vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Removing clusters 

Virtual Private Cloud

Classic infrastructure

Clusters that are created with a billable account must be removed manually when they are not needed anymore so that those clusters are no longer consuming resources.

When you delete the cluster, all worker nodes, apps, and containers are permanently deleted. This action can't be undone. Before you proceed, make sure to back up all required data and configuration files.

No backups are created of your cluster or your data in your persistent storage. When you delete a cluster, you can choose to delete your persistent storage. Persistent storage that you provisioned by using a delete storage class is permanently deleted in IBM Cloud infrastructure if you choose to delete your persistent storage. If you provisioned your persistent storage by using a retain storage class and you choose to delete your storage, the cluster, the PV, and PVC are deleted, but the persistent storage instance in your IBM Cloud infrastructure account remains.

Classic clusters only: When you remove a cluster, you also remove any subnets that were automatically provisioned when you created the cluster and that you created by using the ibmcloud ks cluster subnet create command. However, if you manually added existing subnets to your cluster by using the ibmcloud ks cluster subnet add command, these subnets are not removed from your IBM Cloud infrastructure account and you can reuse them in other clusters.

Before you begin:



* Note your cluster ID. You might need the cluster ID to investigate and remove related IBM Cloud infrastructure resources that are not automatically deleted with your cluster.
* Make sure that you have the [Administrator IBM Cloud IAM platform access role](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms).
* If you want to delete the data in your persistent storage, review the delete options for the type of storage that you use.



