vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For example, if 52.137.182.166 is currently registered to your domain and you want to add 52.137.182.270, you must specify --ip 52.137.182.166 --ip 52.137.182.270 in the command.

ibmcloud oc ingress domain update --cluster CLUSTER --domain DOMAIN [--hostname HOSTNAME] [--ip IP]





 Changing a cluster's default domain 

The default Ingress domain is used to form a unique URL for each of your apps and is the domain that is referenced by the IP addresses of any public ALBs in your cluster. When you provision a cluster, the default Ingress domain is automatically created for you, but you can change the default domain to any domain that exists in your cluster. To check your cluster's default domain, run ibmcloud oc cluster get and find the Ingress subdomain in the output.

For more details and command options, see the [CLI reference](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cli&interface=uiingress-domain-default-replace).

It can take up to five minutes for the default domain to update. During that time, your domain might experience downtime.

ibmcloud oc ingress domain default replace --cluster CLUSTER --domain DOMAIN







 Managing external provider credentials 

Learn how to manage the provider credentials that exist in your cluster.



 Viewing external provider credentials 

Get the details of the provider credentials that are added to your cluster. Note that only one set of credentials can be added to a cluster at a time.

For more details and command options, see the [CLI reference](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cli&interface=uiingress-domain-credential-get).

ibmcloud oc ingress domain credential get --cluster CLUSTER





 Removing external provider credentials 

You can remove external provider credentials from your cluster. Note that removing credentials causes any domains registered with those credentials to enter an Error state. The domain status resolves when the credentials are reapplied.
Setting up Terraform for Domain Name Registration 

Terraform on IBM Cloud® enables predictable and consistent provisioning of IBM Cloud services so that you can rapidly build complex, multi-tier cloud environments following Infrastructure as Code (IaC) principles. Similar to using the IBM Cloud CLI or API and SDKs, you can automate the provisioning, update, and deletion of your domain resources by using HashiCorp Configuration Language (HCL).

