vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Persistent storage for single zone clusters 

If you have a single zone cluster, you can choose between the following options in IBM Cloud Kubernetes Service that provide fast access to your data. For higher availability, use a storage option that is designed for geographically distributed data and, if possible for your requirements, create a multizone cluster.

The following image shows the options that you have in IBM Cloud Kubernetes Service to permanently store your data in a single cluster.

Zoom

![Persistent storage options for single zone cluster](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/cs_storage_single_zone.svg)

Figure 2. Persistent storage options for single zone cluster



 Classic File Storage for Classic 

Classic infrastructure



Classic File Storage characteristics

 Characteristics Classic File Storage for Classic 

 Multizone-capable No, as specific to a data center. Data can't be shared across zones, unless you implement your own data replication. 
 Ideal data types All 
 Data usage pattern Random read-write operations, sequential read-write operations, or write-intensive workloads 
 Access Via file system on mounted volume 
 Supported Kubernetes access writes ReadWriteMany (RWX), ReadOnlyMany (ROX), ReadWriteOnce (RWO) 
 Performance Predictable due to assigned IOPS and size. IOPS are shared between the pods that access the volume. 
 Consistency Strong 
 Durability High 
 Resiliency Medium as specific to a data center. File storage server is clustered by IBM with redundant networking. 
 Availability Medium as specific to a data center. 
 Scalability Difficult to extend beyond the data center. You can't change an existing storage tier. 
 Encryption At rest 
 Backup and recovery Set up periodic snapshots, replicate snapshots, duplicate storage, back up data to IBM Cloud Object Storage, or copy data to and from pod and containers. 
 Common use cases Mass or single file storage or file sharing across a single zone cluster. 
 Non-ideal use cases Multizone clusters or geographically distributed data.
When you enable image security enforcement, IBM Cloud Kubernetes Service automatically creates certain image policies in your cluster. When you disable the feature, the underlying ClusterImagePolicy CRD is removed, which removes all the default image policies and any custom images policies that you created.



* Image policies with the name ibm-signed-image-enforcement restrict the images that are run in the namespace to IBM Cloud Kubernetes Service images only. Do not modify these image policies. Any changes that you make are overwritten within a few minutes.
* Other image policies, such as default or default-allow-all, permit images that are not restricted by another image policy. You can modify these image policies and your changes are preserved, but don't rename the image policy. If you rename the policy, more policies with the default name and settings are created.



To review the image policies in your cluster,

Before you begin

[Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster)



