vania-janet/multiturn-rag-retrieval-data huggingface dataset:
persistentVolumeClaim:
claimName: my-pvc
Show more
4. Create the deployment in your cluster.

kubectl apply -f deployment.yaml



For more information, see the following links.



* [Adding Block Storage for VPC to apps](https://cloud.ibm.com/docs/containers?topic=containers-vpc-blockvpc-block-add).
* [Storage class reference](https://cloud.ibm.com/docs/containers?topic=containers-vpc-blockvpc-block-reference).
* [Customizing the default storage settings](https://cloud.ibm.com/docs/containers?topic=containers-vpc-blockvpc-customize-default).







 Adding Block Storage for VPC to your apps 

Choose your Block Storage for VPC profile and create a persistent volume claim to dynamically provision Block Storage for VPC for your cluster. Dynamic provisioning automatically creates the matching persistent volume and orders the physical storage device in your IBM Cloud account.



1. Decide on the [Block Storage for VPC profile](https://cloud.ibm.com/docs/vpc?topic=vpc-block-storage-profiles) that best meets the capacity and performance requirements that you want.
2. Select the corresponding storage class for your Block Storage for VPC profile.

All IBM pre-defined storage classes set up Block Storage for VPC with an ext4 file system by default. If you want to use a different file system, such as xfs or ext3, [create a customized storage class](https://cloud.ibm.com/docs/containers?topic=containers-vpc-blockvpc-customize-storage-class).



* 10 IOPS/GB: ibmc-vpc-block-10iops-tier or ibmc-vpc-block-retain-10iops-tier
* 5 IOPS/GB: ibmc-vpc-block-5iops-tier or ibmc-vpc-block-retain-5iops-tier
VPC clusters: VPC security groups are applied to the network interface of a single virtual server to filter traffic at the hypervisor level. You can add inbound and outbound rules to the default security group for your cluster to manage inbound and outbound traffic to a VPC cluster. For more information about the security groups, including the default settings, see [Controlling traffic with VPC security groups](https://cloud.ibm.com/docs/containers?topic=containers-vpc-security-group&interface=ui).

Because the worker nodes of your VPC cluster exist in a service account and are not listed in the VPC infrastructure dashboard, you can't create a security group and apply it to your worker node instances. You can only modify existing security groups that are created for you.





 How can I do TLS termination with LoadBalancer and Ingress services? 

The Ingress service offers TLS termination at two points in the traffic flow:



* Decrypt package upon arrival: By default, the Ingress ALB load balances HTTP network traffic to the apps in your cluster. To also load balance incoming HTTPS connections, you can configure the ALB to decrypt the network traffic and forward the decrypted request to the apps that are exposed in your cluster. If you use the IBM-provided Ingress subdomain, you can use the IBM-provided TLS certificate. If you use a custom domain, you can use your own TLS certificate to manage TLS termination.
* [Re-encrypt package before you forward it to upstream apps](https://cloud.ibm.com/docs/containers?topic=containers-comm-ingress-annotationsssl-services-support): The ALB decrypts HTTPS requests before forwarding traffic to your apps. If you have apps that require HTTPS and need traffic to be encrypted before it is forwarded to those upstream apps, you can use the ssl-services annotation. If your upstream apps can handle TLS, you can optionally provide a certificate that is contained in a one-way or mutual-authentication TLS secret.









 Persistent storage 

Review supported options for encrypting and protecting your data on persistent storage in IBM Cloud.
* UI
* CLI
* Terraform







 Creating VPC clusters 

Virtual Private Cloud

Use the IBM Cloud CLI or the IBM Cloud console to create a standard VPC cluster, and customize your cluster to meet the high availability and security requirements of your apps.

Do not delete the subnets that you attach 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 load balancers that use IP addresses from the subnet might experience issues, and you might be unable to create new load balancers.



 Prerequisites and notes 



* If worker nodes must access public endpoints, attach a public gateway to each subnet in your VPC.
* A public network gateway is required when you want your cluster to access public endpoints, such as a public URL of another app or an IBM Cloud service that supports public cloud service endpoints only. Make sure to review the [VPC networking basics](https://cloud.ibm.com/docs/containers?topic=containers-plan_vpc_basics) to understand when a public network gateway is required and how you can set up your cluster to limit public access to one or more subnets only.
* Before you can use KMS encryption, you must create a KMS instance and set up the required service authorization in IAM. For more information, see [Managing encryption for the worker nodes in your cluster](https://cloud.ibm.com/docs/containers?topic=containers-encryptionworker-encryption).
* By default, your cluster is provisioned with a VPC security group and a cluster-level security group. If you want to attach additional security groups or change which default security groups are applied when you create the cluster, you must [create your VPC cluster in the CLI](https://cloud.ibm.com/docs/containers?topic=containers-cluster-create-vpc-gen2&interface=uicluster_vpcg2_cli).







 Creating a VPC cluster in the console 



1.
[Network setup for a VPC cluster that runs internet-facing app workloads.](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/vpc_no_pgw.png)

Figure 1. Network setup for a VPC cluster that runs internet-facing app workloads





 Worker-to-worker communication 

To achieve this setup, you create VPC subnets in each zone where you want to deploy worker nodes. No public gateways are required for these subnets. Then, you create a VPC cluster that uses these VPC subnets.





 Worker-to-master and user-to-master communication 

You can choose to allow worker-to-master and user-to-master communication over the public and private networks, or over the private network only.



* Public and private cloud service endpoints: Communication between worker nodes and master is established over the private network through the private cloud service endpoint. By default, all calls to the master that are initiated by authorized cluster users are routed through the public cloud service endpoint.
* Private service endpoint only: Communication to master from both worker nodes and cluster users is established over the private network through the private cloud service endpoint. Cluster users must either be in your VPC network or connect through a [VPC VPN connection](https://cloud.ibm.com/docs/containers?topic=containers-vpc-vpnaas).







 Worker communication to other services or networks 

If your app workload requires other IBM Cloud services, your worker nodes can automatically, securely communicate with IBM Cloud services that support private cloud service endpoints over the private VPC network.





 External communication to apps that run on worker nodes 

After you test your app, you can expose it to the internet by creating a public Kubernetes LoadBalancer service or using the default public Ingress application load balancers (ALBs). The VPC load balancer that is automatically created in your VPC outside of your cluster when you use one of these services routes traffic to your app.
<br> <br>Resources <br><br><br><br> * ibm_kms_key<br> * ibm_kp_key<br><br><br> [View code snippet](https://github.com/IBM-Cloud/terraform-provider-ibm/tree/master/examples/ibm-kms) 







 Kubernetes templates 



 Name Description and resources Code 

 vpc-classic-cluster Create an IBM Cloud Kubernetes Service cluster in a Virtual Private Cloud (VPC) for Generation 1 compute with worker nodes in a default worker pool that you spread across two zones. You can provision an IBM Cloud Object Storage service, and bind this service to the cluster. <br> <br>Resources <br><br><br><br> * ibm_is_vpc<br> * ibm_is_subnet<br> * ibm_container_vpc_cluster<br> * ibm_container_vpc_worker_pool<br> * ibm_resource_instance<br> * ibm_container_bind_service<br><br><br> [View code snippet](https://github.com/IBM-Cloud/terraform-provider-ibm/tree/master/examples/ibm-cluster/vpc-classic-cluster) 
 vpc-Gen2-cluster Create an IBM Cloud Kubernetes Service cluster in a Virtual Private Cloud (VPC) for Generation 2 compute with worker nodes in a default worker pool that you spread across two zones. Also, you provision an IBM Cloud Object Storage service, and bind this service to the cluster.
* Container Registry plugin (container-registry),
* dev plugin,



* a Docker engine,
* kubectl to interact with Kubernetes clusters,
* git to clone source code repository.



You will find instructions to download and install these tools for your operating environment in the [Getting started with solution tutorials](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-tutorials) guide.

In addition: A minimal cluster with one (1) zone, one (1) worker node and the smallest available size (Flavor) is sufficient for this tutorial.

Open the [Kubernetes clusters](https://cloud.ibm.com/kubernetes/clusters) and click Create cluster. See the documentation referenced below for more details based on the cluster type. Summary:



* Click Standard tier cluster
* For Kubernetes on VPC infrastructure see reference documentation [Creating VPC clusters](https://cloud.ibm.com/docs/containers?topic=containers-cluster-create-vpc-gen2&interface=ui).



* Click Create VPC:



* Enter a name for the VPC.
* Chose the same resource group as the cluster.
* Click Create.



* Attach a Public Gateway to each of the subnets that you create:



* Navigate to the [Virtual private clouds](https://cloud.ibm.com/vpc-ext/network/vpcs).
* Click the previously created VPC used for the cluster.
* Scroll down to subnets section and click a subnet.
* In the Public Gateway section, click Detached to change the state to Attached.
* Click the browser back button to return to the VPC details page.
* Repeat the previous three steps to attach a public gateway to each subnet.





* For Kubernetes on Classic infrastructure see reference documentation [Creating classic cluster](https://cloud.ibm.com/docs/containers?topic=containers-cluster-create-classic&interface=ui).
* Choose a resource group.
* Uncheck all zones except one.
* Classic clusters only: Super User role or the [minimum required permissions](https://cloud.ibm.com/docs/containers?topic=containers-classic-roles) for classic infrastructure.
* VPC clusters only: Administrator platform access role for [VPC Infrastructure](https://cloud.ibm.com/docs/vpc?topic=vpc-iam-getting-started).



User that creates the cluster
: In addition to the API key, each individual user must have the following permissions to create a cluster.
: 

* Administrator platform access role for Kubernetes Service in the console (containers-kubernetes in the API or CLI). If your access is scoped to a resource group or region, you must also have the Viewer platform access role at the Account level to view the account's VLANs.
* Administrator platform access role for Container Registry in the console (container-registry in the API or CLI) at the Account level.
* Viewer platform access role to IAM Identity Service for account management access.
* Viewer platform access role for the resource group access.



More information about assigning permissions
: 

* To understand how access works and how to assign users roles in IBM Cloud IAM, see [Setting up access to your cluster](https://cloud.ibm.com/docs/containers?topic=containers-access-overviewaccess-checklist).
* To create clusters, see [Preparing to create clusters at the account level](https://cloud.ibm.com/docs/containers?topic=containers-clusters&interface=ui).
* For permissions that you might set up for different types of users such as auditors, see [Example use cases and roles](https://cloud.ibm.com/docs/containers?topic=containers-usersexample-iam).
[solution tutorial icon](https://cloud.ibm.com/media/docs/images/homepage/solution-tutorial.svg) [Provision IBM Cloud VPC Subnets and configure Distributed Virtual Switch Portgroups for VMs](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-vpc-bm-vmware-newvm)Provision IBM Cloud VPC Subnets and configure Distributed Virtual Switch Portgroups for VMs Solution tutorial

This tutorial presents a simple example to deploy a VMware virtual machine running on VMware cluster and attached to IBM Cloud VPC subnet using a VLAN interface and allow the virtual machine to vMotion between hosts.

![solution tutorial icon](https://cloud.ibm.com/media/docs/images/homepage/solution-tutorial.svg) [Provision NFS storage and attach to cluster](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-vpc-bm-vmware-nfs)Provision NFS storage and attach to cluster Solution tutorial

In this tutorial, an NFS file share is created in IBM Cloud VPC and it is attached to a VMware cluster as a Datastore. This phase is optional, if you use vSAN as your preferred storage option.

![solution tutorial icon](https://cloud.ibm.com/media/docs/images/homepage/solution-tutorial.svg) [Provision vCenter Appliance](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-vpc-bm-vmware-vcenter)Provision vCenter Appliance Solution tutorial

In this tutorial, you will deploy a vCenter for a VMware Deployment in IBM Cloud VPC and a floating VLAN interface for it.

!
This delegation policy is required so that the VPC infrastructure can encrypt the boot volume of the worker nodes in the IBM-managed service account with your customer-provided root key of the KMS provider.
3. Create a cluster or worker pool that includes the account where the KMS instance resides, the KMS provider instance and root key. Each worker node in the worker pool then is encrypted by the KMS provider that you manage. Each worker pool in your cluster can use the same KMS instance and root key, the same KMS instance with different root keys, or different instances.



* Creating a cluster: Only the default worker pool's nodes are encrypted. After you create the cluster, if you create more worker pools, you must enable encryption in each pool separately. For more information, see [Creating clusters](https://cloud.ibm.com/docs/containers?topic=containers-cluster-create-vpc-gen2&interface=ui) or the [CLI reference documentation](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicli_cluster-create-vpc-gen2).



* UI: From the [cluster creation page](https://cloud.ibm.com/kubernetes/catalog/create), make sure to include the KMS instance, Root key and optionally, if the KMS instance resides in a different account, the KMS account fields.
* CLI: Make sure to include the --kms-instance-id, --crk fields and also the optional--kms-account-id field if the KMS instance resides in an account different from the clusters account, such as in the following VPC example.
(https://cloud.ibm.com/docs/openshift?topic=openshift-strategyenv_flavors)
* [Do I use multiple clusters, or just add more workers to an existing cluster?](https://cloud.ibm.com/docs/openshift?topic=openshift-strategyenv_multicluster)
* [How can I set up my resources within the cluster?](https://cloud.ibm.com/docs/openshift?topic=openshift-strategyenv_resources)
* [How can I keep my cluster in a supported state?](https://cloud.ibm.com/docs/openshift?topic=openshift-strategyupdating_kube)



* [Making your resources highly available](https://cloud.ibm.com/docs/openshift?topic=openshift-strategykube_ha)



[Planning your cluster network setup](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_clustersplan_clusters)

[Understanding network basics of VPC clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_vpc_basicsplan_vpc_basics)



* [Worker-to-worker communication using VPC subnets](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_vpc_basicsvpc-worker-worker)
* [Worker-to-master and user-to-master communication using Virtual private endpoints or cloud service endpoints](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_vpc_basicsvpc-workeruser-master)
* [Worker-to-master communication in VPC clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_vpc_basicsworker-to-master-comms)
[Persistent VPC load balancers](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaasvpc_lb_persist) can be detached from one VPC cluster and then attached to another. The new cluster must be within the same VPC as the original cluster.



 Detaching a VPC load balancer from a cluster 

VPC load balancers are linked to the Kubernetes LoadBalancer service definition that they were created with. To detach a persistent VPC load balancer from a cluster, you must break the link with the LoadBalancer service by [renaming the VPC load balancer](https://cloud.ibm.com/docs/vpc-infrastructure-cli-plugin?topic=vpc-infrastructure-cli-plugin-vpc-referenceload-balancer-update), or by removing the service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name annotation from the original LoadBalancer service definition. You can also detach a persistent VPC load balancer from a cluster by [deleting the cluster](https://cloud.ibm.com/docs/containers?topic=containers-remove).

If you remove the annotation, the original LoadBalancer service reverts and creates a non-persistent VPC load balancer in the original cluster. This non-persistent VPC load balancer follows the kube-<cluster_ID>-<kubernetes_lb_service_UID> naming convention.





 Attaching a VPC load balancer to a cluster 

After a persistent VPC load balancer is detached from a cluster, you can attach to a different cluster by creating a new Kubernetes LoadBalancer service definition that references the VPC load balancer, or by updating an existing Kubernetes LoadBalancer service that exists on the new cluster.
<br>For more information, see [Getting started with SSH keys](https://cloud.ibm.com/docs/vpc?topic=vpc-ssh-keys). 
 Placement groups ibmcloud is placement-groups [List all placement groups](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-referenceplacement-groups-list) 



Use the following commands to determine the required information for creating a new instance template.



1. List the IBM Cloud VPCs that are associated with your account.

ibmcloud is vpcs

For this example, you see a response similar to the following output.

ID Name Status Classic access Default network ACL Default security group Resource group
r006-0d37163a-701d-4ad6-9ece-a3e34cf28935 cdl available false acl-test-1 pedicure-budding-providing-excluded Default
r006-212def4b-93f0-4b9a-a331-94178b99d474 cli-test-1 available false surprise-pacifier-cubicle-demystify foyer-alongside-rug-zen Default

If you don't have one available, you can create an IBM Cloud VPC by using the ibmcloud is vpc-create command. For more information about creating an IBM Cloud VPC, see [IBM Cloud VPC CLI reference](https://cloud.ibm.com/docs/vpc?topic=vpc-infrastructure-cli-plugin-vpc-referencevpcs).
2. List the regions associated with your account.

ibmcloud is regions

For this example, you see a response similar to the following output.

Name Endpoint Status
us-south /v1/regions/us-south available
3. List the zones associated with the region.

ibmcloud is zones us-south

For this example, you see a response similar to the following output.

Name Region Status
us-south-1 us-south available
us-south-3 us-south available
4.
Red Hat OpenShift on IBM Cloud security group kube-<vpc-id> <br><br> * Automatically created and attached to any cluster-related VPE gateways in the VPC.<br> * Automatically created and attached to each VPC ALB that is created in the VPC.<br> * Allows traffic necessary for the cluster infrastructure to function.<br><br><br> 









 Viewing VPC security groups in the CLI 

Follow the steps to view details about the VPC security groups.



1. List your clusters and note the ID of the cluster that you are working in.

To check what VPC a cluster is in, run ibmcloud oc cluster get --cluster <cluster_name_or_id> and check the VPC ID in the output.

ibmcloud oc cluster ls --provider vpc-gen2
2. List the security groups attached to the VPC that your cluster is in. The VPC security group is assigned a randomly generated name, such as trench-hexagon-matriarch-flower. The VPC cluster security group is named in the format of kube-<cluster-ID>. The Red Hat OpenShift on IBM Cloud security group is named in the format of kube-<vpc-ID>.

ibmcloud is sgs | grep <vpc_name>

Example output.

ID Name Rules Network interfaces VPC Resource group

r006-111aa1aa-1a1a-1a11-1111-a111aaa1a11a trench-hexagon-matriarch-flower 4 0 my-vpc default
r006-222aa2aa-2a2a-2a22-2222-a222aaa2a22a kube-a111a11a11aa1aa11a11 4 0 my-vpc default
r006-333aa3aa-3a3a-3a33-3333-a333aaa3a33a kube-r006-111a11aa-aaa1-1a1a-aa11-1a1a111aa11 4 0 my-vpc default
3. Get the details of a security group.
Enabling Flow Logs for VPC cluster components 

Virtual Private Cloud

You can configure IBM Cloud Flow Logs for VPC to gather information about the traffic entering or leaving your VPC cluster worker nodes. Flow logs are stored in an IBM Cloud Object Storage instance and can be used for troubleshooting purposes, adhering to compliance regulations, and more. For more information about Flow Logs for VPC, see [Flow logs use cases](https://cloud.ibm.com/docs/vpc?topic=vpc-flow-logs&interface=uiflow-logs-use-cases).

When you use Flow Logs for VPC with a Kubernetes Service VPC cluster, you can enable flow logs at the VPC level, or at the VPC subnet or VPC load balancer level. You cannot specify which worker nodes to gather flow logs for. However, you can review the flow log output to identify information that is specific to the worker nodes you want to investigate.



 Configuring a flow log collector 

To configure flow logs at the VPC, VPC subnet, or VPC load balancer level, see [Creating a flow log collector](https://cloud.ibm.com/docs/vpc?topic=vpc-ordering-flow-log-collector) in the VPC documentation.

To enable flow logs, you must have an IBM Cloud Object Storage instance with a single-region bucket that is in the same region as the VPC resource you are monitoring.





 Viewing worker node flow logs 

Your Flow Logs for VPC gathers information from the VPC, VPC subnet, or VPC load balancer level. However, you can use the flow logs to gather information that is specific to your worker nodes. Separate flow log files are created for ingress and egress traffic.



1. In the CLI, find the ibm-cloud.kubernetes.io/instance-id label value for the worker node.

kubectl describe node <worker_node_ip> | grep instance-id

Example output.
- apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
annotations:
version: 2.0.2_285
labels:
addonmanager.kubernetes.io/mode: Reconcile
app: ibm-vpc-block-csi-driver
name: vpc-block-external-attacher-role
rules:
- apiGroups:
- ""
resources:
- persistentvolumes
verbs:
- get
- list
- watch
- update
- patch
- apiGroups:
- ""
resources:
- nodes
verbs:
- get
- list
- watch
- apiGroups:
- csi.storage.k8s.io
resources:
- csinodeinfos
verbs:
- get
- list
- watch
- apiGroups:
- storage.k8s.io
resources:
- volumeattachments
verbs:
- get
- list
- watch
- update
- patch
- apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
annotations:
version: 2.0.2_285
labels:
addonmanager.kubernetes.io/mode: Reconcile
app: ibm-vpc-block-csi-driver
name: vpc-block-external-attacher-binding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: vpc-block-external-attacher-role
subjects:
- kind: ServiceAccount
name: ibm-vpc-block-controller-sa
namespace: kube-system
- apiVersion: apps/v1
kind: DaemonSet
metadata:
annotations:
version: 2.0.2_285
labels: