假设您有一个大型组织，它在裸机上运行自己的 kubernetes 集群。
这个想法是，该组织内的不同业务部门可以“按需”获取云资源并在其上做他们想做的事情。
为此，您可以创建命名空间并为每个 BU 提供自己的命名空间以执行其想要的操作。
但还有什么可以说的呢：
- 他们想将这个命名空间进一步拆分为命名空间——子命名空间是一个东西吗？
- 他们想要运行自己的 kubernetes 集群。即用例可能是该组织正在为其他人开发 kubernetes 解决方案 - 因此他们将在这里构建它，然后一旦全部构建完成，就将其部署到客户站点上的全新 kubernetes 集群。
这可能吗？
答案1
我可以向您介绍两个概念，它们使用不同的方法将 Kubernetes 集群作为不同 Kubernetes 集群的下属。它们都还没有准备好使用，但这些文章很好地解释了如何做到这一点：
Kubernetes 拥有自己的不断增长的功能集，可用于多租户用例。但是，我们的目标是为用户提供完全托管的 Kubernetes，而不限制他们使用任何原始 Kubernetes 环境所能获得的功能，包括对节点的特权访问。此外，在更大的企业场景中，具有内置隔离机制的单个 Kubernetes 集群通常不足以满足合规性和安全性要求。更高级的（防火墙）分区或分层安全概念很难通过单一安装来重现。在命名空间隔离的情况下，特权访问和防火墙区域几乎无法在不绕过安全措施的情况下实现。
现在，您可以设置多个完全独立（且联合）的 Kubernetes 安装。但是，自动部署和管理这些集群需要额外的工具和复杂的监控设置。此外，我们希望能够根据需要启动和关闭集群、扩展集群、更新集群、跟踪哪些集群可用，并能够灵活地将它们分配给组织和团队。实际上，此设置可以与联合控制平面相结合，通过一个 API 端点将部署联合到集群。
根据上述要求，我们着手构建所谓的 Giantnetes - 或者如果你喜欢电影的话，可以称之为 Kubeception。从最基本的抽象上讲，它是一个外部 Kubernetes 集群（实际的 Giantnetes），用于运行和管理多个完全隔离的用户 Kubernetes 集群。
物理机器使用我们的 CoreOS Container Linux 引导工具 Mayu 进行引导。Giantnetes 组件本身是自托管的，即 kubelet 负责自动引导位于清单文件夹中的组件。您可以将其称为 Kubeception 的第一级。
一旦 Giantnetes 集群运行，我们就会使用它来调度用户 Kubernetes 集群以及用于管理和保护它们的工具。
我们选择 Calico 作为 Giantnetes 网络插件，以确保在 Giantnetes 上运行的所有应用程序的安全性、隔离性和正确的性能。
然后，为了创建内部 Kubernetes 集群，我们启动一些 pod，这些 pod 会配置网桥、创建证书和令牌，并为未来的集群启动虚拟机。为此，我们使用 KVM 和 qemu 等轻量级技术来配置 CoreOS Container Linux VM，这些 VM 将成为内部 Kubernetes 集群的节点。您可以将其称为 Kubeception 的第二级。
目前，这意味着我们用 Docker 容器启动 Pod，然后使用 KVM 和 qemu 启动虚拟机。但是，我们正在考虑使用 rkt qemu-kvm 来实现这一点，这将导致为我们的 Giantnetes 使用 rktnetes 设置。
2017 年 1 月 20 日星期五，作者：Giant Swarm 软件工程师 Hector Fernandez 和开发倡导者 Puja Abbassi
巧合的是，云原生应用的概念引发了宠物与牛群的讨论，你开始将基础设施的每个组件视为牛群中可抛弃的部分，而不再是不可替代的宠物。根据这种新的思维方式，每个组件都必须能够在不受影响的情况下发生故障：服务器、机架、数据中心……一切。然而讽刺的是，许多公司现在将他们的 Kubernetes 集群视为宠物，并花费大量时间和资源来照顾和维护它。
对我们来说，这似乎很奇怪，而且不应该如此，因为它与云原生应用程序的基本概念相矛盾。因此，我们的使命很明确：我们希望 Kubernetes 集群成为低维护的牛：完全托管、可扩展、多租户和随时可丢弃。此外，我们希望所有集群都有一个 API。
首先要设置一个外部 Kubernetes 集群，该集群运行多个独立客户集群的主组件。与任何其他 Kubernetes 集群一样，主集群由四个主组件组成：API 服务器、etcd 键值存储、调度程序和控制器。为了防止停机，我们为每个组件创建了一个包含多个实体的高可用性设置。
然后，为了启动内部集群，我们创建命名空间，生成证书、令牌和 SSH 密钥，并部署主组件。随后，我们添加入口以使 API 服务器和 etcd 可从外部访问。最后，我们安装基本插件，如 Heapster、kube-proxy、Kube-dns 和仪表板。
2017 年 3 月 15 日上午 9:49，作者：Sebastian Scheele
答案2
无法在容器内运行生产 Kubernetes 集群。
但是，您可以在虚拟机而不是裸机上运行 Kubernetes 节点。这样，与直接在裸机上运行 Kubernetes 相比，您可以更轻松地将资源分配给需要的业务部门。
您还应该研究一下 OpenShift，它是 Kubernetes 的一个分支，具有用于多租户的附加功能。
答案3
查看园丁尝试这样做的项目。
简而言之，您有一个 kubernetes 集群，它可以像普通 pod 一样运行其他集群的控制平面。kubernetes 中的 Kubernetes。