[k8s]k8s的控制层kubelet+docker配合调度机制(k8架构)
意外停掉一台node的kubelet,发现调度有问题,研究了下调度的细节k8s架构
https://ws1.sinaimg.cn/large/9e792b8fgy1fmhhzgeht3j20oq0hi74o.jpg
控制层- kubelet(配合节点docker工作)
https://ws1.sinaimg.cn/large/9e792b8fgy1fmhhx18al7j20qv0dg75o.jpg
数据层- kube-proxy
https://ws1.sinaimg.cn/large/9e792b8fgy1fmhifp4bxtj20dh06aweq.jpg
逻辑图:
https://ws1.sinaimg.cn/large/9e792b8fgy1fmhif5di4cj20fr0bdq51.jpg
object
参考: https://kubernetes.io/docs/concepts/#
https://ws1.sinaimg.cn/large/9e792b8fgy1fmjog34f6tj20vm0cpjsb.jpg
各个组件各司其职
参考: http://www.cnblogs.com/jianyuan/p/5063530.html
https://ws1.sinaimg.cn/large/9e792b8fgy1fmjmn3e0y2j20fe0c2jt2.jpg
pod rc svc之间的关系
参考: 启动一个简单的集群: tomcat+mysql
https://ws1.sinaimg.cn/large/9e792b8fgy1fmjmxawe55j21kw0kwayz.jpg
测试pod调度
停掉n1的kubelet,等几min后
kubectl get node 显示n1 not ready
在等几min后
kubectl get no -o wide AGE字段显示unkown.
在等几min.
发现开始调度了,调度结果
https://ws1.sinaimg.cn/large/9e792b8fgy1fmhhcvwsm8j20h30b7jt0.jpg
注: 调度完成后即使挂掉的n1起来,pod也不会重新回归了.
在跑道n1上去看,以前老的容器依旧running,待下次启动kubelet后,这些容器立马被kubelet干掉.
这是n1启动后kubelet的日志
https://ws1.sinaimg.cn/large/9e792b8fgy1fmhhuegxsij21fr041jrr.jpg
出现的问题: kubelet和docker不好好配合,导致kubelet挂掉后无法调度.没查清楚什么问题
https://ws1.sinaimg.cn/large/9e792b8fgy1fmhhsu4pchj21az0d8q4k.jpg
难道是内核和docker兼容问题? 不得而知,已上尝试调度好几次,有一次出现这个问题
参考:
https://docs.docker.com/engine/userguide/storagedriver/selectadriver/#docker-ee-and-cs-engine
http://blog.csdn.net/styshoo/article/details/60715942
https://ws1.sinaimg.cn/large/9e792b8fgy1fmhim8qx82j20t909w752.jpg
为了给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
https://ws1.sinaimg.cn/large/9e792b8fgy1fmijckcvn1j20rd08dgoo.jpg
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 等对象的可用实例数量。
页:
[1]