KEP-4762: Allows setting any FQDN as the pod's hostname #132558
Conversation
|
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: HirazawaUi The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/sig network |
|
This PR may require API review. If so, when the changes are ready, complete the pre-review checklist and request an API review. Status of requested reviews is tracked in the API Review project. |
a61c1bb to
c2af269
Compare
c2af269 to
df177ae
Compare
|
/retest |
| allErrs = append(allErrs, field.Forbidden(fldPath.Child("hostnameOverride"), "when `pod.Spec.SetHostnameAsFQDN` is true")) | ||
| } | ||
| // If HostNetwork is true, HostnameOverride must not be set. | ||
| if spec.SecurityContext != nil && spec.SecurityContext.HostNetwork { |
There was a problem hiding this comment.
Our description in the KEP appears to be slightly inaccurate. We state in the KEP:
if the hostNetwork field is true, it will always use the hostname of the host where the pod is located as the pod's name.
However, we declare this as invalid behavior in the table, so I also disallow it. If we have any other thoughts on this, I can remove this validation.
There was a problem hiding this comment.
|
/cc @thockin |
|
/test pull-kubernetes-node-e2e-containerd-alpha-features |
1 similar comment
|
/test pull-kubernetes-node-e2e-containerd-alpha-features |
|
@HirazawaUi: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
| // - `hostNetwork` must be set to false. | ||
| // | ||
| // This field must be a valid DNS subdomain as defined in RFC 1123 and contain at most 64 characters. | ||
| // Requires the HostnameOverride feature gate to be enabled. |
There was a problem hiding this comment.
Maybe it should be like this?
| // Requires the HostnameOverride feature gate to be enabled. | |
| // Requires the HostnameOverride feature gate to be enabled. | |
| // | |
| // +featureGate=HostnameOverride | |
| // +optional |
| func validatePodHostName(spec *core.PodSpec, fldPath *field.Path) field.ErrorList { | ||
| allErrs := field.ErrorList{} | ||
|
|
||
| if spec.HostnameOverride != nil { |
There was a problem hiding this comment.
remove just one indententation by returning early if is nil
if spec.HostnameOverride == nil {
return allErrs
}
|
you are missing one important part, pkg/api/pod/util.go needs to deal with the skewed problem where the feature was enablled and later roll back per example, see https://github.com/kubernetes/kubernetes/pull/91699/files#diff-40853a2fe474b6bde454934dc4e0742a3d9bbf98c31336d8d74520ebe8a2e300 for reference |
What type of PR is this?
/kind feature
What this PR does / why we need it:
The
HostnameOverridefeature gate is scheduled for release-1.34. The associated KEP has been merged, and this PR implements the content of the KEP.ref: https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/4762-allow-arbitrary-fqdn-as-pod-hostname .
Which issue(s) this PR is related to:
Special notes for your reviewer:
For this PR, we have added the following e2e tests:
podSpec.hostnameandpodSpec.hostnameOverridefields, the pod hostname shall be the value ofpodSpec.hostnameOverride.podSpec.hostnameOverridefield, the pod hostname shall be the value ofpodSpec.hostnameOverride.podSpec.subdomainandpodSpec.hostnameOverridefields, the pod hostname shall be the value ofpodSpec.hostnameOverride.podSpec.setHostnameAsFQDNandpodSpec.hostnameOverridefields, pod creation shall not be allowed.podSpec.hostNetworkandpodSpec.hostnameOverridefields, pod creation shall not be allowed.podSpec.hostnameOverride, pod creation shall not be allowed.These cases sufficiently cover all entries related to the
podSpec.hostnameOverridefield mentioned in the table. Should additional test cases be required for other entries in the table, they should be addressed in a new PR, as they are unrelated to this Feature gate.Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: