什么是控制器

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

控制器的类型

ReplicationController和ReplicaSet

ReplicationController(RC)用来确保容器利用的正本数始终维持在用户定义的正本数，即如果有容器异样退出，会主动创立新的Pod来代替，而如果异样多进去的容器也会主动回收。

在新版本的Kubernetes中倡议应用ReplicaSet来取代ReplicationController，ReplicaSet跟ReplicationController没有实质的区别，只是名字不一样，并且ReplicaSet反对汇合式的selector（标签）。

apiVersion: extensions/v1beta1kind: ReplicaSetmetadata:  name: frontendspec:  replicas: 3  selector:    natchLatels:      tier: frontend  template:    metadata:      latels:        tier: frontend    sepc:      containsers:      - name: myapp        image: myapp:v1        env:        - name: GET_HOST_FROM          values: dns        ports:        - containerPort: 80

Deployment

Deployment为Pod和ReplicaSet提供了一个申明式定义（declarative)办法，用来代替以前的ReplicationController类不便的治理利用，典型的利用场景包含：

  • 定义Deployment来创立Pod和ReplicaSet
  • 滚动降级和回滚利用
  • 扩容和缩容
  • 暂停和持续Deployment
apiVersion: extensions/v1beta1kind:Deploymentmetadata:  name: nginx-deploymentspec:  replicas: 3  template:    metadata:      labels:        app: nginx    spec:      containers:      - name: nginx        image: myapp:v1        ports:        - containerPort: 80

扩容

kubectl scale deployment nginx-deployment --replicats 10

如果集群反对HPA的话，还能够为Deployment设置主动扩大

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

更新镜像也比较简单

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

回滚

kubectl rollout undo deployment/nginx-deploymentkubectl rollout status deployments nginx-deployment #查看回滚状态kubectl rollout history deployment/nginx-deployment #查看回滚历史kubectl rollout pause deployment/nginx-deployment #暂停deployment的更新

DaemonSet

Daemon确保全副或者一些Node上运行一个Pod的正本，当有Node退出集群时，也会为他们新增一个Pod，当有Node从集群移除时，这些Pod也会被回收，删除DaemonSet将会删除它创立的所有Pod

应用DaemonSet的一些典型用法：

  • 运行集群存储daemon，如glusterd、ceph
  • 在每个Node上运行日志手机daemon，如fluentd、logstash
  • 在每个Node上运行监控daemon，如prometheus Node Exporter、colletcd、Datadog代理、New Relic代理，或Ganglia gmond
apiVersion: apps/v1kind: DaemonSetmetadata:  name: daemonset-example #与上面的selector.matchLabels中的name必须保持一致，不然会始终重启  labels:    app: daemonsetspec:  selector:    matchLabels:      name: daemonset-example  template:    metadata:      labels:        name: daemonset-example    spec:      containers:      - name: daemonset-example        image: myapp:v1

StateFulSet

StateFulSet作为Controller为Pod提供惟一的标识，它能够保障部署和scale的程序

StateFulSet是为了解决有状态服务的问题，对应Deployment和ReplicaSet是为无状态服务而设计的，器利用场景包含：

  • 稳固的长久化存储，即Pod从新调度后还能拜访到雷同的长久化数据，基于PVC来实现
  • 稳固的网络标识，即Pod从新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现
  • 有序部署，有序扩大，即Pod是有程序的，在部署或者扩大的时候要根据定义的程序顺次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Runing和Ready状态），基于init containers来实现
  • 有序膨胀，有序删除（即从N-1到0）

Job/CronJob

Job负责批处理工作，即仅执行一次工作，它保障批处理工作的一个或者多个Pod胜利完结

CronJob治理基于工夫的Job，即：

  • 在给定工夫只运行一次
  • 周期性地在给定工夫点运行

典型利用场景如数据库备份，发送邮件等

Job

apiVersion: batch/v1kind: Jobmetadata:  name: pispec:  templata:    metadata:      name: pi    spec:      containers:      - name: pi        image: perl        command: ["perl","-Mbignum=bpi","-wle","print bpi(2000)"]      restartPolicy: Never

CronJob

apiVersion: batch/v1beta1kind: CronJobmetadata:  name: hellospec:  schedule: "*/1 * * * *" #必须填写的字段  completions: 1 #标记Job完结须要胜利运行的Pod个数，默认为1  parallelism: 1 #标记并行运行的Pod个数，默认为1  activeDeadlineSeconds: 5 #标记失败Pod的重试最大工夫，超过这个工夫不会持续重试  startingDeadlinSeconds: 5 #启动Job的期限（秒级别）  concurrencyPolicy: Allow #并发策略，可选Allow（默认）容许并发运行Job、Forbid禁止编发运行、Replace替换  jobTemplate: #必须填写的字段    spec:      template:        spec:          containers:          - name: hello            image: busybox            args:            - /bin/sh            - -c            - date: echo Hello from the Kubernetes cluster          restartPolicy: OnFailure

Horizontal Pod Autoscaling

利用的资源使用率通常都有顶峰和低谷的时候，如何削峰填谷，进步集群的整体资源利用率，让service中的Pod个数主动调整呢？这就要依赖于Horizontal Pod Autoscaling了，即Pod的程度主动缩放