首页 Web开发 Windows程序 编程语言 数据库 移动开发 系统相关 微信 其他好文

Kubernetes：Controller

时间：2021-02-20 11:50:43   收藏：0   阅读：0

简介

Kubernetes集群中的Controller对象可以创建和管理多个Pod，提供副本管理、健康检查、滚动升级和集群级别的自愈能力。例如，如果一个节点故障，Controller就能自动将该节点上的Pod调度到其他健康的节点上。这些Controller运行在Kubernetes集群的主节点上，它们不断控制集群中的资源向期望状态迁移（stauts -> spec）。常用的Controller类型有：

ReplicaSet

决定一个Pod有多少同时运行的副本，并保证这些副本的期望状态与当前状态一致。

配置

一个典型的ReplicaSet配置如下：

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  replicas: 3            # 副本数
  selector: 
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: docker.io/redis:latest

应用场景

由于ReplicaSet并不支持使用命令kubectl roll-update对Pod进行滚动更新，因此若想要以可控的方式更新Pod，建议使用Deployment。

Deployment

Deployment为Pod和ReplicaSet提供声明式的更新能力，用于管理无状态的应用。

配置

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: docker.io/nginx:latest
        ports:
        - containerPort: 80

创建

[root@test-master1 ~]# kubectl create -f test.yml --record
deployment.apps/nginx-deployment created
[root@test-master1 ~]# kubectl get deployment
NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3         3         3            3           9s

查看上线状态

[root@test-master1 ~]# kubectl rollout status deployment.v1.apps/nginx-deployment
deployment "nginx-deployment" successfully rolled out
[root@test-master1 ~]# kubectl get pods --show-labels
NAME                                READY     STATUS    RESTARTS   AGE       LABELS
nginx-deployment-5cbbd6c556-gj4vp   1/1       Running   0          4m        app=nginx,pod-template-hash=1766827112
nginx-deployment-5cbbd6c556-vk4vl   1/1       Running   0          4m        app=nginx,pod-template-hash=1766827112
nginx-deployment-5cbbd6c556-z24z8   1/1       Running   0          4m        app=nginx,pod-template-hash=1766827112
[root@test-master1 ~]# kubectl get rs
NAME                          DESIRED   CURRENT   READY     AGE
nginx-deployment-5cbbd6c556   3         3         3         2d

查看详细信息

[root@test-master1 ~]# kubectl describe rs nginx-deployment-5cbbd6c556
Name:           nginx-deployment-5cbbd6c556
Namespace:      gwr
Selector:       app=nginx,pod-template-hash=1766827112
Labels:         app=nginx
                pod-template-hash=1766827112
...

其中一些参数的含义：

我们可以发现ReplicaSet被命名为Deployment名称加一个数字的格式（nginx-deployment-5cbbd6c556），这个数字是使用Pod标签中pod-template-hash字段作为种子随机生成的。而此标签字段是通过对Pod的template进行哈希处理得到的，可确保Deployment管理的ReplicaSet不重叠。

更新

使用kubectl edit deployment <deployment-name>命令，可直接对Deployment管理的Pod进行更新。当使用kubectl describe deployments命令查看更新信息时，可以在Events下看到更新的过程：

Events:
    Type    Reason             Age   From                   Message
    ----    ------             ----  ----                   -------
    Normal  ScalingReplicaSet  2m    deployment-controller  Scaled up replica set nginx-deployment-2035384211 to 3
    Normal  ScalingReplicaSet  24s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 1
    Normal  ScalingReplicaSet  22s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 2
    Normal  ScalingReplicaSet  22s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 2
    Normal  ScalingReplicaSet  19s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 1
    Normal  ScalingReplicaSet  19s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 3
    Normal  ScalingReplicaSet  14s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 0

回滚

当Deployment不稳定时（例如进入反复崩溃状态），我们需要对其进行回滚操作。默认情况下，Deployment的所有上线记录都保留在系统中，以便可以随时回滚。

StatefulSet

StatefulSet用于管理有状态的应用程序，被其管理的Pod有一个按顺序增长的ID。它与Deployment最大的不同在于，StatefulSet始终将一系列不变的名字分配给Pod，这些Pod从同一个模板创建但并不能相互替换且每个Pod都对应一个特有的持久化存储标识。

应用场景

配置

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # has to match .spec.template.metadata.labels
  serviceName: "nginx"
  replicas: 3 # by default is 1
  template:
    metadata:
      labels:
        app: nginx # has to match .spec.selector.matchLabels
    spec:
      terminationGracePeriodSeconds: 10 # not 0
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "my-storage-class"
      resources:
        requests:
          storage: 1Gi

Pod标识

StatefulSet管理的Pod具备一个唯一标识，该标识由以下几部分组成：

部署和扩缩容

在默认情况下.spec.podManagementPolicy字段值为OrderedReady，它代表依次进行Pod的部署和扩缩容：

若要并行管理Pod，需要设置.spec.podManagementPolicy字段值为Parallel，此时StatefulSet将同时并行地创建或终止其所有的Pod。

更新

StatefulSet的更新策略有两种，它是通过定义spec.updateStrategy.type字段的方式进行选择的。

若Pod的template出错，导致Pod始终不能进入Running和Ready的状态，StatefulSet将停止滚动更新并一直等待（OrderedReady）。在修复template以后，StatefulSet将继续等待出错的Pod进入就绪状态，而该状态将永远无法出现。因此还必须删除所有已经尝试使用错误template的Pod，随后StatefulSet才会使用修复后的template重建Pod。

DaemonSet

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

使用场景

Spec配置

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      tolerations:
      # this toleration is to have the daemonset runnable on master nodes
      # remove it if your masters can‘t run pods
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers

调度策略

DaemonSet Controller将会向DaemonSet管理的的Pod添加spec.nodeAffinity字段，并进一步由Kubernetes Scheduler将Pod绑定到目标节点。

nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
    nodeSelectorTerms:
    - matchFields:
      - key: metadata.name
        operator: In
        values:
        - target-host-name

此外，容忍度（toleration）node.kubernetes.io/unschedulable:NoSchedule将被系统自动添加到DaemonSet的Pod中。由此，默认调度器在调度DaemonSet的Pod时可以忽略节点的unschedulable属性。

通信

与DaemonSet中的Pod进行通信的几种可能模式如下：

Jobs

Job会创建一个或者多个Pods，并确保指定数量的Pod可以执行到Succeeded状态。随着Pods成功结束，Job跟踪记录成功完成的Pods个数。当数量达到指定的成功个数阈值时，Job结束。删除Job的操作会清除其创建的全部Pod。

配置

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4 # Job 最大的重试次数

Endpoint Controller

负责维护Endpoint与其对应的Service的关系。Endpoint Controller会周期性地进行检查，确保它们始终运行在用户期望的状态。

GC Controller

在Kubernetes中，每一个从属对象都有一个metadata.ownerReferences字段，标识其拥有者是哪一个对象。GC Controller会删除那些曾经有owner，后来又不再有owner的对象。

参考文献

https://kubernetes.io/docs/home/
https://kuboard.cn/learning/

评论（0）
© 2014 mamicode.com 版权所有 京ICP备13008772号-2  联系我们:gaon5@hotmail.com
迷上了代码！