5.k8s资源控制器

一、控制器说明

Pod 的分类

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

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

什么是控制器

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

控制器的类型
- ReplicationController和ReplicaSet
- Deployment : 有状态服务
- DaemonSet：指定运行在那个node上
- StateFulSet ：有状态服务
- Job/CronJob：定制脚本
- Horizontal Pod Autoscaling ：类似阿里云的AS弹性伸缩
ReplicationController和ReplicaSet

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

在新版的Kubernetes中建议使用ReplicaSet来取代RelicationController， ReplicaSet跟ReplicationConller没有本质的不同，只是名字不一样，并且ReplicaSet支持集合式的selector；

Deployment

Deployment为Pod和ReplicaSet提供了一个声明式定义（declarative）方法，用来替代以前的ReplicationController来方便的管理应用，典型的应用场景包括；
- 定义Deployment来创建Pod和ReplicaSet
- 滚动升级和回滚应用
- 扩容和缩容
- 暂停和继续Deployment
命令式编程：它侧重于如何实现程序，就像我们刚接触编程的时候那样，我们需要把程序的实现过程按照逻辑结果一步步写下来

声明式编程：它侧重于定义想要什么，然后告诉计算机/引擎，让他们帮你去实现

声明式编程（Deployment）： apply（优） create

命令式（rs） create （优） apply

DaemonSet

DaemonSet确保全部（或者一些）Node上运行一个Pod的副本，当有Node加入集群时，也会为他们新增一个Pod ，当有Node从集群移除时，这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod

使用DaemonSet的一些典型用法
- 运行集群存储daemon ，例如在每个Node上运行glusterd，ceph
- 在每个Node上运行日志收集daemon，例如fluentd， logstash
- 在每个Node上运行监控daemon，例如Prometheus Node Exporter，collectd，Datadog代理，New Relic 代理，或Ganglia gmond
Job

job负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束

CronJob 在特定时间循环创建Job

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

典型的用法如下所示：
- 在给定的时间点调度Job运行
- 创建周期性运行的Job，例如：数据备份，发送邮件
StatefulSet

StatefulSet作为Controller为Pod提供唯一的标识，它可以保证部署和scale的顺序

StatefulSet是为了解决有状态服务的问题（对应Deployments和ReplicaSets是为无状态服务而设计），其应用场景包括：
- 稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC
- 稳定的网络标识，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现
- 有序部署，有序扩展，即Pod是有顺序的，在部署或扩展的时候要依据定义的顺序依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现
- 有序收缩，有序删除（即从N-1到0）
Horizontal Pod Autoscaling

应用的资源使用率通常都有高峰和低谷的时候，如果削峰填谷，提高集群的整体资源利用率，让service中的Pod个数自动调整呢？这就有赖于Horizontal Pod Autoscaling了，顾名思议，使Pod水平自动缩放。

二、RS、Deployment

2.1 RS与RC与Deployment关联

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

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

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: nginxv1
        image: hub.syuee.com/library/nginx:v1
        env:
        - name: GET_HOSTS_FROM
          value: dns
        ports:
        - containerPort: 80

查看标签kubectl label pod --show-labels

RS与Deployment的关联

Deployment

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

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

部署一个简单的nginx应用

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx 
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: hub.syuee.com/library/syuee-nginx:v2
        ports:
        - containerPort: 80

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

扩容

kubectl scale deployment nginx-deployment --replicas 10

如果集群支持horizontal pod autoscaling的话

kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80

更新镜像也比较简单

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

回滚

kubectl rollout undo deployment/nginx-deployment

2.2 Deployment更新策略

Deployment可以保证在升级时只有一定数量的Pod是down的。默认的。它会确保至少有比期望的Pod数量少一个是up状态（最多一个不可用）

Deployment同时也可以确保只创建出超过期望数量的一定数量的Pod。默认的，它会确保最多比期望的Pod数量多一个的Pod是UP的（最多1个surge）

未来的kubernetes版本中，将从1-1变成25%-25%

kubectl describe deployment

Rollover(多个rollout并行

假如您创建了一个有5个nginx:1.7.9 relica的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都创建完成后才开始改变航道

2.3 回退Deployment

<!--只有Deployment的rollout被处罚就会创建revision。也就是说当且仅当Deployment的Pod template（如.spec.template>
被更改， 例如更新template中的label和容器镜像时 ， 就会创建一个新的revision。 其他的更新， 比如扩容Deployment不会创建
revision-因此我们可以很方便的手动或者自动扩容。 这意味着当您回退到历史revision时 ， 只有Ddeploument中的Pod template 
部分才会回退-->

kubectl set image deployment/nginx-deployment nginx-nginx:1.9.1
kubectl rollout status deployments nginx-deployment
kubectl get pods
kubectl rollout history deployment/nginx-deployment
kubectl rollout undo deployment/nginx-deployment
kubectl rollout undo deployment/nginx-deployment --to-revision=2 ## 可以使用--revision参数指定某个历史版本
kubectl rollout pause deployment/nginx-deployment #暂停deployment的更新

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

kubectl rollout status deploument/nginx
waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment "nginx" successfully rolled out
echo $?

清理Policy

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

三、Daemonset

什么是daemonset

DaemonSet确保全部（或者一些）Node上运行一个Pod的副本，当有Node加入集群时，也会为他们新增一个Pod，当有Node从集群移除时，这些Pod也会被回收，删除DaemonSet将会删除它创建的所有Pod

使用DaemonSet的一些典型用法：

运行在集群存储daemon，例如在每个Node上运行glusterd， ceph
在每个Node上运行日志收集daemon，例如fluentd，logstash

在每个Node上运行监控daemon，例如Prometheus Node Exporter，collectd ，Datadog代理，New Relic代理，或Ganglia gmond

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: daemonset-example
  labels:
    app: daemonset
spec:
  selector:
    matchLabels:
      name: daemonset-example
  template:
    metadata:
      labels:
        name: daemonset-example
    spec:
      containers:
      - name: daemonset-example
        image: hub.syuee.com/library/syuee-nginx:v2

四、Job

Job负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束

特殊说明

spec.template格式同Pod
RestartPolicy仅支持Never或OnFailure
单个Pod时，默认Pod成功运行后Job即结束
.spec.completions标志Job结束需要成功运行的Pod个数，默认为1
.spec.parallelism标志并行运行的Pod的个数，默认为1
.spec.activeDeadlineSeconds标志失败Pod的重试最大时间，超过这个时间不会继续重试

Example

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    metadata:
      name: pi
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl", "-Mbigunm-bpi","-wle","print bpi(1000)"]
      restartPolicy: Never

posted @ 2021-07-25 15:26 白色的番茄阅读(82) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

白色的番茄

你也许无法掌握自己的命运，无法预测未来的危机，但是你至少应该为可能出现的问题做一点准备。