vania-janet/multiturn-rag-retrieval-data huggingface dataset:
If you are linking to a Red Hat OpenShift cluster in IBM Cloud, review the topic on [Planning highly available persistent storage](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_planningchoose_storage_solution). If you are linking to an IBM Cloud Kubernetes Service cluster, you can choose from several [Kubernetes storage options](https://cloud.ibm.com/docs/containers?topic=containers-storage_planningchoose_storage_solution) and decide on the storage type that best fits your use case. In both cases, you need to provision persistent storage. Be aware that you are charged separately for your storage usage, so you can factor in the cost of the various storage options when you make your selection. All of the predefined storage classes in your Kubernetes cluster on IBM Cloud use File Storage as the backing storage. For more information, see [IBM Cloud File Storage pricing](https://www.ibm.com/cloud/file-storage/pricing).





 Multizone-capable storage 

If your Kubernetes cluster is configured with SDS (Portworx) storage, you can leverage multizone-capable storage for your nodes. 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 for high availability, if a zone failure occurs, the nodes can come up in another zone, with their associated storage intact, ensuring high availability of the node. To learn more about multizone-capable storage, see the comparison of persistent storage options for multizone clusters on [OpenShift](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_planningpersistent_storage_overview) or [IBM Cloud Kubernetes service](https://cloud.ibm.com/docs/containers?topic=containers-storage_planningpersistent_storage_overview).
Cluster autoscaler With the ibm-iks-cluster-autoscaler plug-in, you can scale the worker pools in your cluster automatically to increase or decrease the number of worker nodes in the worker pool based on the sizing requests of your scheduled workloads. For more information, see [Scaling clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-classic-vpc). 
 Diagnostics and debug tool While you troubleshoot, you can use the [IBM Cloud Kubernetes Service Diagnostics and Debug Tool add-on](https://cloud.ibm.com/docs/openshift?topic=openshift-debug-tool) to run tests and gather pertinent information from your cluster. 
 IBM Cloud Paks [IBM Cloud Paks™](https://www.ibm.com/cloud-paks/) are containerized, licensed IBM middleware and open source software components that you can use to modernize, move, and build cloud-native business applications in hybrid and multicloud deployments. By running exclusively on Red Hat OpenShift and Red Hat Enterprise Linux, Cloud Paks are built atop a secure stack and maintain consistency in deployment and behavior across cloud providers. To get started, see [Adding Cloud Paks](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_cloud_paks). 
 Istio for service mesh Unlike for community Kubernetes clusters, the Istio managed add-on is not supported. Instead, use the [Red Hat service mesh operator](https://docs.openshift.com/container-platform/4.11/service_mesh/v1x/servicemesh-release-notes.html). Note: The default IBM Cloud configuration of the routers enables host networking, which is not compatible with the service mesh network policy.
The private NLB exposes the private cloud service endpoint of the master as an internal 172.21.x.x cluster IP address that the strongSwan VPN pod can access. If you enable only the private cloud service endpoint, you can use the Kubernetes dashboard or temporarily enable the public cloud service endpoint to create the private NLB.





 Configuring the strongSwan VPN in a multizone cluster 

Multizone clusters provide high availability for apps in the event of an outage by making app instances available on worker nodes in multiple zones. However, configuring the strongSwan VPN service in a multizone cluster is more complex than configuring strongSwan in a single-zone cluster.

Before you configure strongSwan in a multizone cluster, first try to deploy a strongSwan Helm chart into a single-zone cluster. When you first establish a VPN connection between a single-zone cluster and an on-premises network, you can more easily determine remote network firewall settings that are important for a multizone strongSwan configuration.



* Some remote VPN endpoints have settings such as leftid or rightid in the ipsec.conf file. If you have these settings, check whether you must set the leftid to the IP address of the VPN IPSec tunnel.
* If the connection is inbound to the cluster from the remote network, check whether the remote VPN endpoint can re-establish the VPN connection to a different IP address in case of load balancer failure in one zone.



To get started with strongSwan in a multizone cluster, choose one of the following options.



* If you can use an outbound VPN connection, you can choose to configure only one strongSwan VPN deployment. See [Configuring one outbound VPN connection from a multizone cluster](https://cloud.ibm.com/docs/containers?topic=containers-vpnmultizone_one_outbound).
* If you require an inbound VPN connection, the configuration settings you can use vary depending on whether the remote VPN endpoint can be configured to re-establish the VPN connection to a different public load balancer IP when an outage is detected.
For example, if you integrate Grafeas into your app build process, Grafeas can store information about the initiator of the build request, vulnerability scan results, and quality assurance sign-off so that you can make an informed decision if an app can be deployed to production. You can use this metadata in audits or to prove compliance for your software supply chain. Yes Yes 
 Helm [Helm](https://helm.sh) is a Kubernetes package manager. You can create new Helm charts or use preexisting Helm charts to define, install, and upgrade complex Kubernetes applications that run in IBM Cloud Kubernetes Service clusters. For more information, see [Setting up Helm in IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-helm). Yes Yes 
 IBM Cloud Continuous Delivery Automate your app builds and container deployments to Kubernetes clusters by using a toolchain. For more information about the setup, see [working with Tekton pipelines](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-tekton-pipelines). Yes Yes 
 Istio on IBM Cloud Kubernetes Service [Istio](https://www.ibm.com/cloud/istio) is an open source service that gives developers a way to connect, secure, manage, and monitor a network of microservices, also known as a service mesh, on cloud orchestration platforms. Istio on IBM Cloud® Kubernetes Service provides a one-step installation of Istio into your cluster through a managed add-on. 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.
Accessing the cluster master with admission controllers and webhooks 

Admission controllers intercept authorized API requests from various Kubernetes resources before the requests reach the API server that runs in your IBM Cloud Kubernetes Service cluster master. Mutating admission webhooks might modify the request, and validating admission webhooks check the request. If either webhook rejects a request, the entire request fails. Advanced features, whether built-in or added on, often require admission controllers as a security precaution and to control what requests are sent to the API server. For more information, see [Using Admission Controllers](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) and [Dynamic Admission Control](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) in the Kubernetes documentation.



 What are the default admission controllers in my cluster? 

Review the order of default admission controllers by cluster version in the [kube-apiserver component reference information](https://cloud.ibm.com/docs/containers?topic=containers-service-settingskube-apiserver).





 Can I create my own admission controllers? 

Yes, see the [Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) documentation for more information.

As noted in the Kubernetes documentation, you can use admission controllers for operations that are otherwise handled by the control plane. As such, take great caution when you configure a custom admission controller. You are responsible for any changes that happen in your cluster because of a custom admission controller.





 What are the best practices for using webhooks? 

Keep in mind the following best practices and considerations when you configure a webhook.
Site map 

Find what you are looking for in the topics that are available for IBM Cloud for Financial Services®.



 Getting started with IBM Cloud for Financial Services 

[Getting started with IBM Cloud for Financial Services](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-aboutabout)



* [IBM Cloud Framework for Financial Services](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-aboutibm-cloud-framework-for-financial-services)



* [Control requirements](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-aboutframework-control-requirements)
* [Framework guidance and reference architectures](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-aboutframework-guidance)



* [Becoming IBM Cloud for Financial Services Validated](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-aboutbecoming-fs-validated)
* [Next steps](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-aboutnext-steps)







 Best practices and requirements 

[Best practices and requirements for software as a service](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-best-practicesbest-practices)



* [1. Use an approved reference architecture](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-best-practicesbest-practices-reference-architecture)
* [2. Use only services that are IBM Cloud for Financial Services Validated](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-best-practicesbest-practices-financial-services-validated-services)
* [3.
For example, if the default access to a particular resource is the Readers of all organizations, and that access is changed to the Admin of Org1, then only the Admin of Org1 will have access to the resource. Because access to certain resources is fundamental to the smooth operation of a channel, it is highly recommended to make access control decisions carefully. If you decide to limit access to a resource, make sure that the access to that resource is added, as needed, for each organization.

You can use the blockchain console to select which ACLs to apply to resources on a channel. See this information under [Creating a channel](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-build-networkibp-console-build-network-channels-create) for instructions on how to configure access control for a channel.





 API authentication 

In order to use the blockchain [APIs](https://cloud.ibm.com/apidocs/blockchain) to create and manage network components, your application needs to be able to authenticate and connect to your network. See this topic on [API Authentication on IBM Cloud](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-apisibp-v2-apis-authentication)







 Best practices for security on the customer Kubernetes cluster 

Audience: Tasks in this section are typically performed by Kubernetes infrastructure managers.

The IBM Blockchain Platform console allows you to deploy and manage nodes on a Kubernetes cluster that you operate. The previous section addressed the security of the console. The following sections detail the best practices you can use to secure your Kubernetes cluster and the nodes of your network:



* [Kubernetes cluster security](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-securityibp-security-Kubernetes-security)
* [Network security](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-securityibp-security-Kubernetes-network)
[Part 2: Set up a Continuous Integration (CI) toolchain](https://cloud.ibm.com/docs/devsecops?topic=devsecops-tutorial-ci-toolchain)Part 2: Set up a Continuous Integration (CI) toolchain

This tutorial is part 2 of a 4-part tutorial series where you learn IBM Cloud® DevSecOps best practices by using a complete reference implementation that is available as a service and powered by IBM Cloud® Continuous Delivery. In part 2 of this tutorial series, you use the toolchain template for continuous integration (CI) with security and compliance-related best practices in DevSecOps. It is preconfigured for continuous deployment with inventory integration, change management with Git Repos and Issue Tracking, evidence collection, and deployment to IBM Cloud Kubernetes Service.

Kubernetes service Continuous Delivery

+1

DevSecOps



* 1 hour
* 2023-06-06



[Part 1: Set up prerequisites](https://cloud.ibm.com/docs/devsecops?topic=devsecops-tutorial-cd-devsecops)Part 1: Set up prerequisites

This tutorial is part 1 of a 4-part tutorial series where you learn IBM Cloud® DevSecOps best practices by using a complete reference implementation that is available as a service and powered by IBM Cloud® Continuous Delivery. In part 1 of this tutorial series, you review some background information and set up prerequisites.

Kubernetes service Continuous Delivery

+1

DevSecOps



* 1 hour
* 2022-07-14



[Provisioning an IBM Cloud virtual server for classic infrastructure](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-sample_infrastructure_config)Provisioning an IBM Cloud virtual server for classic infrastructure

You can provision your virtual server for classic infrastructure by using the IBM Cloud Provider plug-in. Similar to the IBM Cloud virtual server for VPC provision that you provisioned.
Furthermore, k8s.gcr.io registry traffic will be redirected to registry.k8s.io. For more information, see [k8s.gcr.io Redirect to registry.k8s.io - What You Need to Know](https://kubernetes.io/blog/2023/03/10/image-registry-redirect/). Note that IBM Cloud Kubernetes Service has already handled this migration action for all resources provided by IBM. 
 kubelet legacy iptables rules kubelet no longer creates certain legacy iptables rules by default. It is possible that this will cause problems with some third-party components that improperly depended on those rules. For more information, see [Kubernetes’s IPTables Chains Are Not API](https://kubernetes.io/blog/2022/09/07/iptables-chains-not-api/).
Best practices and requirements for software 

These best practices summarize some of the most important technical principles for software providers based on the [controls](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-aboutframework-control-requirements) and implementation guidance of the IBM Cloud Framework for Financial Services. These best practices are not a replacement for the information provided in the [Control Implementation Overview templates](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-aboutcontrol-implementation-overview-templates), which are still the definitive guides to the controls and required evidence for application providers.

If you're a SaaS provider, see [Best practices for software as a service](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-best-practices).



 1. Enable operators to properly configure your application to meet the controls 

Requirement: Enable and organization operating your software to meet the controls of the IBM Cloud Framework for Financial Services.

Purpose & value: An operator is responsible for the IBM Cloud Framework for Financial Services controls for every piece of software they run in their management or workload VPCs, whether running in a virtual server instance or in Red Hat OpenShift on IBM Cloud containers. So, the overarching principle for a software provider is to enable their software to be deployed, configured, and managed in a way that could be Financial Services Validated.

Implementation guidance: Provide clear written instructions for an operator to follow in order to deploy, configure, and manage your software on the IBM Cloud for Financial Services.





 2. Provide account and access management to enable a zero-trust environment 

Requirement: Enable operators to implement a system of zero-trust where account, identity, and access management is based on the principles of separation of duties and least privilege.

Purpose & value: The design of the IBM Cloud for Financial Services is intended to enable a zero-trust model for deployments of the reference architectures. The scope of any one individual operator or administrator is strictly limited to those actions necessary and appropriate to perform their assigned roles.
This tutorial is part 4 of a 4-part tutorial series where you learn IBM Cloud® DevSecOps best practices by using a complete reference implementation that is available as a service and powered by IBM Cloud® Continuous Delivery. In part 4 of this tutorial series, you use the toolchain template for continuous compliance (CC) to ensure that your deployed artifacts and their source repositories are always compliant.

Kubernetes service Continuous Delivery

+1

DevSecOps



* 1 hour
* 2023-05-22



[Part 3: Set up a Continuous Deployment (CD) toolchain](https://cloud.ibm.com/docs/devsecops?topic=devsecops-tutorial-cd-toolchain)Part 3: Set up a Continuous Deployment (CD) toolchain

This tutorial is part 3 of a 4-part tutorial series where you learn IBM Cloud® DevSecOps best practices by using a complete reference implementation that is available as a service and powered by IBM Cloud® Continuous Delivery. In part 3 of this tutorial series, you use the toolchain template for continuous deployment (CD) with security and compliance-related best practices in DevSecOps.

Kubernetes service Continuous Delivery

+1

DevSecOps



* 1 hour
* 2023-05-22



[Part 2: Set up a Continuous Integration (CI) toolchain](https://cloud.ibm.com/docs/devsecops?topic=devsecops-tutorial-ci-toolchain)Part 2: Set up a Continuous Integration (CI) toolchain

This tutorial is part 2 of a 4-part tutorial series where you learn IBM Cloud® DevSecOps best practices by using a complete reference implementation that is available as a service and powered by IBM Cloud® Continuous Delivery. In part 2 of this tutorial series, you use the toolchain template for continuous integration (CI) with security and compliance-related best practices in DevSecOps. It is preconfigured for continuous deployment with inventory integration, change management with Git Repos and Issue Tracking, evidence collection, and deployment to IBM Cloud Kubernetes Service.
Persistent storage IO requests can become a bottleneck in some solutions. 10 IOPS/GB+ is recommended.
* Performance generally scales with CPU allocated to peer nodes. Providing each peer and CouchDB (if used) with the maximum CPU capacity is recommended.
* Use Fabric 2.x so chaincode runs as a separate process.
* Increasing the ordering node sendBufferSize default of 10 can improve ordering service performance (100 is the recommended starting point).
* Check CouchDB logs for warnings such as "The number of documents examined is high in proportion to the number of results returned. Consider adding a more specific index to improve this." Indexes for CouchDB rich queries are essential for performance, and will indicate when too many documents are being scanned (full table scans) for a relatively low number of results.
* For ordering service nodes, use monitoring to determine load and CPU pressure. Generally, 1 CPU/2GB RAM prevents ordering service nodes from becoming a bottleneck.
Kubernetes version 1.26 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.26. Changes include updates to Kubernetes and IBM Cloud Provider components.



 Overview 

In clusters that run version 1.23 or earlier, the IBM Cloud provider version enables Kubernetes APIs and features that are at beta. In version 1.24 and later, most new beta features are disabled by default. Kubernetes alpha features, which are subject to change, are disabled in all versions. For more information, see the [Default service settings for Kubernetes components](https://cloud.ibm.com/docs/containers?topic=containers-service-settings) and the [feature gates](https://cloud.ibm.com/docs/containers?topic=containers-service-settingsfeature-gates) for each version.

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.