k8s pod 管理

1、命名空间管理

命名空间(Namespace)是 Kubernetes 中实现集群资源逻辑隔离的核心机制,可将一个物理集群划分为多个虚拟集群。不同命名空间中的资源名称可以重复,资源配额、权限策略均可按命名空间独立配置,非常适合多团队共享集群、多环境(开发 / 测试 / 生产)隔离、资源精细化管控等场景。

Kubernetes 集群默认内置 4 个系统命名空间,各司其职:

  • default:用户未指定命名空间时,资源默认创建在此空间中,适合日常测试与小规模应用。
  • kube-system:存放 Kubernetes 集群核心组件,如 kube-apiserver、kube-controller-manager、CoreDNS、网络插件等,属于集群关键管控资源,普通业务不建议部署在此空间。
  • kube-public:该命名空间下的资源对所有用户(包括未认证用户)可读,通常用于存放集群公共信息、全局配置等。
  • kube-node-lease:用于存储节点心跳租约对象(Lease),提升节点心跳检测的性能与效率,是集群节点状态管理的核心组件。

查看命名空间(名称、状态、存在时长)

root@k8s-master \~# kubectl get namespaces

创建命名空间(支持小写字母、数字和连字符)

root@k8s-master \~# kubectl create namespace timinglee

删除命名空间(会删除ns内所有资源)

root@k8s-master \~# kubectl delete namespaces timinglee

2、pod管理

Pod 是 Kubernetes 中最小的调度与运行单元 ,它不是单个容器,而是一组(一个或多个)共享网络、存储栈的容器的集合。同一个 Pod 内的容器可以通过 localhost 互相访问,共享挂载卷,拥有独立的 Pod IP。日常业务中绝大多数 Pod 由 Deployment、StatefulSet 等控制器管理,裸 Pod(无控制器管理)不具备自愈与扩缩容能力。

查看pod,-o wide 显示节点、PodIP

kubectl get pods -o wide

命令式创建pod

kubectl run lee --image nginx:latest

查看pod详细事件(排错核心,ImagePullBackOff镜像拉取失败看这里)

kubectl describe pods error

删除单个pod

kubectl delete pods error

删除当前命名空间所有pod

kubectl delete pods --all

3、kubectl 常用实操命令

kubectl 是 Kubernetes 的命令行管理工具,支持命令式对象管理、命令式对象配置、声明式对象配置三种操作模式。以下为日常运维中最高频的资源管理命令,覆盖部署、更新、排障、运维全流程。

#create:命令式创建deployment

kubectl create deployment webcluster --replicas 2 --image myapp:v1

#edit:直接编辑在线资源yaml

kubectl edit deployments.apps webcluster

#patch:json片段修改资源

kubectl patch deployments.apps webcluster -p '{"spec":{"replicas":1}}'

#expose:创建service暴露应用

kubectl expose deployment webcluster --port 80 --target-port 80

#logs:查看pod容器日志

kubectl logs pods/webcluster-77c87d9946-gh9v7

#attach:连接容器标准输入输出

kubectl attach pods/testpod -it

#exec:进入容器执行命令(最常用)

kubectl exec -it pods/testpod -c testpod -- /bin/bash

#cp:宿主机和pod之间拷贝文件

kubectl cp testpod:/usr/share/nginx/html/index.html /mnt/test

kubectl cp /mnt/index.html testpod:/usr/share/nginx/html/index.html

#rollout:版本更新、重启、历史

kubectl rollout status deployment webcluster

kubectl rollout restart deployment webcluster

kubectl rollout history deployment webcluster

#scale:扩缩副本数

kubectl scale deployment webcluster --replicas 4

#label:增删标签,`key-`代表删除标签

kubectl label pods webcluster-9787d97f6-zl6q2 app-

kubectl label pods webcluster-9787d97f6-zl6q2 app=webcluster

4、YAML 声明式编写 Pod

声明式配置是 Kubernetes 推荐的生产级使用方式,通过 YAML 文件定义资源的期望状态,使用 kubectl apply -f 文件名.yaml 提交,具备幂等性(多次提交结果一致),便于版本控制、审计与复用。以下为 Pod 常见配置场景的 YAML 示例与说明

Pod 多容器

