第四章 应用程序生命周期管理（上）
1、在Kubernetes中部署应用流程
1.1 使用Deployment部署Java应用
在 Kubernetes 中，Deployment 是一种控制器，用于管理 Pod 的部署和更新。以下是使用 Deployment 部署 Java 应用的步骤：
1）创建 Deployment
使用 kubectl create deployment 命令创建一个名为 web 的 Deployment，并指定要使用的镜像：
kubectl create deployment web --image=lizhenliang/java-demo使用 kubectl get 命令显示 Deployment 和 Pod 的详细信息，包括名称、状态、副本数等
kubectl get deployment,pods2）使用 Service 发布Pod
在 Kubernetes 中，Service 用于将一组 Pod 暴露给外部网络。以下是使用 Service 发布 Pod 的步骤：
使用 kubectl expose 命令创建一个 Service，并指定要暴露的端口和类型：
kubectl expose deployment web --port=80 --type=NodePort --target-port=8080 --name=web--port=80：Service 的端口为 80
--type=NodePort：Service 类型为 NodePort，这意味着 Service 会在每个节点的 IP 地址上暴露一个端口
--target-port=8080：Pod 的端口为 8080
--name=web：Service 的名称为 web
使用 kubectl get 命令查看 Service 的状态：
kubectl get service
2、服务编排（YAML）
2.1 YAML文件格式说明
YAML（YAML Ain't Markup Language）是一种人类可读的数据序列化格式，广泛用于配置文件和数据交换。在 Kubernetes 中，YAML 文件用于定义和配置各种资源，如 Pod、Deployment、Service 等。以下是 YAML 语法格式的详细说明：
① 缩进表示层级关系
YAML 使用缩进来表示层级关系，类似于 Python。缩进必须是空格，不能使用制表符（Tab）。通常建议使用 2 个空格进行缩进。
level1: level2: level3: value② 不支持制表符“tab”缩进，使用空格缩进
YAML 解析器对制表符非常敏感，因此必须使用空格进行缩进。
# 错误的缩进（使用制表符） level1: level2: value # 正确的缩进（使用空格） level1: level2: value③ 通常开头缩进 2 个空格
为了保持一致性和可读性，通常建议在每个层级开始时缩进 2 个空格。
level1: level2: level3: value④ 字符后缩进 1 个空格，如冒号、逗号等
在键值对中，冒号（
:）后面通常需要跟一个空格。key: value⑤ “---” 表示 YAML 格式，一个文件的开始
在 YAML 文件中，“- - -” 用于表示一个新的文档的开始。一个文件中可以包含多个文档，每个文档以“- - -” 开头。
--- document1: key1: value1 --- document2: key2: value2⑥ “#” 注释
YAML 支持使用
#进行注释。注释行以#开头，不会被解析器处理。# 这是一个注释 key: value # 这也是一个注释
2.2 YAML文件创建资源对象
2.2.1 Deployment
| apiVersion | API版本 |
| kind | 资源类型，即功能 |
| metadata | 资源元数据（name资源名字、namespace命名空间） |
| spec | 资源规格 |
| replicas | 副本(实例)数量 |
| selector | 标签选择器，与下面metadata.labels保持一致 |
| template | Pod模板 |
| metadata | Pod元数据 |
| spec | Pod规格 |
| containers | 容器配置 |
将你需要创建的资源描述到YAML文件中：
- 部署：kubectl apply -f xxx.yaml
- 执行多部署：kubectl apply -f xxx1.yaml -f xxx2.yaml
- 卸载：kubectl delete -f xxx.yaml
示例：Kubernetes Deployment YAML 文件
使用 kubectl create deployment 命令创建一个 Deployment并指定镜像、副本数和命名空间。命令示例：（添加 -o 选项 可导出YAML）
kubectl create deployment web --image=lizhenliang/java-demo --replicas=3 -n default使用 YAML 文件来定义和创建 Deployment，内容如下：
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
namespace: default
labels:
app: web
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: lizhenliang/java-demo
ports:
- containerPort: 8080
解释说明：
apiVersion: apps/v1：指定 API 版本。
kind: Deployment：指定资源类型为 Deployment。
metadata：定义资源的元数据，包括名称、命名空间和标签。
name: web：Deployment 的名称为 web。
namespace: default：Deployment 所在的命名空间为 default。
labels：为 Deployment 添加标签 app: web。
spec：定义 Deployment 的详细规格。
replicas: 3：指定副本数为 3。
selector：定义选择器，用于匹配 Pod 标签。
matchLabels：匹配标签 app: web。
template：定义 Pod 模板。
metadata：定义 Pod 的元数据，包括标签 app: web。
spec：定义 Pod 的详细规格。
containers：定义容器列表。
name: web：容器的名称为 web。
image: lizhenliang/java-demo：使用的镜像为 lizhenliang/java-demo。
ports：定义容器端口。
containerPort: 8080：容器端口为 8080。
2.2.2 Service
| port | Service端口，通过ClusterIP访问用 |
| targetPort | 镜像内服务端口，例如nginx镜像是80 |
| selector | 标签选择器，与Deployment中标签保 持一致 |
| type | Service类型 |
示例：Kubernetes Service YAML 文件
使用 kubectl expose 命令为现有的 Deployment 创建一个 Service，并指定端口、目标端口和服务类型。以下是命令示例：
kubectl expose deployment web --port=80 --target-port=8080 --type=NodePort -n default创建一个名为 web-service.yaml 的文件，内容如下：
apiVersion: v1
kind: Service
metadata:
name: web-service
namespace: default
labels:
app: web
spec:
type: NodePort
ports:
- port: 80
targetPort: 8080
selector:
app: web解释说明：
apiVersion: v1：指定 API 版本。
kind: Service：指定资源类型为 Service。
metadata：定义资源的元数据，包括名称、命名空间和标签。
name: web-service：Service 的名称为 web-service。
namespace: default：Service 所在的命名空间为 default。
labels：为 Service 添加标签 app: web。
spec：定义 Service 的详细规格。
type: NodePort：指定服务类型为 NodePort，允许外部访问。
ports：定义服务端口和目标端口。
port: 80：Service 的端口为 80。
targetPort: 8080：目标端口为 8080，即 Pod 中容器的端口。
selector：定义选择器，用于匹配 Pod 标签。
app: web：匹配标签 app: web 的 Pod。
— 定义标签：
注意：Service中的selector字段指定Lables，即左图红框内的Lables保持一致
① 一般推荐定义两个，由项目和应用组成，例如：
project: ec //键：值，可任意定义
app: portal
② matchLabels 必须与下面labels保持一致，否则apply会报错
apiVersion: apps/v1
...
spec:
selector:
matchLabels:
project: ec //指定项目
app: portal //指定应用
template:
metadata:
labels:
project: ec
app: portal
...Service是通过标签进行转发（负载均衡），获取Service关联后面Pod的IP
kubectl get endpoints2.2.3 资源字段太多，记不住怎么办
Kubernetes 的资源字段非常多，完全记住所有字段是不现实的。以下是一些实用的方法来帮助你管理和生成 YAML 文件：
1. 使用 create 命令生成 YAML 文件
使用 kubectl create 命令结合 -o yaml 和 --dry-run=client 选项生成 YAML ，而不实际创建资源。
kubectl create deployment nginx --image=nginx:1.16 -o yaml --dry-run=client > my-deploy.yaml
-o yaml：以 YAML 格式输出
--dry-run=client：在客户端模拟运行，不实际创建资源--dry-run=server：提交到api层面尝试运行
2. 使用 get 命令导出现有资源的 YAML 文件
如果已创建了一个资源，可使用 kubectl get 命令将其导出为 YAML 文件
kubectl get deployment nginx -o yaml > my-deploy.yaml
3. 使用 kubectl explain 命令查看字段说明
kubectl explain 命令可帮助查看资源的字段说明，了解每个字段的含义和用法
kubectl explain pods.spec.containers
kubectl explain deployment
4. 参考官方文档的示例
Kubernetes 官方文档提供了丰富的示例和详细的字段说明，是学习和参考的好资源。
- Kubernetes 官方文档
- Kubernetes API 参考
3、Deployment 工作负载
3.1 介绍
Deployment是最常用的K8s工作负载控制器（Workload Controllers）， 是K8s的一个抽象概念，用于更高级层次对象，部署和管理Pod。其他控制器还有DaemonSet、StatefulSet等。
1. 管理 Pod 和 ReplicaSet
- Pod：Kubernetes 中最小的部署单元，包含一个或多个容器。
- ReplicaSet：确保指定数量的 Pod 副本始终运行。
- Deployment：管理 ReplicaSet，从而间接管理 Pod。
2. 主要功能
- 上线部署：通过定义新的 ReplicaSet 来部署新版本的 Pod。
- 副本设定：指定 Pod 的副本数量，确保应用的高可用性。
- 滚动升级：逐步替换旧版本的 Pod，实现平滑升级。
- 回滚：在升级过程中出现问题时，可以回滚到之前的版本。
3. 应用场景
- 网站：部署和管理网站的前端和后端服务。
- API：部署和管理 API 服务，确保 API 的高可用性和可扩展性。
- 微服务：管理微服务架构中的各个服务，实现服务的独立部署和升级。
3.2 应用生命周期管理流程
1. 部署（Deployment）
部署是将应用程序首次部署到 Kubernetes 集群中的过程。这个过程通常包括以下步骤：
- 编写 YAML 文件：定义 Deployment、Service 等资源
- 应用 YAML 文件：使用 kubectl apply -f <filename>.yaml 命令将资源应用到集群中
- 验证部署：使用 kubectl get pods 和 kubectl get deployments 验证 Pod 和 Deployment 状态
2. 升级（Upgrade）
升级是指将应用程序更新到新版本的过程。Kubernetes 提供滚动升级（Rolling Update）策略，确保在升级过程中服务不中断。
- 更新 YAML 文件：修改 Deployment 中的镜像版本或其他配置
- 应用更新：使用 kubectl apply -f <filename>.yaml 命令应用更新
- 监控升级过程：使用 kubectl rollout status deployment/<deployment-name> 监控升级状态
3. 回滚（Rollback）
回滚是指在升级过程中出现问题时，将应用程序恢复到之前的版本。Kubernetes 提供了回滚功能，可以轻松地将 Deployment 回滚到之前的版本。
- 回滚到上一个版本：使用 kubectl rollout undo deployment/<deployment-name> 命令。
- 回滚到指定版本：使用 kubectl rollout undo deployment/<deployment-name> --to-revision=<revision-number> 命令。
4. 下线（Deletion）
下线是指将应用程序从 Kubernetes 集群中移除的过程。这个过程通常包括以下步骤：
- 删除 Deployment：使用 kubectl delete deployment/<deployment-name> 命令删除 Deployment
- 删除 Service：如果存在相关的 Service，使用 kubectl delete service/<service-name> 命令删除 Service
3.3 应用部署
通过 Deployment 部署镜像，两种方式：
- ① kubectl create deployment web --image=nginx:1.16 --replicas=3
- ② kubectl apply -f xxx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
namespace: default
spec:
replicas: 3 # Pod副本预期数量
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web # Pod副本的标签
spec:
containers:
- name: web
image: nginx:1.16 //指定镜像版本3.4 应用升级
应用升级主要对象为镜像，镜像里面是包含了项目和运行环境例如nginx，在修改YAML的镜像并执行时，Deployment控制器会根据检测到的镜像版本进行升级；即 修改镜像默认是产生的一次滚动升级（更新镜像三种方式，自动触发滚动升级）
方式1：kubectl apply -f xxx.yaml
...
spec:
containers:
- name: web
image: nginx:1.16 //修改指定镜像版本方式2：kubectl set image deployment 容器名=镜像名称:版本 //非交互
kubectl set image deployment web web=nginx:1.17
注意：容器名为 -name：定义的名字
备注：升级新的镜像是通过创建新的副本且升级完成的情况下，通过删除旧镜像进行去替换
方式3：kubectl edit deployment # 使用系统编辑器，在线打开
kubectl edit deployment web补充：edit在线编辑，只有个别的资源可以使用
3.4.1 滚动升级详细介绍
滚动发布是指每次只升级一个或多个服务，升级完成后加入生产环境，不断执行这个过程，直到集群中 的全部旧版本升级新版本。
了解：有关K8S的主流发布方案，每种方案都有其独特的优势和适用场景。
① 滚动升级（Rolling Update）
Kubernetes 默认的升级策略，适用于大多数场景。它通过逐步替换旧版本的 Pod，实现平滑升级，确保在升级过程中服务不中断。
- 逐步替换：逐步创建新版本的 Pod，并删除旧版本的 Pod
- 平滑过渡：在升级过程中，新旧版本的 Pod 可以同时存在，确保服务的连续性
- 自动回滚：如果升级过程中出现问题，Kubernetes 可以自动回滚到之前的版本
② 蓝绿升级（Blue-Green Deployment）
是一种更复杂的发布策略，适用于需要零停机时间和快速回滚的场景。它将目标服务器分为两组：蓝组和绿组。先升级一组（例如蓝组），上线后没问题再升级另一组（绿组）。
- 零停机时间：在升级过程中，始终有一组服务在运行，确保服务的连续性
- 快速回滚：如果新版本出现问题，可以快速切换回旧版本
- 资源消耗：需要两倍的服务器资源，因为两组服务同时运行
③ 灰度升级（Canary Deployment）
是一种逐步发布新版本的策略，适用于需要逐步验证新版本稳定性的场景。它按照一定百分比升级，例如先升级 10%，继续 50%，最后 40%。
- 逐步验证：逐步将流量切换到新版本，验证其稳定性
- 风险控制：如果新版本出现问题，可以快速回滚，减少影响范围
- 灵活性：可以根据实际情况调整升级比例
滚动升级在K8s中的实现：
- 1个Deployment
- 2个ReplicaSet
滚动更新一次只升级一小部分Pod，成功后，再升级一部分Pod，最终完成 所有Pod升级，整个过程始终有Pod在运行，从而保证了业务的连续性。
查看滚动升级过程：
使用 kubectl describe deployment web 命令查看详情
新建RS web-nginx-f5f6b7648，并设置副本为1
缩容RS web-nginx-6b999f8f 副本数由3到2
扩容RS web-nginx-f5f6b7648 副本数由1到2
缩容RS web-nginx-6b999f8f 副本数由2到1
扩容RS web-nginx-f5f6b7648 副本数由2到3
缩容RS web-nginx-6b999f8f 副本数由1到0
- 备注：Scaled up RS 新建/扩容 ，Scaled down RS 缩容
- 备注：deployment pod 名称格式组成 ：deployment名称-RS 名称-随机字符串
3.4.2 ReplicaSet控制器
ReplicaSet：副本集，主要维护Pod副本数量，不断对比当前Pod数量 与期望Pod数量（在Deployment控制器创建的Pod中进行删除Pod的操作，ReplicaSet会自动帮忙拉起新的Pod）
用途：Deployment每次发布都会创建一个RS作为记录， 用于实现滚动升级和回滚（一个RS相当于一次历史的版本）
① 查看RS记录
- 命令：kubectl get replicaset
[root@k8s-master-1-71 ~]# kubectl get replicaset
NAME DESIRED CURRENT READY AGE
web-5cc97bc7d5 1 1 1 3h35m
# 或者
kubectl get rs② 查看详细RS记录
- 命令：kubectl describe rs
[root@k8s-master-1-71 ~]# kubectl describe rs web-5cc97bc7d5
Name: web-test-yaml-5cc97bc7d5
Namespace: default
Selector: app=web,pod-template-hash=5cc97bc7d5
Labels: app=web
pod-template-hash=5cc97bc7d5
Annotations: deployment.kubernetes.io/desired-replicas: 1
deployment.kubernetes.io/max-replicas: 2
deployment.kubernetes.io/revision: 1
Controlled By: Deployment/web-test-yaml
Replicas: 1 current / 1 desired
Pods Status: 1 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=web
pod-template-hash=5cc97bc7d5
Containers:
nginx:
Image: nginx
Port: <none>
Host Port: <none>
Environment: <none>
Mounts: <none>
Volumes: <none>
Events: <none>
③ 查看版本对应RS记录
- 命令：kubectl rollout history deployment
[root@k8s-master-1-71 ~]# kubectl rollout history deployment web-nginx
deployment.apps/web-nginx
REVISION CHANGE-CAUSE
1 <none>
2 <none>
3.5 回滚
用途：项目升级失败恢复到正常版本
① 回滚上一个版本
- 命令：kubectl rollout undo deployment
[root@k8s-master-1-71 ~]# kubectl rollout undo deployment web-nginx
② 回滚历史指定版本
- 命令：kubectl rollout undo deployment web --to-revision=版本记录
[root@k8s-master-1-71 ~]# kubectl rollout undo deployment web-nginx --to-revision=4
注：回滚是重新部署某一次部署时的状态，即当时版本所有配置
通过脚本方式获取历史发布版本与镜像对应关系：
脚本如下：
kubectl describe $(kubectl get rs -o name) | egrep "revision:|Image:"- 解释：发布镜像的RS记录名称（版本） kubectl get rs -o name // -o name 只获取rs名称
- 解释：每个RS对应一个镜像的RS版本与发布历史版本号 kubectl describe rs
测试：
for i in {1..1000}
do
sleep 1
curl -I http://192.168.1.71:32233
done3.6 项目下线
- 命令：kubectl delete deployment/web
- 命令：kubectl delete svc/web
3.7 应用实力扩容和缩容
水平扩/缩容实现方式（场景：当并发过大，可以启动多个Pod实例，应对提高并发）
- 修改yaml里的 replicas 值，再apply -f xxx.yaml文件
- kubectl scale deployment --replicas=副本数
注：replicas参数控制Pod副本数量
[root@k8s-master-1-71 ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
web-nginx-7bbcc98c54-6rd6f 1/1 Running 0 6m40s
web-nginx-7bbcc98c54-prtgm 1/1 Running 0 6m43s
web-nginx-7bbcc98c54-x69wf 1/1 Running 0 6m38s
# 从3副本缩容至2副本
[root@k8s-master-1-71 ~]# kubectl scale deployment web-nginx --replicas=2
deployment.apps/web-nginx scaled
[root@k8s-master-1-71 ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
web-nginx-7bbcc98c54-6rd6f 1/1 Running 0 8m5s
web-nginx-7bbcc98c54-prtgm 1/1 Running 0 8m8s
# 从2副本扩容至5副本
[root@k8s-master-1-71 ~]# kubectl scale deployment web-nginx --replicas=5
deployment.apps/web-nginx scaled
[root@k8s-master-1-71 ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
web-nginx-7bbcc98c54-6rd6f 1/1 Running 0 8m47s
web-nginx-7bbcc98c54-9jcv4 1/1 Running 0 12s
web-nginx-7bbcc98c54-g48n8 1/1 Running 0 12s
web-nginx-7bbcc98c54-hkdrk 1/1 Running 0 12s
web-nginx-7bbcc98c54-lccp9 1/1 Running 0 12s课后作业
1、创建一个deployment 副本数 3，然后滚动更新镜像版本，并记录这个更新记录，最后再回滚到上一个版本
- 名称：nginx
- 镜像版本：1.16
- 更新镜像版本：1.17
2、给web deployment扩容副本数为3
3、把deployment输出json文件，再删除创建的deployment
4、生成一个deployment yaml文件保存到/opt/deploy.yaml
- 名称：web
- 标签：app_env_stage=dev
小结：
本篇为 【Kubernetes CKA认证 Day3】的学习笔记，希望这篇笔记可以让您初步了解到 YAML文件如何编排，Deployment的工作负载模式，K8S一般生命周期管理流程等，课后还有扩展实践，不妨跟着我的笔记步伐亲自实践一下吧！
Tip：毕竟两个人的智慧大于一个人的智慧，如果你不理解本章节的内容或需要相关笔记、视频，可私信小安，请不要害羞和回避，可以向他人请教，花点时间直到你真正的理解。
