vania-janet/multiturn-rag-retrieval-data huggingface dataset:
oc new-app --name <app_name> https://github.com/<path_to_app_repo> [--context-dir=<subdirectory>]

What does the new-app command do?
: The new-app command creates a build configuration and app image from the source code, a deployment configuration to deploy the container to pods in your cluster, and a service to expose the app within the cluster. For more information about the build process and other sources besides Git, see the [Red Hat OpenShift documentation](https://docs.openshift.com/container-platform/4.11/applications/creating_applications/odc-creating-applications-using-developer-perspective.html).







 Deploying apps to specific worker nodes by using labels 

When you deploy an app, the app pods indiscriminately deploy to various worker nodes in your cluster. Sometimes, you might want to restrict the worker nodes that the app pods to deploy to. For example, you might want app pods to deploy to only worker nodes in a certain worker pool because those worker nodes are on bare metal machines. To designate the worker nodes that app pods must deploy to, add an affinity rule to your app deployment.

Before you begin



* [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).
* Make sure that you are assigned a [service access role](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-perms) that grants the appropriate Kubernetes RBAC role so that you can work with Kubernetes resources in the Red Hat OpenShift project.
* Optional: [Set a label for the worker pool](https://cloud.ibm.com/docs/openshift?topic=openshift-add_workersworker_pool_labels) that you want to run the app on.



To deploy apps to specific worker nodes,



1. Get the ID of the worker pool that you want to deploy app pods to.
The default satellite-healthcheck-<location_ID> Link endpoint allows the Satellite control plane master to check the health of your location's control plane cluster, and alerts IBM Site Reliability Engineers (SREs) when manual intervention is required.



* To manually resolve issues with your Satellite location infrastructure management, such as host assignment or attachment, IBM SREs use tooling to access the IBM Cloud Satellite API server. The Satellite API server communicates with the Satellite control plane master in IBM Cloud.
* To manually resolve issues with masters of Satellite-enabled IBM Cloud service clusters in your location, such as if the master fails to correctly deploy, IBM SREs use tooling to access the default openshift-api-<cluster_ID> Link endpoint for the master of the service cluster.



Note that tooling is controlled through the IBM Cloud region that your Satellite location is managed from.





 What access do IBM SREs have to my data and workloads that run in my Satellite-enabled IBM Cloud service clusters? 

Satellite Link uses a zero-trust model: IBM Cloud has no access to your workloads by default. Any management of infrastructure in your location that is initiated by IBM SREs occurs through the Satellite API server, which exists in IBM Cloud, and any management of Satellite-enabled IBM Cloud service cluster masters occurs through the default openshift-api-<cluster_ID> Link endpoint for that cluster.

The access through the openshift-api-<cluster_ID> endpoint is isolated from your workloads and the network connections, such as the Link endpoints, that your workloads use. The openshift-api-<cluster_ID> provides access only to the Satellite location control plane. IBM SREs have no access to the hosts that are assigned as worker nodes of your Satellite-enabled IBM Cloud service clusters, where you run workloads in your location, because no default Link endpoints are created for workloads that run on these worker nodes, and all SSH access is disabled as part of the host bootstrapping process.





 How can I monitor and manage IBM access into my location?
Sizing your Kubernetes cluster to support your workload 

Figuring out how many worker nodes you need in your cluster to support your workload is not an exact science. You might need to test different configurations and adapt. Good thing that you are using IBM Cloud Kubernetes Service, where you can add and remove worker nodes in response to your workload demands.

To get started on sizing your cluster, ask yourself the following questions.



 How many resources does my app require? 

First, let's begin with your existing or project workload usage.



1. Calculate your workload's average CPU and memory usage. For example, you might view the Task Manager on a Windows machine, or run the top command on a Mac or Linux. You might also use a metrics service and run reports to calculate workload usage.
2. Anticipate the number of requests that your workload must serve so that you can decide how many app replicas you want to handle the workload. For example, you might design an app instance to handle 1000 requests per minute and anticipate that your workload must serve 10000 requests per minute. If so, you might decide to make 12 app replicas, with 10 to handle the anticipated amount and an extra 2 for surge capacity.







 What else besides my app might use resources in the cluster? 

Now let's add some other features that you might use.



1. Keep in mind that the [worker nodes reserve certain amounts of CPU and memory resources](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodesresource_limit_node) to run required components, such as the operating system or container runtime.
2. Consider whether your app pulls large or many images, which can take up local storage on the worker node.
3.
By default, the source IP address of the client request is not preserved. When a client request to your app is sent to your cluster, the request is routed to a pod for the load balancer service that exposes the ALB. If no app pod exists on the same worker node as the load balancer service pod, the load balancer forwards the request to an app pod on a different worker node. The source IP address of the package is changed to the public IP address of the worker node where the app pod runs.

To preserve the original source IP address of the client request, you can enable [source IP preservation](https://kubernetes.io/docs/tutorials/services/source-ip/source-ip-for-services-with-typeloadbalancer). Preserving the client’s IP is useful, for example, when app servers have to apply security and access-control policies.

When source IP preservation is enabled, load balancers shift from forwarding traffic to an app pod on a different worker node to an app pod on the same worker node. Your apps might experience downtime during this shift. If you [disable an ALB](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_alb_configure), any source IP changes you make to the load balancer service that exposes the ALB are lost. When you re-enable the ALB, you must enable source IP again.

If you configured edge nodes in your cluster, ALB pods are deployed to edge nodes and can only forward traffic to app pods that are also deployed to those edge nodes. Ensure that you have [at least three edge worker nodes per zone](https://cloud.ibm.com/docs/containers?topic=containers-edgeedge_nodes).

To enable source IP preservation, edit the load balancer service that exposes an Ingress ALB:



1. Enable source IP preservation for a single ALB or for all the ALBs in your cluster.



* To set up source IP preservation for a single ALB:



1. Get the ID of the ALB for which you want to enable source IP.
[Create a worker pool](https://cloud.ibm.com/docs/openshift?topic=openshift-add_workersadd_pool) that spans all zones in your cluster and has at least two workers per zone if you use NLBs or 3 or more workers per zone if you use ALBs. In the ibmcloud oc worker-pool create command, include the --label dedicated=edge option to label all worker nodes in the pool. All worker nodes in this pool, including any worker nodes that you add later, are labeled as edge nodes.

If you want to use an existing worker pool, the pool must span all zones in your cluster and have at least two worker nodes per zone. You can label the worker pool with dedicated=edge by using the [ibmcloud oc worker-pool label set command](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_worker_pool_label_set).

To ensure that ALB pods are always scheduled to edge worker nodes if they are present and not scheduled to non-edge worker nodes, you must create or use an existing worker pool that has at least three edge worker nodes per zone. During the update of an ALB pod, a new ALB pod rolls out to replace an existing ALB pod. However, ALB pods have anti-affinity rules that don't permit a pod to deploy to a worker node where another ALB pod already exists. If you have only two edge nodes per zone, both ALB pod replicas already exist on those edge nodes, so the new ALB pod must be scheduled on a non-edge worker node. When three edge nodes are present in a zone, the new ALB pod can be scheduled to the third edge node. Then, the old ALB pod is removed.
2. Verify that the worker pool and worker nodes have the dedicated=edge label.



* To check the worker pool

ibmcloud oc worker-pool get --cluster <cluster_name_or_ID> --worker-pool <worker_pool_name_or_ID>
* To check individual worker nodes, review the Labels field of the output of the following command.
To access default Red Hat OpenShift components such as the web console or OperatorHub without being connected to your VPC's private network, you must attach a [public gateway](https://cloud.ibm.com/docs/vpc?topic=vpc-about-networking-for-vpcpublic-gateway-for-external-connectivity) to the VPC subnets that the worker nodes are deployed to. All egress is permitted for worker nodes on a subnet with an attached public gateway, but all ingress is still blocked.

If you deploy apps in your cluster that must receive traffic requests from the internet, you can [create a VPC load balancer](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaas) to expose your apps. To allow ingress network traffic to your apps, you must configure your VPC load balancer for the ingress network traffic that you want to receive.

Security groups are applied to your VPC instance and VPC ALBs by default. For more information, see [Controlling traffic with VPC security groups](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-security-group).





 What is network segmentation and how can I set it up for a VPC cluster? 

Network segmentation describes the approach to divide a network into multiple subnetworks. You can group apps and related data to be accessed by a specific group in your organization. Apps that run in one subnetwork can't see or access apps in another subnetwork. Network segmentation also limits the access that is provided to an insider or third-party software and can limit the range of malicious activities.

Red Hat OpenShift on IBM Cloud provides IBM Cloud VPC subnets that ensure quality network performance and network isolation for worker nodes. A VPC subnet consists of a specified private IP address range (CIDR block) and configures a group of worker nodes and pods as if they were attached to the same physical wire. VPC subnets are dedicated to your IBM Cloud account and not shared across IBM customers.
Repeat the previous step for each pod in your cluster.
5. Add up the resource requests and limits of the apps that you deployed by default.



6. Subtract the sum of your workload resource limits that you estimated in Step 5 from the available compute resources of your worker nodes that you estimated in Step 2. The remaining amount is the extra compute resources that you have to run new workloads or to scale your existing workloads.
7. For workloads that need to scale up and down in response to resource requests, set up the [horizontal pod autoscaler](https://cloud.ibm.com/docs/containers?topic=containers-update_appapp_scaling) and [cluster worker pool autoscaler](https://cloud.ibm.com/docs/containers?topic=containers-cluster-scaling-classic-vpc).
8. [Set up monitoring tools](https://cloud.ibm.com/docs/containers?topic=containers-health-monitorview_metrics) to continue reviewing CPU and memory usage across worker nodes in your cluster.
9. Run performance tests to continue refining the number of worker nodes you need in your cluster, with representative latency, scalability, data set, and workload requirements.









 Structuring your Kubernetes environment 

Your IBM Cloud Kubernetes Service is linked to one IBM Cloud infrastructure portfolio only. Within your account, you can create clusters that are composed of a master and various worker nodes. IBM manages the master, and you can create a mix of worker pools that pool together individual machines of the same flavor, or memory and CPU specs. Within the cluster, you can further organize resources by using namespaces and labels. Choose the best mix of cluster, flavors, and organization strategies so that you can make sure that your teams and workloads get the resources that they need.



 What type of cluster and flavors should I get? 

Types of clusters: Decide whether you want a [single zone, multizone, or multiple cluster setup](https://cloud.ibm.com/docs/containers?topic=containers-ha_clustersha_clusters).
Also, keep in mind that worker nodes use some compute resources for basic cluster functionality, default and custom [add-ons](https://cloud.ibm.com/docs/containers?topic=containers-updateaddons), and [resource reserves](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodesresource_limit_node).

What does scaling up and down look like?
: In general, the cluster autoscaler calculates the number of worker nodes that your cluster needs to run its workload. Scaling the cluster up or down depends on many factors, including the following.



* The minimum and maximum worker node size per zone that you set.
* Your pending pod resource requests and certain metadata that you associate with the workload, such as anti-affinity, labels to place pods only on certain flavors, or [pod disruption budgets](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/).
* The worker pools that the cluster autoscaler manages, potentially across zones in a [multizone cluster](https://cloud.ibm.com/docs/containers?topic=containers-ha_clustersmz-clusters).
* The [custom Helm chart values](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-helmca_chart_values) that are set, such as skipping worker nodes for deletion if they use local storage.



For more information, see the Kubernetes Cluster Autoscaler FAQs for [How does scale-up work?](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.mdhow-does-scale-up-work) and [How does scale-down work?](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.mdhow-does-scale-down-work).

Can I change how scale-up and scale-down work?
For more information about available bare metal flavors and how bare metal is different from virtual machines, see [Physical machines (bare metal)](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodesbm).
* What is the smallest size cluster that I can make?

Your cluster must have at least 1 worker node to run default Kubernetes components. You can't have a cluster with 0 worker nodes, and you can't power off or suspend billing for your worker nodes. Additionally, the type of cluster and the number of worker pools that you have can impact the size of your cluster.



* Single zone clusters: [Create a cluster](https://cloud.ibm.com/docs/containers?topic=containers-clusters) with 1 worker node in the default worker pool.
* Multizone clusters: You must [create a cluster](https://cloud.ibm.com/docs/containers?topic=containers-clusters) with 1 worker node per zone in the worker pool. Later, you can [remove zones](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_zone_rm) from the worker pool or [remove individual worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_rm) so that your cluster size reduces to the minimum size of 1.
* Worker pools: For any type of cluster, each worker pool must always have at least 1 worker node. For the smallest size cluster possible, you can have only 1 worker pool.



Keep in mind that some services such as Ingress might require multiple worker nodes for high availability, and you might not be able to run these services or your apps in the smallest size cluster possible.
* Which Kubernetes versions does the service support?

IBM Cloud Kubernetes Service concurrently supports multiple versions of Kubernetes. When a new version (n) is released, versions up to 2 behind (n-2) are supported. Versions more than 2 behind the latest (n-3) are first deprecated and then unsupported.
* [Taint your worker pool](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cliworker_pool_taint) to allow only the deployments or pods with the matching toleration to be deployed to your worker pool.
* [Add a label](https://cloud.ibm.com/docs/containers?topic=containers-add_workersworker_pool_labels) to your worker pool other than the default worker pool. This label is used in your deployment configuration to specify nodeAffinity or nodeSelector which limits the workloads that can be deployed on the worker nodes in the labeled worker pool.
* Use [pod disruption budgets](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/) to prevent abrupt rescheduling or deletions of your pods.
* If you're using pod priority, you can [edit the priority cutoff](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.mdhow-does-cluster-autoscaler-work-with-pod-priority-and-preemption) to change what types of priority trigger scaling up. By default, the priority cutoff is zero (0).







 Can I use taints and tolerations with autoscaled worker pools? 

Yes, but make sure to [apply taints at the worker pool level](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cliworker_pool_taint) so that all existing and future worker nodes get the same taint. Then, you must include a [matching toleration in your workload configuration](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) so that these workloads are scheduled onto your autoscaled worker pool with the matching taint.
* [Taint your worker pool](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-cliworker_pool_taint) to allow only the deployments or pods with the matching toleration to be deployed to your worker pool.
* [Add a label](https://cloud.ibm.com/docs/openshift?topic=openshift-add_workersworker_pool_labels) to your worker pool other than the default worker pool. This label is used in your deployment configuration to specify nodeAffinity or nodeSelector which limits the workloads that can be deployed on the worker nodes in the labeled worker pool.
* Use [pod disruption budgets](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/) to prevent abrupt rescheduling or deletions of your pods.
* If you're using pod priority, you can [edit the priority cutoff](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.mdhow-does-cluster-autoscaler-work-with-pod-priority-and-preemption) to change what types of priority trigger scaling up. By default, the priority cutoff is zero (0).







 Can I use taints and tolerations with autoscaled worker pools? 

Yes, but make sure to [apply taints at the worker pool level](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-cliworker_pool_taint) so that all existing and future worker nodes get the same taint. Then, you must include a [matching toleration in your workload configuration](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) so that these workloads are scheduled onto your autoscaled worker pool with the matching taint.
If you have only two edge nodes per zone, both ALB pod replicas already exist on those edge nodes, so the new ALB pod must be scheduled on a non-edge worker node. When three edge nodes are present in a zone, the new ALB pod can be scheduled to the third edge node. Then, the old ALB pod is removed.
2. Verify that the worker pool and worker nodes have the dedicated=edge label.



* To check the worker pool

ibmcloud ks worker-pool get --cluster <cluster_name_or_ID> --worker-pool <worker_pool_name_or_ID>
* To check individual worker nodes, review the Labels field of the output of the following command.

kubectl describe node <worker_node_private_IP>



3. Retrieve all existing NLBs in the cluster.

kubectl get services --all-namespaces | grep LoadBalancer

In the output, note the Namespace and Name of each load balancer service. For example, the following output shows one public NLB in the default namespace.

NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default webserver-lb LoadBalancer 172.21.190.18 169.46.17.2 80:30597/TCP 11m
4. Using the output from the previous step, run the following command for each NLB. This command redeploys the NLB to an edge worker node. You can deploy both public and private NLBs to the edge worker nodes.

kubectl get service -n <namespace> <service_name> -o yaml | kubectl apply -f -

Example output

service "webserver-lb" configured
5. To verify that networking workloads are restricted to edge nodes, confirm that NLB are scheduled onto the edge nodes and are not scheduled onto non-edge nodes.



* NLB pods



1. Confirm that the NLB pods are deployed to edge nodes. Search for the external IP address of the load balancer service that is listed in the output of step 3.
The following steps for limiting strongSwan VPN traffic by worker node use this example scenario: Say that you have a multi-tenant IBM Cloud Kubernetes Service cluster with six worker nodes. The cluster supports tenant A and tenant B. You taint the worker nodes in the following ways.



* Two worker nodes are tainted so that only tenant A pods are scheduled on the workers.
* Two worker nodes are tainted so that only tenant B pods are scheduled on the workers.
* Two worker nodes are not tainted because at least 2 worker nodes are required for the strongSwan VPN pods and the load balancer IP to run on.



To limit VPN traffic to tainted nodes for each tenant.



1. To limit the VPN traffic to only workers dedicated to tenant A in this example, you specify the following toleration in the values.yaml file for the tenant A strongSwan Helm chart.

tolerations:
- key: dedicated
operator: "Equal"
value: "tenantA"
effect: "NoSchedule"

This toleration allows the route daemon set to run on the two worker nodes that have the dedicated="tenantA" taint and on the two untainted worker nodes. The strongSwan VPN pods for this deployment run on the two untainted worker nodes.
2. To limit the VPN traffic to only workers dedicated to tenant B in this example, you specify the following toleration in the values.yaml file for the tenant B strongSwan Helm chart.

tolerations:
- key: dedicated
operator: "Equal"
value: "tenantB"
effect: "NoSchedule"

This toleration allows the route daemon set to run on the two worker nodes that have the dedicated="tenantB" taint and on the two untainted worker nodes. The strongSwan VPN pods for this deployment also run on the two untainted worker nodes.









 Upgrading or disabling the strongSwan Helm chart 

Ensure that you consistently upgrade your strongSwan Helm chart for the latest features and security fixes.

Review the supported versions of the strongSwan Helm chart. Typically, a chart version becomes deprecated 6 months after its release date.