提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

---

前言

1、管理操作分为两大类陈述和声明
2、k8s 基础信息查看（命令）增删改查
3、项目生命周期 创建 发布 更新 回滚 删除 所有命令和过程
4、主要发布过程 金丝雀发布 蓝绿发布 滚动发布

---

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

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

• 陈述式（命令式）管理方法
• 声明式（配置清单式）管理方法

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

1.1.1 基本原理

1. Kubernetes 集群资源管理的唯一入口是通过调用 apiserver 的接口。
2. kubectl 是官方 CLI 命令行工具，用于与 apiserver 通信，将用户命令转化为 apiserver 能识别的
   请求，实现集群资源管理。
3. 查看 kubectl 命令大全：

kubectl --help

中文文档参考：http://docs.kubernetes.org.cn/683.html
4. 对资源的“增、删、查”操作较方便，但“改”操作相对复杂。

1.1.2 基础信息查看命令

kubectl version # 查看版本信息
kubectl api-resources # 查看资源对象简写
kubectl cluster-info # 查看集群信息

命令自动补全与日志查看

source <(kubectl completion bash) # 启用kubectl自动补全
journalctl -u kubelet -f # 查看node节点日志

1.1.3 基本资源查看命令

kubectl get <resource> [-o wide|json|yaml] [-n namespace]

-n 指定命名空间
-o 指定输出格式
–all-namespaces ：显示所有命名空间
–show-labels ：显示所有标签
-l app=nginx ：筛选指定标签的资源

kubectl get componentstatuses # 查看 master 节点状态
kubectl get namespace # 查看命名空间
kubectl get all -n default # 查看default命名空间的所有资源

1.1.4 命名空间操作

kubectl create ns app # 创建命名空间
kubectl delete namespace app # 删除命名空间

1.1.5 创建 Deployment（副本控制器）

自主式保存在主机上

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

kubectl create deployment
kubectl run 自主式的pod 静态

###描述某个资源的详细信息
kubectl describe deployment nginx-wl -n kube-public
kubectl describe pod nginx-wl-d47f99cb6-hv6gz -n kube-public
kubectl get pods -n kube-public

1.1.6 登录容器与删除 Pod

kubectl exec -it nginx-wl-d47f99cb6-hv6gz bash -n kube-public
kubectl delete pod nginx-wl-d47f99cb6-hv6gz -n kube-public

#若pod无法删除，总是处于terminate状态，则要强行删除pod
kubectl delete pod <pod-name> -n <namespace> --force --grace-period=0
#grace-period表示过渡存活期，默认30s，在删除pod之前允许POD慢慢终止其上的容器进程，从而优雅退
出，0表示立即终止pod

1.1.7 扩缩容与删除

kubectl scale deployment nginx-wl --replicas=2 -n kube-public
kubectl scale deployment nginx-wl --replicas=1 -n kube-public
kubectl delete deployment nginx-wl -n kube-public

1.2、项目生命周期管理

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

1.2.1 创建阶段（kubectl create）

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

kubectl create --help

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

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

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

创建后验证：

# 查看 Deployment 状态
kubectl get deployment nginx

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

1.2.2 ：发布（kubectl expose 与 Service 详解）

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

kubectl expose --help

kubectl expose deployment nginx --port=80 --target-port=80 --name=nginx-service
--type=NodePort

Service 的核心作用

Service 是一个核心的 “服务抽象资源”—— 它的核心作用是为一组动态变化的 Pod 提供 “稳定的访问入口”，同时实现负载均衡，是 K8s 集群内服务通信、对外暴露服务的关键组件。

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

Service 类型

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

扩展端口类型

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。

实战：创建 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 信息（重点看 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

负载均衡查看（节点上）

#在 node01 节点上操作，查看负载均衡端口
yum install ipvsadm -y
ipvsadm -Ln
TCP 192.168.10.21:44847 rr
-> 172.17.26.3:80 Masq 1 0 0
-> 172.17.36.2:80 Masq 1 0 0
-> 172.17.36.3:80 Masq 1 0 0
TCP 10.0.0.189:80 rr
-> 172.17.26.3:80 Masq 1 0 0
-> 172.17.36.2:80 Masq 1 0 0
-> 172.17.36.3:80 Masq 1 0 0
curl 10.0.0.189
curl 192.168.10.20:44847

1.2.3 更新（kubectl set 与滚动更新）

1.2.4 回滚阶段（kubectl rollout）

##对资源进行回滚管理
kubectl rollout --help
//查看历史版本
kubectl rollout history deployment/nginx
//执行回滚到上一个版本
kubectl rollout undo deployment/nginx
//执行回滚到指定版本
kubectl rollout undo deployment/nginx --to-revision=1
//检查回滚状态
kubectl rollout status deployment/nginx

1.2.5 删除阶段（kubectl delete）

//删除副本控制器
kubectl delete deployment/nginx
//删除service
kubectl delete svc/nginx-service
kubectl get all

1.3 主流发布策略实战

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

1.3.1 金丝雀发布（Canary Release）

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

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

总结

核心总结

两种管理方式对比：

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

项目生命周期关键命令：

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

发布策略选择：

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

1.蓝绿发布:

两套设备进行新旧版本替换
好处用户无感知，业务稳定
缺点粍资2倍资源成本高
原理:完成切换/替换 方便快速退回

2.滚动发布

按照比列分批分部滚动更新，k8s默认的更新机制
无创建一定的比列的新pod，再删除旧的pod
原理：分批进行切换逐步更新减少流量冲击

3.灰度发布

金丝雀先更新一部分pod，然后暂停更新，安排一部分用户的流量去访问新的pod来做测试
，当测试没有问题后再扩大测试比列知道全部更新完成

实践建议

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