一，什么是pod控制器

Pod 控制器（工作负载workload）是 Kubernetes 中用于管理 Pod 的中间层资源，其主要职责是确保 Pod 的运行状态符合用户的期望。在 Pod 出现异常时，控制器会根据设定的策略尝试恢复 Pod 的运行(会先重启，当重启策略无效的时候，重新创建新的pod资源，再删除旧的不好用的pod)。

二，pod控制器类型（重点）

关键点在什么时候使用什么控制器类型

1.ReplicaSet

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

ReplicaSet主要三个组件：

（1）用户期望的pod副本数量

（2）标签选择器，判断哪个pod归自己管理

（3）当现存的pod数量不足，会根据pod资源模板进行新建

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

2.Deployment

工作在ReplicaSet之上，用于管理无状态应用，目前来说最好的控制器。支持滚动更新和回滚功能，能提供声明式配置。

ReplicaSet 与Deployment 这两个资源对象逐步替换之前RC的作用。

3.DaemonSet

用于确保集群中的每一个节点只运行特定的pod副本，通常用于实现系统级后台任务。比如ELK服务

特性：服务是无状态的

服务必须是守护进程

4.StatefulSet

管理有状态应用，用在 MySQL、Redis、Cassandra 等

5.Job

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

6.Cronjob

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

三，pod与控制器的关系

controllers：在集群上管理和运行容器的 pod 对象， pod 通过 label-selector 相关联。

Pod 通过控制器实现应用的运维，如伸缩，升级等。

1.Deployment

部署无状态应用

管理Pod和ReplicaSet

具有上线部署、副本设定、滚动升级、回滚等功能

提供声明式更新，例如只更新一个新的image

应用场景：web服务

vim nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx	
spec:replicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.15.4ports:- containerPort: 80kubectl create -f nginx-deployment.yamlkubectl get pods,deploy,rs查看控制器配置
kubectl edit deployment/nginx-deployment
apiVersion: apps/v1
kind: Deployment
metadata:annotations:deployment.kubernetes.io/revision: "1"creationTimestamp: "2021-04-19T08:13:50Z"generation: 1labels:app: nginx					#Deployment资源的标签name: nginx-deploymentnamespace: defaultresourceVersion: "167208"selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/nginx-deploymentuid: d9d3fef9-20d2-4196-95fb-0e21e65af24a
spec:progressDeadlineSeconds: 600replicas: 3					#期望的pod数量，默认是1revisionHistoryLimit: 10selector:matchLabels:app: nginxstrategy:rollingUpdate:maxSurge: 25%				#升级过程中会先启动的新Pod的数量不超过期望的Pod数量的25%，也可以是一个绝对值maxUnavailable: 25%		#升级过程中在新的Pod启动好后销毁的旧Pod的数量不超过期望的Pod数量的25%，也可以是一个绝对值type: RollingUpdate			#滚动升级template:metadata:creationTimestamp: nulllabels:app: nginx				#Pod副本关联的标签spec:containers:- image: nginx:1.15.4				#镜像名称imagePullPolicy: IfNotPresent	#镜像拉取策略name: nginxports:- containerPort: 80				#容器暴露的监听端口protocol: TCPresources: {}terminationMessagePath: /dev/termination-logterminationMessagePolicy: FilednsPolicy: ClusterFirstrestartPolicy: Always				#容器重启策略schedulerName: default-schedulersecurityContext: {}terminationGracePeriodSeconds: 30
......查看历史版本
kubectl rollout history deployment/nginx-deployment
deployment.apps/nginx-deployment
REVISION  CHANGE-CAUSE
1         <none>

2.SatefulSet

部署有状态应用，稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现

稳定的网络标志，即Pod重新调度后其PodName和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: nginxlabels:app: nginx
spec:ports:- port: 80name: webclusterIP: Noneselector:app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:name: web
spec:selector:matchLabels:app: nginx # has to match .spec.template.metadata.labelsserviceName: "nginx"replicas: 3 # by default is 1template:metadata:labels:app: nginx # has to match .spec.selector.matchLabelsspec:terminationGracePeriodSeconds: 10containers:- name: nginximage: k8s.gcr.io/nginx-slim:0.8ports:- containerPort: 80name: webvolumeMounts:- name: wwwmountPath: /usr/share/nginx/htmlvolumeClaimTemplates:- metadata:name: wwwspec:accessModes: [ "ReadWriteOnce" ]storageClassName: "my-storage-class"resources:requests:storage: 1Gi

