Kubernetes 中 Pod 和 Node 的关系详解
引言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 集群中的应用，确保在复杂的容器化情况中，应用能够平稳运行、主动扩展，而且具备强盛的容错能力。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]