K8S集群-Pod资源使用完整版-CSDN博客

本文链接：https://blog.csdn.net/qq_69174109/article/details/143116612

K8S集群-Pod资源使用完整版

一、Pod基础

1.Pod的基本概念

Pod 是 Kubernetes 中的最小可部署单元（最小调度单元），是一个或多个容器的集合。Pod 内的容器共享相同的网络命名空间（IP 地址、端口等）和存储卷，因此它们可以通过 localhost 互相通信。以下是 Pod 的几个关键概念：

单容器和多容器：一个 Pod 可以包含一个或多个容器。单容器 Pod 是最常见的用法，而多容器 Pod 通常用于需要紧密协作的场景，如日志收集、代理服务等。
共享资源：
- 网络：Pod 内的所有容器共享相同的网络命名空间，因此它们的 IP 地址和端口是相同的。
- 存储：Pod 可以通过挂载存储卷来共享数据，Pod 中的每个容器都可以访问这些卷。
生命周期：Pod 是短暂的，Kubernetes 不会修复已崩溃的 Pod，而是通过调度器创建新的 Pod 来替代它们。
亲和性与反亲和性：Kubernetes 提供了 Pod 的调度机制，可以通过配置让 Pod 更倾向于或者避免在某些节点上运行。
Pod 的用途：一般用来运行应用程序的实例。对于多容器的 Pod，各容器通常实现协作功能，确保应用程序的可靠运行。

简单来说，Pod 是 Kubernetes 中的核心单位，用于管理和调度容器应用程序的运行。

2.自主式Pod和控制器管理的Pod

在kubernetes中，按照pod的创建方式可以将其分为两类：

自主式pod：kubernetes直接创建出来的Pod，这种pod删除后就没有了，也不会重建。

它通常通过 kubectl run 或直接使用 Pod 的 YAML 文件创建：

apiVersion: v1
kind: Pod
metadata:
  name: standalone-pod
spec:
  containers:
    - name: my-container
      image: nginx

kubectl apple -f pod.yaml

控制器创建的pod：kubernetes通过控制器创建的pod，这种pod删除了之后还会自动重建。

由 Kubernetes 控制器（如 Deployment、ReplicaSet、DaemonSet、StatefulSet 等）管理的 Pod。控制器根据定义的规则自动管理 Pod 的生命周期：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

kubectl apple -f deployment.yaml

自主式Pod和控制器管理的Pod区别如下：

特性	自主式 Pod	控制器管理的 Pod
管理方式	手动创建和管理	自动化管理，由控制器（如 Deployment）管理
重建和恢复	需要手动重启或重新创建	自动重启和重建，由控制器保证运行
副本数量	只能手动创建多个 Pod	控制器保证副本数量一致
适用场景	短期任务、调试、临时工作	长期运行的服务、生产环境
高可用性	无	有
滚动更新	无	支持

控制器管理的 Pod 更适合生产环境和需要自动化管理的场景，而自主式 Pod 通常用于调试、测试或一次性任务。

二、Pod资源创建

1.安装补全命令和参数工具：

yum -y install bash-completion

# 配置为 kubectl 命令启用 Bash 自动补全功能
source /usr/share/bash-completion/bash_completion
kubectl print completion bash 
kubectl completion bash > ~/.kube/completion.bash.inc
source '/root/.kube/completion.bash.inc'

官网地址：kubectl 快速参考 | Kubernetes 详细内容请前往官网查看。

2.快速查询资源的详细信息和字段解释

kubectl explain 命令用于查看 Kubernetes 资源的详细信息和字段解释。你可以通过它来了解每个资源的结构以及各字段的作用，尤其在编写 YAML 配置文件时非常有用。

使用方法：

kubectl explain <资源类型>：查看资源的整体描述。
kubectl explain <资源类型>.<字段>：查看资源中特定字段的解释。

例如：

kubectl explain pods
kubectl explain pods.spec.containers

第一条命令是查看 Kubernetes 中 Pod 资源的详细说明，展示 Pod 的结构、用途以及每个字段的解释。
第二条命令进一步查看 Pod 中 spec 下 containers 字段的详细说明。它显示了 containers 内可用的子字段（如 name, image, ports 等）

3.常见字段的说明

