Kubernetes 中 Pod 和 Node 的关系详解

CopyLower

于 2024-10-01 14:08:02 发布

阅读量629

点赞数 6

分类专栏： Java 学习云计算文章标签： kubernetes 容器云原生

本文链接：https://blog.csdn.net/lssffy/article/details/142620690

版权

学习同时被 3 个专栏收录

234 篇文章 8 订阅

订阅专栏

Java

127 篇文章 2 订阅

订阅专栏

云计算

13 篇文章 0 订阅

订阅专栏

引言

Kubernetes（K8s）是目前最流行的容器编排平台之一，能够自动化管理和调度容器化应用。在 Kubernetes 的架构中，Pod 和 Node 是两个非常重要的概念。Pod 是 Kubernetes 中最小的可部署单元，而 Node 则是 Kubernetes 集群中的工作节点。理解 Pod 和 Node 的关系，有助于开发者在设计、部署和管理 K8s 应用时更好地进行资源调度和优化。

本文将深入讲解 Pod 和 Node 的概念、它们的关系，以及 Kubernetes 如何通过调度器和控制器来管理这两者的交互。文章会结合图文和代码示例，帮助开发者全面理解 Pod 和 Node 之间的协作关系。

第一部分：Kubernetes 架构基础

1.1 什么是 Kubernetes？

Kubernetes 是一个开源的容器编排平台，能够自动化地管理容器化应用的部署、扩展和运维。它的核心目标是简化大规模容器的管理，提供弹性、负载均衡、自动恢复等功能。

Kubernetes 的架构主要包括以下组件：

Master 节点：
- API Server：负责处理所有来自客户端和其他组件的 REST 请求。
- Scheduler（调度器）：决定 Pod 应该调度到哪个 Node 上运行。
- Controller Manager（控制器管理器）：负责集群中各个控制器的管理，比如 Pod 副本的维持、节点故障处理等。
- etcd：分布式键值存储，用于保存集群的状态数据。
Node（工作节点）：
- Kubelet：每个 Node 上运行的守护进程，负责管理 Pod 和容器的生命周期。
- Kube-Proxy：负责 Pod 间的网络代理和负载均衡。
- 容器运行时：如 Docker 或 containerd，负责拉取镜像和运行容器。
Pod：Kubernetes 中的最小部署单元，包含一个或多个容器。

1.2 什么是 Pod？

Pod 是 Kubernetes 中的最小可部署单元，一个 Pod 可以包含一个或多个紧密相关的容器。Pod 中的容器共享同一个网络命名空间（IP 地址和端口空间）和存储卷。Pod 的生命周期由 Kubernetes 控制，它能够通过控制器（如 Deployment、DaemonSet 等）来管理。

Pod 的主要特点：

每个 Pod 具有唯一的 IP 地址。
Pod 中的所有容器共享同一个网络和存储。
Pod 的生命周期短暂，可以随着调度和资源变动进行自动重建或销毁。

1.3 什么是 Node？

Node 是 Kubernetes 集群中的工作节点，负责运行 Pod。一个 Node 通常是一台物理服务器或虚拟机，Kubernetes 集群可以由多台 Node 组成。每个 Node 运行必要的 Kubernetes 组件，包括 kubelet、kube-proxy 和容器运行时（如 Docker）。

Node 的主要功能：

运行 Pod 并管理它们的生命周期。
监控节点的健康状况，并报告给 Kubernetes 控制平面。
提供网络代理服务，确保 Pod 能够彼此通信。

1.4 Pod 和 Node 的角色

在 Kubernetes 中，Node 是运行 Pod 的宿主环境，Node 提供了计算、存储和网络资源，而 Pod 则是 Kubernetes 负责调度和管理的工作单元。因此，Pod 和 Node 之间的关系可以看作是任务和工作者的关系：Pod 是要完成的任务，而 Node 是执行这些任务的工作者。

第二部分：Pod 和 Node 的关系

2.1 Pod 调度到 Node

Pod 的调度是 Kubernetes 中的一个核心功能。Kubernetes 的调度器根据资源需求、节点的可用性和调度策略等多个因素，将 Pod 分配到某个合适的 Node 上。Pod 在被调度后，会在该 Node 上启动和运行，直到 Pod 结束或被迁移。

调度的过程包括以下几个步骤：

创建 Pod：用户通过 YAML 配置文件或 API 创建 Pod，Pod 进入 Pending 状态。
调度器决定 Pod 的目标 Node：Kubernetes 调度器会根据 Node 的资源使用情况、调度策略等，将 Pod 分配到某个 Node 上。
Kubelet 启动 Pod：Kubelet 负责在指定的 Node 上启动和管理 Pod 的生命周期。
Pod 运行：Pod 被调度到某个 Node 后，Kubelet 通过容器运行时（如 Docker）启动容器。

2.1.1 Pod 调度示例

