目录

引言：为什么需要K8s?

一、什么是K8s

二、K8s的核心功能

三、K8s的核心架构

---

引言：为什么需要K8s?

当你只有一个 Docker 容器时，你的工作很简单：docker run 就够了。这就像养一盆绿植，偶尔浇浇水（重启容器）就行。

但当业务起来后，你需要同时运行 10 个、100 个容器实例时，事情就变了：

        你需要自动扩容应对高峰，而不是半夜爬起来手动开服务器；

        你需要自动恢复处理宕机，而不是等用户投诉才发现服务挂了；

        你需要滚动更新发布版本，而不是登录 10 台机器敲一样的命令。

手动管理大量容器的复杂度呈指数级上升，你需要的不是更多的“运维手”，而是一个容器编排平台。

这就是 Kubernetes 诞生的意义。它通过声明式 API 和强大的自动化能力，让管理成百上千个容器变得像管理一个容器一样简单。

一、什么是K8s

K8s（全称 Kubernetes）是一个开源的容器编排平台，用于自动部署、扩展和管理容器化应用程序。

“K8s” 这个名字来自于 “Kubernetes” 的首字母 “K” 和尾字母 “s”，中间 8 个字母缩写为 8，所以简称为 K8s。

可以这样来理解：如果你用 Docker 等容器技术打包应用，当容器数量很少时手动管理还行；一旦有几十、上百甚至上千个容器在运行，就需要一个“指挥官”来自动调度、监控、恢复、扩容——这个指挥官就是 K8s。

二、K8s的核心功能

1.自动部署与回滚：可以声明想要的应用程序状态，例如运行 3 个 nginx 实例，K8s 会自动达到该状态。发布新版本时支持滚动更新，出现问题了可以一键回滚。

2.服务发现与负载均衡：K8s可以自动给容器分配 IP 和 DNS 名称，并在多个容器副本之间分发流量，不需要手动配置负载均衡器。

3.水平自动扩缩：可以根据 CPU、内存或自定义指标（如请求数）自动增加或减少容器副本数量，应对流量高峰和低谷。

4.自我修复：K8s能监控容器健康状态。如果某个容器崩溃、不响应健康检查或被节点删除，K8s 会自动重启、重新调度或替换它。

5.存储编排：K8s支持挂载多种存储系统（本地磁盘、云存储、NFS、Ceph 等），并在容器之间共享存储卷，存储的生命周期独立于容器。

6.配置与密钥管理：将配置信息（ConfigMap）和敏感信息（Secret）与应用代码分离，更新配置无需重新构建镜像，支持热更新。

7.批处理与定时任务：支持一次性任务（Job）和定时任务（CronJob），适用于数据处理、备份、报表生成等场景。

8.跨平台与可移植：可以在物理机、虚拟机、公有云、私有云、混合云上运行，主流云厂商（AWS、Azure、GCP、阿里云、腾讯云等）都提供托管 K8s 服务。

总结一下，K8s 就像是一个容器的“操作系统”或“航空管制中心”，让你在大规模容器环境中，无需关心每台机器在哪里、容器跑在哪个节点、要不要手动重启或扩容——你只需要声明“我要什么”，K8s 负责“给你实现”。

三、K8s的核心架构

K8s有两大组件：控制平面和工作节点，如果说控制平面公司管理层，工作节点就是一线员工。下面的图展示了这两大组件以及它们之间的交互关系。

控制平面是集群的“大脑”，负责全局决策和状态管理。它包含四个核心组件： API Server、Scheduler、Controller Manager、etcd。

API Server是整个 Kubernetes 控制平面的前端，也是唯一直接与用户、管理员或其它组件交互的入口，它暴露 Kubernetes API（默认监听 6443 端口），所有对集群的查询和变更操作都必须经过它。我们可以把它理解为集群的“接待大厅”和“安检口”：所有请求都先到这里，由它完成认证、授权和准入控制后，再交给后端组件处理。

Scheduler是调度器，它负责监视新创建的、尚未分配节点的 Pod，并为它们选择一个最合适的节点运行。调度时会综合考虑资源需求、节点负载、亲和性、数据本地性等多种因素。我们可以把它理解为集群的“房产中介”，它给每个新来的 Pod 分配一个“住处”，这个“住处”一般在工作节点。

Contronller Manager负责运行 K8s 中所有的控制器进程。每个控制器逻辑上是一个独立进程，但为了方便管理，它们被编译到同一个二进制文件中，运行在同一个进程里。他的核心职责是维持集群的期望状态，例如我们声明“要有 3 个 Pod”，控制器会不断检查实际数量，少了就创建、多了就销毁。我们可以把它理解为为集群的“监工”，它会持续对比“现状”与“期望”，并采取行动让两者一致。

etcd是K8s集群的后台数据库，所有集群状态数据都持久化保存在 etcd 中。它是集群的“记忆中枢”，只要etcd 记录了，集群就可以知道“当前应该是什么样”。

工作节点是实际运行容器的地方，包括 Kubelet、Kube Proxy、容器运行时。

kubelet运行在集群中每个节点上的代理程序，是节点的核心组件,负责确保容器在 Pod 中正常运行且处于健康状态。它会监听来自 kube-apiserver 的指令，并调用底层容器运行时（如 Docker、containerd）来启动、停止、检查容器。值得注意的是，kubelet 只管理由 Kubernetes 创建的容器；对于不是通过 K8s 启动的容器，kubelet 视而不见，不管理、不监控。

kube-proxy是一个网络代理，同样运行在集群的每个节点上，他的主要职责是维护节点上的网络规则，使得集群内部和外部的网络会话能够与 Pod 进行通信。如果操作系统提供了可用的数据包过滤层（如 Linux 的 iptables），kube-proxy 会优先使用它；如果没有提供，kube-proxy 会自行转发流量。

容器运行时是真正运行容器的底层引擎，例如 Docker、containerd、CRI-O。kubelet 通过容器运行时接口（CRI）调用它来执行容器的创建、启动、停止、销毁。

Pod是K8s中最小的调度和部署单元，一个 Pod 里可以包含一个或多个容器，Pod 内的容器共享网络、存储和 IPC 命名空间，可以通过 localhost 互相通信。