【K8S】Kubernetes 基本架构、节点类型及运行流程详解（附架构图及流程图）
Kubernetes 架构
- k8s 集群 = 多个 master node + 多个 work node
- Master 节点（主节点）：负责集群的管理任务，包括调度容器、维护集群状态、监控集群、管理服务发现等。
- Worker 节点（工作节点）：实际运行应用程序的容器。每个工作节点上都运行着容器运行时（如
containerd），并接受来自主节点的调度指令。
节点：（Node）通常指一个物理服务器或虚拟机，承载运行容器的实际工作负载，节点可以看作是 Kubernetes 集群中的计算单元
组成结构
节点（Node）
- 定义：运行容器的物理服务器或虚拟机（在云环境中，节点通常是虚拟机；在本地环境或裸机环境中，节点可以是物理服务器）
- 节点的类型
- 主节点（Master Node 或 Control Plane）
- 工作节点（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）- 定义：targetPort 定义了 Service 转发到容器内部的具体端口（通常为 containerPort）
- 功能：Service 通过 targetPort 决定如何调用 Pod，通常不需要手动设置
- 容器内部的端口 (
containerPort)- 定义：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 -
工作流程-
- 接收请求：Ingress 接收来自外部的 HTTP/HTTPS 请求
-
- 路由匹配：Ingress Controller 根据配置的路由规则（域名、路径等）匹配请求
-
- 转发请求：将请求转发到对应的后端服务（Service）
- 支持基于路径的转发（如 /api -> api-service）
- 支持基于域名的转发（如 api.example.com -> api-service）
-
- 负载均衡：Ingress Controller 可以实现请求的负载均衡
-
- 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）访问该应用
-
工作流程
- 将 myApp-service 服务通过 30080 端口暴露给外部，供外部访问
- Kube Proxy 监听 30080 端口请求，并将请求转发到 myApp-service 对应的端口 80
- Service 根据 selector 选择 app=MyApp 的 Pod ，并通过负载均衡策略选择一个 Pod 处理请求
- Service 将请求转发到后端 Pod 的端口（targetPort: 8080）
- Pod 处理请求并返回响应给 Service
- Service 将响应返回给 Kube Proxy
- 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之间