一个简单的 Pod 调度 YAML 文件如下：

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: nginx-container
    image: nginx
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

在这个配置文件中，example-pod 定义了一个包含 Nginx 容器的 Pod。Pod 被创建后，Kubernetes 调度器会根据 resources 中定义的资源请求和限制（如内存和 CPU），决定将 Pod 调度到哪个 Node 上。

2.2 Node 为 Pod 提供的资源

Node 为 Pod 提供了运行时所需的所有资源，包括 CPU、内存、存储和网络。每个 Node 都有一定的资源容量，当一个 Pod 被调度到某个 Node 上时，该 Node 必须为 Pod 分配足够的资源。

资源包括：

计算资源（CPU 和内存）：Node 为 Pod 分配 CPU 和内存。Pod 的资源请求和限制由 requests 和 limits 字段定义。
存储资源：Pod 可以使用持久化存储（如 PersistentVolume）或临时存储（如 emptyDir），这些存储资源由 Node 提供。
网络资源：Node 提供网络代理服务，确保 Pod 能够与其他 Pod 和外部服务通信。

2.3 Pod 在 Node 上的生命周期

Pod 在 Node 上的生命周期主要包括以下阶段：

Pending：Pod 已创建，但还未被调度到任何 Node。
Running：Pod 已被调度到某个 Node，且所有容器都已经启动。
Succeeded：Pod 中的所有容器都正常结束（容器退出码为 0）。
Failed：Pod 中至少有一个容器非正常结束（容器退出码不为 0）。
Unknown：Node 无法联系到 Pod 的状态。

在 Pod 的整个生命周期中，Kubelet 负责监控 Pod 的健康状态，并根据需要对 Pod 进行重启、迁移等操作。

第三部分：Pod 与 Node 之间的调度策略

3.1 Pod 的调度决策

Kubernetes 调度器根据 Pod 的资源需求、调度策略和集群的当前状态，决定将 Pod 调度到哪个 Node。调度决策过程包括以下几个步骤：

过滤节点：首先，调度器会根据资源需求（如 CPU 和内存）和节点状态，过滤掉那些不符合条件的节点。
优先级计算：调度器对剩余的节点计算优先级，优先级越高的节点越有可能成为目标节点。
选择节点：调度器根据优先级选择最合适的节点，并将 Pod 调度到该节点上。

3.2 节点选择策略

在 Pod 的调度过程中，开发者可以通过多种策略来影响 Pod 的调度决策：

NodeSelector：NodeSelector 是一种简单的节点选择策略，允许开发者将 Pod 限制调度到具备特定标签的节点上。

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-nodeselector
spec:
  nodeSelector:
    disktype: ssd
  containers:
  - name: myapp
    image: myapp:latest

在这个示例中，Pod 只会被调度到具有 disktype=ssd 标签的节点上。

NodeAffinity：NodeAffinity 是一种更灵活的调度策略，允许开发者定义软性和硬性约束，控制 Pod 调度的优先级。

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd
  containers:
  - name: myapp
    image: myapp:latest

在这个示例

中，requiredDuringSchedulingIgnoredDuringExecution 表示 Pod 在调度时必须满足这些条件，调度器会将 Pod 分配到具有 disktype=ssd 的节点上。

Taints 和 Tolerations：Taints 和 Tolerations 用于防止 Pod 被调度到某些特定的节点，或者允许特定的 Pod 忽略节点的 Taints。

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-toleration
spec:
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoSchedule"
  containers:
  - name: myapp
    image: myapp:latest

在这个示例中，Pod 被允许调度到带有特定 Taint 的节点上。

第四部分：Pod 与 Node 的网络与通信

4.1 Pod 与 Node 的网络模型

Kubernetes 的网络模型确保每个 Pod 都有一个独立的 IP 地址，Pod 之间的通信基于这个 IP 地址。而 Node 通过网络插件（如 Calico、Flannel 等）来实现 Pod 间、Pod 与服务之间的通信。

Pod IP：每个 Pod 都有一个独立的 IP 地址，Pod 内的所有容器共享该 IP 地址。Pod 间可以直接通过 IP 地址进行通信。
Service IP：Kubernetes 中的 Service 为一组 Pod 提供了一个稳定的访问入口，客户端通过 Service IP 访问 Pod。
NodePort：Node 可以为 Pod 提供对外的端口访问，通过将节点的某个端口映射到 Pod 上的端口，外部客户端可以直接通过 Node IP 和端口访问 Pod。

4.1.1 NodePort 示例

apiVersion: v1
kind: Service
metadata:
  name: example-service
spec:
  type: NodePort
  selector:
    app: myapp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
    nodePort: 30001

在这个示例中，NodePort 服务将 Kubernetes 集群外部的请求转发到运行在 Node 上的 Pod。

4.2 Pod 与 Node 的通信