Looking for a managed Terraform on IBM Cloud® solution? Try out [IBM Cloud® Schematics](https://cloud.ibm.com/docs/schematics?topic=schematics-getting-started). With Schematics, you can use the Terraform scripting language that you are familiar with, but you don't have to worry about setting up and maintaining the Terraform command line and the IBM Cloud® Provider plug-in. Schematics also provides pre-defined Terraform templates that you can easily install from the IBM Cloud® catalog.



 Installing Terraform and configuring resources for domains 

To install Terraform and configure resources for domain resources:



* Follow the [Terraform on IBM Cloud® getting started tutorial](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-getting-started) to install the Terraform CLI and configure the IBM Cloud® Provider plug-in for Terraform. The plug-in abstracts the IBM Cloud® APIs that are used to provision, update, or delete domain resources.
* Create a Terraform configuration file that is named main.tf. In this file, you add the configuration to create a domain resource. For more information, see the [Terraform documentation](https://www.terraform.io/docs/language/index.html).





1. Create a CIS instance by using the ibm_resource_instance resource argument in your main.tf file.
ibmcloud dns custom-resolver-create --name NAME [--location LOCATION1] [--location LOCATION2] [-description DESCRIPTION] [-f, --force] [-i, --instance INSTANCE] [--output FORMAT]



 Command options 

-n, --name
: The name of the custom resolver.

-d, --description
: The descriptive text of the custom resolver.

-f, --force
: Allow creating custom resolver with fewer than 2 locations.

--location
: The Locations on which the custom resolver will be running. The location subnet CRN is required. For example: --location subnet1,enable --location subnet2,disable

-i, --instance
: Instance name or ID. If not set, the context instance specified by dns instance-target INSTANCE is used.

--output
: Specify output format. Currently, json is the only supported format.





 Examples 

Create a custom resolver for instance dns-demo.

ibmcloud dns custom-resolver-create --name "example" --location crn:v1:bluemix:public:is:us-south-1:a/01652b251c3ae2787110a995d8db0135::subnet:0716-b49ef064-0f89-4fb1-8212-135b12568f04,enable --description "demo" -i "dns-demo"







 ibmcloud dns custom-resolver-update 

Update a custom resolver for a service instance.

ibmcloud dns custom-resolver-update RESOLVER_ID [--name NAME] [--enabled true|false] [--description DESCRIPTION] [-i, --instance INSTANCE] [--output FORMAT]



 Command options 

RESOLVER_ID
: The ID of custom resolver.

-n, --name
: The name of the custom resolver.

-d, --description
: The descriptive text of the custom resolver.

--enabled
Note that though the DNS record for the route subdomain is registered in the public DNS system, the DNS resolution servers are reachable from the VPC.
3. The private VPC load balancer resolves the VPC hostname to an available private IP address of a Ingress controller service that was reported as healthy. The VPC load balancer continuously checks the IP addresses of the services that expose the Ingress controller in each zone in your cluster.
4. Based on the resolved IP address, the VPC load balancer sends the request to a Ingress controller service.
5. The Ingress controller forwards the request to the private IP address of the app pod over the private network. The source IP address of the request packet is changed to the IP address of the worker node where the Ingress controller pod runs. Each Ingress controller sends requests to the app instances in its own zone and to app instances in other zones. Additionally, if multiple app instances are deployed in one zone, the Ingress controller alternates requests between app pods.
6. When the app returns a response packet, it uses the IP address of the worker node where the Ingress controller that forwarded the client request exists. The Ingress controller then sends the response packet through the VPC load balancer and through the IBM Cloud VPC VPN, Transit Gateway, or Direct Link to the client.









 Route types and TLS termination 

Red Hat OpenShift offers four types of routes based on the type of TLS termination that your app requires. Each route type is supported for public and private routes.



Types of routes based on TLS termination

 Route type Use case 

 Simple If you don't need TLS encryption, create a simple route to handle non-encrypted HTTP traffic. 
 Passthrough When you want TLS connections to pass uninterruptedly from the client to your app pod, create a passthrough route. The router is not involved in TLS termination for encrypted HTTPS traffic, so the app pod must terminate the TLS connection. This type can also be used for HTTP/2 and for non-HTTP TLS endpoints.
This is the preferred routing protocol.
8. Then, create your Tier-1 Gateways in the regional edge cluster. You can select which data center (or edge node) is your preferred Tier-1 path in the regional cluster.
9. You can attach your segments into this level of Tier-1 Gateways. Also, you can create multiple segments and advertise them through Tier-1 Gateway to north bound Tier-0 Gateways.



This network topology example does not consider the management and control plane (vCenter and NSX Managers). The control plane high availability is discussed in another availability pattern.

The main reason that you need two layers is for physical north-south connectivity in the data centers and each data center having their own private and public VLANs and IP addresses for the uplinks. These IP addresses cannot move between the data centers. Therefore, you must consider the routing and network address translation if you use public connectivity in this topology.





 Multisite – multitenant 

Multisite – multitenant is also a use case and network deployment pattern where tenants require a solution with conflicting IP spaces and complete route table isolation. This topology provides seamless site recovery by using dynamic routing protocols, such as BGP. The vCenter Server automation does not deploy multisite topology automatically. However, you can customize the default single-site topology after initial vCenter Server deployment. When you have the compute capacity in the required data center, you can manually deploy the required additional edge nodes. Then, create a new edge cluster for the Tier-0 and Tier-1 Gateways through NSX-T. This overlay topology is highly scalable and it is possible to automate, for example, by using Ansible and Terraform.

The following diagram shows an example of a multisite – multitenant topology. It consists of a two layer Tier-0 design with three edge clusters. The routing table separation is done at Tier-1 and optionally, also at the regional Tier-0 level. Two edge clusters in the two data centers or zones in a multizone region, and one edge cluster deployed across the multizone region with edge nodes in each participating zone or data center.

Zoom

!
The route advertisements between T1 and T0 gateways are fully customizable by you and are done by NSX-T. No routing protocol is required or used between T1 and T0 advertisements.



The following diagram shows an example of a customer deployment that uses the standard topology, when the segments are attached directly to the Tier-0 Gateway. You can add more segments to the Tier-0 Gateway or and delete the Tier-1 Gateway that is deployed by the automation, if needed.

Zoom

![Single-site – single tenant example topology](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/arch-pattern-1-zone-t0.svg)

Figure 2. Single-site – single tenant example topology



1. The vCenter Server automation deploys an example topology by following this model. The deployment includes a single vCenter and three NSX-T Managers that are deployed in the cluster on the initial IBM Cloud data center location.
2. The vCenter Server automation deploys two edge cluster transport nodes and a single edge cluster for your Tier-0 and Tier-1 Gateways.
3. The Tier-0 Gateway provides north-south routing capabilities and the access to IBM Cloud private network is provided through its uplinks.
4. The access to private network is provided through private uplinks, which are attached to a portable subnet on a private primary VLAN on the IBM Cloud private network. The routing to IBM Cloud services uses these uplinks. The automation provisions the IP addresses to the uplinks from the IBM Cloud managed 10/8 address space.
5. If you provision your instance with public interfaces, the access to public network is provided through public uplinks, which are attached to a portable subnet on a public VLAN on the IBM Cloud public network. The routing to internet uses these uplinks, and the public IP addresses to the uplinks are provisioned by the automation.
6. You can expand the default topology by adding new segments to the existing Tier-0 Gateway.
Gateway cluster profiles instancename-dcname-clustername-service-edge-cluster-profile <br>instancename-dcname-clustername-service-edge-cluster-profile 
 Transport zones instancename-tz-esxi-private <br>instancename-tz-esxi-public <br>instancename-tz-vm-overlay <br>instancename-tz-edge-private <br>instancename-tz-edge-public 
 Segments instancename-podname.dcname-customer-t0-172-16-16-0 <br>instancename-podname.dcname-customer-t1-192-168-0-0 <br>instancename-podname.dcname-customer-t1-192-168-1-0 <br>instancename-podname.dcname-customer-to-private <br>instancename-podname.dcname-customer-to-public <br>instancename-podname.dcname-service-to-private <br>instancename-podname.dcname-service-to-public <br>instancename-clustername-edge-teps 
 IP address pools instancename-clustername-tep-pool 
 Transport nodes profiles instancename-podname.dcname-clustername-esxi-tpn-profile 
 Tier-0 and Tier-1 gateways instancename-podname.dcname-clustername-T0-function (where function includes services, workload, openshift) <br>instancename-podname.dcname-clustername-T1-function 







 Transport nodes 

Transport nodes define the physical server objects or VMs that participate in the virtual network fabric. Review the following table to understand the design.



Table 8. NSX-T transport nodes

 Transport node type Uplink profile IP assignment 

 ESXi esxi-private-profile <br>esxi-public-profile tep-pool 
 Gateway cluster edge-private-profile <br>edge-public-profile <br>edge-tep-profile <br>mgmt-edge-private-profile <br>mgmt-edge-public-profile <br>mgmt-edge-tep-profile tep-pool 







 Uplink profiles and teaming
[Single-site – single tenant example topology with Tier-1 gateway](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/v2t-diagrams-1-zone-t1.svg)

Figure 1. Single-site – single tenant example topology with Tier-1 gateway



1. The vCenter Server automation deploys an example single-site topology, which follows the principles that are presented in this model. The deployment includes a single vCenter and three NSX-T Managers that are deployed on the cluster on the initial IBM Cloud data center location.
2. The vCenter Server automation deploys two edge cluster transport nodes and a single edge cluster for your Tier-0 and Tier-1 gateways.
3. The Tier-0 gateway provides north-south routing capabilities and access to IBM Cloud private network is provided though its uplinks.
4. Access to private network is provided though private uplinks, which are attached to a portable subnet on a private primary VLAN on the IBM Cloud private network. The routing to IBM Cloud services uses these uplinks. IP addresses for the uplinks are provisioned by automating the 10/8 address space that is managed by the IBM Cloud.
5. If you provision your instance with public interfaces, access to public network is provided though public uplinks. They are attached to a portable subnet on a public VLAN on the IBM Cloud public network. The routing to internet uses these uplinks and public IP addresses to the uplinks are provisioned by the automation.
6. A single Tier-1 gateway is provisioned by the automation for the workloads. You can use this topology or customize it by provisioning new Tier-1 gateways.
7. You can expand the default topology by adding new segments to the existing Tier-1 Gateway (or to the new Tier-1 gateways provisioned by you).
[Single-site – multitenant example topology](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/arch-pattern-1-zone-t1-mt.svg)

Figure 3. Single-site – multitenant example topology



1. The vCenter Server automation deploys an example single-site topology, which follows the principles that are presented in this model. The deployment includes a single vCenter and three NSX-T Managers that are deployed in the cluster on the initial IBM Cloud data center location.
2. The vCenter Server automation deploys two edge cluster transport nodes and a single edge cluster for your Tier-0 and Tier-1 Gateways.
3. The Tier-0 Gateway provides north-south routing capabilities and the access to IBM Cloud private network is provided through its uplinks.
4. The access to private network is provided through private uplinks, which are attached to a portable subnet on a private primary VLAN on the IBM Cloud private network. The routing to IBM Cloud services uses these uplinks. The automation provisions the IP addresses to the uplinks from the IBM Cloud managed 10/8 address space.
5. If you provision your instance with public interfaces, the access to public network is provided through public uplinks, which are attached to a portable subnet in a public VLAN on the IBM Cloud public network. The routing to internet uses these uplinks, and the public IP addresses to the uplinks are provisioned by the automation.
6. A single Tier-1 Gateway is provisioned for the workloads by the automation. You can use this topology and expand it by adding new Tier-1 Gateways.
7. You can add new tenant segments to the existing Tier-1 Gateway (or to the other Tier-1 Gateways provisioned by you). The route advertisements between T1 and T0 Gateways are fully customizable by you and is done by NSX-T. No routing protocol is required or used between T1 and T0 advertisements.
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. Worker 10.73.14.26 then uses the source IP address from the original request packet, the client IP, to return the app pod's response packet directly to the client.







 Traffic flow in a multizone cluster 

The following diagram shows how version 2.0 NLBs in each zone direct traffic from the internet to an app in a multizone cluster.

Zoom

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

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



1. A request to your app uses the [DNS subdomain](https://cloud.ibm.com/docs/openshift?topic=openshift-loadbalancer_hostname) for your NLBs. You can also access the NLB in each zone by using its public IP address and port on the worker node. Note that by default, each NLB 2.0 is set up in one zone only. To achieve high availability, you must deploy an NLB 2.0 in every zone where you have app instances.
2. A DNS system service resolves the subdomain to the portable public IP address of one of the NLBs and its assigned port on the worker node.
: Source requests from clients that run outside the location to your destination resource in your Satellite location contain an HTTP header such as linkserver_hostname:endpoint_port. The Satellite Link tunnel server changes the HTTP header on the request to the destination host name and port, such as dest_hostname:dest_port, and sends the request to the Satellite Link connector. The Satellite Link connector then uses the destination's host name and port to send the request to the correct destination resource.





 HTTP tunnel 

When you want TLS connections to pass uninterruptedly from the source to your destination resource, such as to pass a certificate to the destination for mutual authentication, use the HTTP tunnel protocol.

The client source makes an HTTP connection request to the Satellite Link tunnel server or connector component, depending on whether the destination runs outside of the location or within your Satellite location. The Link component then makes the connection to the destination resource. After the initial connection is established, the Link component proxies the TCP connection between the source and destination uninterruptedly.

The Satellite Link component is not involved in TLS termination for encrypted traffic, so the destination resource must terminate the TLS connection. For example, if your destination resource requires mutual authentication, the HTTP tunnel protocol allows your client source to pass the required authentication certificate directly to the destination.





 Server-side certificate authentication for TLS and HTTPS 

If you select the TLS or HTTPS protocols, you can optionally require server-side verification of the destination's certificate. The certificate must be valid for the destination's host name and signed by a trusted Certificate Authority.

If your destination resource has a certificate, you do not need to provide the certificate when you create the endpoint. However, if you are testing access to a destination resource that is still in development and you do not have a trusted certificate yet, you can upload a self-signed certificate for verification. This ssl.crt file must contain the public, base-64 encoded certificate for your resource's host name and must not contain the private ssl.key certificate key.
If you have multiple tenants, you can divide them by using multiple Tier-1 gateways and by controlling routing advertisements and use network address translation (NAT).

This option is suitable for customers with workloads that run on a multiple data center, single tenant, and have some overlapping IP addresses inside their own workloads.

Overlapping IP addresses refers to overlay segments between customer environments that run on the vCenter Server instance.

The following diagram shows an example of a multitenant deployment by using the standard topology. Also, you can see how to expand that for a simple multitenant pattern. You can deploy multiple Tier-1 gateways manually through NSX-T and add each tenant segment to their own Tier-1 gateway.

Zoom

![Single-site – multitenant example topology](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/v2t-diagrams-1-zone-t1-mt.svg)

Figure 3. Single-site – multitenant example topology



1. The vCenter Server automation deploys an example single-site topology, which follows the principles that presented in this model. The deployment includes a single vCenter and three NSX-T Managers that are deployed on the cluster on the initial IBM Cloud data center location.
2. The vCenter Server automation deploys two edge cluster transport nodes and a single edge cluster for your Tier-0 and Tier-1 gateways.
3. The Tier-0 gateway provides north-south routing capabilities and access to IBM Cloud private network is provided though its uplinks.
4. Access to private network is provided though private uplinks, which are attached to a portable subnet on a private primary VLAN on the IBM Cloud private network. The routing to IBM Cloud services uses these uplinks. IP addresses for the uplinks are provisioned by automating the 10/8 address space that is managed by the IBM Cloud.
5. If you provision your instance with public interfaces, access to public network is provided though public uplinks.