将Kubernetes引入到裸机边缘

Packet的独特之处在于侧重裸机，它扩大了Kubespray的支持范围，不仅仅支持平常的云：亚马逊网络服务、谷歌计算引擎、Azure、OpenStack、vSphere和Oracle云基础设施。Kubespray使用Terraform和Ansible，借助自动化消除了安装Kubernetes集群的复杂性。Terraform提供了基础设施，并安装了安装Ansible所需的必备组件。Terraform provider插件能够支持众多不同的云提供商。Ansible剧本随后部署和配置Kubernetes。

由于网上已有将Kubespray部署在Packet上的详细说明(https://github.com/kubernetes-sigs/kubespray/blob/master/docs/packet.md)，我将着重介绍为何裸机支持对Kubernetes来说很重要以及所需的必要条件。

为何支持裸机?

在过去，Kubernetes部署依赖公共云或完全托管版私有云的“舒适工具”(creature comforts)，提供用于运行Kubernetes的虚拟机和网络基础设施。这增加了一层抽象(比如带虚拟机的虚拟机管理程序)，Kubernetes未必需要这层抽象。事实上，Kubernetes一开始就驻留在裸机上(那时叫谷歌的Borg)。

随着我们让工作负载更靠近最终用户(以边缘计算的形式)，并部署到更多样化的环境(包括不同架构和大小的混合和本地基础设施)，依赖同样的公共云底层并非总是可行或理想。比如说，由于边缘位置受资源限制，直接在裸机上运行Kubernetes更高效、更实际。

注意不足

如果裸机集群下面没有功能齐全的公共云，就需要直接在Kubernetes集群中管理一些传统功能，比如负载均衡和存储编排功能。幸好有一些项目(比如MetalLB和Rook)为Kubernetes提供了这种支持。

MetalLB是第2层和第3层负载均衡系统，集成到Kubespray中，很容易在裸机集群上安装支持Rook的机制，Rook负责编排Ceph，为Kubernetes集群提供分布式复制存储。除了支持全部功能外，这种“自备”的存储和负载均衡方法还摆脱了对特定云服务的依赖，帮助你借助可在任何地方安装的方法来避免锁定。

Kubespray支持ARM64处理器。ARM架构(开始经常出现在数据中心级硬件、SmartNIC及其他定制的加速器中)在移动和嵌入式设备有着悠久的历史，非常适合部署在边缘。

展望未来，我希望看到MetalLB与Rook更深入地集成，另外在众多不同的硬件配置上对日常构建版本实行裸机持续集成(CI)。访问Packet的自动化裸机能够支持跨多种处理器、存储方案和网络环境来进行测试和维护。这将有助于确保可以跨公共云、裸机和边缘环境来妥善地部署和管理基于Kubespray的Kubernetes。

需要社区