K8s控制器原理介绍

Posted wn1m

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了K8s控制器原理介绍相关的知识,希望对你有一定的参考价值。

Pod控制器:

  ReplicationController:早期K8s只有这一个控制器,但后来发现让这一个来完成所有任务,太复杂.因此被废弃.
  ReplicaSet: 它用于帮助用户创建指定数量的Pod副本,并确保Pod副本数量一直满足用户期望的副本数量。
        副本数量"多退少补"等机制。【它可认为就是ReplicationController的新版本。】
   它由三个主要组件组成:
     1. 用户期望的Pod的副本数量.
        2. 标签选择器: 使用它来选择自己管理的Pod
        3. Pod模板: 若标签选择器选择的副本数量不足,则根据Pod模板来新建.
  Deployment: 它用于帮我们管理无状态Pod的最好的控制器.
      它支持滚动更新,回滚,它还提供了声明式配置的功能,它允许我们将来根据声明的配置逻辑来定义,
      所有定义的资源都可随时进行重新声明,只要该资源定义允许动态更新。
  DaemonSet:用于确保集群节点上只运行一个Pod的控制器。它一般用于构建系统级应用时使用。
      它不能定义副本数量,副本数量要根据集群的规模来自动创建, 即: 若集群中新加入了一个
      node节点,DaemonSet将自动使用Pod模板在新节点上创建一个Pod,并精确保障每个节点上仅
      运行一个Pod. 所以此控制器,必须要有Pod模板 和 标签选择器。
      它还有另一个作用:就是用于控制Pod仅运行在指定满足条件的节点上,并精确确保其只运行一个Pod.
    它所管理的Pod:
      1. 必须是守护进程,要持续运行在后台。
      2. 它没有终止那一刻,即便不忙,它也监听文件的变动 或 用户对某套接字的请求
  Job: 主要用于创建一个完整指定任务的Pod,一旦任务完成,就会退出;但是若任务未完成,则会重新启动,直到任务完成.
  Cronjob: 它是定义一个周期性任务,Pod启动后,和Job启动的Pod类似,也是任务执行完成后才会终止重启。
      同时它还会自动处理一个任务还未完成,下一个启动时间已经到了的问题。


控制器示例:
  ReplicaSet控制器示例:
  #若想了解下面每个参数的含义,可查看 kubectl  explain  replicaset

  vim replicaset.yaml
    apiVersion: apps/v1           #一般来说,一个清单文件的基本格式:
    kind: ReplicaSet      #apiVersion,kind,metadata这是必须的,下面对 spec是replicaSet的一个必要参数.
    metadata:          #要查看spec支持那些参数: kubectl  explain  replicaset.spec 即可.
      name: myapp
      namespace: default
    spec:
      replicas: 2         #这里是定义ReplicaSet的副本数量.
      selector:
       matchLabels:
        app: myapp
        release: canary
      template:    #查看template支持那些参数: kubectl  explain replicaset.spec.template即可查看.
        metadata:
         name: myapp-pod    #通常Pod的名称空间必须和控制器的名称空间一致,故可省略.
         labels:      #这里创建Pod的标签必须和selector的标签符合,否则此Pod将永久被创建下去。
          app: myapp
          release: canary
        spec:
         containers:
         -  name: myapp-container
          image: busybox
          ports:
          -  name:http
           containerPort: 80

#启动:
  kubectl create -f replicaSet.yaml
  kubectl get pods
  kubectl get rs

  kubectl delete pods PodName
  kubectl get pods        #可以查看控制器控制下的Pod个数少了,会自动被创建.

  #接下来测试,控制器控制下的Pod多了会怎么
    kubectl label pods PodName release=canary,app=myapp #给Pod添加标签
    kubectl get pods --show-labels
    注:
        此测试也说明: 在定义控制器所管理的Pod时,一定要精确定义Pod的标签,
     尽量避免出现,用户创建的Pod标签正好和你定义的控制器符合,产生悲剧!
    另外:
      service 和 控制器它们没有直接关系,只是它们都使用标签选择器来获取Pod,
      这也意味着一个Service可管理多个控制器所创建的Pod.

