vania-janet/multiturn-rag-retrieval-data huggingface dataset:
The ESG is configured with a source NAT rule (SNAT) to allow outbound traffic, which enables internet connectivity to download the Red Hat OpenShift prerequisites and to connect to GitHub and Red Hat®. Alternatively, you can use a web-proxy for internet connectivity. The ESG is also configured to provide access to DNS and NTP services within the IBM Cloud® environment.

The ESG is also configured to use the load balancer capability, thus reducing the need for HAProxy nodes. The load balancers are configured for the apps wildcard DNS URL and the API / API-INT DNS Records. The apps DNS record load balancers to the worker nodes provisioned, while the api and api-int DNS records are load balanced against the control-plane nodes.

Red Hat OpenShift 4.1 installation on the VMware platform requires a capability to download their ignition files to install and configure the RHCOS bootstrap / control-plane and worker nodes. The ESG is configured to provide DHCP and DHCP relay services for the OpenShift logical switch / VXLAN defined.





 NSX Edge specifications 

The first component that is configured within the vCenter Server with Red Hat OpenShift is a pair of NSX Edge virtual machines. The NSX Edge virtual machines are configured as an active-passive pair of X-Large NSX Edge devices.

The Quad-Large NSX Edge was chosen and as part of the configuration process, the NSX Edge is connected to the IBM Cloud public and private VLAN.



Table 2. NSX Edge specifications

 Component Configuration 

 CPU 6 vCPU 
 RAM 8 GB 
 Disk 4.5 GB VMDK resident on shared storage with 4 GB swap 



Because the NSX Edges are configured as active/passive in either the internal or dedicated deployment, vSphere® Distributed Resource Scheduler (DRS) anti-affinity rules must be created by the user to ensure that NSX Edges do not run on the same host as their respective peer appliance.



Table 3. vSphere Distributed Resource Scheduler rules

 Field Value 

 Name NSX Edge OpenShift 
 Type Separate VMs
oc apply -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.2/samples/bookinfo/platform/kube/bookinfo.yaml

The bookinfo.yaml file is annotated sidecar.istio.io/inject: "true" to enable automatic injection of the Istio sidecar for Red Hat OpenShift Service Mesh. So, these pods will also include an Envoy sidecar as they are started in the cluster.

