Kubernetes Pod（调度）和Pod控制器

第一部分：Pod

在 Kubernetes 中，Pod 代表的是集群上处于运行状态的一组【容器】的集合

创建并运行Pod（不推荐直接通过Pod运行容器）

kubectl run <Pod名称> --image=<镜像名称> --port=<端口> --namespace=<命名空间> # 创建并运行一个pod（不推荐直接运行Pod）
kubectl get pod -n <命名空间> -o wide # 查询所有Pod的基本信息
kubectl describe pod <Pod名称> -n <命名空间> # 查看Pod的详细信息
kubectl logs -f <Pod名称> -n <命名空间> # 查看pod的日志
kubectl delete pod <Pod名称> -n <命名空间> --force --grace-period=0 # 强制删除pod

• 通过Pod直接运行容器，会有以下缺点

1、Pod重建后IP会变化，外部无法得知最新的IP
2、业务应用无法启动多个副本
3、运行业务Pod的某个节点挂了，无法实现故障转移、恢复

第二部分：Pod 调度

kube-scheduler 是 Kubernetes 集群的默认调度器，并且是集群 控制面 的一部分。在一个集群中，满足一个 Pod 调度请求的所有节点称之为 可调度节点。 如果没有任何一个节点能满足 Pod 的资源请求， 那么这个 Pod 将一直停留在未调度状态直到调度器能够找到合适的 Node

1、节点标签

与其它的 Kubernetes 对象类似，节点也是有标签的，我们可以手动地为节点添加标签以便指定相关节点在特定的节点上运行

• 设置节点标签

# kubectl label nodes <节点名称> <自定义标签明key>=<自定义标签value> --overwrite # 设置节点标签
kubectl label nodes node1 label-key=label-value --overwrite

# kubectl label nodes <节点名称> <自定义标签明key>- # 删除节点标签
kubectl label nodes node1 label-key-

• 查询节点标签

kubectl get nodes --show-labels

• 将Pod调度到指定节点上

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  nodeName: <节点名称>

• 将Pod调度到含有指定标签的节点上

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  nodeSelector:
    <自定义标签明key>: <自定义标签明value>

2、节点的亲和性与反亲和性

节点亲和性功能类似于 nodeSelector 字段，但它的表达能力更强，并且允许你指定软规则

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      # 只有在规则被满足的时候才能执行调度。类似于nodeSelector，但语法表达能力更强:
      # 节点必须包含一个键名为 label-key 的标签，并且该标签的取值必须为 label-value-1 或 label-value-2
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: <label-key>
            operator: In
            values:
            - <label-value-1>
            - <label-value-2>
      # 尝试寻找满足对应规则的节点，如果找不到匹配的节点，调度器仍然会调度该 Pod
      # 节点最好具有一个键名为 label-key 且取值为 label-value-1 的标签
      # 如果2个节点都满足，则会考察各个节点的 weight 取值，并将该权重值添加到节点的其他得分值之上
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: <label-key-1>
            operator: In
            values:
            - <label-value-1>
     - weight: 2
        preference:
          matchExpressions:
          - key: <label-key-2>
            operator: In
            values:
            - <label-value-2>

常用的 operator 正向逻辑操作符有： In、NotIn、Exists、DoesNotExist、Gt 和 Lt
常用的 operator 反向向逻辑操作符有：NotIn 和 DoesNotExist

3、Pod的亲和性与反亲和性

Pod 亲和性和反亲和性都需要相当的计算量，因此在大规模集群中会显著降低调度速度。所以不建议在包含数百个节点的集群中使用

4、节点的污点和容忍度

节点亲和性是 Pod 的一种属性，它使 Pod 被吸引到一类特定的节点 。污点（Taint）则相反，它使节点能够排斥一类特定的 Pod。容忍度（Toleration） 是应用于 Pod 上的，容忍度允许调度器调度带有对应污点的 Pod（容忍度允许调度但并不保证调度）

• 污点类型

