在本文中，Neoflex的首席架构师Igor Kotenko分享了他在企业基础架构上部署容器化平台的经验。
公司通常选择内部部署解决方案的原因通常是非技术性的，并且通常与融资相关。有人试图降低运营成本（为外部云付费），以利用公司的资本（购买自己的服务器），有人已经拥有坚实的硬件资源，并希望在微服务架构中使用它们。
在继续介绍实现细节之前，我们先来看一下这些术语。
术语“云”被认为非常拥挤。通常区分不同类型的云解决方案：
- 基础架构即服务（IAAS）-硬件（通常为虚拟）；
- 软件即服务（SAAS），例如DBAS-数据库即服务；
- 平台即服务（PAAS）；
- 应用即服务（AAAS）。
同时，没有什么可以阻止各层之间的相互依赖。显然，平台或软件下会存在基础架构。
关于“私有云”一词有些困惑。有时将其称为本地云，有时将其部署在完全隔离网段的租用基础架构上。甚至提到了带有加密的内存和磁盘的虚拟机，而内存转储不会使提供者访问您的信息。在本文中，我们将讨论内部部署的解决方案。
引入私有云时，期望它们与公共云相同，只是更便宜，更安全且更可靠。因此，许多人认为私有云优先级更高。通常，专家只需部署选定版本的Kubernetes或Openshift，并相信这就是他们的工作完成的地方。
公司在实施内部部署云时期望获得什么：
- 资源成本低。因为您只为使用的东西付费。
- 尽快添加和回馈资源的能力。
- 容错能力。服务器崩溃，而是自动提供了另一个服务器。
- 维护成本低。
如何在公共云中实现？
通常，由于流程的自动化，规模经济（批量出售）和不同消费者之间的资源共享。
让我们在私有云的背景下看一下这些承诺。
1.与传统基础设施相比，资源成本低。
其实并非如此。相同的软件部署在相同的计算机上，但位于容器中。相反，根据我们的经验，浪费了更多的资源。
2.能够非常快速地增加和减少资源。
没有。要进行扩展，您需要使闲置的硬件和软件许可证储备保持闲置状态，或者首先丢弃不必要的内容。您可以取消使用资源，但是这些资源将处于空闲状态。
3.容错能力。
是的，但是有很多细微差别。假设服务器已关闭。在哪里可以买到另一个？如何快速部署并将其添加到集群？如果您不是Amazon，那么您将没有无限的资源供应。
4.支持成本低。
我们增加了至少一层（容器化平台）和一些新系统。我们需要具有新能力的专家。节省的钱从哪里来？
让我们更详细地研究这些问题。重要的是要记住，私有云必须与现有的遗留系统共存。组织被迫并行维护现有系统的基础架构，从而组织混合IT环境。
自然，系统的99％并非从头开始构建。通常，即使在实施PAAS解决方案之前，也存在一组流程和自动化来支持旧的基础架构。DevOps流程，计划和资源所有权，监控，软件更新，安全性-所有这些问题都必须在私有云的实施过程中达成共识并进行更改。
DevOps流程如何变化
通常，在实施自己的PAAS之前，构建DevOps的方法是基于使用Ansible或Chef等配置自动化系统的。它们使您可以使用现成的脚本库自动执行几乎所有常规IT流程。但是，集装箱化平台正在推广一种替代方法-“不变基础设施”。其本质不是更改现有系统，而是使用新设置获取系统的现成虚拟映像，并用新映像替换旧映像。新方法不会否决旧方法，但是会强制将配置自动化引入基础结构层。当然，遗留系统需要保留旧方法。
让我们谈谈基础架构层
IT中的事实上的标准是虚拟基础架构的使用。如实践所示，最常见的选择是使用vSphere。造成这种情况的原因很多，但也有后果。在我们的实践中，由于解决方案性能的负责人几乎完全缺乏控制力和对该过程的影响，加剧了资源超额预订（经常在一个皮肤上缝制七个帽子）的问题。公司部门职责范围的划分，资源请求程序的形式化以及部门管理的不同目标，导致了产品环境中的问题以及负载测试的不一致。在某个时候，我们的开发部门甚至创建了虚拟的核心绩效评估工具，快速诊断硬件资源不足。
显然，在这样的基础架构上放置容器化平台的尝试将为现有的混乱局面带来新的色彩。
本地容器化平台是否需要虚拟基础架构还是将其裸机（在铁质服务器上）更好？这个问题已经讨论了很长时间，并且涉及面很广。虚拟化系统制造商的游说文章认为，实际上没有性能损失，而且收益太大。另一方面，有独立的测试结果表明性能损失约10％。不要忘记vSphere许可证的成本。例如，要在便宜的硬件上安装免费版本的Kubernetes只是为了省钱并为vSphere付费？有争议的决定。
值得一提的是开源基础架构虚拟化解决方案，例如Open Stack。总体而言，他被视为需要在团队中进行大量投资的解决方案。根据网络上的统计数据，Open Stack支持团队的人数为20至60人。这与容器化平台支持是分开的！市场上很少有这样的专家，这增加了他们的成本。这种投资通常只能在非常大量的资源上获得回报。
重要的是要考虑公司中具有独特能力的专家的存在。不幸的是，尽管具有透明性和较低的许可成本，但Kubernetes裸机安装通常由于缺乏适当的安装自动化工具而受到阻碍。我们希望未来属于这种方法。
影响虚拟安装和裸机安装之间选择的另一个方面是铁服务器的组织。
通常，组织出于特定目的购买服务器。您可以在数据中心租用服务器（从它们提供的产品中租用），可以标准化和统一命名法（简化组件冗余），可以节省硬件（许多廉价的服务器），可以节省机架空间。不同组织中的不同方法。通常，这些服务器要么是功能强大的服务器，具有大量的内核和内存，要么是体积相对较小的服务器，或者是预制的大杂烩。但是，不要忘记传统系统的需求。在这一点上，我们再次遇到概念上的矛盾。 Kubernetes意识形态是许多廉价的硬件，并且已经为失败做好了准备。服务器掉线了-没关系，您的服务已移至另一服务。数据被分片（复制），而不绑定到容器。传统思想-硬件级别的冗余。 RAID阵列磁盘架，服务器上的多个电源，热插拔。专注于最大的可靠性。要购买这样的Kubernetes基础架构可能会付出不合理的代价。
, …
如果公司拥有配备许多核心的高性能服务器，则可能有必要将它们分配给不同的使用者。在这里，如果没有虚拟化系统，您将无法做。同时，有必要考虑服务器故障或维护停机的可能性。算术很简单：如果有两台服务器，如果一台服务器出现故障，则每台服务器需要50％的动力储备；如果-4台服务器，如果其中一台发生故障，则需要25％的备用空间。乍一看，一切都很简单-您需要无限数量的服务器，然后其中一台服务器的故障不会影响总容量，也不需要保留任何资源。 las，一台主机的资源大小无法大大减少。至少，它应该包含所有相关组件，Kubernetes术语称之为“ pods”。当然，当挤入较小的服务器时，平台本身的服务开销成本正在增长。
出于实际目的，希望统一平台的主机参数。在逼真的示例中，有两个数据中心（对灾难恢复场景的支持意味着至少要保留50％的资源）。接下来，确定组织对容器化平台资源的需求，并确定将其放置在标准裸机或虚拟主机上的可能性。Kubernetes建议-每个节点不超过110个Pod。
因此，要确定节点的大小，您需要考虑以下因素：
- 希望使节点相等。
- 节点必须适合您的硬件（对于虚拟机-多个，一个硬件N个虚拟）；
- 如果一个节点发生故障（对于具有虚拟基础结构的版本-一台铁服务器），则其余节点上应该有足够的资源将Pod移到它们上。
- 一个节点上的Pod不能过多（> 110）；
- 在其他条件相同的情况下，希望使节点更大。
在体系结构的每个方面都必须考虑这些类型的功能。
集中式日志记录-如何从多个选项中进行选择？
监视-也许您现有的监视系统将无法运行，保留两个或迁移到新的监视系统？
平台更新到新版本-定期还是仅在绝对必要时更新？
两个数据中心之间的容错平衡-如何？
安全体系结构，与遗留系统的交互-与公共云有所不同。可以建议构建系统，以便有可能迁移到公共云，但这会使解决方案复杂化。
公共云和私有云的资源的计划，分配和所有权差异不大。主要区别在于有限的资源量。如果在公共云中随时可以使用其他必要的资源（例如，用于负载测试），则内部部署必须仔细计划其使用顺序。这意味着您可能要进行夜间发射，因此，第二和第三条线的员工的工作将在不适当的时间增加。对于自己的人来说，这并不是什么新鲜事物，但是对于等待私有云采用的奇迹，却充满了失望的痛苦。
“干部决定一切”
在计划实施本地容器化平台时，首先，需要具有独特能力的专家。在目前的劳动力市场中，显然没有足够的人才。而且，如果没有这种实施的经验，甚至很难列出所有必要的专家。
例如，要使平台正常工作，您需要选择并安装存储系统。无论选择哪种系统（CEPH或Portworx），这对于平台都是至关重要的。每个人都知道需要管理员来维护数据库。同样，数据存储系统需要单独的专家。不幸的是，在实施该系统之前没有人考虑过这一点！请注意，不同产品的管理员之间的差异是巨大的-与Oracle DBA和MS SQL DBA之间的差异相当。每个职位至少需要两个人：员工去度假，生病，甚至上帝禁止，辞职。对于每个能力，依此类推，支持该解决方案所需的能力列表令人印象深刻。
我要立即警告不要企图跨越某些全能士兵的所有能力。它们的成本，稀有性和损失风险超过了所有合理的限制。
同样，云维护是一个复杂的过程。云公司并非一无所获：在多云的雾气背后，有很多技术和投入的劳动力。
当然，使用咨询服务可以大大加快平台的实施。经验丰富的合作伙伴将帮助您避免许多错误，建立流程并培训您的团队。但是，如果您在平台上托管关键业务服务，则提供质量支持和开发同样重要。而且，目前，市场上现有的所有系统都在积极开发中，出现了新技术，平台的新版本可能需要在升级之前迁移复杂的流程并进行严格的测试。需要强大的支持团队来确保系统的可靠运行。而且您将持续需要这样的团队。
您何时应考虑实施本地容器化平台？
首先，有必要评估投资与回报之间的比率，硬件和员工的成本量。可能有一定的理由使我们无法生活在公共云中，或者确实存在严重的资源需求。也就是说，如果一个组织大约需要100个Core，而您还不准备将支持团队扩展到数十人，那么您很可能应该专注于公共云或具有应用程序服务器的简单配置。支持平台需要最小的团队规模，而且成本可能无法收回。但是，借助扩展资源和所有流程的胜任的自动化，私有解决方案的收益将非常可观。可以使用几乎相同的命令维护数百个节点。
另一个选择标准是计算资源需求的可变性。如果公司中的业务流程或多或少地产生了统一的资源负载，则开发自己的基础架构将更加有利可图。如果您需要使用大容量，但很少使用，请考虑使用公共云或混合云。
无论如何，在选择本地解决方案时，请认真认真地进行系统的工作，并准备对团队进行投资。从简单到复杂。注意实施时间，并在升级到新版本的平台时特别小心。使用从别人的错误中获得的经验，而不是您的错误。
感谢您阅读本文，我们希望您找到有用的信息。