K8S（四）—— Kubectl从入门到精通：K8s资源管理与项目生命周期实战指南

前言

在 Kubernetes（简称 k8s）生态中，kubectl 是与集群交互的核心命令行工具，它充当了开发者/运维人员与 k8s API Server 之间的“桥梁”——将用户指令转化为 API Server 可识别的请求，进而实现对集群资源（Pod、Deployment、Service 等）的全生命周期管理。

无论是日常的资源查询、Pod 调试，还是企业级的应用发布（如金丝雀、蓝绿发布），kubectl 都是不可或缺的工具。本文将从 资源管理思想 出发，系统梳理 kubectl 的核心用法，覆盖陈述式与声明式两种管理方式、项目全生命周期操作（创建-发布-更新-回滚-删除）及主流发布策略，帮助读者从“会用”到“精通”kubectl。

本文配套参考：Kubernetes 中文文档

一、kubectl 与 K8s 资源管理核心概述

1.1 K8s 资源管理的两种核心方式

K8s 对资源的管理本质上分为两类思想，对应不同的使用场景：

管理方式	核心逻辑	适用场景	优势	劣势
陈述式	命令驱动：直接通过 kubectl 命令指定“做什么”（如创建 Pod、删除 Service）	简单操作（如临时查询、快速创建单个资源）、新手入门	命令简洁、即时生效、学习成本低	不便于复杂配置修改、难以批量管理、无版本化记录
声明式	配置驱动：通过 YAML/JSON 配置清单定义“要什么状态”，kubectl 确保集群状态与配置一致	生产环境、复杂资源配置、批量管理、版本控制	支持版本化（如 Git 管理 YAML）、便于团队协作、修改精准	学习成本高、需理解配置清单语法

1.2 kubectl 工具基础

kubectl 是 Kubernetes 官方提供的命令行工具，主要用于与集群的 API Server 进行交互。它能够将用户输入的命令转换为 API Server 可识别的请求格式，从而实现对 Kubernetes 各类资源的高效管理。

1.2.1 kubectl 的核心作用

kubectl 是 k8s 官方 CLI 工具，核心功能包括：

1. 与 API Server 建立通信，传递用户指令；
2. 解析命令行参数，生成符合 k8s API 规范的请求；
3. 接收 API Server 响应，以友好格式（文本、JSON、YAML）展示结果。

1.2.2 基础命令与环境配置

• 查看帮助文档：获取所有命令及参数说明（最常用的“工具书”）

  kubectl --help
  # 查看具体命令的帮助（如 expose）
  kubectl expose --help
  

• 查看版本信息：确认 kubectl 与集群的版本兼容性（k8s 版本兼容原则：kubectl 版本与集群版本差距不超过 1 个小版本）

  kubectl version
  

  

• 查看资源对象简写：记忆常用资源的简写（如 pod 简写为 po、deployment 简写为 deploy），提升操作效率

  kubectl api-resources
  

• 查看集群信息：确认集群健康状态及 API Server 地址

  kubectl cluster-info
  

  

• 配置自动补全：避免重复输入长命令（适用于 Bash 终端）

  source <(kubectl completion bash)
  # 永久生效（需写入 ~/.bashrc）
  echo "source <(kubectl completion bash)" >> ~/.bashrc
  

• 查看 Node 节点日志：排查 Node 节点（如 kubelet 服务）故障

  journalctl -u kubelet -f  # -f 表示实时跟踪日志
  

二、陈述式资源管理：命令驱动的便捷操作

陈述式管理以“命令”为核心，适合快速完成简单操作。本节按基础查询、生命周期管理、发布策略三大模块展开。

2.1 基础信息查看：kubectl get 与辅助命令

2.1.1 核心语法

kubectl get 是最常用的查询命令，语法格式如下：

kubectl get <资源类型/资源名称> [-o 输出格式] [-n 命名空间] [可选参数]

• <资源类型>：如 pod（Pod）、deployment（Deployment）、service（Service）、namespace（命名空间），也可使用 all（查看核心资源，非全部）；
• -o：指定输出格式，常用 wide（显示详细信息，如 Pod 所在 Node、IP）、yaml（YAML 配置）、json（JSON 配置）；
• -n：指定命名空间（默认 default），-A 或 --all-namespaces 表示查看所有命名空间资源；
• 可选参数：--show-labels（显示资源标签）、-l 标签值（模糊查询，如-l app ，仅显示标签为app的资源）、-l 标签键=标签值（按标签筛选资源，如 -l app=nginx）。

2.1.2 关键场景示例

1、查看 Master 节点状态：确认 k8s 核心组件（scheduler、controller-manager、etcd）健康状态

kubectl get componentstatuses
# 简写
kubectl get cs

2、命名空间操作：命名空间用于隔离资源（如开发环境 dev、生产环境 prod），支持不同命名空间相同类型资源重名

# 查看所有命名空间
kubectl get namespace
# 简写
kubectl get ns# 查看default命名空间的所有资源
kubectl get all [-n default]

# 创建命名空间（如 app）
kubectl create ns app# 删除命名空间（会删除该命名空间下所有资源，需谨慎）
kubectl delete ns app

3、创建副本控制器deployment
在命名空间kube-public 创建副本控制器（deployment）来启动Pod（nginx-cwh）

kubectl create deployment nginx-cwh --image=nginx  -n kube-public  

注意：create deployment与run的区别

• kubectl create deployment：创建一个Deployment资源，它会管理一组Pod副本，并提供滚动更新、回滚等功能。
• kubectl run 自主式的pod 静态：创建自主式Pod（standalone pod），这种Pod不受控制器管理，是静态的临时性资源。如果Pod被删除，不会自动重建。

4、查看 Pod 资源：查看指定命名空间的 Pod 状态（Running/Error/CrashLoopBackOff 等）

# 查看 kube-public 命名空间的 Pod，显示详细信息
kubectl get pods -n kube-public -o wide# 按标签筛选（如筛选标签 app=nginx-cwh 的 Pod）
kubectl get pods -l app=nginx-cwh -A

5、查看资源详情：kubectl describe 用于查看资源的详细 metadata（如事件、关联资源、配置信息），排查故障时常用

# 查看 deployment nginx-cwh 的详情（kube-public 命名空间）
kubectl describe deployment nginx-cwh -n kube-public# 查看某个 Pod 的详情（如排查 Pod 启动失败原因）
kubectl describe pod nginx-cwh-556d6766bf-chkld -n kube-public

6、 进入 Pod 容器：kubectl exec 支持跨主机登录容器（区别于 docker exec 只能在容器所在主机操作）

# -it 表示交互式终端，bash 为容器内的 Shell
kubectl exec -it nginx-cwh-556d6766bf-chkld bash -n kube-public

7、删除（重启）pod资源

#删除（重启）pod资源，由于存在deployment/rc之类的副本控制器，删除pod也会重新拉起来
kubectl delete pod nginx-cwh-556d6766bf-chkld -n kube-public#若pod无法删除，总是处于terminate状态，则要强行删除pod
kubectl delete pod <pod-name> -n <namespace> --force --grace-period=0
#grace-period表示过渡存活期，默认30s，在删除pod之前允许POD慢慢终止其上的容器进程，从而优雅退出，0表示立即终止pod

8、扩缩容

kubectl scale deployment nginx-cwh --replicas=2 -n kube-public	# 扩容
kubectl scale deployment nginx-cwh --replicas=1 -n kube-public	# 缩容

9、删除副本控制器

kubectl delete deployment nginx-cwh -n kube-public
kubectl delete deployment/nginx-cwh -n kube-public

2.2 项目全生命周期管理：从创建到删除

项目生命周期涵盖创建-发布-更新-回滚-删除5 个阶段，每个阶段对应特定的 kubectl 命令。

2.2.1 阶段 1：创建（kubectl create）

kubectl create 用于创建资源（如 Deployment、Pod、Service），核心是“定义资源的初始状态”。

kubectl create命令：

• 创建并运行一个或多个容器镜像。
• 创建一个deployment 或job 来管理容器。

# kubectl create命令帮助
kubectl create --help

示例：创建 Nginx Deployment
创建一个名为 nginx 的 Deployment，使用 nginx:1.14 镜像，暴露容器 80 端口，副本数 3（确保高可用）：

kubectl create deployment nginx --image=nginx:1.14 --port=80 --replicas=3

• --image：指定容器镜像（格式：镜像名:标签）；
• --port：指定容器暴露的端口；
• --replicas：指定 Pod 副本数（默认 1）。

创建后验证：

# 查看 Deployment 状态
kubectl get deployment nginx# 查看 Pod 状态（Deployment 会自动创建 Pod）
kubectl get pods -o wide

2.2.2 阶段 2：发布（kubectl expose 与 Service 详解）

创建 Deployment 后，Pod 的 IP 是“动态的”（Pod 重建后 IP 会变化），且外部无法直接访问。kubectl expose 用于创建 Service，解决“IP 动态性”和“负载均衡”问题。

2.2.2.1 Service 的核心作用

1. 固定访问入口：为一组 Pod 提供固定的虚拟 IP（VIP），无论 Pod 如何重建，Service IP 不变；Service 通过 Label Selector 实现的对一组的 Pod 的访问。
2. 负载均衡：通过 Label Selector 匹配 Pod，将请求均匀分发到后端 Pod；
3. 内外网访问控制：通过 Service 类型控制资源的访问范围（集群内/外部）。

2.2.2.2 Service 的 4 种类型

类型	核心特点	适用场景	访问方式
ClusterIP	集群内虚拟 IP，仅集群内 Pod 可访问	集群内部服务间通信（如后端 API 服务）	ClusterIP:Port
NodePort	在每个 Node 上开放一个端口（30000-32767），外部可通过 NodeIP:NodePort 访问	测试环境/小规模外部访问	NodeIP:NodePort
LoadBalancer	结合公有云负载均衡器（如 AWS ELB、阿里云 SLB），提供公网访问入口	生产环境外部访问	负载均衡器公网 IP:Port
ExternalName	将 Service 映射到外部 DNS 域名（如 mysql.simon.com），无需绑定 Pod	访问集群外部资源（如外部数据库）	域名访问

2.2.2.3 Service 端口概念辨析

Service 涉及 4 个端口概念，需明确区别：

• port：Service 自身的端口（集群内访问 Service 的端口，如 Service:80），即通过 clusterIP: port 可以从 Pod 所在的 Node 上访问到 service；
• nodePort：Node 节点开放的端口（外部访问 Service 的端口，如 NodeIP:30080），通过 nodeIP: nodePort 可以从外部访问到某个 service；
• targetPort：Pod 的端口，从 port 或 nodePort 来的流量经过 kube-proxy 反向代理负载均衡转发到后端 Pod 的 targetPort 上，最后进入容器；
• containerPort：容器内部的端口（在 Dockerfile 或 Deployment 中定义，如 Nginx 的 80 端口），targetPort 映射到 containerPort。

k8s集群内部 ： 客户端–》clusterIP:port–>通过targetport–》podIP:cantainerport
k8s集群外部 ： 客户端–》nodeIP:NodePort–>通过targetport–》podIP:cantainerport

2.2.2.4 实战：创建 NodePort 类型 Service

为前面创建的 nginx Deployment 暴露 Service，类型为 NodePort：

# 为deployment的nginx创建service，并通过Service的80端口转发至容器的80端口上，Service的名称为nginx-service，类型为NodePort
kubectl expose deployment nginx --port=80 --target-port=80 --name=nginx-service --type=NodePort

• --port：Service 的端口（集群内访问用）；
• --target-port：Pod 的端口；
• --name：Service 名称（nginx-service）；
• --type：Service 类型（NodePort）。

验证 Service：

# 查看 Service 信息（重点看 PORT(S)，如 80:31107/TCP，31107 为 NodePort）
kubectl get svc nginx-service -o wide# 查看 Service 关联的后端 Pod（Endpoints 列表）
kubectl get endpoints nginx-service# 查看 service 的描述信息
kubectl describe svc nginx-service# 外部访问测试（使用 NodeIP:NodePort）
curl http://<NodeIP>:<NodePort>  # 如 curl http://192.168.10.14:31107

2.2.3 阶段 3：更新（kubectl set 与滚动更新）

kubectl set 用于修改资源的配置（如镜像版本、环境变量），k8s 默认采用 滚动更新 策略（先创建新 Pod，再删除旧 Pod，确保服务不中断）。

示例：更新 Nginx 版本到 1.15
1、查看当前 Nginx 版本（通过 HTTP 响应头）：

curl -I http://<NodeIP>:<NodePort>  # 响应头包含 Server: nginx/1.14.0

2、执行更新：

# 修改 Deployment nginx 的镜像为 nginx:1.15
kubectl set image deployment/nginx nginx=nginx:1.15

3、实时监控更新过程：

kubectl get pods -w  # -w 表示实时跟踪 Pod 状态

观察结果：会先创建新的 Pod（nginx-xxxx-xxx），待新 Pod 处于 Running 状态后，再删除旧 Pod，实现“无缝更新”。

# 再看更新好后的 Pod 的 ip 会改变
kubectl get pods -o wide

4、验证更新结果：

curl -I http://<NodeIP>:<NodePort>  # 响应头变为 Server: nginx/1.15.12

2.2.4 阶段 4：回滚（kubectl rollout）

若更新后出现故障（如镜像拉取失败、应用兼容性问题），需通过 kubectl rollout 回滚到历史版本。

回滚操作步骤：
1、查看历史版本记录：

# 查看 Deployment 的历史版本
kubectl rollout history deployment/nginx 

2、回滚到上一个版本：

kubectl rollout undo deployment/nginx

3、回滚到指定版本（如版本 1）：

kubectl rollout undo deployment/nginx --to-revision=1

4、检查回滚状态：

# 显示“deployment "nginx" successfully rolled out”表示回滚成功
kubectl rollout status deployment/nginx  

5、验证回滚结果

   curl -I http://<NodeIP>:<NodePort>  # 响应头变为 Server: nginx/1.14.2

2.2.5 阶段 5：删除（kubectl delete）

kubectl delete 用于删除资源，删除时需注意：

• 删除 Deployment 会自动删除关联的 Pod；
• 删除 Service 仅删除访问入口，不影响 Pod。

示例：删除 Nginx 相关资源

# 删除 Deployment（会删除关联的 Pod）
kubectl delete deployment/nginx# 删除 Service
kubectl delete svc/nginx-service# 验证删除结果
kubectl get all  # 确认 nginx 相关的 Deployment、Pod、Service 已消失

特殊场景：强制删除卡住的 Pod
若 Pod 处于 Terminating 状态无法删除，可强制删除（跳过优雅退出，适用于紧急场景）：

kubectl delete pod <Pod 名称> -n <命名空间> --force --grace-period=0

• --grace-period=0：表示立即终止 Pod（默认 30s 优雅退出时间，用于关闭容器内进程）。

2.3 主流发布策略实战

企业级应用发布需兼顾“可用性”与“风险控制”，常用发布策略包括 金丝雀发布、滚动发布、蓝绿发布。

2.3.1 金丝雀发布（Canary Release）

核心思想：先将少量流量导入新版本，验证无故障后再全量发布（类似“投石问路”），风险最低。

Deployment控制器允许自定义滚动更新的节奏，支持手动暂停(pause)或继续(resume)更新操作。

例如，可以在第一批新Pod创建完成后暂停更新，此时系统会同时运行新旧两个版本的应用。随后，可将少量用户流量导向新版本Pod进行验证测试。若运行稳定，则继续完成剩余的滚动更新；若发现问题，则可立即执行回滚操作。这种渐进式发布策略被称为金丝雀发布(Canary Release)。

k8s 中通过 kubectl rollout pause/resume 实现：

1、触发更新并暂停滚动：

# 更新 Nginx 镜像到 1.16，同时暂停 Deployment 更新
kubectl set image deployment/nginx nginx=nginx:1.16 && kubectl rollout pause deployment/nginx# 查看更新状态（此时仅创建部分新 Pod，旧 Pod 未删除）
kubectl rollout status deployment/nginx
kubectl get pods -o wide

2、验证新版本可用性：

# 访问 Service，观察流量是否正常（仅部分请求会路由到新 Pod）
curl -I http://<PodIP> # 该pod更新为nginx/1.16.0
curl -I http://<NodeIP>:<NodePort>  # 部分响应为 nginx/1.16.0，部分为旧版本

3、确认无故障后，继续全量更新：

kubectl rollout resume deployment/nginx# 实时监控全量过程
kubectl get pods -w

4、全量验证：

curl -I http://<PodIP>  # 所有响应均为 nginx/1.16.1

2.3.2 滚动发布（Rolling Update）

核心思想：逐步替换旧 Pod（如每次替换 1/4），先创建少量新版本 Pod，待其就绪后删除等量旧版本 Pod，循环直至全部替换。默认无暂停，适用于对可用性要求不极致的场景（如内部服务）。

k8s Deployment 默认采用此策略，无需额外配置，前面2.2.3 阶段 3：更新即为此策略的实战。

2.3.3 蓝绿发布（Blue-Green Release）

核心思想：部署两套完全相同的环境（蓝环境：旧版本，绿环境：新版本），验证绿环境无故障后，切换流量到绿环境，回滚时只需切回蓝环境。
k8s 中通过双 Deployment + 切换 Service 标签实现：

1、创建“蓝环境”（旧版本，如 nginx:1.14）：

kubectl create deployment nginx-blue --image=nginx:1.14 --replicas=2
kubectl expose deployment nginx-blue --port=80 --type=NodePort --name=nginx-svc

2、创建“绿环境”（新版本，如 nginx:1.15）：

kubectl create deployment nginx-green --image=nginx:1.15 --replicas=2

3、验证绿环境：

# 直接访问绿环境 Pod（通过 Pod IP）
kubectl get pods -l app=nginx-green -o wide
curl http://<绿环境 Pod IP>  # 确认版本为 1.15.0

4、切换流量到绿环境（修改 Service 标签）：

# 将 Service 从关联 nginx-blue 改为关联 nginx-green
kubectl patch service nginx-svc -p '
spec:selector:app: nginx-green
'

5、验证切换结果：

curl -I http://<NodeIP>:<NodePort>  # 响应为 nginx/1.15.0

6、回滚（如需）：

kubectl patch service nginx-svc -p '
spec:selector:app: nginx-blue
'

三、声明式资源管理：配置清单驱动的规范操作

声明式管理以“YAML/JSON 配置清单”为核心，适合生产环境——配置可版本化、可复用、便于团队协作。

3.1 声明式管理的核心特点

1. 基于“期望状态”：配置清单定义资源的最终状态，k8s 自动将集群状态同步到期望状态；
2. 支持增量更新：修改配置清单后，kubectl apply 仅更新变化的字段，无需删除重建；
3. 版本化管理：配置清单可存入 Git，便于追溯历史变更（如“谁改了、改了什么、什么时候改的”）。

3.2 配置清单的常用操作

配置清单以 YAML 格式为主（比 JSON 更易读），核心操作包括“查看、解释、修改、删除”。

3.2.1 查看配置清单（kubectl get -o yaml）

