Skip to main content

K3S vs K0S

· 10 min read
vs.k0sk3s
since2020-062019-03
byMirantsRancher/SUSE
GovernanceMirantsCNCF
Githubk0sproject/k0sk3s-io/k3s
Stars
Issues
CNIkube-router,calicoflannel
CRIcontainerdcontainerd
CSIOpenEBSlocal-path-provisioner
Windows✅ - calico
Archamd64,arm,arm64amd64,arm,arm64
LoadBalancern/aklipper-lb
Ingressn/atraefik
Controller-Workerkonnectivityremotedialer - WebSocket 反向代理
文档⭐️⭐️⭐️⭐️
成熟⭐️⭐️⭐️⭐️⭐️
国内环境友好⭐️⭐️⭐️⭐️
Pod CIDR10.244.0.0/1610.42.0.0/16
Service CIDR10.96.0.0/1210.43.0.0/16
CoreDNS10.96.0.1010.43.0.10
configuration/etc/k0s/k0s.yaml/etc/rancher/k3s/config.yaml
registry/etc/k0s/k0s.yaml/etc/rancher/k3s/registry.yaml
data-dir/var/lib/k0s/var/lib/rancher/k3s
bin-dir/var/lib/k0s/bin/var/lib/rancher/k3s/data/current
kubeconfig/var/lib/k0s/pki/admin.conf/etc/rancher/k3s/k3s.yaml
manifest/var/lib/k0s/manifests/var/lib/rancher/k3s/server/manifests
local storage/var/openebs/local/var/lib/rancher/k3s/storage/
服务运行方式supervisor - 独立多进程embeded - 单进程
containerdbundled系统/bundled
  • k0s
    • CIS security benchmark
    • 符合 FIPS 140-2 要求
    • bundled
      • iptables, containerd, ctr, runc, etcd, kine
      • openebs
        • openebs-hostpath -> /var/openebs/local
      • kube-router
      • konnectivity
      • helm-controller
  • k3s
    • CNCF 项目 - 脱离了 rancher
    • bundled
      • containerd, ctr, runc, etcd, kine
      • helm-controller - 支持部署 helm chart, CDR 控制
      • traefik - 提供 ingress 能力 - 通过 helm 部署
      • local-path-provisioner - 提供基于本地目录的存储类
        • 默认 /var/lib/rancher/k3s/storage
      • klipper-lb - 基于 iptable 转发的负载均衡
caution
  • k3s 默认包含较多组件,部署后 可使用性 更高,但部分组件( traefik,klipper-lb,local-path-provisioner )不建议生产使用,提供这些组件更多是为了保证功能完整,开箱即用。
  • 使用 k3s 不推荐使用内置 traefik 和 klipper-lb
    • ingress 建议自行安装 - 比较重要的核心组件
    • 建议使用 metallb 替代 klipper-lb
  • 因为 Controller-Worker 网络不同,k3s 和 k0s 无法混合使用

命令对比

k0sk3s
k0s systinfo./contrib/util/check-config.sh
k0s backupk3s etcd-snapshot
k0s restorek3s server --cluster-reset-restore-path
k0s controllerk3s server
k0s workerk3s agent
n/ak3s crictl
k0s installhttps://get.k3s.io 会安装 systemd, openrc 服务
k0s resetn/a
k0s kubeconfig createn/a
k0sctln/a
k0sctl apply~autok3s
k0sctl backupn/a
------
k0s kubectlk3s kubectl
k0s ctrk3s ctr

如何选择

相同点

  • 面向相同用户群体和使用场景,非常类似
  • 核心都使用 kine - 区别不大
  • 都有大的企业支撑开发

选择考量

  • k3s
    • 更成熟 - 存在时间更长,使用的更独立
    • 社区更大 - 社区还与 rancher、rke 有交集
    • 中文化社区友好
    • 单节点默认 SQLite
  • k0s
    • 更新 - 2020 年 - 目前已经成熟,可以用于生产
    • 用户体验更好
    • k0sctl
      • 能更好的辅助维护更多的集群,减少对 脚本/ansible 的依赖。
      • 更好升级
      • 更好备份
    • 单节点默认 etcd/kine

