List-Watch
Kubernetes 是通过 List-Watch的机制进行每个组件的协作,保持数据同步的,每个组件之间的设计实现了解耦。
List-Watch机制
工作机制:
用户通过 kubectl请求给 APIServer 来建立一个 Pod。
APIServer会将Pod相关元信息存入 etcd 中,待写入操作完成,APIServer 即会返回确认信息至客户端。
当etcd 接受创建 Pod 信息后,会发送ReplicaSet事件给 APIServer。
由于 Controller Manager 会监听(Watch,通过https的6443端口)APIServer 中的事件。此时 APIServer 接受到了 Create 事件,就会发送给 Controller Manager。
Controller Manager 在接到 Create 事件以后,调用其中的 Replication Controller 来保证 Node 上面需要创建的副本数量。
在 Controller Manager 创建 Pod 副本以后,APIServer 会在 etcd 中记录这个 Pod 的详细信息。
之后etcd 会将创建 Pod 的信息通过事件发送给 APIServer。
Scheduler 在监听(Watch)APIServer,它会将待调度的 Pod 按照调度算法和策略绑定到集群中 Node 上。
Scheduler 调度完毕以后会更新更详细 Pod 的信息,并将上面的 Pod 信息更新至 API Server,由 APIServer 更新至 etcd 中,保存起来。
etcd 将更新成功的事件发送给 APIServer,APIServer 也开始反映此 Pod 对象的调度结果。
kubelet 是在 Node 上面运行的进程,它也通过 List-Watch 的方式监听(Watch,通过https的6443端口)APIServer 发送的 Pod 更新的事件。kubelet 会尝试在当前节点上调用 Docker 启动容器,并将 Pod 以及容器的结果状态回送至 APIServer。
APIServer 将 Pod 状态信息存入 etcd 中。在 etcd 确认写入操作成功完成后,APIServer将确认信息发送至相关的 kubelet,事件将通过它被接受。
命令
指定调度节点
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 3
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
nodeName: node01
containers:
- name: myapp
image: soscscs/myapp:v1
ports:
- containerPort: 80
查看pod
kubectl get pods -o wide
查看详细事件(发现未经过 scheduler 调度分配)
kubectl describe pod myapp-6bc58d7775-6wlpp
给 node 设置标签
kubectl get node
kubectl label nodes node01 qqq=1
kubectl label nodes node02 qqq=2
kubectl get nodes --show-labels
修改label 的值
kubectl label nodes node02 kgc=a --overwrite
Pod亲和性与反亲和性
定向调度使用起来非常方便,但是也存在一定的问题,那就是没有满足条件的node,那么Pod将不会被运行,即使在集群中还有可用的Node列表也不行,这就限制了它的使用场景
基于上面的问题,kubernetes还提供了一种亲和性调度(Affinity),它在NodeSelector的基础之上进行了扩展,可用通过配置的形式,实现优先选择满足条件的Node进行调度,如果没有,也可以调度到不满足的节点上,使调度更加灵活。
节点的亲和性 | 硬策略 | 软策略 |
---|---|---|
podaffinity | 和满足标签的pod | 在同一个拓步域 |
podAntiAffinity | 和满足标签的pod | 不在同一个拓步域 |
节点亲和性
pod.spec.nodeAffinity
●preferredDuringSchedulingIgnoredDuringExecution:软策略
●requiredDuringSchedulingIgnoredDuringExecution:硬策略
硬策略实例
软策略实例
Pod 亲和性
pod.spec.affinity.podAffinity/podAntiAffinity
●preferredDuringSchedulingIgnoredDuringExecution:软策略
●requiredDuringSchedulingIgnoredDuringExecution:硬策略
污点和容忍
污点
节点亲和性,是Pod的一种属性(偏好或硬性要求),它使Pod被吸引到一类特定的节点。污点则相反,它使节点能够排斥一类特定的 Pod。
污点 和容忍相互配合,可以用来避免 Pod 被分配到不合适的节点上。每个节点上都可以应用一个或多个 taint ,这表示对于那些不能容忍这些 taint 的 Pod,是不会被该节点接受的。如果将 toleration 应用于 Pod 上,则表示这些 Pod 可以(但不一定)被调度到具有匹配污点的节点上。
使用 kubectl taint 命令可以给某个 Node 节点设置污点,Node 被设置上污点之后就和 Pod 之间存在了一种相斥的关系,可以让 Node 拒绝 Pod 的调度执行,甚至将 Node 已经存在的 Pod 驱逐出去。
当前 taint effect 支持如下三个选项:
NoSchedule:表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上
PreferNoSchedule:表示 k8s 将尽量避免将 Pod 调度到具有该污点的 Node 上
NoExecute:表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上,同时会将 Node 上已经存在的 Pod 驱逐出去
设置污点
kubectl taint node node01 qqq=value1:NoSchedule
节点说明中,查找 Taints 字段
kubectl describe node node-name
去除污点
kubectl taint node node01 qqq:NoSchedule-