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:
     selector:
         matchLabels:
             app:myapp
             release: canary
     template:
            metadata:
                labels:
                     app:myapp
                     release: canary
            spec:
                 cantainers:
                  -   name: myapp
                       image: busybox
                       ports:
                       -   name:http
                           containerPort: 

#编写以上清单文件后，就可以执行：
　　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.-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:
  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:
---      #这表示分隔符.
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.-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>