Kubernetes 基本架构、节点类型及运行流程详解（附架构图及流程图）

Kubernetes 基本架构、节点类型及运行流程详解（附架构图及流程图）

引用

CSDN

1.

https://blog.csdn.net/Shad0wLEO/article/details/145876177

Kubernetes作为容器编排领域的事实标准，其架构设计和运行机制一直是开发者关注的重点。本文将详细介绍Kubernetes的基本架构、节点类型及运行流程，帮助读者全面理解这一强大的容器编排系统。

Kubernetes 架构

Kubernetes集群由多个主节点（Master Node）和工作节点（Worker Node）组成。

• 主节点（Master Node）：负责集群的管理任务，包括调度容器、维护集群状态、监控集群、管理服务发现等。
• 工作节点（Worker Node）：实际运行应用程序的容器。每个工作节点上都运行着容器运行时（如containerd），并接受来自主节点的调度指令。

组成结构

节点（Node）

• 定义：运行容器的物理服务器或虚拟机。在云环境中，节点通常是虚拟机；在本地环境或裸机环境中，节点可以是物理服务器。
• 节点的类型：
• 主节点（Master Node 或 Control Plane）
• 工作节点（Worker Node）

主节点（Master Node）

• 定义：调度和管理整个集群的状态的地方
• 功能：负责管理整个 Kubernetes 集群的控制平面，处理集群的调度、API 调用、集群状态维护等任务。主节点通常不运行应用工作负载
• 组成

工作节点（Worker Node）

• 定义：真正运行应用负载的地方，提供实际的计算资源和服务，所有应用服务都以 Pod 的形式运行在工作节点上，每个工作节点运行多个 Pod
• 功能：实际运行应用容器的节点。所有的应用 Pod 都部署在这些工作节点上
• 组成

架构图

+---------------------------------------+
|               kubectl                 |  
|  (用户接口：CLI工具，与API Server交互)  |
+---------------------------------------+
                  |
+---------------------------------------+
|           API Server (控制平面)        |
|     (接收和处理请求，管理集群状态)       |
+---------------------------------------+
   |        |            |              |
+--------+  +--------+  +----------+   +---------------------+
| etcd   |  |Scheduler| |Controller|   | Kubelet (每个节点)  |
| (存储) |  | (调度器) | | Manager  |   | (工作节点上运行Pod)   |
+--------+  +--------+  +----------+   +----------------0----+
                             |
                  +----------------------------+
                  |       Pod (容器)           |
                  | (运行在工作节点上，提供服务)   |
                  +----------------------------+

端口类型

1. 外部访问的端口 (nodePort)

• 定义：一个开放在每个节点（Node）上的固定端口，是为每个 Service 分配的固定端口，一个向外暴露的 Service 对应一个 nodePort（端口范围通常在 30000-32767）
• 功能：NodePort 类型的 Service 暴露一个端口给外部用户，使得外部请求可以通过固定的端口访问集群中的应用（接收到的外部请求会转发到 Service 暴露的端口（如 80））

2. 服务暴露的端口 (port)

• 定义：Kubernetes 使用 Service 来暴露和管理 Pod 的访问，port 端口是集群内的其他服务或容器通过该 Service 访问 Pod 的端口
• 功能：Service 暴露多个端口（例如 80 端口），并将流量转发到端口对应的 Pods 中

3. 服务设置的端口（targetPort）

• 定义：targetPort 定义了 Service 转发到容器内部的具体端口（通常为 containerPort）
• 功能：Service 通过 targetPort 决定如何调用 Pod，通常不需要手动设置

4. 容器内部的端口 (containerPort)

• 定义：Pod 内的 Container 向外暴露的端口，通过 containerPort 可以找到 port 中的一个容器
• 功能：container 监听 containerPort 并处理请求，Service 会将请求从自己的端口转发到对应的 Pod 的 ContainerPort 上

工作流程

1. 发起请求：客户端请求（外部请求）通过 NodeIP:NodePort 向 k8s 发起请求（NodeIP 决定请求的 Node，NodePort 决定请求的 Service）
2. 监听与转发：每个 Node 上的 kube-proxy 监听多个到达 NodePort 端口的请求，并由 kube-proxy 将请求转发到 NodePort 对应的 Service
3. 监听与转发：每个 Service 监听一个到达 NodePort 端口的请求，接收到请求后通过 selector 找到符合条件的 Pod，并通过负载均衡策略选择一个 pod 并将请求发送给这个 pod 对应的 targetPort 端口
4. 监听请求：每个 pod 监听一个 targetPort 端口发来的请求，由 pod 中的主容器监听 containerPort（containerPort 和 targetPort 通常相同）
5. 处理请求：主容器监听一个 ContainerPort 端口发来的请求，主容器接收请求并处理请求（或转发给其他容器处理请求）
6. 处理请求：主容器接收并最终处理请求，处理过程中可能会通过 containerPort 调用其他容器的功能

服务分类

ClusterIP 服务

• 定义：仅在 Kubernetes 集群内部可访问，服务的 IP 地址只在集群内部网络中有效，无法从集群外部通过 ClusterIP 直接访问服务
• 适用场景：内部服务之间的通信，如微服务架构中服务间的 RPC 调用