Pod 与 Node 之间的通信是通过 Kubelet 实现的，Kubelet 运行在每个 Node 上，负责管理 Pod 的生命周期。Kubelet 会定期与 API Server 通信，报告 Pod 和 Node 的状态，并接受来自控制平面的指令。

此外，Kube-Proxy 也在 Node 上运行，负责处理集群内部的网络流量，确保 Pod 与外部服务之间的通信正常进行。

第五部分：Pod 与 Node 的健康检查与自动修复

5.1 Pod 的健康检查

Kubernetes 提供了 liveness 和 readiness 探针，用于监控 Pod 中容器的健康状态。如果容器的健康检查失败，Kubernetes 会根据配置的重启策略重启容器，确保应用程序的高可用性。

5.1.1 Liveness Probe 示例

apiVersion: v1
kind: Pod
metadata:
  name: liveness-pod
spec:
  containers:
  - name: myapp
    image: myapp:latest
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 5

在这个示例中，livenessProbe 定期检查应用的 /health 路径，如果应用不响应，Kubernetes 会自动重启 Pod。

5.2 Node 的健康检查

Kubernetes 通过 kubelet 监控每个 Node 的健康状态，并通过 node controller 来管理节点的健康。如果 Node 出现故障或与 API Server 失联，Kubernetes 会标记该节点为不可用状态，并将其上的 Pod 迁移到其他健康的节点上。

第六部分：Pod 与 Node 的资源管理与扩展

6.1 Pod 资源管理

在 Kubernetes 中，开发者可以为 Pod 定义资源请求（Requests）和限制（Limits）。资源请求是 Pod 运行所需的最小资源，而资源限制则是 Pod 可以使用的最大资源。Kubernetes 会根据这些定义，确保每个 Pod 都有足够的资源，并防止资源过度使用。

6.1.1 资源管理示例

apiVersion: v1
kind: Pod
metadata:
  name: resource-limited-pod
spec:
  containers:
  - name: myapp
    image: myapp:latest
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

在这个示例中，Pod 的容器请求最少 64Mi 内存和 250m CPU，而最多只能使用 128Mi 内存和 500m CPU。

6.2 Node 资源管理

每个 Node 都有一定的 CPU、内存和存储容量。Kubernetes 会监控 Node 的资源使用情况，并在调度 Pod 时避免将 Pod 分配到资源不足的节点上。

当 Node 上的资源紧张时，Kubernetes 可以根据调度策略，自动将 Pod 迁移到其他资源更充足的节点上。

6.3 Pod 水平自动伸缩

Kubernetes 提供了 Horizontal Pod Autoscaler（HPA），用于根据应用的负载情况，自动增加或减少 Pod 的数量。

6.3.1 HPA 示例

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp-deployment
  minReplicas: 2
  maxReplicas: 10
  targetCPUUtilizationPercentage: 80

在这个示例中，当 CPU 使用率超过 80% 时，HPA 会自动增加 myapp-deployment 的副本数。

第七部分：Pod 与 Node 的容错机制

7.1 Pod 容错机制

Kubernetes 提供了多种机制来确保 Pod 的高可用性和容错能力，包括：

重启策略：Pod 的容器如果失败，Kubernetes 可以自动重启它们。
节点故障时的 Pod 迁移：如果某个 Node 故障，Kubernetes 会将该节点上的 Pod 重新调度到其他健康的节点上。

7.2 Node 容错机制

Kubernetes 通过 Node Controller 来监控 Node 的健康状态。如果 Node 长时间没有响应，Kubernetes 会将其标记为不可用，并将其上的 Pod 迁移到其他健康的节点上。

第八部分：Pod 与 Node 的调优与最佳实践

8.1 Pod 调优

合理设置资源请求与限制：为 Pod 设置合理的 CPU 和内存请求，可以确保 Pod 在运行时获得足够的资源。
使用探针进行健康检查：通过 liveness 和 readiness 探针，可以监控 Pod 的健康状态，确保 Kubernetes 能够及时检测并处理 Pod 异常。

8.2 Node 调优

定期监控节点资源：使用 Kubernetes 提供的监控工具，定期检查 Node 的 CPU、内存和存储使用情况。
设置合理的调度策略：通过 Node Affinity、Taints 和 Tolerations 等机制，可以优化 Pod 的调度，确保 Pod 运行在合适的节点上。

第九部分：总结

Kubernetes 中 Pod 和 Node 的关系是容器编排系统中的核心组成部分。Node 为 Pod 提供运行所需的资源，而 Pod 是 Kubernetes 中的工作负载单元，调度到不同的 Node 上运行。通过 Kubernetes 的调度策略、资源管理和容错机制，Pod 和 Node 之间形成了紧密的协作关系，确保应用程序的高可用性和性能。

理解 Pod 和 Node 的关系，有助于开发者更好地设计和优化 Kubernetes 集群中的应用，确保在复杂的容器化环境中，应用能够平稳运行、自动扩展，并且具备强大的容错能力。