Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
AWS EBS provisioner should get node zone info from k8s #76976
What type of PR is this?
What this PR does / why we need it:
Which issue(s) this PR fixes:
Special notes for your reviewer:
Hi @zhan849. Thanks for your PR.
I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with
Once the patch is verified, the new status will be reflected by the
I understand the commands that are listed here.
Apr 24, 2019
2 times, most recently
Apr 24, 2019
What are the implications of this for a kubelet that accidentally or maliciously records incorrect information in its node object? Is there a check against the source of truth (cloud provider) at any point in the process?
Zone information is actually maintained by node controller and is retrieved directly from cloud provider and thus trustworthy: https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/cloud/node_controller.go#L296
zone labels are also mutable by kubelets.
I'm sympathetic to the issue being fixed, but I don't think this use of node role labels is acceptable. If we want to start using those labels like this, we need guarantees that they will be set and maintained, and we don't have those now.
I think this needs to be reverted to remove this label use, and alternate methods of solving the PV issue explored (I could see using info from Node objects as an efficient check, and verifying node zone or master tag against metadata the first time we encounter the node, or if what is recorded in the node disagrees with our last check against metadata)
I will open another ticket to move the conversation over. We can hold off cherry-picking to release-1.14 for not, but I think it's too early to determine whether this PR would create regression and should be reverted
cloud providers have more leeway to dictate how metadata tags must be configured in order to interoperate with the kubernetes cloud provider code. I'm concerned about trading the existing behavior of metadata tags for labels that current users of the aws cloud provider are not guaranteed to have set.
Please go ahead and revert this PR, it breaks compatibility for existing AWS cloud provider users, and bases behavior of core kubernetes components on the node role labels, which is not an intended use. Code freeze is approaching, and we should not leave this use in place.
@liggitt @smarterclayton I'm proposing an alternative optimization that leaves the code path for volumes that need to bind immediately, but use the zone info from selected node for topo-aware volume provisioning, which still achieved significant reduction in cloud provider footprint.
I pinged sig-storage in the PR but also wanna get feedbacks from you guys:
thanks for the time!