K8s集群完成部署后, 紧接着要进行POD的创建调度来支持工作负载。工作负载的建立调度才是k8s作为资源调度容器编排的重点功能. 看到这读者容易想起DevOps里与业务继承的自动编排, K8s与CICD的贯通以及自动化, 我们将在后续的篇章里覆盖, 本篇作为系列文章的第二篇, 首先要解决的是K8s的POD的创建与调度, 并了解相关概念进一步了解k8s。K8s的层级架构是k8s集群—Node (物理机或虚拟机) – POD – Container. 说到工作负载,先要了解容器和pod的概念容器: 容器是运行应用程序的独立运行环境里面包含应用代码以及它需要的所有依赖。容器与以前的虚拟机对应, 虚拟机通过Hypervisor 虚拟硬件,每个 VM 都有完整操作系统。容器共享宿主机操作系统内核。容器是为了解决以往虚拟机对硬件依赖,资源消耗大, 弹性扩缩容不便的问题应运而生.Pod Pod 就是 Kubernetes 中运行应用的最小单位相当于一个“应用运行的小房间”里面可以放一个或多个紧密协作的容器。Pod 是 Kubernetes 中最小的可部署和管理的计算单元代表集群中一个正在运行的应用进程。它不是单个容器而是一组共享网络、存储和运行环境的容器集合通常被调度到同一节点上并协同工作。把服务器想象成一栋楼的话, POD就像一个房间, 容器就是房间里执行任务的设备概念类比说明Node一栋楼一台服务器Pod一个房间应用运行的地方Container房间里的设备真正执行任务的程序一. POD的创建与调度过程:在 Kubernetes (k8s) 集群中Pod的创建与调度是一个涉及多个组件协同工作的过程。这个过程确保了Pod 能够被正确地创建、调度到合适的节点上并最终在节点上运行起来。以下是各个组件在此过程中的合作流程1.用户提交请求用户通过 kubectl 等客户端工具向 API Server 发送创建 Pod 的请求。请求通常包含 Pod 的配置信息如 YAML 文件。2.API Server验证与存储API Server 接收请求后首先进行验证如语法、权限、配额等。验证通过后API Server 将 Pod 的定义信息写入 etcd 数据库中。此时Pod 状态为 Pending未调度。3.4.Controller Manager监控与创建副本Controller Manager 组件监听 API Server 的事件。如果 Pod 是由 Deployment、ReplicaSet 等控制器管理的Controller Manager 会根据期望状态如副本数创建新的 Pod 副本并更新到 etcd 中。这一步可能发生在 Pod 初始创建或副本数量调整时。5. Scheduler监听与调度Scheduler 组件通过 Watch 机制监听 API Server专门寻找状态为 Pending 且尚未分配节点nodeName 为空的 Pod。它会根据一系列预选Predicates和优选Priorities策略来选择一个最合适的节点。预选(Predicates)过滤掉不满足 Pod 调度要求的节点。例如节点资源是否足够CPU、内存、节点标签是否匹配NodeSelector、NodeAffinity、Pod 是否容忍节点的污点Taints Tolerations等。优选(Priorities)对通过预选的节点进行打分考虑因素包括资源利用率如 LeastRequestedPriority、资源平衡如 BalancedResourceAllocation、镜像本地化ImageLocalityPriority等。最终选择得分最高的节点。6.Scheduler更新调度结果Scheduler 将选定的节点信息nodeName更新到 Pod 的定义中并通过 API Server 将此更新写入 etcd。这标志着 Pod 已被调度到指定节点。7.8.9Kubelet执行Pod创建每个节点上的 Kubelet 组件通过 Watch 机制监听 API Server获取分配给本节点的 Pod 信息。当 Kubelet 发现有 Pod 被调度到本节点时它会执行以下操作网络配置调用 CNIContainer Network Interface插件为 Pod 创建网络。容器运行时调用 CRIContainer Runtime Interface接口通过容器运行时如 Docker、containerd拉取镜像并创建容器。存储挂载如果 Pod 需要持久化存储Kubelet 会调用 CSIContainer Storage Interface接口挂载存储卷。状态监控Kubelet 持续监控 Pod 及其容器的运行状态并将状态信息上报给 API Server。10.状态同步与维护API Server 将 Pod 的最终状态如 Running更新到 etcd 中。Controller Manager 会持续监控 Pod 状态确保实际状态与期望状态一致。如果 Pod 崩溃或节点故障Controller Manager 会触发重新调度流程。整个流程中API Server 作为核心通信枢纽负责接收请求、存储状态、通知其他组件etcd作为分布式存储持久化保存集群状态Scheduler 负责决策调度Kubelet负责节点上的具体执行。各组件通过 API Server 和etcd 实现了信息同步和协同工作。二. POD创建调度实验示例:那么了解了POD了解了POD创建调度的过程, 我们来实际看一个POD创建调度的例子.1. 首先我们来看一个示例Yaml,保存为mysql-deploy.yaml(注意把注释注解内容去掉):apiVersion: apps/v1 #使用的Kubernetes API版本Deployment资源属于 apps/v1 组kind: Deployment #定义资源类型这里创建的是 Deployment 控制器metadata: #资源的元数据信息name: mysql # Deployment 的名称kubectl 中显示为 deployment/mysqlspec: # 资源的期望状态定义replicas: 1 # 期望运行的 Pod 副本数量这里只运行1个MySQL Podselector: # Deployment 用于查找并管理 Pod 的标签选择器matchLabels: # 使用 label 精确匹配方式app: mysql # 选择 labelapp:mysql 的 Pod 作为管理对象template: # Pod 模板Deployment 会按这个模板创建 Podmetadata: # Pod 的元数据labels: # Pod 的标签app: mysql # Pod 标签必须与 selector.matchLabels 一致spec: # Pod 的运行配置nodeSelector: # 节点选择器用于限制 Pod 运行在哪些 Node 上db: mysql # 只有带 label dbmysql 的 Node 才能运行此 Podcontainers: # Pod 内的容器列表- name: mysql # 容器名称image: mysql:8 # 使用的容器镜像DockerHub官方 MySQL 8resources: # 容器资源管理配置requests: # 最小资源请求调度时保证的资源memory: 2Gi # 至少需要 2GB 内存cpu: 1 # 至少需要 1 个CPU核心limits: # 容器可使用的最大资源限制memory: 4Gi # 最大可使用 4GB 内存超过会被 OOMKillcpu: 2 # 最大可使用 2 个CPU核心超过会被限速这里为了验证POD调度, 我们使用了nodeselector方式来指定特定Node运行mysql pod. 比如实验中,我们使用vm04node. 然后用给node打label的方式来实现node选择逻辑:Kubectl label node vm04node mysqltrue查看node的label情况:Kubectl get nodes –show-labels2. 在master上运行该命令: kubectl apply -f mysql-deploy.yaml3. 查看mysql 容器是否在vm04node上创建成功: kubectl get pods –o wide确认pod是调度到了vm04node.4.确认容器运行状态: kubectl logs mysql-xxx-xxx 看到mysqld:ready for connections, 说明Mysql 容器启动成功5. 查看容器内mysql是否正常起来以及是否可以正常连接: kubectl exec -it mysql-xxx-xxx容器内执行 mysql -h 127.0.0.1 –u root -p xxxxxx , 运行show databases; 命令展示数据库5. 删除当前的mysql pod : kubectl delete pod –l appmysql之后再次展示pod情况: kubectl get pods -A, 发现mysql 已有新的pod在运行, 说明mysql的deployment, 依据yaml定义在维护执行到这里就跑通了k8s pod的部署调度基本逻辑. 读者可以边实验边了解。后续系列文章中将陆续覆盖容器持久化, devops自动化等企业实践内容。欢迎大家关注生产力联盟, 掌握智能时代新质生产力.附录:Kubernetes Workload类型对比,下面整理Workload类型运行应用的资源。kind控制器主要用途是否有状态Pod身份扩容方式典型场景DeploymentDeployment Controller无状态应用否随机任意扩容Web APIStatefulSetStatefulSet Controller有状态应用是固定顺序扩容MySQLDaemonSetDaemonSet Controller每节点运行一个通常无状态随机自动随Node日志采集JobJob Controller一次性任务不适用临时完成后退出数据处理CronJobCronJob Controller定时任务不适用临时按时间触发定时备份ReplicaSetReplicaSet Controller保证Pod数量否随机任意Deployment底层
企业数字化底座-k8s企业实践系列第二篇pod创建调度
发布时间：2026/5/27 5:34:32
K8s集群完成部署后, 紧接着要进行POD的创建调度来支持工作负载。工作负载的建立调度才是k8s作为资源调度容器编排的重点功能. 看到这读者容易想起DevOps里与业务继承的自动编排, K8s与CICD的贯通以及自动化, 我们将在后续的篇章里覆盖, 本篇作为系列文章的第二篇, 首先要解决的是K8s的POD的创建与调度, 并了解相关概念进一步了解k8s。K8s的层级架构是k8s集群—Node (物理机或虚拟机) – POD – Container. 说到工作负载,先要了解容器和pod的概念容器: 容器是运行应用程序的独立运行环境里面包含应用代码以及它需要的所有依赖。容器与以前的虚拟机对应, 虚拟机通过Hypervisor 虚拟硬件,每个 VM 都有完整操作系统。容器共享宿主机操作系统内核。容器是为了解决以往虚拟机对硬件依赖,资源消耗大, 弹性扩缩容不便的问题应运而生.Pod Pod 就是 Kubernetes 中运行应用的最小单位相当于一个“应用运行的小房间”里面可以放一个或多个紧密协作的容器。Pod 是 Kubernetes 中最小的可部署和管理的计算单元代表集群中一个正在运行的应用进程。它不是单个容器而是一组共享网络、存储和运行环境的容器集合通常被调度到同一节点上并协同工作。把服务器想象成一栋楼的话, POD就像一个房间, 容器就是房间里执行任务的设备概念类比说明Node一栋楼一台服务器Pod一个房间应用运行的地方Container房间里的设备真正执行任务的程序一. POD的创建与调度过程:在 Kubernetes (k8s) 集群中Pod的创建与调度是一个涉及多个组件协同工作的过程。这个过程确保了Pod 能够被正确地创建、调度到合适的节点上并最终在节点上运行起来。以下是各个组件在此过程中的合作流程1.用户提交请求用户通过 kubectl 等客户端工具向 API Server 发送创建 Pod 的请求。请求通常包含 Pod 的配置信息如 YAML 文件。2.API Server验证与存储API Server 接收请求后首先进行验证如语法、权限、配额等。验证通过后API Server 将 Pod 的定义信息写入 etcd 数据库中。此时Pod 状态为 Pending未调度。3.4.Controller Manager监控与创建副本Controller Manager 组件监听 API Server 的事件。如果 Pod 是由 Deployment、ReplicaSet 等控制器管理的Controller Manager 会根据期望状态如副本数创建新的 Pod 副本并更新到 etcd 中。这一步可能发生在 Pod 初始创建或副本数量调整时。5. Scheduler监听与调度Scheduler 组件通过 Watch 机制监听 API Server专门寻找状态为 Pending 且尚未分配节点nodeName 为空的 Pod。它会根据一系列预选Predicates和优选Priorities策略来选择一个最合适的节点。预选(Predicates)过滤掉不满足 Pod 调度要求的节点。例如节点资源是否足够CPU、内存、节点标签是否匹配NodeSelector、NodeAffinity、Pod 是否容忍节点的污点Taints Tolerations等。优选(Priorities)对通过预选的节点进行打分考虑因素包括资源利用率如 LeastRequestedPriority、资源平衡如 BalancedResourceAllocation、镜像本地化ImageLocalityPriority等。最终选择得分最高的节点。6.Scheduler更新调度结果Scheduler 将选定的节点信息nodeName更新到 Pod 的定义中并通过 API Server 将此更新写入 etcd。这标志着 Pod 已被调度到指定节点。7.8.9Kubelet执行Pod创建每个节点上的 Kubelet 组件通过 Watch 机制监听 API Server获取分配给本节点的 Pod 信息。当 Kubelet 发现有 Pod 被调度到本节点时它会执行以下操作网络配置调用 CNIContainer Network Interface插件为 Pod 创建网络。容器运行时调用 CRIContainer Runtime Interface接口通过容器运行时如 Docker、containerd拉取镜像并创建容器。存储挂载如果 Pod 需要持久化存储Kubelet 会调用 CSIContainer Storage Interface接口挂载存储卷。状态监控Kubelet 持续监控 Pod 及其容器的运行状态并将状态信息上报给 API Server。10.状态同步与维护API Server 将 Pod 的最终状态如 Running更新到 etcd 中。Controller Manager 会持续监控 Pod 状态确保实际状态与期望状态一致。如果 Pod 崩溃或节点故障Controller Manager 会触发重新调度流程。整个流程中API Server 作为核心通信枢纽负责接收请求、存储状态、通知其他组件etcd作为分布式存储持久化保存集群状态Scheduler 负责决策调度Kubelet负责节点上的具体执行。各组件通过 API Server 和etcd 实现了信息同步和协同工作。二. POD创建调度实验示例:那么了解了POD了解了POD创建调度的过程, 我们来实际看一个POD创建调度的例子.1. 首先我们来看一个示例Yaml,保存为mysql-deploy.yaml(注意把注释注解内容去掉):apiVersion: apps/v1 #使用的Kubernetes API版本Deployment资源属于 apps/v1 组kind: Deployment #定义资源类型这里创建的是 Deployment 控制器metadata: #资源的元数据信息name: mysql # Deployment 的名称kubectl 中显示为 deployment/mysqlspec: # 资源的期望状态定义replicas: 1 # 期望运行的 Pod 副本数量这里只运行1个MySQL Podselector: # Deployment 用于查找并管理 Pod 的标签选择器matchLabels: # 使用 label 精确匹配方式app: mysql # 选择 labelapp:mysql 的 Pod 作为管理对象template: # Pod 模板Deployment 会按这个模板创建 Podmetadata: # Pod 的元数据labels: # Pod 的标签app: mysql # Pod 标签必须与 selector.matchLabels 一致spec: # Pod 的运行配置nodeSelector: # 节点选择器用于限制 Pod 运行在哪些 Node 上db: mysql # 只有带 label dbmysql 的 Node 才能运行此 Podcontainers: # Pod 内的容器列表- name: mysql # 容器名称image: mysql:8 # 使用的容器镜像DockerHub官方 MySQL 8resources: # 容器资源管理配置requests: # 最小资源请求调度时保证的资源memory: 2Gi # 至少需要 2GB 内存cpu: 1 # 至少需要 1 个CPU核心limits: # 容器可使用的最大资源限制memory: 4Gi # 最大可使用 4GB 内存超过会被 OOMKillcpu: 2 # 最大可使用 2 个CPU核心超过会被限速这里为了验证POD调度, 我们使用了nodeselector方式来指定特定Node运行mysql pod. 比如实验中,我们使用vm04node. 然后用给node打label的方式来实现node选择逻辑:Kubectl label node vm04node mysqltrue查看node的label情况:Kubectl get nodes –show-labels2. 在master上运行该命令: kubectl apply -f mysql-deploy.yaml3. 查看mysql 容器是否在vm04node上创建成功: kubectl get pods –o wide确认pod是调度到了vm04node.4.确认容器运行状态: kubectl logs mysql-xxx-xxx 看到mysqld:ready for connections, 说明Mysql 容器启动成功5. 查看容器内mysql是否正常起来以及是否可以正常连接: kubectl exec -it mysql-xxx-xxx容器内执行 mysql -h 127.0.0.1 –u root -p xxxxxx , 运行show databases; 命令展示数据库5. 删除当前的mysql pod : kubectl delete pod –l appmysql之后再次展示pod情况: kubectl get pods -A, 发现mysql 已有新的pod在运行, 说明mysql的deployment, 依据yaml定义在维护执行到这里就跑通了k8s pod的部署调度基本逻辑. 读者可以边实验边了解。后续系列文章中将陆续覆盖容器持久化, devops自动化等企业实践内容。欢迎大家关注生产力联盟, 掌握智能时代新质生产力.附录:Kubernetes Workload类型对比,下面整理Workload类型运行应用的资源。kind控制器主要用途是否有状态Pod身份扩容方式典型场景DeploymentDeployment Controller无状态应用否随机任意扩容Web APIStatefulSetStatefulSet Controller有状态应用是固定顺序扩容MySQLDaemonSetDaemonSet Controller每节点运行一个通常无状态随机自动随Node日志采集JobJob Controller一次性任务不适用临时完成后退出数据处理CronJobCronJob Controller定时任务不适用临时按时间触发定时备份ReplicaSetReplicaSet Controller保证Pod数量否随机任意Deployment底层
