vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Changing service endpoints or VLAN connections in Red Hat OpenShift 3.11 

After you initially set up your network when you [create a cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-clusters), you can change the service endpoints that your cluster master is accessible through or change the VLAN connections for your worker nodes.

The content on this page is specific to classic clusters only. For information about VPC clusters, see [Understanding network basics of VPC clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-subnets).

The content on this page is specific to classic clusters that run Red Hat OpenShift 3.11 only. In clusters that run Red Hat OpenShift 3.11, you must enable the public cloud service endpoint during cluster creation, and you can't disable it later. You can later enable the private cloud service endpoint. In clusters that run version 4, you choose the public cloud service endpoint only or public and private cloud service endpoints during cluster creation, and you can't later change the cloud service endpoints.



 Setting up the private cloud service endpoint 

Enable the private cloud service endpoint for your cluster.

The private cloud service endpoint makes your Kubernetes master privately accessible. Your worker nodes and your authorized cluster users can communicate with the Kubernetes master over the private network. To determine whether you can enable the private cloud service endpoint, see [Worker-to-master and user-to-master communication](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_basicsworkeruser-master). Note that you can't disable the private cloud service endpoint after you enable it.



1. Enable [VRF](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointvrf) in your IBM Cloud infrastructure account. To check whether a VRF is already enabled, use the ibmcloud account show command.
2.
Working with the Red Hat OpenShift agent 

After you provision an instance of the IBM Cloud Monitoring service in the IBM Cloud, you can deploy the Monitoring agent on your Red Hat OpenShift cluster to collect data and metrics automatically. You can configure which metrics to monitor in each environment.



 Pre-reqs 



