k8s:Deployment

最新推荐文章于 2024-05-03 16:35:59 发布

波浪Y

最新推荐文章于 2024-05-03 16:35:59 发布

阅读量203

点赞数 1

分类专栏： k8s 文章标签： linux 运维容器 k8s docker

本文链接：https://blog.csdn.net/m0_50434960/article/details/114482747

版权

k8s 专栏收录该内容

22 篇文章 0 订阅

订阅专栏

Deployment

推荐使用Deployment这种控制器，而不是RC或者RS，这是为什么呢?

对比下二者之间的功能吧，首先RC是Kubernetes的一个核心概念，当我们把应用部署到集群之后，需要保证应用能够持续稳定的运行，RC就是这个保证的关键，主要功能如下：

确保Pod数量：它会确保Kubernetes中有指定数量的Pod 在运行，如果少于指定数量的Pod，RC就会创建新的，反之这会删除多余的，保证Pod的副本数量不变。
确保Pod健康：当Pod不健康，比如运行出错了，总之无法提供正常服务时，RC也会杀死不健康的Pod，重新创建新的。
弹性伸缩：在业务高峰或者低峰的时候，可以通过RC来动态的调整Pod数量来提高资源的利用率，当然我们也提到过如果使用HPA这种资源对象的话可以做到自动伸缩。
滚动升级：滚动升级是一种平滑的升级方式，通过逐步替换的策略，保证整体系统的稳定性。

Deployment同样也是Kubernetes系统的一个核心概念，主要职责和RC一样的都是保证Pod的数量和健康，二者大部分功能都是完全一致的，我们可以看成是一个升级版的RC控制器，那Deployment又具备那些新特性呢？

RC的全部功能：Deployment具备上面描述的RC的全部功能
事件和状态查看：可以查看Deployment的升级详细进度和状态
回滚：当升级Pod的时候如果出现问题，可以使用回滚操作回滚到之前的任一版本
版本记录：每一次对Deployment的操作，都能够保存下来，这也是保证可以回滚到任一版本的基础
暂停和启动：对于每一次升级都能够随时暂停和启动

作为对比，我们知道Deployment作为新一代的RC，不仅在功能上更为丰富了，同时我们也说过现在官方也都是推荐使用Deployment来管理Pod的，比如一些官方组件kubedns、kube-proxy也都是使用的Deployment来管理的，所以大家也最好使用Deployment来管理Pod。

在这里插入图片描述
可以看出一个Deployment拥有多个Replica Set，而一个Replica Set拥有一个或多个Pod。一个Deployment控制多个rs主要是为了支持回滚机制，每当Deployment操作时，Kubernetes会重新生成一个Replica Set并保留，以后有需要的话就可以回滚至之前的状态。

在这里插入图片描述
下面创建一个Deployment，它创建了一个Replica Set来启动2个nginx pod。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-demo
  labels:
    demo: deployment-demo
spec:
  replicas: 2
  selector:
    matchLabels:
      demo: deployment-demo
  template:
    metadata:
      labels:
        demo: deployment-demo
    spec:
      containers:
      - name: nginx
        image: nginx:1.13.3
        ports:
        - containerPort: 80
[root@master ~]# kubectl  get deployments.apps 
NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
deployment-demo          2/2     2            2           3m35s

[root@master ~]# kubectl  get pods 
NAME                                      READY   STATUS      RESTARTS   AGE
deployment-demo-5598c869bb-bk2j6          1/1     Running     0          3m53s
deployment-demo-5598c869bb-kjp5z          1/1     Running     0          3m53s

[root@master ~]# kubectl  get pods --show-labels 
NAME                                      READY   STATUS      RESTARTS   AGE     LABELS
deployment-demo-5598c869bb-bk2j6          1/1     Running     0          5m38s   demo=deployment-demo,pod-template-hash=5598c869bb
deployment-demo-5598c869bb-kjp5z          1/1     Running     0          5m38s   demo=deployment-demo,pod-template-hash=5598c869bb

[root@master ~]# kubectl  describe pods deployment-demo-5598c869bb-
Events:
  Type    Reason     Age        From               Message
  ----    ------     ----       ----               -------
  Normal  Scheduled  <unknown>  default-scheduler  Successfully assigned default/deployment-demo-5598c869bb-kjp5z to node1
  Normal  Pulling    29m        kubelet, node1     Pulling image "nginx:1.13.3"
  Normal  Pulled     28m        kubelet, node1     Successfully pulled image "nginx:1.13.3"

上面的Deployment的yaml文件中的replicas:2将会保证我们始终有2个POD在运行。
由于Deployment和RC的功能大部分都一样的，下面演示下Deployment的滚动升级和回滚功能。

滚动升级

现在将yaml文件中的nginx镜像修改为nginx(默认最新latest)，然后在spec下面添加滚动升级策略：

spec:
  replicas: 2
  minReadySeconds: 5
  strategy:
# 指定滚动更新的策略
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
         
[root@master ~]# kubectl  get pods -o wide 
NAME                                      READY   STATUS      RESTARTS   AGE     IP             NODE    NOMINATED NODE   READINESS GATES
deployment-demo-7c9555bf46-s68qb          1/1     Running     0          8m46s   10.244.3.196   node2   <none>           <none>
deployment-demo-7c9555bf46-xsxmz          1/1     Running     0          8m46s   10.244.3.197   node2   <none>           <none>

[root@master ~]# kubectl  describe pods deployment-demo-7c9555bf46-
Events:
  Type    Reason     Age        From               Message
  ----    ------     ----       ----               -------
  Normal  Scheduled  <unknown>  default-scheduler  Successfully assigned default/deployment-demo-7c9555bf46-xsxmz to node2
  Normal  Pulled     7m57s      kubelet, node2     Container image "nginx" already present on machine
  Normal  Created    7m57s      kubelet, node2     Created container nginx
  Normal  Started    7m56s      kubelet, node2     Started container nginx

