Kubernetes控制器

TOC

了解控制器

kubernetes控制器会监听资源的创建、更新、删除事件，并触发Reconcile调用函数作为响应，Reconcile是一个使用资源对象的命名空间和资源对象名称来调用的函数，使得资源对象得实际状态与资源清单中定义的状态保持一致。

ReplicaSet

可以创建多副本的控制器，用于高可用高并发场景。
资源清单编写如下：

# nginx-rs.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-rs
  namespace: default
spec:
  replicas: 3  #期望的Pod副本数量，默认值为1
  selector:  #Label Selector，必须匹配Pod模板中的标签
    matchLabels:
      app: nginx
  template:  # Pod 模板
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.23.1
        ports:
        - containerPort: 80

ReplicaSet控制器删除了Pod并不会重新创建一个新的Pod，虽然可以高并发作用，但是没有自动恢复的能力，不能高可用，这是ReplicaSet控制器的弊端。

Deployment

Deployment控制器其实就是在ReplicaSet控制器之上的控制器，在平时应用中一般我们不会直接去使用ReplicaSet控制器，而是使用Deployment控制去操控ReplicaSet控制器，Deployment控制器在它的基础上新增了Pod的滚动更新功能。
资源清单编写如下：

#nginx-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  minReadySeconds: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.23.1
        ports:
        - containerPort: 80

可以看出比起ReplicaSet配置清单中多了如下选项：

  minReadySeconds: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%

minReadySeconds：表示Kubernetes在等待设置的时间后才进行升级，如果没有设置该值，Kubernetes 会假设该容器启动起来后就提供服务了
type: RollingUpdate：其中type类型分为RollingUpdate和Recreate，RollingUpdate为滚动更新，Recreate则是执行全部重新创建
maxSurge：升级过程中最多可以比原先设置多出的Pod数量，可以是数字也可以是百分比
maxUnavailable：升级过程中最多有多少个 Pod 处于无法提供服务的状态

DarmonSet

DaemonSet用于在每个 Kubernetes 节点中将守护进程的副本作为后台进程运行，说白了就是在每个节点部署一个 Pod副本
资源清单编写如下：

# nginx-ds.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nginx-ds
  namespace: default
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.23.1
        name: nginx
        ports:
        - name: http
          containerPort: 80

应用场景大概如下：

  • 节点监控守护进程，如 Prometheus 监控集群，可以在每个节点上运行一个 node-exporter进程来收集监控节点的信息；
  • 日志收集守护程序，如fluentd或logstash，在每个节点上运行以收集容器的日志
  • 节点网络插件，比如flannel、calico，在每个节点上运行为 Pod 提供网络服务。

注意：也可以结合污点来实现某些需求和部署调整

Job和Cronjob

Job控制器：
一般用来创建一个任务，我们定义一个 Job 来执行一个倒计时的任务
资源清单编写如下：

# job-demo.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: job-demo
spec:
  parallelism: 2
  completions: 8
  template:
    spec:
      restartPolicy: OnFailure #执行失败则重启，要不就是死循环，job只适合执行一次
      containers:
      - name: counter
        image: busybox
        command:
        - "bin/sh"
        - "-c"
        - "for i in 9 8 7 6 5 4 3 2 1; do echo $i; done"

parallelism：定义了一个Job在任意时间最多可以有多少个 Pod 同时运行
completions：定义Job至少要完成任务的Pod数量
restartPolicy：重启策略一般这里会用Never(无论成功与否都不重启)和OnFailure(运行失败则重启)
Cronjob控制器：
就是在Job的基础上加上了时间调度，我们可以在给定的时间点运行一个任务，也可以周期性地在给定时间点运行
资源清单编写如下：

# cronjob-demo.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: cronjob-demo
spec:
  schedule: "*/1 * * * *"
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
          - name: hello
            image: busybox
            args:
            - "bin/sh"
            - "-c"
            - "for i in 9 8 7 6 5 4 3 2 1; do echo $i; done"

定时格式的编写和linux中的crontab差不多
successfulJobsHistoryLimit：指定可以保留多少成功完成的job
failedJobsHistoryLimit：指定可以保留多少失败的job

StatefulSet

StatefulSet用于部署有状态服务的控制器
Headless Service：
对于DNS的两种情况：

  • 1.第一种就是普通的 Service，我们访问"mysvc.mynamespace.svc.cluster.local"的时候是通过集群中的 DNS 服务解析到的 mysvc 这个 Service 的 cluster IP 的。
  • 2.第二种情况就是 Headless Service，对于这种情况，我们访问"mysvc.mynamespace.svc.cluster.local"的时候是直接解析到的 mysvc 代理的某一个具体的 Pod 的 IP 地址，中间少了 cluster IP 的转发，这就是二者的最大区别，Headless Service 不需要分配一个 VIP，而是可以直接以 DNS 的记录方式解析到后面的 Pod 的 IP 地址。

资源清单编写如下：

apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: default
  labels:
    app: nginx
spec:
  ports:
  - name: http
    port: 80
  clusterIP: None
  selector:
    app: nginx

注意：定义上和普通的 Service 几乎一致, 只是他的'clusterIP=None'，所以，这个 Service 被创建后并不会被分配一个 cluster IP，而是会以 DNS 记录的方式暴露出它所代理的 Pod
1.创建pv

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv001
spec:
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteOnce
  hostPath:
    path: /tmp/pv001
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv002
spec:
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteOnce
  hostPath:
    path: /tmp/pv002

2.编写StatefulSet 资源清单

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
  namespace: default
spec:
  serviceName: "nginx"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.23.1
        ports:
        - name: web
          containerPort: 80
        volumeMounts:
        - name: pv-test
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: pv-test
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

高级控制器HPA

HPA 通过监控分析一些控制器控制的所有 Pod 的负载变化情况来确定是否需要调整 Pod 的副本数量。

补充说明：HPA是在Deployment控制器之上的控制器，主要通过控制Deployment来管理控制Pod。

资源清单编写如下：
1.先创建一个deployment限制cpu或者memory

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  minReadySeconds: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.23.1
        name: nginx
        resources:
          limits:
            cpu: 2000m
            memory: 4Gi
          requests:
            cpu: 2000m
            memory: 4Gi
        ports:
        - name: http
          containerPort: 80

2.编写HPA资源清单：

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-deploy-hpa
  namespace: default
spec:
  maxReplicas: 3
  minReplicas: 5
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deploy
  metrics:
  - type: Resource
    resource:
      name: cpu
      targetAverageUtilization: 30