189 8069 5689
本文来自：Rancher Labs
创新互联服务紧随时代发展步伐，进行技术革新和技术进步，经过十多年的发展和积累，已经汇集了一批资深网站策划师、设计师、专业的网站实施团队以及高素质售后服务人员，并且完全形成了一套成熟的业务流程，能够完全依照客户要求对网站进行做网站、网站建设、建设、维护、更新和改版，实现客户网站对外宣传展示的首要目的，并为客户企业品牌互联网化提供全面的解决方案。
自k3s问世以来，社区里有许多小伙伴都问过这样的问题“除了中间的数字之外，k3s和K8s的区别在哪里？”，“在两者之间应该如何选择？”。本文将简单介绍它们两者的区别。
正如大家所了解到的那样，Kubernetes是一个“容器编排平台”，也就是说你可以从一组机器中选择其中之一来运行你所需要使用的容器。
它也处理诸如升级你的容器之类的事情，所以如果你发布网站的新版本，它会逐渐使用新版本来启动容器，并放弃旧版本，这一过程仅需一到两分钟。
K8s是Kubernetes的缩写，因为在K和s之间有8个字母，故称K8s。然而，通常情况下，无论人们谈论的是Kubernetes还是K8s，他们正在说的是原生上游的Kubernetes，由Google所设计的一个真正高可用且可扩展的平台。
问题是，虽然你可以使用诸如Minikube之类的工具在本地计算机上运行Kubernetes，但是如果要在生产环境中运行它，你将很快获得一些“最佳实践”的建议，如：
将你的节点和master分开，使用你的master运行控制平面，使用你的节点运行工作负载，两者永远也不会见面
在独立的集群上运行etcd，以确保它能够处理负载
很快，你将拥有3倍的K8S master、3倍的etcd、2倍的Ingress以及你的节点。所以在你到达需要询问“我的站点需要多少个节点”这一阶段之前，实际情况下你至少已经有了8个中型实例。
别误会，我不是在指责这些建议不好。相反，如果你正在运行一个生产工作负载，那么这些建议是十分明智的。毕竟，没有比在星期五晚上调试过载的停机生产集群更糟糕的了！
但是，如果你只是想学习Kubernetes，或者给一些非核心的应用托管一个development/staging集群，那么采纳上述建议就有些“杀鸡用牛刀“的感觉了，不是吗？至少对我来说是这样的。如果我只是想启动集群来查看我的Kubernetes manifest（包括部署配置等等）是否是正确的，我并不愿意每月为此付出几百元。
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则是性价比更高的选择。
赶紧试试看吧！