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

Kubernetes 架构

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

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


组成结构

节点(Node)

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

主节点(Master Node)

  1. 定义:调度和管理整个集群的状态的地方

  2. 功能:负责管理整个 Kubernetes 集群的控制平面,处理集群的调度、API 调用、集群状态维护等任务。主节点通常不运行应用工作负载

  3. 组成

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

工作节点(Worker Node)

  1. 定义:真正运行应用负载的地方,提供实际的计算资源和服务,所有应用服务都以 Pod 的形式运行在工作节点上,每个工作节点运行多个 Pod

  2. 功能:实际运行应用容器的节点。所有的应用 Pod 都部署在这些工作节点上

  3. 组成

    组件名称 功能描述
    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 (容器)           |
                  | (运行在工作节点上,提供服务)   |
                  +----------------------------+

工作流程


端口类型

  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

    1. 定义:targetPort 定义了 Service 转发到容器内部的具体端口(通常为 containerPort)
    2. 功能:Service 通过 targetPort 决定如何调用 Pod,通常不需要手动设置
  4. 容器内部的端口 (containerPort)

    1. 定义: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

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

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 访问方式,适合基于域名或路径规则管理外部流量

示例

  1. 目标:通过 NodePort 服务将一个应用程序(MyApp)暴露给外部访问,使外部用户可以通过节点的 IP 地址和端口号(30080)访问该应用

  2. 工作流程

    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 将响应返回给用户
  3. 代码实现

    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之间
    
相关推荐
霍格沃兹测试开发学社测试人社区1 小时前
性能测试丨JMeter 分布式加压机制
软件测试·分布式·测试开发·jmeter
hxj..2 小时前
Redis分布式缓存面试题
redis·分布式·缓存·分布式缓存
綝~6 小时前
分布式爬虫
分布式·爬虫
leijiwen12 小时前
RWA经济模型:基于数据为生产要素的商业模型
分布式·去中心化·零售·rwa
红豆和绿豆19 小时前
实现分布式限流开源项目
分布式·开源
晓夜残歌20 小时前
Spark on Yarn 多机集群部署
大数据·分布式·spark
小小工匠21 小时前
架构思维:分布式缓存_提升系统性能的关键手段(上)
分布式·缓存·架构
信徒_1 天前
rabbitmq 延时队列
分布式·rabbitmq·ruby