通过 kubectl get -o yaml 导出已有资源的 YAML 配置，作为模板使用：

# 导出 nginx Deployment 的 YAML 配置，保存到 nginx-deploy.yaml
kubectl get deployment nginx -o yaml > nginx-deploy.yaml# 导出 nginx-service 的 YAML 配置，保存到 nginx-svc.yaml
kubectl get service nginx -o yaml > nginx-svc.yaml

打开 YAML 文件，核心结构包括：

• apiVersion：API 版本（如 apps/v1 对应 Deployment）；
• kind：资源类型（如 Deployment、Service）；
• metadata：资源元数据（如 name、namespace、labels）；
• spec：资源的期望状态（如 Deployment 的 replicas、template（Pod 模板））。

3.2.2 解释配置清单（kubectl explain）

若不理解 YAML 字段的含义，可通过 kubectl explain 查看字段说明：

# 查看 Deployment 的 metadata 字段说明
kubectl explain deployment.metadata# 查看 Deployment 的 spec.template.spec 字段说明（Pod 模板的核心配置）
kubectl explain deployment.spec.template.spec

3.2.3 修改配置清单（离线/在线）

3.2.3.1 离线修改（推荐）

1、编辑 YAML 文件（如修改 Service 的端口为 8080）：

vim nginx-svc.yaml
# 找到 spec.ports.port 字段，修改为 8080

2、应用修改（kubectl apply）：

kubectl apply -f nginx-svc.yaml

3、验证修改结果：

kubectl get service ngin  # 确认 PORT(S) 为 8080:<NodePort>/TCP

注意：若 kubectl apply 不生效（如资源字段不可增量更新），需先删除旧资源，再重新创建：

kubectl delete -f nginx-svc.yaml
kubectl apply -f nginx-svc.yaml

3.2.3.2 在线修改（临时场景）

通过 kubectl edit 在线编辑配置清单，保存后即时生效（但不会修改本地 YAML 文件，适合临时修改）：

# 在线编辑 nginx-service 的配置
kubectl edit service nginx

编辑时，找到 spec.ports.port 字段，修改为 888，保存退出后，修改立即生效。

3.2.4 删除配置清单（kubectl delete -f）

通过 YAML 文件删除资源，确保“删除的资源与创建的资源完全一致”：

# 删除 nginx-service（通过 nginx-svc.yaml）
# 声明式删除
kubectl delete -f nginx-svc.yaml
# 陈述式删除
# kubectl delete service nginx

总结与实践建议

核心总结

1. 两种管理方式对比：

   • 陈述式：命令驱动，适合简单操作（如查询、临时创建）；
   • 声明式：配置驱动，适合生产环境、复杂配置、版本化管理。

2. 项目生命周期关键命令：

   • 创建：kubectl create；
   • 发布：kubectl expose；
   • 更新：kubectl set；
   • 回滚：kubectl rollout；
   • 删除：kubectl delete。

3. 发布策略选择：

   • 金丝雀发布：风险最低，适合核心业务（如支付、订单）；
   • 滚动发布：无感知更新，适合非核心业务（如内部管理系统）；
   • 蓝绿发布：切换迅速，适合对可用性要求极高的场景（如电商大促）。

实践建议

1. 新手入门：先掌握陈述式命令（如 kubectl get、kubectl create），熟悉资源类型后再学习声明式；
2. 生产环境：所有资源通过 YAML 配置清单管理，存入 Git，执行“GitOps”流程（如通过 ArgoCD 自动同步配置）；
3. 故障排查：优先使用 kubectl describe 查看资源事件，再用 kubectl logs 查看 Pod 日志，定位问题根源；
4. 版本兼容：确保 kubectl 版本与 k8s 集群版本差距不超过 1 个小版本，避免命令不兼容问题。

通过本文的学习，相信你已掌握 kubectl 的核心用法。建议结合实际环境多动手实践（如搭建 minikube 本地集群），才能真正将知识转化为技能！