小编点评

**Pod 是 Kubernetes 的重要概念** Pod 是一个容器化应用的最小单元，它是一个独立的容器，它可以运行一个应用程序或服务。 **Pod 的关键特征：** * **容器化：** Pod 是一个独立的容器，它可以运行一个应用程序或服务。 * **资源隔离：** Pod 拥有独立的资源，不会与其他 Pod 相竞争。 * **共享网络：** Pod 可以访问所有网络资源，包括 CPU、内存、网络等。 * **独立调度：** Pod 可以独立调度到不同的节点。 * **可扩展性：** Pod 可以扩展到任何支持容器运行的节点。 **Pod 的用途：** * **应用程序容器：** Pod 可以用于运行应用程序，如 web 应用程序、数据库等。 * **服务容器：** Pod 可以用于运行服务，如 API 服务、消息队列等。 * **网络容器：** Pod 可以用于创建网络容器，以实现网络共享。 * **存储容器：** Pod 可以用于创建存储容器，以存储数据。 **Pod 的生命周期：** Pod 的生命周期可以分为以下几个阶段： * **创建阶段：** 在 Kubernetes 中创建一个 Pod。 * **运行阶段：** 创建的 Pod 在 Kubernetes 中运行。 * **停止阶段：** Pod 被删除。 * **重启阶段：** 当 Pod 停止运行时，它会被重启。 **Pod 的资源限制：** Pod 的资源限制可以用于控制每个 Pod 的资源使用量，例如 CPU、内存等。 **Pod 的健康检查：** Pod 的健康检查可以用于确保 Pod 的正常运行。常见的健康检查方法包括： * **HTTP 检查：** Pod 可以使用 HTTP 连接到容器上的端口，检查容器是否运行正常。 * **Shell 命令：** Pod 可以使用 Shell 命令来检查容器的状态，例如检查 CPU 使用率、内存使用率等。 * **TCP Socket 建立：** Pod 可以与容器上的 TCP 服务建立连接，检查容器是否正常运行。

正文

Pod 是 k8s 系统中可以创建和管理的最小单元， 是资源对象模型中由用户创建或部署的最小资源对象模型， 也是在 k8s 上运行容器化应用的资源对象， 其他的资源对象都是用来支撑或者扩展 Pod 对象功能的， 比如控制器对象是用来管控 Pod 对象的， Service 或者Ingress 资源对象是用来暴露 Pod 引用对象的， PersistentVolume 资源对象是用来为 Pod提供存储等等， k8s 不会直接处理容器， 而是 Pod， Pod 是由一个或多个 container 组成Pod 是 Kubernetes 的最重要概念， 每一个 Pod 都有一个特殊的被称为” 根容器“的 Pause容器。 Pause 容器对应的镜 像属于 Kubernetes 平台的一部分， 除了 Pause 容器， 每个 Pod还包含一个或多个紧密相关的用户业务容器

• 最小部署单元
• 是一组容器的集合
• 一个Pod 中的容器，是共享网络的
• 生命周期是短暂的，重启后数据丢失，所以需要（nfs)

Pod 存在的意义

• 创建容器使用 Docker, 一个 Docker 对应一个容器，一个容器有一个进程，一个容器运行一个应用程序(多个不方便管理) docker ps -a
• Pod是多进程设计：里面可以包括多个容器，一个容器运行一个应用程序，因此Pod可以运行多个应用程序
• 为了亲密性应用：两个应用之间进行交互，网络之间调用，两个应用需要频繁调用

Pod 实现机制

容器本身之间相互隔离，通过 namespace、group

• 共享网络，通过Pause容器，把其它业务容器加入到 Pause 容器里面，让所有业务容器在同一个 namespace ，实现网络共享
  

• 共享存储，引入数据卷Volumn，使用数据卷进行持久化存储（日志数据，业务数据），当一个节点挂了，漂移到另一个节点，数据不丢失
  

Pod 拉取策略

[root@k8smaster ~]# kubectl edit deployment/javademo1
.....
 spec:
      containers:
      - image: registry.cn-shanghai.aliyuncs.com/vipsoft/vipsoft:4.3
        imagePullPolicy: IfNotPresent
        name: vipsoft
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
.....