An installation of Red Hat OpenShift Service Mesh differs from upstream Istio community installations in multiple ways. Refer [this link](https://docs.openshift.com/container-platform/4.12/service_mesh/v2x/ossm-vs-community.html) comparing Service Mesh and Istio. By default, Istio injects the sidecar if you have labeled the project istio-injection=enabled. Red Hat OpenShift Service Mesh handles this differently and requires you to opt in to having the sidecar automatically injected to a deployment, so you are not required to label the project. This avoids injecting a sidecar if it is not wanted (for example, in build or deploy pods).
3. Verify that the pods are up and running.

oc get pods

Sample output:

NAME READY STATUS RESTARTS AGE
details-v1-789c5f58f4-9twtw 2/2 Running 0 4m12s
productpage-v1-856c8cc5d8-xcx2q 2/2 Running 0 4m11s
ratings-v1-5786768978-tr8z9 2/2 Running 0 4m12s
reviews-v1-5874566865-mxfgm 2/2 Running 0 4m12s
reviews-v2-86865fc7d9-mf6t4 2/2 Running 0 4m12s
reviews-v3-8d4cbbbbf-rfjcz 2/2 Running 0 4m12s

Note that each bookinfo pods has 2 containers in it.
DevOps operator [Operator platform access role for a cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-iam-platform-access-roles), [Writer service access role not scoped to a namespace (for the whole cluster)](https://cloud.ibm.com/docs/openshift?topic=openshift-iam-service-access-roles), [Cloud Foundry developer space role](https://cloud.ibm.com/docs/openshift?topic=openshift-cloud-foundry-roles). 
 Operator or site reliability engineer [Administrator platform access role for a cluster, region, or resource group](https://cloud.ibm.com/docs/openshift?topic=openshift-iam-platform-access-roles), [Reader service access role for a cluster or region](https://cloud.ibm.com/docs/openshift?topic=openshift-iam-service-access-roles) or [Manager service access role for all cluster namespaces](https://cloud.ibm.com/docs/openshift?topic=openshift-iam-service-access-roles) to be able to use kubectl top nodes,pods commands. 







 Where can I find a list of security bulletins that affect my cluster? 

If vulnerabilities are found in Red Hat OpenShift, Red Hat OpenShift releases CVEs in security bulletins to inform users and to describe the actions that users must take to remediate the vulnerability. Red Hat OpenShift security bulletins that affect Red Hat OpenShift on IBM Cloud users or the IBM Cloud platform are published in the [IBM Cloud security bulletin](https://cloud.ibm.com/status?component=containers-kubernetes&selected=security).

Some CVEs require the latest patch update for a version that you can install as part of the regular [cluster update process](https://cloud.ibm.com/docs/containers?topic=containers-updateupdate) in Red Hat OpenShift on IBM Cloud. Make sure to apply security patches in time to protect your cluster from malicious attacks.
IBM Cloud Controller Manager v1.17.12-1 v1.18.9-2 Updated to support the Kubernetes 1.18.9 release and to use calicoctl version 3.13.4. Updated network load balancer (NLB) events to use the latest IBM Cloud troubleshooting documentation. For VPC load balancers, the service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol" annotation was added to preserve the source IP address of requests to apps in your cluster. 
 IBM Cloud RBAC Operator 4b47693 31c794a Updated to use Go version 1.15.2. 
 Key Management Service provider v2.0.4 v2.1.0 Updated to use the key management service (KMS) provider secret to identify when a [Key Protect](https://cloud.ibm.com/docs/openshift?topic=openshift-encryptionkeyprotect) key is enabled and disabled so that encryption and decryption requests are updated accordingly. 
 Load balancer and load balancer monitor for IBM Cloud Provider 208 234 Improved startup performance of version 2.0 private network load balancers (NLBs). Updated to use Go version 1.15.2. 
 Red Hat OpenShift Control Plane Operator v4.4.0-20200821 v4.5.0-20201009 See the [Red Hat OpenShift on IBM Cloud toolkit release notes](https://github.com/openshift/ibm-roks-toolkit/releases/tag/v4.5.0+20201009). 
 Red Hat OpenShift 4.4.20 4.5.13 See the [Red Hat OpenShift release notes](https://docs.openshift.com/container-platform/4.5/release_notes/ocp-4-5-release-notes.htmlocp-4-5-13). 
 Red Hat OpenShift configuration N/A N/A New version 4.5 clusters that run on the VPC infrastructure provider and use IBM Cloud Object Storage now proxy container image traffic through the internal registry pods directly to the Object Storage endpoints.
: Patch updates are available for Red Hat OpenShift [3.11.146_1525_openshift](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_311311146_1525).





 1 October 2019 

End of service of IBM Log Analysis and IBM Cloud Monitoring
: Removed steps for using IBM Log Analysis and IBM Cloud Monitoring to work with cluster logs and metrics. You can collect logs and metrics for your cluster by setting up [IBM Log Analysis](https://cloud.ibm.com/docs/containers?topic=containers-healthlogging) and [IBM Cloud Monitoring](https://cloud.ibm.com/docs/monitoring?topic=monitoring-kubernetes_clusterkubernetes_cluster) instead.

Red Hat OpenShift options
: To help you decide whether to use built-in Red Hat OpenShift capabilities or integration with IBM Cloud services, the following topics are added.



* [Choosing an image registry solution](https://cloud.ibm.com/docs/openshift?topic=openshift-registryopenshift_registry_options)
* [Choosing among load balancing solutions](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_network_planningload-balancing-comparison) like router or Ingress
* [Understanding options for logging and monitoring](https://cloud.ibm.com/docs/openshift?topic=openshift-healthoc_logmet_options)



New! Single zone location for Red Hat OpenShift clusters
: The following locations are now supported. For more locations, see [Single and multizone locations in Red Hat OpenShift on IBM Cloud](https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zones).



* Oslo, Norway
* San Jose, California, US









 September 2019 



 24 September 2019 

CLI change log
If you plan to connect your cluster to on-premises networks through IBM Cloud Direct Link or a VPN service, you can avoid subnet conflicts by specifying a custom subnet CIDR that provides the private IP addresses for your services. The subnet must be specified in CIDR format with a size of at least /24, which allows a maximum of 255 services in the cluster, or larger. The subnet that you choose must be within one of the following ranges.



* 172.17.0.0 - 172.17.255.255
* 172.21.0.0 - 172.31.255.255
* 192.168.0.0 - 192.168.254.255
* 198.18.0.0 - 198.19.255.255



: Note that the pod and service subnets can't overlap.

--entitlement cloud_pak
: Include this option only if you use this cluster with an [IBM Cloud Pak](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_cloud_paks) that has a Red Hat OpenShift entitlement. When you specify the number of workers (--workers) and flavor (--flavor), make sure to specify only the number and size of worker nodes that you are entitled to use in [IBM Passport Advantage](https://www.ibm.com/software/passportadvantage/index.html). After your cluster is created, you are not charged the Red Hat OpenShift license fee for the entitled worker nodes in the default worker pool. Do not exceed your entitlement. Keep in mind that your OpenShift Container Platform entitlements can be used with other cloud providers or in other environments. To avoid billing issues later, make sure that you use only what you are entitled to use. For example, you might have an entitlement for the OCP licenses for two worker nodes of 4 CPU and 16 GB memory, and you create this worker pool with two worker nodes of 4 CPU and 16 GB memory. You used your entire entitlement, and you can't use the same entitlement for other worker pools, cloud providers, or environments.
: To get started, see the following topics:



* [Getting started with IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-started).
* [Importing images from IBM Cloud Container Registry](https://cloud.ibm.com/docs/openshift?topic=openshift-registryimagestream_registry) into the internal registry image stream.
* [Using IBM Cloud Container Registry](https://cloud.ibm.com/docs/openshift?topic=openshift-registryopenshift_iccr).



Public registry
: Public registries such as Docker Hub are a way to share images across teams, companies, clusters, or cloud providers. Some public registries might also offer a private registry component. Use cases:



* Pushing and pulling images on the public network.
* Quick testing of a container across cloud providers.
* Don't need enterprise-grade features such as vulnerability scanning or access management.



: For more information, see the public registry's documentation, such as [Quay](https://quay.io/) or [Docker Hub](https://hub.docker.com/).





 Storing images in the internal registries 

Red Hat OpenShift clusters have an internal registry by default. The images in the internal registry are backed up, but vary depending on the infrastructure provider of your Red Hat OpenShift on IBM Cloud cluster.

Classic clusters
: Your Red Hat OpenShift cluster is set up by default with an internal registry that uses classic IBM Cloud File Storage for Classic as the backing storage. When you delete the cluster, the internal registry and its images are also deleted. If you want to persist your images, consider using a private registry such as IBM Cloud Container Registry, backing up your images to persistent storage such as Object Storage, or creating a separate, stand-alone Red Hat OpenShift container registry (OCR) cluster. For more information, see the [Red Hat OpenShift docs](https://docs.openshift.com/container-platform/4.11/registry/index.html).

VPC clusters
To set up virtualization, your Bare Metal Server must meet the following requirements.



* Must support virtualization technology.



* For Intel CPUs, support for virtualization is referred to as Intel VT or VT-x.
* For AMD CPUs, support for virtualization is referred to as AMD Virtualization or AMD-V.



* Must have a minimum of minimum of 8 cores and 32 GB RAM, plus any additional cores that you need for your vCPU overhead. For more information, see [CPU overhead](https://docs.openshift.com/container-platform/4.11/virt/install/preparing-cluster-for-virt.htmlCPU-overhead_preparing-cluster-for-virt) in the Red Hat OpenShift docs.
* Must include enough memory for your workload needs. For example: 360 MiB + (1.002 * requested memory) + 146 MiB + 8 MiB * (number of vCPUs) + 16 MiB * (number of graphics devices). For more information, see [Memory overhead](https://docs.openshift.com/container-platform/4.11/virt/install/preparing-cluster-for-virt.htmlmemory-overhead_preparing-cluster-for-virt) in the Red Hat OpenShift docs.
* Must run Red Hat CoreOS operating system, which is installed during when you attach it to the location.



If your servers do not meet these requirements, follow the steps to [create a Bare Metal Server](https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-ordering-baremetal-server). For a list of bare metal options, see [Available options for a bare metal server](https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bmoptions-for-bare-metal-servers).





 Step 1: Attaching bare metal servers to your location 

Follow these general steps to attach your bare metal servers to your location. These steps might vary, depending on your specific hardware.
[Using IBM Cloud Kubernetes Service on classic to host the dl-reverse-proxy](https://cloud.ibm.com/docs/satellite?topic=satellite-dl-iks-classic)Using IBM Cloud Kubernetes Service on classic to host the dl-reverse-proxy

Follow these steps to set up the dl-reverse-proxy for IBM Cloud® Direct Link by using IBM Cloud Kubernetes Service on classic.

Satellite Kubernetes service

+1

Direct Link



* 2 hours
* 2023-01-30



[Deploying OpenShift Data Foundation on Satellite clusters with Azure worker nodes](https://cloud.ibm.com/docs/satellite?topic=satellite-odf-tutorial)Deploying OpenShift Data Foundation on Satellite clusters with Azure worker nodes

In this tutorial, you complete the following tasks to set up OpenShift Data Foundation.

Satellite Kubernetes service

+1

Virtual Private Cloud (VPC)



* 2 hours
* 2023-06-02



[Deploying apps to clusters with Continuous Delivery and Satellite Config](https://cloud.ibm.com/docs/satellite?topic=satellite-sat_toolchain_tutorial)Deploying apps to clusters with Continuous Delivery and Satellite Config

Deploy Kubernetes resources, like deployments, from your GitHub or GitLab repository to multiple clusters with IBM Cloud® Continuous Delivery and Satellite Config.

Satellite Continuous Delivery



* 30 minutes
* 2022-12-14



[Setting up virtualization on a Satellite location](https://cloud.ibm.com/docs/satellite?topic=satellite-virtualization-location)Setting up virtualization on a Satellite location

You can set up your Bare Metal Servers to use Red Hat OpenShift virtualization in your Satellite location. By using virtualization, you can provision Windows or other virtual machines on your Bare Metal Servers in a managed Red Hat OpenShift space.

Satellite



* 2023-06-19
For a list of bare metal options, see [Available options for a bare metal server](https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bmoptions-for-bare-metal-servers).





 Step 1: Attaching bare metal servers to your location 

Follow these general steps to attach your bare metal servers to your location. These steps might vary, depending on your specific hardware. For a complete tutorial, see [Attaching IBM Cloud Bare Metal Servers for Classic hosts](https://cloud.ibm.com/docs/satellite?topic=satellite-assign-bare-metal).



1. [Download a Red Hat CoreOS ISO](https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/). Find the corresponding ISO version that matches the Red Hat OpenShift version that you want to use. For example, if you want to use version 4.11, [download a version of RHCOS for 4.11](https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.11/), such as rhcos-4.11.9-x86_64-live.x86_64.iso.
2. Log in to your bare metal server.
3. In the BIOS settings, ensure that virtualization is enabled.
4. Set up your boot order to boot the Red Hat CoreOS ISO file that you downloaded in step 1.
5. Boot your system to install the ISO.
6. After Red Hat CoreOS is booted into memory, set up network connections so you can provide the location ignition file and attach the server to your location.
7. Download the ignition script for your Satellite location.

ibmcloud sat host attach --location <location_name> --operating-system RHCOS
8. Edit your ignition file to include the bare metal host name and network information.
Setting up Single Root I/O Virtualization (SR-IOV) in IBM Cloud Satellite clusters 

Satellite

Single Root I/O Virtualization (SR-IOV) allows you to share a single, supported network device with multiple pods in your Satellite cluster. You can enable SR-IOV in your cluster by installing and configuring the SR-IOV network operator. For more information about SR-IOV, see [About Single Root I/O Virtualization (SR-IOV) hardware networks](https://docs.openshift.com/container-platform/4.6/networking/hardware_networks/about-sriov.html).

Supported network interface controllers
: The SR-IOV Network Operator can be used with supported network interface controllers (NICs) only. For more information, see [Supported NICs](https://docs.openshift.com/container-platform/4.6/networking/hardware_networks/installing-sriov-operator.html).



 Prerequisites for using SR-IOV 



1. [Create a Satellite location](https://cloud.ibm.com/docs/satellite?topic=satellite-locations).
2. [Set up your location control plane](https://cloud.ibm.com/docs/satellite?topic=satellite-setup-control-plane).
3. [Attach more hosts to your location](https://cloud.ibm.com/docs/satellite?topic=satellite-attach-hosts) to use as worker nodes in your cluster. The hosts that you want to use as worker nodes must have a [Supported NIC](https://docs.openshift.com/container-platform/4.6/networking/hardware_networks/installing-sriov-operator.html).







 Installing the SR-IOV network operator 

[Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).



1.
: Enable the public cloud service endpoint so that your Red Hat OpenShift master can be accessed over the public network, for example to run oc commands from your CLI, and so that your Red Hat OpenShift master and the worker nodes can communicate over the public VLAN. You must enable the public cloud service endpoint, and can't later disable it.After you create the cluster, you can get the endpoint by running ibmcloud oc cluster get --cluster <cluster_name_or_ID>.

--private-service-endpoint
: In [VRF-enabled](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointvrf) and [service endpoint-enabled accounts](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointservice-endpoint): Enable the private cloud service endpoint so that your Red Hat OpenShift master and the worker nodes can communicate over the private VLAN. If you specify this option, you must also enable the public cloud service endpoint by using the --public-service-endpoint option. Note that you can't later change the cloud service endpoints.After you create the cluster, you can get the endpoint by running ibmcloud oc cluster get --cluster <cluster_name_or_ID>.

--pod-subnet
: All pods that are deployed to a worker node are assigned a private IP address in the 172.30.0.0/16 range by default. If you plan to connect your cluster to on-premises networks through IBM Cloud® Direct Link or a VPN service, you can avoid subnet conflicts by specifying a custom subnet CIDR that provides the private IP addresses for your pods. When you choose a subnet size, consider the size of the cluster that you plan to create and the number of worker nodes that you might add in the future. The subnet must have a CIDR of at least /23, which provides enough pod IPs for a maximum of four worker nodes in a cluster.
When you assign a policy in the IBM Cloud IAM console, leave the Resource field blank for configurations or subscriptions. Instead, you can scope the access policy to a cluster group for more control of how your Satellite Config resources are deployed.
: To let users view the Kubernetes resources that run in clusters with Satellite Config, you must assign an access policy with the appropriate role (Administrator, Manager, or Reader) to IBM Cloud Satellite (and not scoped to a particular resource or resource type).
: After you enable Satellite Config permissions when you create a Satellite cluster in the console or in the CLI with the --enable-admin-agent option for the ibmcloud oc cluster create satellite command, you must set the context of the cluster to synchronize permissions. You can set the cluster context by launching the Red Hat OpenShift web console or by running the ibmcloud oc cluster config command in the CLI. Note: If you registered a Red Hat OpenShift on IBM Cloud cluster in the public cloud to use with Satellite Config, you do not need to set the cluster context to synchronize permissions.

Configuration files in Satellite Config
: 

* You can upload only an individual configuration file of Kubernetes resources per release version. You cannot upload a directory or several different configuration files.
* Configuration files are subject to Kubernetes requirements, such as that the manifest must be expressed in YAML format.







 IBM Cloud services 

You can have up to 40 instances of a supported IBM Cloud service per Satellite location. For example, you might have a Satellite location that has 40 Red Hat OpenShift on IBM Cloud clusters in it.

Each supported service might have its own limitations to run in Satellite. Check the documentation of the supported service to understand the limitations.