K8S 进阶 -2(deployment,replicateSet...)

写在前面:

deployment和replicateSet都是管理pod的工具,那么他们是如何工作呢?先上图

 

deploy控制RS,RS控制Pod,这一整套,向外提供稳定可靠的Service

 

实战:

我们先创建一个deployment。

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx-deployment
  #指定域
  namespace: nginx
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.14.0
        name: nginx
        volumeMounts:
        - name: conf
          mountPath: /etc/nginx/nginx.conf
        - name: log
          mountPath: /var/log/nginx/
        - name: html
          mountPath: /etc/nginx/html
      #标签选择器(集群状态下,可以指定服务部署在特定node节点上,这就是标签的作用)
      #nodeSelector:
        #type: nginx
      #设置污点可以调度到对应服务器
      tolerations:
      - key: "key"
        operator: "Equal"
        value: "nginx"
        effect: "NoSchedule"
      volumes:
      - name: conf
        hostPath:
          path: /usr/local/nginx/conf/nginx.conf
      - name: log
        hostPath:
          path: /usr/local/nginx/logs
          type: Directory
      - name: html
        hostPath:
          path: /usr/local/nginx/html
          type: Directory

接下来,看看我们生成的pod,deploy.,rs

可以看到,在生成一个nginx-deployment 的同时生成了一个rs(nginx-deployment-5d7975b79c)。同时还包含资源最小单位POD。在他的历史版本中也出现了这一个版本记录。

一,修改replicas

 

可以看到修改replicas之后,无论是deploy, rs, history 都不会变,只会增加pod的数量,而且原来的pod并不会改变。在注意一下版本历史,也没有改变。

二,修改image

这里面涉及的东西就很多了。慢慢来

第一个变化:肯定是 rs无缘无故多了一个。其实想想也很简单。因为出现版本的变化,pod肯定是要更新的,最前面我们也说了,deploy是通过 rs去管理pod的。当我们更新时,肯定会多一个副本集,注意TAG那一列。

第二个变化:pod由原来的nginx-deployment-5d7975b79c-* 变成 nginx-deployment-77fcbbfc7b-*系列。前缀时rs的名字。这个变化很简单,自己想想喽,这里想说的时另外一个 处于Terminating状态,最后消失的pod。为什么呢? 还记得之前我们说过strategy这个标签吗,当type为rollingUpdate时,它定义了最大不可用和最大不可超两个含义。在replicas=3, maxSure=25%的时候,也就是说最大pod的数量为4个(大约)。当我们三个新的pod全部更新成功的时候,这一个 也会最终消失。如果更新失败呢,比如镜像not found?这里给出答案,三个旧的pod不变,多出一个新的containercreatinferror 的pod。

第三个变化:历史版本多了一个。看他的change-cause 可以看明白为什么。

 

讲到这里,你应该可以明白deploy, rs,的关系了吧。

 

接下来,我们看看 另外一组命令 kubectl rollout pause/resume/undo deploy/nginx-deployment -n nginx

 pause 暂停功能
resume恢复功能(用于启动被pause的deploy服务)
undo取消功能 (可以指定版本回归(kubectl rollout history deploy/nginx-deployment -n nginx))

经过pause之后,修改镜像,pod并不会变化,尽管deploy的镜像版本已经变化。接下来我们 恢复deploy的功能。

 

第一次,我们使用错误的镜像,多了一个errimagepull 的pod,旧的pod并没有改变。在我们使用resume之后,自动更新了pod。

更多操作见(K8S 进阶 -3 (金丝雀发布、滚动更新、蓝绿部署) 

更多可参考 http://docs.kubernetes.org.cn/645.html

  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值