#控制器的配置是支持动态更新的.
  kubectl edit rs replicaset   #将其副本数量修改一个再查看效果。

#它还支持动态更新Pod的镜像版本.
  kubectl edit rs replicaset
  kubectl get rs -o wide
  注:
   这里查看到Pod镜像版本修改了,但实际上正在运行的Pod的镜像版本并没有改变.
  这时若你手动删除一个Pod,新建的Pod将使用新版本创建.
  这样就可以轻松实现 金丝雀 发布更新了,即: 先删除一个,让一个Pod使用新版本,使用新版本Pod
  会得到一部分流量,这一部分流量就可以作为测试流量,若2天后,没有发现用户抱怨Bug,则可以
  手动将Pod一个一个删除,并替换成新版本的Pod。

 

Deployment:

  技术图片

    它是ReplicaSet控制器的控制器,即: Deployment控制器它不直接用于管理Pod,它是用来管理
  ReplicaSet控制器的,这样做的好处是,可实现动态更新和回滚,如上图所示,它能实现
  多种更新方式,上图显示的是 灰度更新 过程,它将ReplicaSetV1控制的Pod,每次一个的
  删除,并在ReplicaSetV2上重建,若ReplicaSetV2上线后,有问题,还能快速回滚到V1.
  通常来说Deployment不会直接删除ReplicaSet,它会保留10个版本,以便回滚使用。

 它通过更新Pod的粒度来实现 灰度更新,金丝雀更新,蓝绿更新。
 它控制Pod创建粒度是 比如:
  1.在删除时,必须保障有5个Pod,但可临时多一个Pod,则它会创建一个,删除一个. 直到全部替换。
  2.必须保障有5个,但可临时少一个Pod,则它会先删除一个,在创建一个,直到全部替换。
  3.必须保障有5个,但可多一个,也可少一个,此时它会创建一个,删除两个,再创建2个,再删除2个,直到全部替换。
  4.还有一种是允许临时多出一倍,则它会一次性创建5个,然后直接替换使用新的Pod,在把老的Pod删除。

Deployment控制参数:
  strategy:    #设置更新策略
  type <Recreate|RollingUpdate>    #指定更新策略类型.Recreate: 它是删除一个,重建一个.
                           RollingUpdate: 这是滚动更新。
  rollingUpdate:
    maxSurge: 用于定义滚动更新时,副本最多允许增加几个. 它支持两种值:
          5: 表示副本数最多增加5个。
          20%: 若你有10个Pod副本, 20%就是最多增加2个副本.
    maxUnavailable: 最多允许几个不可用.它也支持整数 或 百分比.
  revisionHistoryLimit <Int>    #设置保存几个历史ReplicaSet版本.默认10个
  paused <boolean>       #是否在更新前先暂停

vim  myapp-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
     name: myapp-deploy
     namespace: default
spec:
     replicas: 2
     selector:
         matchLabels:
             app:myapp
             release: canary
     template:
            metadata:
                labels:
                     app:myapp
                     release: canary
            spec:
                 cantainers:
                  -   name: myapp
                       image: busybox
                       ports:
                       -   name:http
                           containerPort: 80

 

#编写以上清单文件后,就可以执行:
  kubectl apply -f deploy-demo.yaml

  kubectl get deploy
  kubectl get rs

  vim deploy-demo.yaml
    #修改副本数量为4

  kubectl apply -f deploy-demo.yaml    #修改后再次apply是运行,apply可应用配置多次,并且它会自动反映出清单的变化.

  kubectl describe deploy myapp-deploy    #查看Annotaions,RollingUpdateStrategy.


  #测试动态滚动更新
    vim deploy-demo.yaml
      修改镜像的版本为新版本.

  终端2:
    kubectl get pods -l app=myapp -w

  终端1:
    kubectl apply -f deploy-demo.yaml

  再到终端2上查看滚动更新的效果。
    kubectl get rs -o wide    #可查看到多了一个rs,而且旧版rs的数据都是0.

    kubectl rollout history deployment myapp-deploy    #查看滚动更新的历史