2.1StatefulSet组成

综上所述，可知StatefulSet由三个组件（部分）组成

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

---

2.2headless的由来

在deployment中，每个pod是没有名称，是随机字符串，是无序的。而statefulset中是要求有序的，每一个pod的名称必须是固定的。当节点挂了，重建之后的标识符是不变的，每一个节点的节点名称是不能改变的。pod名称是作为pod识别的唯一标识符，必须保证其标识符的稳定并且唯一。

为了实现标识符的稳定，需要一个headless service 解析直达到pod，需要给pod配置一个唯一的名称。

2.3有状态服务和无状态服务的区别

k8s的StatefullSet是为了解决有状态服务的问题(对应Deployments和ReplicaSets是为无状态服务而设计)

有状态和无状态服务的区别如下:

有状态:

（1）有实时的数据需要存储

（2）集群服务中,把某一台服务器抽离出去,过一段时间再加入到集群中,如果服务集群无法正常工作

(相互之间需要数据同步)

无状态:

（1）没有实时的数据需要存储

（2）集群服务中,把某一台服务器抽离出去,过一段时间再加入到集群中,如果服务集群还是正常工作

(相互之间不用数据同步)

2.4使用volumeClainTemplate目的

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

2.5服务发现

StatefulSet 是 Kubernetes 用于管理有状态应用的控制器，服务发现在 StatefulSet 中尤为重要。服务发现是应用服务之间相互定位的过程

（1）应用场景

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

（2）K8S中服务发现的方式

K8S中服务发现的方式是DNS，使K8S集群能够自动关联Service资源的“名称”和“CLUSTER-IP”，从而实现服务被集群自动发现的目的

实现K8S里DNS功能的插件

• **skyDNS：**Kubernetes 1.3之前的版本（现在不用l）
• **kubeDNS：**Kubernetes 1.3至Kubernetes 1.11(现在不用了)
• **CoreDNS：**Kubernetes 1.11开始至今

（3）安装CoreDNS

只有二进制部署环境需要安装CoreDNS

安装方法一

** 去GitHub下载 **

https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/coredns/coredns.yaml.basevim transforms2sed.sed
s/__DNS__SERVER__/10.0.0.2/g
s/__DNS__DOMAIN__/cluster.local/g
s/__DNS__MEMORY__LIMIT__/170Mi/g
s/__MACHINE_GENERATED_WARNING__/Warning: This is a file generated from the base underscore template file: coredns.yaml.base/gsed -f transforms2sed.sed coredns.yaml.base > coredns.yaml

安装方法二

使用yaml文件

kubectl create -f coredns.yamlkubectl get pods -n kube-systemvim nginx-service.yaml
apiVersion: v1  
kind: Service  
metadata:name: nginx-servicelabels:app: nginx  
spec:type: NodePort  ports:- port: 80targetPort: 80  selector:app: nginxkubectl create -f nginx-service.yamlkubectl get svc
NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
kubernetes      ClusterIP   10.96.0.1       <none>        443/TCP        5d19h
nginx-service   NodePort    10.96.173.115   <none>        80:31756/TCP   10s

vim pod6.yaml 
apiVersion: v1
kind: Pod
metadata:name: dns-test
spec:containers:- name: busyboximage: busybox:1.28.4args:- /bin/sh- -c- sleep 36000restartPolicy: Neverkubectl create -f pod6.yaml 

解析kubernetes和nginx-service名称
kubectl exec -it dns-test sh
/ # nslookup kubernetes
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.localName:      kubernetes
Address 1: 10.96.0.1 kubernetes.default.svc.cluster.local
/ # nslookup nginx-service
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.localName:      nginx-service
Address 1: 10.96.173.115 nginx-service.default.svc.cluster.local

