【AI 总结】Kubernetes 概述

Kubernetes Overview | AI 总结

一、基本信息

1. 名称含义：“Kubernetes” 源于希腊语，意为 “舵手” 或 “飞行员”；缩写 “K8s” 因 “K” 与 “s” 之间有 8 个字符而得名。
2. 开源背景：由 Google 于 2014 年开源，其构建基于 Google 十几年大规模运行生产工作负载的经验，并融合了社区优秀想法与实践。
3. 平台定位：可移植、可扩展的开源平台，用于管理容器化的工作负载和服务，支持声明式配置与自动化，拥有庞大且快速增长的生态系统。

二、核心功能：为何需要 Kubernetes

Kubernetes 为分布式系统提供弹性运行框架，核心功能涵盖多方面，具体如下：

功能类别	具体说明
服务发现与负载均衡	支持通过 DNS 名称或自身 IP 地址暴露容器，流量过大时可均衡分配网络流量，保障部署稳定
存储编排	允许自动挂载用户选择的存储系统，如本地存储、公共云提供商的存储等
自动部署和回滚	支持描述容器所需状态，以受控速率将实际状态调整为期望状态，可自动化完成新容器创建、旧容器删除及资源转移
自动装箱计算	接收由多个节点组成的集群及容器 CPU、内存需求，将容器合理调度到节点上，实现资源最优利用
自我修复	能重启失败容器、替换故障容器、终止不响应用户定义健康检查的容器，且在容器准备好服务前不向客户端通告
密钥与配置管理	可存储管理密码、OAuth 令牌、SSH 密钥等敏感信息，无需重建容器镜像即可部署更新密钥和应用配置，避免密钥在堆栈配置中暴露
批处理执行	除管理服务外，还能管理批处理和 CI 工作负载，必要时可替换失败容器
水平扩缩	支持通过简单命令、用户界面，或依据 CPU 使用率自动对应用进行扩缩容
IPv4/IPv6 双栈	可为 Pod（容器组）和 Service（服务）分配 IPv4 与 IPv6 地址
可扩展性设计	无需修改上游源代码，即可为 Kubernetes 集群添加功能

▶

什么是服务发现和负载均衡

1. 服务发现解决的是 “如何找到某个服务” 的问题

在 K8s 中，Pod 的 IP 地址是动态的（Pod 可能会被销毁并重新创建，每次分配的 IP 都不同）。如果没有服务发现，客户端就无法准确知道该访问哪个 IP。

• 实现方式： K8s 通过 Service 资源提供了一个统一的入口。
• 如何工作： 你在文档中提到的 “通过 DNS 名称或自身 IP 地址暴露容器”，指的就是 K8s 内置的 CoreDNS。它会为每个 Service 分配一个固定的域名（如 my-service.default.svc.cluster.local）。
• 直白理解： 就像手机通讯录。你不需要记住朋友（Pod）经常变动的临时电话号码，只需要拨打他的名字（DNS 名称），通讯录（服务发现机制）就会自动帮你转接到他当前的号码上。

2. 负载均衡 解决的是 “如何分配流量” 的问题

当你有一个服务的多个副本（多个 Pod）时，负载均衡器会确保请求不会全部涌向某一个 Pod，从而导致其过载，而其他 Pod 却在闲置。

• 实现方式： K8s 的 Service 本身就具备基本的负载均衡功能（通常通过 iptables 或 ipvs 实现）。
• 如何工作： 正如你文中所说，“流量过大时可均衡分配网络流量”。当流量到达 Service 的统一入口时，它会根据策略（通常是轮询）将请求分发到后端健康的多个 Pod 实例中。
• 直白理解： 就像银行的排队系统。客户（流量）先到一个取号机（Service 入口），取号机根据各个窗口（Pod）的忙闲情况，指引客户去不同的窗口办理业务，保障整个系统的 “部署稳定”。

▶

什么是自动装箱计算 (Bin Packing)

1. 它解决的是 “资源分配自动化” 的问题

在没有 K8s 之前，运维人员需要手动查看哪台服务器还有空余内存，然后决定把程序部署在哪。在机器成百上千的情况下，这几乎是不可能完成的任务。

2. 核心逻辑：需求 vs 供应

• 需求：你在配置文件中定义的容器 CPU 和内存需求（Resource Requests）。
• 供应：集群中各个节点剩余的可分配资源。
• 过程：调度器（Scheduler）像玩俄罗斯方块一样，根据算法把 Pod 放置在资源最匹配的节点上。

3. 直白理解：高效的行李规划

就像你要去旅行，有很多大小不一的衣服和设备。如果你随便塞，可能需要三个行李箱；但如果你精于 “装箱计算”，可能一个行李箱就能全部装下。在 K8s 中，这种 “精打细算” 不仅节省了服务器成本（箱子），还保证了每个应用都有足够的空间（资源）运行。

三、边界定义：Kubernetes 不是什么

