K8S的Pod控制器

Posted 2022-04-12 Richard_Chiang

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了K8S的Pod控制器相关的知识，希望对你有一定的参考价值。

K8S的Pod控制器

Pod控制器有多种类型:

1、ReplicaSet：代用户创建指定数量的pod副本数量，确保pod副本数量符合预期状态，并且支持滚动式自动扩容和缩容功能。

ReplicaSet主要三个组件组成：

用户期望的pod副本数量
标签选择器，判断哪个pod归自己管理
当现存的pod数量不足，会根据pod资源模板进行新建

帮助用户管理无状态的pod资源，精确反应用户定义的目标数量，但是RelicaSet不是直接使用的控制器，而是使用Deployment。

2、Deployment：工作在ReplicaSet之上，用于管理无状态应用，目前来说最好的控制器。支持滚动更新和回滚功能，还提供声明式配置。Replicaset与Deployment这两个资源对象逐步替换之前RC的作用。

3、DaemonSet：用于确保集群中的每一个节点只运行特定的pod副本，通常用于实现系统级后台任务。比如ETK服务特性：服务是无状态的
服务必须是守护进程

4、StatefulSet：管理有状态应用

5、Job：只要完成就立即退出，不需要重启或重建

6、cronjob：周期性任务控制，不需要持续后台运行

httpd nginx 无状态应用
mysql es    有状态应用

Deployment  部署无状态应用 ReplicaSet维护pod副本期望数量   创建时是并行创建，升级时是先创建一部分再删除一部分
StatefulSet 部署有状态应用   创建和删除时是有序创建的（串行的）
            升级时是串行执行的，会先删除旧Pod创建新Pod，
            先从最大到最小序号开始更新，在下一批pod更新完毕（进入running和ready状态）才会更新
5个副本创建时nginx-0 nginx-1 ... nginx-4 删除时 nginx-4 nginx-3 ... nginx-0
DaemonSet   在所有node节点上部署同一种类型pod
Job         部署一次性任务的pod，完成就立刻推出不会重启重建
Cronjob     周期性部署任务的pod，完成就立即退出不会重启重建

  strategy:
    rollingUpdate:
      maxSurge: 25%         升级时会先启动的新pod数量不会超过控制器期望pod数量的25%，也可以设置成一个绝对值    
      maxUnavailable: 25%   升级时会在新pod创建启动好后要销毁的旧pod数量不会超过控制器期望pod数量的25%，也可以设置成一个绝对值

Pod与控制器之间的关系

controllers：在集群上管理和运行容器的 pod对象，pod通过label-selector相关联。
Pod通过控制器实现应用的运维，如伸缩，升级等。

Pod控制器种类以及yaml格式

1、 Deployment

部署无状态应用
管理Pod和Replicaset
具有上线部署、副本设定、滚动升级、回滚等功能
提供声明式更新，例如只更新一个新的image
应用场景：web服务

示例：

vim nginx-deployment.yaml
apiversion: apps/v1
kind: Deployment
metadata:
  nane: nginx-deployiment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata :
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4
        ports:
        - containerPort: 80
或
kubectl create -f nginx-deploynent --image=nginx:1.14 --port=80 --replicas=3 --dry-run=client -o yaml > nginx-deoloyment.yaml
vim nginx-deployment.yaml

kubectl create -f nginx-deploynent.yaml
kubectl get pods,deploy,rs

2、SatefulSet

部署有状态应用

稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
稳定的网络标志，即pod重新调度后其PordName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现
有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running利Ready状态），基于init containers来实现有序收缩，有序删除（即从N-1到0）

常见的应用场景：数据库
https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

apiversion: v1
kind: service
metadata:
  name: nginx
  labels :
    app: nginx
spec:
  ports:
  - port: 80
    nane: 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
    containers:
    - name: nginx
      image: kBs.gcr.io/ nginx-slim:0.8
      ports:
      - containerPort: 80
        name: web
        volumeMounts:
        - name: www
          mountPath: fusr/ share/ nginx/ html
volumeclaimTemplates :
- metadata :
    name: www
  spec:
    accessModes: ["ReadWriteOnce"]
    storageclassName: "my-storage-class"
    resources:
      requests:
        storage: 1Gi

从上面的应用场景可以发现，StatefulSet由以下几个部分组成：

Headless servicer（无头服务）：用于为Pod资源标识符生成可解析的DNS记录。
volumeClaimTemplates（存储卷申请模板）：基于静态或动态PV供给方式为Pod资源提供专有的固定存储。
StatefulSet：用于管控Pod资源。

为什么要有Headless？

在deployment中，每一个pod是没有名称，是随机字符串，是无序的。而statefulset中是要求有序的，每一个pod的名称必须是固定的。当节点挂了，重建之后的标识符是不变的，每一个节点的节点名称是不能改变的。pod名称是作为pod识别的唯一标识符，必须保证其标识符的稳定并且唯一。
为了实现标识符的稳定，这时候就需要一个headless service解析直达到pod，还需要给pod配置一个唯一的名称。

Service类型

ClusterIP
NodePort
Headless Service    解析PodName成podIP直达pod的效果，也就是客户端可以通过PodName访问pod
coreDNS             在K8S集群中字段关联service资源的名称和service clusterIP，从而达到服务被集群自动发现的目的

为什么要有volumeclainTemplate？

