????????Pod （就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个）容器容器是可移植、可执行的轻量级的镜像，镜像中包含软件及其相关依赖。（例如 Docker 容器），这些容器共享存储、网络、以及怎样运行这些容器的声明。Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行，通过namespace进行隔离。

????????Pod 所建模的是特定于应用的“逻辑主机”，其中包含一个或多个应用容器，这些容器是相对紧密的耦合在一起 ——在容器出现之前，在相同的物理机或虚拟机上运行意味着在相同的逻辑主机上运行。

????????Pod是可以创建和管理Kubernetes计算的最小可部署单元，一个Pod代表着集群中运行的一个进程，每个pod都有一个唯一的ip。

1、pod的组成

??????? Pod 被设计成支持形成内聚服务单元的多个协作过程（作为容器）。Pod 中的容器被自动的安排到集群中的同一物理或虚拟机上，并可以一起进行调度。容器可以共享资源和依赖、彼此通信、协调何时以及何种方式终止它们。

????????Pod 为其组成容器提供了两种共享资源：网络和存储。

???????? 网络：
????????每个 Pod 分配一个唯一的 IP 地址。Pod 中的每个容器共享网络命名空间，包括 IP 地址和网络端口。Pod 内的容器可以使用 localhost 互相通信。当 Pod 中的容器与 Pod 之外的实体通信时，它们必须协调如何使用共享的网络资源（例如端口）。存储一个 Pod 可以指定一组共享存储卷包含可被 Pod 中容器访问的数据的目录。

????????存储：
????????Pod 中的所有容器都可以访问共享卷，允许这些容器共享数据。卷还允许 Pod 中的持久数据保留下来，以防其中的容器需要重新启动。

2、pod的一些相关配置

????????官网kubectl命令手册：https://kubernetes.io/docs/reference/generated/kubectl/kubectlcommands

###在server2 server3 节点上配置docker的私有仓库：vim /etc/docker/daemon.json

##内容##
{  
  "registry-mirrors": ["https://reg.red.org"], ##添加私有仓库
  "exec-opts": ["native.cgroupdriver=systemd"],  
  "log-driver": "json-file",  
  "log-opts": {    
    "max-size": "100m"  
  },  
  "storage-driver": "overlay2",  
  "storage-opts": [    
    "overlay2.override_kernel_check=true"  
  ] 
}

##重启docker服务，并保证每个节点有访问的证书（访问私有仓库）

##查看命名空间
[root@server1 docker]# kubectl get ns

##启动一个容器
[root@server1 docker]# kubectl run demo --image=busybox -it

##查看、更改pod的标签--通过标签对pod进行独立管理

##创建标签
[root@server1 kubemainfest]# kubectl label pod myapp app=nginx
                                          ·####pod名称  label

##修改标签
[root@server1 kubemainfest]# kubectl label pod myapp app=nginx18 --overwrite

##过滤包含app标签的pod
[root@server1 kubemainfest]# kubectl get pod -l app

二、Pod的生命周期

????????生命周期，即使从init开始到该POD内所有容器结束运行，或者该容器进程被结束，即周期结束。

上述过程，只有状态监测通过，service才能向外部暴露。

2.1 init容器

????????官网参考：https://kubernetes.io/zh/docs/concepts/workloads/pods/init-containers/

2.1.1 Init容器介绍

????????init容器，被称之为初始化容器，一般用于POD内容器运行前的初始化监测。

Init 容器的特点：

????????? ?有一个或多个先于应用容器启动的Init ；

????????? 它们总是运行到完成；

????????? Init 容器不支持 Readiness，必须在 Pod 就绪之前运行完成；

??????? ? 多个Init时，每个 Init 容器必须运行成功，下一个才能够运行；

????????? 如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。然而，如果 Pod 对应的 restartPolicy 值为 Never，它不会重新启动。

Init 容器的工作优势：

????????? Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码；

????????? Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低；

????????? 应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像；

????????? Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此，Init容器可具有访问 Secrets 的权限，而应用容器不能够访问；

????????? 由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod内的所有的应用容器会并行启动。

2.1.2 创建init容器（🌰）

