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之间