多容器是 Pod 的核心设计之一,遵循「一个 Pod 一个业务主容器 + 辅助容器」的边车(Sidecar)模式。同一个 Pod 内的所有容器共享网络命名空间(可通过 localhost 互访)、共享存储卷、共享主机名。辅助容器常见用途包括:日志收集、流量代理、配置同步、健康检查辅助等。

apiVersion: v1

kind: Pod

metadata:

labels:

run: testpod

name: testpod

spec:

containers:

  • image: myapp:v1

name: myapp1

  • image: busyboxplus:latest

name: busybox

command:

  • /bin/sh

  • -c

  • sleep 10000

hostPort 端口映射

hostPort 会将容器端口直接映射到 Pod 所在宿主机的端口上,外部可通过「节点 IP:hostPort」直接访问该容器。 注意事项:

  1. 同一宿主机上同一 hostPort 只能绑定一个 Pod,存在端口冲突风险,无法在单节点上多副本部署;
  2. Pod 漂移到其他节点后,访问地址会随节点 IP 变化,不适合作为稳定服务入口;
  3. 仅适合临时调试、单体组件场景,生产环境推荐用 Service 暴露服务。

apiVersion: v1

kind: Pod

metadata:

labels:

run: testpod

name: testpod

spec:

containers:

  • image: myapp:v1

name: myapp1

ports:

  • name: http

containerPort: 80 #容器内部端口

hostPort: 80 #宿主机节点端口

protocol: TCP

env 环境变量注入

环境变量是向容器内传递配置的最简单方式,示例中为字面量直接赋值。除了静态值,环境变量还支持从 ConfigMap、Secret、字段引用(如 Pod 名称、节点 IP)等动态获取,是应用配置管理的基础方式之一。

apiVersion: v1

kind: Pod

metadata:

labels:

run: mysql

name: mysql

spec:

containers:

  • image: mysql:8.0

name: mysql8

env:

  • name: MYSQL_ROOT_PASSWORD

value: lee

nodeSelector 指定调度节点

nodeSelector 是最简单的节点定向调度方式,通过节点标签匹配,强制将 Pod 调度到带有对应标签的节点上。示例中使用 Kubernetes 内置的主机名标签 kubernetes.io/hostname,也可自定义节点标签实现业务分组、专属节点池调度。更灵活的调度策略可通过节点亲和性、Pod 亲和性实现。

apiVersion: v1

kind: Pod

metadata:

labels:

run: mysql

name: mysql

spec:

nodeSelector:

kubernetes.io/hostname: k8s-node2

containers:

  • image: mysql:8.0

name: mysql

hostNetwork 共享宿主机网络栈

开启 hostNetwork: true 后,Pod 将直接使用宿主机的网络命名空间,容器的网络与宿主机完全一致,端口直接监听在宿主机上,网络性能损耗最低。 注意事项:

  1. 网络隔离性完全丧失,容器可访问宿主机全部网络栈,存在安全风险;
  2. 容器端口与宿主机端口直接冲突,同端口无法多副本部署;
  3. 仅适用于需要操作主机网络的组件,如网络插件、节点监控、流量采集工具等,普通业务不建议开启。

piVersion: v1

kind: Pod

metadata:

labels:

run: testpod

name: testpod

spec:

hostNetwork: true

containers:

  • image: busybox:latest

name: busybox

command:

  • /bin/sh

  • -c

  • sleep 10000

5、Pod QoS 资源服务质量等级

QoS(Quality of Service,服务质量)是 Kubernetes 为 Pod 划分的资源优先级等级,由 Pod 内容器的 requests(资源申请)和 limits(资源上限)配置共同决定。当节点出现资源不足(尤其是内存不足)时,kubelet 会按照 QoS 等级从低到高依次驱逐 Pod,优先保证高优先级业务的运行。

BestEffort:不配置 requests/limits,优先级最低

BestEffort 等级的 Pod 没有任何资源申请与限制,节点资源充足时可尽可能使用空闲资源,资源紧张时会被最先驱逐。适合非核心、可中断的低优先级任务,如临时测试、批量计算任务等。

resources: {} #不写resources字段

Burstable:requests < limits,优先级中等

resources:

limits:

cpu: 700m

memory: 200M

requests:

cpu: 500m

memory: 100M

Guaranteed:requests 与 limits 完全相等,优先级最高

