我们如何在Kubernetes或Kubeception中运行Kubernetes

编者注:今天的帖子由Giant Swarm团队撰写,展示了他们如何在Kubernetes中运行Kubernetes。

巨群 的容器基础结构最初是为开发人员部署容器化微服务提供一种简便方法。我们的第一代广泛使用 舰队 作为基础架构组件以及调度用户容器的基础层。

为了给用户提供一种更强大的容器管理方法,我们于2016年初将Kubernetes引入了堆栈。但是,由于我们需要一种快速灵活地灵活启动和管理不同用户的Kubernetes集群的方法,因此我们保留了基础机群层。

当我们坚持在容器中运行所有基础基础架构组件时,fleet使我们可以灵活地使用systemd单位文件来声明性地定义我们的基础架构组件。我们自己开发的部署工具使我们能够部署和管理基础架构,而无需使用命令式配置管理工具。

但是,舰队只是一个分布式的初始化,而不是一个完整的调度和编排系统。除了我们在工具方面的大量工作之外,它还需要在同级之间的通信,对帐循环以及我们必须进行的稳定性方面进行重大改进。此外,Kubernetes用法的普及将确保发现问题并更快地解决。

因为我们在向用户介绍Kubernetes以及最近的发展(例如 网络 Stackanetes 对于我们来说,现在也该将基础层迁移到Kubernetes了。

为什么在Kubernetes中使用Kubernetes

现在,您可能会问,为什么有人要在Kubernetes集群中运行多个Kubernetes集群?我们疯了吗?答案是先进的多租户用例及其可操作性和自动化性。

Kubernetes 带有针对多租户用例的不断增长的功能集。但是,我们的目标是为用户提供完全托管的Kubernetes,而对使用任何普通Kubernetes环境(包括对节点的特权访问)所获得的功能没有任何限制。此外,在大型企业场景中,具有内置隔离机制的单个Kubernetes群集通常不足以满足合规性和安全性要求。更高级的(防火墙)分区或分层安全性概念很难通过单个安装来复制。使用名称空间隔离,如果不回避安全措施,几乎无法实现特权访问和防火墙区域。

现在您可以去设置多个完全独立的(和联合的)Kubernetes安装。但是,自动化这些群集的部署和管理将需要其他工具和复杂的监视设置。此外,我们希望能够按需上下移动集群,扩展规模,更新它们,跟踪可用的集群,并能够灵活地将它们分配给组织和团队。实际上,此设置可以与联合控制平面结合使用,以通过一个API端点将部署联合到集群。

并且拥有一个API和前端不是很好吗?

输入巨网

根据上述要求,我们着手构建我们称为Giantnetes的网络-如果您喜欢电影,请构建Kubeception。最基本的抽象是外部Kubernetes集群(实际的Giantnetes),用于运行和管理多个完全隔离的用户Kubernetes集群。

使用我们的CoreOS Container Linux引导工具引导物理机器, 马玉 。 Giantnetes组件本身是自托管的,即,kubelet负责自动引导清单文件中的组件。您可以将其称为Kubeception的第一级。

Giantnetes集群运行后,我们将使用它来调度用户Kubernetes集群以及用于管理和保护它们的工具。

我们选择Calico作为Giantnetes网络插件,以确保在Giantnetes上运行的所有应用程序的安全性,隔离性和正确的性能。

然后,为了创建内部的Kubernetes集群,我们启动了一些Pod,这些Pod配置了网桥,创建了证书和令牌,并为将来的集群启动了虚拟机。为此,我们使用KVM和qemu等轻量级技术来配置CoreOS Container Linux VM,这些VM成为内部Kubernetes集群的节点。您可以将其称为Kubeception的第二级。 

当前,这意味着我们将使用Docker容器启动Pod,而Docker容器随后将使用KVM和qemu启动VM。但是,我们正在考虑通过 rkt qemu-kvm ,这将导致为我们的Giantnetes使用rktnetes设置。

内部Kubernetes集群的网络解决方案分为两个级别。它结合了法兰绒的服务器/客户端架构模型和Calico BGP。虽然使用法兰绒客户端在每个虚拟内部Kubernetes集群的虚拟机之间创建网络桥接,但Calico在虚拟机内部运行以连接不同的Kubernetes节点,并为内部Kubernetes创建单个网络。通过使用Calico,我们模仿了每个Kubernetes集群内部的Giantnetes网络解决方案,并提供了通过Kubernetes网络策略API保护和隔离工作负载的原语。

关于安全性,我们的目标是尽可能地分离特权并使其可审计。当前,这意味着我们使用证书来保护对集群的访问并加密组成集群的所有组件之间的通信(即VM到VM,Kubernetes组件彼此,etcd master到Calico worker等)。为此,我们为每个群集创建一个PKI后端,然后按需在Vault中为每个服务颁发证书。每个组件使用不同的证书,因此,如果任何组件或节点遭到破坏,则避免暴露整个集群。我们还会定期轮换证书。

为了确保从外部访问每个内部Kubernetes集群的API和服务,我们在Giantnetes中运行了多级HAproxy入口控制器设置,该控制器将Kubernetes VM连接到硬件负载平衡器。

用kubectl调查巨网

让我们看一下Giantnetes的最小示例部署。

屏幕截图2016-11-14 at 12.08.40 PM.png

In the above example you see a user Kubernetes cluster customera running in VM-containers on top of Giantnetes. We currently use Jobs for the network 和 certificate setups.

窥视用户集群内部,您会看到DNS窗格和helloworld正在运行。

屏幕截图2016-11-14 at 12.07.28 PM.png

这些用户群集中的每一个都可以独立计划和使用。它们可以按需上下旋转。

结论

综上所述,我们可以展示Kubernetes如何不仅能够轻松自托管,还可以灵活地调度大量内部Kubernetes集群,同时确保更高的隔离度和安全性。该设置的一个亮点是安装的可组合性和自动化以及Kubernetes组件之间的强大协调。这使我们能够轻松地按需创建,销毁和重新安排群集,而不会影响用户或损害基础架构的安全性。它进一步允许我们通过在创建集群时更改一些参数来旋转具有不同大小和配置甚至版本的集群。 

此设置仍处于初期阶段,我们的路线图正在计划在许多方面进行改进,例如透明升级,集群的动态重新配置和扩展,性能改进以及(甚至)安全性。此外,我们期待通过不断发展的Kubernetes操作工具状态和即将推出的功能(例如Init容器,预定作业,Pod和Node亲和力和反亲和力等)来改善设置。

最重要的是,我们正在努力使内部Kubernetes集群成为第三方资源,然后可以由自定义控制器对其进行管理。结果很像 CoreOS的操作员概念。为了确保整个社区都能从该项目中受益,我们将在不久的将来对此进行开源。

-Giant Swarm的软件工程师Hector Fernandez和Puja Abbassi的开发者