vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Example output

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
...
webserver-lb LoadBalancer 172.21.xxx.xxx 1234abcd-us-south.lb.appdomain.cloud 8080:30532/TCP 1d run=webserver
2. Create a custom or IBM-provided DNS subdomain for the load balancer hostname.



* Custom domain: Provide your own custom domain and give it an alias by specifying the load balancer external IP, in the format 1234abcd-us-south.lb.appdomain.cloud as a Canonical Name record (CNAME).



1. Register a custom domain by working with your Domain Name Service (DNS) provider or [IBM Cloud DNS](https://cloud.ibm.com/docs/dns?topic=dns-getting-started).
2. Define an alias for your custom domain by specifying the load balancer external IP as a Canonical Name record (CNAME). In the following example, the load balancer with the external IP of 1234abcd-us-south.lb.appdomain.cloud is reachable at www.your-custom-domain.com.



Host/Service
: The prefix where you want to reach your app such as, www.

Resource Type
: Select CNAME.

TTL
: Select a time to live.

Value/Target
: The LoadBalancer external IP that you retrieved earlier. For example 1234abcd-us-south.lb.appdomain.cloud.. Note that when using IBM Cloud DNS, make sure to enter a trailing period.
* IBM-provided subdomain: Use nlb-dns commands to generate a subdomain with a TLS certificate for the VPC ALB hostname. IBM Cloud takes care of generating and maintaining the wildcard TLS certificate for the subdomain for you.



1. Create a DNS subdomain and TLS certificate.
Setting proxy modes 

Load balancers support DNS-only and HTTP proxy modes. You can have HTTP Proxy and DNS-Only domains in the same load balancer region, but the traffic routing behavior differs as follows:



*  Traffic for domains using HTTP Proxy mode is routed based on the data center associated with the user making the request.
*  Traffic for domains using DNS-Only mode is routed based on the data center associated with the user’s recursive resolver (DNS recursor).





  HTTP Proxy mode 

In HTTP Proxy mode, load balancers have an automatic TTL. CIS announces IBM IP addresses externally, but protects (mask) your origin server IP addresses. Any changes to your load balancer propagate within seconds inside CIS, including any failover events.

Setting the load balancer to HTTP Proxy mode offers the following benefits:



*  Failover is faster, because external DNS caches that don't respect short DNS TTLs do not impact failover performance.
*  The "automatic" TTL (five minutes) reduces the number of authoritative queries made against CIS without impacting failover performance.







  DNS-Only mode 

In DNS-Only mode, you can configure load balancers to set a TTL from 30 seconds to 10 minutes. CIS serves the addresses of the healthy origin servers directly, but relies on DNS resolvers respecting the short TTL to re-query the CIS DNS for an updated list of healthy addresses.
* [node-local-dns-config ConfigMap](https://cloud.ibm.com/docs/containers?topic=containers-cluster_dnsdns_nodelocal_customize_stub_upstream): Extend the NodeLocal DNS cache configuration by customizing stub domains or upstream DNS servers to resolve services that point to external hosts.



NodeLocal DNS caching relies on CoreDNS to maintain the cache of DNS resolutions. Keep applicable NodeLocal DNS cache and CoreDNS configurations such as stub domains the same to maintain DNS resolution consistency.



 Editing the node-local-dns ConfigMap for general configuration updates 

Edit the node-local-dns ConfigMap to customize the NodeLocal DNS cache configuration.

Before you begin: [Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster)



1. Verify that the NodeLocal DNS cache daemon set is available.

kubectl get ds -n kube-system node-local-dns

Example output

NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
node-local-dns 4 4 4 4 4 ibm-cloud.kubernetes.io/node-local-dns-enabled=true 82d
2. Edit the default settings or add custom Corefiles to the NodeLocal DNS cache ConfigMap. Each Corefile that you import must use the coredns path. For more information, see the [Kubernetes documentation](https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/coredns).

Only a limited set of [plug-ins](https://coredns.io/plugins/) is supported for the NodeLocal DNS cache.

kubectl edit configmap -n kube-system node-local-dns

Example output

apiVersion: v1
lb-myapp-dal10 LoadBalancer 172.21.xxx.xxx 168.2.4.5 1883:30303/TCP 6d
lb-myapp-dal12 LoadBalancer 172.21.xxx.xxx 88.2.4.5 1883:31303/TCP 6d
2. Register the IP by creating a DNS subdomain. To specify multiple IP addresses, use multiple --ip options.

ibmcloud ks nlb-dns create classic --cluster <cluster_name_or_id> --ip <NLB_IP> --ip <NLB2_IP>
3. Verify that the subdomain is created.

ibmcloud ks nlb-dns ls --cluster <cluster_name_or_id>

Example output

Hostname IP(s) Health Monitor SSL Cert Status SSL Cert Secret Name
mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud ["168.2.4.5"] None created <certificate>
4. Optional: Set up a custom domain to point to the IBM-provided subdomain that you created in the previous step.



1. Register a custom domain by working with your Domain Name Service (DNS) provider or by using [IBM Cloud DNS](https://cloud.ibm.com/docs/dns?topic=dns-getting-started).
2. Define an alias for your custom domain by specifying the IBM-provided subdomain as a Canonical Name record (CNAME).



5. In a web browser, enter the URL to access your app through the subdomain that you created.



Next, you can [enable health checks on the subdomain by creating a health monitor](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer_hostnameloadbalancer_hostname_monitor).





 Understanding the subdomain format
lb-myapp-dal10 LoadBalancer 172.21.xxx.xxx 168.2.4.5 1883:30303/TCP 6d
lb-myapp-dal12 LoadBalancer 172.21.xxx.xxx 88.2.4.5 1883:31303/TCP 6d
2. Register the IP by creating a DNS subdomain. To specify multiple IP addresses, use multiple --ip options.

ibmcloud oc nlb-dns create classic --cluster <cluster_name_or_id> --ip <NLB_IP> --ip <NLB2_IP>
3. Verify that the subdomain is created.

ibmcloud oc nlb-dns ls --cluster <cluster_name_or_id>

Example output

Hostname IP(s) Health Monitor SSL Cert Status SSL Cert Secret Name
mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud ["168.2.4.5"] None created <certificate>
4. Optional: Set up a custom domain to point to the IBM-provided subdomain that you created in the previous step.



1. Register a custom domain by working with your Domain Name Service (DNS) provider or by using [IBM Cloud DNS](https://cloud.ibm.com/docs/dns?topic=dns-getting-started).
2. Define an alias for your custom domain by specifying the IBM-provided subdomain as a Canonical Name record (CNAME).



5. In a web browser, enter the URL to access your app through the subdomain that you created.



Next, you can [enable health checks on the subdomain by creating a health monitor](https://cloud.ibm.com/docs/openshift?topic=openshift-loadbalancer_hostnameloadbalancer_hostname_monitor).





 Understanding the subdomain format
* [June 2021](https://cloud.ibm.com/docs/containers?topic=containers-containers-relnotescontainers-jun21)



* From 07 to 31 July 2021, the DNS provider is changed from Cloudflare to Akamai for all containers.appdomain.cloud, containers.mybluemix.net, and containers.cloud.ibm.com domains for all clusters in IBM Cloud Kubernetes Service. Review the following actions that you must make to your Ingress setup.
* 

* If you currently allow inbound traffic to your classic cluster from the Cloudflare source IP addresses, you must also allow inbound traffic from the [Akamai source IP addresses](https://github.com/IBM-Cloud/kube-samples/tree/master/akamai/gtm-liveness-test) before 07 July. After the migration completes on 31 July, you can remove the Cloudflare IP address rules.



* 

* The Akamai health check does not support verification of the body of the health check response. Update any custom health check rules that you configured for Cloudflare that use verification of the body of the health check responses.



* 

* Cluster subdomains that were health checked in Cloudflare are now registered in the Akamai DNS as CNAME records. These CNAME records point to an Akamai Global Traffic Management domain that health checks the subdomains. When a client runs a DNS query for a health checked subdomain, a CNAME record is returned to the client, as opposed to Cloudflare, in which an A record was returned. If your client expects an A record for a subdomain that was health checked in Cloudflare, update your logic to accept a CNAME record.



* 

* During the migration, an Akamai Global Traffic Management (GTM) health check was automatically created for any subdomains that had a Cloudflare health check. If you previously created a Cloudflare health check for a subdomain, and you create an Akamai health check for the subdomain after the migration, the two Akamai health checks might conflict.
The createDomainMapping example displays the attributes of the newly created CDN. Make note of the uniqueId, as you must provide it as a parameter for many other APIs. The output should look similar to this:

Array
(
[0] => stdClass Object
(
[bucketName] => mybucket
[cacheKeyQueryRule] => include-all
[certificateType] => SHARED_SAN_CERT
[cname] => api-testing.cdn.appdomain.cloud.
[domain] => api-testing.cdntesting.net
[header] => origin.cdntesting.net
[httpPort] => 80
[httpsPort] =>
[originHost] => origin.cdntesting.net
[originType] => HOST_SERVER
[path] => /media/
[performanceConfiguration] => General web delivery
[protocol] => HTTP
[respectHeaders] => 0
[serveStale] => 1
[status] => CNAME_CONFIGURATION
[uniqueId] => 610345992629xxx
[vendorName] => akamai
)

)
Show more





 Example code to verify a domain mapping 

VerifyDomainMapping checks if the CNAME configuration is complete and if so, moves the CDN status to RUNNING status. Before calling verifyDomainMapping, you must add a CNAME record of the custom hostname to your DNS server.

This example calls verifyDomainMapping with the UniqueId that was returned as part of createDomainMapping. The SoapClient should be initialized by using the SoftLayer_Network_CdnMarketplace_Configuration_Mapping class as shown in the following example.

$client = SoftLayerSoapClient::getClient(
'SoftLayer_Network_CdnMarketplace_Configuration_Mapping',
null,
$apiUsername,
$apiKey
);

try {
$uniqueId = 610345992629xxx;
29 December 2020 



 New resources New data sources Enhancements 

 <br><br> * [ibm_cis_certificate_order](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/cis_certificate_order)<br> * [ibm_cis_certificate_upload](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/cis_certificate_upload)<br> * [ibm_cis_dns_records_import](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/cis_dns_records_import)<br> * [ibm_cis_dns_record](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/cis_dns_record)<br> * [ibm_cis_page_rule](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/cis_page_rule)<br> * [ibm_is_virtual_endpoint_gateway](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/is_virtual_endpoint_gateway)<br> * [ibm_is_virtual_endpoint_gateway_ip](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/is_virtual_endpoint_gateway_ip)<br><br><br> <br><br> * [ibm_cis_certificates](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/data-sources/cis_certificates)<br> * [ibm_cis_custom_certificates](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/data-sources/cis_custom_certificates)<br
: To continue receiving important security updates and support, you must [update the cluster to a supported version](https://cloud.ibm.com/docs/containers?topic=containers-cs_versionsprep-up) immediately.







 June 2021 

From 07 to 31 July 2021, the DNS provider is changed from Cloudflare to Akamai for all containers.appdomain.cloud, containers.mybluemix.net, and containers.cloud.ibm.com domains for all clusters in Red Hat OpenShift on IBM Cloud. Review the following actions that you must make to your Ingress setup.



* If you currently allow inbound traffic to your classic cluster from the Cloudflare source IP addresses, you must also allow inbound traffic from the [Akamai source IP addresses](https://github.com/IBM-Cloud/kube-samples/tree/master/akamai/gtm-liveness-test) before 07 July. After the migration completes on 31 July, you can remove the Cloudflare IP address rules.
* The Akamai health check does not support verification of the body of the health check response. Update any custom health check rules that you configured for Cloudflare that use verification of the body of the health check responses.
* Cluster subdomains that were health checked in Cloudflare are now registered in the Akamai DNS as CNAME records. These CNAME records point to an Akamai Global Traffic Management domain that health checks the subdomains. When a client runs a DNS query for a health checked subdomain, a CNAME record is returned to the client, as opposed to Cloudflare, in which an A record was returned. If your client expects an A record for a subdomain that was health checked in Cloudflare, update your logic to accept a CNAME record.
* During the migration, an Akamai Global Traffic Management (GTM) health check was automatically created for any subdomains that had a Cloudflare health check. If you previously created a Cloudflare health check for a subdomain, and you create an Akamai health check for the subdomain after the migration, the two Akamai health checks might conflict.
myingressresource mycluster-<hash>-0000.us-south.containers.appdomain.cloud 169.46.52.222,169.62.196.238 80 1h







 Step 5: Check your domain mappings and Ingress resource configuration 



1. If you use a custom domain, verify that you used your DNS provider to map the custom domain to the IBM-provided subdomain or the ALB's public IP address. Note that using a CNAME is preferred because IBM provides automatic health checks on the IBM subdomain and removes any failing IPs from the DNS response.



* IBM-provided subdomain CNAME: Check that your custom domain is mapped to the cluster's IBM-provided subdomain in the Canonical Name record (CNAME).

host www.my-domain.com

Example output

www.my-domain.com is an alias for mycluster-<hash>-0000.us-south.containers.appdomain.cloud
mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.46.52.222
mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.62.196.238
* Public IP address A record: Check that your custom domain is mapped to the ALB's portable public IP address in the A record. The IPs should match the public ALB IPs that you got in step 1 of the [previous section](https://cloud.ibm.com/docs/containers?topic=containers-ingress-debugping).

host www.my-domain.com

Example output

www.my-domain.com has address 169.46.52.222
www.my-domain.com has address 169.62.196.238



2. Check the Ingress resource configuration files for your cluster.

kubectl get ingress -o yaml



1. Ensure that you define a host in only one Ingress resource. If one host is defined in multiple Ingress resources, the ALB might not forward traffic properly and you might experience errors.
* Click on the Order a public certificate tile.
* Complete the form:



* Name - type a name you can remember.
* Description - enter a description of your choice.
* Under Certificate authority select your configured Let's Encrypt certificate authority engine.
* Under Key algorithm, pick your preferred algorithm,
* Bundle certificates - leave off
* Automatic certificate rotation - leave off
* Under DNS provider select your configured DNS provider instance
* Click on Select domains check the Select with wildcard and leave the domain itself unchecked and click on Done.



* Click Order.



2. Configure HTTPS from client web browsers to the CIS endpoint. In CIS configure TLS Security:



* Open the Security panel and choose TLS.
* For the Mode choose Client-to-edge. This will terminate HTTPS connections at the global load balancer and will switch to HTTP connections to the VPC load balancer.



3. In the CIS configure the global load balancer to use TLS:



* Open Reliability panel and choose Global Load Balancer.
* Locate the global load balancer created earlier and turn on Proxy.



4. In a browser open [https://lb.example.com](https://lb.example.com) to verify success.



Next configure HTTPS from CIS to the VPC load balancer.

Add an HTTPS listener to the VPC load balancers:



1. Navigate to VPC then Load balancers and click vpc-lb-region1.
2. Choose Front-end listeners.
3. Click Create listener.
4. Select HTTPS and enter for Port a value of 443.
5. Select the Default back-end pool: region1-pool or region2-pool.
6. Select the Secrets Manager instance you created earlier, the SSL Certificate drop down should show the certificate name that you ordered using your Secrets Manager instance earlier from Let's Encrypt. Click on Create.
* [Set up a VPC ALB](https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaassetup_vpc_ks_vpc_lb). Ensure that you define an HTTPS port in your Kubernetes LoadBalancer service that configures the VPC ALB.
* To use the TLS certificate to access your app via HTTPS, your app must be able to terminate TLS connections.



To register a VPC ALB hostname with a DNS subdomain,



1. Retrieve the hostname for your VPC ALB by running the get svc command. In the output, look for the hostname in the EXTERNAL-IP column. For example, 1234abcd-us-south.lb.appdomain.cloud.

kubectl get svc -o wide

Example output

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
...
webserver-lb LoadBalancer 172.21.xxx.xxx 1234abcd-us-south.lb.appdomain.cloud 8080:30532/TCP 1d run=webserver
2. Create a custom or IBM-provided DNS subdomain for the load balancer hostname.



* Custom domain: Provide your own custom domain and give it an alias by specifying the load balancer external IP, in the format 1234abcd-us-south.lb.appdomain.cloud as a Canonical Name record (CNAME).



1. Register a custom domain by working with your Domain Name Service (DNS) provider or [IBM Cloud DNS](https://cloud.ibm.com/docs/dns?topic=dns-getting-started).
2. Define an alias for your custom domain by specifying the load balancer external IP as a Canonical Name record (CNAME). In the following example, the load balancer with the external IP of 1234abcd-us-south.lb.appdomain.cloud is reachable at www.your-custom-domain.com.



Host/Service
: To continue receiving important security updates and support, you must [update the cluster to a supported version](https://cloud.ibm.com/docs/containers?topic=containers-cs_versionsprep-up) immediately.







 June 2021 

From 07 to 31 July 2021, the DNS provider is changed from Cloudflare to Akamai for all containers.appdomain.cloud, containers.mybluemix.net, and containers.cloud.ibm.com domains for all clusters in IBM Cloud Kubernetes Service. Review the following actions that you must make to your Ingress setup.



* If you currently allow inbound traffic to your classic cluster from the Cloudflare source IP addresses, you must also allow inbound traffic from the [Akamai source IP addresses](https://github.com/IBM-Cloud/kube-samples/tree/master/akamai/gtm-liveness-test) before 07 July. After the migration completes on 31 July, you can remove the Cloudflare IP address rules.
* The Akamai health check does not support verification of the body of the health check response. Update any custom health check rules that you configured for Cloudflare that use verification of the body of the health check responses.
* Cluster subdomains that were health checked in Cloudflare are now registered in the Akamai DNS as CNAME records. These CNAME records point to an Akamai Global Traffic Management domain that health checks the subdomains. When a client runs a DNS query for a health checked subdomain, a CNAME record is returned to the client, as opposed to Cloudflare, in which an A record was returned. If your client expects an A record for a subdomain that was health checked in Cloudflare, update your logic to accept a CNAME record.
* During the migration, an Akamai Global Traffic Management (GTM) health check was automatically created for any subdomains that had a Cloudflare health check. If you previously created a Cloudflare health check for a subdomain, and you create an Akamai health check for the subdomain after the migration, the two Akamai health checks might conflict.
Then, you can register the external IP addresses of the VPC NLB in each zone with one [DNS subdomain](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaasvpc_nlb_dns).







 Registering a DNS record and TLS certificate 

VPC NLBs provide static external IP addresses through which you can access your app. To register an SSL certificate for your app domain to support HTTPS, you can create an IBM-provided subdomain or bring your own custom domain.

For example, say that you have a multizone cluster, and run replicas of your app on worker nodes in each zone of your cluster. You [create one VPC NLB](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaassetup_vpc_nlb) per zone to expose the app replicas. Then, you can register the external IP addresses provided by each VPC NLB with one DNS entry.

After you create a DNS subdomain for VPC NLBs, you can't use nlb-dns health-monitor commands to create a custom health check. Instead, the default VPC health check is used. For more information, see the [VPC documentation](https://cloud.ibm.com/docs/vpc?topic=vpc-nlb-health-checks).



* [Create one VPC NLB](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaassetup_vpc_nlb) per zone for your app. Ensure that you define an HTTPS port in your Kubernetes LoadBalancer service that configures the VPC NLB.
* To use the SSL certificate to access your app via HTTPS, your app must be able to terminate TLS connections.



To register VPC NLB IP addresses with a DNS subdomain,



1. Retrieve the external IP address of your load balancer.

oc get svc -o wide

Example output
06496f64-a689-4693-ba23-320959b7b677 kube-bh077ne10vqpekt0domg-046e0f754d624dca8b287a033d55f96e 8 minutes ago 1234abcd-us-south.lb.appdomain.cloud no 95482dcf-6b9b-4c6a-be54-04d3c46cf017 online 717f2122-5431-403c-b21d-630a12fc3a5a 10.XXX.XXX.XXX active - c6540331-1c1c-40f4-9c35-aa42a98fe0d9 00809211b934565df546a95f86160f62
8. From your connection to the VPC private network, access the IP address of the Kubernetes LoadBalancer service that you found in step 6 and your app port in the format <external_IP>:<app_port>.
9. Optional: Repeat these steps to deploy a private VPC NLB in each zone where you want to expose your app. Then, you can register the external IP addresses of the VPC NLB in each zone with one [DNS subdomain](https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaasvpc_nlb_dns).







 Registering a DNS record and TLS certificate 

VPC NLBs provide static external IP addresses through which you can access your app. To register an SSL certificate for your app domain to support HTTPS, you can create an IBM-provided subdomain or bring your own custom domain.

For example, say that you have a multizone cluster, and run replicas of your app on worker nodes in each zone of your cluster. You [create one VPC NLB](https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaassetup_vpc_nlb) per zone to expose the app replicas.