[root@master ~]# kubectl  get rs
NAME                                DESIRED   CURRENT   READY   AGE
deployment-demo-5598c869bb          0         0         0       44m
deployment-demo-7c9555bf46          2         2         2       12m

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处于无法服务的状态。

查看状态
[root@master ~]# kubectl rollout status deployment deployment-demo 
deployment "deployment-demo" successfully rolled out
暂停升级
[root@master ~]# kubectl  rollout pause deployment deployment-demo 
deployment.apps/deployment-demo paused
继续升级
[root@master ~]# kubectl rollout resume deployment deployment-demo 
deployment.apps/deployment-demo resumed

回滚Deployment

我们已经能够滚动平滑的升级我们的Deployment，但是如果升级后的POD出了问题该怎么办？最好最快的方式当然是回退到上一次能够提供正常工作的版本，Deployment就为我们提供了回滚机制。

首先，查看Deployment的升级历史：

[root@master ~]# kubectl  rollout history deployment deployment-demo 
deployment.apps/deployment-demo 
REVISION  CHANGE-CAUSE
1         <none>
2         <none>

[root@master ~]# kubectl  apply -f dep-demo.yaml --record

 [root@master ~]# kubectl  rollout history deployment deployment-demo 
deployment.apps/deployment-demo 
REVISION  CHANGE-CAUSE
1         <none>
2         kubectl apply --filename=dep-demo.yaml --record=true

从上面的结果可以看出在执行Deployment升级的时候最好带上record参数，便于我们查看历史版本信息。

默认情况下，所有通过kubectl xxxx --record都会被kubernetes记录到etcd进行持久化，这无疑会占用资源，最重要的是，时间久了，当你kubectl get rs时，会有成百上千的垃圾RS返回给你，那就不是我们想要的效果。

上生产时，我们最好通过设置Deployment的.spec.revisionHistoryLimit来限制最大保留的revision number，比如15个版本，回滚的时候一般只会回滚到最近的几个版本就足够了。其实rollout history中记录的revision都和ReplicaSets一一对应。如果手动delete某ReplicaSet，对应的rollout history就会被删除，也就是还说你无法回滚到这个revison了。

rollout history和ReplicaSet的对应关系，可以在kubectl describe rs $RSNAME返回的revision字段中得到，这里的revision就对应着rollout history返回的revison。

同样我们可以使用下面的命令查看单个revison的信息：

[root@master ~]# kubectl  rollout history deployment deployment-demo --revision=2
deployment.apps/deployment-demo with revision #2
Pod Template:
  Labels:	demo=deployment-demo
	pod-template-hash=7c9555bf46
  Annotations:	kubernetes.io/change-cause: kubectl apply --filename=dep-demo.yaml --record=true
  Containers:
   nginx:
    Image:	nginx
    Port:	80/TCP
    Host Port:	0/TCP
    Environment:	<none>
    Mounts:	<none>
  Volumes:	<none>

假如现在要直接回退到当前版本的前一个版本：

kubectl rollout undo deployment nginx-deploy
deployment.apps/nginx-deploy rolled back

当然也可以用revision回退到指定的版本：

[root@master ~]# kubectl  rollout undo deployment deployment-demo --to-revision=1
deployment.apps/deployment-demo rolled back

[root@master ~]# kubectl  get pods
NAME                                      READY   STATUS              RESTARTS   AGE
deployment-demo-5598c869bb-7sdv2          0/1     ContainerCreating   0          18s
deployment-demo-5598c869bb-f6z8r          0/1     ContainerCreating   0          18s

[root@master ~]# kubectl  get pods 
NAME                                      READY   STATUS      RESTARTS   AGE
deployment-demo-5598c869bb-7sdv2          1/1     Running     0          4m29s
deployment-demo-5598c869bb-f6z8r          1/1     Running     0          4m29s

[root@master ~]# kubectl  describe pods deployment-demo-5598c869bb-
Events:
  Type    Reason     Age        From               Message
  ----    ------     ----       ----               -------
  Normal  Scheduled  <unknown>  default-scheduler  Successfully assigned default/deployment-demo-5598c869bb-f6z8r to node1
  Normal  Pulled     4m4s       kubelet, node1     Container image "nginx:1.13.3" already present on machine
  Normal  Created    4m4s       kubelet, node1     Created container nginx
  Normal  Started    4m4s       kubelet, node1     Started container nginx

Deployment总结：

扩容
[root@master ~]# kubectl  scale deployment deployment-demo --replicas=3

更新镜像方法
1.set
[root@master ~]# kubectl  set image -f dep-demo.yaml  nginx=nginx1.13.3
2.edit
[root@master ~]# kubectl  edit deployments.apps deployment-demo
3.更改yaml
[root@master ~]# kubectl  apply -f dep-demo.yaml

波浪Y

关注

1
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
k8s:Deployment

Deployment推荐使用Deployment这种控制器，而不是RC或者RS，这是为什么呢?对比下二者之间的功能吧，首先RC是Kubernetes的一个核心概念，当我们把应用部署到集群之后，需要保证应用能够持续稳定的运行，RC就是这个保证的关键，主要功能如下：确保Pod数量：它会确保Kubernetes中有指定数量的Pod 在运行，如果少于指定数量的Pod，RC就会创建新的，反之这会删除多余的，保证Pod的副本数量不变。确保Pod健康：当Pod不健康，比如运行出错了，总之无法提供正常服务时，RC
复制链接

扫一扫