vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Note that you have two types of Kubernetes clusters you can deploy: an IBM Kubernetes Service cluster or an OpenShift cluster. The IBM Blockchain Platform can be linked to either one. Your choice of cluster will be based on your use case.

For more information about the IBM Kubernetes Service, see [Getting started with IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-getting-started).

For more information about OpenShift, see [About the OpenShift Kubernetes Engine](https://docs.openshift.com/container-platform/4.3/welcome/oke_about.html).

As both IBM Kubernetes Service clusters and OpenShift clusters are based on Kubernetes, you will find that many of the underlying decisions about hardware and storage types will be the same regardless of which cluster provider you choose. Note that the Kubernetes version of the cluster you deploy must be v1.24 - v1.26 to be compatible with the IBM Blockchain Platform.

Note that if you want high availability or disaster recovery, you will need to make a decision about the storage class you are using. The default storage class on the cluster will be used by the dynamic provisioning. So, customers can set any storage class as the default. For more information, see [Deciding on the file storage configuration](https://cloud.ibm.com/docs/containers?topic=containers-file_storagefile_predefined_storageclass).



 Free IBM Kubernetes Service clusters 

The IBM Kubernetes service offers a free cluster that can be used for 30 days. Note that the free cluster offers limited storage and transaction throughput, and that it is not possible to migrate data from free clusters to paid clusters. For more information about the differences between the free and paid Kubernetes clusters on IBM Cloud, see [Comparison of free and standard clusters](https://cloud.ibm.com/docs/containers?topic=containers-cs_ovcluster_types).
5.4.2 IBM Cloud Kubernetes Service can optionally [enable a Kubernetes Key Management Service (KMS) provider](https://cloud.ibm.com/docs/containers?topic=containers-encryptionkms). 
 5.5.1 IBM Cloud Kubernetes Service can optionally [enable image security enforcement](https://cloud.ibm.com/docs/containers?topic=containers-imagesportieris-image-sec). 
 5.6.2 IBM Cloud Kubernetes Service does not annotate all pods with [seccomp profiles](https://kubernetes.io/docs/concepts/security/pod-security-policy/). 
 5.6.3 IBM Cloud Kubernetes Service deploys some system components that do not set a [pod or container securityContext](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/). 
 5.6.4 IBM Cloud Kubernetes Service deploys some Kubernetes resources to the default names.
* Other commands don't return resources in all locations. To run credential set/unset/get, api-key reset, and vlan spanning get commands, you must specify a region in the --region.



* Working with resources:



* When you use the global endpoint, you can work with resources that you have access permissions to in any location, even if you target one region and the resource that you want to work with is in another region.
* If you have clusters with the same name in different regions, use the cluster ID when you run commands or set a region with the ibmcloud ks init command and use the cluster name when you run commands.



* Legacy functionality:



* If you need to list and work with resources from one region only, you can use the ibmcloud ks init[command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_init) to target a regional endpoint instead of the global endpoint. Example to target the US South regional endpoint:

ibmcloud ks init --host https://us-south.containers.cloud.ibm.com
* To use the global functionality, you can use the ibmcloud ks init command again to target the global endpoint. Example to target the global endpoint again:

ibmcloud ks init --host https://containers.cloud.ibm.com





IBM Cloud Kubernetes Service API:



* [Get started with the API](https://cloud.ibm.com/docs/containers?topic=containers-cs_api_installcs_api).
* [View documentation on the API commands](https://containers.cloud.ibm.com/global/swagger-global-api//).
* Generate a client of the API to use in automation by using the [swagger.json API](https://containers.cloud.ibm.com/global/swagger-global-api/swagger.json).



To interact with the global IBM Cloud Kubernetes Service API, enter the command type and append global/v1/command to the endpoint.
Deploy Kubernetes resources to multiple clusters by using IBM Cloud Satellite Config 

In this tutorial, you learn how to create an open toolchain by using IBM Cloud® Continuous Delivery and deploy your application (app) by using [IBM Cloud Satellite](https://cloud.ibm.com/docs/satellite?topic=satellite-getting-started). You also learn how toolchains are implemented in the Continuous Delivery service and how to deploy a simple web app by using a Continuous Delivery-only toolchain template.

IBM Cloud Satellite brings public cloud services to any environment, allowing customers with stringent regulatory requirements to use the flexibility and agility of these services for their secure on-premises data center. Continuous Delivery uses [Satellite Config](https://cloud.ibm.com/docs/satellite?topic=satellite-cluster-config) to deploy an app across a group of clusters in IBM Cloud Satellite. With Satellite Config, you create a configuration to specify which Kubernetes resources you want to deploy to a cluster group of Kubernetes or Red Hat® OpenShift® clusters that are running in your Satellite location or in IBM Cloud.

The toolchain that is used in this tutorial implements standard DevOps practices around continuous delivery capabilities. After you make sure that you meet all of the continuous integration requirements, this toolchain helps you to manage your deployments in IBM Cloud Satellite locations. After you create clusters and associate them with a Satellite cluster group, you can create a toolchain to change your deployment source code and push the change to the GitHub repo. When you push changes to your repo, the Tekton-based delivery pipeline automatically deploys the code.

[Tekton](https://www.ibm.com/cloud/blog/tekton-a-modern-approach-to-continuous-delivery) is an open source, vendor-neutral, Kubernetes-native framework that you can use to build, test, and deploy apps. Tekton provides a set of shared components for implementing [continuous delivery](https://www.ibm.com/garage/method/practices/deliver/practice_continuous_delivery/) systems.
Set Origin Name to us-cluster
4. Set Origin Address to the kubernetes service <IngressSubdomain> printed by ibmcloud ks cluster get --cluster $MYCLUSTER for the US cluster
5. Set Health check to the one created in the previous section
6. Set Health Check Region to Western North America
7. Click Save







 One pool for the cluster in London 



1. Select the Origin pools tab and click Create.
2. Set Name to UK
3. Set Origin Name to uk-cluster
4. Set Origin Address to the kubernetes service <IngressSubdomain> printed by ibmcloud ks cluster get --cluster $MYCLUSTER for the UK cluster
5. Set Health check to the one created in the previous section
6. Set Health Check Region to Western Europe
7. Click Save







 And one pool with both clusters 



1. Select the Origin pools tab and click Create.
2. Set Name to All
3. Add two origins:



1. one with Origin Name set to us-cluster and the Origin Address set to <IngressSubdomain> in Dallas
2. one with Origin Name set to uk-cluster and the Origin Address set to <IngressSubdomain> in London



4. Set Health Check Region to Eastern North America
5. Set Health check to the one created in the previous section
6. Click Save









 Create the Global Load Balancer 

With the origin pools defined, you can complete the configuration of the load balancer.



1. Select the Load balancers tab and click Create.
2. Enter a name, <glb_name>, under Name for the Global Load Balancer. This name will also be part of your universal application URL (http://<glb_name>.<your_domain_name>), regardless of the location.
3. Under Geo routes, click Add route



1. Select Default from the Region drop down
2. Select the pool All
Example 2 

Set the region explicitly.

 set the region endpoint to "us-south"
$ ibmcloud kp region-set us-south

OK

The REGION must be a valid regional endpoint.

 this should fail (not a valid regional endpoint)
$ ibmcloud kp region-set not-a-region

FAILED





 Example 3 

Unset (remove) the regional endpoint.

 remove the regional endpoint
$ ibmcloud kp region-set -u

OK







 Required parameters 



* -i, --instance-id

The IBM Cloud instance ID that identifies your Key Protect instance.

You can set an environment variable instead of specifying -i with the following command: $ export KP_INSTANCE_ID=<INSTANCE_ID>.







 Optional parameters 



* REGION

Specify a regional endpoint. This parameter is optional and if not specified, you are prompted to select a regional endpoint from a list.
* -u, --unset

Unset (remove) the regional endpoiont.









 kp registrations 

Registrations are associations between root keys and other cloud resources, such as Cloud Object Storage (COS) buckets or Cloud Databases deployments.

For example, in Key Protect you create a root key, which is used by COS to protect data at rest.

The relationship between other cloud resources and Key Protect is called a registration.

Do not delete a root key if there are resources, such as COS buckets and objects, that rely on the root key. Deleting the root key means you cannot recover those resources. This is known as "crypto shredding" and there is no recovery from this action.

ibmcloud kp registrations
-i, --instance-id INSTANCE_ID
[-r, --key-ring KEY_RING_ID]
[-c, --crn-query CRN_PATTERN]
[-k, --key-id KEY_ID_OR_ALIAS]
[-o, --output OUTPUT]



 Examples 

These are examples of kp registrations.

Registration examples show numerous Cloud Resource Names (CRNs).
Unsupported: Kubernetes version 1.13
: With the release of version 1.17, clusters that run version 1.13 are unsupported. To continue receiving important security updates and support, you must [update the cluster to a supported version](https://cloud.ibm.com/docs/containers?topic=containers-cs_versionsprep-up) immediately.





 19 February 2020 

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

Developing and deploying apps
: You can now find expanded information on how to develop and deploy an app to your cluster in the following pages.



* [Planning app deployments](https://cloud.ibm.com/docs/containers?topic=containers-plan_deploy)
* [Building containers from images](https://cloud.ibm.com/docs/containers?topic=containers-images)
* [Developing Kubernetes-native apps](https://cloud.ibm.com/docs/containers?topic=containers-app)
* [Deploying Kubernetes-native apps in clusters](https://cloud.ibm.com/docs/containers?topic=containers-deploy_app)
* [Managing the app life cycle](https://cloud.ibm.com/docs/containers?topic=containers-update_app)



Learning paths
: Curated learning paths for [administrators](https://cloud.ibm.com/docs/containers?topic=containers-learning-path-admin) and [developers](https://cloud.ibm.com/docs/containers?topic=containers-learning-path-dev) are now available to help guide you through your IBM Cloud Kubernetes Service experience.

Setting up image build pipelines
: You can now find expanded information on how to set up an image registry and build pipelines in the following pages.
In this tutorial, you interact with the Dallas region. If you're logged in to a different region, be sure to set Dallas as your target region by running the following command.

ibmcloud target -r us-south -g default
2. Create a Kubernetes cluster.

ibmcloud ks cluster create classic --zone dal10 --flavor free --name my-test-cluster
3. Create a Secrets Manager instance.

ibmcloud resource service-instance-create my-secrets-manager secrets-manager trial us-south

Provisioning for both Secrets Manager and your Kubernetes cluster takes 5 - 15 minutes to complete.
4. Before you continue to the next step, verify that your cluster and Secrets Manager instance are provisioned successfully.



1. Verify that the deployment of your worker node is complete.

ibmcloud ks worker ls --cluster my-test-cluster

When your worker node is finished provisioning, the status changes to Ready.

ID Public IP Private IP Flavor State Status Zone Version
kube-c39pf4ld0m87o3fv1utg-mytestclust-default-000000dd 169.xx.xx.xxx 10.xxx.xx.xxx free normal Ready mex01 1.20.7_1543
2. Next, verify that your Secrets Manager instance provisioned successfully.

ibmcloud resource service-instance my-secrets-manager

When the instance is finished provisioning, the state changes to Active.

Name: my-secrets-manager
ID: crn:v1:bluemix:public:secrets-manager:us-south:a/f047b55a3362ac06afad8a3f2f5586ea:fe06948b-0c6b-4183-8d4b-e6c1d38ff65f::
GUID: fe06948b-0c6b-4183-8d4b-e6c1d38ff65f
Location: us-south
Service Name: secrets-manager
Service Plan Name: trial
Resource Group Name: default
Instead, use a Kubernetes service, which represents a group of pods and provides a stable entry point through the service's virtual IP address, called its cluster IP. For more information, see the Kubernetes documentation on [Services](https://kubernetes.io/docs/concepts/services-networking/service/discovering-services).



 How can I make sure that my services are connected to the correct deployments and ready to go? 

For most services, add a selector to your service .yaml file so that it applies to pods that run your apps by that label. Many times when your app first starts up, you don't want it to process requests immediately. Add a readiness probe to your deployment so that traffic is only sent to a pod that is considered ready. For an example of a deployment with a service that uses labels and sets a readiness probe, check out this [NGINX YAML](https://raw.githubusercontent.com/IBM-Cloud/kube-samples/master/deploy-apps-clusters/nginx_preferredAntiAffinity.yaml).

Sometimes, you don't want the service to use a label. For example, you might have an external database or want to point the service to another service in a different namespace within the cluster. When this happens, you have to manually add an endpoints object and link it to the service.





 How can I expose my services on the Internet? 

You can create three types of services for external networking: NodePort, LoadBalancer, and Ingress.

You have different options that depend on your cluster type. For more information, see [Planning networking services](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planningexternal).



* Standard cluster: You can expose your app by using a [NodePort, load balancer, or Ingress service](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planningexternal).
Kubernetes cluster instance Resource Editor Us-south This policy is required to configure the secret and the monitoring agent in the Kubernetes cluster. 



For more information about the IBM Cloud® Kubernetes Service IAM roles, see [User access permissions](https://cloud.ibm.com/docs/containers?topic=containers-access_referenceaccess_reference).





 Step 1: Provision an IBM Cloud Monitoring instance 

In this getting tutorial, instructions are provided to provision an instance of the IBM Cloud Monitoring in the US-South region. For more information about supported regions, see [Regions](https://cloud.ibm.com/docs/monitoring?topic=monitoring-endpoints).

To provision an instance of IBM Cloud Monitoring through the IBM Cloud UI, complete the following steps:



1. [Log in to your IBM Cloud account](https://cloud.ibm.com/login).

After you log in with your user ID and password, the IBM Cloud UI opens.
2. Click Catalog. The list of the services that are available in IBM Cloud opens.
3. To filter the list of services that is displayed, select the Logging and monitoring category.
4. Click the IBM Cloud Monitoring tile.
5. Select a location and a service plan.

By default, the Lite plan is set.

For more information about other service plans, see [Pricing plans](https://cloud.ibm.com/docs/monitoring?topic=monitoring-pricing_planspricing_plans).
6. Configure the resource.

Enter a name for the service instance.

Select a resource group.

Optionally add tags.
7. Click Create.

After you provision an instance, the Observability dashboard opens and shows details for your Monitoring instances.



To provision an instance through the CLI, see [Provisioning an instance through the IBM Cloud CLI](https://cloud.ibm.com/docs/monitoring?topic=monitoring-provisionprovision_cli).





 Step 2: Configure your Kubernetes cluster to send metrics to your instance
IBM Cloud Kubernetes Service does not support the [Portworx experimental InitializerConfiguration admission controller](https://docs.portworx.com/portworx-install-with-kubernetes/storage-operations/hyperconvergence/initializer-experimental-feature-in-stork-v1-1).





 Can I install Portworx in a private cluster? 

Yes. If you want to install Portworx in a private cluster, your IBM Cloud account must be set up with [Virtual Routing and Forwarding (VRF)](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointvrf) and access to private cloud service endpoints for IBM Cloud services.

If you want to install Portworx in a cluster that doesn't have VRF or access to private cloud service endpoints (CSEs), you must create a rule in the default security group to allow inbound and outbound traffic for the following IP addresses: 166.9.24.81, 166.9.22.100, 166.9.20.178. For more information, see [Updating the default security group](https://cloud.ibm.com/docs/vpc?topic=vpc-updating-the-default-security-groupupdating-the-default-security-group).





 What's next? 

All set? Let's start with [creating a cluster with an SDS worker pool of at least three worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-clusters). If you want to include non-SDS worker nodes into your Portworx cluster, [add raw block storage](https://cloud.ibm.com/docs/containers?topic=containers-utilitiesmanual_block) to each worker node. After your cluster is prepared, [install Portworx](https://cloud.ibm.com/docs/containers?topic=containers-storage_portworx_deploy) in your cluster and create your first hyper-converged storage cluster.
ibmcloud ks cluster service unbind --cluster CLUSTER --namespace KUBERNETES_NAMESPACE --service SERVICE_INSTANCE [-q]

Minimum required permissions
: Editor platform access role for the cluster in IBM Cloud Kubernetes Service and Developer Cloud Foundry role

Command options:

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

-n, --namespace KUBERNETES_NAMESPACE
: Required: The name of the Kubernetes namespace.

--service SERVICE_INSTANCE
: Required: The name of the IBM Cloud service instance that you want to remove. To find the name of the service instance, run ibmcloud ks cluster service ls --cluster <cluster_name_or_ID>.

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



 Example cluster service unbind command 

ibmcloud ks cluster service unbind --cluster my_cluster --namespace my_namespace --service 8567221







 ibmcloud ks cluster subnet add 

Classic infrastructure

Make an existing portable public or private classic subnet in your IBM Cloud infrastructure account available to a cluster or reuse subnets from a deleted cluster instead of using the automatically provisioned subnets.

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. To enable communication between workers that are on different subnets on the same VLAN in non-VRF accounts, you must [enable routing between subnets on the same VLAN](https://cloud.ibm.com/docs/containers?topic=containers-subnetssubnet-routing).

ibmcloud ks cluster subnet add --cluster CLUSTER --subnet-id SUBNET [-q]

Minimum required permissions
If you select the cluster control plane APIs in your CBR rule, then only traffic from resources in the network zones that associate with that rule can interact with the cluster control plane APIs. All other requests are blocked.
: If you use the CLI, you can specify the --api-types option and the crn:v1:bluemix:public:containers-kubernetes::::api-type:cluster type.
: If you use the API, you can specify "api_type_id": "crn:v1:bluemix:public:containers-kubernetes::::api-type:cluster" in the "operations" spec.

Management APIs
: Protect access to the APIs for provisioning and managing clusters, worker pools, and more. CBR rules that apply to the management API type control access the Red Hat OpenShift on IBM Cloud APIs, which includes all ibmcloud oc commands calls, such as ibmcloud oc clusters, ibmcloud oc cluster create, and more. If you select the management APIs in your CBR rule, then resources in the network zone that associate with the rule can interact with the management APIs.
: If you use the CLI, you can specify the --api-types option and the crn:v1:bluemix:public:containers-kubernetes::::api-type:management type.
: If you use the API, you can specify "api_type_id": "crn:v1:bluemix:public:containers-kubernetes::::api-type:management" in the "operations" spec.

To follow an example CBR scenario, see [Setting up context-based restrictions](https://cloud.ibm.com/docs/openshift?topic=openshift-cbr-tutorial).





 Allowing Red Hat OpenShift on IBM Cloud to access other IBM Cloud resources by using CBR 

You must add the containers-kubernetes to your network zones for rules created against the following services.

IAM Identity service