apiVersion：指定 Kubernetes API 的版本
- v1、apps/v1 等
kind：定义资源的类型
- Pod、Deployment、Service 等
metadata：用于存储资源的元数据信息的部分，包含了一些对资源进行标识、管理和组织的字段。
- name：资源的名称，必须是唯一的，便于资源的标识。
- namespace：资源所属的命名空间，用于逻辑分组。
- labels：键值对，用于标记资源，方便选择器进行筛选。
- annotations：用于存储非标识信息的键值对，用于记录版本号和时间信息，方便后续管理和维护。
- uid：资源的唯一标识符，由系统自动生成。
spec：定义资源的期望状态的字段，描述了资源在集群中应该如何表现。
- containers：定义 Pod 中运行的容器列表，包含每个容器的镜像、名称、端口等。
  - name：容器名称，必须唯一。
  - image：容器使用的镜像（例如 nginx:latest）。
  - ports：定义容器开放的端口。
    - containerPort：容器内开放的端口号。
    - protocol：协议类型，常用值有 TCP 和 UDP。
  - env：环境变量列表。
    - name：环境变量名称。
    - value：环境变量的值。
  - resources：定义容器的资源需求（CPU、内存等）。
    - limits：资源限制，如 CPU、内存的最大使用量。
    - requests：资源请求，即容器启动时最少需要的资源量。
- volumes：定义 Pod 可能使用的存储卷。
  - name：卷的名称。
  - persistentVolumeClaim：引用已存在的 PVC。
  - hostPath：使用主机路径作为卷。
- nodeName：指定 Pod 应该调度到的节点名称。
- restartPolicy：定义容器的重启策略，如 Always、OnFailure 等。
  - 常用值：Always, OnFailure, Never。

4.查看Pod的详细信息

如果Pod拉失败或者想了解Pod的内容，可以执行如下命令进行查看：

kubectl describe pod <pod-name> # 输出Pod中所有资源的详细信息
kubectl describe pod <pod-name> -c <container-name> # 输出Pod中指定资源的详细信息

kubectl logs <pod-name> -c <container-name>  # 查看特定容器的日志：
kubectl logs -f <pod-name> # 查看实时的日志

5.Pod资源的删除

方法一：

kubectl delete pod <pod-name>
kubectl delete pod <pod-name> --grace-period=0 --force  # 强制删除Pod

方法二：

kubectl delete -f <pod.yaml> --grace-period=0 --force   # 强制删除Pod

6.进入容器

kubectl exec -ti <pod-name> -c <container-name> -- /bin/sh

三、亲和性和反亲和性

“亲和性”（Affinity）和“反亲和性”（Anti-affinity）通常用于计算机集群管理，特别是在云计算和容器编排系统（如 Kubernetes）中，用来控制应用程序或服务的部署策略。

1.亲和性（Affinity）

亲和性表示的是将某些工作负载（如 Pod、虚拟机）安排在一起，或者靠近特定的资源上。通过亲和性规则，可以指导系统将相关的工作负载尽量调度到相同的节点或同一组资源上，达到资源优化或提高性能的效果。

例子：

节点亲和性（Node Affinity）：你可以指定 Pod 只在具备特定标签的节点上运行，比如要求某个应用程序只运行在带有高性能 GPU 的节点上。
Pod 间亲和性（Pod Affinity）：要求一些 Pod 尽量部署在相同的节点上，例如为了减少网络延迟，将相关的服务 Pod 部署在同一个节点上。

2.反亲和性（Anti-affinity）

反亲和性表示避免将某些工作负载安排在同一资源或同一区域上。反亲和性规则用于确保高可用性和故障隔离，避免在同一硬件故障或网络分区时导致多个实例同时宕机。

例子：

Pod 间反亲和性（Pod Anti-affinity）：你可以要求同一类型的多个副本 Pod 不在同一节点上运行，以防止单点故障。如果一个节点崩溃，其他节点上的副本仍能正常运行，保证服务的高可用性。
区域反亲和性（Zone Anti-affinity）：你可以配置应用程序的副本分布在不同的可用区，以避免整个可用区的故障影响所有副本。

3.应用场景：

亲和性：例如在一个数据处理系统中，多个应用模块之间有大量的数据交互，可以使用亲和性将它们部署在同一节点上以减少通信延迟。
反亲和性：例如你运行一个有多个副本的服务，你可能希望这些副本部署在不同的节点或不同的机架上，来减少硬件或网络故障的影响。

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: rs-nginx
  namespace: test
  labels:
    app: rs-nginx
spec:
  selector:
    matchLabels:
      app: rs-nginx
  template:
    metadata:
      labels:
        app: rs-nginx
  spec:
    affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
            - matchExpressions:
                - key: kubernetes.io/hostname
                  operator: NotIn
                  values: 
                    - node01
                    - node02
                    - worker03                                                                               
    containers:
      - name: nginx
        image: nginx:1.21.1
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        command:
          - "/bin/bash"
          - "-c"
          - "sleep 300"

1. `nodeAffinity`

这是 Kubernetes 中的节点亲和性（Node Affinity）设置，用于指定 Pod 在调度时应该运行在哪些节点上，或者避免在哪些节点上运行。

2. `requiredDuringSchedulingIgnoredDuringExecution`

这个字段表示强制性的亲和性规则，也就是说，在 Pod 调度时，必须满足这个规则才可以被调度到某个节点上。如果没有满足该规则的节点，Pod 将无法被调度成功。