Guaranteed 等级的 Pod 资源申请与上限完全一致,Kubernetes 会为其完整预留对应资源,不与其他 Pod 共享。该等级 Pod 优先级最高,节点资源不足时几乎不会被驱逐,仅在系统 OOM 且无更低等级 Pod 可驱逐时才会被影响。适合数据库、核心业务服务等对稳定性要求极高的应用。

补充说明:QoS 是 Pod 级别的属性,由 Pod 中所有容器的资源配置共同决定;只要有一个容器不符合规则,就会影响整个 Pod 的 QoS 等级。
resources:

limits:

cpu: 500m

memory: 100M

requests:

cpu: 500m

memory: 100M

6、restartPolicy 容器重启策略(Pod 级别)

重启策略定义了当 Pod 内容器退出时,kubelet 的处理行为,属于 Pod 级别的全局配置,对 Pod 内所有容器生效。重启是指在当前节点本地重启容器,不会重建 Pod,Pod IP 与所在节点保持不变。

Always:无论容器怎么退出,总是重启(deployment 默认)

无论容器是正常退出(退出码 0)还是异常退出(退出码非 0),kubelet 都会自动重启容器。适用于需要长期持续运行的服务类应用,如 Web 服务、缓存、数据库等,是 Deployment 控制器的默认重启策略。

OnFailure:容器异常退出(返回码≠0)才重启;正常退出不重启

仅当容器以非 0 状态码异常退出时,才触发重启;若容器正常执行完成退出(退出码 0),则不再重启。适用于一次性批处理任务,执行成功即结束,失败则自动重试,是 Job 控制器的常用策略。

Never:无论退出状态,永远不重启(Job 常用)

无论容器退出状态如何,都不会重启容器。Pod 中所有容器退出后,Pod 进入终态(Succeeded 或 Failed)。适合单次执行、无需重试的任务,或需要自行管理重启逻辑的场景。

apiVersion: v1

kind: Pod

metadata:

labels:

run: testpod

name: testpod

spec:

restartPolicy: OnFailure

containers:

  • image: busybox:latest

name: busybox

command: "/bin/sh","-c","sleep 30"

7、Pod 生命周期

Pod 拥有完整的生命周期,从创建到终止会经历 Pending(等待调度)、Running(运行中)、Succeeded(成功终止)、Failed(异常终止)、Unknown(状态未知)几个阶段。除了主业务容器,Kubernetes 还提供了初始化容器、生命周期探针等机制,精细化管控 Pod 的启动、运行与健康状态。

init 容器

初始化容器(Init Container)是在业务容器启动前运行的容器,用于完成启动前的准备工作。 核心特点:

  1. 串行执行:多个 Init 容器按定义顺序依次执行,前一个执行成功后才会启动下一个;
  2. 必须全部成功:所有 Init 容器都执行成功后,才会启动主业务容器;
  3. 不支持就绪探针:Init 容器只需执行完成,无需持续运行;
  4. 资源计入 Pod 总申请:Init 容器的资源请求会纳入 Pod 调度时的资源计算。

initContainers:初始化容器,必须全部成功执行完毕后,才启动业务容器,常用于等待依赖、初始化配置。

apiVersion: v1

kind: Pod

metadata:

labels:

run: webserver

name: webserver

spec:

initContainers:

  • name: busybox

image: busybox:latest

command:

  • /bin/sh

  • -c

  • "until test -e /testfile;do echo wating for myservice; sleep 2;done"

containers:

  • image: myapp:v1

name: webserver

restartPolicy: Always

livenessProbe 存活探针

存活探针用于检测容器是否处于正常运行状态。如果探测失败,kubelet 会判定容器异常,并自动重启该容器,以此实现故障自愈。

支持三种探测方式:

  • exec:在容器内执行指定命令,命令退出码为 0 则判定成功,适合自定义健康检查逻辑;
  • tcpSocket:尝试连接容器指定端口,能建立 TCP 连接则判定成功,适合端口类服务;
  • httpGet:向容器指定端口与路径发送 HTTP GET 请求,返回状态码在 200~399 之间则判定成功,适合 Web 服务。

关键参数说明:

  • initialDelaySeconds:容器启动后延迟多久开始第一次探测,需适配应用启动耗时,避免应用未就绪就被误杀;
  • periodSeconds:两次探测的间隔时间;
  • timeoutSeconds:单次探测的超时时间;
  • 另有 failureThreshold(连续失败多少次后触发重启)、successThreshold(连续成功多少次后判定恢复正常)。

