vania-janet/multiturn-rag-retrieval-data huggingface dataset:
r006-444bb4bb-4b4b-4b44-4444-b444bbb4b44b inbound ipv4 tcp Ports:Min=22,Max=22 0.0.0.0/0







 Viewing the default VPC security groups in the UI 



1. From the [Security groups for VPC dashboard](https://cloud.ibm.com/vpc-ext/network/securityGroups), find the security groups that are attached to the VPC that your cluster is in. 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>. Click on the security group.

To sort the security groups by the VPC they are attached to, click the Virtual Private Cloud column heading in the table.
2. To view the inbound and outbound rules attached to the security group, click the Rules tab.







 Minimum inbound and outbound requirements 

The following inbound and outbound rules are covered by the default VPC security groups. Note that you can modify the randomly named VPC security group and the cluster-level kube-<cluster-id> security group, but you must make sure that these rules are still met.

Modifying the kube-<vpc-id> security group is not recommended as doing so might cause disruptions in network connectivity between the cluster and the Kubernetes master. Instead, you can [remove the default security group from the VPC ALB or VPE gateway](https://cloud.ibm.com/docs/vpc-infrastructure-cli-plugin?topic=vpc-infrastructure-cli-plugin-vpc-reference&interface=clisecurity-group-target-remove) and [replace it with a security group](https://cloud.ibm.com/docs/vpc-infrastructure-cli-plugin?topic=vpc-infrastructure-cli-plugin-vpc-reference&interface=clisecurity-group-target-add) that you create and manage.



 Required inbound and outbound rules for cluster workers
In this case, even though the VPC ALB deploys to a different subnet in the same VPC, the VPC ALB can still route traffic to your worker nodes on the cluster subnets. To see subnets in all resource groups, run ibmcloud oc subnets --provider vpc-gen2 --vpc-id <vpc> --zone <zone>.

service.kubernetes.io/ibm-load-balancer-cloud-provider-zone
: Annotation to specify a VPC zone that your cluster is attached to. When you specify a zone in this annotation, two processes occur.



1. The VPC ALB is deployed to the same subnet in that zone that your worker nodes are connected to.
2. Only worker nodes in your cluster in this zone are configured to receive traffic from the VPC ALB.



: To see zones, run ibmcloud oc zone ls --provider vpc-gen2.
: To place the load balancer in a specific zone, you must specify this annotation when you create the load balancer. If you later change this annotation to a different zone, the load balancer itself is not moved to the new zone. However, the load balancer is reconfigured to send traffic to only worker nodes in the new zone.
: If the dedicated: edge label is set on worker nodes and you specify this annotation, then only edge nodes in the specified zone are configured to receive traffic. Edge nodes in other zones and non-edge nodes in the specified zone don't receive traffic from the load balancer.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol
: Optional. The protocol type to use for the custom health checks. Choose http, https, or tcp. This annotation overrides the TCP or HTTP configuration set with the externalTrafficPolicy annotation. However, if externalTrafficPolicy is set to Local, the incoming traffic rules still apply.
* 1 hour
* 2023-05-05



[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

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.

VMware Solutions Virtual Private Cloud (VPC)



* 1 hour
* 2023-05-05



[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

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.

Virtual Private Cloud (VPC) VMware Solutions



* 1 hour
* 2023-05-05



[Deploy NSX-T Managers ](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-vpc-bm-vmware-nsx-t-deploy)Deploy NSX-T Managers

In this tutorial, NSX-T will be deployed on the VMware Cluster. This includes deploying NSX-T managers, adding compute manager and adding host and edge transport nodes. This phase is optional, if you plan to use NSX-T for your Virtual Machine networking.

Virtual Private Cloud (VPC) VMware Solutions



* 1 hour
* 2023-05-05
* [Exposing an app by using a VPC load balancer in a VPC cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-loadbalancer-qslb_qs_vpc)



[Exposing apps with load balancers for VPC](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaasvpc-lbaas)



* [Network Load Balancer for VPC](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaasnlb_vpc)
* [Application Load Balancer for VPC](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaaslb_vpc)
* [Setting up a Network Load Balancer for VPC](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaassetup_vpc_nlb)



* [Setting up a public VPC NLB](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaassetup_vpc_nlb_pub)
* [Setting up an NLB using port range](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaasnlb-setup-portrange)
* [Setting up a private VPC NLB](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaassetup_vpc_nlb_priv)
* [Registering a DNS record and TLS certificate](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaasvpc_nlb_dns)
ibmcloud is public-gateways

Example output

ID Name VPC Zone Floating IP Created Status Resource group
26426426-6065-4716-a90b-ac7ed7917c63 test-pgw testvpc(36c8f522-.) us-south-1 169.xx.xxx.xxx(26466378-.) 2019-09-20T16:27:32-05:00 available -
2ba2ba2b-fffa-4b0c-bdca-7970f09f9b8a pgw-73b62bc0-b53a-11e9-9838-f3f4efa02374 team3(ff537d43-.) us-south-2 169.xx.xxx.xxx(2ba9a280-.) 2019-08-02T10:30:29-05:00 available -



* If you already have a public gateway in each zone, note the IDs of the public gateways.
* If you don't have a public gateway in each zone, create a public gateway. Consider naming the public gateway in the format <cluster>-<zone>-gateway. In the output, note the public gateway's ID.



ibmcloud is public-gateway-create <gateway_name> <VPC_ID> <zone>

Example output

ID 26466378-6065-4716-a90b-ac7ed7917c63
Name mycluster-us-south-1-gateway
Floating IP 169.xx.xx.xxx(26466378-6065-4716-a90b-ac7ed7917c63)
Status pending
Created 2019-09-20T16:27:32-05:00
Zone us-south-1
VPC myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf)
Resource group -
4. Using the IDs of the public gateway and the subnet, attach the public gateway to the subnet.
* "c": compute family of profiles (higher on the CPUs), 1 vCPU to 2 GiB of memory ratio
* "m": memory family of profiles (higher on the memory), 1 vCPU to 8 GiB of memory ratio



The second character represents the CPU architecture.



* "z": s390x



The third character represents the generation of the IBM Cloud infrastructure where the profile is provisioned.



* "1": IBM Cloud Virtual Servers for Classic
* "2": IBM Cloud Virtual Servers for VPC



The fourth character is a "e", such as bz2e, which identifies the profile as a secure execution profile. These profiles are available when you select IBM Hyper Protect Container Runtime image as the image for provisioning the virtual server instance. For more information, see [s390x virtual server images](https://cloud.ibm.com/docs/vpc?topic=vpc-vsabout-images). The characters after "-" represents the number of vCPUs and the size of RAM (GiB). For example, "2x8" means that this profile has 2 vCPU and 8 GiB of RAM.

Using “bz2-4x16” as an example, you can know from the name that it is a balanced profile that provides 4 vCPUs of compute and 16 GiB of memory. The profile is deployed on an s390x host and is for the second-generation VPC.





 Viewing instance profiles in the UI 



1. In the IBM Cloud console, go to Menu icon ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/icons/icon_hamburger.svg) > VPC Infrastructure > Compute > Virtual server instances.
2. From the Virtual server instances page, click New instance.
3. You can either select a profile configuration from Popular profiles or click All profiles to view more configurations.







 Viewing instance profiles from the CLI
If you don't have a VPC subnet in the zone, [create a VPC subnet](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-vpc-resources-with-cli-and-api&interface=clicreate-a-subnet-cli). VPC subnets provide IP addresses for your worker nodes and load balancer services in the cluster, so [create a VPC subnet with enough IP addresses](https://cloud.ibm.com/docs/containers?topic=containers-vpc-subnetsvpc_basics_subnets), such as 256. You can't change the number of IP addresses that a VPC subnet has later.

ibmcloud ks subnets --zone <zone> --provider vpc-gen2 --vpc-id <VPC_ID>
4. List the worker pools in your cluster and note their names.

ibmcloud ks worker-pool ls --cluster <cluster_name_or_ID>
5. Add the zone to your worker pool. Repeat this step for each zone that you want to add to your worker pool. If you have multiple worker pools, add the zone to all your worker pools so that your cluster is balanced in all zones. Include the --worker-pool option for each worker pool.

If you want to use different VPC subnets for different worker pools, repeat this command for each subnet and its corresponding worker pools. Any new worker nodes are added to the VPC subnets that you specify, but the VPC subnets for any existing worker nodes are not changed.

ibmcloud ks zone add vpc-gen2 --zone <zone> --subnet-id <subnet_id> --cluster <cluster_name_or_ID> --worker-pool <worker_pool_name>
6. Verify that the zone is added to your cluster. Look for the added zone in the Worker Zones field of the output. Note that the total number of workers in the Workers field has increased as new worker nodes are provisioned in the added zone.
Configuring ACLs and security groups for use with VPN 

Access control lists (ACLs) and security groups can be configured on the VPN gateway's subnet where the VPN gateway is deployed, and other VPC subnets that communicate over the VPN tunnel.

The following diagram illustrates packet flow through VPC network ACLs.

Zoom

![Packet flow through VPC ACLs](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/vpc/images/vpc-traffic-flow.png)

Figure 1. Packet flow through VPC ACLs

Encapsulated, bidirectional traffic flows from the peer gateway (1) to the VPC resources that are a part of the encrypted domain. Unencapsulated packets then leave the VPN subnet and enter the VSI subnet (2). They travel back to the VPN subnet (3), where they then return to the peer gateway (4).

If you configure ACLs or security groups on the VPN gateway's subnet, make sure that the following rules are in place to allow management traffic and VPN tunnel traffic. For more information, see [Setting up network ACLs](https://cloud.ibm.com/docs/vpc?topic=vpc-using-acls) and [About security groups](https://cloud.ibm.com/docs/vpc?topic=vpc-using-security-groups).



Table 1. Inbound and outbound rules on VPN gateway's subnet

 Inbound/Outbound Rules Protocol Source IP Source Port Destination IP Destination Port 

 Inbound All Peer gateway public IP<br><br>[1] N/A VPN gateway's subnet N/A 
 Outbound All VPN gateway's subnet N/A Peer gateway public IP<br><br>[2] N/A 
 Inbound All On-premises, private CIDR N/A VPC CIDR N/A
ACLs consist of inbound and outbound rules that define which ingress and egress is permitted for each VPC subnet.

If your worker nodes must access a public endpoint outside of the cluster, you can enable a public gateway on the VPC subnet that the worker nodes are deployed to. A public gateway can be attached to or detached from a subnet at any time.

The default IP address range for VPC subnets is 10.0.0.0 – 10.255.255.255. For a list of IP address ranges per VPC zone, see the [VPC default address prefixes](https://cloud.ibm.com/docs/vpc?topic=vpc-configuring-address-prefixes).

If you enable classic access when you create your VPC, [classic access default address prefixes](https://cloud.ibm.com/docs/vpc?topic=vpc-setting-up-access-to-classic-infrastructureclassic-access-default-address-prefixes) automatically determine the IP ranges of any subnets that you create. However, the default IP ranges for classic access VPC subnets conflict with the subnets for the IBM Cloud Kubernetes Service control plane. Instead, you must [create the VPC without the automatic default address prefixes, and then create your own address prefixes and subnets within those ranges for your cluster](https://cloud.ibm.com/docs/containers?topic=containers-vpc-subnetsclassic_access_subnets).

Need to create your cluster by using custom-range subnets? Check out this guidance on [custom address prefixes](https://cloud.ibm.com/docs/vpc?topic=vpc-configuring-address-prefixes). If you use custom-range subnets for your worker nodes, you must [ensure that your worker node subnets don't overlap with your cluster's pod subnet](https://cloud.ibm.com/docs/containers?topic=containers-vpc-subnetsvpc-ip-range).
If you add more zones to the cluster, the VPC ALB is not updated to listen for incoming traffic on the new zones. You can route incoming traffic to all backend worker nodes in the cluster across all zones, but you cannot change the VPC subnets that the VPC ALB listens on.



* VPC NLBs listen only on a single VPC subnet in a single zone. They cannot be configured to listen on multiple VPC subnets or to listen on multiple zones. You can specify the single subnet for an NLB to listen on with the service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets or service.kubernetes.io/ibm-load-balancer-cloud-provider-zone annotations.



Versions 1.25 and later

VPC NLBs forward incoming traffic to all worker nodes in the cluster unless you restrict incoming traffic to specific worker nodes with the service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector or service.kubernetes.io/ibm-load-balancer-cloud-provider-zone annotations. To limit traffic to a specific zone, you can use these annotations to specify worker nodes in that zone.
Versions 1.24 and earlier

VPC NLBs forward incoming traffic only to the cluster worker nodes that are in the same zone the ALB listens in.



* Disabling load balancer NodePort allocation is not supported for VPC load balancers.
* VPC ALBs only: Mixed protocol load balancer services are not currently supported in IBM Cloud Kubernetes Service. You cannot specify both TCP and UDP ports in your load balancer definition.
* 1.24 or later: VPC NLBs can be set up with both UDP and TCP on the same VPC LB, but the listening port must be different.
In this case, even though the VPC NLB deploys to a different subnet in the same VPC, the VPC NLB can still route traffic to your worker nodes on the cluster subnets in the same zone. To see subnets in all resource groups, run ibmcloud oc subnets --provider vpc-gen2 --vpc-id <vpc> --zone <zone>.

service.kubernetes.io/ibm-load-balancer-cloud-provider-zone
: Optional: Annotation to specify a VPC zone that your cluster is attached to. The VPC NLB is deployed to the same subnet in that zone that your worker nodes are connected to. Because the VPC NLB is single-zone, only worker nodes in your cluster in this zone are configured to receive traffic.
: To see zones, run ibmcloud oc zone ls --provider vpc-gen2. If you later change this annotation to a different zone, the VPC NLB is not moved to the new zone.
: Note that if you don't specify this annotation or the service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets annotation, the VPC NLB is deployed to the most optimal zone. For example, the VPC NLB is deployed only to zones in which worker nodes exist and are in the Ready state.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp
: Optional: Specify a TCP port to use for TCP health checks in a UDP load balancer. Required for UDP load balancers that have externalTrafficPolicy set to Cluster. For more information on setting port values, see [Configuring TCP health checks for UDP load balancers](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaasvpc_lb_health_udp).

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol
: Optional.
* [Detaching a VPC load balancer from a cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaasvpc_lb_move_detach)
* [Attaching a VPC load balancer to a cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaasvpc_lb_move_attach)



* [Health checks for load balancers](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaasvpc_lb_health)



* [Customizing health checks for VPC load balancers](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaasvpc_lb_health_custom)
* [Enabling TCP health checks for UDP load balancers](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaasvpc_lb_health_udp)



* [Changing load balancer subnets or zones](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaaslbaas_change_subnets)
* [Limitations](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaaslbaas_limitations)



[Classic: About network load balancers (NLBs)](https://cloud.ibm.com/docs/openshift?topic=openshift-loadbalancer-aboutloadbalancer-about)



* [Comparison of basic and DSR load balancing in version 1.0 and 2.0 NLBs](https://cloud.ibm.com/docs/openshift?topic=openshift-loadbalancer-aboutcomparison-lbs)
Verify the assignment was created by listing your assignments.

curl -X GET "https://containers.cloud.ibm.com/global/v2/storage/satellite/getAssignments" -H "accept: application/json" -H "Authorization: Bearer TOKEN"







 Deploying an app that uses Block Storage for VPC 

You can use the ibm-vpc-block-csi-driver to create PVCs that you can use in your cluster workloads.



1. Create a PVC that references a VPC storage class that you created earlier.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
storageClassName: ibmc-vpc-block-5iops-tier
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
2. Create the PVC in your cluster.

oc apply -f pvc.yaml
3. Create a YAML configuration file for a pod that mounts the PVC that you created.

apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment
labels:
app: my-app
spec:
replicas: 1
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- image: ngnix Your containerized app image.
name: my-container
volumeMounts:
- name: my-volume
mountPath: /mount-path
volumes:
- name: my-volume
persistentVolumeClaim:
claimName: my-pvc

Show more
4. Create the pod in your cluster.

oc apply -f deployment.yaml
5. Verify that the pod is deployed. Note that it might take a few minutes for your app to get into a Running state.

oc get pods

NAME READY STATUS RESTARTS AGE
my-deployment 1/1 Running 0 2m58s
* [Creating an instance group template](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-auto-scale-instance-groupcreating-instance-template)
* [Creating an instance group](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-auto-scale-instance-groupcreating-instance-group)
* [Creating scaling policies](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-auto-scale-instance-groupcreating-scaling-policies)
* [FAQs for application load balancers](https://cloud.ibm.com/docs/vpc?topic=vpc-load-balancer-faqs)
* [FAQs for auto scale](https://cloud.ibm.com/docs/vpc?topic=vpc-faqs-auto-scale)
You assign the additional hosts that you previously attached as worker nodes to provide the compute power for the cluster. You can even [register existing Red Hat OpenShift clusters to your location](https://cloud.ibm.com/docs/satellite?topic=satellite-register-openshift-clusters) to use as deployment targets.
3. [Manage your applications](https://cloud.ibm.com/docs/satellite?topic=satellite-cluster-config) with Satellite Config.
4. Create [Satellite cluster storage templates](https://cloud.ibm.com/docs/satellite?topic=satellite-storage-template-ov).
5. Learn more about the [Satellite Link component](https://cloud.ibm.com/docs/satellite?topic=satellite-link-location-cloud) and how you can use endpoints to manage the network traffic between your location and IBM Cloud.



Need help? Check out [Getting support](https://cloud.ibm.com/docs/satellite?topic=satellite-get-help) where you can find information about cloud status, issues, and logging; contacting support; and setting your email notification preferences for IBM Cloud platform-related items.
ibmcloud sat config version create --name <version_name> --config <config_name_or_ID> --file-format yaml --read-config <file_path>



Understanding this command's components

 Component Description 

 --name <version_name> Enter a name for your configuration version. 
 --config <config_name_or_ID> Enter the name or ID of the Satellite configuration that you created earlier. 
 --read-config <file_path> Enter the relative file path to the Kubernetes resource file on your local machine. 



Example output

Creating configuration version...
OK
Configuration Version <version_name> was successfully created with ID ad5ae7a9-4f74-486c-816a-32de98de00df.
2. Create a Subscription for your cluster group to the Satellite configuration. After you create the subscription, Satellite Config automatically downloads the Kubernetes resource file for the version that you specified and starts applying this file across all clusters that belong to the cluster group. This process takes a few minutes to complete. In addition, information about all Kubernetes resources that you create are sent back from your clusters to Satellite Config and can be reviewed in the Satellite [Cluster resources](https://cloud.ibm.com/satellite/resources) dashboard. Review the command options by running ibmcloud sat subscription create.

ibmcloud sat subscription create --group <cluster_group_name> --config <config_name_or_ID> --name <subscription_name> --version <version_name_or_ID>



Understanding this command's components

 Component Description 

 --group <cluster_group_name> Enter the name of the cluster group where you want to deploy your Kubernetes resources. 
 --config <config_name_or_ID> Enter the name or ID of the Satellite configuration that you created earlier. 
 --name <subscription_name> Enter a name for your Satellite subscription.