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 之前启动。