NodePort 服务

• 定义：Node 中的 Service 的端口号，集群通过 NodeIP:NodePort 将服务暴露给外部用户
• 功能：用于将服务暴露在每个 Node（包括 Worker 和 Master）上的特定端口
• 缺点：多个服务有多个 IP，用户访问哪个 IP 就会访问对应的 Node，没有统一的负载均衡策略
• 工作流程
• 用户创建一个 NodePort 类型的服务
• Kubernetes 会在集群中所有节点（包括 Worker Node 和 Master Node）上分配一个特定的端口（通常在 30000-32767 之间）
• 外部请求可以通过任何节点（Master 或 Worker）的IP地址 + NodePort 来访问服务（不仅限于 Master Node）

示例：如果在集群中定义了一个 NodePort 服务，分配了端口号 30001，并且集群有三个节点：

• Master Node IP: 192.168.1.10
• Worker Node 1 IP: 192.168.1.20
• Worker Node 2 IP: 192.168.1.30

那么可以从集群外通过以下任意地址访问该服务：

• http://192.168.1.10:30001 （Master Node）
• http://192.168.1.20:30001 （Worker Node 1）
• http://192.168.1.30:30001 （Worker Node 2）

LoadBalancer 服务

• 定义：服务商提供的外部 IP，让用户通过统一的 IP 地址（External IP）访问服务
• ExternalIP：使外部访问可以通过集群节点的 IP 地址访问指定服务（很少用，更常见的是通过 NodePort 或 Ingress 暴露服务）
• 功能
• 自动创建一个外部负载均衡器，并将流量路由到 Kubernetes 集群中的服务
• 提供了更简便的方式访问服务（通过一个外部 IP） ，通常用于云环境（如 AWS、GCP、Azure）
• 缺点：用户需要知道具体的 IP 地址，可读性不好，不便于用户记忆
• 工作流程
• 用户创建一个 LoadBalancer 类型的服务
• 服务商分配一个外部 IP 地址给这个服务
• 用户可以通过这个外部 IP 地址直接访问该服务，而不需要知道任何节点的 IP

Ingress 服务

• 定义：Kubernetes 用于 HTTP/HTTPS 路由的组件，通常配合 Ingress Controller（如 Nginx Ingress Controller）来工作
• 功能：将外部流量转发到内部服务，使外部访问可以通过配置域名、路径等规则访问服务，而不需要知道具体的 IP
• 工作流程
• Ingress 接收来自外部的 HTTP/HTTPS 请求
• Ingress Controller 根据配置的路由规则（域名、路径等）匹配请求
• 将请求转发到对应的后端服务（Service）
• 支持基于路径的转发（如 /api -> api-service）
• 支持基于域名的转发（如api.example.com-> api-service）
• 负载均衡：Ingress Controller 可以实现请求的负载均衡
• SSL/TLS 终止：处理 HTTPS 请求的 SSL/TLS 终止（如果配置了证书）
• 组成部分

总结

• ClusterIP 类型的服务 ：内部访问使用的 IP，无法从集群外部访问
• NodePort 类型的服务：外部可以访问的服务，使用 “任意节点(Master 或 Worker)的 IP 地址” + “NodePort” 进行访问
• LoadBalancer 类型的服务：在云环境中，可以使用 LoadBalancer 类型的服务来获得一个外部 IP 地址，直接从外部访问
• Ingress 类型的服务：提供了一种更加灵活的 HTTP/HTTPS 访问方式，适合基于域名或路径规则管理外部流量

示例

目标：通过 NodePort 服务将一个应用程序（MyApp）暴露给外部访问，使外部用户可以通过节点的 IP 地址和端口号（30080）访问该应用

工作流程

1. 将 myApp-service 服务通过 30080 端口暴露给外部，供外部访问
2. Kube Proxy 监听 30080 端口请求，并将请求转发到 myApp-service 对应的端口 80
3. Service 根据 selector 选择 app=MyApp 的 Pod ，并通过负载均衡策略选择一个 Pod 处理请求
4. Service 将请求转发到后端 Pod 的端口（targetPort: 8080）
5. Pod 处理请求并返回响应给 Service
6. Service 将响应返回给 Kube Proxy
7. Kube Proxy 将响应返回给用户

代码实现

apiVersion: v1               # 声明 API 版本（如何同 API Server 进行交互），v1 最常用
kind: Service                # 声明资源类型为 Service
metadata:                    # 声明服务的元数据
  name: myApp-service        # 声明服务的名字，Kubernetes 内部和外部引用该服务时将使用这个名字
spec:                        # specification: 声明资源对象的配置信息
    type: NodePort             # 声明该服务为节点端口类型的 (向外暴露的服务)
  selector:                  # 选择器，用来选择对应的 Pod，服务会将流量转发到符合条件的 Pod
    app: MyApp               # 选择 pod 的 Label 中 app=nginx 的资源
  ports:
- protocol: TCP          # 指定服务使用的协议是 TCP
      port: 80               # 服务对集群内部公开的端口
      targetPort: 8080       # 服务后方 pod 的端口
      nodePort: 30080        # 声明向外提供服务的端口号, 必须在30000~32767之间

本文原文来自CSDN