适用于本地化、集群、边缘计算和物联网的几款轻量级K8s：MicroK8s、K3s和K0s


关键任务应用程序需要一个有弹性的 Kubernetes 集群，它可以丢失任何节点，但仍能提供可靠的服务。零停机时间是生产环境中的必要条件。容错对于远程、无人值守的集群、设备和工业物联网尤其重要，在这些地方，访问受限且分布在一个国家、一个大陆或全球。
MicroK8s 使高可用性具有弹性和自我修复能力，无需管理干预。
一个高可用的 Kubernetes 集群可以承受任何组件的故障并继续不间断地服务工作负载。一个高可用的 Kubernetes 集群需要三个因素：

  • 有必须超过一个工作节点。由于 MicroK8s 将每个节点都用作工作节点，因此如果集群中存在多个节点，则始终会有多个工作节点。
  • 该Kubernetes API服务必须在多个节点上运行，从而失去了一个单一节点也不会导致群集无法使用。MicroK8s 集群中的每个节点都是一个 API 服务器，它简化了负载平衡，意味着如果一个 API 端点出现故障，我们可以立即切换到不同的 API 端点。
  • 集群状态必须在可靠的数据存储中。默认情况下，MicroK8s 使用Dqlite（一种高可用性 SQLite）作为其数据存储。

HA MicroK8s 所需的只是集群中的三个或更多节点，此时 Dqlite 自动高可用。如果集群具有三个以上的节点，则其他节点将成为数据存储的备用候选节点，并在数据存储丢失其中一个节点时自动提升。备用节点自动提升到 Dqlite 的投票集群，使得 MicroK8s HA 具有自治性，并确保即使不采取任何管理措施也能维持仲裁。
使用 raft，Dqlite 自动处理领导者选举，如果失败则选举一个替代领导者，并确保始终保留集群状态。不属于投票组的节点可以是备用的，等待添加到投票法定人数，或者备用，准备在需要时添加。HA 集群形成、Dqlite 同步、选民和领导者选举的过程是完全自主的，以确保需要最少的管理。
MicroK8s 只需添加更多 MicroK8s 节点即可提供生产级 Kubernetes 集群。不需要额外的配置——在三台机器上安装 MicroK8s，运行 join 命令将它们链接在一起，然后你就会拥有一个自动启用 HA 的生产级 Kubernetes 集群。
HA MicroK8s 在所有节点上提供 API 服务。这意味着集群中的任何节点都可以成为 kubectl 的目标。管理员可以在任何节点上执行任务。根据容量和利用率，自动选择三个节点为 Kubernetes 控制平面提供数据存储。如果数据存储节点发生故障，则会提升不同的节点以参与数据存储共识。
  
K3s - 轻量级 Kubernetes
轻量级 Kubernetes。生产就绪，易于安装，一半的内存，全部在一个小于 100 MB 的二进制文件中。
非常适合：
  • 边缘
  • 物联网
  • CI
  • 发展
  • 手臂
  • 嵌入 k8s
  • k8s 集群学博士不可行的情况

特点：
  • 小，开发人员需要最小的 K8s 用于笔记本电脑和工作站的开发。MicroK8s 提供了一个独立的 K8s，当你在 Ubuntu 上运行它时，它与 Azure AKS、Amazon EKS、Google GKE 兼容。
  • 简单。为了简单和确定，没有移动部件的单包安装最大限度地减少管理和操作。包括所有依赖项和电池。
  • 安全。更新可用于所有安全问题，并且可以立即应用或安排以适合您的维护周期。
  • 当前. MicroK8s 跟踪上游并在与上游 K8s 同一天发布测试版、RC 和最终位。您可以跟踪最新的 K8s 或坚持使用 1.10 以后的任何发布版本。
  • 综合的。MicroK8s 包含一系列针对常见 K8s 功能和服务的精选清单：
    • 服务网格：Istio、Linkerd
    • 无服务器：Knative
    • 监控：Fluentd、Prometheus、Grafana、Metrics
    • Ingress、DNS、仪表板、集群
    • 自动更新到最新的 Kubernetes 版本
    • 用于 AI/ML 的 GPGPU 绑定
    • Kubeflow！

  
k0s - 零摩擦 Kubernetes
k0s 是一个包罗万象的 Kubernetes 发行版，其中预先配置了所有必需的功能，使构建 Kubernetes 集群只需将可执行文件复制到每个主机并运行它即可。
主要特征
  • 打包为单个静态二进制文件
  • 自托管、隔离的控制平面
  • 各种存储后端：etcd、SQLite、MySQL（或任何兼容的）、PostgreSQL
  • 弹性控制平面
  • Vanilla 上游 Kubernetes
  • 支持自定义容器运行时（containerd 是默认值）
  • 支持自定义容器网络接口 (CNI) 插件（默认为 kube-router）
  • 支持 x86-64、ARM64 和 ARMv7

 
黑客网友评论
k3s体积比较小，K0s稍微大一些，50mb vs 150mb。
在所有低操作 K8s 发行版中，从初始设置、维护和在不太强大的硬件上使用的角度来看，k3s 是最好的。
甚至现在还有更高级别的工具，例如 k3os 和 k3sup，可以进一步减少初始部署的痛苦。
MicroK8s 以“没有添加或删除 API”而自豪。这在我的书中并不是那么积极。另一方面，K3s 主动删除了 alpha API，以减少二进制大小和内存使用。如果您只使用稳定的 Kubernetes 原语，效果会很好。
 
去年年底我在一个客户项目中使用了 Microk8s，这真的很痛苦，但我确信它服务于非常喜欢 Snap/Canonical 生态系统的一组特定用户。
相比之下，K3s 非常轻量级，可以通过 K3d 项目在容器中运行。
如果人们想使用 K8s 上游或针对 Kubernetes 的开发补丁，他们可能会发现 KinD 更快、更容易。
Minikube 最近也受到了很多人的喜爱，它也可以在不依赖 Virtual Box 的情况下运行。
[0] https://k3sup.dev/ [1] https://kind.sigs.k8s.io/docs/user/quick-start/

 
我从 k3s 转移到 microk8s 进行本地开发。我放弃了 k3s，因为我需要 calico CNI 并且设置起来很痛苦，在 microk8s 上它只是 `microk8s enable calico`。我还发现 k3s 对默认的 Traefik 入口和 service-lb 有点过于自以为是。我认为 Traefik 可能是目前最好的 Ingress。
 
如果你很懒，Microk8s 很棒。我最近构建了一个小型 3 节点集群，为几百个用户托管内部应用程序，几乎我需要做的唯一设置是：使用 Snap* 安装它，启用一些插件（存储、traefik、coredns），在每个节点上运行 join 命令并使用 haproxy** 和 keepalived *** 设置一个基本的负载均衡器。
  
原来Kubernetes 不适用于网络连接较差的环境，这种环境在处理 Edge 和 IoT 场景时很常见，自 2019 年以来发生了巨大的变化，k3sup（k3s 安装程序）工具的创建者，对 Raspberry Pi 上的 K3s 也有相当多的经验。
 
microk8s vs.minikube：
Microk8s 的优点：

  • - 绑定挂载支持 => 可以挂载包含其 node_modules 的项目，并在它在 pod 中热重新加载时从主机对其进行处理。
  • - dns、registry、istio 和 metallb 的插件可以正常工作。
  • - 感觉比 minikube 更灵活。

Microk8s 的缺点：
  • - 通过 snap 独家分发 => 不能轻松安装在 nix/nixos 上。