K3S vs K0S

K0S vs K3S

• 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 转发的负载均衡

命令对比

如何选择

相同点

• 面向相同用户群体和使用场景，非常类似
• 核心都使用 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
  • 改动更小

为什选择 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

2. 通过 docker 启动 registry 缓存镜像 - 配置为 mirror 可加速或者实现 airgap
3. 如果不想在 k8s 内 dind 可以映射 host docker.sock

组件简介

• kine k3s 和 k0s 最核心组件
  • 提供 etcd 能力
  • 后端支持 etcd,sqlite,mysql,postgresql,dqlite
• traefik
  • 提供 Ingress 能力
• k3s-io/helm-controller
  • 支持部署 helm chart
  • 通过 CDR 控制
• CNI - 容器网络
  • flannel
  • calico
  • kube-router
• CSI - 容器存储
  • local-path-provisioner
    • 基于本地路径提供 volume
  • openebs
• LoadBalancer
  • k3s-io/klipper-lb
    • 基于 iptable 提供 ClusterIP 能力
  • metallb

参考

• certified-kubernetes-installer

为什么会存在不同发行版

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