K8S的Pod控制器控制器|

识字粗堪供赋役，不须辛苦慕公卿。这篇文章主要讲述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.yamlkubectl 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: 3by 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配置一个唯一的名称。
【K8S的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动态创建的PVHeadless 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、DaemonSetDaemonSet确保全部（或者一些）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: 80kubectl apply -f ds.yaml

4、JobJob分为普通任务（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