|
| 1 | +// Module included in the following assemblies: |
| 2 | +// |
| 3 | +// * hosted_control_planes/hcp-deploy/hcp-deploy-aws.adoc |
| 4 | +// * hosted_control_planes/hcp-deploy/hcp-deploy-bm.adoc |
| 5 | +// * hosted_control_planes/hcp-deploy/hcp-deploy-virt.adoc |
| 6 | +// * hosted_control_planes/hcp-deploy/hcp-deploy-non-bm.adoc |
| 7 | +// * hosted_control_planes/hcp-deploy/hcp-deploy-ibm-power.adoc |
| 8 | +// * hosted_control_planes/hcp-deploy/hcp-deploy-ibmz.adoc |
| 9 | + |
| 10 | +:_mod-docs-content-type: PROCEDURE |
| 11 | +[id="hcp-custom-kubeapi_{context}"] |
| 12 | += Defining a custom DNS name |
| 13 | + |
| 14 | +As a cluster administrator, you can create a hosted cluster with an external API DNS name that is different from the internal endpoint that is used for node bootstraps and control plane communication. You might want to define a different DNS name for the following reasons: |
| 15 | + |
| 16 | +* To replace the user-facing TLS certificate with one from a public CA without breaking the control plane functions that are bound to the internal root CA |
| 17 | +* To support split-horizon DNS and NAT scenarios |
| 18 | +* To ensure a similar experience to standalone control planes, where you can use functions such as the "Show Login Command" function with the correct `kubeconfig` and DNS configuration |
| 19 | +
|
| 20 | +In order to define a DNS name, you insert a domain name in the `KubeAPICustomName` field of a `HostedCluster` object. You can define the name either during your initial setup or as part of a post-deployment update. |
| 21 | + |
| 22 | +.Procedure |
| 23 | + |
| 24 | +. In the specification for the `HostedCluster` object, add the `kubeAPIServerDNSName` field and the address for the domain. |
| 25 | ++ |
| 26 | +[source,yaml] |
| 27 | +---- |
| 28 | +kubeAPIServerDNSName: <your_custom_address> <1> |
| 29 | +---- |
| 30 | ++ |
| 31 | +<1> The value for the `kubeAPIServerDNSName` field must be a valid, addressable domain. |
| 32 | + |
| 33 | +. In the `namedCertificates` file of the OpenShift API, specify which certificate to use, as shown in the following example. |
| 34 | ++ |
| 35 | +.Example `namedCertificates` file |
| 36 | ++ |
| 37 | +[source,yaml] |
| 38 | +---- |
| 39 | +spec: |
| 40 | + configuration: |
| 41 | + apiServer: |
| 42 | + servingCerts: |
| 43 | + namedCertificates: |
| 44 | + - names: |
| 45 | + - xxx.example.com |
| 46 | + - yyy.example.com |
| 47 | + servingCertificate: |
| 48 | + name: my-serving-certificate |
| 49 | +---- |
| 50 | + |
| 51 | +After the `kubeAPIServerDNSName` field is defined and the certificate is specified, the Control Plane Operator controllers create a `kubeconfig` file named `custom-admin-kubeconfig`, which is stored in the `HostedControlPlane` namespace. The certificates are generated from the root CA, and the `HostedControlPlane` namespace manages their expiration and renewal. |
| 52 | + |
| 53 | +The Control Plane Operator reports a new `kubeconfig` file named `CustomKubeconfig` in the `HostedControlPlane` namespace. That file uses the new server that is defined in the `KubeAPICustomName` field. |
| 54 | + |
| 55 | +The custom `kubeconfig` file is referenced in the `HostedCluster` object in the `status` field as `CustomKubeconfig`. |
| 56 | + |
| 57 | +A new secret, named `<hosted_cluster_name>-custom-admin-kubeconfig`, is created in the `HostedCluster` namespace. You can use the secret to access the `HostedCluster` API server. |
| 58 | + |
| 59 | +[NOTE] |
| 60 | +==== |
| 61 | +This process does not directly affect the data plane, so no rollouts are expected to occur. |
| 62 | +==== |
| 63 | + |
| 64 | +If you remove the `kubeAPIServerDNSName` field from the specification, all newly generated secrets and the `CustomKubeconfig` reference will be removed from the cluster and from the `status` field. |
0 commit comments