vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Disable the add-on for the [ALB OAuth Proxy](https://cloud.ibm.com/docs/containers?topic=containers-debug-tool) in a cluster.

ibmcloud ks cluster addon disable alb-oauth-proxy --cluster CLUSTER

Minimum required permissions
: Administrator platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster.



 Example addon disable alb-oauth-proxy command 

ibmcloud ks cluster addon disable alb-oauth-proxy --cluster my_cluster







 ibmcloud ks cluster addon disable debug-tool 

Virtual Private Cloud

Classic infrastructure

Disable the add-on for the IBM Cloud Kubernetes Service Diagnostics and Debug Tool.

ibmcloud ks cluster addon disable debug-tool --cluster CLUSTER [-f]

Minimum required permissions
: Administrator platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster.

-f
: Optional: Force the command to run with no user prompts.





 ibmcloud ks cluster addon disable istio 

Classic infrastructure

Disable the managed Istio add-on. Removes all Istio core components from the cluster, including Prometheus.

ibmcloud ks cluster addon disable istio --cluster CLUSTER [-f]

Minimum required permissions
: Administrator platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster.

-f
: Optional: This Istio add-on is a dependency for the istio-extras and istio-sample-bookinfo managed add-ons. Include this option to also disable those add-ons.





 ibmcloud ks cluster addon disable istio-extras 

Classic infrastructure
As opposed to version 1.0 NLBs, version 2.0 NLBs don't use NAT when forwarding requests to app pods on other workers. When an NLB 2.0 routes a client request, it uses IP over IP (IPIP) to encapsulate the original request packet into another packet. This encapsulating IPIP packet has a source IP of the worker node where the load balancer pod is, which allows the original request packet to preserve the client IP as its source IP address. The worker node then uses direct server return (DSR) to send the app response packet to the client IP. The response packet skips the NLB and is sent directly to the client, decreasing the amount of traffic that the NLB must handle. For more information about DSR load balancing with version 2.0 NLBs, see [Components and architecture of an NLB 2.0](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer-aboutplanning_ipvs).





 Components and architecture of an NLB 1.0 

The TCP/UDP network load balancer (NLB) 1.0 uses Iptables, a Linux kernel feature to load balance requests across an app's pods.

Mixed protocol load balancer services are not supported in IBM Cloud Kubernetes Service. You cannot specify both TCP and UDP ports your in load balancer definition.



 Traffic flow in a single-zone cluster 

The following diagram shows how an NLB 1.0 directs communication from the internet to an app in a single-zone cluster.

Zoom

![Expose an app in a single-zone cluster by using an NLB 1.0.](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/cs_loadbalancer_planning.png)

Figure 1. Expose an app in a single-zone cluster by using an NLB 1.0



1. A request to your app uses the public IP address of your NLB and the assigned port on the worker node.
Hostname: webserver-855556f688-76rkp
Pod Information:
-no pod information available-
Server values:
server_version=nginx: 1.13.3 - lua: 10008
Request Information:
client_address=1.1.1.1
method=GET
real path=/
query=
request_version=1.1
request_scheme=http
request_uri=http://<loadbalancer_IP>:8080/
Request Headers:
accept=/
host=<loadbalancer_IP>
user-agent=curl/7.54.0
Request Body:
-no body in request-

In the Request Information section of the output, the source IP address is, for example, client_address=1.1.1.1. The source IP address is the public IP of the system that you're using to run curl. Otherwise, if you are connecting to the internet through a proxy or VPN, the proxy or VPN might be obscuring your system's actual IP address. In either case, the NLB sees your system's source IP address as the client IP address.
6. Copy your system's source IP address (client_address=1.1.1.1 in the previous step output) into your cheat sheet to use in later lessons.



Great! At this point, your app is exposed to the public internet from the public NLB port only. Traffic to the public node ports is blocked. Your cluster is partially locked down from unwanted traffic.

Next, you can create and apply Calico policies to allow traffic from only certain source IPs.





 Step 3: Allow incoming traffic from a specific IP to the NLB 

You now decide to completely lock down traffic to the PR firm's cluster and test access by allowing only your own computer's IP address.

First, in addition to the node ports, you must block all incoming traffic to the NLB exposing the app. Then, you can create a policy that allows your system's IP address.
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

You can find the complete example in [this IBM Cloud deployment pattern blog](https://www.ibm.com/cloud/blog/ibm-cloud-kubernetes-service-deployment-patterns-4-multi-zone-cluster-app-exposed-via-loadbalancer-aggregating-whole-region-capacity).





 Unsupported scheduling algorithms 

Destination Hashing (dh)
: The destination of the packet, which is the NLB IP address and port, is used to determine which worker node handles the incoming request. However, the IP address and port for NLBs in Red Hat OpenShift on IBM Cloud don't change. The NLB is forced to keep the request within the same worker node that it is on, so only app pods on one worker handle all incoming requests.

Dynamic connection counting algorithms
: The following algorithms depend on dynamic counting of connections between clients and NLBs. However, because direct service return (DSR) prevents NLB 2.0 pods from being in the return packet path, NLBs don't track established connections.



* Least Connection (lc)
* Locality-Based Least Connection (lblc)
* Locality-Based Least Connection with Replication (lblcr)
* Never Queue (nq)
* Shortest Expected Delay (seq)



Weighted pod algorithms
: The following algorithms depend on weighted app pods. However, in Red Hat OpenShift on IBM Cloud, all app pods are assigned equal weight for load balancing.



* Weighted Least Connection (wlc)
* Weighted round-robin (wrr)
* Control who can create pods in your cluster with [pod security policies](https://cloud.ibm.com/docs/containers?topic=containers-psp).



Then, you can check out the following network configuration steps for your cluster setup:



* Classic clusters:



* Isolate networking workloads to edge worker nodes [in classic clusters without a gateway](https://cloud.ibm.com/docs/openshift?topic=openshift-edge).
* Expose your apps with [public networking services](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_network_planningopenshift_routers) or [private networking services](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_network_planningprivate_access).
* Connect your cluster with services in private networks outside of your IBM Cloud account by setting up [IBM Cloud Direct Link](https://cloud.ibm.com/docs/dl?topic=dl-get-started-with-ibm-cloud-dl) or the [strongSwan IPSec VPN service](https://cloud.ibm.com/docs/openshift?topic=openshift-vpn).
* Create Calico host network policies to isolate your cluster on the [public network](https://cloud.ibm.com/docs/openshift?topic=openshift-network_policiesisolate_workers_public) and on the [private network](https://cloud.ibm.com/docs/openshift?topic=openshift-network_policiesisolate_workers).
* If you use a gateway appliance, such as a Virtual Router Appliance (VRA), [open up the required ports and IP addresses](https://cloud.ibm.com/docs/openshift?topic=openshift-firewallfirewall_inbound) in the public firewall to permit inbound traffic to networking services.
1.2.13 IBM Cloud Kubernetes Service can optionally configure [Pod security admission](https://cloud.ibm.com/docs/containers?topic=containers-pod-security-admission), which is similar to the unsupported [Kubernetes pod security policies](https://kubernetes.io/docs/concepts/security/pod-security-policy/). 
 1.2.16 IBM Cloud Kubernetes Service can optionally configure [Pod security admission](https://cloud.ibm.com/docs/containers?topic=containers-pod-security-admission), which is similar to the unsupported [Kubernetes pod security policies](https://kubernetes.io/docs/concepts/security/pod-security-policy/). 
 1.2.22 IBM Cloud Kubernetes Service can optionally [enable Kubernetes API server auditing](https://cloud.ibm.com/docs/containers?topic=containers-health-auditaudit-api-server). 
 1.2.23 IBM Cloud Kubernetes Service can optionally [enable Kubernetes API server auditing](https://cloud.ibm.com/docs/containers?topic=containers-health-auditaudit-api-server). 
 1.2.24 IBM Cloud Kubernetes Service can optionally [enable Kubernetes API server auditing](https://cloud.ibm.com/docs/containers?topic=containers-health-auditaudit-api-server). 
 1.2.25 IBM Cloud Kubernetes Service can optionally [enable Kubernetes API server auditing](https://cloud.ibm.com/docs/containers?topic=containers-health-auditaudit-api-server). 
 1.2.33 IBM Cloud Kubernetes Service can optionally [enable a Kubernetes Key Management Service (KMS) provider](https://cloud.ibm.com/docs/containers?topic=containers-encryptionkms).
If you choose to [enable source IP preservation for an NLB 1.0 service](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancerlb_source_ip), ensure that app pods are scheduled onto the edge worker nodes by [adding edge node affinity to app pods](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancerlb_edge_nodes). App pods must be scheduled onto edge nodes to receive incoming requests.
4. Optional: You can remove a taint from the worker nodes.

To remove all taints from all worker nodes in a worker pool,

ibmcloud ks worker-pool taint rm -c <cluster_name_or_ID> --worker-pool <worker_pool_name_or_ID>

To remove individual taints from individual worker nodes,

kubectl taint node <node_name> dedicated:NoSchedule- dedicated:NoExecute-







 Deploying the Sysdig agent on edge worker nodes 

To allow the Sysdig agent pods to be deployed to your edge worker nodes, run the following kubectl patch command to update the sysdig-agent DaemonSet. This command applies the NoExecute toleration to the DaemonSet to ensure that the agent pods don't get evicted from the node.

kubectl patch ds sysdig-agent -n ibm-observe --type merge --type='json' -p='[{"op": "add", "path": "/spec/template/spec/tolerations/-", "value": {"operator": Exists, "effect": NoExecute}}]'

If you used pod labels such as dedicated=edge, you can also apply this label to any pods that you want to allow on your edge nodes.
For example, if you use any in-cluster webhooks, you must add policies to ensure that the webhooks can make the required connections. You also must create policies for any non-local services that extend the Kubernetes API. You can find these services by running oc get apiservices. Note that default/openshift-apiserver is included as a local service and does not require a network policy.









 Controlling traffic between pods 

Kubernetes policies protect pods from internal network traffic. You can create simple [Kubernetes network policies](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-kube-policies) to isolate app microservices from each other within a namespace or across namespaces.

By default, any pod has access to any other pod in the cluster. Additionally, any pod has access to any services that are exposed by the pod network, such as a metrics service, the cluster DNS, the API server, or any services that you manually create in your cluster.





 Logging denied traffic 

To log denied traffic requests to certain pods in your cluster, you can create a Calico log network policy.

When you set up network policies to limit traffic to app pods, traffic requests that are not permitted by these policies are denied and dropped. In some scenarios, you might want more information about denied traffic requests. For example, you might notice some unusual traffic that is continuously being denied by one of your network policies. To monitor the potential security threat, you can set up logging to record every time that the policy denies an attempted action on specified app pods.

This section shows you how to log traffic that is denied by a Kubernetes network policy. To log traffic that is denied by a Calico network policy, see [Lesson 5 of the Calico network policy tutorial](https://cloud.ibm.com/docs/openshift?topic=openshift-policy_tutoriallesson5).
Lock the data store for the Calico IPAM records.

calicoctl datastore migrate lock
2. Save the IPAM check results.

calicoctl ipam check -o report.json
3. Release unused IP addresses. This process can run for up to 20 minutes depending on how many IP addresses must be released.

calicoctl ipam release --from-report=report.json
4. Unlock the data store.

calicoctl datastore migrate unlock
5. Verify that all unused IP addresses are released.

calicoctl ipam check

Example output

Check complete; found 0 problems.



5. Optional: To verify that the data store was successfully unlocked and that IP addresses are now available for assignment, create a pod and check that it starts correctly.



1. For example, create a simple NGINX pod.

oc run test --image=nginx --generator=run-pod/v1
2. Verify that the pod has an IP address and is running successfully.

oc get po test
3. Delete the test pod.

oc delete pod test



6. Continue to the next section to check for unused IP address blocks.







 Step 2: Releasing IP address blocks 

Next, check for and clean up entire blocks of IP addresses that are assigned to a worker node but are not used by that worker node.

Occasionally, when a worker node is assigned a second or third block of IP addresses, entire blocks of IP addresses that the worker node previously used might later be completely unused. Additionally, when you remove or replace a worker node, the cleanup of the IP address block by the Calico IPAM might fail due to the lack of a worker node for the calico-kube-controllers to temporarily run on, or due to problems with the CNI plug-in or containerd runtime when the worker node is removed or replaced.

Ensuring that IP blocks are free is especially important for all classic clusters that run Kubernetes version 1.19 or later and all VPC clusters.
[Disable the network policies in your namespace](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-troubleshootingibp-v2-troubleshooting-disable-network-policies). This should resolve connectivity issues with your nodes.





 How do I disable the network policies in my namespace? 

 What’s happening 

You may need to disable the network policies in your namespace to address connectivity issues in your network.

 How to fix it 

Check if network policies have been applied in your namespace by running the following CLI command:

kubectl get netpol -n <NAMESPACE>

If the command returns a list of one or more network policies that you did not apply and/or you want to disable, first disable the operator creation of network policies. Get the operator deployment spec in your namespace and check for environment variable IBPOPERATOR_CONSOLE_APPLYNETWORKPOLICY:

kubectl get deploy ibm-hlfsupport-operator -n <NAMESPACE>

If it is present, remove the environment variable IBPOPERATOR_CONSOLE_APPLYNETWORKPOLICY:

kubectl edit deploy ibm-hlfsupport-operator -n <NAMESPACE>

Once the operator creation of the network policy has been disabled, delete the network policies from the namespace:

kubectl delete netpol -n <NAMESPACE> <NETWORKPOLICYNAME>





 How do I delete a peer pod? 

 What’s happening 

You are looking for the commands to delete a peer.

 How to fix it 

Use the following CLI command to identify and then delete and restart the failing peer:



* List the pods: kubectl get pods --all-namespaces
* Delete the pod: kubectl delete pod -n <NAMESPACE> <PODNAME>



Replace <NAMESPACE> with the name of your Kubernetes namespace or your OpenShift project.





 How can I recover a contract after a failed upgrade of the smart contract container? 

 What’s happening
Unsupported: Deprecated and removed OpenShift features For more information, review the [OpenShift version 4.13 deprecated and removed features](https://docs.openshift.com/container-platform/4.13/release_notes/ocp-4-13-release-notes.htmlocp-4-13-deprecated-removed-features) and [Preparing to update to OpenShift Container Platform 4.13](https://docs.openshift.com/container-platform/4.13/updating/updating-cluster-prepare.htmlupdating-cluster-prepare) for possible actions required. 
 Known OpenShift issues For more information, review the [OpenShift version 4.13 known issues](https://docs.openshift.com/container-platform/4.13/release_notes/ocp-4-13-release-notes.htmlocp-4-13-known-issues) for possible actions required. 
 Updated worker node metrics configuration In order for your cluster to maintain pod and node metrics during the update, your cluster master must be at fix pack version [4.12.16_1545_openshift](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_412&interface=ui41216_1545_openshift_M) or later and your cluster worker nodes must be at fix pack version [4.12.19_1546_openshift](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_412&interface=ui41219_1546_openshift_W) or later. 
 OpenShift Console access changes on IBM Cloud VPC Previously, Red Hat OpenShift on IBM Cloud VPC clusters that have disabled their public service endpoint, provided Red Hat OpenShift console access via the private service endpoint URL (for example https://cX00.private.us-south.containers.cloud.ibm.com:port) which required the internet browser to reach the IBM Cloud private network with routing to 166.8.0.0/14.
The ConfigMap maps the user ID nobody from the NFS host system to the root user ID 0 in your container. This process is also referred to as no root squash. An effective way of updating all your worker nodes is to use a daemon set, which runs a specified pod on every worker node in your cluster. In this case, the pod that is controlled by the daemon set updates each of your worker nodes to enable root permission on the volume mount path.

The deployment is configured to allow the daemon set pod to run in privileged mode, which is necessary to access the host file system. Running a pod in privileged mode does create a security risk, so use this option with caution.

While the daemon set is running, new worker nodes that are added to the cluster are automatically updated.

Before you begin:



* [Create persistent storage](https://cloud.ibm.com/docs/openshift?topic=openshift-file_storageadd_file).
* [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).



Steps:



1. Copy the norootsquash daemon set [deployment YAML file](https://github.com/IBM-Cloud/kube-samples/tree/master/daemonset-sample)
2. Create the norootsquash daemon set deployment.

oc apply -f norootsquash.yaml
3. Get the name of the pod that your storage volume is mounted to. This pod is not the same as the norootsquash pods.

oc get pods
4. Log in to the pod.

oc exec -it mypod /bin/bash
5. Verify that the permissions to the mount path are root.

root@mypod:/ ls -al /mnt/myvol/
total 8
drwxr-xr-x 2 root root 4096 Feb 7 20:49 .
drwxr-xr-x 1 root root 4096 Feb 20 18:19 .
Use cocoa change-request attachment add instead!

Adds a Change Task to a specific Change Request.

Options:

--description A more detailed description for the Change Task. [string]
--name Name of the Change Task. [string] [required]
--data Data for the Change Task or a path prefixed with @ to read the data from. [string] [default: "@/dev/stdin"]
--provider (Optional) Change Management service provider (choices: 'servicenow', 'servicenow-v3', default: 'servicenow')

Required Environment Variables, if you are using ServiceNow v1 or v2 provider:

SERVICENOW_TOKEN= ServiceNow API Token
SERVICENOW_URL= ServiceNow API URL

Required Environment Variables, if you are using ServiceNow v3 provider:

IAM_ACCESS_TOKEN= Access token obtained from the IAM service corresponding to pnp-ibmcloud-api-key.
SERVICENOW_URL= ServiceNow API URL

Running the command:

$ cocoa change-request task add "CHGXXXXXXX" --name='<task-name>' --data='<data-for-the-task>'

$ cat data.txt | cocoa change-request task add "CHGXXXXXXX" --name='<task-name>'

$ cocoa change-request task add "CHGXXXXXXX" --name='<task-name>' --data='@<path/to/file>'





 cocoa change-request task get 

This command is deprecated and will be removed in 2.0.0. Use cocoa change-request attachment get instead!

Gets a specific Change Task of a Change Request.

Options:

--provider (Optional) Change Management service provider (choices: 'servicenow', 'servicenow-v3', default: 'servicenow')

Required Environment Variables, if you are using ServiceNow v1 or v2 provider:

SERVICENOW_TOKEN= ServiceNow API Token
SERVICENOW_URL= ServiceNow API URL
Controlling traffic between pods with Kubernetes policies 

Virtual Private Cloud

You can use Kubernetes policies to control network traffic between pods in your cluster and to isolate app microservices from each other within a namespace or across namespaces.

Level of application: Worker node host endpoint

Default behavior: No Kubernetes network policies exist by default in your cluster. By default, any pod has access to any other pod in the cluster. Additionally, any pod has access to any services that are exposed by the pod network, such as a metrics service, the cluster DNS, the API server, or any services that you manually create in your cluster.

Use case: Kubernetes network policies specify how pods can communicate with other pods and with external endpoints. Both incoming and outgoing network traffic can be allowed or blocked based on protocol, port, and source or destination IP addresses. Traffic can also be filtered based on pod and namespace labels. When Kubernetes network policies are applied, they are automatically converted into Calico network policies. The Calico network plug-in in your cluster enforces these policies by setting up Linux Iptables rules on the worker nodes. Iptables rules serve as a firewall for the worker node to define the characteristics that the network traffic must meet to be forwarded to the targeted resource.

If most or all pods don't require access to specific pods or services, and you want to ensure that pods by default can't access those pods or services, you can create a Kubernetes network policy to block ingress traffic to those pods or services.

For more information about how Kubernetes network policies control pod-to-pod traffic and for more example policies, see the [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/network-policies/).



 Isolate app services within a namespace 

The following scenario demonstrates how to manage traffic between app microservices within one namespace.

An Accounts team deploys multiple app services in one namespace, but they need isolation to permit only necessary communication between the microservices over the public network. For the app Srv1, the team has front end, back end, and database services.