vania-janet/multiturn-rag-retrieval-data huggingface dataset:
FAQs 



 What locations are available for deploying VPC resources that make up the Spectrum Scale cluster? 

Available regions and zones for deploying VPC resources and a mapping of those to city locations and data centers can be found in [Locations for resource deployment](https://cloud.ibm.com/docs/overview?topic=overview-locations). While any of the available regions can be used, resources are provisioned only in a single availability zone within the selected region.





 What permissions do I need in order to create a cluster using the offering? 

Instructions for setting the appropriate permissions for IBM Cloud services that are used by the offering to create a cluster can be found in [Granting user permissions for VPC resources](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-user-permissions-for-vpc-resources), [Managing user access for Schematics](https://cloud.ibm.com/docs/schematics?topic=schematics-access), [Assigning access to Secrets Manager](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-assign-access), and [Creating trusted profiles](https://cloud.ibm.com/docs/account?topic=account-create-trusted-profile).





 How do I SSH among nodes? 

The IBM Spectrum Scale solution consists of two separate clusters (storage and compute). The SSH key parameter that is provided through Schematics (storage_cluster_key_pair and compute_cluster_key_pair) can be used to log in to the respective cluster nodes. You can log in to any node only through the bastion host by using the following command:

ssh -J ubuntu@<IP_address_bastion_host> vpcuser@<IP-address-of-nodes>

Although all of the nodes of each cluster have passwordless SSH set up among them, due to security constraints, you can't directly log in to a node from one cluster to another cluster.





 How many compute and storage nodes can I deploy in my Spectrum Scale cluster through this offering?
Managing IBM Cloud File Storage for VPC 

When you set up persistent storage in your cluster, you have three main components: the Kubernetes persistent volume claim (PVC) that requests storage, the Kubernetes persistent volume (PV) that is mounted to a pod and described in the PVC, and the file share. Depending on how you created your storage, you might need to delete all three components separately.



 Creating a custom storage class 

Create your own customized storage class with the preferred settings for your File Storage for VPC instance.

To create your own storage class:



1. Review the [Storage class reference](https://cloud.ibm.com/docs/containers?topic=containers-storage-file-vpc-sc-ref) to determine the profile that you want to use for your storage class.

If you want to use a pre-installed storage class as a template, you can get the details of a storage class by using the kubectl get sc <storageclass> -o yaml command.
2. Create a customized storage class configuration file.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: ibmc-vpc-file-custom
provisioner: vpc.file.csi.ibm.io
mountOptions:
- hard
- nfsvers=4.0
- sec=sys
parameters:
profile: "custom-iops" The VPC Storage profile used. /docs/vpc?topic=vpc-block-storage-profiles&interface=uitiers-beta
iops: "400" Default IOPS. User can override from secrets
billingType: "hourly" The default billing policy used. User can override this default
encrypted: "false" By default, all PVC using this class will only be provider managed encrypted. The user can override this default
encryptionKey: "" If encrypted is true, then a user must specify the encryption key used associated KP instance
resourceGroup: "" Use resource group if specified here. else use the one mentioned in storage-secrete-store
For other supported regions, see [Multizone metros for VPC clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zones). If you have a federated ID, include the --sso option.

ibmcloud login -r us-south [-g <resource_group>] [--sso]
2. Create a VPC for your cluster. For more information, see the docs for creating a VPC in the [console](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-a-vpc-using-the-ibm-cloud-console) or [CLI](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-vpc-resources-with-cli-and-api&interface=cli).



1. Create a VPC called myvpc and note the ID in the output. VPCs provide an isolated environment for your workloads to run within the public cloud. You can use the same VPC for multiple clusters, such as if you plan to have different clusters host separate microservices that need to communicate with each other. If you want to separate your clusters, such as for different departments, you can create a VPC for each cluster.

ibmcloud is vpc-create myvpc
2. Create a public gateway and note the ID in the output. In the next step, you attach the public gateway to a VPC subnet, so that your worker nodes can communicate on the public network. Default Red Hat OpenShift components, such as the web console and OperatorHub, require public network access. If you skip this step, you must instead be connected to your VPC private network, such as through a VPN connection, to access the Red Hat OpenShift web console or access your cluster with kubectl commands.

ibmcloud is public-gateway-create gateway-us-south-1 <vpc_ID> us-south-1
3. Create a subnet for your VPC, and note its ID.
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:
addonmanager.kubernetes.io/mode: Reconcile
app: ibm-vpc-block-csi-driver
name: ibm-vpc-block-csi-node
namespace: kube-system
spec:
selector:
matchLabels:
app: ibm-vpc-block-csi-driver
template:
metadata:
labels:
app: ibm-vpc-block-csi-driver
spec:
containers:
- args:
- --v=5
- --csi-address=$(ADDRESS)
- --kubelet-registration-path=$(DRIVER_REGISTRATION_SOCK)
env:
- name: ADDRESS
value: /csi/csi.sock
- name: DRIVER_REGISTRATION_SOCK
value: /var/lib/kubelet/csi-plugins/vpc.block.csi.ibm.io/csi.sock
- name: KUBE_NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
image: quay.io/k8scsi/csi-node-driver-registrar:v1.2.0
lifecycle:
preStop:
exec:
command:
- /bin/sh
- -c
- rm -rf /registration/vpc.block.csi.ibm.io /registration/vpc.block.csi.ibm.io-reg.sock
name: csi-driver-registrar
securityContext:
runAsNonRoot: false
runAsUser: 0
privileged: false
volumeMounts:
* [1 May 2019](https://cloud.ibm.com/docs/containers?topic=containers-containers-relnotescontainers-may0119)



* Assigning infrastructure access











 Tutorials library for Kubernetes Service 

[Tutorials library for Kubernetes Service](https://cloud.ibm.com/docs?tab=tutorials&tags=containers&page=1&pageSize=20)





 Creating a cluster in your Virtual Private Cloud (VPC) 

[Creating a cluster in your Virtual Private Cloud (VPC)](https://cloud.ibm.com/docs/containers?topic=containers-vpc_ks_tutorialvpc_ks_tutorial)



* [Objectives](https://cloud.ibm.com/docs/containers?topic=containers-vpc_ks_tutorialvpc_ks_objectives)
* [Audience](https://cloud.ibm.com/docs/containers?topic=containers-vpc_ks_tutorialvpc_ks_audience)
* [Prerequisites](https://cloud.ibm.com/docs/containers?topic=containers-vpc_ks_tutorialvpc_ks_prereqs)
* [Create a cluster in VPC](https://cloud.ibm.com/docs/containers?topic=containers-vpc_ks_tutorialvpc_ks_create_vpc_cluster)
* [Deploy a privately available app](https://cloud.ibm.com/docs/containers?topic=containers-vpc_ks_tutorialvpc_ks_app)
* [Set up a Load Balancer for VPC to expose your app publicly](https://cloud.ibm.com/docs/containers?topic=containers-vpc_ks_tutorialvpc_ks_vpc_lb)
* [What's next?](https://cloud.ibm.com/docs/containers?topic=containers-vpc_ks_tutorialvpc_ks_next)







 Migrating an app from Cloud Foundry to a cluster
Managing IBM Cloud File Storage for VPC 

When you set up persistent storage in your cluster, you have three main components: the Kubernetes persistent volume claim (PVC) that requests storage, the Kubernetes persistent volume (PV) that is mounted to a pod and described in the PVC, and the file share. Depending on how you created your storage, you might need to delete all three components separately.



 Creating a custom storage class 

Create your own customized storage class with the preferred settings for your File Storage for VPC instance.

To create your own storage class:



1. Review the [Storage class reference](https://cloud.ibm.com/docs/openshift?topic=openshift-storage-file-vpc-sc-ref) to determine the profile that you want to use for your storage class.

If you want to use a pre-installed storage class as a template, you can get the details of a storage class by using the oc get sc <storageclass> -o yaml command.
2. Create a customized storage class configuration file.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: ibmc-vpc-file-custom
provisioner: vpc.file.csi.ibm.io
mountOptions:
- hard
- nfsvers=4.0
- sec=sys
parameters:
profile: "custom-iops" The VPC Storage profile used. /docs/vpc?topic=vpc-block-storage-profiles&interface=uitiers-beta
iops: "400" Default IOPS. User can override from secrets
billingType: "hourly" The default billing policy used. User can override this default
encrypted: "false" By default, all PVC using this class will only be provider managed encrypted. The user can override this default
encryptionKey: "" If encrypted is true, then a user must specify the encryption key used associated KP instance
resourceGroup: "" Use resource group if specified here.
[menu icon](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/icons/icon_hamburger.svg) > VPC Infrastructure > Compute > Placement Groups.
2. Click Create and enter the information in Table 1 on the New placement for VPC page.





Table 2. Fields required to create a placement group

 Field Value 

 Placement group name A unique resource name within the region is required for your placement group. If you don't specify a name, a name is generated and assigned to your placement group. 
 Resource group Select the resource group that contains the account resources and users that you want to be able to access the placement group. For more information about resource groups, see [Managing resource groups](https://cloud.ibm.com/docs/account?topic=account-rgs). 
 Region The region of the placement group. 
 User tags Keywords that are used for profile management. 
 Placement strategy Host spread - All provisioned instances are placed on separate hosts that might be in the same rack.<br><br>Power spread - All provisioned instances are placed on different racks with separate power and network supplies. Each rack also contains dual power supplies from different sources. 







 Creating a placement group from the CLI 

A placement group must be created first before an instance can use it. After a placement group is created, an instance can be attached to it during provisioning.



 Before you begin 



1. Make sure that you download, install, and initialize the following CLI plug-ins. For more information, see [CLI prerequisites](https://cloud.ibm.com/docs/vpc?topic=vpc-set-up-environmentcli-prerequisites-setup).



* IBM Cloud CLI
* The vpc-infrastructure plug-in



2. Have an [IBM Cloud VPC created](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-a-vpc-using-cli).
Resource group name resource_group_name The name of the resource group that contains this cluster. 
 Service instance service_instance The ID of this cluster. You can retrieve this value from the cluster's overview page in the IBM Cloud Console as "Cluster ID" or using the IBM Cloud CLI. 
 Location location Location of the cluster derived from its cloud resource name. 
 Namespace namespace Namespace of the service account that is used to retrieve a Compute Resource token and get an IAM token. 
 Service account name Name of the service account that is used to retrieve a Compute Resource token and get an IAM token. 
 Pod pod The name of the Kubernetes pod that runs the code that wants to retrieve an IAM token. 







 Virtual server for VPC attribute names 



Table 4. Virtual server for VPC attribute names

 IBM Cloud console name CLI and API name Description 

 Resource group ID resource_group_id The ID of the resource group that contains this cluster. You can identify the resource group of a cluster by using its overview page in the IBM Cloud Console. 
 Resource group name resource_group_name The name of the resource group that contains this cluster. 
 Resource ID resource The ID of the virtual server for VPC. 
 Instance group name instance_group_name Name of the instance group, if this virtual server is part of one. 
 Region region Region into which this virtual server is deployed. 
 Subnet subnet_id The subnet ID of the virtual server for VPC, if one is available. 
 VPC ID vpc_id The VPC ID of the virtual server for VPC, if one is available. 
 Zone zone Zone name in which this virtual server is deployed to. 







 IBM Cloud CLI command examples 

The following examples show how you can use the attribute names in the CLI to build trusted profile links and conditions.



 Linking a trusted profile to Kubernetes a cluster 

To link the trusted profile Test to the Kubernetes cluster c0pigdctkkc07fs7pm06 in the account 444aebb0657c7f0f3aae8e7bdc78709a and service account my-service-account in the namespace my-namespace, specify the following command:
VPC clusters can be provisioned using virtual worker nodes on standard infrastructure or dedicated hosts. Free VPC clusters are not supported.





 Can I combine different flavors in a cluster? 

Yes. To add different flavors to your cluster, you must [create another worker pool](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_pool_create). You can't resize existing worker pools to have different compute resources such as CPU or memory.





 How can I change worker node flavors? 

See [updating flavors](https://cloud.ibm.com/docs/containers?topic=containers-updatemachine_type).





 Are the worker nodes encrypted? 

The secondary disk of the worker node is encrypted. For more information, see [Overview of cluster encryption](https://cloud.ibm.com/docs/containers?topic=containers-encryptionencrypt_ov). After you create a worker pool, you might notice that the worker node flavor has .encrypted in the name, such as b3c.4x16.encrypted.





 How do I manage my worker nodes? 

Worker nodes in classic clusters are provisioned into your IBM Cloud account. You can manage your worker nodes by using IBM Cloud Kubernetes Service, but you can also use the [classic infrastructure dashboard](https://cloud.ibm.com/classic/) in the IBM Cloud console to work with your worker node directly.

Unlike classic clusters, the worker nodes of your VPC cluster are not listed in the [VPC infrastructure dashboard](https://cloud.ibm.com/vpc/overview). Instead, you manage your worker nodes with IBM Cloud Kubernetes Service only. However, your worker nodes might be connected to other VPC infrastructure resources, such as VPC subnets or VPC Block Storage. These resources are in the VPC infrastructure dashboard and can be managed separately from there.





 What limitations do I need to be aware of? 

Kubernetes limits the maximum number of worker nodes that you can have in a cluster.
Understanding network basics of VPC clusters 

When you create your cluster, you must choose a networking setup so that certain cluster components can communicate with each other and with networks or services outside of the cluster.



* [Worker-to-worker communication](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_vpc_basicsvpc-worker-worker): All worker nodes must be able to communicate with each other on the private network through VPC subnets.
* [Worker-to-master and user-to-master communication](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_vpc_basicsvpc-workeruser-master): Your worker nodes and your authorized cluster users can communicate with the Kubernetes master securely over virtual private endpoints or cloud service endpoints.
* [Worker communication to other services or networks](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_vpc_basicsvpc-worker-services-onprem): Allow your worker nodes to securely communicate with other IBM Cloud services, such as IBM Cloud® Container Registry, to on-premises networks, to other VPCs, or to classic infrastructure resources.
* [External communication to apps that run on worker nodes](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_vpc_basicsvpc-external-workers): Allow public or private requests into the cluster as well as requests out of the cluster to a public endpoint.





 Worker-to-worker communication using VPC subnets 

Before you create a VPC cluster for the first time, you must [create a VPC subnet](https://cloud.ibm.com/vpc/provision/network) in each zone where you want to deploy worker nodes. A VPC subnet is a specified private IP address range (CIDR block) and configures a group of worker nodes and pods as if they are attached to the same physical wire.

When you create a cluster, you specify an existing VPC subnet for each zone.
* UI
* CLI







 Controlling traffic with VPC security groups 

Virtual Private Cloud

VPC clusters use various security groups to protect cluster components. These security groups are automatically created and attached to cluster workers, load balancers, and cluster-related VPE gateways. You can modify or replace these security groups to meet your specific requirements, however, any modifications must be made according to these guidelines to avoid network connectivity disruptions.



 VPC security groups 

Default behavior
: Virtual Private Cloud security groups filter traffic at the hypervisor level. Security group rules are not applied in a particular order. However, requests to your worker nodes are only permitted if the request matches one of the rules that you specify. When you allow traffic in one direction by creating an inbound or outbound rule, responses are also permitted in the opposite direction. Security groups are additive, meaning that if your worker nodes are attached to more than one security group, all rules included in the security groups are applied to the worker nodes. Newer cluster versions might have more rules in the kube-clusterID security group than older cluster versions. Security group rules are added to improve the security of the service and do not break functionality.

Limitations
: Because the worker nodes of your VPC cluster exist in a service account and aren't 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 the existing security group.

If you modify the default VPC security groups, you must, at minimum, include the required [inbound](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-security-groupmin-outbound-rules-sg-workers) and [outbound](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-security-groupmin-inbound-rules-sg-workers) rules so that your cluster works properly.



 Security groups applied to cluster workers 

Do not modify the rules in thekube-<cluster-ID> security group as doing so might cause disruptions in network connectivity between the workers of the cluster and the control cluster.
[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.

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

In this tutorial, a vSAN cluster is created using the local disks attached the Bare Metal Servers for VPC. This phase is optional, if you use NFS.

![solution tutorial icon](https://cloud.ibm.com/media/docs/images/homepage/solution-tutorial.svg) [Public frontend and private backend in a Virtual Private Cloud](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-vpc-public-app-private-backend)Public frontend and private backend in a Virtual Private Cloud Solution tutorial

This tutorial walks you through creating your own IBM Cloud® Virtual Private Cloud (VPC) with multiple subnets and a virtual server instance (VSI) in each subnet. A VPC is your own, private cloud on shared cloud infrastructure with logical isolation from other virtual networks.

!
Make sure that you use a zone that your worker nodes are connected to. To list VPC zones that your worker nodes use, run ibmcloud ks cluster get --cluster <cluster_name_or_ID> and look at the Worker Zones field in your CLI output. If you don't specify a zone, one of the worker node zones is automatically selected for your Block Storage for VPC instance.

region
: The region of the worker node where you want to attach storage.

tags
: In the parameters, enter a space-separated list of tags to apply to your Block Storage for VPC instance. Tags can help you find instances more easily or group your instances based on common characteristics, such as the app or the environment that it is used for.

iops
: If you entered custom for the profile, enter a value for the IOPs that you want your Block Storage for VPC to use. Refer to the [Block Storage for VPC custom IOPs profile](https://cloud.ibm.com/docs/vpc?topic=vpc-block-storage-profilescustom) table for a list of supported IOPs ranges by volume size.

reclaimPolicy
: Enter the reclaim policy for your storage class. If you want to keep the PV, the physical storage device and your data when you remove the PVC, enter Retain. If you want to delete the PV, the physical storage device and your data when you remove the PVC, enter Delete.

allowVolumeExpansion
: Enter the volume expansion policy for your storage class. If you want to allow volume expansion, enter true. If you don't want to allow volume expansion, enter false.

volumeBindingMode
: Choose if you want to delay the creation of the Block Storage for VPC instance until the first pod that uses this storage is ready to be scheduled. To delay the creation, enter WaitForFirstConsumer. To create the instance when you create the PVC, enter Immediate.
3. Create the customized storage class in your cluster.

kubectl apply -f custom-storageclass.yaml
4. Verify that your storage class is available in the cluster.
Get the Worker Zones and VPCs that your cluster is created in.

ibmcloud ks cluster get -c <cluster>

Example output

...
Worker Zones: us-south-1, us-south-2, us-south-3
Ingress Subdomain: vpc-prod.us-south.containers.appdomain.cloud
Ingress Secret: vpc-prod
Creator: -
Public Service Endpoint URL: https://c2.us-south.containers.cloud.ibm.com:20267
Private Service Endpoint URL: https://c2.private.us-south.containers.cloud.ibm.com:20267
Pull Secrets: enabled in the default namespace
VPCs: ff537d43-a5a4-4b65-9627-17eddfa5237b
...
3. For the worker zones and VPC that you found, ensure that you [enabled a public gateway on the VPC subnets in each worker zone](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-vpc-resources-with-cli-and-api&interface=cliattach-public-gateway-cli).
4. List the public gateways for the subnets. In the output, for the zones and VPC that your cluster is in, note the gateway Floating IP addresses for the subnets. These IP addresses must be added to your allowlist.

ibmcloud is public-gateways

Example output

ID Name Status Floating IP VPC Zone
5d308ea5-9f32-43b3-aaae-194d5723a3e5 pgw-b9d45630-c053-11e9-b2f8-79328ce05e7e available 169.XX.XXX.XX test-vpc us-south-1