KEP-4762: Allows setting any FQDN as the pod's hostname

[HirazawaUi]

• One-line PR description: Allows users to set any FQDN as the hostname of a pod

• Issue link: Allows setting any FQDN as the pod's hostname #4762

• Other comments:

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: HirazawaUi
Once this PR has been reviewed and has the lgtm label, please assign deads2k, thockin for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• keps/prod-readiness/OWNERS
• keps/sig-network/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[HirazawaUi]

As mentioned here, during the POC, I was unable to find a good method to pass the kube-apiserver configuration options to the default or REST logic, so I listed it as an alternative. I'd really appreciate any suggestions on this. If there are any ways I haven’t thought of to pass the kube-apiserver configuration options, I will revise it to be our main solution and list the current solution as an alternative.

[HirazawaUi]

Passing the cluster-domain as an argument to the ApiServer and generating the actualPodHostname in the REST based on the hostname in the PodSpec, the setHostnameAsFQDN field, and the ApiServer's cluster-domain args, the POC can be found here:

HirazawaUi/kubernetes@a55bc1a

This is one of the options I envisioned. Although it’s not good, I still pushed the code and hope to get more feedback.

[aojea]

a new field?

this will make this more complicated than it is today, no?

why is not an alternative to allow to relax the validation of the current pod.spec.hostname field to be able to set a fqdn there?

[HirazawaUi]

Yes, adding it will make everything more complex, but now we will create DNS records based on the hostname field in podSpec. If we set the FQDN in the hostname, it is undoubtedly a disruption to the existing behavior.
ref: https://github.com/kubernetes/kubernetes/blob/e1aa8197eddd277fb82be0b8bbc2ba2b4ca67af7/pkg/controller/endpoint/endpoints_controller.go#L439-L441

https://github.com/coredns/coredns/blob/a6338e924e29d318e7a1e971b5bde23f36d083af/plugin/kubernetes/kubernetes.go#L463-L497

[aojea]

why is disruptive? are those controllers not copying the field verbatim?

[HirazawaUi]

When we set the hostname field in the podSpec to an FQDN, such as www.google.com, and also set the subdomain field, we end up with an FQDN hostname that appends the cluster-suffix, resulting in www.google.com.subdomain.default.svc.cluster.local. Additionally, we get a DNS record for www.google.com.subdomain.default.svc.cluster.local. I believe this does not align with our current design patterns, and it also can't meet our current needs.

Of course, we can also state that when the hostname in the podSpec is set to an FQDN, we can ignore the subdomain field. I will add this to the Alternatives section.

[aojea]

... or to keep the current hostname and be able to override or omit the default.svc.cluster.local part , right ? :)

[HirazawaUi]

yes, added.

[HirazawaUi]

/cc @thockin

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[HirazawaUi]

/remove-lifecycle stale

[HirazawaUi]

ping @thockin

[aojea]

people can use an init container, no?

apiVersion: v1
kind: Pod
metadata:
  name: myapp-fqdn
  labels:
    app.kubernetes.io/name: MyApp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo "Hostname $(hostname) fqdn $(hostname -f)" && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', "hostname mypod.fqdn.com"]
    securityContext:
      privileged: true

$ kubectl apply -f init-hostname.yaml
pod/myapp-fqdn created
$ kubectl logs pod/myapp-fqdn
Defaulted container "myapp-container" out of: myapp-container, init-myservice (init)

Hostname mypod.fqdn.com fqdn mypod.fqdn.com <----

I think the effort and complexity this introduces is not giving enough benefit , specially if there is an alternative

[sftim]

Per #4768 (comment), let's list several alternatives including that one (it's good if each has its own subheading).

Remember that actions like "write documentation for…" are valid alternatives.