【K8s笔记】kubernetes的相关组件

kube-apiserver

kube-apiserver 是 Kubernetes 集群中最核心的组件之一，仅运行在master node上面，可以理解为整个集群的“大门”或“中枢神经”。

¶kube-apiserver 的作用

集群的 API 网关
- kube-apiserver 提供了 RESTful API 接口，所有对 Kubernetes 的操作（比如 kubectl、Dashboard、CI/CD 工具等）都要经过它。
- 它是唯一可以直接操作 etcd 数据的组件。
统一入口，安全认证
- 所有的创建、查询、修改、删除等请求都必须经过 kube-apiserver。
- 它负责认证（Authentication）、鉴权（Authorization）、准入控制（Admission Control）等安全机制。
状态管理的中心枢纽
- kube-apiserver 把用户的操作转化为对 etcd 的读写。
- 其他控制面组件（如 scheduler、controller-manager）也都通过 apiserver 获取和更新集群状态。
与各组件通信的桥梁
- kube-apiserver 是所有控制面组件和节点组件通信的唯一通道。
- 比如 kubelet、controller-manager、scheduler、operator 等都要通过它与集群交互。

¶你可以这样理解

kube-apiserver = 集群的“前台服务台”
- 所有请求都要“报到登记”，它统一接收、校验、分发请求。
kube-apiserver = 集群的“数据总线”
- 所有信息流动都要经过它。

¶工作流程举例

你用 kubectl create -f pod.yaml 创建一个 Pod。
kubectl 把请求发给 kube-apiserver。
kube-apiserver 检查请求是否合法（认证、鉴权、准入）。
校验通过后，apiserver 把 Pod 信息写入 etcd。
其他控制器（如 scheduler）通过 apiserver 发现新 Pod 并进行调度。

¶图示

用户/工具
   |
   v
+--------------------+
|   kube-apiserver   |  <--- 所有请求的入口
+---------+----------+
          |
          v
        etcd

¶总结一句话

kube-apiserver 是 Kubernetes 的 API 网关和控制中心，负责处理所有请求、统一管理集群状态，是整个集群的“总指挥”。

kube-controller-manager

kube-controller-manager 是 Kubernetes 控制平面上的一个核心组件，仅运行在master node上面，主要负责“控制循环（Control Loop）”机制，确保集群实际状态和期望状态一致。你可以把它理解为集群的自动化管理员，不断地“观察-对比-修正”集群的各种资源。

¶主要作用

运行各种控制器（Controller）
- kube-controller-manager 其实是很多“控制器”程序的集合，每个控制器负责一种资源的自动化管理，比如：
  - ReplicaSetController：确保副本数正确
  - NodeController：管理节点状态
  - JobController：管理 Job 生命周期
  - DeploymentController：管理 Deployment 的滚动升级和回滚
  - ServiceAccountController：自动创建和维护 ServiceAccount
  - 还有很多其他控制器
控制循环
- 每个控制器都在不断地“观察”集群的实际状态（通过 kube-apiserver），
- 与用户设定的期望状态对比，
- 如果不一致，就自动采取行动，调整实际状态向期望状态靠拢。
和 kube-apiserver 交互
- kube-controller-manager 不直接操作 etcd，而是通过 kube-apiserver 读写资源信息。

¶工作流程举例

比如你创建了一个 Deployment，期望有 3 个副本 Pod：

你用 kubectl 创建 Deployment，apiserver 写入 etcd。
kube-controller-manager 里的 DeploymentController 发现当前只有 1 个 Pod，和期望的 3 个不一致。
它就会创建 2 个新的 Pod，直到副本数达到 3。
如果某个 Pod 挂了，Controller 会自动补上新的 Pod。

¶图示

+---------------------------+
|   kube-controller-manager |
|  (内含多个控制器)         |
+-----------+---------------+
            |
            v
      kube-apiserver
            |
           etcd

¶总结一句话

kube-controller-manager 是 Kubernetes 的自动化调节器，负责各种资源的健康和数量，确保集群状态始终符合用户的期望。

kube-scheduler

kube-scheduler 也是 Kubernetes 控制平面中的一个核心组件，专门负责Pod 的调度。它的主要作用是：
决定每个新创建的 Pod 应该运行到哪个 Node（节点）上。

¶工作原理