PreferNoSchedule: 避免把Pod调度到设置了污点的node上，除非没有node可以调度
NoSchedule：避免把Pod调度到设置了污点的node上，但是不会影响当前node上已经存在的Pod
NoExecute：避免把Pod调度到设置了污点的node上，同时也会将当前node上已经存在的Pod驱离

• 设置节点的污点

# kubectl taint nodes <节点名称> <污点key>=<污点value>:<污点类型>[PreferNoSchedule|NoSchedule|NoExecute] # 为指定节点设置污点

# kubectl taint nodes <节点名称> <污点key>=<污点value>:<污点类型>[PreferNoSchedule|NoSchedule|NoExecute]- # 为指定节点去除污点
# kubectl taint nodes <节点名称> <污点key>- # 去除所有节点上的污点

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  tolerations:
  - key: "<要容忍的污点的key>"
    operator: "Exists|Equal"
    value: "<容忍的污点的value>"
    effect: "这里必须要和标记的污点的规则相同[PreferNoSchedule|NoSchedule|NoExecute]"
    tolerationSeconds: 3600

第四部分：Pod控制器

当 Pod 所在的 节点 出现故障时， 所有该节点上的 Pod 的状态都会变成失败（Kubernetes 将这类失败视为最终状态），即使该节点恢复正常运行了，我们也需要重新创建新的 Pod 才能恢复应用。为了减轻用户的使用负担，通常不需要用户直接管理每个 Pod，而是通过使用【Pod控制器】来帮助用户管理 Pod，确保Pod符合预期的状态，当Pod资源出现故障时，会尝试对Pod进行重启或重建

• 【通过命令直接删除Pod,Pod会在控制器的作用下重新创建并启动】
• 【通过命令直接删除Deployment,该控制器下的所有Pod都会被删除】
• 【通过命令直接删除NameSpace,该命名空间下的所有Deployment、Pod都会被删除】

1、ReplicaSet 和 Deployment 控制器

ReplicaSet: 代用户创建指定数量的pod副本，确保pod副本数量符合预期状态，并且支持滚动式自动扩容和缩容功能
Deployment：工作在ReplicaSet之上，用于管理无状态应用。支持滚动更新和回滚功能，提供声明式配置。 因此建议你在需要 ReplicaSet 时使用 Deployment

## 创建Deployment（命令）
kubectl create deployment <deployment名称> --image=<镜像> -n <命名空间> # 创建deployment，会自动创建相应的Pod
kubectl scale deployment <deployment名称> --replicas=2 -n <命名空间> # 将deployment下的pod扩容到2个
kubectl describe deployment <deployment名称> -n <命名空间> # 查看deployment的详细信息
kubectl delete deployment <deployment名称> -n <命名空间> # 删除deployment，级联删除其下的所有pod

创建命名空间

kubectl create ns dev && kubectl get ns

基于 Nginx 的 Deployment 示例

vi deployment-nginx.yaml # 编辑yaml文件

apiVersion: apps/v1
kind: Deployment
metadata:
   namespace: dev
   name: nginx
   labels: 
      app: nginx
spec: 
  selector: # 标签选择器，指定当前控制器管理哪些Pod
    matchLabels:
      app: nginx
    matchExpressions:
      - { key: app, operator: In, values: [nginx] }
  replicas: 2 # 初始化Pod副本数量
  template: # 当Pod副本数量不足时，会根据下面的模板创建Pod副本
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

kubectl apply -f deployment-nginx.yaml --record # 创建deployment，会自动创建相应的Pod

kubectl delete -f deployment-nginx.yaml # 删除 deployment

查看 dev 空间下的 对象

kubectl get deployment,replicaSet,pod  -n dev -o wide --show-labels

• deployment 字段描述

NAME Deployment 名称
READY 显示应用程序的可用副本数，模式是“就绪个数/期望个数”
UP-TO-DATE 显示为了达到期望状态已经更新的副本数
AVAILABLE 显示应用可供用户使用的副本数
AGE 显示应用程序运行的时间

• 如果Pod没有创建成功，则需要查看指定 pod 的启动日志

kubectl describe -n dev pod nginx-85996f8dbd-2qscb

