Kubernetes 之资源对象 Pod详解
官网:https://kubernetes.io/docs/concepts/workloads/pods/
简介
Pod 是 Kubernetes 中最小的可部署、可调度单元。 Kubernetes 不是直接管理单个容器,而是管理 Pod。一个 Pod 里面可以有一个容器,也可以有多个紧密协作的容器。这些容器共享存储、网络资源和运行规范;Pod 内的内容会被共同调度到同一台 Node 上运行。
Pod 内部三种容器详解
(1) Pause 基础设施容器(隐形容器,必存在,yaml 不配置)
特点:
- 镜像:k8s.gcr.io/pause,很小,只有几百 KB
- 所有 Pod 自动生成,不用在 yaml 定义,看不到配置
- 整个 Pod 的网络基石
核心作用:
- 创建 Pod 网络命名空间:pause 占住 net、uts 命名空间,后面所有业务 /init 容器加入这个网络,实现同 Pod 共用一个 IP、localhost互通
- 共享 PID、挂载命名空间
- 僵尸进程回收:回收容器产生的孤儿进程,避免容器残留
- 一句话:Pause=Pod 的网络底座,没有它就没有 PodIP
(2) InitContainer 初始化容器(initContainers 字段配置)
运行规则:
- 串行执行,从上到下逐个运行,上一个 init 成功退出,才运行下一个
- 所有 Init 全部正常退出 (exit=0) 之后,才启动业务容器
- 任意 Init 异常报错退出,Pod 反复重启(CrashLoopBackOff),业务永远起不来
常用场景:
- 等待依赖服务就绪:等 MySQL、CoreDNS 启动完再启业务
- 拉取配置文件、解压资源到共享目录
- 目录权限初始化、预创建文件
简易 yaml 片段 展示具体位置:
spec: initContainers: name: init-wait image: busybox command: ["sh","-c","until nslookup mysql;do sleep 2;done"] #等待mysql解析成功 containers: name: nginx image: nginx(3) 业务容器 containers(yaml 的 containers 数组,分两种:主容器 + Sidecar 边车)
Init 全部完成后,所有 containers 里的容器并行同时启动
a. 主业务容器
- 跑核心业务:Nginx、Java 项目、MySQL,实现产品功能。
b .Sidecar 边车容器(本质还是业务容器,分工辅助)
- 和主容器同网络、同存储,不处理业务,只做配套运维工作
- 日志边车:Filebeat 采集主容器日志,推送 ELK
- 代理边车:Envoy/Istio 做流量管控、熔断限流
- 配置同步边车:实时同步配置文件
- 示例:Nginx (主)+Filebeat (边车),共用 emptyDir 日志目录。
完整启动时序总结
- kubelet 创建 Pause 容器 → 分配 PodIP、初始化网络
- 依次运行所有 Init 容器,全部执行成功退出
- 一次性启动所有 containers(主 + 边车)
配置文件 展示:
spec: initContainers: # 初始化容器,串行先跑完 - name: init-xxx image: busybox containers: # 业务+边车全都在这,并行启动 # 主业务容器 - name: nginx-main image: nginx ports: - containerPort:80 # sidecar边车容器(同pod,共享网络/存储) - name: filebeat-sidecar image: filebeat:7.9 volumeMounts: - name: logdir mountPath: /usr/local/nginx/logsPod 分类
1 .静态 Pod(Static Pod)
静态 Pod 是节点 kubelet 直接管理的 Pod,完全不经过 API Server、调度器、控制器,仅靠节点本地 yaml 文件驱动运行
kubeadm 搭建集群时,控制平面组件(apiserver、etcd、scheduler、controller-manager)全部以静态 Pod 运行。目录默认: /etc/kubernetes/manifests 。
静态 Pod 始终都会绑定到特定节点的 Kubelet 上。这些 Pod 在节点的特定目录中定义(默认:/etc/kubernetes/manifests ),kubelet 会监视并管理这些 Pod 的生命周期。
静态 Pod 特性:
- 无控制器管理:不由 Deployment、ReplicaSet 等控制器管理;
- 节点级别:仅存在于定义它们的特定节点上;
- API 服务器可见:可在集群中通过 kubectl get pods 查看;
- 无法通过 kubectl 管理:只能通过修改节点上的配置文件进行操作;
- 高优先级:在控制器管理的 Pod 之前启动。
