vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* The master is publicly accessible to authorized cluster users only through the public cloud service endpoint. Your cluster users can securely access your Kubernetes master over the internet to run kubectl commands, for example.







 Public and private cloud service endpoints 

To make your master publicly or privately accessible to cluster users, you can enable the public and private cloud service endpoints. VRF is required in your IBM Cloud account, and you must enable your account to use service endpoints. To enable VRF and service endpoints, run ibmcloud account update --service-endpoint-enable true.



* If worker nodes are connected to public and private VLANs, communication between worker nodes and master is established over both the private network through the private cloud service endpoint and the public network through the public cloud service endpoint. By routing half of the worker-to-master traffic over the public endpoint and half over the private endpoint, your master-to-worker communication is protected from potential outages of the public or private network. If worker nodes are connected to private VLANs only, communication between worker nodes and master is established over the private network through the private cloud service endpoint only.
* The master is publicly accessible to authorized cluster users through the public cloud service endpoint. The master is privately accessible through the private cloud service endpoint if authorized cluster users are in your IBM Cloud private network or are connected to the private network through a VPN connection or IBM Cloud Direct Link. Note that you must [expose the master endpoint through a private load balancer](https://cloud.ibm.com/docs/containers?topic=containers-access_clusteraccess_private_se) so that users can access the master through a VPN or IBM Cloud Direct Link connection.
* You can optionally secure access to your private cloud service endpoint by creating a subnet allowlist. Only authorized requests to your cluster master that originate from subnets in the allowlist are permitted through the cluster's private cloud service endpoint. For more information, see [Creating an allowlist for the private cloud service endpoint](https://cloud.ibm.com/docs/containers?topic=containers-access_clusterprivate-se-allowlist).







 Private service endpoint only
It also presumes you are comfortable with using the Kubernetes CLI to administer your Kubernetes cluster.

If you are using a Kubernetes cluster on IBM Cloud and IBM Cloud HSM, both services need to be deployed from the same IBM Cloud account and on the same VLAN. If they are not on the same VLAN, then VLAN spanning must be enabled.

When the entire HSM configuration is complete, it resembles the following diagram:

HSM configured with an HSM client image

Zoom

![HSM configured with an HSM client image](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/blockchain/images/hsm_2proxy.svg)

Figure 1. An example configuration of an HSM configured with an HSM client image.

The steps in this topic focus specifically on the creation of the Cloud HSM and the HSM Client in the diagram. When you deploy a CA, peer, or ordering node to use the HSM, you need to provide the label and PIN of the HSM partition. This configuration assumes you enabled HSM on your Kubernetes cluster when you deployed the service.



 Part One: Set up the HSM device and HSM client 



1. Provision the HSM and configure it with at least one partition. For example, you can follow instructions for [Provisioning IBM Cloud HSM](https://cloud.ibm.com/docs/hardware-security-modules?topic=hardware-security-modules-provisioning-ibm-cloud-hsm).

Be sure to record the Label and PIN for the partition. You will need to provide these values later when you configure a blockchain node to use this HSM partition. Also, save the IP address associated with the HSM device. We will refer to this value throughout these instructions as <HSM_ADDRESS>.
2.
You can manually set infrastructure credentials to a different account only for classic clusters, not for VPC clusters.



 ibmcloud ks credential get 

Classic infrastructure

If you set up your IBM Cloud account to use different credentials to access the IBM Cloud infrastructure portfolio, get the infrastructure username for the region and resource group that you are currently targeted to.

ibmcloud ks credential get --region REGION [-q] [--output json]

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

Command options:

--region REGION
: Specify a region in IBM Cloud Kubernetes Service: jp-osa, jp-tok, au-syd, eu-de, eu-gb, us-east, or us-south.

--output json
: Optional: Prints the command output in JSON format.

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



 Example credential get command 

ibmcloud ks credential get --region us-south







 ibmcloud ks credential set classic 

Classic infrastructure

Set credentials for a resource group and region so that you can access the IBM Cloud infrastructure portfolio through your IBM Cloud account.

If you have an IBM Cloud Pay-As-You-Go account, you have access to the IBM Cloud infrastructure portfolio by default. However, you might want to use a different, existing IBM Cloud infrastructure account to order infrastructure. You can link this infrastructure account to your IBM Cloud account by using this command.

If IBM Cloud infrastructure credentials are manually set for a region and a resource group, these credentials are used to order infrastructure for all clusters within that region in the resource group. These credentials are used to determine infrastructure permissions, even if an [IBM Cloud IAM API key](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_api_key_info) exists for the resource group and region. If the user whose credentials are stored does not have the required permissions to order infrastructure, then infrastructure-related actions, such as creating a cluster or reloading a worker node can fail.
* [ibmcloud ks quota ls](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_quota_ls)







 ibmcloud ks subnets 

[List available portable subnets in your IBM Cloud infrastructure account](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_subnets).





 ibmcloud ks vlan 

[List public and private VLANs for a zone and view the VLAN spanning status](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clivlan).



* [ibmcloud ks vlan ls](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_vlans)
* vlan spanning: View the VLAN spanning status for your IBM Cloud classic infrastructure account.



* [ibmcloud ks vlan spanning get](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_vlan_spanning_get)









 ibmcloud ks vpcs 

[List all VPCs in the targeted resource group. If no resource group is targeted, then all VPCs in the account are listed.](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_vpcs).





 ibmcloud ks flavors 

[List available flavors for a zone](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_machine_types).





 ibmcloud ks locations 

[List supported IBM Cloud Kubernetes Service locations](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_supported-locations).





 ibmcloud ks messages
* Tokyo (AP North, jp-tok): https://jp-tok.containers.cloud.ibm.com
* Toronto (ca-tor): https://ca-tor.containers.cloud.ibm.com
* Washington, D.C. (US East, us-east): https://us-east.containers.cloud.ibm.com



To use the global functionality, you can use the ibmcloud oc api command again to target the global endpoint: https://containers.cloud.ibm.com

ibmcloud oc api --endpoint ENDPOINT [--insecure] [--skip-ssl-validation] [--api-version VALUE] [-q]

Minimum required permissions
: None

Command options:

--endpoint ENDPOINT
: The IBM Cloud Kubernetes Service API endpoint. Note: This endpoint is different than the IBM Cloud endpoints. This value is required to set the API endpoint.

--insecure
: Allow an insecure HTTP connection. This option is optional.

--skip-ssl-validation
: Allow insecure SSL certificates. This option is optional.

--api-version VALUE
: Optional: Specify the API version of the service that you want to use.

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

Example: View information about the current API endpoint that is targeted.

ibmcloud oc api

API Endpoint: https://containers.cloud.ibm.com
API Version: v1
Skip SSL Validation: false
Region: us-south





 init command 

Virtual Private Cloud

Classic infrastructure

Initialize the Red Hat OpenShift on IBM Cloud plug-in or specify the region where you want to create or access Red Hat OpenShift clusters.

Region-specific endpoints are deprecated. Use the [global endpoint](https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zonesendpoint) instead.
Create a configuration YAML file for your Kubernetes LoadBalancer service. Consider naming the service in the format <app_name>-vpc-nlb-<VPC_zone>.

Mixed protocol load balancer services are not currently supported in IBM Cloud Kubernetes Service. Do not specify both TCP and UDP ports in your load balancer definition, as doing so causes an error that prevents the load balancer service from provisioning. Note that specifying the service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp annotation with a TCP port does not create this conflict.

apiVersion: v1
kind: Service
metadata:
name: <app_name>-vpc-nlb-<VPC_zone>
annotations:
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "nlb"
service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: "<subnet_ID>"
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector: "<key>=<value>"
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp: "<tcp_port"
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol: "<protocol>"
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port: "<port>"
For every subsequent cluster that you create in that zone, you can specify the VLAN pair that you want to use. You can reuse the same public and private VLANs that were created for you because multiple clusters can share VLANs.

For more information about VLANs, subnets, and IP addresses, see [Overview of networking in IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-subnetsbasics).

Need to create your cluster by using custom subnets? Check out [Using existing subnets to create a cluster](https://cloud.ibm.com/docs/containers?topic=containers-subnetssubnets_custom).





 Worker node communication across subnets and VLANs 

In several situations, components in your cluster must be permitted to communicate across multiple private VLANs. For example, if you want to create a multizone cluster, if you have multiple VLANs for a cluster, or if you have multiple subnets on the same VLAN, the worker nodes on different subnets in the same VLAN or in different VLANs can't automatically communicate with each other. You must enable either Virtual Routing and Forwarding (VRF) or VLAN spanning for your IBM Cloud infrastructure account.



* [Virtual Routing and Forwarding (VRF)](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointvrf): VRF enables all the private VLANs and subnets in your infrastructure account to communicate with each other. Additionally, VRF is required to allow your workers and master to communicate over the private cloud service endpoint, and to communicate with other IBM Cloud instances that support private cloud service endpoints. To check whether a VRF is already enabled, use the ibmcloud account show command. To enable VRF, run ibmcloud account update --service-endpoint-enable true. This command output prompts you to open a support case to enable your account to use VRF and service endpoints. VRF eliminates the VLAN spanning option for your account because all VLANs are able to communicate.
Alternatively, you can use the APIs to deploy a peer or orderer to a specific zone. For more information on how to do this with the APIs, see [Creating a node within a specific zone](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-apisibp-v2-apis-zone).

The CA zone selection is only available when the default database type SQLite is used and your cluster is configured with multiple zones.

Other CA considerations: If you have multiple zones configured for your Kubernetes cluster, when you create a new CA with a PostgreSQL database and replica sets, an anti-affinity policy ensures that the CA replica sets are automatically configured across the zones. Replica sets are represented as shaded CA boxes in the diagram above. Adequate resources must exist in the other zones in order for the anti-affinity policy to be used.



 Multizone-capable storage: 

Before you deploy any nodes, you have the additional option to configure your Kubernetes cluster to use [multizone-capable storage](https://cloud.ibm.com/docs/containers?topic=containers-storage_planningpersistent_storage_overview) as your persistent storage. Without multizone-capable storage, if an entire zone goes down, any blockchain nodes in that zone cannot automatically come up in another zone because their associated persistent storage is unavailable in the failed zone. When multizone-capable storage is configured, if a zone failure occurs, peers and ordering nodes can come up in another zone, with their associated storage intact, ensuring high-availability. In order to leverage this capability with the IBM Blockchain Platform, you need to configure your cluster to use SDS (Portworx) storage.
You can manually set infrastructure credentials to a different account only for classic clusters, not for VPC clusters.



 ibmcloud ks credential get 

Classic infrastructure

If you set up your IBM Cloud account to use different credentials to access the IBM Cloud infrastructure portfolio, get the infrastructure username for the region and resource group that you are currently targeted to.

ibmcloud ks credential get --region REGION [-q] [--output json]

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

Command options:

--region REGION
: Specify a region in IBM Cloud Kubernetes Service: jp-osa, jp-tok, au-syd, eu-de, eu-gb, us-east, or us-south.

--output json
: Optional: Prints the command output in JSON format.

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



 Example credential get command 

ibmcloud ks credential get --region us-south







 ibmcloud ks credential set classic 

Classic infrastructure

Set credentials for a resource group and region so that you can access the IBM Cloud infrastructure portfolio through your IBM Cloud account.

If you have an IBM Cloud Pay-As-You-Go account, you have access to the IBM Cloud infrastructure portfolio by default. However, you might want to use a different, existing IBM Cloud infrastructure account to order infrastructure. You can link this infrastructure account to your IBM Cloud account by using this command.

If IBM Cloud infrastructure credentials are manually set for a region and a resource group, these credentials are used to order infrastructure for all clusters within that region in the resource group. These credentials are used to determine infrastructure permissions, even if an [IBM Cloud IAM API key](https://cloud.ibm.com/docs/cli?topic=cli-kubernetes-service-clics_api_key_info) exists for the resource group and region. If the user whose credentials are stored does not have the required permissions to order infrastructure, then infrastructure-related actions, such as creating a cluster or reloading a worker node can fail.
Kubernetes version 1.22 is unsupported as of 18 January 2023. Update your cluster to at least [version 1.23](https://cloud.ibm.com/docs/containers?topic=containers-cs_versions_123) as soon as possible.



 Kubernetes version 1.22 change log 

View information about version changes for major, minor, and patch updates that are available for your IBM Cloud® Kubernetes Service clusters that run version 1.22. Changes include updates to Kubernetes and IBM Cloud Provider components.



 Overview 

Unless otherwise noted in the change logs, the IBM Cloud Kubernetes Service provider version enables Kubernetes APIs and features that are at beta. Kubernetes alpha features, which are subject to change, are disabled.

For more information about major, minor, and patch versions and preparation actions between minor versions, see [Kubernetes versions](https://cloud.ibm.com/docs/containers?topic=containers-cs_versions).

Check the [Security Bulletins on IBM Cloud Status](https://cloud.ibm.com/status?component=containers-kubernetes&selected=security) for security vulnerabilities that affect IBM Cloud Kubernetes Service. You can filter the results to view only Kubernetes Cluster security bulletins that are relevant to IBM Cloud Kubernetes Service. Change log entries that address other security vulnerabilities but don't also refer to an IBM security bulletin are for vulnerabilities that are not known to affect IBM Cloud Kubernetes Service in normal usage. If you run privileged containers, run commands on the workers, or execute untrusted code, then you might be at risk.

Some change logs are for worker node fix packs, and apply only to worker nodes. You must [apply these patches](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_update) to ensure security compliance for your worker nodes. These worker node fix packs can be at a higher version than the master because some build fix packs are specific to worker nodes.
IBM Blockchain Platform locations 

IBM Cloud® is hosted worldwide in various locations. Locations are data centers within a geographic area that is accessed by an endpoint. IBM Blockchain Platform deploys blockchain networks within IBM Cloud globally in different locations. When you create IBM Blockchain Platform service instance in IBM Cloud, your blockchain network and network resources are created and stored in the IBM Cloud location where you create the service instance in.



 IBM Blockchain Platform for IBM Cloud 

To deploy the IBM Blockchain Platform for IBM Cloud, you need to select two locations:



1. You need to deploy a Kubernetes cluster on IBM Cloud. You can deploy the cluster to any geography supported by the IBM Kubernetes service or Red Hat OpenShift on IBM Cloud. For more information, see the list of [locations for the IBM Kubernetes service](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zones) or [locations for OpenShift on IBM Cloud](https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zones).

Zoom

![Kubernetes cluster on IBM Cloud locations](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/blockchain/images/ibp_v2_regions.png)

Figure 1. Kubernetes cluster on IBM Cloud locations
2. After you deploy a cluster on IBM Cloud, you need to deploy an instance of the IBM Blockchain Platform. The IBM Blockchain Platform operational tooling can be deployed in each of the regions in the table below:





Table 1. IBM Blockchain Platform for IBM Cloud locations

 Geography Country IBM Blockchain Platform operational tools region 

 Asia Pacific Australia Sydney 
 Asia Pacific Japan Tokyo 
 Europe Germany Frankfurt 
 Europe United Kingdom London 
 North America United States Dallas 
 North America United States Washington, D.C.
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.
* Outbound network access uses (TCP:443) where the region matches the delivery pipeline location and is either au-syd (Sydney, Australia), eu-de (Frankfurt, Germany), eu-gb (London, United Kingdom), jp-tok (Tokyo, Japan), jp-osa (Osaka, Japan), us-south (Dallas, US), us-east (Washington DC, US), br-sao (Sao Paulo), or ca-tor (Toronto, CA). For example, for the Frankfurt region specify https://private-worker-service.eu-de.devops.cloud.ibm.com (TCP:443). For network access to the global endpoint for API key validation, use https://iam.cloud.ibm.com (TCP:443).



* Permissions to pull images from icr.io. Private workers require the tekton-pipelines infrastructure and must be able to pull tekton-releases images from icr.io to complete the private worker installation.

To pull images from the icr.io container registry, you might need to [define a specific Kubernetes ClusterImagePolicy](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-faq_pipeline_private_workers&interface=uipipeline_private_worker_image_policy).
* Optional.
By default, the ibmcloud oc cluster service bind command creates service credentials with the public cloud service endpoint. To use the private cloud service endpoint, you must manually create service credentials for your service that use the private cloud service endpoint, and then use the --key option to specify the name of the existing service credentials.

Your service might not yet support private cloud service endpoints.





 Can I use all IBM Cloud services in my cluster? 

You can use service binding only for services that support service keys so that the service credentials can automatically be created and stored in a Kubernetes secret. To find a list of services that support service keys, see [Enabling external apps to use IBM Cloud services](https://cloud.ibm.com/docs/account?topic=account-externalappexternalapp).

Services that don't support service keys usually provide an API that you can use in your app. The service binding method does not automatically set up API access for your app. Make sure to review the API documentation of your service and implement the API interface in your app.





 Can I bind multiple IBM Cloud services to multiple clusters at once? 

IBM Cloud service binding is on a per-cluster, per-service basis, and works by creating a Kubernetes secret that your pods can mount.

For multiple clusters and services, you can [use IAM trusted profiles instead](https://cloud.ibm.com/docs/openshift?topic=openshift-pod-iam-identity). In IAM, you create a trusted profile with access policies for the IBM Cloud services that you want. Then, you link the trusted profile with as many clusters as you want, based on conditions such as all the prod Kubernetes namespaces in clusters in a resource group. Finally, your pods mount the Kubernetes service account projected volume to get a token that can be exchanged for an IAM token that your apps use to authenticate with the IBM Cloud services.







 Adding IBM Cloud services to clusters 

Use IBM Cloud service binding to automatically create service credentials for your IBM Cloud services and store these credentials in a Kubernetes secret.

Before you begin:



* Ensure you have the following roles: