vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Kubernetes pod logs To check the logs for individual app pods, you can use the command line to run oc 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. 
 Monitoring <br><br> * Because IBM manages your cluster master, event alerting for the master is disabled. IBM monitors your cluster master and fixes issues as they are detected. For this reason, in the Administrator perspective of the Red Hat OpenShift, you might see a Not available message for the control plane status.<br> * The built-in Prometheus alert manager includes two rules that display as active alerts in a FIRING state: KubeControllerManagerDown and KubeSchedulerDown. These components are part of the IBM-managed cluster master, so you can ignore these alerts.<br><br><br> 
 Operating system Worker nodes must run RHEL 7 or RHEL 8. You can't create a cluster with worker nodes that run different types of operating systems, such as Red Hat OpenShift on Red Hat Enterprise Linux and community Kubernetes on Ubuntu. 
 OperatorHub catalog To use the OperatorHub catalog in private clusters see [Disabling and mirroring OperatorHub catalog source images](https://cloud.ibm.com/docs/openshift?topic=openshift-operatorsmirror-operatorhub). 
 Pod instances You can run 110 pods per worker node. If you have worker nodes with 11 CPU cores or more, you can support 10 pods per core, up to a limit of 250 pods per worker node. The number of pods includes kube-system and ibm-system pods that run on the worker node. For improved performance, consider limiting the number of pods that you run per compute core so that you don't overuse the worker node. For example, on a worker node with a b3c.4x16 flavor, you might run 10 pods per core that use no more than 75% of the worker node total capacity.
Note that VPC Block Storage is not removed automatically, even if you used a Delete storage class to provision the storage. If the reclaim policy says Retain, or if you provisioned your storage without a storage class, then your PV and physical storage are not removed when you remove the PVC. You must remove the PVC, PV, and the physical storage separately.

If your storage is charged monthly, you still get charged for the entire month, even if you remove the storage before the end of the billing cycle.
3. Remove any pods that mount the PVC. List the pods that mount the PVC. If no pod is returned in your CLI output, you don't have a pod that uses the PVC.

kubectl get pods --all-namespaces -o=jsonpath='{range .items[]}{"n"}{.metadata.name}{":t"}{range .spec.volumes[]}{.persistentVolumeClaim.claimName}{" "}{end}{end}' | grep "<pvc_name>"

Example output

blockdepl-12345-prz7b: claim1-block-bronze
4. Remove the pod that uses the PVC. If the pod is part of a deployment, remove the deployment.

kubectl delete pod <pod_name>
5. Verify that the pod is removed.

kubectl get pods
6. Remove the PVC.

kubectl delete pvc <pvc_name>
7. Review the status of your PV. Use the name of the PV that you retrieved earlier as VOLUME. When you remove the PVC, the PV that is bound to the PVC is released. Depending on how you provisioned your storage, your PV goes into a Deleting state if the PV is deleted automatically, or into a Released state, if you must manually delete the PV. Note: For PVs that are automatically deleted, the status might briefly say Released before it is deleted. Rerun the command after a few minutes to see whether the PV is removed.
You can disable or enable the storage of response data on the ALB while the data is sent to the client. This setting is disabled by default. To enable, set the following Ingress resource [annotation](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/rewrite).

nginx.ingress.kubernetes.io/proxy-buffering: "on"





 Customizing connect and read timeouts 

To set the amount of time that the ALB waits to connect to and read from the back-end app before the back-end app is considered unavailable, use the following [annotations](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/custom-timeouts).

nginx.ingress.kubernetes.io/proxy-connect-timeout: 62

nginx.ingress.kubernetes.io/proxy-read-timeout: 62





 Customizing error actions 

To indicate custom actions that the ALB can take for specific HTTP errors, set the custom-http-errors[field](https://kubernetes.github.io/ingress-nginx/examples/customization/custom-errors/).





 Changing the default HTTP and HTTPS ports 

To change the default ports for HTTP (port 80) and HTTPS (port 443) network traffic, [modify each ALB service](https://cloud.ibm.com/docs/containers?topic=containers-comm-ingress-annotationscomm-customize-deploy) with the following Kubernetes Ingress ibm-ingress-deploy-config ConfigMap [fields](https://cloud.ibm.com/docs/containers?topic=containers-comm-ingress-annotationscomm-customize-deploy).

Example field setting.

httpPort=8080
httpsPort=8443





 Adding path definitions to external services
Not Scored 1 Pass Shared 
 5.6.2 Ensure that the seccomp profile is set to docker/default in your pod definitions. Not Scored 2 [Fail](https://cloud.ibm.com/docs/openshift?topic=openshift-cis-benchmark-410ibm-remediations-and-explanations-410) Shared 
 5.6.3 Apply security context to your pods and containers. Not Scored 2 [Fail](https://cloud.ibm.com/docs/openshift?topic=openshift-cis-benchmark-410ibm-remediations-and-explanations-410) Shared 
 5.6.4 The default namespace should not be used. Scored 2 Pass Shared 







 IBM remediations and explanations 



Explanation and remediation

 Section Remediation/Explanation 

 1.2.1 Red Hat OpenShift on IBM Cloud utilizes RBAC for cluster protection, but allows anonymous discovery, which is considered reasonable per [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/). 
 1.2.10 Red Hat OpenShift on IBM Cloud does not enable the [EventRateLimit](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/eventratelimit) admission controller since it is a Kubernetes alpha feature. 
 1.2.12 Red Hat OpenShift on IBM Cloud does not enable the [AlwaysPullImages](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/alwayspullimages) admission controller since it overrides a container's imagePullPolicy and may impact performance. 
 1.2.13 Red Hat OpenShift on IBM Cloud supports [pod security context constraints](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_scc) which are similar to Kubernetes pod security policies.
To block traffic to NodePorts while you are using an NLB service, see [Controlling inbound traffic to network load balancer (NLB) or NodePort services](https://cloud.ibm.com/docs/containers?topic=containers-network_policiesblock_ingress).



Next, you can [register an NLB subdomain](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer_hostname).





 Scheduling algorithms 

Scheduling algorithms determine how an NLB 2.0 assigns network connections to your app pods. As client requests arrive to your cluster, the NLB routes the request packets to worker nodes based on the scheduling algorithm. 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 IBM Cloud Kubernetes Service. 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.
NAME READY STATUS RESTARTS AGE
gid-deployment-5dc86db4c4-5hbts 2/2 Running 0 69s
8. Log in to your pod.

kubectl exec <pod_name> -it -- bash





 Verifying the read and write permissions for the non-root user 



1. List the user ID and group IDs for the current user inside the pod. The setup is correct if your non-root user ID is listed as uid and the supplemental group ID that you defined in your storage class is listed under groups.

id

Example output

uid=2020 gid=0(root) groups=0(root), 65531
2. List the permissions for your volume mount directory that you defined in your deployment. The setup is correct if the supplemental group ID that you defined in your storage class is listed with read and write permissions in your volume mount directory.

ls -l /<volume_mount_path>

Example output

drwxrwxr-x 2 nobody 65531 4096 Dec 11 07:40 .
drwxr-xr-x 1 root root 4096 Dec 11 07:30 ..
3. Create a file in your mount directory.

echo "Able to write to file storage with my non-root user." > /myvol/gidtest.txt
4. List the permissions for the files in your volume mount directory.

ls -al /mnt/nfsvol/

Example output

drwxrwxr-x 2 nobody 65531 4096 Dec 11 07:40 .
drwxr-xr-x 1 root root 4096 Dec 11 07:30 ..
-rw-r--r-- 1 2020 4294967294 42 Dec 11 07:40 gidtest.txt .

In your CLI output, the non-root user ID is listed with read and write access to the file that you created.
5. Exit your pod.

exit
As long as your cluster has enough space, you can have as many pods as you want.

Spread pods across multiple nodes (anti-affinity)
: When you create your deployment, each pod can be deployed to the same worker node. This is known as affinity, or colocation. To protect your app against worker node failure, you can configure your deployment to spread your pods across multiple worker nodes by using the podAntiAffinity option with your standard clusters. You can define two types of pod anti-affinity: preferred or required. For more information, see the Kubernetes documentation on [Assigning Pods to Nodes](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/).

For an example of affinity in an app deployment, see [Making your app deployment YAML file](https://cloud.ibm.com/docs/containers?topic=containers-appapp_yaml).

Distribute pods across multiple zones or regions
: To protect your app from a zone failure, you can create multiple clusters in separate zones or add zones to a worker pool in a multizone cluster. Multizone clusters are available only in certain [classic](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zoneszones-mz) or [VPC](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zoneszones-vpc) multizones, such as Dallas. If you create multiple clusters in separate zones, you must [set up a global load balancer](https://cloud.ibm.com/docs/containers?topic=containers-ha_clustersmultiple-clusters-glb). When you use a replica set and specify pod anti-affinity, Kubernetes spreads your app pods across the nodes. If your nodes are in multiple zones, the pods are spread across the zones, increasing the availability of your app. If you want to limit your apps to run only in one zone, you can configure pod affinity, or create and label a worker pool in one zone.
When you grant the supplemental group ID read and write access to the file storage, any non-root user that belongs to the group ID, including your pod, is granted access to the file storage.

You can use one of the provided [gid storage classes](https://cloud.ibm.com/docs/containers?topic=containers-file_storagefile_storageclass_reference) or create a custom storage class to define your own supplemental group ID.

Allocating a supplemental group ID for a non-root user of a file storage device is supported for single zone clusters only, and can't be used in multizone clusters.



1. Select one of the [provided gid storage classes](https://cloud.ibm.com/docs/containers?topic=containers-file_storagefile_storageclass_reference) to assign the default group ID 65531 to your non-root user that you want to read and write to your file storage. If you want to assign a custom group ID, create a YAML file for a customized storage class. In your customized storage class YAML file, include the gidAllocate: "true" parameter and define the group ID in the gidFixed parameter.

Example storage classes for assigning the default group ID 65531.



* ibmc-file-bronze-gid
* ibmc-file-silver-gid
* ibmc-file-gold-gid



Example customized storage class to specify a different group ID.

apiVersion: storage.k8s.io/v1beta1
kind: StorageClass
metadata:
name: ibmc-file-bronze-gid-custom
labels:
kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
type: "Endurance"
iopsPerGB: "2"
sizeRange: "[1-12000]Gi"
mountOptions: nfsvers=4.1,hard
billingType: "hourly"
reclaimPolicy: "Delete"
classVersion: "2"
gidAllocate: "true"
You can also configure a single-tenant cluster to allow privileged pods without putting other tenants at risk of being compromised. Keep in mind that managing a cluster requires in-depth Kubernetes, Red Hat OpenShift, and infrastructure knowledge to ensure cluster capacity and security for your deployments.

Multi-tenant clusters use Red Hat OpenShift projects to isolate tenants and are usually managed by a separate team that does not belong to one of the tenants. A multi-tenant cluster might be your option if you have multiple teams that must run small workloads in a cluster, and where creating a single-tenant cluster that is highly available across multiple zones does not bring the cost benefits that you want. While multi-tenant clusters usually require fewer people to manage and administer the cluster, they might not provide the level of isolation that you need and add more complexity in the following areas:



* Access: When you set up multiple projects, you must configure proper RBAC policies for each project to ensure resource isolation. RBAC policies are complex and require in-depth Kubernetes knowledge.
* Privileged pods: If one tenant in a multi-tenant cluster requires to run privileged pods, this pod can access other projects in the cluster or damage the shared compute host. Controlling privileged pods is a complex task that requires effort and deep technical expertise. Use [security context constraints (SCCs)](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_sccoc_sccs) to control what resources your tenants can deploy in the cluster.
* Network policies: Because your worker nodes are connected to the same private network, you must make sure that you have strict network policies in place to prevent pods from accessing pods in other namespaces.
* Compute resource limitation: To ensure that every team has the necessary resources to deploy services and run apps in the cluster, you must set up [resource quotas](https://kubernetes.io/docs/concepts/policy/resource-quotas/) for every namespace. Resource quotas determine the deployment constraints for a project, such as the number of Kubernetes resources that you can deploy, and the amount of CPU and memory that can be consumed by those resources.
As noted in the Kubernetes documentation, you can use admission controllers for operations that are otherwise handled by the control plane. As such, take great caution when you configure a custom admission controller. You are responsible for any changes that happen in your cluster because of a custom admission controller.





 What are the best practices for using webhooks? 

Keep in mind the following best practices and considerations when you configure a webhook.



* Create [replica pods](https://cloud.ibm.com/docs/containers?topic=containers-appreplicaset) for the webhook so that if one pod goes down, the webhook can still process requests from your resources. Spread the replica pods across zones, if possible.
* Set an appropriate failurePolicy option, such as whether your webhook fails or ignores connection failures or timeouts. You might set the failurePolicy to Ignore if you want your webhook to ignore connection errors an timeouts. Note that this does not change how the apiserver behaves if the webhook rejects a request.
* Review the timeoutSeconds interval. Older webhooks that use the v1beta1.admissionregistration.k8s.io API have a default timeout of 30 seconds. The v1 API uses a default of 10 seconds. If the webhook failure policy is Ignore and the current timeoutSeconds is 30, consider reducing the timeout to 10 seconds.
* Set appropriate CPU and memory [resource requests and limits](https://cloud.ibm.com/docs/containers?topic=containers-appresourcereq) for your webhook.
* Add [liveness and readiness probes](https://cloud.ibm.com/docs/containers?topic=containers-appprobe) to help make sure your webhook container is running and ready to serve requests.
* Set pod [anti-affinity scheduling rules](https://cloud.ibm.com/docs/containers?topic=containers-appaffinity) to prefer that your webhook pods run on different worker nodes and zones when possible.
Selecting Point of Delivery (PoD) based locations using the CLI and API 

Each physical data center location in IBM Cloud® is divided into multiple, discrete networking LANs, otherwise known as PoDs. Each of these has its own separate network infrastructure, a limited number of VLANs, as well as public and private IP subnets. These VLANs and subnets are shared by all clients that have compute capacity that is provisioned within that PoD space.

Currently, you can use the UI to select the deploying data center location at the specific zone, such as tok02. You can also select the deploying VLAN and subnet when you have the existing one. However, you cannot specify PoD-based locations except for a gateway appliance and VLAN in the UI.

Because you cannot specify PoD locations, and there is no VLAN or subnets, your provisioning can be distributed over multiple PoDs, which can be problematic.

To prevent this issue, you can order a "Premium VLAN" in advance, then specify it as your network VLAN; however, this option incurs an additional cost.

A better option is to use the CLI and API.



  Using the CLI and API to specify PoD 

You can use the CLI and API to specify PoD using the following option:

--extras '{"virtualGuests": [{"hostname": "test", "domain": "softlayer.com", "primaryBackendNetworkComponent": {"router": {"id": 1673467}}}]}'

The primaryBackendNetworkComponentId can be obtained through the following API call:

slcli call-api SoftLayer_Network_Pod getAllObjects
You can check which pods use the priority classes by running the following command.

kubectl get pods --all-namespaces -o custom-columns=NAME:.metadata.name,PRIORITY:.spec.priorityClassName





 Creating a priority class 

To set pod priority, you need to use a priority class.

Before you begin:



* [Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster)
* Ensure that you have the [Writer or Manager IBM Cloud IAM service access role](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms) for the default namespace.





1. List existing priority classes. You can use an existing priority class as a template for the new class.

kubectl get priorityclasses
2. Choose the priority class that you want to copy and create a local YAML file.

kubectl get priorityclass <priority_class> -o yaml > Downloads/priorityclass.yaml
3. Make your priority class YAML file.

apiVersion: scheduling.k8s.io/v1alpha1
kind: PriorityClass
metadata:
name: <priority_class_name>
value: <1000000>
globalDefault: <false>
description: "Use this class for XYZ service pods only."



Understanding the YAML file components

 Components Description 

 name Required: The name of the priority class that you want to create. 
 value Required: Enter an integer less than or equal to 1 billion (1000000000). The higher the value, the higher the priority. Values are relative to the values of other priority classes in the cluster.
You cannot uninstall individual Speech service components
: The documentation now notes that you cannot uninstall individual service components (microservices) once they are installed. To remove any of the following components, you must uninstall the Watson Speech services in their entirety and reinstall only the components that you need: Speech to Text runtime, Speech to Text asynchronous HTTP, Speech to Text customization, Text to Speech runtime, and Text to Speech customization. For more information about installing the Speech services, see [Watson Speech services on IBM Cloud Pak for Data](https://www.ibm.com/docs/en/cloud-paks/cp-data/4.5.x?topic=services-watson-speech).

New beta spell_out_mode parameter for German voices
: To indicate how individual characters of a string are to be spelled out, you can now include the beta spell_out_mode query parameter with a synthesis request for a German voice. By default, the service spells out individual characters at the same rate at which it synthesizes text for a language. You can use the parameter to direct the service to spell out individual characters more slowly, in groups of one, two, or three characters. Use the parameter with the SSML <say-as> element to control how the characters of a string are synthesized. For more information, see [Specifying how strings are spelled out](https://cloud.ibm.com/docs/text-to-speech?topic=text-to-speech-synthesis-paramsparams-spell-out-mode).

Known limitation with using the Ogg audio format with the Safari browser
: By default, the service returns audio in the Ogg audio format with the Opus codec (audio/ogg;codecs=opus). However, the Ogg audio format is not supported with the Safari browser. If you are using the the Text to Speech service with the Safari browser, you must specify a different format in which you want the service to return the audio.