vania-janet/multiturn-rag-retrieval-data huggingface dataset:
5.2.1 Red Hat OpenShift on IBM Cloud can optionally configure [Red Hat OpenShift security context constraints](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_scc) and [Kubernetes pod security admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/) which are similar to the deprecated [Kubernetes pod security policies](https://kubernetes.io/docs/concepts/security/pod-security-policy/). 
 5.2.2 Red Hat OpenShift on IBM Cloud can optionally configure [Red Hat OpenShift security context constraints](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_scc) and [Kubernetes pod security admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/) which are similar to the deprecated [Kubernetes pod security policies](https://kubernetes.io/docs/concepts/security/pod-security-policy/). 
 5.2.3 Red Hat OpenShift on IBM Cloud can optionally configure [Red Hat OpenShift security context constraints](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_scc) and [Kubernetes pod security admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/) which are similar to the deprecated [Kubernetes pod security policies](https://kubernetes.io/docs/concepts/security/pod-security-policy/).
If you don't want to enable automatic sidecar injection for a namespace, you can manually inject the sidecar into a deployment YAML. Inject sidecars manually when apps are running in namespaces alongside other deployments that you don't want sidecars automatically injected into.

Do not enable sidecar injection for the kube-system, ibm-system, or ibm-operators namespaces.



1. Download the istioctl client.

curl -L https://istio.io/downloadIstio | sh -
2. Navigate to the Istio package directory.

cd istio-1.18.0



To manually inject sidecars into a deployment:



1. Inject the Envoy sidecar into your app deployment YAML.

istioctl kube-inject -f <myapp>.yaml | kubectl apply -f -
2. Deploy your app.

kubectl apply <myapp>.yaml
3. If you didn't create a service to expose your app, create a Kubernetes service. Your app must be exposed by a Kubernetes service to be included as a microservice in the Istio service mesh. Ensure that you follow the [Istio requirements for pods and services](https://istio.io/latest/docs/ops/deployment/requirements/).
4. Define a service for the app.

apiVersion: v1
kind: Service
metadata:
name: myappservice
spec:
selector:
<selector_key>: <selector_value> Enter the label key selector_key and value selector_value pair that you want to use to target the pods where your app runs.
ports:
- protocol: TCP
port: 8080 The port that the service listens on.
5. Create the service in your cluster. Ensure that the service deploys into the same namespace as the app.

kubectl apply -f myappservice.yaml -n <namespace>
For example, run the following commands to stage your app without App Management utilities:

ibmcloud cf set-env <myApp> BLUEMIX_APP_MGMT_INSTALL false
ibmcloud cf restage <myApp>





 Restrictions 

Changes that you make to your app by using App Management are transient and are lost after you exit this mode. This mode is only for temporary development use and is not intended to be used as a production environment due to performance.



 Liberty utilities 



 jmx 

The jmx utility enables the JMX REST Connector to allow a remote JMX client to manage the app by using IBM Cloud user credentials.

You can monitor multiple instances of an app by using JMX, but it requires a separate JMX connection for each instance. The default is to monitor instance 0. To monitor instance 1, you can use the following:

ibmcloud cf ssh -i 1 -N -T -L 5000:127.0.0.1:5001

For more information on configuring a JMX connector, see [Configuring secure JMX connection to the Liberty profile](https://www.ibm.com/support/knowledgecenter/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/twlp_admin_restconnector.html).

The jmx utility does not start proxy.





 localjmx 

The localjmx utility enables the [localConnector-1.0](http://www.ibm.com/support/knowledgecenter/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/rwlp_feature_localConnector-1.0.html) Liberty feature. Combined with local port forwarding, localjmx acts an alternate way of allowing a remote JMX client to manage the app.

localjmx requires you to install JConsole.

To use localjmx, first establish port forwarding by using the ibmcloud cf ssh command. For example:

ibmcloud cf ssh -N -T -L 5000:127.0.0.1:5000 <appName>
For more information, see the [Kubernetes documentation on Assigning Pods to Nodes](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/).

Required anti-affinity
: You can deploy only the number of replicas that you have worker nodes for. For example, if you have three worker nodes in your cluster but you define five replicas in your YAML file, then only three replicas deploy. Each replica lives on a different worker node. The leftover two replicas remain pending. If you add another worker node to your cluster, then one of the leftover replicas deploys to the new worker node automatically. If a worker node fails, the pod does not reschedule because the affinity policy is required. For an example YAML with required, see [Liberty app with required pod anti-affinity](https://github.com/IBM-Cloud/kube-samples/blob/master/deploy-apps-clusters/liberty_requiredAntiAffinity.yaml).

Preferred anti-affinity
: You can deploy your pods to nodes with available capacity, which provides more flexibility for your workload. When possible, the pods are scheduled on different worker nodes. For example, if you have three worker nodes with enough capacity in your cluster, it can schedule the five replica pods across the nodes. However, if you add two more worker nodes to your cluster, the affinity rule does not force the two extra pods that are running on the existing nodes to reschedule onto the free node.

Worker node affinity
: You can configure your deployment to run on only certain worker nodes, such as bare metal. For more information, see [Deploying apps to specific worker nodes by using labels](https://cloud.ibm.com/docs/containers?topic=containers-deploy_appnode_affinity).

Example for preferred anti-affinity

spec:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
if [ "$1" == "-h" ]] || [ "$1" == "--help" ]]; then
usage; exit 1
fi
fi

number of options provided to the script must be 2
if [ "$" -ne 2 ]]; then
echo "Invalid number of options provided"
usage; exit 1
fi

1st option must be 'iam' or 'pod-identity'
if [! "$1" = "iam" ]] && [! "$1" = "pod-identity" ]]; then
echo "Provide a valid auth-type"
usage; exit 1
fi

IBMCLOUD_AUTHTYPE=$1
SECRET=$2
}

usage - prints the usage for execution of script
usage() {
echo "USAGE:
bash generate-secret.sh <auth-type> <apikey/profile-id>
auth-type: auth-type should be either iam or pod-identity. Provide iam to use api key, pod-identity to use trusted profile"
}

main
main() {

validate_options "$@"

auth_type="IBMCLOUD_AUTHTYPE=$IBMCLOUD_AUTHTYPE"

secret=

if [ "$IBMCLOUD_AUTHTYPE" == "iam" ]]; then
secret="IBMCLOUD_APIKEY=$SECRET"
else
secret="IBMCLOUD_PROFILEID=$SECRET"
fi

encodedValue=$(echo -e "$auth_typen$secret" | base64)
on certain os, base64 encoding introduces newline, removing the same here.
encodedValue=${encodedValue//$'n'/}

fetch the controller pod name
controllerPodName=$(kubectl get pods -n kube-system | grep ibm-vpc-block-csi-controller | awk '{print $1}')
Try to limit the number of containers that run in privileged mode and consider changing the configuration for your app so that the app can run without advanced permissions.

If you want to block privileged containers from running in your cluster, consider setting up custom [security context constraints](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_scccustomize_sccs).

Apply OS security settings to pods
: You can customize the default [security context constraints](https://docs.openshift.com/enterprise/3.0/admin_guide/manage_scc.html) to control the user ID and group ID that can run inside the container, or the user ID and group ID that owns the volume mount path. Setting a specific user ID helps facilitate a least privilege model. If the security context does not specify a user, Kubernetes automatically uses the user that is specified in the container image. For more information , see [Configuring security context constraints](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_scc).

Set CPU and memory limits for containers
: Every container requires a specific amount of CPU and memory to properly start and to continue to run. You can define [Limit ranges](https://docs.openshift.com/enterprise/3.1/dev_guide/limits.html) for your containers or pods to limit the amount of CPU and memory that they can consume. If no limits for CPU and memory are set, and the container is busy, the container uses all the resources that are available. This high consumption of resources might affect other containers on the worker node that don't have enough resources to properly start or run, and puts your worker node at risk for denial-of-service attacks.







 Storing personal information 

You are responsible for ensuring the security of your personal information in Kubernetes resources and container images. Personal information includes your name, address, phone number, email address, or other information that might identify, contact, or locate you, your customers, or anyone else.

Use a Kubernetes secret to store personal information
For more information, see the [Kubernetes documentation on Assigning Pods to Nodes](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/).

Required anti-affinity
: You can deploy only the number of replicas that you have worker nodes for. For example, if you have three worker nodes in your cluster but you define five replicas in your YAML file, then only three replicas deploy. Each replica lives on a different worker node. The leftover two replicas remain pending. If you add another worker node to your cluster, then one of the leftover replicas deploys to the new worker node automatically. If a worker node fails, the pod does not reschedule because the affinity policy is required. For an example YAML with required, see [Liberty app with required pod anti-affinity](https://github.com/IBM-Cloud/kube-samples/blob/master/deploy-apps-clusters/liberty_requiredAntiAffinity.yaml).

Preferred anti-affinity
: You can deploy your pods to nodes with available capacity, which provides more flexibility for your workload. When possible, the pods are scheduled on different worker nodes. For example, if you have three worker nodes with enough capacity in your cluster, it can schedule the five replica pods across the nodes. However, if you add two more worker nodes to your cluster, the affinity rule does not force the two extra pods that are running on the existing nodes to reschedule onto the free node.

Worker node affinity
: You can configure your deployment to run on only certain worker nodes, such as bare metal. For more information, see [Deploying apps to specific worker nodes by using labels](https://cloud.ibm.com/docs/openshift?topic=openshift-deploy_appnode_affinity).

Example for preferred anti-affinity

spec:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
Red Hat OpenShift has different default settings than community Kubernetes, such as stricter security context constraints. Review the following common scenarios where you might need to modify your apps so that you can deploy them on Red Hat OpenShift clusters.



Common scenarios that require app modifications

 Scenario Steps you can take 

 Your app runs as root. You might see the pods fail with a CrashLoopBackOff status The pod requires privileged access. See [Example steps for giving a deployment privileged access](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_deployopenshift_move_apps_example_scc). For more information, see the Red Hat OpenShift documentation for [Managing Security Context Constraints (SCC)](https://docs.openshift.com/container-platform/4.11/authentication/managing-security-context-constraints.html). 
 Your apps are designed to run on Docker. These apps are often logging and monitoring tools that rely on the container runtime engine, call the container runtime API directly, and access container log directories. In Red Hat OpenShift, your image must be compatible to run with the CRI-O container runtime. For more information, see [Using the CRI-O Container Engine](https://docs.openshift.com/container-platform/3.11/crio/crio_runtime.html). 
 Your app uses persistent file storage with a non-root user ID that can't write to the mounted storage device. [Adjust the security context](https://cloud.ibm.com/docs/openshift?topic=openshift-debug_storage_file) for the app deployment so that runAsUser is set to 0. 
 Your service is exposed on port 80 or another port less than 1024. You might see a Permission denied error. Ports less than 1024 are privileged ports that are reserved for start-up processes.
: The subnet that you choose must be within one of the following ranges.



* 172.16.0.0 - 172.17.255.255
* 172.21.0.0 - 172.31.255.255
* 192.168.0.0 - 192.168.254.255
* 198.18.0.0 - 198.19.255.255



: Note that the pod and service subnets can't overlap. The service subnet is in the 172.20.0.0/16 range by default. This value can't be set to the value of the related location's pod-subnet or service-subnet.

--service-subnet SUBNET
: Optional. Specify a custom subnet CIDR to provide private IP addresses for services. This option can be used only if you also enable Red Hat CoreOS with the --coreos-enabled option. All services that are deployed to the cluster are assigned a private IP address in the 172.20.0.0/16 range by default. You can avoid subnet conflicts with the network that you use to connect to your location by specifying a custom subnet CIDR that provides the private IP addresses for your services.
: The subnet must be specified in CIDR format with a size of at least /24, which allows a maximum of 255 services in the cluster, or larger. The subnet that you choose must be within one of the following ranges.



* 172.16.0.0 - 172.17.255.255
* 172.20.0.0 - 172.31.255.255
* 192.168.0.0 - 192.168.254.255
* 198.18.0.0 - 198.19.255.255



: Note that the pod and service subnets can't overlap. The pod subnet is in the 172.16.0.0/16 range by default. This value can't be set to the value of the related location's pod-subnet or service-subnet.

--pod-network-interface-selection METHOD
: Optional. The method for selecting the node network interface for the internal pod network.
App deployment The apps that you deploy to and services that you integrate with your cluster must be able to run on the operating system of the worker nodes. 
 Calico network plug-in Changing the Calico plug-in, components, or default Calico settings is not supported. For example, don't deploy a new Calico plug-in version, or modify the daemon sets or deployments for the Calico components, default IPPool resources, or Calico nodes. Instead, you can follow the documentation to [create a Calico NetworkPolicy or GlobalNetworkPolicy](https://cloud.ibm.com/docs/containers?topic=containers-network_policies), to [change the Calico MTU](https://cloud.ibm.com/docs/containers?topic=containers-kernelcalico-mtu), or to [disable the port map plug-in for the Calico CNI](https://cloud.ibm.com/docs/containers?topic=containers-kernelcalico-portmap). 
 Cluster quota You can't exceed 100 clusters per region and per [infrastructure provider](https://cloud.ibm.com/docs/containers?topic=containers-infrastructure_providers). If you need more of the resource, [contact IBM Support](https://cloud.ibm.com/docs/get-support?topic=get-support-using-avatar). In the support case, include the new quota limit for the region and infrastructure provider that you want. 
 Kubernetes Make sure to review the [Kubernetes project limitations](https://kubernetes.io/docs/setup/best-practices/cluster-large/). 
 KMS provider Customizing the IP addresses that are allowed to connect to your IBM® Key Protect for IBM Cloud® instance is not supported. 
 Kubernetes pod logs To check the logs for individual app pods, you can use the command line to run kubectl logs <pod name>. Do not use the Kubernetes dashboard to stream logs for your pods, which might cause a disruption in your access to the Kubernetes dashboard.
To control access at the pod level, you can configure [pod security policies (PSPs)](https://cloud.ibm.com/docs/containers?topic=containers-psp).

Within the app deployment YAML, you can set the security context for a pod or container. For more information, review the [Kubernetes documentation](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/).

Want to control access at the application level? To create a sign-on flow that you can update at any time without changing your app code, try integrating your app with [IBM Cloud App ID](https://cloud.ibm.com/docs/appid?topic=appid-getting-started).





 After I deploy my app, how can I monitor its health? 

You can set up IBM Cloud [logging and monitoring](https://cloud.ibm.com/docs/containers?topic=containers-health) for your cluster. You might also choose to integrate with a third-party [logging or monitoring service](https://cloud.ibm.com/docs/containers?topic=containers-supported_integrationshealth_services).
For more information about how to use this storage class or set custom group IDs, see [File storage: Adding non-root user access to persistent storage fails](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_storage_nonroot). 
 Billing Hourly 
 Pricing [Pricing information](https://cloud.ibm.com/cloud-storage/file/order) 







 Sample customized storage classes 

You can create a customized storage class and use the storage class in your PVC.

Red Hat OpenShift on IBM Cloud provides [pre-defined storage classes](https://cloud.ibm.com/docs/openshift?topic=openshift-file_storagefile_storageclass_reference) to provision File Storage for Classic with a particular tier and configuration. Sometimes, you might want to provision storage with a different configuration that is not covered in the pre-defined storage classes. You can use the examples in this topic to find sample customized storage classes.

To create your customized storage class, see [Customizing a storage class](https://cloud.ibm.com/docs/openshift?topic=openshift-file_storagecustom-sc-nfs-creat). Then, [use your customized storage class in your PVC](https://cloud.ibm.com/docs/openshift?topic=openshift-file_storageadd_file).



 Creating topology-aware storage 

To use File Storage for Classic in a multizone cluster, your pod must be scheduled in the same zone as your File Storage for Classic instance so that you can read and write to the volume. Before topology-aware volume scheduling was introduced by Kubernetes, the dynamic provisioning of your storage automatically created the File Storage for Classic instance when a PVC was created. Then, when you created your pod, the Kubernetes scheduler tried to deploy the pod to a worker node in the same data center as your File Storage for Classic instance.

Creating the File Storage for Classic instance without knowing the constraints of the pod can lead to unwanted results.
To use a scheduling algorithm, specify its Keepalived short name in the scheduler annotation of your NLB service configuration file: service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler: "rr". Check the following lists to see which scheduling algorithms are supported in Red Hat OpenShift on IBM Cloud. If you don't specify a scheduling algorithm, the round-robin algorithm is used by default. For more information, see the [Keepalived documentation](https://www.keepalived.org/doc/scheduling_algorithms.html).



 Supported scheduling algorithms 

Round Robin (rr)
: The NLB cycles through the list of app pods when routing connections to worker nodes, treating each app pod equally. round-robin is the default scheduling algorithm for version 2.0 NLBs.

Source Hashing (sh)
: The NLB generates a hash key based on the source IP address of the client request packet. The NLB then looks up the hash key in a statically assigned hash table, and routes the request to the app pod that handles hashes of that range. This algorithm ensures that requests from a particular client are always directed to the same app pod. Kubernetes uses Iptables rules, which cause requests to be sent to a random pod on the worker. To use this scheduling algorithm, you must ensure that no more than one pod of your app is deployed per worker node. For example, if each pod has the label run=<app_name>, add the following anti-affinity rule to the spec section of your app deployment:

spec:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: run
operator: In
values:
- <APP_NAME>
topologyKey: kubernetes.io/hostname
Why are DNS lookups from certain pods so slow? 

  What’s happening 

Certain containers that are based on Alpine Linux, such as NGINX, have issues with DNS query handling that can cause them to not process valid DNS responses. A small percentage of DNS lookups from these pods can take over 5 seconds instead of the typical <80ms. If the timeout that is set for your application is less than 5 seconds, the DNS lookups can time out.

To test whether your pod has this problem, log in to it and verify that curl is installed. You can install curl with the apk add curl command. Then, inside the pod run the following command.

for i in $(seq 1 50); do curl -k -w "time_namelookup: %{time_namelookup}n" -so /dev/null "https://www.ibm.com/"; done

  Why it’s happening 

This issue might be caused by the way DNS responses are handled in these pods. For example, when an IPv6 (AAAA record) and an IPv4 (A record) response are returned at nearly the same time, one of the two responses might not be processed, causing the DNS client to not register the response. After a 5 second delay, the DNS client sends out a new request.

  How to fix it 

You can resolve this issue in one of the following ways.



*  (Preferred) Use a base image for your container that does not have this problem, such as Alpine 3.18. You can also replace Alpine with [ubi-minimal](https://hub.docker.com/r/redhat/ubi8-minimal).
*  Add options single-request-reopen or options single-request options to the client pod's /etc/resolv.conf file. For example, use the following postStart command to add these options to your pod. These options tell the DNS client to send out only one request (A or AAAA) at a time, and avoids the problem where two responses come back at nearly the same time.



lifecycle:
postStart:
exec:
command:
- /bin/sh
- -c
- "/bin/echo 'options single-request-reopen' >> /etc/resolv.conf"