Kubernetes(四)——项目生命周期管理和yml文件编写
前言
本文围绕 K8s 项目生命周期全流程展开，详解发布策略、声明式资源管理及 YAML 文件编写技巧，为实操运维提供清晰指引。
一、项目生命周期管理
1、项目生命周期阶段
创建 → 发布 → 更新 → 回滚 → 删除
2、创建阶段（kubectl create）
创建”容器端口“
# 创建并运行一个或多个容器镜像。
# 创建一个deployment 或job 来管理容器。
kubectl create --help
//启动 nginx 实例，暴露容器端口 80，设置副本数 3
kubectl create deployment nginx --image=nginx:1.14 --port=80 --replicas=3
kubectl get pods
kubectl get all
# 查看容器端口
kubectl get pods -o custom-columns="NAME:.metadata.name,PORT:.spec.containers[0].ports[0].containerPort"
# 查看归属（是不是受控Pod）
kubectl get pods -o custom-columns="NAME:.metadata.name,CONTROLLER:.metadata.ownerReferences[0].kind,NAME:.metadata.ownerReferences[0].name"
3、发布阶段（kubectl expose）
将资源暴露为 Service
kubectl expose --help
kubectl expose deployment nginx --port=80 --target-port=80 --name=nginx-service --type=NodePort
1）service 类型：
2）扩展端口类型
port ：
port 是 k8s 集群内部访问service的端口，即通过 clusterIP: port 可以从 Pod 所在的 Node 上访问到service
nodePort：
nodePort 是外部访问 k8s 集群中 service 的端口，通过 nodeIP: nodePort 可以从外部访问到某个service。
targetPort ：
targetPort 是 Pod 的端口，从 port 或 nodePort 来的流量经过 kube-proxy 反向代理负载均衡转发到后端 Pod 的 targetPort 上，最后进入容器。
containerPort :
containerPort 是 Pod 内部容器的端口，targetPort 映射到 containerPort。
3）查看网络状态与服务端口
#查看pod网络状态详细信息和 Service暴露的端口
kubectl get pods,svc -o wide
##查看关联后端的节点
kubectl get endpoints
#查看 service 的描述信息
kubectl describe svc nginx
4) 负载均衡查看（节点上）
#在 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
###在master01操作 查看访问日志
kubectl logs nginx-cdb6b5b95-fjm2x
kubectl logs nginx-cdb6b5b95-g28wz
kubectl logs nginx-cdb6b5b95-x4m24
轮询查看：
4、更新阶段（kubectl set）
#更改现有应用资源一些信息。
kubectl set --help
#获取修改模板
kubectl set image --help
Examples:
# Set a deployment's nginx container image to 'nginx:1.9.1', and its busybox
container image to 'busybox'.
kubectl set image deployment/nginx busybox=busybox nginx=nginx:1.9.1
# 查看当前 nginx 的版本号
curl -I http://192.168.10.20:44847
curl -I http://192.168.10.21:44847
##将nginx 版本更新为 1.15 版本
kubectl set image deployment/nginx nginx=nginx:1.15
kubectl get pods -w #/处于动态监听 pod 状态，由于使用的是滚动更新方式，所以会先生成一个新
的pod，然后删除一个旧的pod，往后依次类推
kubectl get pods -o wide #再看更新好后的 Pod 的 ip 会改变
更新示例：
5、回滚阶段（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
回滚示例：
6、删除阶段（kubectl delete）
//删除副本控制器
kubectl delete deployment/nginx
//删除service
kubectl delete svc/nginx-service
kubectl get all
删除示例：
二、发布版本
1、三种发布方式概述
- 蓝绿发布：同时部署新版本（绿）和旧版本（蓝）两套环境，验证通过后直接切换流量到新版本，旧版本作为备份随时回滚。
- 滚动发布：按批次逐步替换旧版本 Pod，每替换一批验证一批，全程无服务中断，支持灰度放量和风险可控。
- 金丝雀发布：先将少量流量切到新版本（金丝雀版本），验证无问题后再逐步扩大流量占比，最终全量切换。
2、金丝雀发布实战
1）监控更新的过程
kubectl get pods -w
2）更新deployment的版本，并配置暂停deployment
kubectl set image deployment/nginx-deployment nginx=nginx:1.15 && kubectl rollout pause deployment/nginx-deployment
可以看到已经新增了一个资源，但是并未按照预期的状态去删除一个旧的资源，就是因为使用了pause暂停命令
验证版本号：正常轮询，新创建的就是1.15所以正常的，只要看到1.14.2即可
curl -I 10.96.0.147:80
3）确保更新的pod没问题了，继续更新
kubectl rollout resume deployment/nginx-deployment
curl -I 10.96.0.147:80
3、k8s发布的方法
使用的滚动发布
三、声明式资源管理方法
1、基本原理
1.适合于对资源的修改操作
2.声明式资源管理方法依赖于资源配置清单文件对资源进行管理，资源配置清单文件有两种格式：yaml（人性化，易读），json（易于api接口解析）
3.对资源的管理，是通过事先定义在统一资源配置清单内，再通过陈述式命令应用到k8s集群里
4.语法格式：kubectl create/apply/delete -f xxxx.yaml
2、查看和解释配置清单
//查看资源配置清单(yaml的格式)
kubectl get deployment nginx -o yaml
//解释资源配置清单
kubectl explain deployment.metadata # 查询yaml文件相关命令参数
kubectl get service nginx -o yaml # 查看service的yaml格式展示的内容
kubectl explain service.metadata
查看资源配置清单：
3、修改资源配置清单并应用
离线修改：
修改yaml文件，并用 kubectl apply -f xxxx.yaml 文件使之生效
注意：当apply不生效时，先使用delete清除资源，再apply创建资源
# 导出yaml文件模板
kubectl get service nginx -o yaml > nginx-svc.yaml
vim nginx-svc.yaml #修改port: 8080
# 删除该yaml文件产生的旧资源
kubectl delete -f nginx-svc.yaml
# 重新加载该文件
kubectl apply -f nginx-svc.yaml
kubectl get svc
在线修改：
直接使用 kubectl edit service nginx 在线编辑资源配置清单并保存退出即时生效（如port: 888）
PS：此修改方式不会对yaml文件内容修改
4、删除资源配置清单
陈述式删除：（命令行操作）
kubectl delete service nginx
声明式删除：（yaml文件进行操作）
kubectl delete -f nginx-svc.yaml
扩展：一般都是使用陈述式删除，声明式创建资源
四、yaml文件编写方法
1、kubernetes支持两种文件格式
支持yaml和json格式来管理资源对象
json格式：主要用于 api 接口之间消息的传递
yaml格式：用于配置和管理，YAML 是一种简洁的非标记性语言，内容格式人性化，较易读
2、yaml语法格式
● 大小写敏感
● 使用缩进表示层级
● 不支持Tab键制表符作缩进，只能使用空格缩进
● 缩进的空格格数不重要，只要相同层级对齐即可，通常用两个空格
● 符号字符后面一个空格 如：冒号、逗号、-等
● ”—“表示一个yml文件的开始，用于分割yml文件
● ”#“ 表示注释
3、api资源版本标签
注意点：
如果是业务场景一般首选使用 apps/v1
带有beta字样的代表的是测试版本，不用在生产环境中，如apps/v1beta1
api版本标签的作用：
1） 区分资源的 “成熟度”，控制功能迭代 。
区分稳定版 / 测试版，指导生产环境使用；
2） 规范资源 YAML 的定义格式
YAML 必须指定正确版本，K8s 才能解析
3）保证集群的版本兼容
集群升级时，通过版本平滑过渡，避免功能中断
4）按功能分组，管理资源范围
按业务域归类资源，让 API 结构更清晰
输出api版本标签:
kubectl versions
输出：
4、yaml文件示例
4.1、创建deployment和Pod
mkdir /opt/demo && cd /opt/demo
vim nginx-deployment.yaml
# 第一部分：资源的“身份标识”——告诉 K8s 这是什么类型的资源、用什么版本解析
apiVersion: apps/v1 # 【必选】指定解析这个资源的API版本
# 通俗：相当于“文件格式版本”，Deployment 必须用 apps/v1，写错会报错
# 核心：Deployment/StatefulSet 用 apps/v1；Pod/Service 用 v1；Ingress 用 networking.k8s.io/v1
kind: Deployment # 【必选】定义资源类型
# 通俗：告诉 K8s 你要创建“部署控制器”（Deployment），而非 Service/Ingress 等
# 核心：常用值——Deployment（部署应用）、Service（服务入口）、Ingress（域名路由）、Pod（最小运行单元）
# 第二部分：资源的“基础信息”——给资源起名字、打标签、指定归属
metadata: # 【必选】资源的元数据（描述信息），固定字段
name: nginx-deployment # 【必选】资源名称（Deployment的名字）
# 核心：同一 Namespace 内名称必须唯一，比如不能有两个叫 nginx-deployment 的 Deployment
labels: # 【可选】给 Deployment 本身打标签（不是 Pod 的标签！）
app: nginx # 标签键值对：key=app，value=nginx
# 作用：方便用标签筛选资源，比如 kubectl get deploy -l app=nginx
# 第三部分：资源的“核心配置”——定义 Deployment 要管理多少 Pod、Pod 长什么样
spec: # 【必选】Deployment 的核心配置段，固定字段
replicas: 3 # 【必选】指定要运行的 Pod 副本数
# 通俗：启动 3 个相同的 Nginx Pod，实现负载均衡
# 核心：改这个数值可以扩缩容，比如改成 5 就是 5 个 Pod
selector: # 【必选】标签选择器——Deployment 靠这个找到要管理的 Pod
matchLabels: # 【必选】匹配标签规则（精确匹配）
app: nginx # 核心：必须和下面 template.metadata.labels 里的标签完全一致！
# 作用：Deployment 只管理带 app=nginx 标签的 Pod，避免管错其他 Pod
template: # 【必选】Pod 模板——定义要创建的 Pod 长什么样（所有副本都按这个模板创建）
metadata:
labels: # 【必选】给 Pod 打标签（关键！）
app: nginx # 核心：必须和上面 selector.matchLabels 一致，否则 Deployment 找不到 Pod
spec: # 【必选】Pod 的核心配置段
containers: # 【必选】定义 Pod 里的容器（一个 Pod 可以有多个容器）
- name: nginx # 【必选】容器名称（Pod 内唯一）
image: nginx:1.15.4 # 【必选】容器使用的镜像（镜像名+版本）
# 核心：不写版本默认拉 latest，生产环境必须指定具体版本（如 1.15.4），避免镜像更新导致故障
ports: # 【可选】声明容器要暴露的端口（仅声明，不实际映射）
- containerPort: 80 # 声明容器监听 80 端口
# 注意：这只是“告诉 K8s 容器用了 80 端口”，要对外访问还需配 Service
创建资源对象：
kubectl create -f nginx-deployment.yaml
验证结果：
查看Pod和deployment
kubectl get all 或 kubectl get pods
查看Pod的ip和部署的node节点
kubectl get pods -o wide
查看pod的标签
kubectl get pods --show-labels
4.2、创建service
vim nginx-service.yaml
# 第一部分：资源身份标识——告诉 K8s 这是 Service 类型的资源
apiVersion: v1 # 【必选】Service 属于核心资源，固定用 v1（和 Deployment 的 apps/v1 区分开）
# 通俗：Service 的“文件格式版本”，写错会报错（比如写成 apps/v1 就识别不了）
kind: Service # 【必选】定义资源类型为 Service（服务入口）
# 通俗：告诉 K8s 你要创建一个“门牌号”，用来访问 Pod
# 第二部分：资源基础信息——给 Service 起名字、打标签
metadata:
name: nginx-service # 【必选】Service 的名称（同一 Namespace 内唯一）
# 作用：集群内可以通过 “nginx-service” 这个名字访问，不用记 IP
labels:
app: nginx # 【可选】给 Service 本身打标签（不是绑定 Pod 的标签！）
# 作用：方便筛选 Service，比如 kubectl get svc -l app=nginx
# 第三部分：Service 核心配置——类型、端口、绑定 Pod 的规则
spec:
type: NodePort # 【必选】Service 类型（决定怎么暴露服务）
# 可选值：
# - ClusterIP（默认）：仅集群内访问；
# - NodePort：暴露到所有 Node 的固定端口（集群外可访问）；
# - LoadBalancer：对接云厂商 LB（生产常用）
ports: # 【必选】定义端口映射规则（Service 端口 ↔ Pod 端口）
- port: 80 # 【必选】Service 自身的集群内端口（ClusterIP:80）
# 通俗：门牌号的“内部窗口号”，集群内访问 Service 时用这个端口
targetPort: 80 # 【必选】Pod 内容器的端口（对应 Pod 里 nginx 监听的 80 端口）
# 核心：把 Service 的 80 端口请求，转发到 Pod 的 80 端口
selector: # 【核心！关联 Pod 的关键行】标签选择器
app: nginx # ✅ 这一行就是绑定 Pod 的核心！
# 作用：Service 会自动找到所有带 “app=nginx” 标签的 Pod
# 要求：必须和 Pod 的 labels（比如 Deployment 模板里的 app=nginx）完全一致
创建资源对象
kubectl create -f nginx-service.yaml
查询service
kubectl get svc
测试192.168.10.112:32305
curl 192.168.10.112:32305 或者 浏览器访问http://192.168.10.112:32305
4.3、详解k8s中的Port
- port
port 是 k8s 集群内部访问service的端口，即通过 clusterIP: port 可以从 Pod 所在的 Node 上访问到 service - nodePort
nodePort 是外部访问 k8s 集群中 service 的端口，通过 nodeIP: nodePort 可以从外部访问到某个 service。 - targetPort
targetPort 是 Pod 的端口，从 port 或 nodePort 来的流量经过 kube-proxy 反向代理负载均衡转发到后端 Pod 的 targetPort 上，最后进入容器。 - containerPort
containerPort 是 Pod 内部容器的端口，targetPort 映射到 containerPort。
5、快速生成yaml文件模板方法
5.1、快速生成yaml方法示例
kubectl run --dry-run=client 打印相应的 API 对象而不执行创建
kubectl run nginx-test --image=nginx --port=80 --dry-run=client
kubectl create deployment nginx-deploy --image=nginx --port=80 --replicas=3 --dry-run=client
查看生成yaml格式
kubectl run nginx-test --image=nginx --port=80 --dry-run=client -o yaml
kubectl create deployment nginx-deploy --image=nginx --port=80 --replicas=3 --dry-run=client -o yaml
查看生成json格式
kubectl run nginx-test --image=nginx --port=80 --dry-run=client -o json
kubectl create deployment nginx-deploy --image=nginx --port=80 --replicas=3 --dry-run=client -o json
使用yaml格式导出生成模板，并进行修改以及删除一些不必要的参数
kubectl run nginx-test --image=nginx --port=80 --dry-run=client -o yaml > nginx-test.yaml
kubectl create deployment nginx-deploy --image=nginx --port=80 --replicas=3 --dry-run=client -o yaml > nginx-deploy.yaml
5.2、查看快速生成的yaml文件
使用yaml格式导出生成模板，并进行修改以及删除一些不必要的参数
kubectl create deployment nginx-deploy --image=nginx --port=80 --replicas=3 --dry-run=client -o yaml > nginx-deploy.yaml
apiVersion: apps/v1 # 必留：Service 用 v1，Deployment 必须用 apps/v1
kind: Deployment # 必留：定义资源类型为 Deployment
metadata:
creationTimestamp: null # 可删：自动生成的字段，手动写了也会被 K8s 覆盖
labels:
app: nginx # 可选（建议留）：给 Deployment 打标签，方便筛选
name: nginx # 必留：Deployment 名称（唯一）
spec:
replicas: 2 # 必留：Pod 副本数（核心配置）
selector:
matchLabels:
app: nginx # 必留：关联 Pod 的核心标签（必须和 template.labels 一致）
strategy: {} # 可删：空配置会用 K8s 默认的滚动更新策略，写了没用
template:
metadata:
creationTimestamp: null # 可删：自动生成的字段，手动写无意义
labels:
app: nginx # 必留：Pod 的标签（和 selector.matchLabels 绑定）
spec:
containers:
- image: nginx # 必留：容器镜像（建议加版本，比如 nginx:1.24）
name: nginx # 必留：容器名称（Pod 内唯一）
ports:
- containerPort: 80 # 可选（建议留）：声明容器端口（仅标识，不影响访问）
resources: {} # 可选（可删）：空配置表示不限制资源，删了也会用默认值
status: {} # 可删：status 是 K8s 自动维护的状态字段，手动写空毫无意义
将现有的资源生成模板导出并保存到文件中
kubectl get svc service -o yaml > my-svc.yaml
cat my-svc.yaml
apiVersion: v1 # 必留：Service 属于核心资源，固定用 v1（Deployment 才用 apps/v1）
kind: Service # 必留：定义资源类型为 Service
metadata:
creationTimestamp: "2026-01-07T12:20:11Z" # 可删：K8s 自动生成的创建时间，手动写会被覆盖
labels:
app: nginx # 可选（建议留）：给 Service 打标签，方便筛选（和绑定 Pod 无关）
managedFields: # 可删：K8s 内部记录谁修改了资源，手动写无意义
- apiVersion: v1
fieldsType: FieldsV1
fieldsV1:
f:metadata:
f:labels:
.: {}
f:app: {}
f:spec:
f:externalTrafficPolicy: {}
f:ports:
.: {}
k:{"port":80,"protocol":"TCP"}:
.: {}
f:port: {}
f:protocol: {}
f:targetPort: {}
f:selector:
.: {}
f:app: {}
f:sessionAffinity: {}
f:type: {}
manager: kubectl-create
operation: Update
time: "2026-01-07T12:20:11Z"
name: service # 必留：Service 名称（同一 Namespace 唯一）
namespace: default # 可选（可删）：默认就是 default 命名空间，不写也会自动归到 default
resourceVersion: "150531" # 可删：K8s 内部版本号，自动生成
uid: 773b38cb-5e41-4fde-ae92-86f30182c6f4 # 可删：K8s 自动生成的资源唯一标识
spec:
clusterIP: 10.96.0.147 # 可删：K8s 自动分配 ClusterIP，手动写会被覆盖（除非指定固定 IP）
clusterIPs: # 可删：和 clusterIP 重复，自动生成
- 10.96.0.147
externalTrafficPolicy: Cluster # 可选（可删）：默认值就是 Cluster，删了不影响
ports:
- nodePort: 32305 # 可选（可删）：手动指定 NodePort 端口，不写 K8s 会自动分配（30000-32767）
port: 80 # 必留：Service 集群内端口（核心）
protocol: TCP # 可选（可删）：默认协议就是 TCP，删了等价
targetPort: 80 # 必留：Pod 内容器的端口（和容器监听端口一致）
selector:
app: nginx # 必留：绑定 Pod 的核心标签（必须和 Pod 标签一致）
sessionAffinity: None # 可选（可删）：默认就是无会话亲和性，删了不影响
type: NodePort # 必留：Service 类型（ClusterIP/NodePort/LoadBalancer）
status:
loadBalancer: {} # 可删：status 是 K8s 自动维护的状态，手动写空没用
5.3、通过命令查看帮助（重点）
查看deployment控制器的pod模板里容器的参数
kubectl explain deployments.spec.template.spec.containers
或者
kubectl explain pods.spec.containers
总结
本文系统梳理 K8s 项目管理、发布方式与配置清单编写要点，助力高效掌握声明式资源管理及 YAML 实操技能。
更多推荐
14
0- 0
已为社区贡献12条内容
所有评论(0)