为什选择 K0S

  • k0s 作为 supervisor 运行 - 🌟
    • 每个进程独立 - etcd, k0s-api, kube-apiserver
      • 方便调试,排查问题 - 能清楚知道哪个进程启动了没启动
      • 能看到所有实际运行参数
      • 可以单独 kill 进程 - 例如: 修改了 containerd 镜像配置,只能通过 kill 来使新的配置生效
        • 不需要启停全部服务
    • 代码部署运行逻辑清晰 - 如果需要更深入了解
  • k0s bundled 了更多依赖 - ⭐️ - containerd, iptables - 目前 k3s 和 k0s 这一块区别不大
    • 几乎对系统没什么额外依赖
  • k0sctl 辅助部署
    • 如果需要可自行进行定制化
    • 替代部分 ansible 工作
  • 默认 control plane 和 worker 分离
    • ⚠️ 部署有一些注意事项
  • 使用 konnectivity - 相对更 kubernetes
    • 改动更小
caution
  • 默认用到了 k8s.gcr.io 镜像 - 国内环境部署需要注意,建议用 airgap 包导入基础镜像。
  • k0sctl 功能还比较欠缺 @2022

为什选择 K3S

  • 更加成熟
  • 更新更频繁 - 更贴近上游
  • 易于迁移备份 - e.g. sqlite -> etcd, k3s snapshot
  • 社区更大
  • 对中国环境友好 - 背靠 rancher
    • k0s 默认 k8s.gcr.io 镜像 - 国内环境部署需要注意,建议用 airgap 包导入基础镜像。

关于 Provisioning

虽然有 autok3s 和 k0sctl,一般重复部署时候还是建议自行脚本部署,但初次尝试使用这种自动化工具问题不大。

建议自行部署的主要原因:

  1. 工具可能会更新迭代 - 工具会变
  2. 特殊需求 - e.g. 需要自定义配置,pod 数量,网络参数
  3. 特殊环境 - e.g. musl, arm, alpinelinux
  4. 更好管控细节

当需要在多个环境中进行重复部署时,自行编写的自动化脚本比使用官方的自动化工具更加可靠。

关于 Docker

不建议使用 Docker 作为容器运行时,建议使用 containerd。

  1. 默认配置,不需要任何配置
  2. 避免污染 docker
  3. 现在都 bundle 了 containerd,更能匹配 k8s 要求的版本

推荐 Docker 用于前期 bootstrap 或者作为 host sock 给容器内用。

  1. 通过 docker 启动 dns 相关的服务
  • dns 服务过于底层,不应该在 k8s 内部运行,会导致启动很慢
  • 用于实现重新映射 domain -> ip
  • 例如: adguard, dnsmasq
  • 例如: 映射 docker.io 为 内网 IP
  1. 通过 docker 启动 registry 缓存镜像 - 配置为 mirror 可加速或者实现 airgap
  2. 如果不想在 k8s 内 dind 可以映射 host docker.sock

组件简介

参考

为什么会存在不同发行版

K8S 作为最原始的项目,派生出来很多 分支/发布版。

Kubernetes 的核心能力为资源调度,主要资源为 Pod/容器组/计算资源。 因为是分布式多节点,所以对网络有要求。Pod 调度主要提供计算能力,实际使用还会需要存储能力。 也就是说 Kubernetes 涉及到核心的三元素

  • 计算
  • 网络
  • 存储

Kubernetes 核心调度计算资源,但对于网络和存储是 无意见/Unopinioned ,但实际部署使用时这时候又不可避免的要面对这些问题。 因此不同的 发布版/Distribution 就是对这些问题不同的看法。

K8S 要求

Kubernetes 由 Google 开发,但不是所有人都有那么大规模的问题,而大多数时候都是小规模,先让 K8S “跑起来”。

Kubernetes 自身因为对基础设施层 无意见/Unopinioned,因此默认是没有部署工具,只有要求:

  • 要求节点运行在平坦网络
  • 要求 etcd 能力的状态存储
  • 要求 cloud-controller 提供节点信息
  • 要求 容器运行时

在这些基础之上,Kubernetes 提供基于状态的 接口 进行资源调度。

K8S 部署

除了满足 K8S 的要求,在实际使用时还希望能方便快捷的管理部署。 K8S 提供了 kubeadm 进行安装,不同的发布版也需要提供类似的工具,但工具区分为两部分

  1. 远程开通部署
    • SSH
    • 控制节点通过工具部署到多个节点
  2. 开通部署的提前准备
    • CA 证书
    • ETCD/存储初始化
    • 网络设置
    • Bootstrap

kubeadm 和 k0s, k3s 都属于第二种场景,第一种场景的工具例如

  • autok3s
  • rke
  • ansible
  • k0sctl