大部分有状态副本集都会用到持久存储，比如分布式系统来说，由于数据是不一样的，每个节点都需要自己专用的存储节点。而在deploymentpod模板中创建的存储卷是一个共享的存储卷，多个pod使用同一个存储卷，而statefulset定义中的每一个pod都不能使用同一个存储卷，由此基于pod棋板创建pod是不适应的，这就需要引入voluneClainTemplate，当在使用statefulset创建pod时，会自动生成一个PVC，从而请求绑定一个PV，从而有自己专用的存储卷。

服务发现：就是应用服务之间相互定位的过程。
应用场景：

动态性强：Pod会飘到别的node节点
更新发布频繁：互联网思维小步快跑，先实现再优化，老板永远是先上线再慢慢优化，先把idea变成产品挣到钱然后再慢慢一点一点优化
支持自动伸缩：一来大促，肯定是要扩容多个副本

K8S里服务发现的方式---DNS，使K8S集群能够自动关联service资源的"名称"和"CLUSTER-IP"，从而达到服务被集群自动发现的目的。

实现K8S里DNS功能的插件：

skyDNS：Kubernetes 1.3之前的版本
kubeDNS：Kubernetes 1.3至Kubernetes 1.11
coreDNS：Kubernetes 1.11开始至今

安装coreDNS，仅二进制部署环境需要安装coreDNS

方法一：

下载链接：https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/coredns/coredns.yaml.base

要创建一个StatefulSet资源前提条件要有

Headless Service
静态PV StorageClass动态创建的PV

Headless Service 使用podname解析podIP
                 解析的域名格式是pod_name.service_name[.namespece_name.svc.cluster.local]

总结

无状态：

deployment 认为所有的pod都是一样的
不用考虑顺序的要求
不用考虑在哪个node节点上运行4)可以随意扩容和缩容

有状态

实例之间有差别，每个实例都有自己的独特性，元数据不同，例如etcd，zookeeper
实例之间不对等的关系，以及依靠外部存储的应用。

常规service和无头服务区别

service：一组Pod访问策略，提供cluster-IP群集之间通讯，还提供负载均衡和服务发现。

Headless service：无头服务，不需要cluster-IP，直接绑定具体的Pod的IP

3、DaemonSet

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

使用DaemonSet 的一些典型用法：

运行集群存储daemon，例如在每个Node上运行glusterd、ceph。
在每个Node上运行日志收集daemon，例如fluentd、logstash。
在每个Node上：运行监控demon，例如Prometheus Node Exporter、collectd、Datadog代理、New Relic代理，或Ganglia gmond。

应用场景：Agent

官方案例（监控）
https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/

示例：

vim ds.yaml
apiversion: apps /v1
kind: DaemonSet
metadata:
  name: nginx-daemonSet
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata :
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
      image: nginx:1.15.4
      ports:
      - containerPort: 80

kubectl apply -f ds.yaml

4、Job

Job分为普通任务（Job）和定时任务（CronJob）
常用于运行那些仅需要执行一次的任务

应用场景：数据库迁移、批处理脚木、kube-bench扫描、离线数据处理，视频解码等业务
https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/

示例：

vim job.yaml
apiversion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl
        cormmand: ["perl","-Mbignum=bpi","-wle","print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4
#参数解释
.spec.template.spec.restartPolicy该属性拥有三个候选值：OnFailure，Never和Always。默认值为Always。它主要用于描述Pod内容器的重启策略。在Job中只能将此属性设置为onFailure或Never，否则Job将不间断运行。
.spec.backofflimit用于设置job失败后进行重试的次数，默认值为6。默认情况下，除非Pod共败或容器异常退出，Job任务将不间斯的重试，此时Job遵循.spec.backoffLimit上述说明。一旦.spec.backoffLimit达到，作业将被标记为失败。

#在所有node节点下载perl镜像，因为镜像比较大，所以建议提前下载好
docker pull perl
kubectl apply -f job.yaml
kubectl get pods

5、CronJob

周期性任务，像Linux的Crontab一样。
周期性任务
应用场景：通知，备份
https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/

示例：

#分钟打印hello
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

#它可用参数的配置
spec:
  concurrencyPolicy: Allow          #要保留的失败的完成作业数（默认为1）
  schedule: */1 * * * *           #作业时间表。在此示例中，作业将每分钟运行一次
  startingDeadlineSeconds: 15       #pod必须在规定时间后的15秒内开始执行，若超过该时间未执行，则任务将不运行，且标记失败
  successfulJobsHistoryLimit: 3     #要保留的成功完成的作业数（默认为3）
  terminationGracePeriodSeconds: 30 #job存活时间 默认不设置为永久
  jobTemplate:                      #作业模板。这类似于工作示例

kubectl create -f cronjob.yaml 
kubectl get cronjob
kubectl get pods
kubectl logs hello-1621587180-mffj6
Fri May 21 09:03:14 UTC 2021
Hello from the Kubernetes cluster
#如果报错：Error from server (Forbidden): Forbidden (user=system:anonymous, verb=get, resource=nodes, subresource=proxy) ( pods/log hello-1621587780-c7v54)
#解决办法：绑定一个cluster-admin的权限
kubectl create clusterrolebinding system:anonymous --clusterrole=cluster-admin --user=system:anonymous

以上是关于K8S的Pod控制器的主要内容，如果未能解决你的问题，请参考以下文章

k8s pod控制器使用以及详解

K8S基础

k8s pod控制器详解