注意：如果出现“Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox “908c7e8aafdd9f2aa43c0967f06b71ccd5756ea58590aadcf4f19695136799fd”: plugin type=“calico” failed (add): error getting ClusterInformation: connection is unauthorized: Unauthorized”, 需要手动删除指定节点的calico pod 即可：
kubectl get deployment,pods,service -n kube-system -o wide
kubectl delete pod calico-node-4kdl4 -n kube-system --force --grace-period=0

调整 Deployment 下的 Pod 中容器 对系统资源使用的上限

# kubectl set resources deployment/<deployment>- -c=<容器名称> --limits=cpu=200m,memory=512Mi
kubectl set resources deployment/deployment -c=nginx --limits=cpu=200m,memory=512Mi

调整 Deployment 下的 Pod 副本数量

# kubectl scale deploy <deployment控制器名称> --replicas=<副本数量> -n dev
kubectl scale deploy nginx --replicas=3 -n dev # 手动扩容到3个副本

# kubectl autoscale deployment/<deployment控制器名称> --min=<Pod副本下限> --max=<Pod副本上限> --cpu-percent=<CPU使用率> -n dev 
# 默认1个副本，单CPU使用率达到80%时自动扩容，做多支持3个副本
kubectl autoscale deployment/nginx --min=1 --max=3 --cpu-percent=80 -n dev

调整 Deployment 下 Pod 镜像版本

# kubectl set image deploy <控制器名称> <容器名称>=<镜像> -n <命名空间>
# kubectl set image deploy nginx nginx=nginx:1.14.1 -n dev && kubectl get deployment -n dev -o wide 
kubectl set image deploy nginx nginx=nginx:1.17.2 -n dev && kubectl get deployment -n dev -o wide 
# kubectl rollout status deployment/nginx -n dev # 检查 deployment 上线状态

注意：控制器nginx下包含了2个replicaset（nginx-7bf996d8f【处于运行状态】、nginx-85996f8dbd【可用于版本回滚】），replicaset（nginx-7bf996d8f）下包含了2个Pod副本（nginx-7bf996d8f-9jfg6、nginx-7bf996d8f-bcccc、nginx-7bf996d8f-cdvjt）

回滚到指定版本

kubectl get rs -n dev # 查看 Deployment 创建 ReplicaSet 的历史记录
# 
NAME               DESIRED   CURRENT   READY   AGE
nginx-7bf996d8f    3         3         3       4m7s
nginx-85996f8dbd   0         0         0       28m

# kubectl rollout undo deployment/<deployment名称> --to-revision=<回退的版本层级> -n <命名空间>
# 1表示回退到 nginx-85996f8dbd
# 2表示回退到 nginx-7bf996d8f
kubectl rollout undo deployment/nginx --to-revision=1 -n dev && kubectl get deployment,replicaSet,pod  -n dev -o wide

2、StatefulSet 控制器

1、StatefulSet 适合用来管理有状态的应用，除了可以管理 Pod 集合的部署和扩缩，还可以为这些 Pod 提供持久存储和持久标识符
2、StatefulSet 和 Deployment 类似，StatefulSet 管理基于相同容器规约的一组 Pod。但和 Deployment 不同的是，StatefulSet 为它们的每个 Pod 维护了一个有粘性的 ID。这些 Pod 是基于相同的规约来创建的， 但是不能相互替换：无论怎么调度，每个 Pod 都有一个永久不变的 ID

StatefulSet 对于需要满足以下一个或多个需求的应用程序很有用：
1、稳定的、唯一的网络标识符
2、稳定的、持久的存储
3、有序的、优雅的部署和扩缩
4、有序的、自动的滚动更新

3、DaemonSet 控制器

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

DaemonSet 的一些典型用法：
1、在每个节点上运行集群守护进程
2、在每个节点上运行日志收集守护进程
3、在每个节点上运行监控守护进程

4、Job

创建出来的Pod只要任务完成就立即退出，适用于批量处理一次性任务

5、CronJob

创建出来的Pod会周期性的执行，适用于执行周期性的任务。以Job控制器为其管控对象，并借助它管理Pod资源对象（在特定的时间点反复的运行Job任务）