【k8s】3.k8s的调度过程:一个deployment的创建过程

前情提要:【k8s】1.k8s架构-CSDN博客

首先复习一下k8s的几个核心组件:

  • control plane(master节点)
    • api server:请求入口,操作etcd
    • controller manager:管理集群的状态
    • scheduler:pod调度
    • etcd:数据持久化
  • node(工作节点)
    • kubelet:维护容器的生命周期
    • container runtime(CRI): 镜像管理, Pod 和容器的真正运行
    • kube proxy:服务发现和负载均衡

k8s创建一个deployment的过程

整个过程遵循关注点分离:APIServer, ControllerManager, Etcd, Scheduler, Kubelet, Docker分工明确,各自处理自己的工作。

1. 客户端请求APIServer

请求方通过api接口或kubectl方式请求到APIServer,APIServer会进行认证鉴权、校验等,然后将此deployment创建信息写入etcd。

2. controller manager处理

controller manager监听到etcd中的事件,对于不同的资源,触发不同的处理方式。

对于deployment的处理,分为两方面进行管理:

  • deployment controller:监听deployment的创建事件,创建相应的replicaset副本集(控制副本数量)。k8s是建议用deployment管理副本数而非直接使用replicaset的,用replicaset控制pod。

  • replicaset controller:监听replicaset的创建事件,创建相应的pod。是通过labelSelector标签选择器管理相应标签的pod。

3. scheduler为pod分配节点

scheduler监听到pod的创建事件,通过调度策略为pod分配调度节点。此调度流程分为预选、优选两步骤:

  • 预选:遍历k8s集群中所有的pod,根据节点亲和性、污点、容忍、硬件资源计算等,选出符合要求的ndoe最为预选node。

  • 优选:对预选出的node进行打分,选择分数最高的node,分配给pod。

最终将pod与node的绑定信息通过apiServer写入etcd中。

4. kubelet调度pod

kubelet监听到pod的调度事件,实际去运行pod,如调用docker创建容器。

kubelet会分别调用CRI,CNI,CSI:

  • CRI(Container Runtime Interface)容器运行时接口:负责拉镜像、创建、删除容器等,常用插件:
    • containerd
    • CRI-O
    • Docker Engine
  • CNI(Container Network Interface)容器网络接口:负责管理网络,为pod分配IP等,常用插件:
    • flannel
    • calico
  • CSI(Containter Storage Interface)容器存储接口:负责与外部存储通信,执行卷的附加、挂载等。

以上三种接口是k8s定义的标准,具体的实现都是由插件完成的。

参考:

Kubernetes 从提交 deployment 到 pod 运行的全过程

Kubernetes-Training/03 kubernetes 进阶实践.md

### Kubernetes Deployment Selector 不匹配 Template Labels 问题解析 在 Kubernetes 中,Deployment 的 `selector` 字段定义了控制器用来查找和管理 Pod 的标签选择器。而 `template.metadata.labels` 则是模板中定义的 Pod 标签。如果这两个字段之间的标签不一致,则会导致 `selector does not match template labels` 错误[^1]。 这种错误的根本原因是 Deployment 控制器无法找到与其 `selector` 匹配的 Pod 实例。因此即使部署中有正在运行的 Pod,它们也不会被识别为属于该 Deployment。 #### 示例配置 以下是一个典型的错误案例及其修复方式: ##### 错误配置 ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 2 selector: matchLabels: app: wrong-label template: metadata: labels: app: correct-label spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 ``` 在这个例子中,`selector.matchLabels.app` 设置为了 `wrong-label`,但是 `template.metadata.labels.app` 却设成了 `correct-label`。这就会引发上述提到的选择器不匹配的问题。 ##### 正确配置 要解决这个问题,只需确保两者保持一致性即可: ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 2 selector: matchLabels: app: web-server template: metadata: labels: app: web-server spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 ``` --- ### MinimumReplicasAvailable 错误详解 当发生 `MinimumReplicasAvailable` 错误时,意味着 Deployment 所期望的最小副本数量未能成功启动并进入 Ready 状态。这种情况可能由多种因素引起,包括但不限于以下几点: 1. **Pod 初始化失败** 如果 Pod 在启动阶段因某种原因(如镜像拉取失败、健康检查未通过等)而崩溃或卡住,则可能导致有效副本数不足。 2. **资源限制冲突** 当节点上的 CPU 或内存资源不足以支持新创建的 Pod 时,调度程序将拒绝分配这些 Pod 至相应节点上[^2]。 3. **LabelSelector 配置不当** 如前所述,如果 Deployment 的 LabelSelector 和 PodTemplate 的 Labels 不一致,也会间接造成此类错误,因为控制器找不到符合条件的目标对象来进行扩展操作。 4. **Cattle.io Creator 和 K8S.Kuboard.CN Labels 影响** 特定于 Rancher 或其他平台引入的额外元数据标注(例如 `cattle.io/creator=norman`, `k8s.kuboard.cn/*`) 并不会直接影响到基本的功能逻辑,但如果自定义脚本依赖特定的 label 结构来做进一步处理的话,就需要特别注意兼容性问题[^5]。 #### 故障排除指南 - 检查所有相关联的工作负载状态:`kubectl get all --namespace=<your-namespace>` - 获取具体 Pod 日志以了解内部执行状况:`kubectl logs <pod-name> -n <namespace>` - 描述有问题的对象来获得更多信息线索:`kubectl describe deployment/<deployment-name> -n <namespace>` --- ### 总结 对于 `selector does not match template labels` 错误,关键是确认 Deployment 的 `selector.matchLabels` 和 `template.metadata.labels` 是否完全相同;而对于 `MinimumReplicasAvailable` 错误,则需综合考虑多个潜在诱因逐一排查直至定位根本原因为止。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值