vania-janet/multiturn-rag-retrieval-data huggingface dataset:
You can assign a tag to Red Hat OpenShift on IBM Cloud clusters to help manage your IBM Cloud resources. For example, you might add key:value tags to your cluster and other cloud resources so that your billing department track resources, such as costctr:1234. Tags are visible account-wide. For more information, see [Working with tags](https://cloud.ibm.com/docs/account?topic=account-tag).

Tags are not the same thing as Kubernetes labels. [Kubernetes labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) are key:value pairs that can be used as selectors for the resources that are in your cluster, such as [adding a label to worker pool](https://cloud.ibm.com/docs/openshift?topic=openshift-add_workersworker_pool_labels) to [deploy an app to only certain worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-deploy_appnode_affinity). Tags are an IBM Cloud tool that you can use to filter your IBM Cloud resources, such as clusters, storage devices, or Watson services.

Do not include personal information in your tags. Learn more about [securing your personal information](https://cloud.ibm.com/docs/containers?topic=containers-securitypi) when you work with Kubernetes resources.

Choose among the following options:



* [Create a cluster in the console](https://cloud.ibm.com/docs/openshift?topic=openshift-clusters) with a tag. You can't create a cluster with a tag in the CLI.
* Add tags to an existing cluster in the console or CLI.





 Adding tags to clusters with the console 



1. Log in to the [IBM Cloud clusters console](https://cloud.ibm.com/kubernetes/clusters).
2. Select a cluster with existing tags.
3. Next to the cluster name and status, click the Edit tags pencil icon.
* UI
* CLI







 Installing Delivery Pipeline Private Workers 

Install and register a Delivery Pipeline Private Worker so that IBM Cloud® Continuous Delivery Development teams can use the private worker in their toolchain configuration. Developers can run workloads within the network scope of the private worker installation without any inbound network connectivity.

The Delivery Pipeline uses public and private workers to run pipeline jobs. By default, pipeline jobs are run by using public workers on IBM-managed public shared infrastructure. Pipeline jobs can access resources only on the public network (both within and outside of IBM) and are limited to 60 minutes run time per job.

In certain scenarios, your Delivery Pipeline might require access to internal or on-premises resources. In these situations, you can connect to and integrate a Delivery Pipeline Private Worker to run on your own Kubernetes infrastructure.

The private worker agents that are installed on private clusters request data only from the IBM-hosted private worker service. The data flow is one way and originates only from the agent.



 Prerequisites 

Before you install a private worker, make sure that you have an IBM Cloud® account to create authentication keys. You need the latest kubectl version that is installed on the Administrator's desktop computer. And you must also have a [Kubernetes cluster](https://cloud.ibm.com/kubernetes/clusters) (version 1.15 or higher) with Administrative access to install a private worker.



* Suggested Kubernetes cluster configurations:



* IBM Cloud Kubernetes Service version 1.21 or higher to run workloads in isolation on IBM Cloud Public.
* Red Hat® OpenShift® on IBM Cloud® version 4.9 or later.



* Network access:



* Inbound: Not required.
You can also enable health check monitors on the NLB IPs for each subdomain.

Zoom

![LoadBalancer service traffic in Classic clusters](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/classic-nlb-sz.svg)

How Kubernetes forwards network traffic through LoadBalancer services.





 LoadBalancer services in VPC clusters 

Virtual Private Cloud

[Load Balancer for VPC](https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaas). When you create a Kubernetes LoadBalancer service for an app in your cluster, a layer 7 VPC load balancer is automatically created in your VPC outside of your cluster. The VPC load balancer is multizonal and routes requests for your app through the private NodePorts that are automatically opened on your worker nodes. By default, the load balancer is also created with a hostname that you can use to access your app.

Zoom

![LoadBalancer service traffic in VPC clusters](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/vpc-nlb-sz.svg)

How Kubernetes forwards network traffic through LoadBalancer services.







 Ingress 

Expose multiple apps in a cluster by setting up routing with the [Ingress](https://cloud.ibm.com/docs/containers?topic=containers-managed-ingress-about) application load balancer (ALB). The ALB uses a secured and unique public or private entry point, an Ingress subdomain, to route incoming requests to your apps. You can use one subdomain to expose multiple apps in your cluster as services. Ingress consists of three components:
You can enter text in the drop-down list instead of scrolling through the list.
3. Optional: To scope the access policy to a resource group, select the resource group from the resource group drop-down list. If you want to scope the policy to a Kubernetes namespace, make sure to clear the resource group drop-down list. You can't scope an access policy to both a Kubernetes namespace and a resource group at the same time.
4. From the Region list, select one or all regions.
5. From the Clusterstring equals drop-down list, select the cluster that you want to scope the access policy to. To scope the policy to all clusters, clear or leave the field blank.
6. From the Namespacestring equals field, enter the Kubernetes namespace that you want to scope the access policy to. Note that you can't scope an access policy to a namespace if you also scope the access policy to a resource group. Additionally, if you scope an access policy to a namespace, you must assign only a service access role. don't assign a platform access role at the same time as you assign a service access role. Assign a platform access role separately.
7. Select roles for the access policy.



* Platform access role: Grants access to IBM Cloud Kubernetes Service so that users can manage infrastructure resources such as clusters, worker nodes, worker pools, Ingress application load balancers, and storage. To find a list of supported actions per role, see [platform access roles reference page](https://cloud.ibm.com/docs/containers?topic=containers-iam-platform-access-roles). Note that if you assign a user the Administrator platform access role for only one cluster, you must also assign the user the Viewer platform access role for all clusters in that region in the resource group.
* Service access role: Grants access to the Kubernetes API from within a cluster so that users can manage Kubernetes resources such as pods, deployments, services, and namespaces.
--context-attributes endpointType=private
: Set the context attribute endpointType=private without associating a network zone allows all private traffic to the cluster.

--context-attributes endpointType=public,networkZoneId=all-client-ip
: Set the context attribute endpointType=public and associate the networkZoneId=allow-client-ip that you created earlier to allow only the resources in the allow-client-ip zone to access the cluster over the public network.
2. Verify the rule was created.

ibmcloud cbr rules







 Step 3: Testing your context-based restrictions 

To test your context-based restrictions setup, you can try calling the cluster APIs for your cluster, for example by listing pods, over the public network from an IP address other than the individual IP address that you allowlisted in your network zone. With this setup, all private connectivity is allowed, while only the individual IP address in your network zone can connect to the cluster APIs over the public network.





 Additional scenarios 

Now that you've created a simple CBR network zone and rule, review the following more advanced examples to further control access to your IBM Cloud Kubernetes Service resources.



 Allowing different IPs to access the public and private service endpoints 

In this scenario, you allow different IP addresses or CIDRs to access the public and private service endpoints of your IBM Cloud Kubernetes Service clusters by creating separate network zones for each IP address. Then, you create a rule that allows each network zone to access the public or private service endpoints.



1. Create a network zone for a public IP address or CIDR and another for a private IP address or CIDR that you want to allow to access your IBM Cloud Kubernetes Service clusters.

Example commands to create separate network zones called public-IP-zone and private-IP-zone. In this example, each zone contains multiple IP addresses or CIDRs, separated by a comma, that you want to allow to access your clusters.

ibmcloud cbr zone-create --addresses 1.2.3.4,12.12.12.0/24 --description "Allowed Public IP Addresses Zone" --name "public-ip-zone"
You can create new Helm charts or use preexisting Helm charts to define, install, and upgrade complex Kubernetes applications that run in IBM Cloud Kubernetes Service clusters. For example, you can specify all Kubernetes resources that your app requires in a Helm chart. Then, you can use Helm to create the YAML configuration files and deploy these files in your cluster. You can also [integrate IBM Cloud-provided Helm charts](https://cloud.ibm.com/kubernetes/helm) to extend your cluster's capabilities, such as with a block storage plug-in. For more information, see [Setting up Helm in IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-helm).

Kustomize
: Use the Kubernetes project [Kustomize](https://github.com/kubernetes-sigs/kustomize) to package your apps by both standardizing and customizing your deployments across multiple environments. Kustomize helps you write, customize, and reuse your Kubernetes resource YAML configurations. To get started, see [Packaging apps for reuse in multiple environments with Kustomize](https://cloud.ibm.com/docs/containers?topic=containers-appkustomize).

Razee
: [Razee](https://razee.io/) is an open-source project that automates and manages the deployment of Kubernetes resources across clusters, environments, and cloud providers, and helps you to visualize deployment information for your resources so that you can monitor the rollout process and find deployment issues more quickly. For more information about Razee and how to set up Razee in your cluster to automate your deployment process, see the [Razee documentation](https://github.com/razee-io/Razee).





 Setting up a continuous delivery pipeline for a cluster 

Adopt a DevOps approach by using IBM® Continuous Delivery Pipeline for IBM Cloud®, which includes open toolchains that automate the building and deployment of containerized apps.
You can expose the private cloud service endpoint of the master for your cluster users by [using a private network load balancer (NLB)](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clusteraccess_private_se). The private NLB exposes the private cloud service endpoint of the master as an internal 172.21.x.x cluster IP address that the strongSwan VPN pod can access. If you enable only the private cloud service endpoint, you can use the Kubernetes dashboard or temporarily enable the public cloud service endpoint to create the private NLB.





 Configuring the strongSwan VPN in a multizone cluster 

Multizone clusters provide high availability for apps in the event of an outage by making app instances available on worker nodes in multiple zones. However, configuring the strongSwan VPN service in a multizone cluster is more complex than configuring strongSwan in a single-zone cluster.

Before you configure strongSwan in a multizone cluster, first try to deploy a strongSwan Helm chart into a single-zone cluster. When you first establish a VPN connection between a single-zone cluster and an on-premises network, you can more easily determine remote network firewall settings that are important for a multizone strongSwan configuration.



* Some remote VPN endpoints have settings such as leftid or rightid in the ipsec.conf file. If you have these settings, check whether you must set the leftid to the IP address of the VPN IPSec tunnel.
* If the connection is inbound to the cluster from the remote network, check whether the remote VPN endpoint can re-establish the VPN connection to a different IP address in case of load balancer failure in one zone.



To get started with strongSwan in a multizone cluster, choose one of the following options.



* If you can use an outbound VPN connection, you can choose to configure only one strongSwan VPN deployment.
: Optional: Do not show the message of the day or update reminders.



 Example credential unset command 

ibmcloud ks credential unset --region us-south









 infra-permissions commands 

Check classic IBM Cloud infrastructure permissions that are used in IBM Cloud Kubernetes Service.

The ibmcloud ks infra-permissions commands check only classic IBM Cloud infrastructure, not VPC permissions.



 ibmcloud ks infra-permissions get 

Classic infrastructure

Check whether the credentials that allow [access to the IBM Cloud infrastructure portfolio](https://cloud.ibm.com/docs/containers?topic=containers-access-creds) for the targeted resource group and region are missing suggested or required infrastructure permissions.

If the infrastructure credentials for the region and resource group are missing any permissions, the output of this command returns a list of required and suggested permissions.



* Required: These permissions are needed to successfully order and manage infrastructure resources such as worker nodes. If the infrastructure credentials are missing one of these permissions, common actions such as worker reload can fail for all clusters in the region and resource group.
* Suggested: These permissions are helpful to include in your infrastructure permissions, and might be necessary in certain use cases. For example, the Add Compute with Public Network Port infrastructure permission is suggested because if you want public networking, you need this permission. However, if your use case is a cluster on the private VLAN only, the permission is not needed so it is not considered required.



For a list of common use cases by permission, see [Infrastructure roles](https://cloud.ibm.com/docs/containers?topic=containers-classic-roles).

What if I see an infrastructure permission that I can't find in the console or [Infrastructure roles](https://cloud.ibm.com/docs/containers?topic=containers-classic-roles) table?
: Support Case permissions are managed in a different part of the console than infrastructure permissions. See step 8 of [Customizing infrastructure permissions](https://cloud.ibm.com/docs/containers?topic=containers-access-credsinfra_access).

Which infrastructure permissions do I assign?
The following attributes of the Schematics Workspace or Schematics Action are used to dynamically select the agent instance.



* Resource group
* Location (region)
* Tags



The [Agent assignment policy](https://cloud.ibm.com/docs/schematics?topic=schematics-policy-manage) for an agent instance describes how an Agent is selected to run a Workspace job or Action job.

Example:

If your organization has three different network isolation zones (such as Dev, HR-Stage, and HR-Prod) and you have installed three agents (one each, for the three network isolation zones). You have defined an agent-assignment-policy for the agent running in Dev, with the selector as tags=dev. All workspaces that have tags=dev automatically are bound to the Dev agent. In other words, the Dev agent is used to download Terraform templates (from the Git repository) and run Terraform jobs. Similarly, the agent-assignment-policy can include other attributes of the workspaces, to define the agent for job execution.





 How can I enable debug mode in an agent? 

You can follow these steps to enable or disable the debug mode of an agent.



1. Log in to [IBM Cloud](https://cloud.ibm.com/).
2. Click Kubernetes from the left hand navigator pane, then click Clusters
3. On the Kubernetes Clusters page, click your cluster > Kubernetes dashboard.



* Click the default drop down to view the list of Namespaces:



* In the drop down, type the Schematics-job-runtime Namespaces.
* Click Config Map from the Config and Storage.
* From the Config Maps page. Click the three dots against schematics-jobrunner-config.
* Click Edit to view the Edit a resource page with the YAML, and JSON tabs.
* You can now edit the JR_LOGGERLEVEL parameter for job-runner microservice logging.
Virtual Private Cloud

Classic infrastructure

After you run [ibmcloud oc cluster ca rotate](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_cluster_ca_rotate), view the rotation status of certificate authority (CA) certificates for a cluster.

ibmcloud oc cluster ca status --cluster CLUSTER [-q]

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

Command options:

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

-q
: Optional: Do not show the message of the day or update reminders.



 Example cluster ca status command 

ibmcloud oc cluster ca status --cluster my_cluster







 ibmcloud oc cluster config 

Virtual Private Cloud

Classic infrastructure

After logging in to IBM Cloud, download the Kubernetes configuration data and certificates as a kubeconfig file to your local machine so that you can connect to your cluster and run oc commands.

The kubeconfig file is merged to your existing kubeconfig file in /.kube/config (<user_profile>/.kube/config in Windows), or to the last file that is set by the KUBECONFIG environment variable in your command line session. After you run ibmcloud oc cluster config, you can interact with your cluster immediately, and quickly change the context to other clusters in the Kubernetes context.

ibmcloud oc cluster config --cluster CLUSTER [--admin] [--endpoint ENDPOINT_TYPE] [--network] [--skip-rbac] [-q] [--yaml]

Minimum required permissions
: Viewer or Reader IBM Cloud IAM service access role for the cluster in IBM Cloud Kubernetes Service. Further, if you have only a platform access role or only a service access role, additional constraints apply.
: Updated the IBM Cloud Kubernetes Service CLI plug-in change log page for the [release of version 1.0.57](https://cloud.ibm.com/docs/containers?topic=containers-cs_cli_changelog10).





 6 May 2020 

New! IBM Cloud Kubernetes Service observability plug-in
: You can now use the IBM Cloud Kubernetes Service observability plug-in to create a logging or monitoring configuration for your cluster so that you can forward cluster logs and metrics to an IBM Log Analysis and IBM Cloud Monitoring service instance. For more information, see [Forwarding cluster and app logs to IBM Log Analysis](https://cloud.ibm.com/docs/containers?topic=containers-healthlogging) and [Viewing cluster and app metrics with IBM Cloud Monitoring](https://cloud.ibm.com/docs/containers?topic=containers-health-monitor). You can also use the command line to create the logging and monitoring configuration. For more information, see the [Observability plug-in CLI](https://cloud.ibm.com/docs/containers?topic=containers-observability_cli) reference.





 4 May 2020 

Gateway appliance firewalls
: Updated the [required IP addresses and ports](https://cloud.ibm.com/docs/containers?topic=containers-firewallfirewall_outbound) that you must open in a public gateway device firewall.

Ingress troubleshooting
: Added a [troubleshooting topic](https://cloud.ibm.com/docs/containers?topic=containers-alb-pod-affinity) for when ALB pods don't deploy correctly to worker nodes.







 April 2020 



 30 April 2020 

Cluster and worker node quotas
: Now, each region in your IBM Cloud account has quotas for Kubernetes Service clusters and workers. You can have 100 clusters and 500 worker nodes across clusters per region and per [infrastructure provider](https://cloud.ibm.com/docs/containers?topic=containers-infrastructure_providers).
* The strongSwan Helm chart runs a single VPN pod as the IPSec tunnel endpoint. If the pod fails, the cluster restarts the pod. However, you might experience a short down time while the new pod starts and the VPN connection is re-established. If you require faster error recovery or a more elaborate high availability solution, consider using a VPN solution that runs outside of the cluster on dedicated hardware.
* The strongSwan Helm chart does not provide metrics or monitoring of the network traffic flowing over the VPN connection. For a list of supported monitoring tools, see [Logging and monitoring services](https://cloud.ibm.com/docs/containers?topic=containers-health).
* Only strongSwan Helm chart versions that were released in the last 6 months are supported. Ensure that you consistently [upgrade your strongSwan Helm chart](https://cloud.ibm.com/docs/containers?topic=containers-vpnvpn_upgrade) for the latest features and security fixes.



Your cluster users can use the strongSwan VPN service to connect to your Kubernetes master through the private cloud service endpoint. However, communication with the Kubernetes master over the private cloud service endpoint must go through the 166.X.X.X IP address range, which is not routable from a VPN connection. You can expose the private cloud service endpoint of the master for your cluster users by [using a private network load balancer (NLB)](https://cloud.ibm.com/docs/containers?topic=containers-access_clusteraccess_private_se). The private NLB exposes the private cloud service endpoint of the master as an internal 172.21.x.x cluster IP address that the strongSwan VPN pod can access. If you enable only the private cloud service endpoint, you can use the Kubernetes dashboard or temporarily enable the public cloud service endpoint to create the private NLB.





 Configuring the strongSwan VPN in a multizone cluster 

Multizone clusters provide high availability for apps in the event of an outage by making app instances available on worker nodes in multiple zones.