* Check the topic [Tuning Sysdig Agent](https://docs.sysdig.com/en/docs/installation/sysdig-agent/troubleshooting-agent-installation/tuning-sysdig-agent/)
* Obtain the access key. For more information, see [Getting the access key](https://cloud.ibm.com/docs/monitoring?topic=monitoring-access_key).
* Obtain the public or private ingestion URL. For more information, see [collector endpoints](https://cloud.ibm.com/docs/monitoring?topic=monitoring-endpointsendpoints_ingestion).
* Log in to the OpenShift cluster. Choose a method to login to an OpenShift cluster. [Learn more about the methods to login](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clusteraccess_automation).







 Deploying an agent by using a script 

In order to use this script, you must have a minimum of Viewer and Manager IAM permissions assigned for the OpenShift cluster.

curl -sL https://ibm.biz/install-sysdig-k8s-agent | bash -s -- -a ACCESS_KEY -c COLLECTOR_ENDPOINT -t TAG_DATA -ac 'sysdig_capture_enabled: false' --nodeanalyzer --analysismanager https://<COLLECTOR ENDPOINT>/internal/scanning/scanning-analysis-collector --collector_port 6443 --API_ENDPOINT <API-ENDPOINT> --openshift [-as] [-af]

Where



* ACCESS_KEY is the ingestion key for the instance.
Attaching hosts to your location 

After you create the location in IBM Cloud Satellite®, add compute capacity to your location so that you can set up Red Hat OpenShift clusters or interact with other [Satellite-enabled IBM Cloud services](https://cloud.ibm.com/docs/satellite?topic=satellite-managed-services).

To attach Red Hat CoreOS (RHCOS) hosts, your location must be enabled for Red Hat CoreOS. For more information, see [Creating a location](https://cloud.ibm.com/docs/satellite?topic=satellite-locations). Note that you can still attach Red Hat Enterprise Linux hosts to a location that is enabled for Red Hat CoreOS.

Before you begin, make sure that you have created host machines that meet the [minimum hardware requirements](https://cloud.ibm.com/docs/satellite?topic=satellite-host-reqs) in your on-prem data center, in IBM Cloud, or in public cloud providers. For more information about how to configure hosts in public cloud providers to meet these minimum requirements, see [Cloud infrastructure providers](https://cloud.ibm.com/docs/satellite?topic=satellite-infrastructure-plan).

After you attach a host to your location, Satellite disables the ability to log in to the host as root with SSH for security purposes. You might see error messages if you try to SSH as root into a host that is attached successfully to a location. To restore the ability to SSH into the machine, you can [remove the host](https://cloud.ibm.com/docs/satellite?topic=satellite-host-remove) and reload the operating system.

Not sure how many hosts to attach to your location? See [Sizing your Satellite location](https://cloud.ibm.com/docs/satellite?topic=satellite-location-sizing).



 Downloading the host attachment script for your location 

To attach hosts to your location, you must download a host attachment script. After you download the script, you can run it on your hosts to attach them to your location.
Plan to attach at least 3 hosts to use in the control plane, and attach additional hosts for any services that you want to use.
12. Check that your hosts are shown in the Hosts tab of your [Satellite console](https://cloud.ibm.com/satellite/locations). All hosts show a Health status of Ready when a connection to the machine can be established, and a Status of Unassigned as the hosts are not yet assigned to your Satellite location control plane or a Red Hat OpenShift on IBM Cloud cluster.
13. Assign your hosts to the [Satellite control plane](https://cloud.ibm.com/docs/satellite?topic=satellite-setup-control-plane) or a [Red Hat OpenShift on IBM Cloud cluster](https://cloud.ibm.com/docs/satellite?topic=satellite-assigning-hostshost-assign-manual).







 I created a Satellite location, what's next? 

Now that your Satellite location is set up, you are ready to start using IBM Cloud services.



1. Add compute capacity to your location by [attaching more hosts to the location](https://cloud.ibm.com/docs/satellite?topic=satellite-attach-hosts) so that you can run [Satellite-enabled IBM Cloud service](https://cloud.ibm.com/docs/satellite?topic=satellite-managed-services).
2. Create a [Satellite-enabled IBM Cloud service](https://cloud.ibm.com/docs/satellite?topic=satellite-managed-services), such as a [Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-satellite-clusters). 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.
You can use a private DNS server, but it must be able to resolve hostnames on the public Internet.



Hosts assigned to a specific Red Hat OpenShift cluster or to the control plane must share some properties, which can be different across clusters.



* All Satellite hosts must have the same MTU values.
* Hosts must have TCP/UDP/ICMP Layer 3 connectivity for all ports across hosts. You cannot block certain ports that might block communication across hosts.







 Host network bandwidth 



* The hosts must have minimum network bandwidth connectivity of 100 Mbps, with 1 Gbps preferred.
* The bandwidth required between hosts varies with the number of clusters in the location, and the workloads that run in the cluster. Insufficient network bandwidth can lead to network performance problems.







 Network gateways and interfaces 



* Satellite does not support IPv6.
* All Satellite hosts must have an IPv4 address that can access containers.cloud.ibm.com and must have full IPv4 backend connectivity to the other hosts in the same cluster in the location.
* Hosts can use gateways to connect to the location control plane.







 Inbound connectivity requirements for Satellite hosts 

Hosts must have inbound connectivity on the primary network interface through the default gateway or firewall the system. Hosts that are assigned to the same service; for example, the same cluster, must be able to talk to each other and with the Satellite control plane.

For example, if the primary network interface for a host is eth0, you must open the following required IP addresses and ports on the default gateway or firewall on the eth0 private network interface.



Required inbound connectivity for hosts on the primary network interface

 Description Source IP Destination IP Protocol and ports 

 Allow hosts that are assigned to the same service in your location to communicate with each other and with the Satellite control plane All Satellite hosts All Satellite hosts All ports and protocols 
 Access the API to make changes in a Red Hat OpenShift cluster and access the Red Hat OpenShift web console or through the Red Hat OpenShift router Clients or authorized users Control plane hosts TCP 30000 - 32767 
 Access the web console for a Red Hat OpenShift cluster through the Red Hat OpenShift router Clients or authorized users Red Hat OpenShift cluster hosts TCP 443
Cloud Paks are integrated with the IBM Cloud catalog so that you can quickly configure and install the all the Cloud Pak components into an existing or new Red Hat OpenShift cluster. When you install the Cloud Pak, the Cloud Pak is provisioned with [Schematics](https://cloud.ibm.com/docs/schematics?topic=schematics-getting-started) and a Schematics workspace is created for you. You can use the workspace later to access information about your Cloud Pak installation. You access your Cloud Pak services from the Cloud Pak URL. For more information, consult the [Cloud Pak documentation](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_cloud_paksoc_cloud_pak_ov).





 Can I use the Red Hat OpenShift entitlement that comes with my Cloud Pak for my cluster? 

Yes, if your Cloud Pak includes an entitlement to run certain worker node flavors that are installed with OpenShift Container Platform. To view your entitlements, check in [IBM Passport Advantage](https://www.ibm.com/software/passportadvantage/index.html). Note that your IBM Cloud ID must match your IBM Passport Advantage ID.

You can create the cluster or the worker pool within an existing cluster with the Cloud Pak entitlement by using the --entitlement cloud_pak option in the [ibmcloud oc cluster create classic](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_cluster_create) or [ibmcloud oc worker-pool create classic](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_worker_pool_create) CLI commands. Make sure to specify the correct number and flavor of worker nodes that you are entitled to use.

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.
Tuning performance 

If you have specific performance optimization requirements, you can change the default settings for some cluster components in Red Hat® OpenShift® on IBM Cloud®.

If you choose to change the default settings, you are doing so at your own risk. You are responsible for running tests against any changed settings and for any potential disruptions caused by the changed settings in your environment.

Instead of tuning worker node performance with MachineConfig files in Red Hat OpenShift, you can modify the host with a daemonset file. For more information, see [Changing the Calico MTU](https://cloud.ibm.com/docs/openshift?topic=openshift-kernelcalico-mtu) or [Tuning performance for Red Hat CoreOS worker nodes](https://cloud.ibm.com/docs/openshift?topic=openshift-rhcos-performance).



 Default worker node settings 

By default, your worker nodes have the operating system and compute hardware of the [worker node flavor](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodes) that you choose when you create the worker pool.



 Customizing the operating system 

You can find a list of supported operating systems by cluster version in the [Red Hat OpenShift on IBM Cloud version information](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_versions). Your cluster can't mix operating systems or use different operating systems.

To optimize your worker nodes, consider the following information.



* Image and version updates: Worker node updates, such as security patches to the image or Red Hat OpenShift versions, are provided by IBM for you. However, you choose when to apply the updates to the worker nodes. For more information, see [Updating clusters, worker nodes, and cluster components](https://cloud.ibm.com/docs/containers?topic=containers-update).
* Temporary modifications: If you log in to a pod or use some other process to modify a worker node setting, the modifications are temporary.
Setting up an operational logging solution 

This tutorial shows you one way that can be used to meet the IBM Cloud Framework for Financial Services requirements that are related to [operational logging](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-logging-operational). This approach uses [Red Hat OpenShift on IBM Cloud Container Platform Elasticsearch, Fluentd, and Kibana EFK stack](https://docs.openshift.com/container-platform/4.6/logging/cluster-logging.html) by installing the [Cluster Logging Operator](https://docs.openshift.com/container-platform/4.6/logging/cluster-logging.html). The log data remains within your environment so that you retain full control over it.

We provide guidance, but you are solely responsible for installing, configuring, and operating IBM third-party software in a way that satisfies IBM Cloud Framework for Financial Services requirements. In addition, IBM does not provide support for third-party software.

The final result is a general logging solution that can be used for:



* Logs from Red Hat OpenShift on IBM Cloud applications
* Red Hat OpenShift on IBM Cloud platform logs
* Logs from applications that are running on virtual server instances
* System logs from virtual server instances





 Logging solution architecture 

The capability of the [Red Hat OpenShift on IBM Cloud Cluster Logging Operator](https://docs.openshift.com/container-platform/4.6/logging/cluster-logging.html) allows administrators to aggregate logs across a Red Hat OpenShift on IBM Cloud cluster. These logs include application container logs, infrastructure component logs, and system audit logs. Administrators deploy cluster logging by deploying the Elasticsearch Operator and the Cluster Logging Operator. These operators deploy Elasticsearch servers for collecting and indexing logs, Fluentd for sending logs from worker nodes, and Kibana for searching and displaying the logs.

When using Red Hat OpenShift on IBM Cloud logging for financial service environments, you must install the Elasticsearch Operator and Cluster Logging Operator in every Red Hat OpenShift on IBM Cloud cluster that requires logging.
Backing up and restoring apps and data with PX-Backup 

PX-Backup is a Portworx proprietary backup solution that is compatible with any Red Hat OpenShift on IBM Cloud cluster. You can use PX-Backup to back up and restore Red Hat OpenShift on IBM Cloud resources, apps and data across multiple clusters. For more information on PX-Backup, see [Understanding PX-Backup](https://backup.docs.portworx.com/understand/).

To back up the data in your persistent volumes, you must have a storage class that supports snapshots in your cluster. Clusters with Portworx Enterprise have storage classes available that support snapshots by default. However, for clusters that don't have Portworx Enterprise, you must have a storage classes with snapshot support to back up your persistent volume data. The Block Storage for Classic driver, and the File Storage for Classic driver don't have storage classes that support snapshots. If you have workloads that use these drivers, you can use PX-Backup to back up your apps, but not the data in the persistent volumes. For more information see [Backing up and restoring cluster data with PX-Backup](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_backuppx-backup-and-restore).



 Installing PX-Backup on a Red Hat OpenShift on IBM Cloud cluster 

Install PX-Backup on a Red Hat OpenShift on IBM Cloud cluster in your IBM Cloud account. After you install PX-backup on one cluster in your account, you can use it to back up or restore data and apps for any cluster in that same account.

Before you begin:



* Make sure that your cluster meets the [minimum Portworx requirements](https://docs.portworx.com/start-here-installation/).
* [Log in to your cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).
* Provision and attach 320Gi of block storage to your cluster.
You can use this information for planning purposes, such as to estimate the general time that the version might become unsupported.

Dates that are marked with a dagger (†) are tentative and subject to change.



Release history for Red Hat OpenShift on IBM Cloud version 4.13.

 Supported? Red Hat OpenShift / Kubernetes version Release date Unsupported date 

 Supported 4.13 / 1.26 14 June 2023 26 February 2025† 







 Preparing to update 

Review changes that you might need to make when you [update a cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-update) to version 4.13. This information summarizes updates that are likely to have an impact on deployed apps when you update.

Portworx
: [Portworx](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_about) does not yet support Red Hat OpenShift on IBM Cloud version 4.13 clusters. Do not update your cluster to version 4.13 if Portworx is installed.



 Update before master 

The following table shows the actions that you must take before you [update the cluster master](https://cloud.ibm.com/docs/openshift?topic=openshift-updatemaster).



Changes to make before you update the master to Red Hat OpenShift 4.13

 Type Description 

 Unsupported: Deprecated and removed OpenShift features For more information, review the [OpenShift version 4.13 deprecated and removed features](https://docs.openshift.com/container-platform/4.13/release_notes/ocp-4-13-release-notes.htmlocp-4-13-deprecated-removed-features) and [Preparing to update to OpenShift Container Platform 4.13](https://docs.openshift.com/container-platform/4.13/updating/updating-cluster-prepare.htmlupdating-cluster-prepare) for possible actions required.
LegacyServiceAccountTokenNoAutoGeneration feature gate is enabled For more information, review possible required actions in the LegacyServiceAccountTokenNoAutoGeneration is on by default section of the[Red Hat OpenShift version 4.11 notable technical changes](https://docs.openshift.com/container-platform/4.11/release_notes/ocp-4-11-release-notes.htmlocp-4-11-notable-technical-changes). 
 Red Hat OpenShift web console redirect changed Cluster server URL no longer redirects to the Red Hat OpenShift web console. You must add /console to the URL for the redirect. 







 Update after master 



Changes to make after you update the master to Red Hat OpenShift 4.11

 Type Description 

 Unsupported: RHEL 7 worker nodes Using RHEL 7 worker nodes with Red Hat OpenShift on IBM Cloud version 4.11 clusters is unsupported. After updating the cluster master, if your cluster still has RHEL 7 worker nodes, [migrate your RHEL 7 worker nodes to RHEL 8](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_versions_411rhel-migrate-411). 









 Migrating your worker nodes from RHEL 7 to RHEL 8 

RHEL 8 is the default operating system supported for clusters that run version 4.11. RHEL 7, which is currently the default operating system for cluster versions 4.10 and earlier, is not supported in version 4.11. If you upgrade a cluster master from version 4.10 to 4.11, you must migrate your worker nodes from RHEL 7 to RHEL 8. You cannot upgrade RHEL 7 worker nodes directly to RHEL 8. Instead, after you have upgraded to 4.11, you must provision a new RHEL 8 worker pool in your 4.11 cluster and then remove the RHEL 7 worker pool.
RHCOS enabled locations in Sao Paulo 

The following network requirements are for outbound connectivity for Red Hat Enterprise Linux (RHEL) and Red Hat CoreOS (RHCOS) hosts for use with Red Hat CoreOS enabled locations in the Sao Paulo (br-sao) region.

The type of location that you create dictates the type of operating systems that can run on your hosts. If your location is RHCOS enabled, then you can attach hosts that are running either RHEL and RHCOS. If your location isn't RHCOS enabled, then you can attach only hosts that are running RHEL. You can check whether your [location is RHCOS enabled](https://cloud.ibm.com/docs/satellite?topic=satellite-locationsverify-coreos-location).

You can verify your host setup with the satellite-host-check script. For more information, see [Checking your host setup](https://cloud.ibm.com/docs/satellite?topic=satellite-host-network-check).

You can [download a copy of these requirements](https://cloud.ibm.com/media/docs/downloads/satellite/rhcos-sao-paulo.csv).

Review the following outbound network requirements for RHEL and RHCOS hosts for use with RHCOS enabled locations in the (br-sao) region.

Allow access to Red Hat network time protocol (NTP) servers.
: 

* Destination hostnames: 0.rhel.pool.ntp.org, 1.rhel.pool.ntp.org, 2.rhel.pool.ntp.org, 3.rhel.pool.ntp.org
* Protocol and ports: Allow NTP protocol and provide UDP on port 123



: If you don't want to use Red Hat network time protocol (NTP) servers, you can instead define a [custom NTP server for your RHCOS hosts](https://cloud.ibm.com/docs/satellite?topic=satellite-config-custom-ntp).

Allow hosts to communicate with Red Hat Container Registry.
: Allow your hosts to access the required sites for OpenShift Container Platform.
Why do I see a Could not find user error when I try to access the Red Hat OpenShift on IBM Cloud web console? 

When you try to access the Red Hat OpenShift on IBM Cloud web console, you see an error message similar to the following.

Could not find user.

  Why it’s happening 

This error occurs when you try to access the Red Hat OpenShift on IBM Cloud web console directly, such as through a URL, rather than through the IBM Cloud UI or without running the ibmcloud oc cluster config command. This prevents the IAM user role from synchronizing to the cluster.

  How to fix it 

Synchronize the IAM user information to the Red Hat OpenShift on IBM Cloud cluster.

Before you begin:

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

To synchronize the IAM information for the user, you have 2 options:



*  Log in to your cluster from the [Red Hat OpenShift clusters console](https://cloud.ibm.com/kubernetes/clusters?platformType=openshift).
*  Set your command line context for the cluster by running the ibmcloud oc cluster config --cluster CLUSTER command.



If you use an API key for a functional ID or another user, make sure to log in as the correct user.

After the impacted user completes the IAM synchronization, the cluster administrator can verify the user exists in the cluster by listing users with the oc get users command.