查看statefulset的定义
kubectl explain statefulset
KIND:     StatefulSet
VERSION:  apps/v1DESCRIPTION:StatefulSet represents a set of pods with consistent identities. Identitiesare defined as: - Network: A single stable DNS and hostname. - Storage: Asmany VolumeClaims as requested. The StatefulSet guarantees that a givennetwork identity will always map to the same storage identity.FIELDS:apiVersion	<string>kind	<string>metadata	<Object>spec	<Object>status	<Object>kubectl explain statefulset.spec
KIND:     StatefulSet
VERSION:  apps/v1RESOURCE: spec <Object>DESCRIPTION:Spec defines the desired identities of pods in this set.A StatefulSetSpec is the specification of a StatefulSet.FIELDS:podManagementPolicy	<string>  #Pod管理策略replicas	<integer>    #副本数量revisionHistoryLimit	<integer>   #历史版本限制selector	<Object> -required-    #选择器，必选项serviceName	<string> -required-  #服务名称，必选项template	<Object> -required-    #模板，必选项updateStrategy	<Object>       #更新策略volumeClaimTemplates	<[]Object>   #存储卷申请模板，必选项

清单定义StatefulSet
综上所述，一个完整的 StatefulSet 控制器由一个 Headless Service、一个 StatefulSet 和一个 volumeClaimTemplate 组成。如下资源清单中的定义：vim stateful-demo.yaml
apiVersion: v1
kind: Service
metadata:name: myapp-svclabels:app: myapp-svc
spec:ports:- port: 80name: webclusterIP: Noneselector:app: myapp-pod
---
apiVersion: apps/v1
kind: StatefulSet
metadata:name: myapp
spec:serviceName: myapp-svcreplicas: 3selector:matchLabels:app: myapp-podtemplate:metadata:labels:app: myapp-podspec:containers:- name: myappimage: ikubernetes/myapp:v1ports:- containerPort: 80name: webvolumeMounts:- name: myappdatamountPath: /usr/share/nginx/htmlvolumeClaimTemplates:- metadata:name: myappdataannotations:          #动态PV创建时，使用annotations在PVC里声明一个StorageClass对象的标识进行关联volume.beta.kubernetes.io/storage-class: nfs-client-storageclassspec:accessModes: ["ReadWriteOnce"]resources:requests:storage: 2Gi由于 StatefulSet 资源依赖于一个实现存在的 Headless 类型的 Service 资源，所以需要先定义一个名为 myapp-svc 的 Headless Service 资源，用于为关联到每个 Pod 资源创建 DNS 资源记录。接着定义了一个名为 myapp 的 StatefulSet 资源，它通过 Pod 模板创建了 3 个 Pod 资源副本，并基于 volumeClaimTemplates 向前面创建的PV进行了请求大小为 2Gi 的专用存储卷。

创建pv   静态
//stor01节点
mkdir -p /data/volumes/v{1,2,3,4,5}vim /etc/exports
/data/volumes/v1 192.168.80.0/24(rw,no_root_squash)
/data/volumes/v2 192.168.80.0/24(rw,no_root_squash)
/data/volumes/v3 192.168.80.0/24(rw,no_root_squash)
/data/volumes/v4 192.168.80.0/24(rw,no_root_squash)
/data/volumes/v5 192.168.80.0/24(rw,no_root_squash)systemctl restart rpcbind
systemctl restart nfsexportfs -arvshowmount -e

定义PV
vim pv-demo.yaml
apiVersion: v1
kind: PersistentVolume
metadata:name: pv001labels:name: pv001
spec:nfs:path: /data/volumes/v1server: stor01accessModes: ["ReadWriteMany","ReadWriteOnce"]capacity:storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv002labels:name: pv002
spec:nfs:path: /data/volumes/v2server: stor01accessModes: ["ReadWriteOnce"]capacity:storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv003labels:name: pv003
spec:nfs:path: /data/volumes/v3server: stor01accessModes: ["ReadWriteMany","ReadWriteOnce"]capacity:storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv004labels:name: pv004
spec:nfs:path: /data/volumes/v4server: stor01accessModes: ["ReadWriteMany","ReadWriteOnce"]capacity:storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv005labels:name: pv005
spec:nfs:path: /data/volumes/v5server: stor01accessModes: ["ReadWriteMany","ReadWriteOnce"]capacity:storage: 2Gikubectl apply -f pv-demo.yamlkubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGE
pv001     1Gi        RWO,RWX        Retain           Available                                      7s
pv002     2Gi        RWO            Retain           Available                                      7s
pv003     2Gi        RWO,RWX        Retain           Available                                      7s
pv004     2Gi        RWO,RWX        Retain           Available                                      7s
pv005     2Gi        RWO,RWX        Retain           Available                           			7s