Pod 创建
当你创建 Pod 或 Deployment 时，kube-apiserver 会把 Pod 对象存到 etcd 里。此时 Pod 的 spec.nodeName 字段是空的，表示还没被分配到具体节点。
调度过程
kube-scheduler 会不断监听 kube-apiserver，发现有“待调度”的 Pod（即还没有分配节点的 Pod）。

它会为这些 Pod：
- 过滤出可用的节点（比如资源充足、满足亲和性/反亲和性、Taints/Tolerations 等各种调度条件）
- 根据调度算法打分，选择最合适的节点
- 把选择的节点名字写回 Pod 对象的 spec.nodeName 字段（通过 kube-apiserver）
后续流程
kubelet 监听到自己节点上有新分配的 Pod，就会拉取镜像、启动容器，真正把 Pod 跑起来。

¶图示流程

用户提交 Pod
      ↓
+---------------------+
|   kube-apiserver    |
+---------------------+
      ↓
+---------------------+
|   etcd              |
+---------------------+
      ↑
kube-scheduler 监听到有待调度 Pod
      ↓
选择合适 Node，写回 Pod 的 nodeName 字段
      ↓
kubelet 发现自己节点有新 Pod，拉起容器

¶总结

kube-scheduler 只负责“分配位置”，不负责直接启动 Pod。
它通过 kube-apiserver 读取和写入 Pod 信息，不会直接操作 etcd，也不会直接跟 kubelet 通信。
调度策略可以自定义，比如资源利用率优先、亲和性、反亲和性、污点容忍（Taint/Toleration）等。

一句话总结：

kube-scheduler 是 Kubernetes 的“调度员”，负责把 Pod 安排到最合适的节点上，确保资源合理利用和调度策略达成。

containerd-shim-runc-v2

containerd-shim-runc-v2 是在使用 containerd 作为容器运行时时，负责管理和隔离容器进程的一个关键中间组件。它在 Kubernetes、Docker（新版）、以及很多云原生基础设施中被广泛使用。

¶1. containerd-shim-runc-v2 的定位和作用

containerd 是一个高性能的容器运行时，负责管理容器的生命周期（创建、启动、停止等）。
runc 是一个实现了 OCI（Open Container Initiative）标准的底层容器运行工具，负责真正的“跑”出容器进程。
containerd-shim（shim 就是“垫片”/“中间层”）的作用，是在 containerd 和 runc 之间做隔离和管理。

¶为什么需要 shim？

如果 containerd 直接 fork/exec runc 运行容器，一旦 containerd 挂掉或重启，所有容器也会被杀死（因为进程树断了）。
shim 的作用就是让容器进程和 containerd 解耦：

containerd 创建容器时，会启动一个 shim 进程（如 containerd-shim-runc-v2）。
shim 再调用 runc 创建真正的容器进程，并成为容器进程的父进程。
这样即使 containerd 重启，shim 还在，容器进程不会被影响。
shim 还负责管理容器的 IO（如日志）、信号转发、状态上报等。

¶2. v2 是什么意思？

containerd 早期有 shim v1，后来引入了“runtime v2”架构，允许不同的容器 runtime 插件（不仅仅是 runc），
containerd-shim-runc-v2 就是 v2 版本专门为 runc 实现的 shim。

¶3. 运行时你会看到什么？

在主机上用 ps aux | grep shim，你会看到很多 containerd-shim-runc-v2 进程，每个容器对应一个 shim 进程。
它们的生命周期和容器一致。

¶4. 总结一句话

containerd-shim-runc-v2 是 containerd 体系下，每个容器的“守护进程”，负责管理容器的生命周期和隔离，确保容器与 containerd 进程解耦。

¶参考图示

1	`[containerd] --(启动/管理)--> [containerd-shim-runc-v2] --(调用)--> [runc] --> [容器进程]`

containerd-stress

containerd-stress 是 containerd 项目下的一个测试工具，运行在worker node上面，主要用于对 containerd 进行压力测试（stress test），以验证和评估 containerd 在高并发、高负载等极端场景下的稳定性和性能。

¶详细解释

¶1. containerd-stress 是什么？

containerd-stress 是 containerd 官方仓库（containerd/containerd）自带的一个测试工具。
它的主要作用是批量、自动化地创建和销毁大量容器，模拟高并发操作，从而测试 containerd 的性能、稳定性和资源管理能力。

¶2. 常见用途

验证 containerd 在大规模创建/销毁容器时是否有内存泄漏、死锁、崩溃等问题。
评估 containerd 在极端负载下的处理能力和响应速度。
检查 containerd 在高并发情况下的正确性和健壮性。

