pod控制器

pod控制器：

pv pvc 动态pv.

pod控制器：工作负载，workload.用于管理pod的中间层。确保pod资源符合预期的状态。

预期状态：

1、副本数

2、容器的重启策略

3、镜像拉取策略。

pod出现故障时的重启等等。

pod控制器的类型：

1、replicaSet：指定pod副本的数量。

三个组件：1、pod的副本数? ?2、标签选择器，判断哪个pod归自己管理

? ? ? ? ? ? ? ? ? 3、扩缩容

2、Deployment控制器，他是工作在replicaSet之上。管理无状态应用。目前是最好的控制器。支持滚动更新和回滚。提供声明式配置。
3、statefulSet：控制器的一种，管理有状态的应用，也可以设置副本数，可以扩缩容。pod的序号是固定的。重启之后，pod的名称也不会发生变化。有状态
4、DaemonSet：可以在所有节点部署一个pod，他没有副本数。可以限制部署的节点。也是无状态的应用。服务必须是守护进程。ingress logstash flannel.
5、job：工作pod控制器，执行完成即可退出，不要重启，不需要重建
6、cronjob：周期性的定时任务控制器。不需要在后台持续运行。

（1）有状态应用?
pod的名称有序，所有pod都独立，存储卷也独立。顺序0-n,delete删除也不会改变pod的序号。扩缩容也是有序扩缩容?
（2）无状态应用
deployment认为所有的pod都是一样的，名称无序，共享存储nfs。
不用考虑顺序的要求
不用考虑在哪个node节点上运行
可以随意扩容和缩容

Deployment控制器

SatefulSet?控制器

headless service:无头服务，没有clusterlP。

必须要有动态的pvc.

创建演示?

apiVersion: v1
kind: Service
metadata:
? name: nginx-svc
spec:
? ports:
? - port: 80
? ? targetPort: 80
? clusterIP: None
? selector:
? ? app: nginx-sts
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
? name: nginx-sts
spec:
? replicas: 3
? serviceName: "nginx-sts"
? selector:
? ? matchLabels:
? ? ? app: nginx-sts
? template:
? ? metadata:
? ? ? labels:
? ? ? ? app: nginx-sts
? ? spec:
? ? ? containers:
? ? ? - image: nginx:1.14
? ? ? ? imagePullPolicy: IfNotPresent
? ? ? ? name: nginx-test
? ? ? ? ports:
? ? ? ? - containerPort: 80
? ? ? ? ? protocol: TCP
? ? ? ? volumeMounts:
? ? ? ? - name: www
? ? ? ? ? mountPath: /usr/share/nginx/html
? volumeClaimTemplates:
? - metadata:
? ? ? name: www
? ? spec:
? ? ? accessModes: [ "ReadWriteOnce" ]
? ? ? storageClassName: "nfs-client-storageclass"
? ? ? resources:
? ? ? ? requests:
? ? ? ? ? storage: 2Gi

扩容与缩容

kubectl edit sts

headless service:k8s集群当中一种特殊的服务类型。不分配clusterlP给service.也不会负载均衡到后端的pod。
DNS来提供服务的发现和访问。
由于Clusterip是空，k8s集群会给每个headless service中的pod创建一个dns记录。
格式： pod-name.headless-service-name.namespace.svc.cluster.local.

为什么要用headless:

有序。
独立个体。
deployment的pod是没有名称的，随机字符串，无序。他需要一个集中的clusterip来集中统一为pod提供网络。
statefulset是有序的，pod的名称是固定的。重建之后pod的标识符也不变。pod的名称是唯一的标识符。
系统直接通过pod名称解析ip地址。ip地址不变?

为什么要有volumeClaimTemplates:

有状态的副本吧集群都会涉及持久化存储，每个pod是独立个体，每个pod都有一个自己专用的存储点。
statefulset在定义的时候就规定了每个pod是不能同一个存储卷。所以才需要动态pv.
不是固定节点的应用，不是固定ip的应用、
更新发布比较频发。
支持自动伸缩，节点的资源资源不够，可以自动扩容。

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.14
? ? ? ? ports:
? ? ? ? - containerPort: 80
?
?
kubectl apply -f ds.yaml

daemonSet:确保每个节点上都运行一个pod副本。当node加入集群，也会为他新增一个pod.
当node节点从集群当中移除时，pod也会被回收。
daemonSet不需要指定调度策略，默认会在每个节点创建一个pod。除非污点。
我们也可以通过指定的方式，只把deamonset部署在指定的节点。
没有副本数选择，不需要设置。
控制器类型的资源创建方式：基于控制器创建的pod,delete只是相当于重启，要彻底删除pod,必须删除控制器。
不要随便的delete。

Job控制器

vim job.yaml
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

参数解释：
.spec.template.spec.restartPolicy该属性拥有三个候选值：OnFailure，Never和Always。默认值为Always。它主要用于描述Pod内容器的重启策略。在Job中只能将此属性设置为OnFailure或Never，否则Job将不间断运行。

.spec.backoffLimit用于设置job失败后进行重试的次数，默认值为6。默认情况下，除非Pod失败或容器异常退出，Job任务将不间断的重试，此时Job遵循 .spec.backoffLimit上述说明。一旦.spec.backoffLimit达到，作业将被标记为失败。

job的作用，执行只需要一次性的任务。
脚本需要执行，数据库迁移，视频解码等等业务。
对于k8s系统来说，既然定义了是job，你只需要执行一次，或者指定次数即可。不能一直允许。
第一个：必须指定的容器策略 onfailure never
第二个：执行失败的次数也是受限的。默认是6次。

第三点：更新yaml文件，先删除任务，再更新。不能动态更新。

容器化部署，部署过数据库没有？数据库是核心资产，不会容器化部署。

前端你们会容器化部署吗？nginx可以容器化部署。

CronJob?

周期性任务，定时执行，和linux的crontab一模一样，语法一样

分时日月周

应用场景：定时备份通知作用。定时检测（结合探针一起做）

示例：
//每分钟打印hello
vim cronjob.yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
? name: hello
spec:
? schedule: "*/1 * * * *"
? jobTemplate:
? ? spec:
? ? ? template:
? ? ? ? spec:
? ? ? ? ? containers:
? ? ? ? ? - name: hello
? ? ? ? ? ? image: busybox
? ? ? ? ? ? imagePullPolicy: IfNotPresent
? ? ? ? ? ? args:
? ? ? ? ? ? - /bin/sh
? ? ? ? ? ? - -c
? ? ? ? ? ? - date; echo Hello from the Kubernetes cluster
? ? ? ? ? restartPolicy: OnFailure
?? ??? ? ?
//cronjob其它可用参数的配置
spec:
? concurrencyPolicy: Allow?? ??? ??? ?#声明了 CronJob 创建的任务执行时发生重叠如何处理（并发性规则仅适用于相同 CronJob 创建的任务）。spec仅能声明下列规则中的一种:
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?●Allow (默认)：CronJob 允许并发任务执行。
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?●Forbid：CronJob 不允许并发任务执行；如果新任务的执行时间到了而老任务没有执行完，CronJob 会忽略新任务的执行。
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?●Replace：如果新任务的执行时间到了而老任务没有执行完，CronJob 会用新任务替换当前正在运行的任务。
? startingDeadlineSeconds: 15?? ??? ?#它表示任务如果由于某种原因错过了调度时间，开始该任务的截止时间的秒数。过了截止时间，CronJob 就不会开始任务，且标记失败.如果此字段未设置，那任务就没有最后期限。
? successfulJobsHistoryLimit: 3?? ??? ?#要保留的成功完成的任务数（默认为3）
? failedJobsHistoryLimit：1 ? ? ? ? #要保留多少已完成和失败的任务数（默认为1）
? suspend：true ? ? ? ? ? ? ? ? ? ? #如果设置为 true ，后续发生的执行都会被挂起。 这个设置对已经开始的执行不起作用。默认是 false。
? schedule: '*/1 * * * *'?? ??? ??? ?#必需字段，作业时间表。在此示例中，作业将每分钟运行一次
? jobTemplate:?? ??? ??? ??? ??? ??? ?#必需字段，作业模板。这类似于工作示例
?
kubectl create -f cronjob.yaml?
?
kubectl get cronjob
NAME ? ?SCHEDULE ? ? ?SUSPEND ? ACTIVE ? LAST SCHEDULE ? AGE
hello ? */1 * * * * ? False ? ? 0 ? ? ? ?<none> ? ? ? ? ?25s
?
kubectl 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 ? ? ? ? ?60s
?
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