创建statefulset
kubectl apply -f stateful-demo.yaml kubectl get svc  #查看创建的无头服务myapp-svc
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)             AGE
kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP             50d
myapp-svc    ClusterIP   None             <none>        80/TCP              38skubectl get sts    #查看statefulset
NAME      DESIRED   CURRENT   AGE
myapp     3         3         55skubectl get pvc    #查看pvc绑定
NAME                STATUS    VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
myappdata-myapp-0   Bound     pv002     2Gi        RWO                           1m
myappdata-myapp-1   Bound     pv003     2Gi        RWO,RWX                       1m
myappdata-myapp-2   Bound     pv004     2Gi        RWO,RWX                       1mkubectl get pv    #查看pv绑定
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                       STORAGECLASS   REASON    AGE
pv001     1Gi        RWO,RWX        Retain           Available                                                        6m
pv002     2Gi        RWO            Retain           Bound       default/myappdata-myapp-0                            6m
pv003     2Gi        RWO,RWX        Retain           Bound       default/myappdata-myapp-1                            6m
pv004     2Gi        RWO,RWX        Retain           Bound       default/myappdata-myapp-2                            6m
pv005     2Gi        RWO,RWX        Retain           Available                                                        6mkubectl get pods   #查看Pod信息
NAME                     READY     STATUS    RESTARTS   AGE
myapp-0                  1/1       Running   0          2m
myapp-1                  1/1       Running   0          2m
myapp-2                  1/1       Running   0          2mkubectl delete -f stateful-demo.yaml	当删除的时候是从myapp-2开始进行删除的，关闭是逆向关闭
kubectl get pods -w此时PVC依旧存在的，再重新创建pod时，依旧会重新去绑定原来的pvc
kubectl apply -f stateful-demo.yamlkubectl get pvc
NAME                STATUS    VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
myappdata-myapp-0   Bound     pv002     2Gi        RWO                           5m
myappdata-myapp-1   Bound     pv003     2Gi        RWO,RWX                       5m
myappdata-myapp-2   Bound     pv004     2Gi        RWO,RWX

滚动更新
//StatefulSet 控制器将在 StatefulSet 中删除并重新创建每个 Pod。它将以与 Pod 终止相同的顺序进行（从最大的序数到最小的序数），每次更新一个 Pod。在更新其前身之前，它将等待正在更新的 Pod 状态变成正在运行并就绪。如下操作的滚动更新是按照2-0的顺序更新。
vim stateful-demo.yaml  		#修改image版本为v2
.....
image: ikubernetes/myapp:v2
....kubectl apply -f stateful-demo.yamlkubectl get pods -w   #查看滚动更新的过程
NAME      READY   STATUS        RESTARTS   AGE
myapp-0   1/1     Running       0          29s
myapp-1   1/1     Running       0          27s
myapp-2   0/1     Terminating   0          26s
myapp-2   0/1     Terminating   0          30s
myapp-2   0/1     Terminating   0          30s
myapp-2   0/1     Pending       0          0s
myapp-2   0/1     Pending       0          0s
myapp-2   0/1     ContainerCreating   0          0s
myapp-2   1/1     Running             0          31s
myapp-1   1/1     Terminating         0          62s
myapp-1   0/1     Terminating         0          63s
myapp-1   0/1     Terminating         0          66s
myapp-1   0/1     Terminating         0          67s
myapp-1   0/1     Pending             0          0s
myapp-1   0/1     Pending             0          0s
myapp-1   0/1     ContainerCreating   0          0s
myapp-1   1/1     Running             0          30s
myapp-0   1/1     Terminating         0          99s
myapp-0   0/1     Terminating         0          100s
myapp-0   0/1     Terminating         0          101s
myapp-0   0/1     Terminating         0          101s
myapp-0   0/1     Pending             0          0s
myapp-0   0/1     Pending             0          0s
myapp-0   0/1     ContainerCreating   0          0s
myapp-0   1/1     Running             0          1s