#通过给配置文件打补丁的方式来动态更新:
  kubectl patch deployment myapp-deploy -p ‘"spec":"replicas":5‘
    注: 这样也可以动态修改 myapp-deploy这个Deployment控制器的参数.

  kubectl get pods #可看到Pod个数已经动态创建了。

#动态修改Deployment控制器滚动更新的策略:
  kubectl patch deployment myapp-deploy -p ‘"spec":"strategy":"rollingUpdate":"maxSurge":1,"maxUnavailable":0‘

  kubectl describe deploy myapp-deploy    #查看更新策略

#修改Deployment控制器下Pod的镜像为新版本,然后实现金丝雀更新.
  终端1:
    kubectl get pods -l app=myapp -w

  终端2:
    kubectl set image deployment myapp-deploy myapp=busybox:v3
    kubectl rollout pause deployment myapp-deploy

  终端3:
    kubectl rollout status deployment myapp-deploy

  终端2:
    kubectl rollout resume deployment myapp-deploy

    kubectl get rs -o wide


#回滚到指定版本
  kubectl rollout history deployment myapp-deploy
    deployment.extensions/myapp-deploy
    REVISION CHANGE-CAUSE
      0    <none>
      2    <none>
      3   <none>
      4    <none>
      5    <none>

  kubectl rollout undo deployment myapp-deploy --to-revision=3

  kubectl rollout history deployment myapp-deploy    #可以看到第一版成为第四版.
    deployment.extensions/myapp-deploy
    REVISION CHANGE-CAUSE
      0    <none>
      4    <none>
      5    <none>
      6    <none> #先回到3版本,这里显示为第6版
      7    <none> #接着又尝试回到2版本, 这里显示就是7版本.

 

daemonSet控制器:
  #查看daemonSet控制器的语法
    kubectl explain ds
    kubectl explain ds.spec

vim  ds-demo.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
   name: filebeat-ds
   namespace: default
spec:
  selector:
     matchLabels:
       app:filebeat
       release:stable
  template:
    metadata:
       labels:
         app: filebeat
         release: stable
    spec:
      containers:
      -  name: filebeat
         image: ikubernetes/filebeat:5.6.5-alpine
         env:          #env的用法: kubectl explain  pods.spec.containers.env
         - name: REDIS_HOST
           value: redis.default.svc.cluster.local
         - name: REDIS_LOG_LEVEL
           value: info

  #接着使用apply来应用daemonSet控制器的配置清单创建Pod资源.
  kubectl apply -f ds-demo.yaml

#将多个相关的资源定义在一起的方式,这是工作中常用的方式.
vim  ds-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
     app: redis
     role: logstor
  template:
    metadata:
     labels:
        app: redis
        role: logstor
     spec:
       containers:
       -  name: redis
          image: redis:4.0-alpine
          ports:
          - name: redis
            containerPort:6379
---      #这表示分隔符.
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: filebeat-ds
  namespace: default
spec:
  selector:
    matchLabels:
       app:filebeat
       release:stable
  template:
    metadata:
      labels:
       app: filebeat
       release: stable
    spec:
      containers:
      - name: filebeat
        image: ikubernetes/filebeat:5.6.5-alpine
        env:
        -  name: REDIS_HOST
           value: redis.default.svc.cluster.local
           #fiebeat通过环境变量找到redis的前端service,注意这里指定的名字是redis的前端服务名,而非随意写!
        -  name: REDIS_LOG_LEVEL
           value: info

  #因为此前通过daemonSet创建了两个Pod资源,为了避免冲突,先删除Pod资源.
  kubectl delete -f ds-demo.yaml

#接着再同时创建redis和fliebeat两个Pod资源.
  kubectl apply -f ds-demo.yaml

