[k8s]k8s的控制层kubelet+docker配合调度机制(k8架构)

半只蚂蚁

　　意外停掉一台node的kubelet,发现调度有问题,研究了下调度的细节

k8s架构

控制层- kubelet(配合节点docker工作)

数据层- kube-proxy

　　
逻辑图:
　　


object
　　参考: https://kubernetes.io/docs/concepts/#
　　


各个组件各司其职
　　参考: http://www.cnblogs.com/jianyuan/p/5063530.html
　　


pod rc svc之间的关系
　　参考: 启动一个简单的集群: tomcat+mysql

测试pod调度
　　停掉n1的kubelet,等几min后
　　
kubectl get node 显示n1 not ready
　　
在等几min后
　　
kubectl get no -o wide AGE字段显示unkown.
　　
在等几min.
　　
发现开始调度了,调度结果
　　

　　
注: 调度完成后即使挂掉的n1起来,pod也不会重新回归了.
　　在跑道n1上去看,以前老的容器依旧running,待下次启动kubelet后,这些容器立马被kubelet干掉.
　　
这是n1启动后kubelet的日志
　　


出现的问题: kubelet和docker不好好配合,导致kubelet挂掉后无法调度.没查清楚什么问题

　　难道是内核和docker兼容问题? 不得而知,已上尝试调度好几次,有一次出现这个问题
　　
参考:
　　
https://docs.docker.com/engine/userguide/storagedriver/selectadriver/#docker-ee-and-cs-engine
　　
http://blog.csdn.net/styshoo/article/details/60715942

　　
为了给Docker配置overlay存储驱动，你的Docker host必须运行在Linux kernel3.18版本之上，而且加载了overlay内核驱动。对于overlay2驱动，kernel版本必须在4.0或以上。OverlayFS可以运行在大多数Linux文件系统之上。不过，现在最建议在生产环境中使用ext4。

kube api-versions不同版本对比
　　参考: https://www.youtube.com/watch?v=bMiU4xH8pLw&t=1862s
　　

　　
[k8架构]k8s架构及调度机制图解参考
　　
http://www.cnblogs.com/iiiiher/p/8043444.html
　　

$ kubectl api-versions　　
apiextensions.k8s.io/v1beta1
　　
apiregistration.k8s.io/v1beta1
　　
apps/v1beta1
　　
authentication.k8s.io/v1
　　
authentication.k8s.io/v1beta1
　　
authorization.k8s.io/v1
　　
authorization.k8s.io/v1beta1
　　
autoscaling/v1
　　
batch/v1
　　
bitnami.com/v1alpha1
　　
certificates.k8s.io/v1beta1
　　
extensions/v1beta1
　　
k8s.io/v1
　　
networking.k8s.io/v1
　　
policy/v1beta1
　　
rbac.authorization.k8s.io/v1alpha1
　　
rbac.authorization.k8s.io/v1beta1
　　
settings.k8s.io/v1alpha1
　　
storage.k8s.io/v1
　　
storage.k8s.io/v1beta1
　　
v1
　　

node挂了后到底多久会notready 多久开始调度? 40s判死刑,缓期5min善后
　　参考: https://kubernetes.io/docs/reference/generated/kube-controller-manager/
　　
参考: 崔秀龙的博客: http://blog.fleeto.us/content/node-chong-shang-zhi-hou
　　注: 这个由kube-controller-manager的两个参数决定的
　　

--pod-eviction-timeout：缺省为 5m，五分钟，在 Pod 驱逐行为的超时时间。　　
--node-monitor-grace-period：缺省为 40s，也就是 40 秒，无响应 Node 在标记为 NotReady 之前的等候时间。
　　

　　

　　
--pod-eviction-timeout duration                                     The grace period for deleting pods on failed nodes. (default 5m0s)
　　
--node-monitor-grace-period duration                                Amount of time which we allow running Node to be unresponsive before marking it unhealthy. Must be N times more than kubelet's nodeStatusUpdateFrequency, where N means number of retries allowed for kubelet to post node status. (default 40s)
　　

　　exit状态的pod超过多少会触发gc
　　

--terminated-pod-gc-threshold=12500 #默认,exit状态的pod回收阀值　　

　　

　　监控
　　
参考: 崔秀龙的博客: http://blog.fleeto.us/content/node-chong-shang-zhi-hou
　　

--healthz-bind-address：健康监测地址，缺省为127.0.0.1。　　
--healthz-port：健康检测端口，缺省为 10248。
　　
curl 访问该地址，会得到响应：ok。
　　

　　
另外如果使用kube-metrics exporter进行集群监控，可以关注 RC、Deploy 等对象的可用实例数量。