核心概念

一、K8s 概述

Kubernetes (简称 K8s) 是一个开源的容器编排引擎，用于自动化容器化应用程序的部署、扩展和管理。

简单来说，K8s 就是一个智能的“容器管家”。以前我们手动部署应用，得自己盯着服务器：万一程序崩了要手动重启，流量大了要赶紧加机器，更新代码还得提心吊胆怕断网。有了 K8s，只需要告诉它一个“期望状态”（比如：我要 5 个这玩意儿一直跑着），剩下的脏活累活——比如分发任务、故障自愈、自动扩容它全帮干了。

参考文档：

• kubernetes 中文文档：
  • https://kubernetes.io/zh/docs/home/
  • http://docs.kubernetes.org.cn/
• kubernetes 中文社区：https://www.kubernetes.org.cn/docs

二、架构概览与核心组件

K8s 集群采用典型的 Master-Worker (控制平面-工作节点) 架构。

• Control Plane (控制平面)：集群的“大脑”，负责全局决策（如调度）、检测和响应集群事件。
• Worker Node (工作节点)：集群的“手脚”，负责实际运行应用程序的容器（Pod）。

K8s 的所有组件之间都不直接通过网络互相调用，而是全部通过 kube-apiserver 进行通信。这保证了架构的松耦合和极高的可扩展性。

1. 控制平面组件

通常运行在 Master 节点上，生产环境中必须进行高可用部署（至少 3 个节点）。

kube-apiserver

K8s 集群的统一入口，提供 HTTP REST API 接口，所有其他组件（无论是内部组件还是外部客户端如 kubectl）都需要通过它来交互。它负责请求的认证、授权、准入控制以及 API 注册。

默认端口：

• 6443（TCP）：所有的内部组件（如 kubelet、kube-scheduler）以及外部客户端（kubectl 命令），都是通过请求这个端口与控制平面进行通信的。

默认运行方式：

• 静态 Pod，控制平面的 kubelet 监控 /etc/kubernetes/manifests/kube-apiserver.yaml 文件，直接利用本机的容器运行时拉取镜像并启动 kube-apiserver 容器。

查看 apiserver 的版本

# curl -k https://127.0.0.1:6443/version
{
  "major": "1",
  "minor": "24",
  "gitVersion": "v1.24.2",
  "gitCommit": "f66044f4361b9f1f96f0053dd46cb7dce5e990a8",
  "gitTreeState": "clean",
  "buildDate": "2022-06-15T14:15:38Z",
  "goVersion": "go1.18.3",
  "compiler": "gc",
  "platform": "linux/amd64"
}

etcd

• K8s 的数据库。一个强一致性、高可用的分布式键值存储系统。它保存了整个集群的所有状态数据和配置信息。只有 kube-apiserver 可以直接访问它。

默认端口：

• 2379（TCP）：用于对外提供服务。在 K8s 中，只有 kube-apiserver 会连接这个端口，向 etcd 发起读写请求（例如保存一个新的 Pod 记录，或者查询当前 Node 的状态）。也是使用 etcdctl 命令行工具查询数据时，默认连接的端口。
• 2380（TCP）：用于 etcd 集群内部节点之间的数据同步和心跳维持。etcd 基于 Raft 共识算法，集群中的 Leader 节点和 Follower 节点需要不断地通过这个端口交换数据，以保证数据的高可用和强一致性。只有 etcd 节点彼此之间会用到这个端口，外部组件不会访问它。

默认运行方式：

• 静态 Pod，控制平面的 kubelet 监控 /etc/kubernetes/manifests/etcd.yaml 文件，直接利用本机的容器运行时拉取镜像并启动 etcd 容器。

在对稳定性要求极高的生产环境中，通常会将 etcd 从 K8s 的 Master 节点中剥离出来，部署在完全独立的一组服务器上。kube-apiserver 会通过配置参数（–etcd-servers）指向这组独立的外部机器的 2379 端口。这组外部机器上的 etcd 通常以 Systemd 守护进程（二进制部署）或容器的形式运行。