* [File storage](https://cloud.ibm.com/docs/containers?topic=containers-file_storagestorage_delete_options_file)
* [Block storage](https://cloud.ibm.com/docs/containers?topic=containers-block_storagecleanup_block) for classic clusters
To prevent any interruption of service, [redeploy all your cluster workloads](https://cloud.ibm.com/docs/openshift?topic=openshift-update_appcopy_apps_cluster) to a [supported data center](https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zoneszones-mz) and remove your osl01 or hou02 clusters by 1 August 2021. Before the unsupported date, you are blocked from adding new worker nodes and clusters starting on 1 July 2021. For more information, see [Data center closures in 2021](https://cloud.ibm.com/docs/get-support?topic=get-support-dc-closure).





 2 April 2021 

Master versions
: Master fix pack update change log documentation is available for Red Hat OpenShift version [4.6.22_1538_openshift](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_464622_1538).





 1 April 2021 

Cluster autoscaler add-on
: [Patch update 1.0.2_249](https://cloud.ibm.com/docs/openshift?topic=openshift-ca_changelog) of the cluster autoscaler add-on is available.

Block Storage for VPC add-on
: [Patch update 3.0.0_521](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc_bs_changelog) of the Block Storage for VPC add-on is available.

Block Storage for VPC driver
: Added steps to install the vpc-block-csi-driver on unmanaged clusters. For more information, see [Setting up Block Storage for VPC for unmanaged clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-block-storage-driver-unmanaged).

New! image security add-on
After you [access your cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clusteraccess_cluster_sat) and run oc get nodes or oc describe node <worker_node>, you might see that the worker nodes have master,worker roles. In OpenShift Container Platform clusters, operators use the master role as a nodeSelector so that OCP can deploy default components that are controlled by operators, such as the internal registry, in your cluster. The Satellite hosts that you assigned to your cluster function as worker nodes only, and no master node processes, such as the API server or Kubernetes scheduler, run on your worker nodes.





 Creating single-node clusters for resource-constrained edge locations 

If you are running your Red Hat OpenShift on IBM Cloud cluster on Satellite infrastructure in a remote, resource-constrained edge location with limited resources, such as a small data center in a mobile tower, running a data plane with a smaller foot print might be beneficial for your setup. While typical Red Hat OpenShift on IBM Cloud clusters require at least three worker nodes for high availability, you have the option to create a cluster that runs a single worker node. Single-node clusters have several limitations and should only be used in specific circumstances.

Single-node clusters are recommended only in specific circumstances, and should only be used in resource-constrained edge locations that have multiple redundant locations running the same workload. See the [Limitations](https://cloud.ibm.com/docs/openshift?topic=openshift-satellite-clusterssingle-node-limitations) section for more information.

Single-node clusters lack high availability. By provisioning a single-node cluster, you accept that you are more likely to experience downtime and disruptions in your workload.



 Limitations 

Any cluster with fewer than three worker nodes lacks high availability. By provisioning a single-node cluster, you accept that you are more likely to experience downtime and disruptions in your workload, and that regular worker node upgrades result in your workload going offline. Additionally, if a cluster is provisioned as a single-node cluster, it can not later be converted to a standard, highly available cluster.
Review the prerequisites for the [Metro DR](https://docs.portworx.com/portworx-install-with-kubernetes/disaster-recovery/px-metro/1-install-px/prerequisites) and [Asynchronous DR](https://docs.portworx.com/portworx-install-with-kubernetes/disaster-recovery/async-dr/pre-requisites) configuration.
3. Configure disaster recovery for your cluster. Metro DR:



1. Choose at least two Red Hat OpenShift clusters that are located in the same metro location. If you have one cluster only, you can still configure this cluster for metro disaster recovery, but Portworx can't do a proper failover until a second cluster is configured.
2. Make sure that all your clusters have sufficient [raw and unformatted block storage](https://cloud.ibm.com/docs/openshift?topic=openshift-utilitiesmanual_block) so that you can build your Portworx storage layer.
3. Set up a [Databases for etcd service instance](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_kv_store) for your Portworx key-value store. Because both Red Hat OpenShift clusters must share the key-value store, you can't use the internal Portworx KVDB.
4. Optional: Decide if you want to set up [encryption for your Portworx volumes](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_encryption).
5. Follow the instructions to [install Portworx](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_deploy) with the disaster recovery plan in both of your clusters.
[Single-site deployment topology](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/arch-pattern-s-s-1.svg)

Figure 1. Single-site deployment topology



1. The vCenter Server automation deploys an initial vSphere cluster, which includes a vCenter, three NSX-T managers, and an Active Directory deployment. They run either on a single IBM Cloud Classic Virtual Server Instance or two VMware VMs in a high availability deployment. The initial vSphere cluster is deployed on the initial IBM Cloud data center location. This vSphere cluster also hosts NSX-T edge transport node VMs for services and workload NSX-T edge clusters. The workload NSX-T edge cluster is purpose for your workloads, while the services NSX-T edge cluster is used by optional add-on services. You can expand the capacity of this vSphere cluster by ordering new hosts through IBM Cloud for VMware Solutions portal.
2. If you select an optional gateway cluster, the vCenter Server automates two ESXi hosts by using IBM Cloud bare metal server and forms a new vSphere cluster in your deployment. These ESXi hosts can be used to host, for example, Juniper vSRX virtual router and firewall appliances. This cluster hosts also behave such as [IBM Cloud gateway appliance](https://cloud.ibm.com/docs/gateway-appliance?topic=gateway-appliance-about), which allows you to assign and route VLANs through the router or firewall that is hosted on the cluster.
3. You can add new vSphere clusters to increase the compute capacity for your workloads. You can add vSphere clusters with different host specifications, and define how to functionally position these clusters and what workloads are run on each cluster.
4. You can add NFS based IBM Cloud File Storage for Classic to your clusters.
For more information, see [Using the Portworx KVDB](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_kv_store).







 November 2019 



 26 November 2019 

CLI change log
: Updated the IBM Cloud Kubernetes Service CLI plug-in change log page for the [release of version 0.4.61](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_cli_changelog).

Diagnostics and Debug Tool add-on for Red Hat OpenShift clusters
: The [Diagnostics and Debug Tool](https://cloud.ibm.com/docs/openshift?topic=openshift-debug-tool) add-on is now available for Red Hat OpenShift clusters.

Cluster autoscaling for VPC clusters
: You can [set up the cluster autoscaler](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-helm) on clusters that run on the first generation of compute for Virtual Private Cloud (VPC).

New! Reservations and limits for PIDs
: Worker nodes that run Kubernetes version 1.14 or later set [process ID (PID) reservations and limits that vary by flavor](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodesresource_limit_node), to help prevent malicious or runaway apps from consuming all available PIDs.

Version change log
: Worker node patch updates are available.
: Red Hat OpenShift [3.11.154_1533_openshift](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_311311154_1533_worker).





 22 November 2019 

Bring your own DNS for load balancers
[Portable public IP addresses](https://cloud.ibm.com/docs/containers?topic=containers-subnetsreview_ip) Yes 
 [Logging and monitoring](https://cloud.ibm.com/docs/containers?topic=containers-healthlogging) Yes 
 [Option to provision your worker nodes on physical (bare metal) servers](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodesplanning_worker_nodes) Yes 







 Comparison between Red Hat OpenShift and community Kubernetes clusters 

Both Red Hat OpenShift on IBM Cloud and IBM Cloud Kubernetes Service clusters are production-ready container platforms that are tailored for enterprise workloads. The following table compares and contrasts some common characteristics that can help you choose which container platform is best for your use case.



Characteristics of community Kubernetes and Red Hat OpenShift clusters

 Characteristics Community Kubernetes clusters Red Hat OpenShift clusters 

 Complete cluster management experience through the IBM Cloud Kubernetes Service automation tools (API, CLI, console) Yes Yes 
 Worldwide availability in single and multizones Yes Yes 
 Consistent container orchestration across hybrid cloud providers Yes Yes 
 Access to IBM Cloud services such as AI Yes Yes 
 Software-defined storage Portworx solution available for multizone data use cases Yes Yes 
 Create a cluster in an IBM Virtual Private Cloud (VPC) Yes Yes 
 Latest community Kubernetes distribution Yes 
 Scope IBM Cloud IAM access policies to access groups for service access roles that sync to cluster RBAC Yes 
 Classic infrastructure cluster on only the private network Yes 
 GPU bare metal worker nodes Yes Yes 
 Integrated IBM Cloud Paks and middleware Yes 
 Built-in container image streams, builds, and tooling ([read more](https://blog.cloudowski.com/articles/why-managing-container-images-on-openshift-is-better-than-on-kubernetes/)) Yes 
 Integrated CI/CD with Jenkins Yes 
 Stricter app security context set up by default Yes 
 Simplified Kubernetes developer experience, with an app console that is suited for beginners Yes
"vlan_errors": [],
"reserved_ips": []
}
cluster_id:
----
bmnj1b1d09lpvv3oof0g
reserved_private_ip:
----

reserved_private_vlan_id:
----

reserved_public_ip:
----

Events: <none>



* VPC clusters: Verify that the VPC load balancer for your Ingress controllers exists. In the output, look for the VPC load balancer Name that starts with kube-<cluster_ID>. If you did not install the infrastructure-service plug-in, install it by running ibmcloud plugin install infrastructure-service.



ibmcloud is load-balancers

Even though the VPC load balancer is listed, its DNS entry might still be registering. When a VPC load balancer is created, the hostname is registered through a public DNS. Sometimes, it can take several minutes for this DNS entry to be replicated to the specific DNS that your client is using.
4. Verify that the Ingress controller is successfully created.



1. Check whether a Ingress controller deployment exists for your cluster.



* If a Ingress controller deployment is listed, continue to the next step.
* If no Ingress controller deployment is created after several minutes, [review ways to get help](https://cloud.ibm.com/docs/openshift?topic=openshift-get-help).



oc get deployment -n openshift-ingress

Example output

NAME READY UP-TO-DATE AVAILABLE AGE
router-default 2/2 2 2 26m
2. Check whether the Ingress controller's load balancer service exists and is assigned a public external IP address (classic clusters) or a hostname (VPC clusters).



* If a service that is named router-default is listed and is assigned an IP address (classic clusters) or a hostname (VPC clusters), continue to the next step.
To protect against this failure, you must [set up a multizone cluster to spread worker nodes across three zones, or create multiple single zone clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-ha_clustersha_clusters) in different zones.

Potential failure point 3: Cluster availability
: The Red Hat OpenShift master is the main component that keeps your cluster up and running. The master stores cluster resources and their configurations in the etcd database that serves as the single point of truth for your cluster. The Red Hat OpenShift API server is the main entry point for all cluster management requests from the worker nodes to the master, or when you want to interact with your cluster resources. To protect your cluster master from a zone failure, review the following docs. Create a cluster in a multizone location, which spreads the master across zones. Or, consider setting up a second cluster in another zone. For more information, see [Setting up highly available clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-ha_clustersha_clusters).

Potential failure point 4: Zone availability
: A zone failure affects all physical compute hosts and NFS storage. Failures include power, cooling, networking, or storage outages, and natural disasters, like flooding, earthquakes, and hurricanes. To protect against a zone failure, you must have clusters in two different zones that are load balanced by an external load balancer. For more information, see [Setting up highly available clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-ha_clustersha_clusters).

Potential failure point 5: Region availability
: Every region is set up with a highly available load balancer that is accessible from the region-specific API endpoint. The load balancer routes incoming and outgoing requests to clusters in the regional zones. The likelihood of a full regional failure is low. However, to account for this failure, you can set up multiple clusters in different regions and connect them by using an external load balancer. If an entire region fails, the cluster in the other region can take over the workload.
(https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-classic-vpcscalable-practices-zero)
* [Can I optimize my deployments for autoscaling?](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-classic-vpcscalable-practices-apps)
* [Can I use taints and tolerations with autoscaled worker pools?](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-classic-vpcscalable-practices-taints)



* [Rebalancing or resizing autoscaled worker pools](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-classic-vpcca_update_worker_node_pool)
* [Preparing classic or VPC Gen 2 clusters for autoscaling](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-classic-vpcprepare-autoscale-classic-vpc)



[Preparing Satellite clusters for autoscaling](https://cloud.ibm.com/docs/openshift?topic=openshift-prepare-autoscale-satprepare-autoscale-sat)



* [Understanding autoscaling in Satellite clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-prepare-autoscale-satcluster-scaling-sat)
* [Setting up your location and cluster for autoscaling](https://cloud.ibm.com/docs/openshift?topic=openshift-prepare-autoscale-satsetup-location-cluster-scale-sat)



[Enabling the cluster autoscaler add-on in your cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-install-addoncluster-scaling-install-addon)
[Host commands](https://cloud.ibm.com/docs/satellite?topic=satellite-satellite-cli-referencesat-host-commands) View and modify Satellite host settings. 
 [Location commands](https://cloud.ibm.com/docs/satellite?topic=satellite-satellite-cli-referencesat-location-commands) Create, view, and modify Satellite locations. 
 [Connector commands](https://cloud.ibm.com/docs/satellite?topic=satellite-satellite-cli-referencesat-connector-commands) Create, view, and modify Satellite connectors. 
 [Resource commands](https://cloud.ibm.com/docs/satellite?topic=satellite-satellite-cli-referencesat-resource-commands) Search and view Kubernetes resources that are managed by Satellite. 
 [Service commands](https://cloud.ibm.com/docs/satellite?topic=satellite-satellite-cli-referencesat-service-commands) View Satellite service clusters. 
 [Storage commands](https://cloud.ibm.com/docs/satellite?topic=satellite-satellite-cli-referencesat-storage-commands) View and manage Satellite storage resources. 
 [Subscription commands](https://cloud.ibm.com/docs/satellite?topic=satellite-satellite-cli-referencesat-config-subscription-commands) View and manage Satellite subscriptions to deploy Kubernetes configuration files to your clusters. 







 Cluster commands 

Use these commands to register clusters for use with [Satellite configurations](https://cloud.ibm.com/docs/satellite?topic=satellite-setup-clusters-satconfig). You can use configurations to consistently deploy and update apps across clusters.



 ibmcloud sat cluster get 

Get the details of a cluster that is registered with the Satellite Config component.

ibmcloud sat cluster get --cluster CLUSTER [-q] [--output JSON]



 Minimum required permissions 

IBM Cloud IAM Viewer platform role for the Cluster resource in Satellite.
[Endpoint commands](https://cloud.ibm.com/docs/cli?topic=cli-satellite-cli-referencesat-endpoint-commands) Create, view, and manage Satellite endpoints. 
 [Host commands](https://cloud.ibm.com/docs/cli?topic=cli-satellite-cli-referencesat-host-commands) View and modify Satellite host settings. 
 [Location commands](https://cloud.ibm.com/docs/cli?topic=cli-satellite-cli-referencesat-location-commands) Create, view, and modify Satellite locations. 
 [Resource commands](https://cloud.ibm.com/docs/cli?topic=cli-satellite-cli-referencesat-resource-commands) Search and view Kubernetes resources that are managed by Satellite. 
 [Service commands](https://cloud.ibm.com/docs/cli?topic=cli-satellite-cli-referencesat-service-commands) View Satellite service clusters. 
 [Storage commands](https://cloud.ibm.com/docs/cli?topic=cli-satellite-cli-referencesat-storage-commands) View and manage Satellite storage resources. 
 [Subscription commands](https://cloud.ibm.com/docs/cli?topic=cli-satellite-cli-referencesat-config-subscription-commands) View and manage Satellite subscriptions to deploy Kubernetes configuration files to your clusters. 







 Cluster commands 

Use these commands to register clusters for use with [Satellite configurations](https://cloud.ibm.com/docs/satellite?topic=satellite-setup-clusters-satconfig). You can use configurations to consistently deploy and update apps across clusters.



 ibmcloud sat cluster get 

Get the details of a cluster that is registered with the Satellite Config component.

ibmcloud sat cluster get --cluster CLUSTER [-q] [--output JSON]



 Minimum required permissions 

IBM Cloud IAM Viewer platform role for the Cluster resource in Satellite.
* [ibmcloud ob monitoring config enable public-endpoint|private-endpoint](https://cloud.ibm.com/docs/openshift?topic=openshift-observability_climonitoring_config_enable)
* [ibmcloud ob monitoring config replace](https://cloud.ibm.com/docs/openshift?topic=openshift-observability_climonitoring_config_replace)
* [ibmcloud ob monitoring config show](https://cloud.ibm.com/docs/openshift?topic=openshift-observability_climonitoring_config_show)









 Version history 

[Red Hat OpenShift on IBM Cloud version information](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_versionsopenshift_versions)



* [Available Red Hat OpenShift versions](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_versionsopenshift_versions_available)



* [Red Hat OpenShift on IBM Cloud clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_versionsos-openshift)
* [Clusters in Satellite locations with CoreOS enabled](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_versionsos-satellite-with-coreos)
* [Clusters in Satellite locations without CoreOS enabled](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_versionsos-satellite-without-coreos)



* [Checking a cluster's Kubernetes server version](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_versionsopenshift_server_version)