在创建的每一个Pod中，每一个pod自己的名称都是可以被解析的
kubectl exec -it myapp-0 /bin/sh
Name:      myapp-0.myapp-svc.default.svc.cluster.local
Address 1: 10.244.2.27 myapp-0.myapp-svc.default.svc.cluster.local
/ # nslookup myapp-1.myapp-svc.default.svc.cluster.local
nslookup: can't resolve '(null)': Name does not resolveName:      myapp-1.myapp-svc.default.svc.cluster.local
Address 1: 10.244.1.14 myapp-1.myapp-svc.default.svc.cluster.local
/ # nslookup myapp-2.myapp-svc.default.svc.cluster.local
nslookup: can't resolve '(null)': Name does not resolveName:      myapp-2.myapp-svc.default.svc.cluster.local
Address 1: 10.244.2.26 myapp-2.myapp-svc.default.svc.cluster.local可以看到在容器当中可以通过对Pod的名称进行解析到ip。其解析的域名格式如下：
(pod_name).(service_name).(namespace_name).svc.cluster.local

机器里有这些

作为nfs的nginx01机器上有三个新建的myapp-sts

删除www-myapp-sts

再次创建pvc

去nfs机器nginx01上再次创建下面目录

myapp-sts-0创建好了，依次创建后就可以恢复

动态创建的pv和pvc创建了一次就不会再次创建了，目录名称不会变，只有在yaml里面改才会变

在k8smaster01节点删除sts-0,sts-1.sts-2,在nfs节点nginx01主机仍然有

default-www-myapp-sts-0-pvc-3f494113-9e49-4158-93b0-8ef41290609c

default-www-myapp-sts-1-pvc-d5e65375-48cc-4b76-89d2-770b7f250dfa

default-www-myapp-sts-2-pvc-fecb3ae5-fda8-4133-a6ed-d93f7ebbdf1b

总结

无状态

（1）deployment 认为所有的pod都是一样的

（2）不用考虑顺序的要求

（3）不用考虑在哪个node节点上运行

（4）可以随意扩容和缩容

有状态

（1）实例之间有差别，每个实例都有自己的独特性，元数据不同，例如etcd，zookeeper

（2）实例之间不对等的关系，以及依靠外部存储的应用。

常规service和无头服务区别

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

Headless service：无头服务，不需要cluster-IP，而是直接以DNS记录的方式解析出被代理Pod的IP地址。

vim pod6.yaml 
apiVersion: v1
kind: Pod
metadata:name: dns-test
spec:containers:- name: busyboximage: busybox:1.28.4args:- /bin/sh- -c- sleep 36000restartPolicy: Nevervim sts.yaml
apiVersion: v1
kind: Service
metadata:name: nginxlabels:app: nginx
spec:ports:- port: 80name: webclusterIP: Noneselector:app: nginx
---
apiVersion: apps/v1beta1  
kind: StatefulSet  
metadata:name: nginx-statefulset  namespace: default
spec:serviceName: nginx  replicas: 3  selector:matchLabels:  app: nginxtemplate:  metadata:labels:app: nginx  spec:containers:- name: nginximage: nginx:latest  ports:- containerPort: 80  kubectl apply -f sts.yamlkubectl apply -f pod6.yamlkubectl get pods,svckubectl exec -it dns-test sh
/ # nslookup nginx-statefulset-0.nginx.default.svc.cluster.local
/ # nslookup nginx-statefulset-1.nginx.default.svc.cluster.local
/ # nslookup nginx-statefulset-2.nginx.default.svc.cluster.localkubectl exec -it nginx-statefulset-0 bash
/# curl nginx-statefulset-0.nginx
/# curl nginx-statefulset-1.nginx
/# curl nginx-statefulset-2.nginx扩展伸缩
kubectl scale sts myapp --replicas=4  #扩容副本增加到4个kubectl get pods -w  #动态查看扩容kubectl get pv  #查看pv绑定kubectl patch sts myapp -p '{"spec":{"replicas":2}}'  #打补丁方式缩容kubectl get pods -w  #动态查看缩容

kubectl patch statefulsets.apps myapp-sts -p '{"spec":{"replicas":2}}'
下一级用：号
同级用，号

在删除一个缩成两个了

3.DaemonSet

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

3.1DaemonSet用法

• 运行集群存储 daemon，例如在每个 Node 上运行 glusterd、ceph。
• 在每个 Node 上运行日志收集 daemon，例如fluentd、logstash。
• 在每个 Node 上运行监控 daemon，如 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-daemonSetlabels:app: nginx
spec:selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.15.4ports:- containerPort: 80kubectl apply -f ds.yaml//DaemonSet会在每个node节点都创建一个Pod
kubectl get pods
nginx-deployment-4kr6h   1/1     Running     0          35s
nginx-deployment-8jrg5   1/1     Running     0          35s

