Documenting setHostnameAsFQDN feature

KEP: kubernetes/enhancements#1797 and kubernetes/enhancements#1792
Code PR: kubernetes/kubernetes#91699
This commit is contained in:
Javier Diaz-Montes
2020-06-19 10:05:55 -04:00
parent c7cf16fbb6
commit 64422b159a
2 changed files with 14 additions and 0 deletions
@@ -157,6 +157,18 @@ pointing to the Pod's IP address. Also, Pod needs to become ready in order to ha
record unless `publishNotReadyAddresses=True` is set on the Service.
{{< /note >}}
### Pod's setHostnameAsFQDN field {#pod-sethostnameasfqdn-field}
When a Pod is configured to have fully qualified domain name (FQDN), its hostname is the short hostname. For example, if you have a Pod with the fully qualified domain name `busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`, then by default the `hostname` command inside that Pod returns `busybox-1` and the `hostname --fqdn` command returns the FQDN.
When you set `setHostnameAsFQDN: true` in the Pod spec, the kubelet writes the Pod's FQDN into the hostname for that Pod's namespace. In this case, both `hostname` and `hostname --fqdn` return the Pod's FQDN.
{{< note >}}
In Linux, the hostname field of the kernel (the `nodename` field of `struct utsname`) is limited to 64 characters.
If a Pod enables this feature and its FQDN is longer than 64 character, it will fail to start. The Pod will remain in `Pending` status (`ContainerCreating` as seen by `kubectl`) generating error events, such as Failed to construct FQDN from pod hostname and cluster domain, FQDN `long-FDQN` is too long (64 characters is the max, 70 characters requested). One way of improving user experience for this scenario is to create an [admission webhook controller](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) to control FQDN size when users create top level objects, for example, Deployment.
{{< /note >}}
### Pod's DNS Policy
DNS policies can be set on a per-pod basis. Currently Kubernetes supports the