##编写资源清单，创建init容器
[root@server1 kubemainfest]# vim init.yml 
[root@server1 kubemainfest]# cat init.yml 
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox:latest
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:        ##初始化容器内容
  - name: init-myservice    ##myservice
    image: busybox:latest
    command: ['sh', '-c', "until nslookup myservice.default.svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
  - name: init-mydb        ##mydb
    image: busybox:latest
    command: ['sh', '-c', "until nslookup mydb.default.svc.cluster.local; do echo waiting for mydb; sleep 2; done"]


##创建init的服务
[root@server1 kubemainfest]# cat service.yml 
kind: Service
apiVersion: v1
metadata:
  name: myservice
spec:
  ports:    ##设置端口映射
    - protocol: TCP
      port: 80
      targetPort: 9376
---
kind: Service
apiVersion: v1
metadata:
  name: mydb
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9377

上述过程中：初始化的进行时执行nslookup指令。

????????通过解析myservice.default.svc.cluster.local这个地址，如果解析成功则继续，不成功则一直处于初始化状态,循环do里面的内容。刚启动由于没有加入服务，则会一直循环

2.2 探针

2.2.1 探针基本简介（分类、结果、重启策略、定义的生命周期、三种控制器）

探针分类：ExecAction、TCPSocketAction、HTTPGetAction：

??????? ? ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功；

????????? TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的；

????????? HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于400，则诊断被认为是成功的。

探测结果:

????????? 成功：容器通过了诊断。

????????? 失败：容器未通过诊断。

????????? 未知：诊断失败，因此不会采取任何行动。

Kubelet 可以选择是否执行在容器上运行的三种探针执行和做出反应：

????????? livenessProbe：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为 Success。

????????? readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success。

????????? startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探测 (startup probe)，则禁用所有其他探测，直到它成功为止。如果启动探测失败，kubelet 将杀死容器，容器服从其重启策略进行重启。如果容器没有提供启动探测，则默认状态为成功Success。

一个问题：

????????该什么时候使用存活（liveness）和就绪（readiness）探针?

????????如果容器中的进程能够在遇到问题或不健康的情况下自行崩溃，则不一定需要存活探针; kubelet 将根据 Pod 的restartPolicy 自动执行正确的操作。

????????如果希望容器在探测失败时被杀死并重新启动，那么指定一个存活探针，并指定restartPolicy 为 Always 或 OnFailure。

??????? 如果要仅在探测成功时才开始向 Pod 发送流量，请指定就绪探针。在这种情况下，就绪探针可能与存活探针相同，但是 spec 中的就绪探针的存在意味着 Pod 将在没有接收到任何流量的情况下启动，并且只有在探针探测成功后才开始接收流量。

??????? 如果希望容器能够自行维护，可以指定一个就绪探针，该探针检查与存活探针不同的端点。请注意，如果只想在 Pod 被删除时能够排除请求，则不一定需要使用就绪探针；在删除 Pod 时，Pod 会自动将自身置于未完成状态，无论就绪探针是否存在。当等待 Pod 中的容器停止时，Pod 仍处于未完成状态。

重启策略：
????????PodSpec 中有一个 restartPolicy 字段，可能的值为 Always、OnFailure 和 Never。默认为 Always。

Pod 的生命：

????????一般Pod 不会消失，直到人为销毁他们，这可能是一个人或控制器。

??????? 建议创建适当的控制器来创建 Pod，而不是直接自己创建 Pod。因为单独的 Pod 在机器故障的情况下没有办法自动复原，而控制器却可以。

三种可用的控制器：

????????? 使用 Job 运行预期会终止的 Pod，例如批量计算。Job 仅适用于重启策略为 OnFailure 或 Never 的 Pod。

????????? 对预期不会终止的 Pod 使用 ReplicationController、ReplicaSet 和 Deployment ，例如 Web 服务器。 ReplicationController 仅适用于具有 restartPolicy 为 Always 的 Pod。

????????? 提供特定于机器的系统服务，使用 DaemonSet 为每台机器运行一个 Pod 。

2.2.2 举个🌰

##存活探针
[root@server1 kubemainfest]# cat init.yml 
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: nginx
  initContainers:
  - name: init-myservice
    image: busybox
    command: ['sh', '-c', "until nslookup myservice.default.svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
  containers:
  - name: myapp-container
    image: nginx
    imagePullPolicy: IfNotPresent
    livenessProbe:            ##存活探针
      tcpSocket:              ##对指定端口上的容器的 IP 地址进行 TCP 检查
        port: 80
      initialDelaySeconds: 1
      periodSeconds: 2
      timeoutSeconds: 1
    readinessProbe:         ##就绪探针
      httpGet:          
        path: /hostname.html          
        port: 80        
      initialDelaySeconds: 1        
      periodSeconds: 3        
      timeoutSeconds: 1

[root@server1 kubemainfest]# cat service.yml 
kind: Service
apiVersion: v1
metadata:
  name: myservice
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  selector:        ##与就绪探针相对应
    app: myapp

????????此时 前提是restartPolicy是always，所以当容器被挂载后会自动重启，该策略可以在资源清单中修改，这里不做赘述。

三、Pod节点的创建、增加、删除、改（更新和回滚）及集群中的POD（service中的POD）

3.1、pod的创建

3.1.1 普通方式创建

##创建Pod
[root@server1 docker]# kubectl run nginx --image=nginx     ##POD名字和指定镜像

##查看Pod
[root@server1 docker]# kubectl get pod

##查看Pod具体信息
[root@server1 docker]# kubectl get pod -o wide    ##运行状态--此时只有集群内可以访问

[root@server1 docker]# kubectl describe pod nginx     ##详情信息

##查看指定Pod日志
[root@server1 docker]# kubectl logs nginx

?3.1.2 使用控制器创建

##使用控制器部署
[root@server1 docker]# kubectl create deployment mynet --image=nginx

###其中###
mynet-5d5d4897f7-bgd48 
名字 -- 控制器rs - 容器ip

?【注】上述方法创建的POD在删除时，会自动拉起

3.2 pod的增和删（扩容与缩容）

##POD扩容---只有通过控制器创建的节点才能进行扩容---扩容缩容的实质是通过创建副本的数量进行控制

##创建pod
[root@server1 docker]# kubectl create deployment mynet --image=nginx

##扩容
[root@server1 docker]# kubectl scale deployment mynet --replicas=2

[root@server1 docker]# kubectl scale deployment mynet --replicas=5

#缩容
[root@server1 docker]# kubectl scale deployment mynet --replicas=3

控制器的调度规则：自动实现负载均衡，但master节点只负责管理，不提供服务。

3.3? Pod的删除

##删除直接创建的POD
[root@server1 docker]# kubectl delete pod nginx

##删除通过控制器创建的POD
[root@server1 docker]# kubectl delete deployment.apps mynet

3.4 Pod镜像的更新和回滚

##镜像更新
[root@server1 ~]# kubectl set image deployments mynet nginx=nginx:1.18.0 --record
[root@server1 ~]# kubectl rollout history deployment mynet
[root@server1 ~]# kubectl rollout undo deployment mynet--to-revision=2

kubectl get all 查看当前的所有资源

3.5 service下的Pod

3.5.1 集群内部的管控

????????service是一个抽象概念，定义了一个服务的多个pod逻辑合集和访问pod的策略，一般把service称为微服务。

????????pod客户端：可以通过service的名称访问后端的两个Pod

????????ClusterIP（默认类型）： 自动分配一个仅集群内部可以访问的虚拟IP

##创建service---前提是存在控制器管理的集群
[root@server1 docker]# kubectl expose deployment mynet --port=80 --target-port=80
                                                   外部主机访问时的端口  映射到服务器上的端口
##查看service
[root@server1 docker]# kubectl get svc mynet

##查看标签
[root@server1 docker]# kubectl get pod --show-labels

##查看详细信息
[root@server1 docker]# kubectl describe svc mynet

?【注】--port为暴漏出来的端口，不是默认值时需要额外指定，若相同则不需要再指定

3.5.2? 外部主机访问客户端Pod

##使用NodePort类型暴漏端口，使外部可以访问

##方法一##
[root@server1 docker]# kubectl edit svc mynet        ##编写配置文件

[root@server1 docker]# kubectl get svc                ##查看服务信息

##方法二##
#########在启动服务时，指定端口的访问规则
[root@server1 docker]# kubectl expose deployment nginx --port=80 --target-port=80 -type=NodePort

四、编写管理Pod的资源清单

????????官网指南：https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#deployment-v1-apps

??????? 自动生成：kubectl get pod -o yaml |less

4.1 基本格式和字段含义

????????一般使用yaml格式的文件来创建符合要求的POD，这样的yaml文件我们一般称为资源清单。

常用字段解释：

表 1 资源清单字段说明
参数名称	字段说明	说明
version	String	K8S API的版本，目前基本为V1，可以使用kubectl api-version命令查看
kind	String	这里指的是yaml文件定义的资源类型和角色，比如：POD
metadata	Object	元数据对象，固定值
metadata.name	String	元数据对象的名字，由我们编写，例如POD的名称
metadata.namespace	String	元数据对象的命名空间，由我们编写
Spec	Object	详细定义对象，固定值
Spec.containers[]	List	Spec对象的容器列表定义，是个列表
Spec.containers[].name	String	定义容器的名称
Spec.containers[].image	String	定义用到的镜像名称
spec.containers[].imagePullPolicy?	String	定义镜像拉取策，有Always、Never、IfNotPresent 三个值可选： (1)Always:是每次都尝试重新拉取镜像 ?(2)Never:表示仅便用本地镜 ?(3)IfNOtPresent：如果本地有镜像就使用本地镜像，没有就拉取在线镜像。 ? 默认值是Always。
spec.containers[].command[]	List	指定容器启动命令，因为是数组可以指定多个，不指定则使用镜像打包时使用的启动命令
spec.containers[].largs[]?	List	? (List): 指定容器启动命令参数，因为是数组可以指定多个。
spec.containers[].worKingDir	String	?指定容器工作目录
spec.containers[].volumeMounts[]	List	?指容器内部的存卷配置
spec.containers[].volumeMounts[].name	String	?指可以被容器挂载的存储卷的名称
spec.containers[].volumeMounts[].mountPatn	String	指可以被容器挂载的存储卷路径
spec.containers[].volumeMounts[].readOnly	String	设置存储卷路径的读写模式，ture或者false,默认为读写模式
spec.containers[].ports[]		?指走容器需要用到的端囗列表
spec.containers[].ports[].name	String	指定端口名称
spec.containers[].ports[].containerPort	String	?指定容器需要监听的端囗号
spec.containers[].ports[].hostPort	String	指定容器所在主机需要监听的端囗号，默认跟上面containerPort相同，注意设置了hostPort同一台主机无法启动该容器的相同副本（因为主机端囗号不能相同，这样会冲突）
spec.containers[].ports[].protocol	String	指定端囗协议，支持TCP和UDP,默认值为TCP
spec.containers[].env[]?	List	指定容器运行前需设置的环境变量列表
spec.containers[].env[].name	String	指定环境变量名称
spec.containers[].env[].value	String	指定环境变量值
spec.containers[].resources	Object	指定资源限制和资源请求的值（这里开始就是设置容器的资源上限〕
spec.containers[].resources.limits	Object	?指定设置容器运行时资源的运行上限
spec.containers[].resources.limits.cpu	String	指定CPU的限制，单位为core数，将用于 docker run --cpu-shares参数（这里前面文章Pod资源限制有讲过）
spec.containers[].resources.limits.memory	String	?指定MEM内存的限制，单位为MiB、GiB
spec.restartPolicy?	String	?定义Pod的重启策略，可选值为Always、OnFailure, 默认值为 Always。 (1)Always: Pod 一旦终止运行，则无论容器是如何终止的，Kubelet服务都将重启它。 (2)OnFailure:只有Pod以非零退出码终止时，kubelet才会重启该容器。如果容器正常结束〔退出码为0），则kubelet将不会重启它。 (3)Never:Pod终止后，kubelet将退出码报给Master,不会重该Pod。
spec.nodeSelector	Object	? 定义Node的Label过滤标签,以key:value格式指定
spec.imagePuIlSecrets	Object	?定义pull镜像时便用secret名称，以name:secretkey格式指定
spec.hostNetwork????	Boolean	?定义是否使用主机网络模式，默认值为false。设置true表示使用宿主机网络，不使用docker网桥，同时设置了 true将无法在同一台宿主机上启动第二个副本。

4.2 举个🌰----创建、修改、交互、查询策略

4.2.1 创建资源清单

##清除之前的POD

##删除控制器管理的POD
[root@server1 ~]# kubectl delete deployment.apps mynet

##删除service管理的
[root@server1 ~]# kubectl delete svc mynet

##删除单独创建的的
[root@server1 ~]# kubectl delete pod demo

##查看帮助命令
[root@server1 ~]# kubectl explain pod

##导出现有文件
[root@server1 ~]# kubectl get pod -o yaml |less

##编写一个清单
[root@server1 ~]# mkdir kubemainfest
[root@server1 ~]# cd kubemainfest/
[root@server1 kubemainfest]# ls
[root@server1 kubemainfest]# vim pod.yml
[root@server1 kubemainfest]# cat pod.yml 
apiVersion: v1
kind: Pod
metadata: 
  name: mynet
spec:
  containers:
  - name: mynet1
    image: nginx
[root@server1 kubemainfest]# kubectl get pod

?4.2.2 修改资源清单

##修改时需要先删除之前所产生的资源清单
[root@server1 kubemainfest]# kubectl delete -f pod.yml 

##编写资源清单---交互式不能以这种方式打开
[root@server1 kubemainfest]# vim pod.yml 
apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  containers:
  - name: busybox
    image: busybox

##再次创建
[root@server1 kubemainfest]# kubectl create -f pod.yml

??4.2.3 通过资源清单打开交互式POD

##编写打开交互式的资源清单
[root@server1 kubemainfest]# vim pod.yml 

[root@server1 kubemainfest]# cat pod.yml 
apiVersion: v1
kind: Pod
metadata: 
  name: myapp
spec:
  containers:
  - name: nginx
    image: nginx
  - name: busybox
    image: busybox
    tty: true
    stdin: true
    stdinOnce: true

[root@server1 kubemainfest]# kubectl apply -f pod.yml 

[root@server1 kubemainfest]# kubectl get pod

##交互式访问
[root@server1 kubemainfest]# kubectl attach myapp -c busybox -it

##非交互式访问
[root@server1 kubemainfest]# kubectl exec -it myapp -c nginx -- sh

【注】镜像关闭时，容器会自动重启

4.2.4 查询功能

在进行资源清单编写时，学会使用查询功能，进行逐级查询：

🌰 kubectl explain pod.spec.containers

4.2.5 🌰（端口映射）

##添加资源拉取策略、端口映射策略    

[root@server1 kubemainfest]# vim pod.yml 
[root@server1 kubemainfest]# cat pod.yml 
apiVersion: v1
kind: Pod
metadata: 
  name: myapp
spec:
  containers:
  - name: nginx
    image: nginx
    ports:                ##时间名称
    - name: http
      containerPort: 80    ##容器端口
      hostPort: 80         ##主机端口
  - name: busybox
    image: busybox
    tty: true
    stdin: true
    stdinOnce: true
    imagePullPolicy: IfNotPresent        ##资源存在时，不再拉取

4.2.6🌰（网络及重启）

##使用主机网络模式、重定义启动方式
[root@server1 kubemainfest]# vim pod.yml 
[root@server1 kubemainfest]# cat pod.yml 
apiVersion: v1
kind: Pod
metadata: 
  name: myapp
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - name: http
      hostPort: 80
      containerPort: 80
  hostNetwork: true            ##使用主机网络
  - name: busybox
    image: busybox
    tty: true
    stdin: true
    stdinOnce: true
    imagePullPolicy: IfNotPresent
  restartPolicy: Never        ##定义重启模式

????????主机网络模式：会直接使用宿主机的网络，但是只能有一个不能有副本

????????重启模式：容器在交互时，退出会自动重启容器，当进行大型计算式，只需要计算一次，不需要重启，此时即可设定为该模式。

4.2.7🌰（资源限制及标签）

##资源限制设置、标签设置
[root@server1 kubemainfest]# vim pod.yml 
[root@server1 kubemainfest]# cat pod.yml 
apiVersion: v1
kind: Pod
metadata: 
  name: myapp
spec:
  containers:
  - name: nginx
    image: nginx
    resources:        ##资源限制
      requests:
        memory: 100Mi
        cpu: 0.1
      limits:
        memory: 200Mi
        cpu: 0.2
  nodeSelector:            ##标签设置
    kubernetes.io/hostname: server3

?标签设置时，需要先查看对应node所拥有的的标签：

kubectl get node --show-labels

????????通过Label进行筛选操作：

##通过label进行对应操作
[root@server1 kubemainfest]# vim pod.yml 
[root@server1 kubemainfest]# cat pod.yml 
apiVersion: v1
kind: Pod
metadata: 
  name: myapp
  labels:            ##设置对应的标签
    app: nginx18
spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      requests:
        memory: 100Mi
        cpu: 0.1
      limits:
        memory: 200Mi
        cpu: 0.2
  nodeSelector:
    kubernetes.io/hostname: server3

五、Pod的控制器

5.1 控制器的介绍

????????POD通畅情况下可以分为：自主式POD、控制器管理的POD

????????? 自主式 Pod：Pod 退出后不会被创建

????????? 控制器管理的 Pod：在控制器的生命周期里，始终要维持 Pod 的副本数目

????????关于控制器管理的POD其控制器类型分为：Replication Controller和ReplicaSet、Deployment、DaemonSet、 StatefulSet、Job、CronJob、 HPA（Horizontal Pod Autoscaler）。

5.1.1 Replication Controller和ReplicaSet

????????ReplicaSet 是下一代的 Replication Controller，官方推荐使用ReplicaSet。

??????? ReplicaSet 和 Replication Controller 的唯一区别是选择器的支持，ReplicaSet 支持新的基于集合的选择器需求。ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行。虽然 ReplicaSets 可以独立使用，但今天它主要被Deployments 用作协调 Pod 创建、删除和更新的机制。

5.1.2 Deployment

????????Deployment 为 Pod 和 ReplicaSet 提供了一个申明式的定义方法。典型的应用场景：用来创建Pod和ReplicaSet 、滚动更新和回滚、扩容和缩容、暂停与恢复。

5.1.3 DaemonSet

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

DaemonSet 的典型用法：
????????? 在每个节点上运行集群存储 DaemonSet，例如 glusterd、ceph；

??????? ? 在每个节点上运行日志收集 DaemonSet，例如 fluentd、logstash；

??????? ? 在每个节点上运行监控 DaemonSet，例如 Prometheus Node Exporter、zabbix agent等；

??????? ? 一个简单的用法是在所有的节点上都启动一个 DaemonSet，将被作为每种类型的 daemon 使用；

????????? 一个稍微复杂的用法是单独对每种 daemon 类型使用多个 DaemonSet，但具有不同的标志，并且对不同硬件类型具有不同的内存、CPU 要求。

5.1.4 StatefulSet

????????StatefulSet 是用来管理有状态应用的工作负载 API 对象。实例之间有不对等关系，以及实例对外部数据有依赖关系的应用，称为“有状态应用”；

????????StatefulSet 用来管理 Deployment 和扩展一组 Pod，并且能为这些 Pod 提供序号和唯一性保证。

StatefulSets 对于需要满足以下一个或多个需求的应用程序很有价值：

??????? ? 稳定的、唯一的网络标识符。

????????? 稳定的、持久的存储。

????????? 有序的、优雅的部署和缩放。

????????? 有序的、自动的滚动更新。

5.1.5 Job

????????Job执行批处理任务，仅执行一次任务，保证任务的一个或多个Pod成功结束。

5.1.6 CronJob

????????Cron Job 创建基于时间调度的 Jobs。一个 CronJob 对象就像 crontab (cron table) 文件中的一行，它用 Cron 格式进行编写，并周期性地在给定的调度时间执行 Job。

5.1.7 HPA

????????HPA根据资源利用率自动调整service中Pod数量，实现Pod水平自动缩放。

5.2 举个🌰

5.2.1 replicaset

????????参考官网：https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#replicaset-v1-apps

##ReplicaSet--通过副本数进行拉伸##

##副本数为3
[root@server1 control]# vim rs.yml 
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: replicaset-example
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: nginx
                      

##副本数为10
[root@server1 control]# vim rs.yml 
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: replicaset-example
spec:
  replicas: 10
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: nginx

?【注】回收时，会有优先回收新创建的容器，如果只是单纯的修改镜像，则相同副本不会使用新的镜像，但当进行副本扩容时，则会使用新的副本

?5.2.2 Deployment控制器

????????参考官网：https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#deployment-v1-apps

##控制器部署Deployment清单---单独
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: nginx
        ports:
        - containerPort: 80

##控制器部署Deployment--多个
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-v1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: ngnix
        ports:
        - containerPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-v2
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: nginx:1.18.0
        ports:
        - containerPort: 80

【注】当镜像的版本更改时，会产生新的控制器容器，版本更改回去后，会产生相应的回滚。

?5.2.3 DaemonSet控制器

????????DaemonSet控制器可以每个节点部署一个容器

##DaemonSet控制器

[kubeadm@server1 mainfest]$ vim daemonset.yml
[kubeadm@server1 mainfest]$ cat daemonset.yml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: daemonset-example
  labels:
    k8s-app: zabbix-agent
spec:
  selector:
    matchLabels:
      name: zabbix-agent
  template:
    metadata:
      labels:
        name: zabbix-agent
    spec:
      containers:
      - name: zabbix-agent
        image: zabbix-agent

5.2.4 Job控制器

????????参考官网：https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#job-v1-batch

##JOB控制器
apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
   metadata:
     name: pi
   spec:
     containers:
     - name: pi
       image: perl
       command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
     restartPolicy: Never

##一次性访问，内容可以通过日志查看
[root@server1 control]# kubectl logs pi-nczkf

5.2.5 CronJob 控制器

##CronJob控制器

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: cronjob-example
spec:
  schedule: "* * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: cronjob
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello from k8s cluster
          restartPolicy: OnFailure