During my latest Kubernetes lab rebuild, I noticed some significant differences in the some functions of Kubernetes cluster. I’ve done my best to go back and update the previous blog posts with notes and pointers to make this clear. However – going forward please consider my GitHub Salt repo as the ‘source of truth’ for the Kubernetes configuration files and current build process. I’ll be updating that regularly as I continue to optimize the Salt config and add onto the Kubernetes configuration. A couple of big hitters I want to call out as differences between my initial build and this one…
cAdvisor is now part of kubelet
That’s right! We no longer need to have a separate manifest and container for cAdvisor. We can see that any host running the kubelet process is exposing port 4194…
And sure enough…
kube-proxy and kubelet no longer use etcd
In my first build, both the kubelet and kube-proxy service relied on talking directly to etcd to interact with the cluster. The associated configs looked like…
The newest systemd service configuration looks like this…
So what’s happened here is the cluster communication has moved to the API server. In the case of the kubelet, the variable is just called ‘api_server’ whereas the kube-proxy service refers to the API server as the ‘master’.
Those were the two big items that I noticed as I rebuilt. I’m sure there will be more as the project progresses and I’ll do my best to stay on top of them.
Manifest deployed containers now show under ‘get pods’
At first I thought there was something wrong with my lab when I saw this…
In my case, the ‘fluent-es’ container is a container deployed to each host through a local manifest present on each minion. I don’t recall these showing up on the master before, but they do now.
Pingback: Kubernetes Weekly: Issue #2 – Kubernetes Weekly
Hello,
I am running kubelet – 0.12.2, but even with –cadvisor_port=4194 specified, it is not listening on port 4194, unless I explicitly point to manifest directory.
Alex