title: K8s概念_组件&架构&接口&api
date: 2026-02-04
categories:
  - K8s
tags:
  - 学习笔记

摘要：全面拆解 Kubernetes “大脑”控制平面与工作节点的核心组件功能，并深度探讨 CRI/CSI/CNI 三大标准接口及“一切皆对象”的 K8s API 逻辑架构与访问流水线。

基本概念

定义

Kubernetes 是一个开源的容器编排引擎，一个可弹性运行分布式系统的框架,用来对容器化应用进行自动化部署、扩缩和管理。此开源项目由云原生计算基金会（CNCF）托管。

功能

• 服务发现和负载均衡

  • Kubernetes 可以使用 DNS 名称或自己的 IP 地址来暴露容器。

  • 如果进入容器的流量很大，Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。

• 存储编排

  • Kubernetes 允许你自动挂载你选择的存储系统，例如本地存储、公共云提供商等。

• 自动部署和回滚

  • 你可以使用 Kubernetes 描述已部署容器的所需状态，它可以以受控的速率将实际状态更改为期望状态。

  • 例如，你可以自动化 Kubernetes 来为你的部署创建新容器，删除现有容器并将它们的所有资源用于新容器。

• 自动完成集装箱计算

  • 你为 Kubernetes 提供许多节点组成的集群，在这个集群上运行容器化的任务。

  • 你告诉 Kubernetes 每个容器需要多少 CPU 和内存 (RAM)，Kubernetes 可以将这些容器按实际情况调度到节点上，以最佳方式利用资源。

• 自我修复

  • Kubernetes 将重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器。

  • 在准备好服务之前，不会将其通告给客户端。

• 密钥配置与管理

  • Kubernetes 允许你存储和管理敏感信息，例如密码、OAuth 令牌和 SSH 密钥。

  • 可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置。

• 其他高级特性

  • 批处理执行：除了服务外，还可以管理批处理和 CI 工作负载。

  • 水平扩缩：根据 CPU 使用率自动对应用进行扩缩。

  • IPv4/IPv6 双栈：为 Pod 和 Service 分配双栈地址。

  • 可拓展：支持功能插件化修改与扩展。

历史背景

![[Container_Evolution 1.svg|489]]

• 相比虚拟机，容器流行的优势

  • 敏捷应用程序的创建和部署

  • 持续开发、集成和部署

  • 开发与运维的分离

  • 可观察性

  • 跨开发、测试和生产的环境一致性

  • 跨云和操作系统发行版本的可移植性

  • 以应用程序为中心的管

  • 松散耦合、分布式、弹性、解放的微服务

  • 资源隔离

  • 资源利用

K8s三种组件&架构

K8s是由控制平面和一个或者多个工作节点组成 ![[kubernetes-cluster-architecture 1.svg]] ![[components-of-kubernetes.svg]]

控制平面组件

控制平面组件管理整个集群的状态-保持集群和用户期望一致：

• kube-apiserver

  • API 服务器是 Kubernetes 控制平面的组件， 该组件负责公开了 Kubernetes API，负责处理接受请求的工作。 API 服务器是 Kubernetes 控制平面的前端

  • Kubernetes API 服务器的主要实现是 kube-apiserver。 kube-apiserver 设计上考虑了水平扩缩，也就是说，它可通过部署多个实例来进行扩缩。 你可以运行 kube-apiserver 的多个实例，并在这些实例之间平衡流量

• etcd

  • 一致且高可用的键值存储，用作 Kubernetes 所有集群数据的后台数据库。

  • 如果你的 Kubernetes 集群使用 etcd 作为其后台数据库， 请确保你针对这些数据有一份 备份计划。

  • 你可以在官方文档中找到有关 etcd 的深入知识

• kube-scheduler

  • 负责监视新创建的、未指定运行节点的 Pod， 并选择节点来让 Pod 在上面运行。

  • 调度决策考虑的因素包括单个 Pod 及多个 Pod 集合的资源需求、 软硬件及策略约束、亲和性及反亲和性规范、数据位置、工作负载间的干扰及最后时限

• kube-controller-manager

  • kube-controller-manager 是控制平面的组件， 负责运行控制器进程。

  • 从逻辑上讲， 每个控制器都是一个单独的进程， 但是为了降低复杂性，它们都被编译到同一个可执行文件，并在同一个进程中运行。

  • 控制器有许多不同类型。以下是一些例子：

    • Node 控制器：负责在节点出现故障时进行通知和响应

    • Job 控制器：监测代表一次性任务的 Job 对象，然后创建 Pod 来运行这些任务直至完成

    • EndpointSlice 控制器：填充 EndpointSlice 对象（以提供 Service 和 Pod 之间的链接）。

    • ServiceAccount 控制器：为新的命名空间创建默认的 ServiceAccount。

• cloud-controller-manager

  • 一个 Kubernetes 控制平面组件， 嵌入了特定于云平台的控制逻辑。 云控制器管理器（Cloud Controller Manager）允许将你的集群连接到云提供商的 API 之上， 并将与该云平台交互的组件同与你的集群交互的组件分离开来。

  • cloud-controller-manager 仅运行特定于云平台的控制器。 因此如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境， 所部署的集群不包含云控制器管理器。

  • 与 kube-controller-manager 类似，cloud-controller-manager 将若干逻辑上独立的控制回路组合到同一个可执行文件中，以同一进程的方式供你运行。 你可以对其执行水平扩容（运行不止一个副本）以提升性能或者增强容错能力。

  • 下面的控制器都包含对云平台驱动的依赖：

    • Node 控制器：用于在节点终止响应后检查云平台以确定节点是否已被删除

    • Route 控制器：用于在底层云基础架构中设置路由

    • Service 控制器：用于创建、更新和删除云平台上的负载均衡器

