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

Kubernetes 架构

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

节点：（Node）通常指一个物理服务器或虚拟机，承载运行容器的实际工作负载，节点可以看作是 Kubernetes 集群中的计算单元

组成结构

节点（Node）

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

主节点（Master Node）

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

组成

组件	功能描述
`Kube API Server`	集群的前端（类似集群的网关），负责接收和处理所有API请求，提供认证授权和访问控制功能
`Scheduler`	监控集群节点资源使用情况，根据调度策略将 Pod 分配到合适的工作节点
`Controller Manager`	管理集群中各种资源对象(如 Node、Pod、Service) 的状态，确保实际状态与期望状态一致
`etcd`	高可用键值存储系统，保存集群的配置信息和元数据
`Cloud Controller Manager`	云平台控制器，负责与云平台的API交互

工作节点（Worker Node）

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

组成

组件名称	功能描述
kubelet	负责管理和维护 Pod 对象，保证 Pod 按预期运行，并定期与 Kubernetes API Server 进行通信获取新的 pod 规范，汇报 pod 的运行情况
kube-proxy	负责为 pod 对象提供网络代理和负载均衡，确保网络流量正确转发到相应的 Pod
container runtime	负责拉取容器镜像、创建容器、启动或者停止容器等等（如 Docker-Engine 或 containerd）

架构图

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

工作流程

端口类型

外部访问的端口 (nodePort)
- 定义：一个开放在每个节点（Node）上的固定端口，是为每个 Service 分配的固定端口，一个向外暴露的 Service 对应一个 nodePort（端口范围通常在 30000-32767）
- 功能：NodePort 类型的 Service 暴露一个端口给外部用户，使得外部请求可以通过固定的端口访问集群中的应用（接收到的外部请求会转发到 Service 暴露的端口（如 80））
服务暴露的端口 (port)
- 定义：Kubernetes 使用 Service 来暴露和管理 Pod 的访问，port 端口是集群内的其他服务或容器通过该 Service 访问 Pod 的端口
- 功能：Service 暴露多个端口（例如 80 端口），并将流量转发到端口对应的 Pods 中
服务设置的端口（targetPort）
1. 定义：targetPort 定义了 Service 转发到容器内部的具体端口（通常为 containerPort）
2. 功能：Service 通过 targetPort 决定如何调用 Pod，通常不需要手动设置
容器内部的端口 (containerPort)
1. 定义：Pod 内的 Container 向外暴露的端口，通过 containerPort 可以找到 port 中的一个容器
- 功能：container 监听 containerPort 并处理请求，Service 会将请求从自己的端口转发到对应的 Pod 的 ContainerPort 上

工作流程

发起请求：客户端请求（外部请求）通过 NodeIP:NodePort 向 k8s 发起请求（NodeIP 决定请求的 Node，NodePort 决定请求的 Service）
监听与转发：每个 Node 上的 kube-proxy 监听多个到达 NodePort 端口的请求，并由 kube-proxy 将请求转发到 NodePort 对应的 Service
监听与转发：每个 Service 监听一个到达 NodePort 端口的请求，接收到请求后通过 selector 找到符合条件的 Pod，并通过负载均衡策略选择一个 pod 并将请求发送给这个 pod 对应的 targetPort 端口
监听请求：每个 pod 监听一个 targetPort 端口发来的请求，由 pod 中的主容器监听 containerPort（containerPort 和 targetPort 通常相同）
处理请求：主容器监听一个 ContainerPort 端口发来的请求，主容器接收请求并处理请求（或转发给其他容器处理请求）
处理请求：主容器接收并最终处理请求，处理过程中可能会通过 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 地址直接访问该服务，而不需要知道任何节点的 IP

⭐ Ingress 服务

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

组成部分

组件	功能
Ingress 资源	定义路由规则，指定如何将外部请求转发到内部服务
Ingress Controller	实现 Ingress 资源定义的规则，通常使用 Nginx、Traefik 等
后端服务	处理实际请求的 Kubernetes Service，可以是 ClusterIP、NodePort 等类型

总结

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，服务会将流量转发到符合条件的 Podapp: MyApp               # 选择 pod 的 Label 中 app=nginx 的资源ports:- protocol: TCP          # 指定服务使用的协议是 TCPport: 80               # 服务对集群内部公开的端口targetPort: 8080       # 服务后方 pod 的端口nodePort: 30080        # 声明向外提供服务的端口号, 必须在30000~32767之间