Couple of things.

1. It looks like its looking in the default namespace. It probably should be looking in kube-system. This probably applies only if the next thing isn't done.
2. Doing per node configmaps is quite flexible, it will make for a large number of configmaps to manage.

Can it be changed to do the following:
Look for a node attribute on the given node's attributes named "kubelet.kubernetes.io/config".
If it doesn't exist, the configmap name to use is "kube-system/kubelet-default"
If it does exist, the value of the attribute is used as the configmap name.

This allows all or some kubelets to share configmaps in groups, or each individual kubelet to have its own.

@vishh and I recently talked about our options in this area. We would rather stick to per-node config internally, and build external automation to manage updating the per-node configs based on the attributes, etc. on a given node. Global config (and shared config is just a smaller case of global config) is dangerous because the Kubelets will almost immediately take up new config when they see it change. If the Kubelets are directly looking for a shared config, they will all change to that new config as soon as the configmap changes. In this scenario, if someone makes a bad change to that shared config, they could easily knock out a huge chunk of a cluster (or the whole thing, if some shared config ends up being global).

There's nothing wrong with having a configmap that acts as the source of config for several nodes, but per-node config forces people to think about building rollout automation if they want shared config objects, and this is a good thing.

@kfox1111 you're spot on about kube-system being the right namespace for these. Just updated this PR to reflect that.

@mtaufen I see what you mean about the per node config. But, I think you can get the same affect with less storage by following a pattern of uploading the new config with a unique name, then updating the attributes on the nodes one at a time to point to it.

If global configs are highly desirable, then we need to add some more logic
into config maps.
This idea was suggested by @thockin.
Each config map can contain an old and a new configuration and a rollout
percentage. Nodes will self-sort themselves based on a consistent hash. As
the rollout percentage increases from 0 - 100%, nodes will self-update
themselves based on the percentage number that the hashing scheme puts them
in.
This has the advantage of working for most users who typically do not have
diverse deployments that require custom kubelet configurations. We also
avoid storing a lot of duplicate config objects.
The disadvantage is that we are building a new concept on top of config
maps and we will need additional tooling and automation to make the
experience seamless for end users. I suspect that we might be better off
adding a top-level kubelet config object instead.
Also if we are going down the route of tooling and automation, the burden
of managing per-node configs can also be handled the same way. As for
duplicate storage, may be we could add something similar to
LocalObjectReference to ConfigMaps to re-use config objects instead of
duplicating them.

@mtaufen thanks for fixing the namespace issue. it looks good now.

@mtaufen talked me out of a single global map.

@kfox1111 that is a very good point.

Review status: 0 of 4 files reviewed at latest revision, 10 unresolved discussions, some commit checks failed.

cmd/kubelet/app/server.go, line 333 [r4] (raw file):

Comments from Reviewable

cmd/kubelet/app/server.go, line 333 [r4] (raw file):

Comments from Reviewable

GCE e2e build/test passed for commit e780bb5.

• Test Results
• Build Log
• Test Artifacts
• Internal Jenkins Results

@k8s-bot test this [submit-queue is verifying that this PR is safe to merge]

GCE e2e build/test passed for commit e780bb5.

• Test Results
• Build Log
• Test Artifacts
• Internal Jenkins Results

Automatic merge from submit-queue

Yayyy!!!

On Tue, Aug 23, 2016 at 9:26 AM, Kubernetes Submit Queue <
notifications@github.com> wrote:

Merged #30090 #30090.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#30090 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGvIKOFpZPBawZPIgeYE0AOiiGp1vZD_ks5qix8sgaJpZM4JdAvp
.

kubelet test went red after this merged.