Node组件

节点组件会在每个节点上运行，负责维护运行的 Pod 并提供 Kubernetes 运行时环境

• kubelet

  • kubelet 会在集群中每个节点（node）上运行。 它保证容器（containers）都运行在 Pod 中。

  • kubelet 接收一组通过各类机制提供给它的 PodSpec，确保这些 PodSpec 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器

• kube-proxy

  • kube-proxy 是集群中每个节点（node）上所运行的网络代理， 实现 Kubernetes 服务（Service） 概念的一部分。

  • kube-proxy 维护节点上的一些网络规则， 这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。

  • 如果操作系统提供了可用的数据包过滤层，则 kube-proxy 会通过它来实现网络规则。 否则，kube-proxy 仅做流量转发。

  • 如果你使用网络插件为 Service 实现本身的数据包转发， 并提供与 kube-proxy 等效的行为，那么你不需要在集群中的节点上运行 kube-proxy

• 容器运行时container runtime

  • 这个基础组件使 Kubernetes 能够有效运行容器。 它负责管理 Kubernetes 环境中容器的执行和生命周期。

  • Kubernetes 支持许多容器运行环境，例如 containerd、 CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现

插件 Addons

插件使用 Kubernetes 资源（DaemonSet、 Deployment 等）实现集群功能。 因为这些插件提供集群级别的功能，插件中命名空间域的资源属于 kube-system 命名空间

• DNS

  • 集群 DNS 是一个 DNS 服务器，和环境中的其他 DNS 服务器一起工作，它为 Kubernetes 服务提供 DNS 记录。

  • Kubernetes 启动的容器自动将此 DNS 服务器包含在其 DNS 搜索列表中

• web界面

  • Dashboard 是 Kubernetes 集群的通用的、基于 Web 的用户界面。 它使用户可以管理集群中运行的应用程序以及集群本身，并进行故障排除

• 容器资源监控

  • 容器资源监控 将关于容器的一些常见的时序度量值保存到一个集中的数据库中，并提供浏览这些数据的界面

• 容器层面日志

  • 集群层面日志机制负责将容器的日志数据保存到一个集中的日志存储中， 这种集中日志存储提供搜索和浏览接口

• 网络插件

  • 网络插件 是实现容器网络接口（CNI）规范的软件组件。它们负责为 Pod 分配 IP 地址， 并使这些 Pod 能在集群内部相互通信

K8s三大接口

CRI (Container Runtime Interface) - 容器运行时接口

• 职责：负责“生孩子”。K8s 告诉它“我要跑个 Nginx”，CRI 就去拉镜像、起容器。

• 地位：最底层。没有它，Pod 只是 YAML 文件里的文字，无法变成运行的进程。

• 代表实现：containerd (你目前 1.35 用的)、CRI-O。

CSI (Container Storage Interface) - 容器存储接口

• 职责：负责“找硬盘”。Pod 漂移到哪，CSI 就负责把云硬盘或 NAS 挂载到哪。

• 地位：数据的命脉。它解耦了 K8s 与各种云厂商（阿里云、AWS）的存储协议。

• 代表实现：Ceph CSI、NFS CSI、各云厂商磁盘插件。

CNI (Container Network Interface) - 容器网络接口

• 职责：负责“拉网线”。给 Pod 发 IP 地址，打通 Pod 之间的隧道。

• 地位：通信基础。没有它，Pod 之间就是孤岛，Service 和 Ingress 也无法工作。

• 代表实现：Flannel、Calico、Cilium。

K8s-API

• 在 K8s 中，“一切皆对象，一切皆 API”。

• K8s API 的本质不是为了“执行命令”，而是为了 维护状态

• K8s api 是唯一入口： 整个集群中只有 API Server 能读写 etcd。

• K8s api 是标准化的契约：无论底层是 Ubuntu 还是 CentOS，无论网络是 Flannel 还是 Cilium，对外的 API 永远长得一样。

• K8s api 是可扩展的：通过 CRD（自定义资源），你可以像定义原生的 Pod 一样定义你自己的“数据库对象”或“AI任务对象”

API分层过滤

每当你发起一个 API 请求（无论是通过 kubectl 还是代码），都会经过 API Server 的一套标准流水线：

1. 认证 (Authentication)：你是谁？（检查证书、Token）。

2. 鉴权 (Authorization)：你能干什么？（RBAC 检查，是否有权操作这个 Namespace）。

3. 准入控制 (Admission Control)：你发的东西合规吗？（例如：检查 Pod 是否超过了资源配额，或者自动给 Pod 加上标签）。

4. 持久化：通过校验后，数据最终存入 etcd

API逻辑结构

为了处理成百上千种资源，K8s 将 API 组织成了树状结构：

1. 资源路径： /apis/apps/v1/namespaces/default/deployments/my-nginx

   • apis: 告诉 Server 这是个命名组 API。

   • apps: API 组 (Group)。按功能分类（如存储、网络、应用）。

   • v1: 版本 (Version)。区分 Alpha, Beta, Stable。

   • deployments: 资源类型 (Resource)。

   • my-nginx: 资源名称 (Name)。

2. 发现机制：

   • API Discovery: 就像餐厅的“菜单”。它告诉客户端这个集群支持哪些版本的 API。

   • OpenAPI (v2/v3): 就像菜单上的“配料表”。它详细定义了每个字段（如 replicas 必须是整数）的校验规则。