K8s和K3s，如何选择？
大家好，我是猿java。
随着容器化技术的普及和微服务架构的广泛应用，K8s逐渐成为行业标准的容器编排平台。然而，K8s 的复杂性和资源消耗在某些场景下成为限制因素。为了解决这些问题，Rancher Labs 推出了轻量级的 K8s发行版-K3s。这篇文章，我们将对 K3s 与 K8s 进行详细的分析与对比。
1. K8s
1.1 什么是 K8s?
K8s（Kubernetes）是一个开源的容器编排平台，由 Google发起，目前由云原生计算基金会（CNCF）维护，旨在自动化部署、扩展和管理容器化应用，为分布式系统提供强大的工具链和平台。
1.2 K8s的核心组件
1. Master 节点组件：
- kube-apiserver：提供 Kubernetes API 服务，是整个集群的控制平面。
- etcd：分布式键值存储，用于保存集群的全部数据。
- kube-scheduler：负责将 Pods 调度到合适的节点上。
- kube-controller-manager：运行各种控制器，管理集群状态。
2. Worker 节点组件：
- kubelet：负责与节点上容器运行时通信，管理 Pod 生命周期。
- kube-proxy：处理网络代理和负载均衡。
- 容器运行时：如 Docker、containerd 等，执行容器。
如下图：
1.3 K8s的工作原理
Kubernetes通过声明式的配置管理集群状态，用户通过 YAML 或 JSON 文件描述期望的集群状态，K8s 通过其控制器不断调整实际状态以匹配期望状态。调度器决定 Pod 运行的位置，控制器管理 Pods、ReplicaSets、Deployments 等资源，确保应用的高可用与可扩展。
2. K3s
2.1 什么是 K3s?
K3s 是由 Rancher Labs 开发的轻量级 Kubernetes 发行版，旨在简化 Kubernetes 的部署和管理，适用于资源受限的环境，如边缘计算、物联网（IoT）设备等。K3s 减少了 Kubernetes 的一些组件和依赖，使其更加轻便且易于安装。
2.2 K3s的核心组件
- 简化的控制平面：将多个组件打包，减少资源占用。
- 轻量级的 etcd：使用 SQLite 作为默认数据存储，也支持外部 etcd。
- 内置的网络插件：采用 Flannel 作为默认 CNI 插件。
- 内置的服务与关联工具：如 Traefik 作为默认的 ingress 控制器。
如下图：
2.3 K3s的工作原理
K3s 在保持 Kubernetes 核心功能的基础上，通过移除不必要的插件和组件、优化代码结构，减少了资源消耗和复杂度。它支持 ARM 架构，适合在边缘设备上运行，并提供一键安装脚本，简化了部署过程。
3. K3s 与 K8s的对比
虽然 K3s支持大多数Kubernetes的API和功能，但它有以下关键特点使其与众不同：
- 更低的资源需求：K3s比完整的Kubernetes集群占用更少的内存、CPU和磁盘空间，使其成为资源受限环境的理想选择。
- 更简便的安装与维护：K3s可以通过一个命令快速安装，无需繁琐的配置过程。它还能自动处理证书管理和其他日常任务，进一步简化了部署和维护。
- 单一二进制文件：与Kubernetes将组件拆分为多个二进制文件不同，K3s将所有必要的组件集成到一个二进制文件中。这不仅减少了攻击面，也简化了更新和维护。
- 更轻量级的联网：K3s采用了一种更轻量级的联网方式，减少了对网络组件如kube-proxy的需求，并简化了复杂的联网设置。
- 精简的功能集：尽管 K3s支持大多数核心Kubernetes功能，但它有意排除了一些高级特性，如自动扩展和高级网络插件支持。这种设计选择使得K3s能够保持其轻量级特性，专注于核心功能。
| 特性/方面 | K3s | K8s（传统 Kubernetes） |
|---|---|---|
| 资源消耗 | 显著较小的占用 | 占用较大，资源需求较高 |
| 安装复杂度 | 简单，单一命令安装 | 设置复杂，需要配置多个组件 |
| 架构 | 单体架构，所有组件集成在一个二进制文件中 | 模块化架构，组件分离（API 服务器、etcd、调度器等） |
| 部署简易性 | 需要最少的设置和配置 | 需要详细的配置和安装程序 |
| 网络模型 | 轻量级，减少了网络开销 | 更全面的网络模型，包含 kube-proxy |
| 功能集 | 支持核心 Kubernetes 功能 | 支持全套 Kubernetes 功能，包括高级能力 |
| 目标环境 | 边缘计算、物联网、本地开发 | 数据中心、云环境、大规模部署 |
| 用例 | 资源受限的环境 | 大规模应用，复杂架构 |
| 社区和支持 | 社区强大，支持不断增长 | 成熟的生态系统，来自 CNCF 和贡献者的广泛支持 |
| 更新和维护 | 更新和维护简化 | 定期更新，升级过程可能更复杂 |
| 高级功能 | 排除了一些高级功能，如水平 Pod 自动扩展、复杂网络插件 | 支持 Kubernetes 的全套功能，包括自动扩展、广泛的网络选项 |
4. 如何选择？
4.1 使用场景分析
K8s比较适合以下的场景：
- 大规模企业应用：需要支持数千个 Pod、复杂的服务网格和多租户环境。
- 高可用性系统：需要支持多数据中心部署、自动故障恢复和滚动更新。
- 复杂的 CI/CD 流水线：需要集成多种工具和自动化流程。
K3s比较适合以下的场景：
- 边缘计算节点：需要在资源受限的边缘设备上运行，且对延迟敏感。
- 物联网应用：设备数量多且多为低功耗、低性能设备。
- 开发与测试环境：快速搭建轻量级集群，方便开发人员进行测试和迭代。
4.2 性能与资源考虑
- 如果环境资源充足，且需要全面的 Kubernetes 功能支持，选择 K8s。
- 如果资源有限，或需要在嵌入式设备、边缘节点上运行，选择 K3s。
4.3 管理与维护
- K8s：维护复杂，需要专业的 DevOps 团队，适合有能力管理大规模集群的企业。
- K3s：维护简便，适合小团队或希望快速部署容器编排平台的用户。
4.4 成本效益
- K8s：可能需要更多的硬件资源和人力投入，适合需要高性能和高可用性的应用。
- K3s：降低了硬件和管理成本，适合预算有限或希望快速上线的项目。
5. 结论
本文，我们分析以及对比了 K8s 和 K3s，K8s作为当前最流行的容器编排平台，拥有强大的功能和广泛的社区支持，适用于大规模和复杂的应用场景。然而，K8s 的资源消耗和复杂性在某些场景下成为限制因素。K3s 作为轻量级的 K8s 发行版，通过简化架构和减少资源占用，填补了在资源受限环境下的需求。
在实际应用中，选择 K3s 还是 K8s，应根据具体的应用场景、资源情况和管理能力来决定。对于需要全面功能支持和高可用性的企业级应用，K8s 依然是首选；而对于边缘计算、物联网、小规模部署或快速开发测试环境，K3s 则是更为合适的选择。
6. 学习交流
如果你觉得文章有帮助，请帮忙转发给更多的好友，或关注公众号：猿java，持续输出硬核文章。