¶3. 工作原理

它会通过 containerd 的 API，批量并发地发起容器创建、启动、停止、销毁等操作。
可以配置并发数、容器数量、操作类型、持续时间等参数，根据需要灵活调整压测强度。

¶4. 适用人群

containerd 的开发者：用于开发阶段的回归和压力测试。
云厂商/运维人员：评估 containerd 在生产环境下的极限性能或稳定性。

¶5. 和 containerd/runc 的关系

containerd-stress 只是一个测试工具，不参与生产环境的容器管理。
它会通过 containerd，间接调用 runc 去实际创建和运行容器。

¶参考资料

¶总结一句话

containerd-stress 是 containerd 官方的压力测试工具，用于批量、高并发地创建和销毁容器，评估 containerd 的性能和稳定性。

crictl

crictl 是一个用于与 CRI（Container Runtime Interface）兼容的容器运行时（比如 containerd、CRI-O）进行交互的命令行工具。

¶详细解释

¶1. crictl 是什么？

crictl 由 Kubernetes 社区（kubernetes-sigs/cri-tools 项目）维护。
它是一个类似于 docker 命令的工具，但它不是给 Docker 用的，而是专门用来操作符合 CRI 标准的容器运行时。
主要用于调试、排查和管理 Kubernetes 节点上的容器和镜像。

¶2. 为什么需要 crictl？

在 Kubernetes 1.6+，Kubelet 通过 CRI 与底层容器运行时（如 containerd、CRI-O）通信，而不是直接和 Docker 通信。
docker 命令无法直接管理 containerd、CRI-O 里的容器。
crictl 能直接和这些运行时交互，进行容器、镜像、Pod 的管理和排查。

¶3. 常用功能/命令

查看所有 Pod/容器/镜像
1
2
3
crictl pods crictl ps -a crictl images
查看日志
1
crictl logs <容器ID>
进入容器
1
crictl exec -it <容器ID> /bin/sh

删除容器/镜像

1 2	`crictl rm <容器ID> crictl rmi <镜像ID>`

¶4. 和 docker 命令的区别

功能	docker	crictl
面向运行时	Docker Engine	CRI 兼容运行时（如 containerd、CRI-O）
用途	日常容器管理	Kubernetes 节点排查、调试
支持	Docker	containerd、CRI-O、Mirantis Container Runtime 等

¶5. 工作原理

crictl 通过 gRPC 或 Unix Socket 与本地的 CRI 运行时（如 containerd 的 containerd.sock）通信。
它只实现了 CRI 标准的 API，不关心底层实现细节。

¶总结一句话

crictl 是 Kubernetes 官方推荐的 CRI 运行时命令行工具，用于调试和管理 containerd、CRI-O 等容器运行时中的容器和镜像。

ctr

ctr 是 containerd 的官方命令行客户端工具。
主要用于直接和 containerd 守护进程交互，执行容器管理相关的底层操作。
适合做调试、开发、底层运维，不建议日常生产环境直接用它管理容器。

¶`ctr` 的主要用途

管理镜像（拉取、推送、查看等）
管理容器（创建、启动、停止、删除等）
管理快照、命名空间等 containerd 相关资源

¶为什么叫 `ctr`？

ctr 是 “container” 的缩写，表示它是 containerd 的客户端工具。

¶`ctr` 和 `crictl`、`docker` 的区别

ctr：直接操作 containerd，功能全但偏底层，界面不友好，主要给开发者和调试用。
crictl：是基于 Kubernetes 的 CRI（容器运行时接口）标准的命令行工具，主要用于 Kubernetes 集群环境下的容器调试。
docker：是 Docker 引擎的命令行工具，使用体验最好，功能丰富，适合日常开发和生产。

¶常用命令举例

# 查看所有命名空间
ctr namespaces list

# 查看所有镜像
ctr -n k8s.io images list

# 拉取镜像
ctr -n k8s.io images pull docker.io/library/nginx:latest

# 创建并启动一个容器
ctr -n k8s.io run -t --rm docker.io/library/nginx:latest mynginx /bin/sh

-n k8s.io 指定命名空间，Kubernetes 默认用 k8s.io。

¶总结

ctr 是 containerd 的底层命令行工具，适合做调试和底层管理。
一般日常开发用 docker，Kubernetes 环境下用 crictl，只有特殊需求才用 ctr。

kube-proxy

