Sebastian是Loodse创始人兼CEO，Loodse是一家软件公司，开发了Kubermatic——用于Kubernetes多集群管理。 在Loodse之前，Sebastian在企业部门有十余年工作经验。 他在软件生产商SAP开始职业生涯，在那里他参与了SAP Hana的开发，并担任国际客户的顾问工作。

　　一直以来，容器就是个很酷的概念，但事实上，广泛部署却十分困难。你几乎没法手动管理容器之间的网络、持续存储和数百个容器间的自动扩展，而一个让人拍案叫绝的容器管理平台却迟迟未出现。

　　这样的局面一直维持到2014年，谷歌将 Kubernetes 项目发布到开放源代码社区之前。

　　Kubernetes 一开源，企业或者开发人员就可以在 Kubernetes 集群上自动管理网络、存储、自动扩展、警报以及许多其他标准化基础架构功能，开奖，它极少宕机，而且表现非凡。大规模运行容器和利用分布式基础设施成为许多公司的可行选择。

　　巧合的是，云原生应用程序的想法引来了 pets 与 cattle 的讨论，基础设施的每个组件都变得可替代，而不再是不可替代的 pet。随着这种思路的更新，每个组件在运行失败的时候都不会受影响：服务器、机架、数据中心这些。然而，讽刺的是，许多公司像对待宠物一样对待其 Kubernetes 集群，花费大量时间和资源来照顾。

　　在我们看来，这相当奇怪，本不该如此，因为它违背了云原生应用的理念。因此，我们的任务很明确：我们希望 Kubernetes 成为低维护 cattle：完全管理、可扩展、多租户和随时可用。此外，我们希望为所有的集群提供一个 API。

　　如果 Kubernetes 为运行自动化集群提供了完美的工具，那么为什么不使用 Kubernetes 自主托管多个 Kubernetes 集群？为什么不把关注的重点从“管理一个 Kubernetes 集群”，重新转移到“管理一个服务”？例如配置 “Kubernetes-as-a-Service” 的服务。

　　Kubernetes 中如何运行 Kubernetes 呢？

　　首先要做的是建立运行多个独立客户集群的主组件的外部 Kubernetes 集群。像其他 Kubernetes 集群一样，主集群由四个主要组件组成：API server，etcd key value store，scheduler 和 controller。为了防止停机，我们为每个组件创建了一个具有多个实体的高可用性设置。

　　然后，启动内部集群。我们创建了一个命名空间，生成证书、令牌和 SSH 密钥，并部署主组件。随后，我们添加了一个入口，使 API 服务器等从外部访问。最后，我们安装了基本的插件，如 Heapster，kube-proxy，Kube-dns 和 dashboard。

　　之后，我们想知道内部群集中发生了什么，也就是节点和 pod 实际上正在运行的地方。不幸的是，无法进行标准的 Kubernetes 设置，只能与主集群的 API 进行通信。为了进一步复杂化，我们要使用 N 个 API 服务器和 N 个拥有主集群 IP 的 etcd 实例来设置 N 个集群。因此，我们需要提供一种能够通过 SSH 隧道向客户 API 服务器3发送客户 API 服务器3的加密请求的 HTTP 和 TCP 代理服务。

　　总结

　　我们展示的是：您可以在 Kubernetes 中运行 Kubernetes 来提供多个自主托管和完全管理的内部集群。这样可以轻松地创建、更新、删除和重新安排集群，而不影响功能。此外，这种架构确保更高的隔离度和安全性，并且很大程度上促进了多租户。

　　虽然这个概念还处于萌芽阶段，但我们认为，Kubernetes-in-Kubernetes 是为再次逃避 pet 范式所跨出的重要一步。这个概念使企业能够大规模地运行多个集群，同时追求真正的云原生策略，让企业只需要专注于应用程序，而不是基础设施。

　　原文：Running Kubernetes in Kubernetes（https://thenewstack.io/running-kubernetes-kubernetes/）