#接着为redis创建一个服务,来暴露redis的服务端口,以便filebeat可以将日志发送给服务,服务再将日志转发给redis.
  kubectl expose deployment redis --port=6379
  kubectl get svc      #查看创建的service

#验证redis是否可以收到filebeat的日志.
  kubectl get pods      #等redis处于running状态就可以登陆查看了.
  kubectl exec -it redis-5b5d.... -- /bin/sh
  / data # netstat -tnl
  / data # nslookup redis.default.svc.cluster.local    #解析redis的域名.
  / data # redis-cli -h redis.default.svc.cluster.local     #验证能否通过域名直接登陆redis
  / data # keys *          #登陆redis成功后,查看是否有key被创建.

#登陆filebeat查看状态
  kubectl exec -it filebeat-ds-h776m -- /bin/sh
  / # ps uax
  / # cat /etc/filebeat/filebeat.yml    #查看其配置文件中redis的定义.
  / # printenv            #查看环境变量.
  / # kill -1 1            #使用-1信号 让filebeat重读配置文件,这会导致Pod重启,不过没事.

#另外,通过-o wide 可以看到daemonSet定义的Pod一定是一个节点上运行一个Pod.
  kubectl get pods -l app=filebeat -o wide    #daemonSet定义的Pod不运行在主节点上,
                      #主要是因为前面部署时,定义了Master节点是不调度的.
#测试时,发现以下问题:
  # kubectl get node
    NAME STATUS ROLES AGE VERSION
    192.168.111.80 Ready node 2d21h v1.13.5
    192.168.111.81 Ready node 2d21h v1.13.5
    192.168.111.84 Ready,SchedulingDisabled master 2d21h v1.13.5 #主节点配置了,不调度,即污点.
    192.168.111.85 NotReady,SchedulingDisabled master 2d21h v1.13.5

  # kubectl get pod -l app=filebeat -o wide
    NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
    filebeat-ds-8gfdr 1/1 Running 0 13m 10.10.171.2 192.168.111.81 <none> <none>
    filebeat-ds-ml2bk 1/1 Running 1 13m 10.10.240.193 192.168.111.84 <none> <none> #竟然运作在主节点上了!!
    filebeat-ds-zfx57 1/1 Running 0 13m 10.10.97.58 192.168.111.80 <none> <none>
    #从运行状态上看, 符合DaemonSet的特性,每个节点都运行一个. 但为啥它能运行在Master上,原因不明?



#daemonSet也是支持滚动更新的,怎么更新?
  kubectl explain ds.spec.updatestrategy.rollingUpdate    #它只支持先删一个在创建一个, 因为一个节点只能运行一个Pod.

#定义daemonSet控制器filebeat-ds 滚动更新其下管理的Pod的image 升级到filebeat:5.6.6-alpine
  kubectl set image daemonsets filebeat-ds filebeat=ikubernetes/filebeat:5.6.6-alpine

#查看Pod的更新过程
  kubectl get pods -w

DaemonSet的更新策略:
  updateStrategy:
  type <RollingUpdate |OnDelete>    #OnDelete: 即删除时创建。

#动态更新DaemonSet:
  kubectl get ds
  kubectl set image daemonSets filebeat-ds filebeat=ikubernetes/filebeat:5.6.6-alpine

  终端2:
    kubectl get pods -w

  #让pod和宿主机的共享名称空间:
  Pods:
    hostNetwork <boolean> #让Pod共享宿主机的网络名称空间,启动Pod后,可直接访问宿主机的80,来访问容器.
    hostPID <boolean>   #这其实就是Docker网络模型中与宿主机共享网络名称空间的模型.
    hostIPC <boolean>

 

以上是关于K8s控制器原理介绍的主要内容,如果未能解决你的问题,请参考以下文章

kubernetes之K8s核心原理--第一篇

k8s集群网络-总结

基于K8s Jenkins CICD和RBAC角色权限控制

K8S系列深入解析滚动升级

Kubernetes浅析基本概念和原理

k8s网络原理-ipvs