K8s 还是 K3s？This is a question

自 k3s 问世以来，社区里有许多小伙伴都问过这样的问题“除了中间的数字之外，k3s 和 K8s 的区别在哪里？”，“在两者之间应该如何选择？”。本文将简单介绍它们两者的区别。

什么是 Kubernetes?

正如大家所了解到的那样，Kubernetes 是一个“容器编排平台”，也就是说你可以从一组机器中选择其中之一来运行你所需要使用的容器。

它也处理诸如升级你的容器之类的事情，所以如果你发布网站的新版本，它会逐渐使用新版本来启动容器，并放弃旧版本，这一过程仅需一到两分钟。

那么，究竟什么是 K8s？

K8s 是 Kubernetes 的缩写，因为在 K 和 s 之间有 8 个字母，故称 K8s。然而，通常情况下，无论人们谈论的是 Kubernetes 还是 K8s，他们正在说的是原生上游的 Kubernetes，由 Google 所设计的一个真正高可用且可扩展的平台。

问题是，虽然你可以使用诸如 Minikube 之类的工具在本地计算机上运行 Kubernetes，但是如果要在生产环境中运行它，你将很快获得一些“最佳实践”的建议，如：

1. 将你的节点和 master 分开，使用你的 master 运行控制平面，使用你的节点运行工作负载，两者永远也不会见面

2. 在独立的集群上运行 etcd，以确保它能够处理负载

3. 理想状态下，分离 Ingress 节点，以便它们能够轻松处理进入的流量，即便一些底层节点已经十分忙碌

很快，你将拥有 3 倍的 K8S master、3 倍的 etcd、2 倍的 Ingress 以及你的节点。所以在你到达需要询问“我的站点需要多少个节点”这一阶段之前，实际情况下你至少已经有了 8 个中型实例。

别误会，我不是在指责这些建议不好。相反，如果你正在运行一个生产工作负载，那么这些建议是十分明智的。毕竟，没有比在星期五晚上调试过载的停机生产集群更糟糕的了！

但是，如果你只是想学习 Kubernetes，或者给一些非核心的应用托管一个 development/staging 集群，那么采纳上述建议就有些“杀鸡用牛刀“的感觉了，不是吗？至少对我来说是这样的。如果我只是想启动集群来查看我的 Kubernetes manifest（包括部署配置等等）是否是正确的，我并不愿意每月为此付出几百元。

k3s 的优势在哪里？

Rancher Labs 是业界领先的容器软件提供商，其旗舰产品 Rancher 是一款开源的企业级 Kubernetes 管理平台，极为出色地管理和安装 Kubernetes 集群。他们发布了一系列产品，构成他们的生态，例如，Longhorn 是一个轻量级并且可靠的容器化分布式块存储解决方案，可用于 Kubernetes 中，并在近期被收纳入 CNCF 沙箱项目中。闲杂让我们回到这篇文章的主题，Rancher Labs 也是 k3s 这款轻量级 Kubernetes 发行版的创建者。

k3s 将安装 Kubernetes 所需的一切打包进仅有 60MB 大小的二进制文件中，并且完全实现了 Kubernetes API。为了减少运行 Kubernetes 所需的内存，Rancher 删除了很多不必要的驱动程序，并用附加组件对其进行替换。

k3s 是一款完全通过 CNCF 认证的 Kubernetes 发行版，这意味着你可以编写 YAML 来对完整版的 Kubernetes 进行操作，并且它们也将适用于 k3s 集群。

由于它只需要极低的资源就可以运行，因此它能够在任何 512MB RAM 以上的设备上运行集群，换言之，我们可以让 pod 在 master 和节点上运行。

当然，既然它是一个小型的二进制文件，那么我们可以在短时间内安装它，相比于启动常规 Kubernetes 集群，安装它仅需一小部时间。通常我们仅需要不到 2 分钟的时间就能够启动一个带有几个节点的 k3s 集群，也就是说，你可以一有机会就部署应用程序来学习或者进行测试。

听起来不错，实际如何呢？

当人们提到 Kubernetes 时，他们想到的是如果节点死亡，容器会自动在其他节点上启动，容器之间的负载均衡、隔离和滚动部署，所有这些优点在完整版的 Kubernetes 和 k3s 之间是相同的。

但是，k3s 并不总是只有优点，否则的话每个人都会去使用 k3s。那么，为什么有些人没有使用 k3s 呢？

首先，当前 k3s 的版本（k3s v0.8.1）仅能运行单个 master，这意味着如果你的 master 宕机，那么你就无法管理你的集群，即便已有集群要继续运行。但是在 k3s v0.10 的版本中，多主模式已经是实验性功能，也许在下一个版本中能够 GA。

其次，在单个 master 的 k3s 中，默认的数据存储是 SQLite，这对于小型数据库十分友好，但是如果遭受重击，那么 SQLite 将成为主要痛点。但是，Kubernetes 控制平面中发生的更改更多是与频繁更新部署、调度 Pod 等有关，因此对于小型开发/测试集群而言，数据库不会造成太大负载。

结语

K8s 和 k3s 各有优劣，使用场景也有所区别，因此不能一概而论。如果你要进行大型的集群部署，那么我建议你选择使用 K8s；如果你处于边缘计算等小型部署的场景或仅仅需要部署一些非核心集群进行开发/测试，那么选择 k3s 则是性价比更高的选择。

赶紧试试看吧！