【问题标题】：To virtualize or not to virtualize a bare metal server for a kubernetes deployment为 Kubernetes 部署虚拟化或不虚拟化裸机服务器
【发布时间】：2017-01-02 07:47:27
【问题描述】：
我想在大型物理服务器（24 核）上部署 kubernetes，但我不确定很多事情。
除了在裸机上运行之外，为 k8s 集群创建虚拟机的优缺点是什么。
我有以下考虑：
- 创建 vm 将允许工作负载隔离。可以创建用于实验的新虚拟机并将其分配给开发人员。
- 另一方面，在裸机上运行 k8s 时，可以为每个开发人员创建一个新的 NAMESPACE 进行实验，他们可以在其中运行他们的代码。毕竟他们的所有代码都应该在 docker 容器中运行。
安全性：
- 拥有 vm 将限制授予未来维护者的访问量，从而限制可能造成的损害。而另一方面，任何未来维护者的主要任务都是添加/删除节点，他们需要裸机访问权限才能做到这一点。
身份验证：
- 目前，开发人员只有在他们的代码通过 CI 管道运行并部署他们正在运行的部署时才会接触服务器。但是查看日志呢？我们是否可以设置分层 kubectl 身份验证以允许开发人员仅访问已分配给他们的任何命名空间（我相信这应该可以通过 k8s 命名空间授权插件实现）。
服务器上已经存在多个虚拟机。这会是个问题吗？
【问题讨论】：
标签：
virtual-machine
kubernetes
virtualization
cloud-bare-metal
【解决方案1】：
128 个核心和疑问....对于单个服务器来说，这是很多核心。
但对于 Kubernetes，这无关紧要：
Kubernetes 可以使用不同大小的服务器并最大限度地利用它们。但是，如果您将主服务器进程和节点/工作进程合并到单个服务器上，则可能会产生不必要的资源问题。正如您已经提到的，您可以使用命名空间来管理它们。
我们所做的是在单个 dev/qa kubernetes 环境中使用与命名空间的持续集成，其中更改有自己的命名空间（因此我们运行许多命名空间）并在这些命名空间中运行完整的环境部署。使用一堆 shell 脚本来管理它。这既适用于您所拥有的大型服务器，也适用于较小（或虚拟）的盒子。虚拟化对您的好处可能主要在于将大盒子分成较小的盒子，以便您也可以将它用于其他目的，然后只是 kubernetes（是的，kubernetes 运行除了 MS Windows，没有桌面，没有用于 VPN 目的的内核模块等)。
【解决方案2】：
我会以不同 vm 的形式将 dev 和 prod 分开。我曾经在 docker 中有一个 webapp，它使用了太多线程，所以主机上的 docker 守护进程崩溃了。幸运的是，它仅限于一位主持人。您可以通过设置限制来保护这一点，但这是一种风险：开发中的一个错误也可能导致产品失败。
【解决方案3】：
我认为答案是“视情况而定！”这不是一个真正的答案。就个人而言，我会使用 VM 拆分机器并以这种方式部署。您可以更灵活地分配多少服务器资源，并且可以轻松创建新环境，然后轻松销毁。
即使这些虚拟机真的很大，我认为它仍然更容易管理，因为你的机器上有现有的虚拟机。
也就是说，您不能运行单节点服务器并不是技术原因，但您可能会遇到升级停机问题（如果这是一个问题），以及该服务器是否需要修补或重新启动，那么你的整个集群就宕机了。
我会查看您的环境对 HA 和正常运行时间的需求，以及您将如何部署虚拟机（如果您走这条路），然后确定最适合您的方法。