儋州市网站建设_网站建设公司_云服务器_seo优化

前言

本文围绕 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

1. port
   port 是 k8s 集群内部访问service的端口，即通过 clusterIP: port 可以从 Pod 所在的 Node 上访问到 service
2. nodePort
   nodePort 是外部访问 k8s 集群中 service 的端口，通过 nodeIP: nodePort 可以从外部访问到某个 service。
3. targetPort
   targetPort 是 Pod 的端口，从 port 或 nodePort 来的流量经过 kube-proxy 反向代理负载均衡转发到后端 Pod 的 targetPort 上，最后进入容器。
4. 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 实操技能。