vania-janet/multiturn-rag-retrieval-data huggingface dataset:
This command deploys a Monitoring agent as a Kubernetes daemon set in your cluster. The agent collects cluster and pod metrics, such as the worker node CPU and memory usage, and the amount of incoming and outgoing network traffic for your pods. For more information, see [Forwarding cluster and app metrics to IBM Cloud Monitoring](https://cloud.ibm.com/docs/containers?topic=containers-health-monitormonitoring).

ibmcloud ob monitoring config create --cluster CLUSTER --instance MONITORING_INSTANCE [--sysdig-access-key ACCESS_KEY] [--private-endpoint]

Minimum required permissions:



* Administrator platform access role and Manager service access role for all Kubernetes namespaces in IBM Cloud Kubernetes Service
* Editor platform access role and Manager server access role for IBM Cloud Monitoring



Command options:

--cluster CLUSTER
: The name or ID of the cluster for which you want to create a monitoring configuration for IBM Cloud Monitoring. To retrieve your cluster name or ID, run ibmcloud ks clusters. This value is required.

--instance MONITORING_INSTANCE
: The ID or name of the IBM Cloud Monitoring service instance that you want to use to create the monitoring configuration. 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.

Example command
If you need a new VLAN, order one by [contacting IBM Cloud support](https://cloud.ibm.com/docs/vlans?topic=vlans-ordering-premium-vlansordering-premium-vlans).

Then, [create a cluster](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_cluster_create) that uses this new VLAN.

If you have another VLAN that is available, you can [set up VLAN spanning](https://cloud.ibm.com/docs/vlans?topic=vlans-vlan-spanningvlan-spanning) in your existing cluster. After, you can add new worker nodes to the cluster that use the other VLAN with available subnets. To check if VLAN spanning is already enabled, use the ibmcloud ks vlan spanning get --region <region>[command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_vlan_spanning_get).

If you are not using all the subnets in the VLAN, you can reuse subnets on the VLAN by adding them to your cluster.



1. Check that the subnet that you want to use is available. The infrastructure account that you use might be shared across multiple IBM Cloud accounts. In this case, even if you run the ibmcloud ks subnets command to see subnets with Bound Clusters, you can see information only for your clusters. Check with the infrastructure account owner to make sure that the subnets are available and not in use by any other account or team.
2. Use the [ibmcloud ks cluster subnet add command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_cluster_subnet_add) to make an existing subnet available to your cluster.
3. Verify that the subnet was successfully created and added to your cluster. The subnet CIDR is listed in the Subnet VLANs section.
If you update your cluster to version 1.16 from an earlier version, you can [configure the CoreDNS autoscaler](https://cloud.ibm.com/docs/containers?topic=containers-cluster_dnsdns_autoscale) to use a minimum of 3 pods.<br><br><br><br> * CoreDNS caching is updated to better support older DNS clients. If you disabled the CoreDNS cache plug-in, you can now re-enable the plug-in.<br> * The CoreDNS deployment is now configured to check readiness by using the ready plug-in.<br> * CoreDNS version 1.6 no longer supports the proxy plug-in, which is replaced by the forward plug-in. In addition, the CoreDNS kubernetes plug-in no longer supports the resyncperiod option and ignores the upstream option.<br><br><br> 
 IBM Cloud File Storage for Classic plug-in and monitor 350 351 Updated to use the distroless/static base image and to use Go version 1.12.10. 
 Kubernetes v1.15.5 v1.16.2 See the [Kubernetes release notes](https://github.com/kubernetes/kubernetes/releases/tag/v1.16.2). 
 Kubernetes configuration N/A N/A [Kubernetes service account token volume projection](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/service-account-token-volume-projection) is enabled and issues tokens that use https://kubernetes.default.svc as the default API audience. 
 Kubernetes admission controllers configuration N/A N/A The RuntimeClass admission controller is disabled to align with the RuntimeClass feature gate, which was disabled in IBM Cloud Kubernetes Service version 1.14.
Kubernetes Ingress Controller version 1.0.0 is supported on IBM Cloud Kubernetes Service cluster versions 1.19 or newer.<br><br><br><br> * Cluster versions 1.19, 1.20, and 1.21: Ingress and IngressClass resources that were created on clusters that run on Kubernetes versions 1.19, 1.20 or 1.21 and Ingress Controller version 1.0.0 are automatically updated during the cluster update to 1.22. The Kubernetes API Server dynamically manages the conversion from the earlier extensions/v1beta1 and networking.k8s.io/v1beta1 Ingresses to the new networking.k8s.io/v1.<br> * External Ingress resources: For Ingress resources that are stored outside of Kubernetes clusters, such as in a version control system or any other external storage, the extensions/v1beta1 and networking.k8s.io/v1beta1 descriptors can't be used with Kubernetes 1.22. Convert these descriptors to networking.k8s.io/v1 Ingresses and IngressClasses.<br> * If you have ALB auto updates enabled, you don't need to manually update your ALBs.<br> * If you have ALB auto updates disabled, you must update your Kubernetes Ingress Controller based ALBs to a supported 0.4.x version before updating to 1.0.0 or newer. To check your auto update settings, run the ibmcloud ks ingress alb autoupdate get command.<br> * ALB OAuth-Proxy add-on: networking.k8s.io/v1beta1 is compatible with ALB OAuth-Proxy add-on version 2.0.0 only. If you use the ALB OAuth-Proxy add-on you must update the add-on to version 2.0.0 before updating your cluster to 1.22.<br><br><br>
Installing the CLI 

You can use the following tools to manage your IBM Cloud Kubernetes Service clusters. While you can install a subset of the tools, all of the following tools are recommended.

Virtual Private Cloud

Classic infrastructure

Satellite



 Understanding the CLI tools 



Table 1: CLI tools

 CLI Description 

 ibmcloud You can use the ibmcloud CLI to login to your account, add users, manage your catalogs and more. 
 ks plug-in After installing the ibmcloud CLI, you can use the ks plug-in to create and manage IBM Cloud Kubernetes Service clusters. 
 kubectl You can use the kubectl CLI to manage resources within your clusters like pods, deployments, and more. 







 Step 1: Run the installation command 

The latest version of the IBM Cloud CLI is installed when you run the command. As the CLI installs, keep an eye on the command line to authenticate as needed.



* For MacOS, run the following command:

curl -fsSL https://clis.cloud.ibm.com/install/osx | sh
* For Linux™, run the following command:

curl -fsSL https://clis.cloud.ibm.com/install/linux | sh
* For Windows™, run the following command in PowerShell as an administrator:

iex (New-Object Net.WebClient).DownloadString('https://clis.cloud.ibm.com/install/powershell')

To open PowerShell, right-click the Windows™ PowerShell icon, and select Run as administrator.
* For WSL2 on Windows™, run the following command:

curl -fsSL https://clis.cloud.ibm.com/install/linux | sh



For more information about installing the Mac OS X M1/ARM or Linux 64-bit ARM versions of the CLI, see the IBM Cloud CLI [release notes](https://github.com/IBM-Cloud/ibm-cloud-cli-release/releases/). These versions are provided as-is and are not fully supported.





 Step 2: Verify the installation
* With the release of the [IBM Cloud Kubernetes Service version 2 API](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_api_installapi_about), the IBM Cloud CLI kubernetes-service plug-in supports both classic and VPC infrastructure providers. Some ibmcloud oc commands support only one type of infrastructure, whereas other commands include additional names or options.
* Adds the --pod-subnet and --service-subnet options to the ibmcloud oc cluster create classic commands for standard clusters that run Kubernetes 1.15 or later. If you plan to connect your cluster to on-premises networks, you can avoid subnet conflicts by specifying a custom subnet CIDR that provides the private IP addresses for your pods and subnets.
* Enhances the ibmcloud oc nlb-dns create and ibmcloud oc nlb-dns add commands so that you can add more than one IP address at a time. For example, to create a DNS entry for multiple network load balancer IP addresses, use multiple options such as ibmcloud oc nlb-dns create --cluster mycluster --ip IP1 --ip IP2.







 Version 0.3.103 

Version 0.3.103 of the CLI was released on 12 August 2019.



* General refactoring and improvements.







 Version 0.3.99 

Version 0.3.99 of the CLI was released on 5 August 2019.



* Improves error handling for ibmcloud oc cluster config.
* Updates the help text in various languages.







 Version 0.3.95 

Version 0.3.95 of the CLI was released on 30 July 2019.



* Adds the ibmcloud oc alias to the Kubernetes Service plug-in for management of Red Hat OpenShift on IBM Cloud clusters.
* 198.18.0.0 - 198.19.255.255



: Note that the pod and service subnets can't overlap. If you use custom-range subnets for your worker nodes, you must [ensure that your worker node subnets don't overlap with your cluster's pod subnet](https://cloud.ibm.com/docs/containers?topic=containers-vpc-subnetsvpc-ip-range).

--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.

--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. Note that if you don't have the correct infrastructure permissions, the cluster creation might only partially succeed, such as the master provisioning but the worker nodes unable to provision. You might skip the permissions check if you want to continue an otherwise blocked operation, such as when you use multiple infrastructure accounts and can handle the infrastructure resources separately from the master, if needed later.

--kms-account-id ID
Copy and paste the command that is displayed in your terminal to set the KUBECONFIG environment variable.

Every time you log in to the IBM Cloud® Kubernetes Service CLI to work with clusters, you must run these commands to set the path to the cluster's configuration file as a session variable. The Kubernetes CLI uses this variable to find a local configuration file and certificates that are necessary to connect with the cluster in IBM Cloud.
3. Obtain the access key. For more information, see [Getting the access key through the IBM Cloud UI](https://cloud.ibm.com/docs/monitoring?topic=monitoring-access_keyaccess_key_ibm_cloud_ui).
4. Obtain the ingestion URL from the [collector endpoints](https://cloud.ibm.com/docs/monitoring?topic=monitoring-endpointsendpoints_ingestion).
5. Deploy the monitoring agent. Run the following command:

curl -sL https://raw.githubusercontent.com/draios/sysdig-cloud-scripts/master/agent_deploy/IBMCloud-Kubernetes-Service/install-agent-k8s.sh | bash -s -- -a ACCESS_KEY -c COLLECTOR_ENDPOINT -t TAG_DATA -ac 'sysdig_capture_enabled: false'

Where



* ACCESS_KEY is the ingestion key for the instance that you previously retrieved.
* COLLECTOR_ENDPOINT is the ingestion URL for the region where the monitoring instance is available that you previously retrieved.
* TAG_DATA are comma-separated tags that are formatted as TAG_NAME:TAG_VALUE. You can associate one or more tags to your monitoring agent. For example: role:serviceX,location:us-south. Later on, you can use these tags to identify metrics from the environment where the agent is running.
* Set sysdig_capture_enabled to false to disable the capture feature. By default is set to true.
If you want to use an IBM Cloud Object Storage service instance as your default backing store, make sure that you [created the service instance](https://cloud.ibm.com/docs/openshift?topic=openshift-deploy-odf-classicodf-create-cos-classic), and created the Kubernetes secret in your cluster. When you create the ODF CRD in your cluster, ODF looks for a secret named ibm-cloud-cos-creds to set up the default backing store by using your Object Storage HMAC credentials.



1. Create a custom resource called OcsCluster. Save and edit the following custom resource definition to include the device paths for the local disks [that you retrieved earlier](https://cloud.ibm.com/docs/openshift?topic=openshift-deploy-odf-classicodf-classic-get-devices). If you don't specify the optional workerNodes parameter, then all worker nodes in your cluster are used for the ODF deployment. Be sure to include the /dev/disk/by-id/ path when you specify your storage devices.



* If your worker node has raw disks with partitions, you need one partition for the OSD and one partition for the MON per worker node. As a best practice, and to maximize storage capacity on partitioned disks, you can specify the smaller partition or disk for the MON, and the larger partition or disk for the OSD. Note that the initial storage capacity of your ODF configuration is equal to the size of the disk that you specify as the osd-device-path when you create your configuration.
* If you devices aren't partitioned, you must specify one raw disk for the MON and one for the OSD for each worker node that you want to use.



Example custom resource for installing ODF on all worker nodes in a version 4.8 cluster by using automatic disk discovery.

apiVersion: ocs.ibm.io/v1
kind: OcsCluster
metadata:
name: ocscluster-classic
spec:
osdStorageClassName: localblock
osdSize: "1"
autoDiscoverDevices: true
IBM Cloud Controller Manager v1.18.9-1 v1.19.2-9 Updated to support the Kubernetes 1.19.2 release and to use Go version 1.15 and calicoctl version 3.16.2. Classic network load balancers (NLBs) now set NET_RAW security context. In addition, support was added for VPC network load balancers. 
 IBM Cloud RBAC Operator 4b47693 31c794a Updated to use Go version 1.15.2. 
 Key Management Service provider v2.0.4 v2.1.0 Updated to use the key management service (KMS) provider secret to identify when a [Key Protect](https://cloud.ibm.com/docs/containers?topic=containers-encryptionkeyprotect) key is enabled and disabled so that encryption and decryption requests are updated accordingly. 
 Kubernetes v1.18.9 v1.19.2 See the [Kubernetes release notes](https://github.com/kubernetes/kubernetes/releases/tag/v1.19.2). 
 Kubernetes configuration N/A N/A Disabled the Kubernetes SCTPSupport and ServiceAppProtocol feature gates. 
 Kubernetes DNS autoscaler 1.7.1 1.8.3 See the [Kubernetes DNS autoscaler release notes](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler/releases/tag/1.8.3). In addition, the Kubernetes DNS autoscaler configuration was updated to include worker nodes that can't be scheduled in scaling calculations. 
 Kubernetes NodeLocal DNS cache 1.15.13 1.15.14 See the [Kubernetes NodeLocal DNS cache release notes](https://github.com/kubernetes/dns/releases/tag/1.15.14). 
 Load balancer and load balancer monitor for IBM Cloud Provider 223 234 Updated to use Go version 1.15.2.
ibmcloud ks cluster subnet detach --cluster my_cluster --subnet-id 1602829







 Deprecated: ibmcloud ks cluster user-subnet add 

Classic infrastructure

Bring your own private subnet to your IBM Cloud Kubernetes Service clusters. This private subnet is not one provided by IBM Cloud infrastructure. As such, you must configure any inbound and outbound network traffic routing for the subnet.

This command is deprecated. Add an existing IBM Cloud infrastructure subnet to your cluster by running [ibmcloud ks cluster subnet add](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_cluster_subnet_add).

When you make a subnet available to a cluster, IP addresses of this subnet are used for cluster networking purposes. To avoid IP address conflicts, make sure that you use a subnet with one cluster only. Do not use a subnet for multiple clusters or for other purposes outside of IBM Cloud Kubernetes Service at the same time. If you use the same subnet across multiple clusters, your default Ingress TLS certificate might become invalidated. In classic clusters, if you have multiple VLANs for your cluster, multiple subnets on the same VLAN, or a multizone classic cluster, you must enable a [Virtual Router Function (VRF)](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointvrf) for your IBM Cloud infrastructure account so your worker nodes can communicate with each other on the private network. To enable VRF, see [Enabling VRF](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointvrf). To check whether a VRF is already enabled, use the ibmcloud account show command. If you can't or don't want to enable VRF, enable [VLAN spanning](https://cloud.ibm.com/docs/vlans?topic=vlans-vlan-spanningvlan-spanning).
ibmcloud oc cluster subnet detach --cluster my_cluster --subnet-id 1602829







 Deprecated: ibmcloud oc cluster user-subnet add 

Classic infrastructure

Bring your own private subnet to your IBM Cloud Kubernetes Service clusters. This private subnet is not one provided by IBM Cloud infrastructure. As such, you must configure any inbound and outbound network traffic routing for the subnet.

This command is deprecated. Add an existing IBM Cloud infrastructure subnet to your cluster by running [ibmcloud oc cluster subnet add](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_cluster_subnet_add).

When you make a subnet available to a cluster, IP addresses of this subnet are used for cluster networking purposes. To avoid IP address conflicts, make sure that you use a subnet with one cluster only. Do not use a subnet for multiple clusters or for other purposes outside of IBM Cloud Kubernetes Service at the same time. If you use the same subnet across multiple clusters, your default Ingress TLS certificate might become invalidated. In classic clusters, if you have multiple VLANs for your cluster, multiple subnets on the same VLAN, or a multizone classic cluster, you must enable a [Virtual Router Function (VRF)](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointvrf) for your IBM Cloud infrastructure account so your worker nodes can communicate with each other on the private network. To enable VRF, see [Enabling VRF](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointvrf). To check whether a VRF is already enabled, use the ibmcloud account show command. If you can't or don't want to enable VRF, enable [VLAN spanning](https://cloud.ibm.com/docs/vlans?topic=vlans-vlan-spanningvlan-spanning).
Assign the license](https://cloud.ibm.com/docs/cloud-pak-data?topic=cloud-pak-data-getting-startedassign_license).

You can deploy Cloud Pak for Data on Virtual Private Cloud (VPC) Gen2 infrastructure. You can use either a single or multi zone deployment. For more information, see [Creating a VPC cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-getting-started&interface=uivpc-gen2-gs).

You must ensure that you have sufficient resources for the services that you plan to install. For more information, see the [prerequisites](https://cloud.ibm.com/catalog/content/ibm-cp-datacore-6825cc5d-dbf8-4ba2-ad98-690e6f221701-globalabout) for IBM Cloud Pak for Data.



 Roles 

To install IBM Cloud Pak® for Data on IBM Cloud, a user must have the following IBM Cloud Identity and Access Management (IAM) roles:



 Role Location Action 

 Platform Editor Manage > Account > Licenses and entitlements Assign a license. 
 Service Manager Manage > Access (IAM) > Roles > Kubernetes Service Run the preinstallation script. 
 Service Writer Manage > Access (IAM) > Roles > Kubernetes Service Run the installation script. 
 Service Manager in any resource group Schematics > Workspaces Create a workspace. 
 Classic Infrastructure > Services > Storage Manage , Classic Infrastructure > Account > Add/Upgrade Storage Manage > Access (IAM) > Users Modify the image registry volume. 



For more information, see [Setting up access to your cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-users).





 Storage 

You must ensure that your cluster has sufficient resources and is configured to use supported storage. You can choose one of the following storage options:



* Single zone VPC Gen2 cluster with storage OpenShift® Data Foundation
* Multi zone VPC Gen2 cluster with storage OpenShift® Data Foundation
Note that the service_name for IBM Cloud Kubernetes Service is containers-kubernetes. To find a list of service names, run the ibmcloud cbr service-ref-targets command. To find a list of API types for a service, run the ibmcloud cbr api-types --service-name SERVICE command.



Example command to create a rule that uses the addresses key and the cluster API type and the ipAddress type.

ibmcloud cbr rule-create my-rule-1 --service-name containers-kubernetes --api-type crn:v1:bluemix:public:containers-kubernetes::::api-type:cluster --zone-id ZONE-ID

The following command creates a rule that protects the CLUSTER-ID cluster. Only resources in the NETWORK-ZONE-ID network zone can access the cluster. This rule includes both the cluster and management API types.

ibmcloud cbr rule-create my-rule-2 --service-name containers-kubernetes --service-instance CLUSTER-ID --zone-id NETWORK-ZONE-ID

The following example command creates a rule that allows all private network connections, but allows only resources in the allow-client-ip network zone to connect to the cluster over the public network. For more information about this scenario, see [Setting up context-based restrictions](https://cloud.ibm.com/docs/containers?topic=containers-cbr-tutorial).

ibmcloud cbr rule-create --api-types crn:v1:bluemix:public:containers-kubernetes::::api-type:cluster --description "privateAccess=allowAll, publicAccess=oneIP" --service-name containers-kubernetes --service-instance CLUSTER-ID --context-attributes endpointType=private --context-attributes endpointType=public,networkZoneId=allow-client-ip





 Creating rules from the console 



1.