带你学会k8s 更高级的对象Deployment
Deployment 引入
前面我们学习了 RC 和 RS 两种资源对象，它们的功能基本上是差不多的，唯一的区别就是 RS 支持集合的 selector。
另外，前面我们也了解了如何用 RC/RS 资源对象来控制 Pod 副本的数量，如何实现了滚动升级 Pod 的功能。现在回过头来看，似乎这些操作都比较完美了，但是在上一篇文章中最后也提到了：现在官方推荐我们使用 Deployment 这种控制器了，而不是前面所学的 RC 和 RS，大家知道原因吗？
Deployment & RC 对比
没有对比就没有伤害，我们来看下它们之间有什么异同吧。首先 RC 是 Kubernetes 的一个核心概念，当我们把应用部署到集群之后，需要保证应用能够持续稳定的运行，RC 就是这个保证的关键，其主要功能如下：
- 维持 Pod 的数量：它会确保 Kubernetes 中有指定数量的 Pod 在运行，如果少于指定数量的 Pod，RC 就会创建新的，反之这会删除多余的，保证 Pod 的副本数量不变。
- 保证 Pod 健康：当 Pod 运行出错了，无法提供正常服务时，RC 会杀死不健康的 Pod，然后重新创建新的。
- 可以弹性伸缩：在业务高峰或者低峰的时候，可以用过 RC 来动态的调整 Pod 数量来提供资源的利用率，当然我们也提到过如果使用 HPA 这种资源对象的话可以做到自动伸缩。
- 滚动升级：滚动升级是一种平滑的升级方式，通过逐步替换的策略，保证整体系统的稳定性，这个前面我们也已经讲过了。
Deployment 同样也是 Kubernetes 系统的一个核心概念，主要职责和 RC 一样，都是确保 Pod 的数量和健康，二者大部分功能都是完全一致的，我们可以看成是一个升级版的 RC 控制器，那 Deployment 除了和 RC 一样的功能外，又具备有哪些其它新特性呢？
- 事件和状态查看：可以查看 Deployment 的升级详细进度和状态
- 回滚操作：当升级 Pod 的时候如果出现问题，可以使用回滚操作回滚到之前的任一版本
- 版本记录：每一次对 Deployment 的操作，都能够保存下来，这也是保证可以回滚到任一版本的基础
作为对比，我们知道 Deployment 作为新一代的 RC，不仅在功能上更为丰富了，同时我们也说过现在官方也都是推荐使用 Deployment 来管理 Pod 的，比如一些官方组件 kube-dns、kube-proxy 也都是使用的 Deployment 来管理的，所以当大家在使用的使用也最好使用 Deployment 来管理 Pod。
Deployment 创建
其实一个 Deployment 资源控制器拥有多个 Replica Set，而一个 Replica Set 拥有一个或多个 Pod。一个 Deployment 可以控制多个 rs 主要是为了支持回滚机制。每当 Deployment 操作时，Kubernetes 会重新生成一个 Replica Set 并保留，以后有需要的话就可以回滚至之前的状态。
下面创建一个 Deployment，它创建了一个 Replica Set 来启动 3 个 nginx pod，yaml 文件如下：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deploy
labels:
k8s-app: nginx-demo
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.8
ports:
- containerPort: 80
将上面内容保存为: nginx-deployment.yaml，执行命令:
$ kubectl create -f nginx-deployment.yaml deployment "nginx-deploy" created
然后执行一下命令查看刚刚创建的 Deployment:
$ kubectl get deployments NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deploy 3 0 0 0 1s
隔一会再次执行上面命令：
$ kubectl get deployments NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deploy 3 3 3 3 4m
我们可以看到 Deployment 已经创建了 1 个 Replica Set 了，执行下面的命令查看 rs 和 pod:
$ kubectl get rs NAME DESIRED CURRENT READY AGE nginx-deploy-431080110 3 3 3 6m
$ kubectl get pod --show-labels NAME READY STATUS RESTARTS AGE LABELS nginx-deploy-431080110-53z8q 1/1 Running 0 7m app=nginx,pod-template-hash=431080110 nginx-deploy-431080110-bhhq0 1/1 Running 0 7m app=nginx,pod-template-hash=431080110 nginx-deploy-431080110-sr44p 1/1 Running 0 7m app=nginx,pod-template-hash=431080110
上面的 Deployment 的 yaml 文件中的 replicas:3 将会保证我们始终有 3 个 POD 在运行。
由于 Deployment 和 RC 的功能大部分都一样的，我们上节课已经和大家演示了大部分功能了，我们这里重点给大家演示下 Deployment 的滚动升级和回滚功能。
Deployment 滚动升级
现在我们将刚刚保存的 yaml 文件中的 nginx 镜像修改为 nginx:1.12.1，然后在 spec 下面添加滚动升级策略：
minReadySeconds: 5
strategy:
# indicate which strategy we want for rolling update
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
minReadySeconds:
- Kubernetes 在等待设置的时间后才进行升级
- 如果没有设置该值，Kubernetes 会假设该容器启动起来后就提供服务了
- 如果没有设置该值，在某些极端情况下可能会造成服务不正常运行
maxSurge:
- 升级过程中最多可以比原先设置多出的 POD 数量
- 例如：maxSurage=1，replicas=5,则表示 Kubernetes 会先启动 1 一个新的 Pod 后才删掉一个旧的 POD，整个升级过程中最多会有 5+1 个 POD。
maxUnavaible:
- 升级过程中最多有多少个 POD 处于无法提供服务的状态
- 当 maxSurge 不为 0 时，该值也不能为 0
- 例如：maxUnavaible=1，则表示 Kubernetes 整个升级过程中最多会有 1 个 POD 处于无法服务的状态。
然后执行命令：
$ kubectl apply -f nginx-deployment.yaml deployment "nginx-deploy" configured
然后我们可以使用 rollout 命令查看状态：
$ kubectl rollout status deployment/nginx-deploy Waiting for rollout to finish: 1 out of 3 new replicas have been updated.. deployment "nginx-deploy" successfully rolled out
升级结束后，继续查看 rs 的状态：
$ kubectl get rs NAME DESIRED CURRENT READY AGE nginx-deploy-2078889897 0 0 0 47m nginx-deploy-3297445372 3 3 3 42m nginx-deploy-431080110 0 0 0 1h
根据 AGE 我们可以看到离我们最近的当前状态是：3，和我们的 yaml 文件是一致的，证明升级成功了。用 describe 命令可以查看升级的全部信息：
Name: nginx-deploy
Namespace: default
CreationTimestamp: Wed, 18 Oct 2017 16:58:52 +0800
Labels: k8s-app=nginx-demo
Annotations: deployment.kubernetes.io/revision=3
kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"labels":{"k8s-app":"nginx-demo"},"name":"nginx-deploy","namespace":"defa...
Selector: app=nginx
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx:1.12.1
Port: 80/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Progressing True NewReplicaSetAvailable
Available True MinimumReplicasAvailable
OldReplicaSets: <none>
NewReplicaSet: nginx-deploy-3297445372 (3/3 replicas created)
...
Deployment 回滚
我们已经能够滚动平滑的升级我们的 Deployment 了，但是如果升级后的 POD 出了问题该怎么办？我们能够想到的最好最快的方式当然是回退到上一次能够提供正常工作的版本，Deployment 就为我们提供了回滚机制。
首先，查看 Deployment 的升级历史：
$ kubectl rollout history deployment nginx-deploy deployments "nginx-deploy" REVISION CHANGE-CAUSE 1 <none> 2 <none> 3 kubectl apply --filename=Desktop/nginx-deployment.yaml --record=true
从上面的结果可以看出在执行 Deployment 升级的时候最好带上 record 参数，便于我们查看历史版本信息。
默认情况下，所有通过 kubectl xxxx --record 都会被 kubernetes 记录到 etcd 进行持久化，这无疑会占用资源，最重要的是，时间久了，当你 kubectl get rs 时，会有成百上千的垃圾 RS 返回给你，那时你可能就眼花缭乱了。
如果是在生产，我们最好通过设置 Deployment 的.spec.revisionHistoryLimit 来限制最大保留的 revision number，比如 10 个版本，回滚的时候一般只会回滚到最近的几个版本就足够了。其实 rollout history 中记录的 revision 都和 ReplicaSets 一一对应。如果手动 delete 某个 ReplicaSet，对应的 rollout history 就会被删除，也就是还说你无法回滚到这个 revison 了。
同样我们可以使用下面的命令查看单个 revison 的信息：
$ kubectl rollout history deployment nginx-deploy --revision=3
deployments "nginx-deploy" with revision #3
Pod Template:
Labels: app=nginx
pod-template-hash=3297445372
Annotations: kubernetes.io/change-cause=kubectl apply --filename=nginx-deployment.yaml --record=true
Containers:
nginx:
Image: nginx:1.12.1
Port: 80/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
假如现在要直接回退到当前版本的前一个版本：
$ kubectl rollout undo deployment nginx-deploy deployment "nginx-deploy" rolled back
当然也可以用 revision 回退到指定的版本：
$ kubectl rollout undo deployment nginx-deploy --to-revision=2 deployment "nginx-deploy" rolled back
Deployment 扩容
也可以使用以下命令扩容 Deployment：
$ kubectl scale deployment nginx-deploy --replicas 10 deployment "nginx-deployment" scaled
总结
最后我们总结下关于 Deployment 的一些特性和作用吧：
- 具备 RC 的功能：Deployment 具备 RC 的全部功能
- 事件和状态查看：可以查看 Deployment 的升级详细进度和状态，即可以随时知道 Pod 的部署进度
- 滚动升级和回滚：可滚动升级 pod，但当升级 Pod 的时候如果出现问题，也可以使用回滚操作回滚到之前的任一版本
- 版本记录：每一次对 Deployment 的操作，都能够保存下来，这也是保证可以回滚到任一版本的基础
后续会给大家介绍另外一种更加高级且可自动扩缩容 Pod 的资源对象 HPA。
以上就是k8s 还有更高级的"对象"？它叫 Deployment的详细内容，更多关于k8s 对象Deployment的资料请关注脚本之家其它相关文章！
相关文章
k8s是一个轻便的和可扩展的开源平台,用于管理容器化应用和服务,通过k8s能够进行应用的自动化部署和扩缩容,这篇文章主要介绍了k8s的架构组成,需要的朋友可以参考下2024-05-05
这篇文章主要为大家介绍了Containerd容器运行yum安装与二进制安装，有需要的朋友可以借鉴参考下，希望能够有所帮助，祝大家多多进步，早日升职加薪2022-06-06
这篇文章主要介绍了云原生技术kubernetes的相关资料，帮助大家更好的理解和学习使用K8S，感兴趣的朋友可以了解下2021-03-03
这篇文章主要介绍了k8s pod如何使用sriov问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教2024-07-07
这篇文章主要为大家介绍了k8s还有更高级的"对象"Deployment使用示例详解，有需要的朋友可以借鉴参考下，希望能够有所帮助，祝大家多多进步，早日升职加薪2023-04-04
K8s中的临时容器Ephemeral Containers使用
这篇文章主要介绍了K8s中的临时容器Ephemeral Containers使用,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教2024-07-07
这篇文章主要为大家介绍了从小饭馆客流量变大来讨论云原生负载均衡，为大家做出更生动易懂的云原生解释说明有需要的朋友可以借鉴参考下2022-03-03
这篇文章主要为大家介绍了云原生Kubernetes初始化容器Init使用教程，有需要的朋友可以借鉴参考下，希望能够有所帮助祝大家多多进步早日升职加薪2022-03-03
这篇文章主要为大家介绍了k8s安装CICD devtron过程详解，有需要的朋友可以借鉴参考下，希望能够有所帮助，祝大家多多进步，早日升职加薪2022-11-11
Rainbond云原生部署SpringCloud应用架构实践
这篇文章主要为大家介绍了Rainbond云原生部署SpringCloud应用架构实践，有需要的朋友可以借鉴参考下，希望能够有所帮助，祝大家多多进步，早日升职加薪2022-04-04
最新评论