随着越来越多的企业和应用转向云原生架构，对 Kubernetes 集群的需求也日趋多样化和灵活化。出于故障隔离的考虑，企业的数据中心往往需要多个独立的 Kubernetes 集群来承载不同的业务，而不是全部署在一个共享 Kubernetes 集群上。
此外，由于业务负载普遍具有动态变化的特点，因此每个 Kubernetes 集群的规模也存在动态变化的需求，以适应增长的业务负载，并在业务负载降低时能及时释放计算资源以节省开销。这些 Kubernetes 集群运维的需求可以统一归类到 Kubernetes as a service，即 KaaS 服务。
在主流公有云上，KaaS 是其中非常重要和核心的组成。公有云的 KaaS 可以快速便捷地为其用户创建生产就绪的高可用 Kubernetes 集群，并且提供后续为集群扩容、缩容的运维操作。通常来说，公有云 KaaS 提供的 Kubernetes 集群的节点都是虚拟机，以提高物理资源的利用率。
在私有的企业数据中心，KaaS 需要企业 IT 部门从零构建，包括虚拟化平台、Kubernetes 管理平台、用户终端等多套系统的采购和集成，往往耗时又耗钱。此外，传统主流的虚拟化平台往往因需要支持广泛的虚拟化场景而集成了过多的功能，在单纯支持 Kubernetes 集群的场景下，显得笨重而低效。
为此，SmartX 开源了基于 Cloud Hypervisor 的 Kubernetes 原生轻量虚拟化平台 Virtink，并且在 Virtink 基础上进一步开源了 knest 命令行工具，帮助用户一键式地在 Virtink 上创建和运维 Kubernetes 集群，以更直接、更简单、更高效的方式为私有数据中心提供 KaaS 的能力基础。本文将详细介绍 knest 的功能和使用，帮助用户认识和了解 knest。
准备 Kubernetes 主机集群
就如上面我们提到的，Virtink 是 Kubernetes 原生的虚拟化平台，意味着它需要部署运行在一个 Kubernetes 集群上。为避免混淆，在接下来的内容中，我们这个 Kubernetes 集群称为 Kubernetes 主机集群，而将部署在 Virtink 虚拟机上的 Kubernetes 集群称为 Kubernetes 虚拟机集群。
值得注意的是，Kubernetes 主机集群的节点并不要求一定是物理机，也可以是支持嵌套虚拟化的虚拟机。如果您的手头已有一个现成的 Kubernetes 集群，可以选择将其作为接下来的主机集群，但需要确保集群的每个节点都支持 KVM。
如果您目前没有可用的 Kubernetes 集群，那么可以选择用 minikube 在您的本地创建一个临时的 Kubernetes 集群作为主机集群，例如：
minikube start --memory 6g --cni calico.yaml |
这里我们选择不使用 minikube 默认的 CNI 而使用 Calico，是因为接下来要创建的 Kubernetes 虚拟机集群中的 Calico 需要 Kubernetes 主机集群的 CNI 支持 pod 中的 IPIP 包。Minikube 默认的 CNI 并不支持这个功能，因为选择使用 Calico。并且，Calico 默认是关闭这个功能的，我们需要增加一个环境变量来开启这个功能：
curl -LO https://projectcalico.docs.tigera.io/manifests/calico.yaml sed -i '/^ # Use Kubernetes API as the backing datastore.$/i \ \ \ \ \ \ \ \ \ \ \ \ - name: FELIX_ALLOWIPIPPACKETSFROMWORKLOADS\n value: "true"' calico.yaml |
使用 knest 创建 Kubernetes 虚拟机集群
首先，如果您还没有安装 knest 的话，请在项目的最新 release 中选择对应平台的二进制文件，并安装，例如：
curl -LO https://github.com/smartxworks/knest/releases/download/v0.6.0/knest-linux-amd64 sudo install knest-linux-amd64 /usr/local/bin/knest |
接下来，使用 knest 创建 Kubernetes 虚拟机集群：
knest create demo --pod-network-cidr 10.245.0.0/16 --service-cidr 10.112.0.0/12 |
值得注意的是，Kubernetes 虚拟机集群的 pod 网络段和 service 网络段必须和 Kubernetes 主机集群的区分开，网络段之间不能有重叠。
如果您的 Kubernetes 主机集群是 minikube，那么 minikube 默认的 pod 网络段和 service 网络段分别是 10.244.0.0/16 和 10.96.0.0/12，因此这里选择分别往上走一个网络段作为 Kubernetes 虚拟机集群的 pod 网络段和 service 网络段。
扩容 Kubernetes 虚拟机集群
上面创建的 Kubernetes 虚拟机集群仅包含一个 control plane 节点，且无 worker 节点。如果您的 Kubernetes 主机集群有足够的计算资源，可以选择用 knest 的扩容命令为其添加更多的 control plane 节点和 worker 节点。
而如果您使用的是 minikube 作为 Kubernetes 主机集群，且本地有至少 10G 的可以内存，那么可以选择将 minikube 集群的内容扩大到 10G，然后用 knest 为 Kubernetes 虚拟机集群添加一个 worker 节点：
knest scale demo --worker-machine-count 1 |
创建持久化的 Kubernetes 虚拟机集群
通过上面创建的 Kubernetes 虚拟机集群默认使用 Virtink 的 ContainerRootfs 类型的存储。ContainerRootfs 存储能够将 Docker image 中的目录作为虚拟机的 rootfs，因此能够完全利用 Docker 的工具链来构建虚拟机的镜像，但它无法持久化。
如果虚拟机关机后再次启动，其 rootfs 会重新从 Docker image 构建，即无法持久化在虚拟机运行过程中保存到 rootfs 中的文件。如果您希望您的 Kubernetes 虚拟机集群的每个节点都是持久化的，knest 也支持创建持久化的 Kubernetes 虚拟机集群，例如：
knest create demo --pod-network-cidr 10.245.0.0/16 --service-cidr 10.112.0.0/12 --persistent --host-cluster-cni calico --machine-addresses 10.244.0.100-10.244.0.110 |
值得注意的是，考虑到 Kubernetes 虚拟机集群节点需要固定 IP，因此建议 Kubernetes 主机集群的 CNI 选择支持固定 IP 的 CNI，例如 Calico 和 kube-ovn。
在使用 knest 创建持久化的 Kubernetes 虚拟机集群时，需要通过 --host-cluster-cni 参数提供 Kubernetes 主机集群的 CNI 类型，以使 knest 能够将 IP 以适当的方式标注到 VM 上，使其最终能通过 CNI 正确获得固定 IP。
此外，您也需要通过 --machine-addresses 参数提供一定数量的固定 IP，以满足 Kubernetes 虚拟机集群的固定 IP 分配需要。
总结
在企业数据中心构建 Kubernetes as a Service 并非一件容易的事，其中涉及到虚拟化平台、Kubernetes 管理运维平台、用户终端等多个平台的集成。SmartX 开源的 knest 工具，基于其另一个开源的 Kubernetes 原生轻量虚拟化引擎 Virtink 项目，提供一键式创建和运维高效、安全、低开销的 Kubernetes 虚拟化集群，是数据中心 KaaS 较为理想的基础构件。
欢迎您扫描下方二维码，添加 SmartX 开源社区管理员微信，加入 Virtink 社区，与云原生专家和工程师们一起讨论 Knest 和 Virtink 。或者您也可以通过邮箱（virtink@smartx.com）联系我们，沟通您的想法和问题。