1. List the image policies that apply globally to the cluster. For an example configuration, see the [Portieris policy documentation](https://github.com/IBM/portieris/blob/main/helm/portieris/templates/policies.yamlL66).

kubectl get ClusterImagePolicy
2. List the image policies that apply to particular namespaces within the cluster. For an example configuration, see the [Portieris policy documentation](https://github.com/IBM/portieris/blob/main/helm/portieris/templates/policies.yamlL14).

kubectl get ImagePolicy --all-namespaces
06496f64-a689-4693-ba23-320959b7b677 kube-bh077ne10vqpekt0domg-046e0f754d624dca8b287a033d55f96e 8 minutes ago 1234abcd-us-south.lb.appdomain.cloud yes 95482dcf-6b9b-4c6a-be54-04d3c46cf017 online 717f2122-5431-403c-b21d-630a12fc3a5a 10.241.0.7 active 169.63.99.184 c6540331-1c1c-40f4-9c35-aa42a98fe0d9 00809211b934565df546a95f86160f62
6. Access the IP address of the Kubernetes LoadBalancer service that you found in step 4 and your app port in the format <external_IP>:<app_port>.
7. Optional: Repeat these steps to deploy a public VPC NLB in each zone where you want to expose your app. Then, you can register the external IP addresses of the VPC NLB in each zone with one [DNS subdomain](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaasvpc_nlb_dns).



Do not delete the subnets that you attached to your cluster during cluster creation or when you add worker nodes in a zone. If you delete a VPC subnet that your cluster used, any VPC NLBs that use IP addresses from the subnet might experience issues, and you might be unable to create new load balancers.





 Setting up an NLB using port range 

Port ranges can be used in public NLBs when there is a need to host a service from a single host name that has multiple backend applications, each listening on a separate port number. To use port ranges in your Kubernetes cluster, some manual configuration must be performed.
With one click, you can get all Istio core components, additional tracing, monitoring, and visualization up and running. To get started, see [Using the managed Istio add-on](https://cloud.ibm.com/docs/containers?topic=containers-istio) Yes Yes 
 Jenkins X Jenkins X is a Kubernetes-native continuous integration and continuous delivery platform that you can use to automate your build process. For more information about how to install it on IBM Cloud Kubernetes Service, see [Introducing the Jenkins X open source project](https://www.ibm.com/cloud/blog/installing-jenkins-x-on-ibm-cloud-kubernetes-service). 
 Razee [Razee](https://razee.io/) is an open-source project that automates and manages the deployment of Kubernetes resources across clusters, environments, and cloud providers, and helps you to visualize deployment information for your resources so that you can monitor the rollout process and find deployment issues more quickly. For more information about Razee and how to set up Razee in your cluster to automate your deployment process, see the [Razee documentation](https://github.com/razee-io/Razee). Yes Yes 
 IBM Cloud Schematics [IBM Cloud Schematics](https://cloud.ibm.com/docs/schematics?topic=schematics-getting-started) is a managed Terraform service where you can use native Terraform capabilities, but you don't have to worry about setting up and maintaining the Terraform CLI and IBM Cloud Provider plug-in. For more information about how to use Terraform to create a cluster, see [Creating single and multizone Kubernetes and Red Hat OpenShift clusters](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-tutorial-tf-clusters). Yes Yes
Connectivity to services 



 Journey Map 

![Architecture](https://cloud.ibm.com/docs-content/v1/content/b7b9235ce6abd45b66931867c388cf107d38e15b/cloud-native-journey/kubernetes-on-vpc/images/connectivity/journey-map.png)





 Overview 

In a typical deployment, your application will leverage one or more IBM Cloud services (i.e. PostgreSQL, Redis, Cloud Object Storage, Logging, etc.). In this section of the journey, we will cover connecting to these services and securing those connections.





 Public vs Private Endpoints 

When creating/configuring a cloud service, you will see two types of connection endpoints - public and private. The recommended way to connect to the service is via it's PRIVATE endpoint. Doing so will use the IBM private backbone for communication and provides the benefit of no data transfer fees. Public endpoints are internet facing and should NOT be enabled unless required (and may incur data transfer fees).

![Architecture](https://cloud.ibm.com/docs-content/v1/content/b7b9235ce6abd45b66931867c388cf107d38e15b/cloud-native-journey/kubernetes-on-vpc/images/connectivity/pub-priv-endpoints.png)





 Allowlisting via Cloud Service Endpoints (CSEs) 

Cloud services allows you to define IP Allowlisting rules, which defines the IPs that are allowed to establish network connectivity to your service. If allowinglisting is not used, then the cloud service does not restrict incoming connections to a specific IP addresses.

IP Allowinglist is a best practice, even if your cloud service is enabled only for private endpoints. Doing so adds additional level of security so only specific IPs on the private backbone are allowed to connect.

As shown in the figure below, its important to understand that each zone in a VPC is assigned a CSE Source Address IP, and it is this IP that is visible to the backend cloud service.
Select the toolchain that you want to modify.



Having trouble finding the toolchain that you configured for your cluster? If one of the stages in your continuous delivery pipeline fails, the toolchain does not show in the DevOps tab of your cluster. Make sure to review errors in your pipeline by selecting your toolchain from the [Continuous Delivery dashboard](https://cloud.ibm.com/devops/toolchains) directly.







 Additional content 



* To automate your CI/CD pipeline, check out the following supported [integrations and tools](https://cloud.ibm.com/docs/containers?topic=containers-cicdcicd_strategy).



* Codeship
* Grafeas
* IBM® Continuous Delivery Pipeline for IBM Cloud®
* Helm
* Kustomize
* Razee



* For a deep dive into the benefits and specifics of automating continuous integration and delivery, check out [Automate continuous integration](https://www.ibm.com/garage/method/practices/code/practice_continuous_integration) and [Build and deploy by using continuous delivery](https://www.ibm.com/garage/method/practices/deliver/practice_continuous_delivery) in the IBM Garage Methodology documentation.







 What's next 



* Understanding [high availability and disaster recovery for IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-ha)
* [Enhance your cluster with extra and open-source capabilities](https://cloud.ibm.com/docs/containers?topic=containers-managed-addons)
* [Adding complex Kubernetes apps to your cluster by using Helm charts](https://cloud.ibm.com/docs/containers?topic=containers-helm)
* [Planning app deployments for high availability](https://cloud.ibm.com/docs/containers?topic=containers-plan_deploy)
Select the toolchain that you want to modify.



Having trouble finding the toolchain that you configured for your cluster? If one of the stages in your continuous delivery pipeline fails, the toolchain does not show in the DevOps tab of your cluster. Make sure to review errors in your pipeline by selecting your toolchain from the [Continuous Delivery dashboard](https://cloud.ibm.com/devops/toolchains) directly.







 Additional content 



* To automate your CI/CD pipeline, check out the following supported [integrations and tools](https://cloud.ibm.com/docs/openshift?topic=openshift-cicdcicd_strategy).



* Codeship
* Grafeas
* IBM® Continuous Delivery Pipeline for IBM Cloud®
* Helm
* Kustomize
* Operators
* Razee



* For a deep dive into the benefits and specifics of automating continuous integration and delivery, check out [Automate continuous integration](https://www.ibm.com/garage/method/practices/code/practice_continuous_integration) and [Build and deploy by using continuous delivery](https://www.ibm.com/garage/method/practices/deliver/practice_continuous_delivery) in the IBM Garage Methodology documentation.







 What's next 



* Understanding [high availability and disaster recovery for IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-ha)
* [Enhance your cluster with extra and open-source capabilities](https://cloud.ibm.com/docs/containers?topic=containers-managed-addons)
* [Adding complex Kubernetes apps to your cluster by using Helm charts](https://cloud.ibm.com/docs/containers?topic=containers-helm)
* [Planning app deployments for high availability](https://cloud.ibm.com/docs/containers?topic=containers-plan_deploy)
Every request that is validated and forwarded by the Ingress controller to your apps has an authorization header that contains the tokens.





 Before you begin 

Before you can get started, ensure that you have the following prerequisites.



* An instance of App ID that is provisioned in the same region in which your cluster is deployed. The service name must contain only alphanumeric characters or hyphens (-), and cannot contain spaces.
* A standard Kubernetes Service cluster with at least two worker nodes in each available zone.
* The following IBM Cloud IAM roles:



* Cluster: Administrator platform role
* Kubernetes namespaces: Manager service role
* App ID: Editor platform role and Writer Service role



* The following CLIs:



* [IBM Cloud](https://cloud.ibm.com/docs/cli?topic=cli-getting-started)
* [Kubernetes](https://kubernetes.io/docs/tasks/tools/install-kubectl/)



* The Kubernetes Service and Container Registry [CLI plug-ins](https://cloud.ibm.com/docs/cli?topic=cli-install-devtools-manuallyidt-install-kubernetes-cli-plugin)



To ensure the best performance of the integration, it is recommended that you always use the latest version of IBM Cloud Kubernetes Service Application Load Balancer (ALB). By default, autoupdate is enabled for your cluster. For more information about autoupdates, see [OnDemand ALB update feature on Kubernetes Service](https://www.ibm.com/cloud/blog/on-demand-alb-update-feature-on-ibm-cloud-kubernetes-service).





 Adding redirect URLs 

A redirect URL is the callback endpoint of your app; the location where a user is sent after successfully signing in or out of your app. To prevent phishing attacks, App ID validates requested URLs against an allowlist of redirect URLs that you add to the service.
[Note icon](https://cloud.ibm.com/docs-content/v1/content/icons/note_icon.svg)](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-ibm-sec-best-practices-change-log) 
 Red Hat OpenShift Kubernetes OCP4 profile Validate the configuration of your IBM Cloud Red Hat OpenShift clusters. [![Note icon](https://cloud.ibm.com/docs-content/v1/content/icons/note_icon.svg)](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-openshift-profile)
[IBM Cloud® Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-getting-started) might be a good choice for your applications.
* Need greater efficiency and revolutionary delivery? [Red Hat OpenShift on IBM Cloud](https://cloud.ibm.com/docs/openshift?topic=openshift-getting-started) might be your solution.



Further information in this announcement will point to additional information to help you decide which application hosting service is right for your organization. All IBM Cloud Foundry users need to decide where to move their Cloud Foundry workload applications prior to the IBM Cloud Foundry "End-of-Support" date.

The following is a suggested checklist to plan your migration:



1. Understand and plan for the timeline and key milestone dates.
2. Evaluate the IBM Cloud® compute migration options.
3. Pick an IBM Cloud® service migration compute target that best meets your requirements and goals.
4. Deploy your applications to the target IBM Cloud® service and compare the operation of your applications.
5. When ready, move application traffic as appropriate. It is suggested that you use a load balancer to slowly adjust workload during the migration. This way you can control your customer engagement with the migrated applications and do complete testing.
6. Stop your IBM Cloud Foundry application instances, and when ready, delete the applications prior to the End-of-Support date.



Note: Reminders will be sent to you as long as you have running IBM Cloud Foundry applications. Those reminders will end when all of your applications have been stopped and your usage of IBM Cloud Foundry is at zero.





 IBM Cloud® compute service options 

IBM Cloud® users have a choice of several modern application hosting runtime platforms on the IBM Cloud®.



* [IBM Cloud Code Engine](https://www.ibm.com/cloud/code-engine) is a fully managed, serverless platform that runs your containerized workloads, including web apps, micro-services, event-driven functions, or batch jobs. IBM Cloud Code Engine even builds container images for you from your source code.
Tekton provides a set of shared components for building [continuous integration](https://www.ibm.com/garage/method/practices/code/practice_continuous_integration/) and [continuous delivery](https://www.ibm.com/garage/method/practices/deliver/practice_continuous_delivery/) systems. As an open source project, Tekton is managed by the [Continuous Delivery Foundation](https://cd.foundation/). The goal is to modernize continuous delivery by providing industry specifications for pipelines, workflows, and other building blocks. With Tekton, you can build, test, and deploy across cloud providers or on-premises systems by abstracting the underlying implementation details. Tekton pipelines are built into [Continuous Delivery](https://www.ibm.com/cloud/blog/announcements/build-and-deliver-using-tekton-enabled-pipelines). For more information about the IBM Cloud® Kubernetes Service, see [IBM Cloud® Kubernetes Service](https://www.ibm.com/garage/method/practices/run/tool_ibm_container).



 Before you begin 

Before you start this tutorial, make sure that you have the following resources in place:



* An [IBM Cloud account](https://cloud.ibm.com/registration). Depending on your IBM Cloud account type, access to certain resources might be limited. Depending on your account plan limits, certain capabilities that are required by some of the deployment strategies might not be available. For more information about IBM Cloud accounts, see [Setting up your IBM Cloud account](https://cloud.ibm.com/docs/account?topic=account-account-getting-started) and [Upgrading your account](https://cloud.ibm.com/docs/account?topic=account-upgrading-account).
* A [Code Engine Project](https://cloud.ibm.com/docs/codeengine?topic=codeengine-getting-started) and an API Key. You can create these resources by using either the UI or the CLI.
Configure CI/CD services for app deployment 

Continuous integration (CI) can help you detect errors early, ensure early system integration, and improve collaboration in your development process.

Continuous delivery (CD) is a practice by which you build and deploy your software so that it can be released into production at any time. By automating your continuous integration and delivery processes through setting up CI/CD pipelines, you can achieve repeatability in code releases and greater predictability in delivery schedules.



 Journey Map 

![Architecture](https://cloud.ibm.com/docs-content/v1/content/b7b9235ce6abd45b66931867c388cf107d38e15b/cloud-native-journey/roks-on-vpc/images/cicd/journey-map.png)





 Setting up continuous integration and delivery 

To add a continuous delivery pipeline to your cluster,



1. From the [Red Hat OpenShift clusters console](https://cloud.ibm.com/kubernetes/clusters?platformType=openshift), select the cluster for which you want to set up a continuous delivery pipeline.
2. Select the DevOps tab.
3. Click on Create a toolchain.
4. Review the available toolchains. IBM provides pre-defined toolchains that you can use to deploy, test, and monitor Kubernetes-native apps or Helm charts. You can expand each toolchain to find an overview of the tools that are set up for you and to find the scripts in GitHub that are used to configure the toolchain in your cluster. For more information about each toolchain, see [Toolchain templates](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-cd_abouttemplates). If you know what tools you want to use, you can create your own toolchain.
5. Select the toolchain that you want to use and click Create.
6. Follow the directions in the console to configure your toolchain.
To be certain that your peers have no database corruption, you should reprovision your peers.

Miscellaneous bug fixes and security patches. If you are running OpenShift Container Platform 3.11 in IBM Cloud, it is recommended that you [upgrade your cluster to 4.3](https://docs.openshift.com/container-platform/4.3/migration/migrating_3_4/planning-migration-3-to-4.html) now in order to fully take advantage of the new features. After you upgrade your cluster, follow instructions to [refresh your blockchain console](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-manage-consoleibp-console-refresh) to experience the latest functionality in this release.



 Fabric peer and ordering node images 

The platform introduces the capability to deploy new peer and ordering nodes based on either Hyperledger Fabric v1.4 or v2.x. Deploying peer and ordering nodes with the latest Fabric images is recommended to ensure that you have access to current Fabric fixes and features. It is not currently possible to migrate existing nodes to Fabric v2 images.





 Elimination of Docker daemon dependency 

Leveraging the Fabric v2 external chaincode launcher capability, when you deploy a peer based on the Fabric v2.1.1 image, smart contracts are deployed into their own pod rather than inside a container on the peer pod.





 Multizone-capable storage 

If your Kubernetes cluster is configured to use multizone-capable storage, new peer and ordering nodes can be deployed that leverage multizone storage, effectively extending their high availability across cluster zones. See [Multizone-capable Storage](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-deploy-iksibp-console-storage-multizone) for more information.





 Kubernetes version upgrade 

IBM Blockchain Platform requires Kubernetes v1.15 - v1.18. If your existing Kubernetes cluster is running v1.14 or lower, you need to upgrade your cluster before you can update your existing blockchain components to this latest release.







 20 May 2020
Click [Using Cloud Object Storage buckets as an evidence locker](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-cos-bucket-evidence) to create a Cloud Object Storage instance. For more information on configuring a bucket that can act as a compliance evidence locker, see [Configuring Cloud Object Storage for storing evidence](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-cos-config).



* Cloud Object Storage instance, Bucket name, and Cloud Object Storage endpoint fields are automatically populated.
* Enter the Service ID API key



* Preferred: An existing key can be imported from a secrets vault by clicking the key icon.
* An existing key can be copy and pasted.





The endpoint field is optional. It is recommended to select or provide the endpoint during the setup of the toolchain or during the pipeline run.





 Deployment target 

Configure the target where the application is deployed. The toolchain provides with an option to either deploy your application to Single cluster or to Multiple clusters by using Satellite Config. If you want to deploy your application to targets like VSI (Virtual Server Instance) or customize deployment process, use the Custom option.





 IBM Cloud API Key 

The API key is used to interact with the ibmcloud CLI tool in several tasks.



* Preferred: An existing key can be imported from a secrets vault by clicking the key icon.
* An existing key can be copy and pasted.
* A new key can be created from here by clicking the New +.



The newly generated API key can be immediately saved to a secrets vault.





 Single cluster deployment target 

With this option, you can deploy your application to an existing Kubernetes cluster on IBM Cloud. The toolchain currently supports Kubernetes cluster that is managed by IBM Cloud Kubernetes Service or a Red Hat OpenShift cluster. After the IBM Cloud API Key field is completed, select the Resource group and Cluster region field where your target cluster is created.