vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Communication to the cluster master can be on the public or private cloud service endpoint. For more information, see [Understanding cluster network basics](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters). 
 Apps and container platform You can choose to create [community Kubernetes or Red Hat OpenShift clusters](https://cloud.ibm.com/docs/containers?topic=containers-faqscontainer_platforms) to manage your containerized apps. Your app build processes don't differ because of the infrastructure provider, but how you expose the app does. For more information, see [Choosing an app exposure service](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning). 
 App networking All pods that are deployed to a worker node are assigned a private IP address in the 172.30.0.0/16 range and are routed between worker nodes on the worker node private IP address of the private VLAN. To expose the app on the public network, your cluster must have worker nodes on the public VLAN. Then, you can create a NodePort, LoadBalancer (NLB), or Ingress (ALB) service. For more information, see [Planning in-cluster and external networking for apps](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning). 
 Storage You can choose from non-persistent and persistent storage solutions such as file, block, object, and software-defined storage. For more information, see [Planning highly available persistent storage](https://cloud.ibm.com/docs/containers?topic=containers-storage-plan). 
 User access To create classic infrastructure clusters, you must set up [infrastructure credentials](https://cloud.ibm.com/docs/containers?topic=containers-access-creds) for each region and resource group. To let users manage the cluster, use [IBM Cloud IAM platform access roles](https://cloud.ibm.com/docs/containers?topic=containers-iam-platform-access-roles).
For larger clusters, use /22 to have enough pod IP addresses for eight worker nodes, /21 to have enough pod IP addresses for 16 worker nodes, and so on.
: The subnet that you choose must be within one of the following ranges:



* 172.17.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.21.0.0/16 range by default.

--service-subnet SUBNET
: All services that are deployed to the cluster are assigned a private IP address in the 172.21.0.0/16 range by default. If you plan to connect your cluster to on-premises networks through IBM Cloud Direct Link or a VPN service, you can avoid subnet conflicts 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.17.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 pod subnet is in the 172.30.0.0/16 range by default.

--skip-advance-permissions-check
: Optional: Skip [the check for infrastructure permissions](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cliinfra_permissions_get) before creating the cluster.
You can choose to register a Secrets Manager instance to your cluster during the cluster create process. You can also specify a secret group that you can use to control access to the secrets in your cluster. Both of these options can be configured or changed after you have created the cluster.

Encryption
: Data encryption with a key management service (KMS) encrypts secrets and other sensitive information in your cluster. You can add an existing KMS instance to your cluster during the cluster create process.

Cluster details
: You can customize the unique cluster name and any [tags](https://cloud.ibm.com/docs/account?topic=account-tag) that you want to use to organize and identify your IBM Cloud resources, such as the team or billing department.

Observability integrations
: You can enable additional observability integrations that you want to include on your cluster. Some integrations are automatically enabled if you have an existing platform instance of that integration. In this case, you cannot disable the integration. If you want to use an integration and you have only an existing application instance of that integration, the integration is disabled by default and you must manually enable it.
: 

* Activity tracking: Activity Tracker service captures a record of your IBM Cloud activities and monitors the activity of your account. You can use this service to investigate abnormal activity and critical actions, and comply with regulatory audit requirements. In addition, you can be alerted on actions as they happen. If you disable this integration and want to enable it later, see [Getting started with Activity Tracker](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-getting-startedgs_step2).



: 

* Logging: You can use Log Analysis to manage operating system logs, application logs, and platform logs. If you want to enable this integration later, see [Logging for clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-health&interface=ui).



: 

* Monitoring: The monitoring service integration allows operational visibility into the performance and health of your applications, services, and platforms.
Cluster health image v1.3.12 v1.3.13 Updated Go dependencies, golangci-lint, gosec, and to Go version 1.19.3. Updated base image version to 116. 
 etcd v3.4.18 v3.4.21 See the [etcd release notes](https://github.com/etcd-io/etcd/releases/v3.4.21). 
 Gateway-enabled cluster controller 1823 1902 Go module updates. 
 GPU device plug-in and installer 373bb9f cce0cfa Updated the GPU driver 470 minor version 
 IBM Calico extension 1096 1213 Updated image to fix the following CVEs: [CVE-2020-35525](https://nvd.nist.gov/vuln/detail/CVE-2020-35525), [CVE-2020-35527](https://nvd.nist.gov/vuln/detail/CVE-2020-35527), [CVE-2022-3515](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3515), [CVE-2022-37434](https://nvd.nist.gov/vuln/detail/CVE-2022-37434), [CVE-2022-2509](https://nvd.nist.gov/vuln/detail/CVE-2022-2509), [CVE-2022-32149](https://nvd.nist.gov/vuln/detail/CVE-2022-32149). 
 IBM Cloud Controller Manager v1.23.13-1 v1.23.13-5 Key rotation and updated Go dependencies. 
 IBM Cloud File Storage for Classic plug-in and monitor 416 420 Updated universal base image (UBI) to version 8.7-923 to resolve CVEs. 
 Key Management Service provider v2.5.10 v2.5.11 Updated Go dependencies and to Go version 1.19.3.
You might also want to integrate add-ons to your cluster. For example, when you [set up Helm in your cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-helm)







 Creating custom RBAC permissions for users, groups, or service accounts 

The view, edit, admin, and cluster-admin cluster roles are automatically created when you assign the corresponding IBM Cloud IAM service access role. Do you need your cluster access policies to be more granular than these predefined permissions allow? No problem! You can create custom RBAC roles and cluster roles.

You can assign custom RBAC roles and cluster roles to individual users, groups of users, or service accounts. When a binding is created for a group, it affects any user that is added or removed from that group. When you add users to a group, they get the access rights of the group in addition to any individual access rights that you grant them. If they are removed, their access is revoked. Note that you can't add service accounts to access groups.

If you want to assign access to a container process that runs in pods, such as a continuous delivery toolchain, you can use [Kubernetes ServiceAccounts](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/). To follow a tutorial that demonstrates how to set up service accounts for Travis and Jenkins and to assign custom RBAC roles to the service accounts, see the blog post [Kubernetes ServiceAccounts for use in automated systems](https://medium.com/@jakekitchener/kubernetes-serviceaccounts-for-use-in-automated-systems-515297974982).

To prevent breaking changes, don't change the predefined view, edit, admin, and cluster-admin cluster roles. Custom RBAC roles are in addition to and don't change or override any RBAC roles that you might have assigned with IBM Cloud IAM service access roles.
: Required: The name or ID of the cluster.

--hardware HARDWARE
: Optional: The level of hardware isolation for your worker node. Use dedicated so that available physical resources are dedicated to you only, or shared to allow physical resources to be shared with other IBM customers. The default is shared. For bare metal flavors, specify dedicated.

--flavor FLAVOR
: Choose a machine type, or flavor, for your worker nodes. You can deploy your worker nodes as virtual machines on shared or dedicated hardware, or as physical machines on bare metal. Available physical and virtual machines types vary by the zone in which you deploy the cluster. For more information, see the documentation for the ibmcloud ks flavors (machine-types)[command](https://cloud.ibm.com/docs/cli?topic=cli-kubernetes-service-clics_machine_types). This value is required for standard clusters and is not available for free clusters.

--workers NUMBER
: An integer that represents the number of worker nodes to create in the cluster.

--private-vlan PRIVATE_VLAN
: Required: The private VLAN that was specified when the cluster was created. Private VLAN routers always begin with bcr (back-end router) and public VLAN routers always begin with fcr (front-end router). When you create a cluster and specify the public and private VLANs, the number and letter combination after those prefixes must match.

--public-vlan PUBLIC_VLAN
: Optional: The public VLAN that was specified when the cluster was created. If you want your worker nodes to exist on a private VLAN only, don't provide a public VLAN ID. Private VLAN routers always begin with bcr (back-end router) and public VLAN routers always begin with fcr (front-end router). When you create a cluster and specify the public and private VLANs, the number and letter combination after those prefixes must match.
Cluster health image v1.2.15 v1.2.16 Updated universal base image (UBI) to the latest 8.4 version to resolve CVEs: [CVE-2021-36222](https://nvd.nist.gov/vuln/detail/CVE-2021-36222), [CVE-2021-37750](https://nvd.nist.gov/vuln/detail/CVE-2021-37750), [CVE-2021-22922](https://nvd.nist.gov/vuln/detail/CVE-2021-22922), [CVE-2021-22923](https://nvd.nist.gov/vuln/detail/CVE-2021-22923), and [CVE-2021-22924](https://nvd.nist.gov/vuln/detail/CVE-2021-22924). 
 etcd v3.4.16 v3.4.17 See the [etcd release notes](https://github.com/etcd-io/etcd/releases/v3.4.17). 
 IBM Calico extension 763 864 Updated to use Go version 1.16.9. Updated universal base image (UBI) to the latest 8.4 version to resolve CVEs. 
 IBM Cloud Block Storage driver and plug-in v2.1.1 v2.1.2 Updated universal base image (UBI) to version 8.4-210 to resolve CVEs. 
 IBM Cloud Controller Manager v1.21.5-1 v1.21.5-2 Updated to ignore VPC load balancer (LB) state when a LB delete is requested. 
 IBM Cloud File Storage for Classic plug-in and monitor 400 401 Updated universal base image (UBI) to the latest 8.4-210 version to resolve CVEs.
When a VRF or VLAN spanning is enabled, the ALB can route packets to various subnets in the account.
6. If you are using a VPC cluster, ensure that traffic requests that are routed by Ingress to node ports on your worker nodes are permitted in [VPC security groups](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-security-group).
7. Note that if you create and delete a cluster with the same or similar name 5 times or more within 7 days, such as for automation or testing purposes, you might reach the [Let's Encrypt Duplicate Certificate rate limit](https://cloud.ibm.com/docs/containers?topic=containers-cs_rate_limit). To ensure that the Ingress subdomain and certificate are correctly registered, the first 24 characters of the clusters' names must be different.
8. If you restrict network traffic to edge worker nodes, ensure that at least two [edge worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-edge) are enabled in each zone so that ALBs deploy uniformly.



If a zone fails, you might see intermittent failures in requests to the Ingress ALB in that zone.





 Setup steps 

Follow the steps to set up Ingress.



 Step 1: Create a ClusterIP service 

A ClusterIP service is required to make your app reachable from within the cluster so that external requests can be forwarded to the app pod. To be included in Ingress load balancing, the names of the ClusterIP services that expose your apps must be unique across all namespaces in your cluster.

For each app deployment that you want to expose, create a Kubernetes ClusterIP service. Your app must be exposed by a Kubernetes service to be included in the Ingress load balancing.

kubectl expose deploy <app_deployment_name> --name my-app-svc --port <app_port> -n <namespace>





 Step 2: Set up TLS termination with TLS certificates and Kubernetes secrets
Managing an instance group 

When you have an instance group created, you can duplicate it, delete it, or edit it to change the scaling method, group size, or target policies for scaling.

To manage your instance group from the Instance groups for VPC page, complete the following steps.



1. In the [IBM Cloud console](https://cloud.ibm.com/vpc-ext), go to Menu icon ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/icons/icon_hamburger.svg) > VPC Infrastructure > Auto scale > Instance groups.
2. On the Instance groups for VPC page, click the Actions icon ![More Actions icon](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/icons/action-menu-icon.svg) for the instance group that you want to manage and select from the options, Duplicate or Delete.
3. To edit or view the details of an instance group, click the instance group that you want to edit or view to access the Instance group details page.





 Duplicating an instance group 

Duplicating an instance group makes a copy of the current settings and presents you with the New instance group page, with fields pre-populated. You can make any necessary changes and then create a new instance group based off of the instance group that you duplicated.





 Deleting an instance group 

If you no longer need the instance group, you can delete the instance group to permanently remove it from your account. All instances that are part of the instance group are deleted as well.





 Editing an instance group 

You can access the instance group details page to make changes to the instance group. You can change the scaling method between static and dynamic methods. You can adjust the instance group size. And you can edit or add target policies for scaling.



 Editing the details for an instance group
* UI
* CLI
* API







 Deleting a secondary zone 



 Deleting a secondary zone using the UI 

To delete a secondary zone using the UI, take the following steps:



1. Navigate to the Custom resolver section of your DNS Services instance, and select the custom resolver from which you want to delete a secondary zone.
2. In the Custom resolver details page, select the Secondary zone tab.
3. Select the overflow menu icon ![overflow menu icon](https://cloud.ibm.com/docs-content/v1/content/d56dbd8ab7d14086029681ee71679e14aea53723/dns-svcs/images/overflow-icon.png) secondary zone you wish to delete and select Delete.
4. Click Delete in the confirmation dialog box, or click Cancel to stop the deletion.







 Deleting a secondary zone using the CLI 

To delete a secondary zone using the CLI, run the following command:

ibmcloud dns secondary-zone-delete RESOLVER_ID SECONDARY_ZONE_ID [-i, --instance INSTANCE_NAME] [--output FORMAT]

Where:



* RESOLVER_ID is the ID of the custom resolver. Required.
* SECONDARY_ZONE_ID is the ID of the secondary zone. Required.
* -i, --instance value is the instance name or ID. If not set, the context instance specified by ibmcloud dns instance-target INSTANCE is used.
* --output value specifies output format. Currently, json is the only supported format.







 Deleting a secondary zone using the API 

To delete a secondary zone using the API, follow these steps:



1. Set up your [API environment](https://cloud.ibm.com/apidocs/dns-svcsauthentication) with the correct variables.
2. Store the following values in variables to be used in the API command:
<-- </section "id="section-command-example-logpush-job" "> --><-- </section "id="section-logpush-job" "> --><-- <section "id="section-logpush-job-delete" "> --> ibmcloud cis logpush-job-delete Delete a log push job for a given domain (Enterprise plan only). ibmcloud cis logpush-job-delete DNS_DOMAIN_ID --dataset DATASET] --jobid JOB_ID] -f, --force] -i, --instance INSTANCE] ! ! ! ! ! !
<-- <section "id="section-command-options-logpush-job-delete" "> --> Command options DNS_DOMAIN_ID: The ID of DNS domain. Required.--dataset value: The category of logs you want to receive. This value cannot be changed after the job is created. Valid values: http_requests, range_events, firewall_events. The default value is http_requests.--jobid value: JOB_ID is the ID of logpush job.-f, --force: Delete log push job without prompting for confirmation.-i , --instance value: Instance name or ID. If not set, the context instance specified by ibmcloud cis instance-set INSTANCE is used.<-- </section "id="section-command-options-logpush-job-delete" "> --><-- <section "id="section-command-example-logpush-job-delete" "> --> Examples Delete http_requests log push job for domain 31984fea73a15b45779fa0df4ef62f9b. ibmcloud cis logpush-job-delete 31984fea73a15b45779fa0df4ef62f9b --dataset http_requests -i cis-demo --force
<-- </section "id="section-delete-glb-pool-examples" "> --><-- </section "id="section-delete-glb-pool" "> --><-- <section "id="section-update-glb-pool" "> --> ibmcloud cis glb-pool-update Update a given GLB pool. ibmcloud cis glb-pool-update GLB_POOL_ID --enable-origin ORIGIN_NAME --enable-origin ORIGIN_NAME ...] --disable-origin ORIGIN_NAME --disable-origin ORIGIN_NAME ...] --add-origin ORIGIN_PARAMETER --add-origin ORIGIN_PARAMETER ...] --remove-origin ORIGIN_NAME --remove-origin ORIGIN_NAME ...] -i, --instance INSTANCE] --output FORMAT]
ibmcloud cis glb-pool-update GLB_POOL_ID (--json @JSON_FILE | JSON_STRING) -i, --instance INSTANCE] --output FORMAT]
Deprecated] ibmcloud cis glb-pool-update GLB_POOL_ID (-s, --json-str JSON_STR | -j, --json-file JSON_FILE) -i, --instance INSTANCE] --output FORMAT] ! !!!!
<-- <section "id="section-update-glb-pool-options" "> --> Command options GLB_POOL_ID: The ID of global load balancer pool. Required.--json: The JSON file or JSON string used to describe a GLB pool.
<-- <ul> -->

* The required fields in JSON data are name, origins, check_regions:

<-- <ul> -->

* name:a short name (tag) for the pool.
* origins:a list of origins within this pool.
* check_regions:a list of geographic region code.

<-- </ul> -->
The service instance must be in the same IBM Cloud account as your cluster, but can be in a different resource group or region than your cluster. To create a service instance, follow the steps in [Provision an instance](https://cloud.ibm.com/docs/monitoring?topic=monitoring-provision). This value is required.

--sysdig-access-key ACCESS_KEY
: The Monitoring access key that you want to use for your configuration. This value is optional. If you don't specify this option, the latest access key is used for your configuration.

--private-endpoint
: When you add this option to your command, the private cloud service endpoint is used to connect to IBM Cloud Monitoring. To use the private cloud service endpoint, your cluster must be enabled for using private cloud service endpoints. Red Hat OpenShift on IBM Cloud clusters that run version 4 don't support private cloud service endpoints. You must use a cluster that runs version 3.11 to use this option.

Example command

ibmcloud ob monitoring config create --cluster mycluster --instance mymonitoringinstance





 ibmcloud ob monitoring config delete 

Virtual Private Cloud

Classic infrastructure

Delete a Monitoring configuration from your cluster.

To remove monitoring configurations that you manually set up without using the Red Hat OpenShift on IBM Cloud observability plug-in, you must first make this configuration available to the plug-in by using the ibmcloud ob monitoring agent discover [command](https://cloud.ibm.com/docs/openshift?topic=openshift-observability_climonitoring_agent_discover).

When you delete the monitoring configuration, the components that are deleted depend on how you created the monitoring configuration. For monitoring configurations that were created with the ibmcloud ob monitoring config create command, the daemon set for the Monitoring agent, the ConfigMap, and secret are removed from your cluster, and metrics are no longer sent to your IBM Cloud Monitoring service instance.
If not set, the context instance specified by ibmcloud cis instance-set INSTANCE is used.--output: Specify output format, only JSON is supported.<-- </section "id="section-create-range-app-options" "> --><-- <section "id="section-create-range-app-examples" "> --> Examples Create a range app for doamin 31984fea73a15b45779fa0df4ef62f9b. ibmcloud cis range-app-create 31984fea73a15b45779fa0df4ef62f9b --json '{"protocol":"tcp/22", "dns":{"type":"CNAME","name":"ssh.example.com"}, "origin_direct":"tcp://1.2.3.4:22"] ! ! ! , "proxy_protocol":"off", "ip_firewall":true, "tls":"full", "edge_ips":{"type":"dynamic", "connectivity":"all"}, "traffic_type":"direct"}' -i "cis-demo"
<-- </section "id="section-create-range-app-examples" "> --><-- </section "id="section-create-range-app" "> --><-- <section "id="section-update-range-app" "> --> ibmcloud cis range-app-update Update an previously existing application's configuration (Enterprise plan only). ibmcloud cis range-app-update DNS_DOMAIN_ID APP_ID --origin-direct ORIGIN_DIRECT -i, --instance INSTANCE] --output FORMAT]
ibmcloud cis range-app-update DNS_DOMAIN_ID APP_ID --add-origin-direct ORIGIN_DIRECT] --remove-origin-direct ORIGIN_DIRECT] -i, --instance INSTANCE] --output FORMAT]