大家好！
在本文中，我们决定推测一下何时以及为什么企业需要Kubernetes。 入门技术有多难，有多快以及如何获得回报。 是否值得，这一切都会带来什么威胁。 我们并没有设定编写深入的技术评论的任务，其中有很多，但是在以下材料中，我们肯定会分享有关Kubernetes下应用程序体系结构和稳定性方面的最佳实践。 现在，我们将重点放在游戏是否值得烛光以及我们将获得的收益上。
上市时间-更新市场更新的速度-如今已成为IT解决方案有效性的关键因素。 该产品每天都需要改进：向其中添加新功能和模块，保持文档和脚本处于完美状态。 同时，在线系统应平稳运行并进行更新，而不会影响用户。
微服务，容器和用于编排的基础结构的保护对象是Kubernetes（或K8S，在技术界称为K8S）。
Kubernetes如何提供持续的系统更新
更新IT解决方案的主要任务是确保从开发环境转移到产品平台后其正确运行。 以及在更新产品时系统的平稳运行。
问题在于开发环境和工业服务器的设置通常不匹配。 容器通过将所有软件组件组合到一个与外部环境隔离的软件包中来解决此问题。 这使您可以在任何基础架构上快速可靠地部署应用程序，并有助于更新系统的代码库。
用户不会注意到，更新是通过容器的复制以及用户从一个容器到另一个容器的顺序重定向来进行的。 对于容器管理（业务流程），我们使用Kuberenetes。 最终，它可以在发生故障时促进解决方案管理，部署和升级，性能监视和调试。
当公司需要Kubernetes时
在以下情况下，公司应该考虑切换到Kubernetes平台了：
- 项目或系统是业务的重要工具，因此即使某些部分发生故障，项目或系统也必须具有容错能力并能够继续工作。
- 系统负载沉重，同时保持快速更新或改进。
- 系统定期需要其他容量。 并迅速需要它们。
- 有了这些，就可以以数周，数月，数年而不是数小时或数天的速度衡量向工业环境提供更新的速度。
除上述内容外，还需要使用Kubernetes作为该解决方案的自动化和标准化工作的工具：
- 公司的IT系统之间没有隔离，并且每个系统都可以相互影响。
- 如果您每次需要编写一个单独的脚本来与部署系统的服务器的参数进行通信，也就是说，您只能手动扩展此过程。
- 开发团队中有关键人物-有关项目或系统的“秘密知识”的载体，它们似乎是独特且不可替代的。
本质上，对于需要支持24/7在线信息系统的公司来说，必须切换到Kubernetes。
为什么选择Kubernetes？
Kubernetes并不是持续集成和部署（CI / CD）的唯一选择。 但是，正是Kubernetes成为管理要求高可用性的系统的行业标准。
对于我们作为开发人员而言，支持Kubernetes的决定性论据如下：
- 该平台专注于应用程序，而不是基础架构。
- Kubernetes便于使用一个数据中心以及分布在不同城市的多个数据中心。
- 通过清晰的文档和活跃的社区，轻松提供解决方案支持。
- 灵活配置不同的应用程序，安全地分配流量。
- Docker容器支持。
Kubernetes业务有什么好处？
- 灵活的配置和自动更新过程
您自己确定将系统的哪一部分投入商业运营。 Kubernetes使您可以缩短发布周期。 从系统源代码到发布到产品环境的所有操作都是自动进行的。 您无需工程师团队即可使系统正常运行。 当前更新不会影响系统的性能，并且可以在方便开发人员的任何时间进行。 - 系统的放置和缩放
该系统既可以放置在客户（或数据中心）的计算能力上，又可以放置在任何云提供商（例如，Amazon或Azure）上。 通过扩展群集，可以轻松实现任何级别的性能和容错能力。 - 标准化和自我证明
该解决方案不需要说明。 它是自记录文件，可立即自动包装成使用单位-容器。 我们将Kubernetes中的配置描述为计划/图表。 我们不会像Kubernetes之前那样编写准备环境的脚本。 相反，我们将有关解决方案工作方式的信息传递给Kubernetes。 他本人也实施了该计划。
开发人员现在正在编写一个应用程序以在容器中工作。 DevOps工程师编写了一个应用程序如何在容器中工作的图表，而Kubernetes本身执行构建解决方案的任务。
Kubernetes技术是标准化的。 您可以轻松地在发布系统中培训新员工，或将系统转移给新承包商。
Kubernetes创建的最终配置描述也是该系统的文档。 从名称中，可以立即清除配置了哪些参数以及它们的用途。
因此，Kubernetes平台总体上实现了应用程序的发行，更新和发行。
- 无痛实时测试
测试解决方案的过程已更改。 开发人员可以根据需要创建与产品相同的环境以进行自动测试。 有关应用程序如何工作以及Kubernetes如何与应用程序一起工作的常规日志有助于调查问题并更快地发现错误。
向Kubernetes进行业务过渡将需要什么
Kubernetes本身只是新系统的一小部分。 您需要准备好使用Kubernetes作为标准化整个开发周期，更新和发布应用程序的工具，这将在过渡时对一切进行更改：软件体系结构，开发过程和基础架构维护。
- 解决方案架构
从产品的角度来看，只有在将系统实施或升级到基于可打包在容器中的服务（无状态服务）的微服务体系结构时，过渡才有可能。 - 开发过程
从开发过程的角度来看，过渡主要涉及思想上的改变。 最后情况的任何情况改善和“拐杖”都被完全排除在外。 一个IT解决方案开发人员只能以一个团队的方式工作，该团队最初生产的是经过初步测试，支持，打包，可分解的产品。 从代码的第一行到操作，所有内容都应该在逻辑上构建。 - 更新过程
即使在开发应用程序体系结构的阶段，您也需要考虑如何不断更新解决方案。 并考虑到人们在更新过程中使用系统并且他们可能会落入不同的版本这一事实，立即了解如何更新数据库，API，支持应用程序的多个版本在逻辑上如何。
另一个想法是，当切换到Kubernetes时，基础架构开始以只读模式运行，并且要更新系统，您需要创建应用程序映像的新版本并告诉Kubernetes使用新版本，之后它将关闭旧版本，并且将会删除自己。
这样就无法避免系统的改进和工作技术的变化。 移动不会很快。 但是您只需要更改一次范例。
案例 我们如何将微服务系统转移到Kubernetes
我们在产品环境中运行一个基于微服务架构的高负载解决方案，该解决方案每天传输超过30万笔交易，并且在高峰时间传输每小时60-80 000笔交易。 我们会定期更新产品，以前还有一些紧急版本需要暂停系统或部分功能。
我们在没有K8S的情况下进入杂货店环境，但最初开发该系统时就非常注意。 将解决方案转换为Kubernetes花费了6周的时间。 我们朝以下方向移动：
1）设置部署管道
一个 配置管道以在测试环境中进行连续组装，测试和应用程序更新（CI / CD）。
b。 在工业环境中设置连续更新。
c。 环境的准备和配置应尽可能接近工业环境（preprod）。 我们在当前虚拟机旁边部署并测试了群集。
d。 制定向工业环境迁移的计划。
因此，一切似乎都很简单，我们拥有适用于所有环境的CI / CD管道，您可以进行切换，但这还为时过早！
2）集群配置选择
我们花了几周的时间来选择最稳定的Kubernetes集群组件和版本配置：操作系统+ Docker + Kubernetes。
我们测试了3种不同的操作系统配置（Ubuntu，CentOS，Oracle Linux最新版本）。 在每个操作系统上，我们检查了Docker和Kubernetes的2个不同版本-版本是标准操作系统软件包的最新版本以及制造商的最新版本。 结果，Oracle Linux标准发行版中的配置显示出最大的稳定性，因此我们选择了它们。
3）配置容器设置
我们花了更多时间调整容器的参数-设置了对内存，磁盘和进程的要求。
并且只有在我们完成所有这些工作并在接近战斗负荷的情况下，在前探针上测试了系统功能的不同参数（稳定性，容错性等），并且系统稳定运行之后，我们才进入最后阶段-迁移。
然后，一切都很简单。
C日迁移
对于战斗迁移，我们根据系统算法内部工作的时间表，选择系统负载最小的时间：最少的用户数量，并且不增加负载。
该系统的停机时间约为一个小时，几乎不影响用户。 迁移本身包括将用户从一个系统切换到另一个系统，并观察到一切正常。
Kubernetes的生活
现在，更新过程不会影响系统性能，可以在方便开发人员的任何时候进行，外观如下：
- 开发人员进行了修订，对其进行了测试，并将代码发送给了出版物。
- 该代码是自动组装的，打包在docker映像中，然后发布到私有docker存储库中。
- Kubernetes会自动生成新版本的服务，检查服务是否正常运行，切换用户以使用新版本的服务，停止旧版本的工作并将其从群集中删除。 更新已进行。
总结我们的经验
如果满足以下条件，则需要Kubernetes：
- 需要系统的高可用性。
- 系统正在动态开发，您需要闭上眼睛将更改交付到产品环境。
- 您想要从代码到产品环境作为一个团队工作。
- 您正在制作一个可以运行多年的动态，不断发展的系统。
Kubernetes是“昂贵的”，因为进入该技术将需要：
- 由相关技术的开发人员研究。
- 审查设计，开发，部署，测试和环境管理过程。
- 具有操作Kubernetes本身的经验：现在，您不仅需要监视系统，还需要监视Kubernetes应用程序服务。
快速偿还Kubernetes：
- 系统更新过程更加简单快捷。 开发人员从繁重的工作中解放了出来。
- 每位新专家都将进入轨道。
- 输送机将是透明且自动化的。
- 您的团队将针对其他系统重复该经验。
- 您将在不停止运行的情况下更新系统，这意味着您不会停止业务。
PS实用建议：将技术入门分为两个阶段：开发具有正确微服务架构的系统，并将其移至K8S的控制之下。 因此，Kubernetes的过渡不会转变为全球重构。