4.Job

ob分为普通任务（Job）和定时任务（CronJob）

常用于运行那些仅需要执行一次的任务

应用场景：数据库迁移、批处理脚本、kube-bench扫描、离线数据处理，视频解码等

官网案例

vim job.yaml
apiVersion: batch/v1
kind: Job
metadata:name: pi
spec:template:spec:containers:- name: piimage: perl  #perl语言编码工具command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]restartPolicy: NeverbackoffLimit: 4bpi圆周率算法-w|e 命令行开关.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 perlkubectl apply -f job.yaml kubectl get pods
pi-bqtf7                 0/1     Completed   0          41s结果输出到控制台
kubectl logs pi-bqtf7
3.14159265......清除job资源
kubectl delete -f job.yaml 
——————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————
backoffLimit
vim job-limit.yaml
apiVersion: batch/v1
kind: Job
metadata:name: busybox
spec:template:spec:containers:- name: busyboximage: busyboximagePullPolicy: IfNotPresentcommand: ["/bin/sh", "-c", "sleep 10;date;exit 1"]restartPolicy: NeverbackoffLimit: 2kubectl apply -f job-limit.yamlkubectl get job,pods
NAME                COMPLETIONS   DURATION   AGE
job.batch/busybox   0/1           4m34s      4m34sNAME                READY   STATUS   RESTARTS   AGE
pod/busybox-dhrkt   0/1     Error    0          4m34s
pod/busybox-kcx46   0/1     Error    0          4m
pod/busybox-tlk48   0/1     Error    0          4m21skubectl describe job busybox
......
Warning  BackoffLimitExceeded  43s    job-controller  Job has reached the specified backoff limit

改下让执行出问题

等待10秒，运行两次，后提示Job has reached the specified backoff limit

5.CronJob

在 Kubernetes 中，周期性任务的功能类似于 Linux 中的 crontab，用于定时调度任务。Kubernetes 提供了一种资源类型叫 CronJob，用于按照指定的时间表周期性地运行任务。CronJob 是 Kubernetes 对 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: helloimage: busyboximagePullPolicy: IfNotPresentargs:- /bin/sh- -c- date; echo Hello from the Kubernetes clusterrestartPolicy: OnFailure  #周期化任务重启策略当非0时重启，正常运行正常退出，不能运行时重复运行cronjob可用参数
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
NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
hello   */1 * * * *   False     0        <none>          25skubectl get pods
NAME                     READY   STATUS      RESTARTS   AGE
hello-1621587180-mffj6   0/1     Completed   0          3m
hello-1621587240-g68w4   0/1     Completed   0          2m
hello-1621587300-vmkqg   0/1     Completed   0          60skubectl 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

总结

**（1）**k8s中pod控制器是k8s 中的一个概念吗 用与管理一组pod的状态

Pod控制器可以确保Pod以一定的数量和副本数运行,并且能够处理不同的启动和终止情况

（2）Pod deployment

• 部署无状态应用 管理 replicas(RS)和pod创建Pod,维护副本数目于期望状态相同
• 创建和删除Pod时候是并行执行的,升级时是先创建一部分 再删除一部分

（3）statefulset

• 部署有状态应用，每个pod 唯一且不变的，在 k8s 集群内部可以通过
• 创建和删除pod有顺序的(串行执行的)
• 升级是也是串行的,会删除旧的pod,再创建新的pod的,删除和升级时逆执行的(先从标识符最大的n-1开始,一直到最小0)
• 创建时是升序执行的(标识符从0到n-1)

每个pod拥有自己的专属持久化存储(PV和PVC)

(pod name) .(service_name).(namespace_name).svc.cluster.local 解析出 pod的IP(基于headless service 和CoreDNS)

（4）daemonSet

理论上 可以在k8s集群的所有node节点上创建相同的pod(不论node节点什么时候加入到k8s集群),但是会收到node节点上的污点的影响

（5）job

部署一次性任务的pod,正常完成后容器立即退出而不重启容器(restarPlolicy不设置always),也不会建pod,异常完成后重建的pod会重试任务,重建次数根据backofflimit 配置指定(默认为6次)

（6）crontab

周期性的部署任务的pod,正常完成后容器立即退出 不会重启容器{restarPlolicy(* * * * *)分时日月周

不设置always},也不会建pod,schedule配置周期性的时间表