1. 非传统 PaaS 系统：虽在容器级别提供部署、扩展、负载均衡等类似 PaaS 的功能，且支持集成日志记录、监控和警报方案，但并非单体式系统，默认解决方案可选、可插拔，为构建开发人员平台提供基础并保留用户选择权。
2. 功能局限性：
   • 不限制应用类型，可支持无状态、有状态、数据处理等多种容器化工作负载；
   • 不部署源代码、不构建应用，CI/CD 工作流取决于组织文化、偏好及技术要求；
   • 不提供中间件、数据处理框架、数据库等应用级内置服务，此类组件可在 Kubernetes 上运行或通过开放服务代理等可移植机制访问；
   • 不是日志记录、监视或警报的完整解决方案，仅集成部分概念证明功能并提供指标收集导出机制；
   • 不指定配置语言或系统，仅提供可由任意声明性规范构成的声明性 API；
   • 不提供或采用全面的机器配置、维护、管理及自我修复系统。
3. 非传统编排系统：不依赖 “先执行 A、再执行 B、最后执行 C” 的固定工作流程，而是通过一组独立可组合的控制过程，持续将当前状态驱动至预期状态，无需集中控制，提升系统易用性、健壮性、弹性与可扩展性。

▶

传统的 PaaS 系统是什么

“传统的 PaaS 系统”（Platform as a Service，平台即服务），是指在云计算早期流行的一种服务模式，其代表产品包括早期的 Heroku、Google App Engine (GAE) 和 Cloud Foundry 等。

1. 强绑定与限制（Opinionated）

• 传统 PaaS：通常是 “非常有主见” 的系统。它们会规定你必须使用哪种编程语言（如 Java、Python、Ruby）、哪种框架、以及哪种数据库。开发者必须按照平台的规则来编写和打包代码。
• K8s 的区别：它不限制应用类型。只要你能把应用打成容器镜像，无论是 Go、C++ 还是旧式的遗留系统，K8s 都能运行。

2. 单体式架构 vs. 可插拔

• 传统 PaaS：通常是一个 “全家桶” 方案。它内置了日志记录、监控、路由、部署流等所有功能。虽然开箱即用很方便，但你很难把其中的某个组件换掉（比如你想换一个特定的日志搜集工具）。
• K8s 的区别：文中提到的 “并非单体式系统”，指的就是 K8s 只提供核心的调度和编排能力。至于日志用 ELK 还是 Fluentd，监控用 Prometheus 还是 Datadog，都是可选且可插拔的。

3. 构建流程的差异

• 传统 PaaS：通常支持 git push 后直接在云端构建源代码（Source-to-Image）。它接管了从代码到运行的整个流水线。
• K8s 的区别：K8s 不部署源代码，也不构建应用。它只管运行你已经构建好的镜像。CI/CD 流水线（如 Jenkins, GitLab CI, GitHub Actions）需要你根据自己的需求额外搭建。

4. 目标受众

• 传统 PaaS：目标是让开发者完全无感。开发者只需要关心业务逻辑，底层的一切都被屏蔽了。但这带来的代价是 “黑盒” 化，一旦出现平台级故障，开发者很难排查。
• K8s：被称为 “构建平台的平台”。它的目标是给运维和架构师提供基础工具，让他们能根据业务需求，搭建出一套最适合自己公司的自定义 PaaS 环境。

总结：文档中之所以强调 K8s 是 “非传统 PaaS”，是为了说明：Kubernetes 提供了 PaaS 的能力（如自动扩缩容、负载均衡），但保留了像底层基础设施（IaaS）那样的极高自由度。 它不替你做所有决定，而是让你拥有选择权。

四、部署技术演进史

1. 传统部署时代
   • 应用运行于物理服务器，无法限制单应用资源使用，易出现资源分配问题，如单应用占用大量资源导致其他应用性能下降；
   • 若为每个应用分配独立物理服务器，会存在资源利用率低、硬件维护成本高的问题。
2. 虚拟化部署时代
   • 引入虚拟化技术，支持在单物理服务器 CPU 上运行多台虚拟机（VM），实现应用间隔离与一定安全性；
   • 可提升物理服务器资源利用率，增强应用可扩缩性，降低硬件成本，能将物理资源转化为可丢弃的虚拟机集群；
   • 缺点是每台 VM 为完整计算机，需在虚拟化硬件上运行包含操作系统在内的所有组件，资源消耗较高。
3. 容器部署时代
   • 容器类似 VM 但隔离性更宽松，可共享操作系统，更轻量，且拥有独立文件系统、CPU、内存、进程空间；
   • 具备跨云、跨 OS 发行版本移植性，还拥有敏捷创建部署、支持持续开发集成部署、分离开发与运维、高可观察性、环境一致性、应用级管理、微服务适配、资源隔离与高效利用等优势。

五、后续学习路径

1. 查阅 Kubernetes 组件相关内容；
2. 了解 Kubernetes API；
3. 学习 Cluster（集群）架构；
4. 着手进行 Kubernetes 的建置实践。