Kubernetes Pod控制器实例演示

Pod控制器

控制器概念
k8s中内建了很多controller（控制器），这些相当于一个状态机，用来控制Pod的具体状态和行为

生命周期不同分类

• 自主式Pod：Pod退出了，此类型的Pod不会被创建

• 控制器管理的Pod：在控制器的生命周期里，始终要维持Pod的副本数目

控制器类型

• ReplicationController和ReplicaSet
• Deployment
• DaemonSet
• StateFulSet
• Job/ConJob
• Horizontal Pod Autoscaling

❤详情看往期文章
Pod控制类型

控制器实例

1、RS 与 RC 与 Deployment 关联RC （ReplicationController ）

主要的作用就是用来确保容器应用的副本数始终保持在用户定义的副本数。即如果有容器异常退出，会自动创建新的Pod来替代；而如果异常多出来的容器也会自动回收

Kubernetes 官方建议使用 RS（ReplicaSet ）替代 RC （ReplicationController ）进行部署，RS 跟 RC 没有本质的不同，只是名字不一样，并且 RS 支持集合式的 selector

查看RS完整模板信息：kubectl explain rs
vim rs.yaml

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
  name: frontend
spec: 
  replicas: 3  # 3个副本
  selector: # 选择标签
    matchLabels: # 匹配标签，匹配上就是rs的
      tier: frontend  # keys:values
  template: # 模板，后面是pod属性
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: myapp
        image: hub.atguigu.com/library/myapp:v1
        env: # 注入环境变量
        - name: GET_HOSTS_FROM
          value: dns
        ports:
        - containerPort: 80

kubectl delete pod --all
kubectl create -f rs.yaml
kubectl get pod
kubectl get pod --show-labels
kubectl label pod frontend-2q74g tier=frontend1 --overwrite=True
kubectl get pod --show-labels
会发现出现四个，第四个是之前的3，因为规定了rs副本数有3个，而且标签匹配只能匹配frontend，因为只有两个，还要再新创建一个rvckj，满足期望值3

然后删除的rs，发现有一个不归rs管理
kubectl delete rs --all
kubectl get pod --show-labels

 

2、RS 与 Deployment 的关联

Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义(declarative)方法，用来替代以前的ReplicationController 来方便的管理应用。典型的应用场景包括：

• 定义Deployment来创建Pod和ReplicaSet
• 滚动升级和回滚
• 应用扩容和缩容
• 暂停和继续Deployment

★部署一个简单的Nginx应用

1、创建
vim deployment.yaml
kubectl apply -f deployment.yaml --record

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: myapp
        image: hub.atguigu.com/library/myapp:v1
        ports:
        - containerPort: 80

kubectl create -f https://kubernetes.io/docs/user-guide/nginx-deployment.yaml --record## --record参数可以记录命令，我们可以很方便的查看每次 revision 的变化

deployment的创建会创建出对应的rs，通过7bb4cb8f64，还有标签确定的。

2、扩容
kubectl scale deployment nginx-deployment --replicas 10
无状态的扩容缩

3、如果集群支持 horizontal pod autoscaling 的话，还可以为Deployment设置自动扩展
kubectl autoscale deployment nginx-deployment --min=10–max=15–cpu-percent=80

4、更新镜像也比较简单
kubectl set image deployment/nginx-deployment myapp(容器名)=wangyanglinux/myapp:v2
kubectl get rs
镜像的修改会触发rs的创建，就像之前所说的。更新和回滚操作会处于pod交替的过程

5、回滚
kubectl rollout undo deployment/nginx-deployment
更新和回滚操作会处于pod交替的过程

3、更新 Deployment

Deployment更新策略

• Deployment 可以保证在升级时只有一定数量的 Pod 是 down 的。默认的，它会确保至少有比期望的Pod数量少一个是up状态（最多一个不可用）
• Deployment 同时也可以确保只创建出超过期望数量的一定数量的 Pod。默认的，它会确保最多比期望的Pod数量多一个的 Pod 是 up 的（最多1个 surge ）
• 未来的 Kuberentes 版本中，将从1-1变成25%-25%

kubectl descirbe deployment

Rollover（多个rollout并行）

假如您创建了一个有5个niginx:1.7.9 replica的 Deployment，但是当还只有3个nginx:1.7.9的 replica 创建出来的时候您就开始更新含有5个nginx:1.9.1 replica 的 Deployment。在这种情况下，Deployment 会立即杀掉已创建的3个nginx:1.7.9的 Pod，并开始创建nginx:1.9.1的 Pod。它不会等到所有的5个nginx:1.7.9的Pod 都创建完成后才开始改变航道

