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