注意:存活探针配置不当会导致容器频繁误重启,需结合应用实际启动速度合理设置参数。

containers:

  • image: myapp:v1

name: testpod

livenessProbe:

tcpSocket:

port: 80

initialDelaySeconds: 3 #启动后多久第一次探测

periodSeconds: 1 #探测间隔

timeoutSeconds: 1 #探测超时

readinessProbe 就绪探针

就绪探针用于检测容器内的业务是否具备对外服务的能力。探测失败时,不会重启容器,而是将该 Pod 从对应 Service 的端点列表中摘除,停止接收新流量;探测恢复成功后,再重新加入 Service 端点,恢复流量。

核心作用:

  1. 保证滚动更新时,新 Pod 完全就绪后才接入流量,旧 Pod 才开始下线,避免服务中断;
  2. 业务内部故障时自动摘流,避免将请求转发给异常实例。

探测方式与参数配置与存活探针完全一致,二者常配合使用:存活探针保证容器活着,就绪探针保证服务可用。

补充:此外还有 startupProbe(启动探针),专门用于启动缓慢的应用。启动探针成功前,存活探针与就绪探针都不会生效;启动探针探测成功后,自动交由存活探针接管,避免慢启动应用在启动阶段被存活探针误重启。
containers:

  • image: myapp:v1

name: webserver

readinessProbe:

httpGet:

path: /index.html

port: 80

initialDelaySeconds: 3

periodSeconds: 2

timeoutSeconds: 1

8、Deployment 版本升级与回退

Deployment 是 Kubernetes 中最常用的无状态应用控制器,它通过管理 ReplicaSet(副本集)来实现 Pod 的滚动更新、版本回溯、弹性扩缩容。每次更新 Deployment 配置(如镜像版本、环境变量),都会生成一个新的 ReplicaSet 版本,历史版本会被保留,支持随时回退,保证发布过程的可控与可回滚。

滚动更新核心原理:更新过程中,Deployment 会逐步增加新版本 ReplicaSet 的副本数,同时减少旧版本 ReplicaSet 的副本数,全程保证可用副本数维持在预期范围内,实现服务不中断升级。更新速度由 maxSurge(最大超出副本数)和 maxUnavailable(最大不可用副本数)两个参数控制。

#升级镜像

kubectl set image deployments webcluster myapp=myapp:v2

#记录更新说明,写入revision

kubectl annotate deployment webcluster kubernetes.io/change-cause="myappv2" --overwrite

#查看版本历史

kubectl rollout history deployment webcluster

#回退到指定版本

kubectl rollout undo deployment webcluster --to-revision=1

#暂停更新

kubectl rollout pause deployment webcluster

#恢复更新

kubectl rollout resume deployment webcluster

总结

本文系统梳理了 Kubernetes 基础运维的核心知识点,从命名空间的资源隔离机制、Pod 的基础操作与声明式配置,到资源服务质量等级、容器生命周期管控,再到 Deployment 的滚动发布与版本回退,覆盖了日常集群运维中最高频的操作与底层核心原理。

这些内容是 Kubernetes 运维的入门基本功,既是日常应用部署、故障排查、版本迭代的实操依据,也是理解集群调度逻辑、服务高可用机制的基础。熟练掌握上述命令与配置规则,可高效完成绝大多数无状态应用的部署与运维工作,为后续深入学习集群调度、有状态服务管理、可观测性与自动化运维打下坚实基础。

相关推荐
Dear~yxy2 小时前
k8s的pod
云原生·容器·kubernetes
Dear~yxy2 小时前
k8s中的控制器管理
云原生·容器·kubernetes
江湖有缘2 小时前
Docker开源项目: 基于Ubuntu系统部署ExpenseOwl自托管记账工具实战教程
ubuntu·docker·开源
众人皆醒我独醉2 小时前
自动扩缩容:KPA/HPA/KEDA 三条路径
面试·kubernetes·llm
qizhideyu3 小时前
kubernetes中的pod管理
云原生·容器·kubernetes
lxw20230271163 小时前
k8s的pod管理
linux·容器·kubernetes
Yiiz.4 小时前
Kubernetes Pod 与控制器知识点
云原生·容器·kubernetes
高磊20054 小时前
Kubernetes Pod 管理实战详解
linux·容器·kubernetes
流星白龙4 小时前
【Docker】9.Docker 镜像仓库实战
运维·docker·容器