vania-janet/multiturn-rag-retrieval-data huggingface dataset:
You can also change the mix of virtual processor cores as your workloads evolve.

Depending on the Cloud Pak, you get licensed IBM and open source software bundled together in a unified management experience with logging, monitoring, security, and access capabilities.



* IBM products: Cloud Paks extend licensed IBM software and middleware from [IBM Marketplace](https://www.ibm.com/products), and integrate these products with your cluster to modernize, optimize, and run hybrid cloud workloads.
* Open-source software: Cloud Paks might also include open source components for cloud-native and portable hybrid cloud solutions. Typically, open source software is unmanaged and you are responsible to keep your components up-to-date and secure. However, Cloud Paks help you consistently manage the entire lifecycle of the Cloud Pak components and the workloads that you run with them. Because the open source software is bundled together with the Cloud Pak, you get the benefits of IBM support and integration with select IBM Cloud features such as billing.



To see the components of each Cloud Pak, consult the [Cloud Pak documentation](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_cloud_paksoc_cloud_pak_ov).





 What else do I need to know to use Cloud Paks? 

When you set up your Cloud Pak, you might need to work with Red Hat OpenShift-specific resources, such as security context constraints. Make sure that you use the [oc CLI or kubectl version 1.12 CLI](https://cloud.ibm.com/docs/openshift?topic=openshift-cli-install) to interact with these resources, such as oc get scc. The kubectl CLI version 1.11 has a bug that yields an error when you run commands against Red Hat OpenShift-specific resources, such as kubectl get scc.
: Red Hat OpenShift [4.4.18_1516_openshift](https://cloud.ibm.com/docs/openshift?topic=openshift-changelog_archive4418_1516), [4.3.33_1537_openshift](https://cloud.ibm.com/docs/openshift?topic=openshift-changelog_archive4333_1537), and [3.11.272_1565_openshift](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_311311272_1565).





 27 August 2020 

Observability CLI plug-in
: Added the following commands to manage your IBM Log Analysis and IBM Cloud Monitoring configurations.



* [ibmcloud ob logging agent discover](https://cloud.ibm.com/docs/openshift?topic=openshift-observability_clilogging_agent_discover)
* [ibmcloud ob logging config enable public-endpoint or private-endpoint](https://cloud.ibm.com/docs/openshift?topic=openshift-observability_clilogging_config_enable)
* [ibmcloud ob logging config show](https://cloud.ibm.com/docs/openshift?topic=openshift-observability_clilogging_config_show)
* [ibmcloud ob monitoring agent discover](https://cloud.ibm.com/docs/openshift?topic=openshift-observability_climonitoring_agent_discover)
* [ibmcloud ob monitoring config enable public-endpoint or private-endpoint](https://cloud.ibm.com/docs/openshift?topic=openshift-observability_climonitoring_config_enable)



New! Worker node flavors
Logging for clusters 

For cluster and app logs, Red Hat® OpenShift® on IBM Cloud® clusters include built-in tools to help you manage the health of your single cluster instance. You can also set up IBM Cloud tools for multi-cluster analysis or other use cases, such as IBM Cloud Kubernetes Service add-ons: IBM Log Analysis and IBM Cloud Monitoring.



 Understanding options for logging 

To help understand when to use the built-in Red Hat OpenShift tools or IBM Cloud integrations, review the following information.

IBM Log Analysis
: Customizable user interface for live streaming of log tailing, real-time troubleshooting issue alerts, and log archiving.



* Quick integration with the cluster via a script.
* Aggregated logs across clusters and cloud providers.
* Historical access to logs that is based on the plan you choose.
* Highly available, scalable, and compliant with industry security standards.
* Integrated with IBM Cloud IAM for user access management.
* Flexible plans, including a free Lite option.



To get started, see [Forwarding cluster and app logs to IBM Log Analysis](https://cloud.ibm.com/docs/openshift?topic=openshift-healthopenshift_logging).

Built-in Red Hat OpenShift logging tools
: Built-in view of pod logs in the Red Hat OpenShift web console.



* Built-in pod logs are not configured with persistent storage. You must integrate with a cloud database to back up the logging data and make it highly available, and manage the logs yourself.



To set up an [OpenShift Container Platform Elasticsearch, Fluentd, and Kibana EFK stack](https://docs.openshift.com/container-platform/4.11/logging/cluster-logging.html), see [installing the cluster logging operator](https://cloud.ibm.com/docs/openshift?topic=openshift-healthoc_logging_operator). Keep in mind that your worker nodes must have at least 4 cores and GB memory to run the cluster logging stack.

Service logs: IBM Cloud® Activity Tracker
Monitoring cluster health and application metrics 

To enable IBM Cloud® Monitoring for your Red Hat® OpenShift® cluster, you need to ensure that the enable_monitoring deployment value is set to true. By doing so, the offering's automation deploys and configures an IBM Cloud Monitoring instance that allows you to collect (1) cluster metrics to monitor the health and resource usage of your worker nodes and (2) custom application metrics to monitor the status of your workloads.

After your cluster is provisioned, you can monitor your workloads by completing the following steps:



1.  From your Red Hat OpenShift cluster page, click your name.
2.  In the Integrations > Monitoring section, click Launch.
3.  You will see a number of default templates in Dashboards > Featured > Kubernetes.
4.  Select Workload Status & Performance. A dashboard opens that displays statistics of your cluster and workloads.



For more information, see [Monitoring cluster health](https://cloud.ibm.com/docs/openshift?topic=openshift-health-monitor).
Choosing an app exposure service 

Securely expose your apps to external traffic by using Red Hat OpenShift Ingress controller or IBM Cloud® Kubernetes Service NodePort, or network load balancer.



 Understanding options for exposing apps 

To securely expose your apps to external traffic, you can use choose from the following services.

[Red Hat OpenShift Ingress controller](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_routes)
: Expose multiple apps in a cluster by setting up routing with the Red Hat OpenShift Ingress controller. The Ingress controller uses the Ingress subdomain as a secured and unique public or private entry point to route incoming requests. You can use one subdomain to expose multiple apps in your cluster as services. The Ingress controller solution uses three components.



* The Ingress operator that manages the Ingress controllers in your cluster.
* The Ingress controller is a HAProxy-based Kubernetes service that manages all incoming traffic for the apps in your cluster by implementing routing rules for the apps. This controller is managed by the Ingress operator. The Ingress controller listens for incoming HTTP, or HTTPS service requests, and then forwards requests to the pods for that app only according to the rules defined in the Ingress resource and implemented by the Ingress controller.
* The Route resource defines the rules for how to route and load balance incoming requests for an app.



: A Route exposes a service as a hostname in the format <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud. An Ingress controller is deployed by default to your cluster, which enable Routes to be used by external clients. The Ingress controller uses the service selector to find the service and the endpoints that back the service. You can configure the service selector to direct traffic through one Route to multiple services. You can also create either unsecured or secured Routes by using the TLS certificate that is assigned by the Ingress controller for your hostname. Note that the Ingress controller supports only the HTTP and HTTPS protocols.
You can use the VRA as a VPN endpoint to create an encrypted IPSec tunnel between servers in IBM Cloud infrastructure and on-premises resources. For example, the following diagram shows how an app on a worker node in Red Hat OpenShift on IBM Cloud can communicate with an on-premises server via a VRA VPN connection on the private VLAN:

Zoom

![Expose an app in Red Hat OpenShift on IBM Cloud by using a load balancer.](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift/images/cs_vpn_vyatta.png)

Figure 2. Expose an app in Red Hat OpenShift on IBM Cloud by using a load balancer



1. An app in your cluster, myapp2, receives a request from an Ingress or LoadBalancer service and needs to securely connect to data in your on-premises network.
2. Because myapp2 is on a worker node that is on a private VLAN only, the VRA acts as a secure connection between the worker nodes and the on-premises network. The VRA uses the destination IP address to determine which network packets to send to the on-premises network.
3. The request is encrypted and sent over the VPN tunnel to the on-premises data center.
4. The incoming request passes through the on-premises firewall and is delivered to the VPN tunnel endpoint (router) where it is decrypted.
5. The VPN tunnel endpoint (router) forwards the request to the on-premises server or mainframe, depending on the destination IP address that was specified in step 2. The necessary data is sent back over the VPN connection to myapp2 through the same process.



To set up a Virtual Router Appliance,



1. [Order a VRA](https://cloud.ibm.com/docs/virtual-router-appliance).
2.
init command 

Virtual Private Cloud

Classic infrastructure

Initialize the Red Hat OpenShift on IBM Cloud plug-in or specify the region where you want to create or access Red Hat OpenShift clusters.

Region-specific endpoints are deprecated. Use the [global endpoint](https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zonesendpoint) instead.

If you need to list and work with resources from one region only, you can use the ibmcloud oc init command to target a regional endpoint instead of the global endpoint.



* Dallas (US South, us-south): https://us-south.containers.cloud.ibm.com
* Frankfurt (EU Central, eu-de): https://eu-de.containers.cloud.ibm.com
* London (UK South, eu-gb): https://eu-gb.containers.cloud.ibm.com
* Osaka (jp-osa): https://jp-osa.containers.cloud.ibm.com
* São Paulo (br-sao): https://br-sao.containers.cloud.ibm.com
* Sydney (AP South, au-syd): https://au-syd.containers.cloud.ibm.com
* Tokyo (AP North, jp-tok): https://jp-tok.containers.cloud.ibm.com
* Toronto (ca-tor): https://ca-tor.containers.cloud.ibm.com
* Washington, D.C. (US East, us-east): https://us-east.containers.cloud.ibm.com



To use the global functionality, you can use the ibmcloud oc init command again to target the global endpoint: https://containers.cloud.ibm.com

ibmcloud oc init [--host HOST] [--insecure] [-p] [-u] [-q]

Minimum required permissions
: None

Command options:

--host HOST
: Optional: The IBM Cloud Kubernetes Service API endpoint to use.
Follow the Kubernetes documentation to [Upgrade from v1alpha1 to v1beta1](https://github.com/kubernetes-csi/external-snapshotterupgrade-from-v1alpha1-to-v1beta1) to make sure that your snapshot CRDs are at the correct v1beta1 version. The steps to downgrade from version v1 to v1beta1 are the same as those to upgrade from v1alpha1. Do not follow the instructions to upgrade from version v1beta1 to version v1. 
 VPC clusters: App URL character length DNS resolution is managed by the cluster's [virtual private endpoint (VPE)](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-subnetsvpc_basics_vpe), which can resolve URLs up to 130 characters. If you expose apps in your cluster with URLs, such as the Ingress subdomain or Red Hat OpenShift routes, ensure that the URLs are 130 characters or fewer. For example, if you use an autogenerated route name in the format <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud that exceeds 130 characters, you might need to [create a route that uses a shorter, custom subdomain](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_routesroutes-setup) instead. 
 Unsupported: Deprecated and removed Red Hat OpenShift features For more information, review the [Red Hat OpenShift version 4.6 deprecated and removed features](https://docs.openshift.com/container-platform/4.6/release_notes/ocp-4-6-release-notes.htmlocp-4-6-deprecated-removed-features).
[Expose an app in Red Hat OpenShift on IBM Cloud by using a version 2.0 NLB](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift/images/cs_loadbalancer_ipvs_planning.png)

Figure 4. Expose an app in Red Hat OpenShift on IBM Cloud by using a version 2.0 NLB



1. A client request to your app uses the public IP address of your NLB and the assigned port on the worker node. In this example, the NLB has a virtual IP address of 169.61.23.130 and runs on the worker node that has the 10.73.13.25 private IP address. Note that if you [create a DNS subdomain](https://cloud.ibm.com/docs/openshift?topic=openshift-loadbalancer_hostname) for your NLB, users can access your app through the NLB's subdomain instead. A DNS system service resolves the subdomain to the portable public IP address of the NLB.
2. The NLB encapsulates the client request packet (labeled as "CR" in the image) inside an IPIP packet (labeled as "IPIP"). The client request packet retains the client IP as its source IP address. The IPIP encapsulating packet uses the worker node 10.73.14.25 IP as its source IP address.
3. The NLB routes the IPIP packet to a worker that an app pod is on and that has the private IP address 10.73.13.26. If multiple app instances are deployed in the cluster, the NLB routes the requests between the workers where app pods are deployed.
4. Worker 10.73.14.26 unpacks the IPIP encapsulating packet, and then unpacks the client request packet. The client request packet is forwarded to the app pod on that worker node.
5.
Testing access to apps with NodePorts 

Virtual Private Cloud

Classic infrastructure

Satellite

Make your containerized app available to internet access by using the public IP address of any worker node in a Red Hat OpenShift cluster and exposing a NodePort. Use this option for testing in Red Hat® OpenShift® on IBM Cloud® and for short-term public access.



 About NodePorts 

Expose a public port on your worker node and use the public IP address of the worker node to access your service in the cluster publicly from the internet.

When you expose your app by creating a Kubernetes service of type NodePort, a NodePort in the range of 30000 - 32767 and an internal cluster IP address is assigned to the service. The NodePort service serves as the external entry point for incoming requests for your app. The assigned NodePort is publicly exposed in the kubeproxy settings of each worker node in the cluster. Every worker node starts listening on the assigned NodePort for incoming requests for the service. To access the service from the internet, you can use the public IP address of any worker node that was assigned during cluster creation and the NodePort in the format <IP_address>:<nodeport>. If you want to access the service on the private network, use the private IP address of any worker node instead of the public IP address.

The following diagram shows how communication is directed from the internet to an app when a NodePort service is configured.

Zoom

![Expose an app in IBM Cloud Kubernetes Service by using NodePort](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift/images/nodeport.svg)

Figure 1. Expose an app by using NodePort



1. A request is sent to your app by using the public IP address of your worker node and the NodePort on the worker node.
2. The request is automatically forwarded to the NodePort service's internal cluster IP address and port. The internal cluster IP address is accessible inside the cluster only.
3.
OpenShift NSX DLR configuration 

The NSX distributed logical router is used to support the Red Hat® OpenShift® 4.7 environment. To use this information, you must understand how to create these components and add the configuration.

Review [Add a Distributed Logical Router](https://docs.vmware.com/en/VMware-NSX-Data-Center-for-vSphere/6.4/com.vmware.nsx.admin.doc/GUID-A20103B0-ABA1-4884-8EC3-287874E23181.html). PowerNSX commands are provided if you would want to use this method.



 NSX DLR 

The NSX distributed logical router runs as a kernel module in the hypervisor of each host and is optimized for East-West routing. Optionally, a DLR Control VM can be installed. The DLR Control VM is needed to peer with NSX Edges and NSX controllers for dynamic routing (OSPF or BGP) updates. In this deployment, static routing is used. However, DLR Control VMs are deployed, in case you require to use a routing protocol.

The NSX DLR Control VMs are configured as an active and passive pair of appliances. During the configuration process, the DLR control VM is deployed in the compact size and the NSX DLR is connected to the Red Hat OpenShift Edge.



Table 1. NSX DLR deployment

 Component Configuration 

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



Since the NSX DLR Control VMs are configured as active/passive, you must create vSphere Distributed Resource Scheduler (DRS) anti-affinity rules. The rules ensure that NSX Edges do not run on the same host as their respective peer appliance.



Table 2. NSX DLR anti-affinity rules

 Field Value 

 Name OpenShift-DLR 
 Type Separate virtual machines 
 Members OpenShift-DLR-0 <br>OpenShift-DLR-1
[Develop and deploy an app on Virtual Private Cloud by using deployment strategies](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-tutorial-cd-vpc)Develop and deploy an app on Virtual Private Cloud by using deployment strategies

In this tutorial, you learn how to create an open toolchain by using different deployment strategies. You also learn how toolchains are implemented in the IBM Cloud® Continuous Delivery service and how to develop and deploy a simple web application (app) by using toolchains.

Creating apps Red Hat OpenShift on IBM Cloud

+2

Kubernetes service,Continuous Delivery



* 30 minutes
* 2022-10-06



[Getting started with apps](https://cloud.ibm.com/docs/apps?topic=apps-getting-started)Getting started with apps

You can use a variety of ways to build and deploy enterprise-ready applications in IBM Cloud. Possible deployment targets include IBM Cloud Kubernetes Service, Red Hat OpenShift on IBM Cloud, and IBM Cloud® Code Engine.

Creating apps



* 30 minutes
* 2023-04-28



[Deploy a Java Liberty app by using IBM Cloud Schematics](https://cloud.ibm.com/docs/apps?topic=apps-tutorial-liberty-webapp)Deploy a Java Liberty app by using IBM Cloud Schematics

In this tutorial, you learn how to create and deploy a scalable Java Liberty application. This scalable web app offers a one-click option to create an IBM Cloud® Schematics workspace with your choice of preconfigured Terraform templates. The Terraform templates deploy your app to IBM Cloud with options for the deployment target (Kubernetes or Red Hat® OpenShift®) and the DevOps toolchain pipeline structure.

Schematics Red Hat OpenShift on IBM Cloud

+4

Red Hat OpenShift on IBM Cloud,Kubernetes service,Continuous Delivery,Creating apps



* 45 minutes
* 2023-03-09
Red Hat OpenShift Bastion node setup 

To enable the deployment, a virtual machine (VM) is provisioned to run the Red Hat® OpenShift® installation steps and host an HTTP Server. This VM is known as the bastion node. The bastion node is connected to the Red Hat OpenShift logical switch and the ESG firewall and NAT rules are configured to allow SSH access from the jump-server or remote device.

The bastion node runs Red Hat® Enterprise Linux®, and it is used to host the scripts, files, and tools to provision the bootstrap, control-plane, and compute nodes. After the deployment, it is recommended to keep the bastion node as an administrative node for the cluster.

The bastion node setup consists of the following steps:



1. Provision a Red Hat VM.
2. Register the Red Hat VM.
3. Install NGINX (HTTP Server).
4. Generate an SSH private key and add it to the agent.





 Provisioning a Red Hat VM 

Provision a Red Hat VM based on the following specifications. Use the vCenter Server user interface or by using the PowerCLI script that is documented later in this document to provision the VM. Record you NAT address, which is configured in the NSX ESG.



Table 1. Red Hat VM - provision

 VM IP address Gateway Disk (GB) Memory (GB) vCPU NAT address 

 bastion 192.168.133.8 192.168.133.1 50 2 1 10.208.59.197 



Use the following table to record your deployment details:



Table 2. Red Hat VM deployment

 Parameter Example Your deployment 

 vCenter Server IP address 
 vCenter Server user 
 vCenter Server password 
 Logical Switch OpenShift-LS 
 vCenter Server instance data store vsanDatastore 
 VM name bastion 
 ISO file name rhel-8.x-x86_64-dvd.iso 
 IP address 192.168.133.8 
 Netmask 255.255.255.0 
 Default gateway 192.168.133.1
For more information, see [Creating a Red Hat OpenShift cluster in your Virtual Private Cloud](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc_rh_tutorial) and [Configuring VPC subnets](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-subnetsvpc_basics_pgw)



1. Run the ibmcloud is public-gateways to see your public gateways.
2. Run the ibmcloud is subnets to see your subnets.
3. For every subnet run the ibmcloud is subnet <subnet-id> to check whenever it has a public gateway.



1. If your subnet does not have a public gateway attached, you need to attach one. For more information, see [Creating public gateways](https://cloud.ibm.com/docs/vpc?topic=vpc-create-public-gateways&interface=cli)





3. Ensure that no firewall rules block the canary traffic. VPC: canary traffic originates from one of the worker nodes, flows through a VPC Public Gateway and arrives to the public side of the VPC Load Balancer instance. Configure your VPC Security Groups to allow this communication. For more information, see [Controlling traffic with VPC security groups](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-security-group). Classic: canary traffic originates from the public IP address of one of the worker nodes and arrives to the public IP address of your classic load balancers. Configure your network policies to allow this communication. For more information, see [Controlling traffic with network policies on classic clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-network_policies).







 Next steps 



1. Wait 30 minutes, then run the oc get clusteroperator ingress command and check the MESSAGE column again.
2.