kube-proxy 是 Kubernetes 集群中的一个核心组件，主要负责为集群中的 Service 提供网络代理和负载均衡功能。

¶详细解释

¶1. 作用

Service 访问代理：kube-proxy 让你可以通过 Service IP（ClusterIP、NodePort、LoadBalancer 等）访问后端 Pod。
负载均衡：当一个 Service 后面有多个 Pod 时，kube-proxy 会把流量分发到这些 Pod 上，实现流量的均衡分配。
网络规则管理：kube-proxy 会在每个节点上维护网络规则（如 iptables、ipvs 或 userspace 规则），确保服务流量能够正确转发到后端 Pod。

¶2. 工作原理

运行位置：kube-proxy 以 DaemonSet 方式运行在每个节点上。
监听 Service 和 Endpoints：它会监听 Kubernetes API Server，获取 Service 和 Endpoints 的变化。
维护转发规则：
- iptables 模式：通过修改 iptables 规则，将 Service 的 IP/端口流量转发到对应的 Pod。
- ipvs 模式：利用 Linux 的 IPVS 进行四层负载均衡，性能更高。
- userspace 模式（较老，已不常用）：直接在用户态转发流量，性能较低。

¶3. 举例说明

当你访问一个 Service 的 ClusterIP（比如 10.96.0.1:80），
- kube-proxy 会把你的请求转发到 Service 后端的某个 Pod（比如 172.17.0.3:8080）。
- 你不用关心 Pod 的 IP，kube-proxy 会自动维护和更新这些转发规则。

¶4. 常见问题解答

kube-proxy 挂了会怎样？
新的 Service 或 Pod 规则无法下发，已有规则还能用，但网络变更不会生效。
kube-proxy 和 ingress 有什么区别？
- kube-proxy 负责集群内部 Service 的四层（L4）代理和负载均衡。
- ingress 负责 HTTP/HTTPS 等七层（L7）代理，处理外部流量进来时的路由和转发。

¶总结

kube-proxy 是 Kubernetes 节点上的网络代理，负责实现 Service 的访问和负载均衡。

kubelet

kubelet 是 Kubernetes 集群中每个节点（无论是 Master 还是 Worker）上都运行的一个核心组件。它的主要作用是负责管理本节点上的 Pod 生命周期，确保 Pod 按照期望的状态运行。

¶详细理解

¶1. kubelet 的主要职责

与 kube-apiserver 通信：
kubelet 会定期向 kube-apiserver 拉取本节点上应该运行哪些 Pod（即 PodSpec）。
Pod 生命周期管理：
kubelet 负责启动、停止、监控这些 Pod（底层通常调用容器运行时，比如 containerd、Docker）。
健康检查：
kubelet 会定期检查 Pod 和容器的健康状况（liveness/readiness probe），并根据需要重启或报告状态。
节点状态上报：
kubelet 会把节点的状态（比如资源使用情况、Pod 状态等）上报给 kube-apiserver。
卷挂载和日志收集：
管理本地或远程存储卷的挂载，以及容器日志的收集和转发。

¶2. kubelet 的工作流程

监听 kube-apiserver
- kubelet 监听 apiserver，拉取分配到本节点的 Pod 列表。
创建/删除 Pod
- 如果发现有新 Pod 需要运行，就调用容器运行时（如 containerd）创建容器。
- 如果发现有 Pod 被删除，就停止并清理对应的容器。
状态同步
- kubelet 持续监控容器的运行状态，并把信息同步到 apiserver。
健康检查
- kubelet 按照 Pod 的探针配置（liveness/readiness）做健康检查，必要时重启容器。

¶3. kubelet 和其他组件的关系

kube-apiserver：
kubelet 通过 apiserver 获取期望的 Pod 列表，并上报节点和 Pod 状态。
容器运行时（CRI）：
kubelet 通过 CRI（Container Runtime Interface）与 Docker、containerd 等容器运行时通信，真正创建和管理容器。
cAdvisor：
kubelet 内置 cAdvisor，用于收集节点和容器的资源使用数据。

¶图示关系

kube-apiserver
     ▲  ▲
     │  │
     │  │  (PodSpec、状态上报)
     │  │
kubelet (每个节点)
     │
     │  (通过 CRI)
     ▼
容器运行时（containerd/Docker）
     │
     ▼
Pod/容器

¶总结一句话

kubelet 就像是每个节点的“管家”，负责让本节点上的 Pod 按照 apiserver 的指令健康、稳定地运行。

一堆网络插件