kube-scheduler

• 负责 Pod 的分配和调度，它会监控新创建且未分配节点的 Pod并根据一系列条件（硬件限制、亲和性/反亲和性规则等），为该 Pod 选择一个最合适的 Worker 节点来运行。

默认端口：

• 10259（TCP）：主要用于暴露自身的 metrics 指标以及健康检查 healthz 等

默认运行方式：

• 静态 Pod，控制平面的 kubelet 监控 /etc/kubernetes/manifests/kube-scheduler.yaml 文件，直接利用本机的容器运行时拉取镜像并启动 kube-scheduler 容器。

kube-controller-manager

• 集群的大管家，运行着诸多后台控制器（如 Node, ReplicaSet Controller），负责维持集群的期望状态。

默认端口：

• 10257（TCP）：主要用于暴露自身的 metrics 指标以及健康检查 healthz 等

默认运行方式：

• 静态 Pod，控制平面的 kubelet 监控 /etc/kubernetes/manifests/kube-controller-manager.yaml 文件，直接利用本机的容器运行时拉取镜像并启动 kube-controller-manager 容器。

2. 工作节点组件

运行在每一个 Worker Node 上，负责维护运行的 Pod 并提供 K8s 运行环境。

kubelet

• 节点的大管家（Agent），它直接与 kube-apiserver 通信，接收分配给该节点的 Pod 配置信息，并确保这些 Pod 中的容器处于运行状态且健康。它只会管理由 K8s 创建的容器。

默认端口：

• 10250（TCP）：kube-apiserver 通过这个端口与 kubelet 通信的。
  • 当执行 kubectl logs (查看日志) 或者 kubectl exec -it – bash (进入容器终端) 时，请求会先到达 kube-apiserver，然后 API Server 就会作为客户端，去连接目标节点上 kubelet 的 10250 端口，最终由 kubelet 连通底层的容器。
• 10248（TCP）：kubelet 自身的健康检查端口，供节点本地的守护进程或监控系统探测 kubelet 是否崩溃，以便触发本地重启自愈。

运行方式：

• systemctl status kubelet

kube-proxy

• 网络代理与负载均衡，它在每个节点上维护网络规则（通常通过操作主机的 iptables 或 IPVS）。这些规则允许从集群内部或外部的网络会话与 Pod 进行通信，是实现 K8s Service 服务的核心组件。

默认端口：

• 10249（TCP）：用于暴露自身的性能指标（Metrics）。Prometheus 等监控系统就是通过抓取每个节点上 kube-proxy 的这个端口，来监控网络规则同步是否延迟、连接数等情况。
• 10256（TCP）：专门用于暴露 /healthz 接口，供 kubelet 或其他组件检查当前的 kube-proxy 进程是否健康存活。

运行方式：

• 通过 DaemonSet 在每个 worker 节点运行。

Container Runtime

• 容器运行时。真正负责运行容器的基础软件（如 containerd, CRI-O），实现了 CRI（Container Runtime Interface）规范，Kubelet 通过 CRI 接口与其交互。

3. 其他组件

下面这些组件，同样对 K8s 集群的正常运行至关重要。

CoreDNS

• 集群的 DNS 服务器。负责为集群中的 Service 和 Pod 提供 DNS 解析服务。

CNI

• 容器网络接口。负责为 Pod 分配网络资源（IP 地址、路由表），并确保不同 Pod 之间可以通信。

三、K8s 核心术语对照表

1. 基础

2. 工作负载

3. 网络与服务暴露

4. 配置与存储

5. 扩展与包管理

6. 标准接口与容器运行时

K8s 本身并不直接提供网络、存储和底层的容器运行能力，而是通过定义一套标准接口（Interfaces），让第三方的插件（Plugins）来具体实现。