回退Deployment

kubectl set image deployment/nginx-deployment nginx=nginx:1.91

查看当前的回滚状态：kubectl rollout status deployments nginx-deployment

查看历史版本：kubectl rollout history deployment/nginx-deployment

如果创建的时候加了record，那么CHANGE-CAUSE才会记录

kubectl rollout undo deployment/nginx-deployment

可以使用 --revision参数指定某个历史版本：kubectl rollout undo deployment/nginx-deployment --to-revision=2

暂停 deployment 的更新：kubectl rollout pause deployment/nginx-deployment   

您可以用kubectl rollout status命令查看 Deployment 是否完成。如果 rollout 成功完成，kubectl rolloutstatus将返回一个0值的 Exit Code

kubectl rollout status deployments nginx-deployment
echo $?

清理 Policy

您可以通过设置.spec.revisonHistoryLimit项来指定 deployment 最多保留多少 revision 历史记录。默认的会保留所有的 revision；如果将该项设置为0，Deployment 就不允许回退了

4、DaemonSet

daemonset.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: daemonset-example  # 对应1 与对应2 要一致
  labels:
    app: daemonset
spec:
  selector:
    matchLabels:
      name: daemonset-example  # 对应2  pod
  template:
    metadata:
      labels:
        name: daemonset-example
    spec:
      containers:
      - name: daemonset-example
        image: wangyanglinux/myapp:v1
        # 模板可以复杂点，init C,start stop,readiness等

kubectl create -f daemonset.yaml
kubectl get pod -o wide
主节点默认不会创建

kubectl delete pod daemonset-example-t5fzc

 

5、Job和CronJob

vim job.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    metadata:
      name: pi
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]  # 圆周率计算小数点
      restartPolicy: Never

kubectl create -f job.yaml
kubectl describe pod pi-9vt9h 查看执行状态

kubectl get job #看当前的任务

验证结果，得出圆周率的2000位，正确

 

6、CronJob

Deployment通过创建rs进行pod管理，而
CronJob通过创建pod进行管理，管理基于时间的 Job，即：

• 在给定时间点只运行一次
• 周期性地在给定时间点运行
• 使用前提条件：当前使用的 Kubernetes 集群，版本 >= 1.8（对 CronJob）。对于先前版本的集群，版本 <1.8，启动 API Server时，通过传递选项–runtime-config=batch/v2alpha1=true可以开启 batch/v2alpha1API

典型的用法如下所示：

• 在给定的时间点调度 Job 运行
• 创建周期性运行的 Job，例如：数据库备份、发送邮件

vim cronjob.yaml

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"  # 调度的时间
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date;echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

kubectl apply -f cronjob.yaml
kubectl get cronjob
kubectl get jobs
然后查询日志进行验证。

[root@k8s-master01 ~]# vim cronjob.yaml
[root@k8s-master01 ~]# kubectl apply -f cronjob.yaml 
cronjob.batch/hello created
[root@k8s-master01 ~]# kubectl get cronjob
NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
hello   */1 * * * *   False     0        <none>          15s
[root@k8s-master01 ~]# kubectl get job
NAME               COMPLETIONS   DURATION   AGE
hello-1601467260   1/1           9s         90s
hello-1601467320   1/1           10s        30s
[root@k8s-master01 ~]# kubectl get pod
NAME                     READY   STATUS      RESTARTS   AGE
hello-1601467260-466fs   0/1     Completed   0          108s
hello-1601467320-c5b5b   0/1     Completed   0          48s
[root@k8s-master01 ~]# kubectl log hello-1601467260-466fs
log is DEPRECATED and will be removed in a future version. Use logs instead.
Wed Sep 30 12:01:13 UTC 2020
Hello from the Kubernetes cluster
[root@k8s-master01 ~]# kubectl log hello-1601467320-c5b5b
log is DEPRECATED and will be removed in a future version. Use logs instead.
Wed Sep 30 12:02:14 UTC 2020
[root@k8s-master01 ~]# kubectl delete cronjob --all
cronjob.batch "hello" deleted

CrondJob本身的一些限制：创建Job操作应该是幂等的
CrondJob的运行成功不好判断，它只会负责去创建Job，但Job的成功可以被判断

StateFullSet和HPA，暂时的知识还不足以支撑，以后再见