cni-plugins 是 Kubernetes/容器网络领域最基础的网络插件工具集，由 containernetworking/plugins 项目维护。
它包含了一组二进制工具，每个工具实现了一种网络功能，CNI（Container Network Interface）规范就是通过这些插件来配置和管理容器网络的。

¶常见 CNI Plugins 及用途

下面是 cni-plugins 目录下常见的二进制工具及其作用：

插件名	作用简介
bridge	创建 Linux bridge，分配 IP，最常见的 Pod 网络
host-local	本地 IP 地址管理/分配
loopback	配置容器的 loopback 网络接口（127.0.0.1）
ipvlan	用 ipvlan 驱动创建接口，适合高性能网络
macvlan	用 macvlan 驱动创建接口，容器有独立 MAC
ptp	点对点连接（veth pair），常用于多主机通信
dhcp	通过 DHCP 为容器分配 IP
flannel	与 flannel 协作，管理 overlay 网络
tuning	调整网络接口参数（如 MTU、队列等）
vlan	用 VLAN tag 创建接口，适合多租户隔离
firewall	配置 iptables 防火墙规则
portmap	实现端口映射（hostPort）
bandwidth	限制容器带宽
static	静态分配 IP

¶举几个典型用法

bridge + host-local
最常用的组合。bridge 插件创建网桥，host-local 插件分配 IP 地址，Pod 通过 veth pair 接入 bridge，能和同节点其它 Pod 通信。
loopback
每个容器都需要配置 loopback 网络（127.0.0.1），loopback 插件自动完成。
portmap
支持 Kubernetes 的 hostPort 功能，把容器端口映射到主机端口。
firewall
给容器加 iptables 规则，限制流量。
tuning
用于调整容器网卡参数，比如 MTU。

¶CNI Plugins 目录结构示例

通常你会看到类似：

/opt/cni/bin/
├── bandwidth
├── bridge
├── dhcp
├── firewall
├── flannel
├── host-local
├── ipvlan
├── loopback
├── macvlan
├── portmap
├── ptp
├── static
├── tuning
├── vlan

¶总结

cni-plugins 不是单一插件，而是一组实现了不同网络功能的可执行文件。
Kubernetes、Docker、Containerd 等容器运行时通过调用这些插件来配置容器网络。
你可以根据需要选择/组合不同插件来实现不同的网络拓扑和功能。

k8s-note

#k8s笔记

【K8s笔记】kubernetes的相关组件

https://学习.fun/k8s-note/k8s-util/

Author

Stephen Zeng

Posted on

April 29, 2025

Licensed under

【K8s笔记】docker Previous

【K8s笔记】etcd Next

【K8s笔记】kubernetes的相关组件

kube-apiserver

¶kube-apiserver 的作用

¶你可以这样理解

¶工作流程举例

¶图示

¶总结一句话

kube-controller-manager

¶主要作用

¶工作流程举例

¶图示

¶总结一句话

kube-scheduler

¶工作原理

¶图示流程

¶总结

containerd-shim-runc-v2

¶1. containerd-shim-runc-v2 的定位和作用

¶为什么需要 shim？

¶2. v2 是什么意思？

¶3. 运行时你会看到什么？

¶4. 总结一句话

¶参考图示

containerd-stress

¶详细解释

¶1. containerd-stress 是什么？

¶2. 常见用途

¶3. 工作原理

¶4. 适用人群

¶5. 和 containerd/runc 的关系

¶参考资料

¶总结一句话

crictl

¶详细解释

¶1. crictl 是什么？

¶2. 为什么需要 crictl？

¶3. 常用功能/命令

¶4. 和 docker 命令的区别

¶5. 工作原理

¶总结一句话

ctr

¶ctr 的主要用途

¶为什么叫 ctr？

¶ctr 和 crictl、docker 的区别

¶常用命令举例

¶总结

kube-proxy

¶详细解释

¶1. 作用

¶2. 工作原理

¶3. 举例说明

¶4. 常见问题解答

¶总结

kubelet

¶详细理解

¶1. kubelet 的主要职责

¶2. kubelet 的工作流程

¶3. kubelet 和其他组件的关系

¶图示关系

¶总结一句话

一堆网络插件

¶常见 CNI Plugins 及用途

¶举几个典型用法

¶CNI Plugins 目录结构示例

¶总结

¶`ctr` 的主要用途

¶为什么叫 `ctr`？

¶`ctr` 和 `crictl`、`docker` 的区别