总结

Pod 控制器有几种？
1、Deployment+ReplicaSet ?部署无状态应用的Pod
2、StatefulSet ? ?部署有状态应用的Pod
3、DaemonSet ? ? ?在K8S集群的所有Node节点上部署相同的Pod
4、Job ? ? ? ? ? ?部署一次性的任务Pod，完成后就会退出并不会重启
5、CronJob ? ? ? ?部署周期性的任务Pod，完成后就会退出并不会重启
?
Deployment
1、部署无状态应用的
2、创建和管理 ReplicaSet(RS)和Pod资源，维护Pod副本数量与期望值相同
3、创建和删除Pod时是并行执行的，升级时是先创建一部分新Pod，再删除一部分旧Pod
?
StatefulSet
1、部署有状态应用的 ??
2、每个Pod的名称是唯一且固定不变的，而且每个Pod应该拥有自己专属的持久化存储（基于PVC模板volumeClaimTemplates绑定PV）
3、需要关联 Headless Service（ClusterIP为None），在K8S集群内部可通过 <pod_name>.<svc.name>.<namespace_name>.svc.cluster.local 的格式解析出 PodIP （基于无头服务和CoreDNS实现）
4、创建、删除、升级、扩缩容Pod都是有序进行的（默认为串行执行的）：
? ? 创建、升级是升序执行的（顺序为Pod标识序号0..n-1），删除是逆序执行的（顺序为 n-1..0）
? ? 扩缩容都是逆序执行的（顺序为 n-1..0），会先删除旧Pod，再创建新Pod
?
spec.podManagementPolicy: Parallel ?#可设置StatefulSet创建和删除Pod时为并行执行
?
service类型种类 ?4+1
ClusterIP
NodePort
LoadBalancer
ExtenalName
?
Headless Service
常规service与Headless Service的区别
常规service：一组Pod的访问策略，提供ClusterIP在K8S集群内部访问，还提供负载均衡和服务发现功能
Headless Service：无头服务，可以不需要ClusterIP，与StatefulSet资源关联配合CoreDNS实现通过 Pod名称 解析出 PodIP
?
DaemonSet
1、理论上可以在K8S集群的所有Node节点上创建同类型的Pod资源（无论Node节点什么加入到K8S集群）
2、会受到Node节点上的污点或者cordon不可调度设置的影响。可以在Pod配置中设置容忍忽略污点，设置uncordon解除不可调度
3、不需要设置副本数replicas
?
Job
1、部署一次性任务的资源
2、任务正常完成后Pod容器会立即退出并不会再重启（Job类型Pod容器的retartPolicy通常设置为Never），也不会重建Pod
3、如果任务异常完成Pod容器异常退出，会重建Pod重试任务，重试次数根据 backoffLimit 配置（默认6次）
?
CronJob
1、部署周期性任务的资源，一次任务至少创建一个Pod
2、任务正常完成后Pod容器会立即退出并不会再重启（Job类型Pod容器的retartPolicy不设置为Always），也不会重建Pod
3、使用 spec.schedule 字段设置时间周期表，格式为 '分 时 日 月 周'