• imagePullPolicy: IfNotPresent
• Always ：总是拉取 pull
• IfNotPresent: 默认值,本地有则使用本地镜像,不拉取
• Never：只使用本地镜像，从不拉取

Pod 资源限制

由Docker限制，非Pod去限制

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: db
    image: mysql
    env:
    - name: MYSQL ROOT PASSWORD
      value: "password"
      resources:
      	# 调度需要至少这么大
        requests:
          memory: "64Mi"
          # 1核=1000m，250m=0.25核
          cpu:“250m”
        # 最大不超过
        limits:
          memory: ”128Mi"
          cpu:"500m"

Pod和Container的资源请求和限制：
spec.containers[].resources.requests.cpu
spec.containers[].resources.requests.memory
spec.containers[].resources.limits.cpu
spec.containers[].resources.limits.memory

Pod 重启机制

apiVersion: v1
kind: Pod
metadata:
  name: dns-test
spec:
  containers:
  - name: busybox
    image: busybox:1.28.4
    args:
    - /bin/sh
	- -C
	- sleep 36000
  restartPolicy:Never

restartPolicy

• Always:当容器终止退出后，总是重启容器，默认策略。
• OnFailure:当容器异常退出（退出状态码非0）时，才重启容器。
• Never:当容器终止退出，从不重启容器。

Pod 健康检查

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec
  labels:
    test: liveness
spec:
  containers:			#容器
  - name: liveness		#容器名字
    image: busybox		#镜像
    args:			#args
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:		#存活检查
      exec:
        command:	#命令
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5	 # 延迟探测时间
      periodSeconds: 5		 # 执行探测频率

• livenessProbe (存活检查)
  如果检查失败，将kill杀死容器，根据Pod的 restartPolicy 来操作
• readinessProbe (就绪检查)
  如果检查失败，K8S会把Pod从Service endpoints 中剔除。
  Probe 支持以下三种检查方法：
• httpGet
  发送HTTP请求，返回200~400范围状态码为成功。
• exec
  执行 Shell 命令返回状态码是0为成功。
• tcpSocket
  发起TCP Socket 建立成功。

Pod 调度策略

创建Pod流程

影响调度因素

• Pod 资源限制对Pod调度有影响，根据 Request 找到足够 Node 节点进行调试
• 节点选择器标签，nodeSelector.env_role:dev，影响
  

kubectl label node node1 env_role=dev

• 节点的亲和性，nodeAffinity 和 nodeSelector 基本一样，根据节点上标签约束来对Pod调度到哪些节点上，功能更强大，符合条件就用，不符合也能用，支持各种操作符
  （1） 硬亲和性：约束条件必须满足
  （2） 软亲和性：尝试满足，不保证

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinityspec:
spec:
  affinity:
    nodeAffinity:
      # 硬亲和性
      requiredDuringschedulingIgnoredDuringExecution:
        nodeSelectorTerms :
        - matchExpressions :
          - key: env 
          roleoperator: In # NotIn Exists Gt Lt DoesNotExists
          values: 
          - dev
          - test
      preferredDuringschedulingIgnoredDuringExecution:
      # 软亲和性
      - weiqht:1
        preference:
           matchExpressions :
           - key: group
           operator: In
           values:
           - otherprod
  containers:
  - name: webdemo
    image: nginx

污点和污点容忍

nodeSelector、nodeAffinity: Pod调度到某些节点上，Pod 属性，高度时实现
Taint 污点：节点不做普通分配调试，是节点属性

场景

• 专用节点

• 配置特定硬件节点

• 基于 Taint 驱逐

演示

# 查看当前节点的污点
[root@k8smaster ~]# kubectl describe node k8snode3 | grep Taint
# 添加污点 kubectl taint node 节点名称 key=value:污点值-
[root@k8smaster ~]# kubectl taint node k8snode1 key=value:NoSchedule
# 删除污点 kubectl taint node 节点名称 key=value:污点值-
[root@k8smaster ~]# kubectl taint node k8snode1 env_role:NoSchedule-

污点值

• NoSchedule: 一定不被调度
• PreferNoSchedule：尽量不被调度
• NoExecute：不会调试，并且还会驱逐Node已有 Pod

污点容忍

加上 tolerations