IgnoredDuringExecution: 这个规则只在 Pod 调度的时候生效，如果调度成功后，节点状态发生变化（比如节点标签被更改），Pod 仍然会继续运行，不会被强制驱逐。

3. `nodeSelectorTerms`

这是一个节点选择器条件的列表，其中包含多个匹配表达式。每个 nodeSelectorTerms 可以包含多个 matchExpressions，如果其中任何一个 nodeSelectorTerms 的条件满足，节点就符合调度要求。

4. `matchExpressions`

这是用来定义如何匹配节点的条件表达式，具体到某个节点上的标签。

key: kubernetes.io/hostname：这个键表示要匹配节点的 hostname，Kubernetes 会给每个节点分配一个主机名标签。
operator: NotIn：这个操作符表示不要把 Pod 调度到值列表中的节点。NotIn 是 Kubernetes 支持的运算符之一，表示 “不在” 列表中的节点。
values：这里的 values 包含了 node01、node02 和 worker03，意思是 Pod 不会被调度到这些节点上。Kubernetes 会在调度时选择其他不在这个列表中的节点来运行 Pod。

四、污点和容忍度

在 Kubernetes 中，容忍度（Tolerations） 是一种机制，允许 Pod 被调度到带有某些 污点（Taints） 的节点上。通过容忍度，Kubernetes 可以控制哪些 Pod 可以容忍特定的节点污点，从而让这些 Pod 能够被调度到有污点的节点上。

背景知识：污点（Taints）

污点（Taints）：是作用在节点（Node）上的一种标记，用来避免某些 Pod 被调度到这些节点上。通过污点，你可以告诉 Kubernetes 不允许（或限制）Pod 被调度到带有特定污点的节点上。
- 例如，如果你有一台节点用于专门的工作负载，你可以给这个节点打上污点，阻止一般的 Pod 被调度到这个节点上。

容忍度（Tolerations）的作用

容忍度 是 Pod 的属性，表示 Pod 能够容忍某些节点的污点，并且可以调度到那些带有相应污点的节点上运行。

通过容忍度，Pod 和节点之间形成了一种配合关系：

污点用来阻止节点上运行不合适的 Pod。
容忍度 允许特定 Pod 被调度到带有特定污点的节点。

例子：污点和容忍度如何配合

污点示例：假设某个节点 node1 上打了一个污点，如下所示：
```
kubectl taint nodes node1 key=value:NoSchedule
```
这表示任何没有相应容忍度的 Pod 都不能调度到 node1 节点上，因为 NoSchedule 表示禁止调度。
容忍度示例：如果一个 Pod 想要运行在 node1 上，就必须具有对应的容忍度，配置类似如下：
```
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: nginx
    image: nginx
  tolerations:
  - key: "key"
    operator: "Equal"
    value: "value"
    effect: "NoSchedule"
```
这里定义的 tolerations 与 node1 的污点相匹配，表示该 Pod 可以容忍 node1 上的污点，因此 Kubernetes 可以将该 Pod 调度到 node1 上运行。

容忍度的字段解释

key：污点的键。
operator：操作符，通常为 Equal，用于匹配污点的值。
value：污点的值。
effect：污点的影响，常见的有以下三种：
- NoSchedule：如果 Pod 没有相应的容忍度，不允许调度到带有该污点的节点。
- PreferNoSchedule：如果可能，Kubernetes 会尽量避免将没有相应容忍度的 Pod 调度到带有该污点的节点，但不是强制性的。
- NoExecute：如果 Pod 没有相应的容忍度，Kubernetes 会驱逐已经运行在带有该污点的节点上的 Pod。

使用场景

隔离特定节点：当你有某些节点专门用于运行特定的工作负载（例如高性能计算任务、存储密集型任务），可以通过污点标记这些节点，然后让相关的 Pod 添加相应的容忍度，这样其他不需要使用这些节点的 Pod 就不会被调度到这些节点上。
节点维护或故障：如果某些节点需要维护或检测到硬件故障，可以通过添加污点来阻止新的 Pod 被调度到这些节点，已有的 Pod 如果没有容忍度，也可以被驱逐。
资源分配优化：污点和容忍度可以帮助你对集群中的节点和工作负载进行更精细的调度控制，确保重要的任务能够被优先调度到指定的节点上，而其他低优先级的任务则被限制。

五、污点 vs 亲和性：总结

特性	污点和容忍度	亲和性
作用对象	节点上的污点	Pod 上的亲和性规则
机制	排除机制，阻止不符合条件的 Pod	引导机制，引导 Pod 去特定节点
强制性	默认是强制的（如 `NoSchedule`）	可以是强制的或软性的
使用场景	防止 Pod 调度到不合适的节点	让 Pod 优先调度到合适的节点
典型场景	防止低优先级任务运行在专用节点上	确保高优先级任务运行在特定节点上