📍 💆🏼 🚕 秉承盗版精神的Kubernetes：我们通往微服务的道路和现成的实施模板 🎰 🧑🏼 👐🏾

嗨，我是Yuri Buylov，我在CarPrice从事开发工作，还实现了DevOps实践，微服务和Kubernetes。我想本着海盗精神谈论Kubernetes，不仅是管理一艘美丽的大型帆船，而且还涉及一艘小而难看的渔船船队，有时会生锈，但速度很快，敏捷且危险。

对于那些开发基础架构或将基础架构迁移到微服务，在Kubernetes上实现DevOps以及以各种方式迁移到云原生的人们来说，这将是很有趣的。我将向您介绍我们的发展道路，在本文的最后，我将分享我们在微服务环境中的基础知识-我将提供指向模板的链接，该模板将为开发人员和测试人员提供方便。

这篇文章是基于在视频演示@Kubernetes会议通过Mail.ru云解决方案如果您不想阅读，请参阅。

Kubernetes之前我们的生活：开发服务器，裸机和Ansible

我们生活在不断变化和实验的模式中：AV测试，测试各种假设。我们启动了新服务，然后，如果某些功能不起作用，我们将其删除。

一旦我们在PHP中获得了巨石，这带来了很多痛苦。为了提供可接受的上市时间，我们采用了典型的方式-我们开始看到这种用于微服务的整体。结果，发现大的整体变成了许多小的整体。这是正常现象，每个面临类似任务的人都是如此。

然后我们开始尝试其他技术，特别是Golang出现在我们公司中，后来成为主要的开发语言。有问题：如何开发，测试和部署所有这些？答案很明显-您需要开发服务器。每个开发人员都应该有一个开发服务器，在那里他可以连接以在那里编写高质量和高性能的代码。

结果，他们写了一个开发服务器。结果是一个Web界面控制了服务器上的docker-compose。还有一个带有源代码的容器，该容器安装在docker-compose中。开发人员可以通过SSH和程序进行连接。测试人员也在那里工作，一切正常。

但是随着服务数量的增加，它变得无法工作。到了必须部署一些东西而不要打开容器包装的时刻。我们拿了裸机，将Docker滚到那里。然后他们担任Ansible，写了几个角色。每个角色都是docker-compose所在的服务，它“来到”其中一辆汽车。

所以我们就住了：在nginx中，我们是用双手向上游注册的，他们说我们应该去哪个端口，此服务所在的位置。甚至有一个yaml文件，其中列出了所有端口，因此应用程序不会竞争它们。

我们如何来到Kubernetes并在上面建立基础设施

显然，一个人不能那样生活，需要编排。我们在2017-2018年了解这一点，所以不清楚在哪里获得该乐队。 Kubernetes才刚刚开始，有HashiCorp Nomad，Rancher和OpenShift。我们尝试了Nomad，这还不错，但是我们不想将docker-compose重写为Nomad配置。

关于Kubernetes，我们立即意识到外国同事试图做到这一点，但他们并不总是成功。而且，我们没有胡子的管理员可以使我们成为一个集群。他们开始思考如何实现这一目标。甚至那时，Kubernetes还是在亚马逊上，但是我们记得锁，之后他们紧急搬家了。因此，该选项立即被丢弃，所有更昂贵的流量在那里。

然后Kubernetes作为服务Mail.ru云容器出现在Mail.ru云解决方案平台上。我们已经将我们的S3存储从亚马逊那里移到了那里，我们决定也尝试使用K8。我们在云中部署了集群，一切正常。

为了进行测试，我们决定在那里部署一些无状态服务。部署了用于移动应用程序的API，它可以工作。发送到那里的流量的50％-可以。是的，有些东西定期掉下来，但是伙计们修复了，一切都很好。结果，整个基础架构已转移，现在它是围绕Kubernetes构建的，主要是开发服务器和舞台服务器。

每个开发人员在VMware中都有自己的Minikube，与他一起工作。我们在MCS云中的Kubernetes中启动新项目，我们还部署了Managed MySQL，该版本随S3中的所有从属，复制和备份一起提供。

我们仍然在裸机上有遗产，包括运行Ansible的Docker集群，但是总有一天我们会弄清楚的。

如何与科技动物园同住而不受苦

现在，科技动物园已不像2011年那样可怕。如果您可以在不同的地方使用专门的工具和技术并随意使用，这甚至是正常的。例如，我们在某些事情上使用Golang，但是Data Scientist使用Python进行工作，您不能强迫它们使用GO或PHP编写。

通常，我们有两个规则：

dockerize：必须有容器；
可观察性：这些容器必须可观察。

继续与动物园进行类比：有牢房，坐在这些牢房中并不重要。最主要的是，水和食物定期，自动且统一地到达，服务的“重要产品”，即原木，被集中运送到某个地方。

为了提供可观察性，我们有一个标准的堆栈：每个应用程序都将日志写入stdout，所有内容都从那里集中传输到EFK。也就是说，开发人员可以来查看Kibana中的日志。在Grafana中，我们将Prometriceus，仪表板和警报中的应用指标作为标准放置。Jaeger是Opentracing的一个故事，它向我们展示了如果我们不知道或不想以其他方式处理该服务，则谁可以访问哪个服务。

如何用所有这些进行开发和测试

假设有一位新开发人员来找我们，他看到了100个服务和100个存储库。他立即有疑问。如何部署这100个服务，以及如何配置？数据库在哪里？有什么帐户？并且有很多这样的问题。因此，新开发者的发布花费了很长的时间，他可以坐一个星期并进行所有设置。

因此，我们开发了1-Click开发环境。每个开发人员都有自己的Minikube，具有条件无限的内核和内存，并部署在VMware云中。加上一个数据库-它每天都来自生产环境，经过混淆，压缩并放在ZFS上。这是我们管理员的个人发展。我们长期从事降低成本的工作，我们需要给所有开发人员一个基础，同时又要坚持不懈。

ZFS中有快照，API开发人员可以在两秒钟内直接从生产中滚动数据库。对于自动测试，情况也一样：我们从API开始，一切正常。

这就是今天的开发流程：

开发人员感到高兴，DevOps和管理员感到高兴，因为所有过程都是统一的，可重复的和统一的。但是有一件事。

分层系统

正如Linus Torvalds所说：“谈话很便宜。给我看代码。”因此，我们使用了多层系统。有一些琐碎的层：开发，阶段，产品，对于要制作CI / CD的每个人来说，它们都会浮现在脑海。

但是仍然有开发人员，他们需要他们的某些领域，一些用户特定的故事，所以我们有一个用户价值层。但这还不够-您仍然需要测试。假设我们创建了一个分支，也许有几个服务，并且需要将其传递给测试人员，以便重复执行。为此，我们有一个包含任务值的层，即任务值。

另一个略带欢乐的时刻-我们不使用基于Helm的Tiller，但实际上我们将其用作模板引擎。也就是说，我们仅使用helm-template，它在输出处提供一个yaml文件，该文件可以归因于Minikube或集群，不需要其他任何东西。

K8s-helm存储库如何工作

就像我说的，我们在开发，生产和阶段都有明显的层次，每个服务都有一个yaml文件，当我们看到一个新服务时，添加文件。

此外，还有一个最有趣的爸爸dev.server。有一些bash脚本可以帮助您创建一个新用户，例如：不要用手创建100个服务，也不填写yaml文件，而只用一个命令即可运行。这是所有这些yaml文件的生成位置。

在同一文件夹中有一个子文件夹任务。如果需要为我们的部署设定一些特定的值，我们只需创建一个包含任务编号的文件夹，然后提交分支即可。然后，我们告诉测试人员：“这样的分支位于存储库中，请使用它并运行它。”他开始工作，猛拉bin爸爸中的命令，一切正常-无需手动配置。 DevOps的奇迹是作为代码的基础架构。

结果，该过程归结为三个团队：

新开发人员到来后，他们给他Minikube，一个带有证书和域的存档文件夹。通常，他只需要kubectl和Helm。他向自己克隆了存储库，向kubectl显示了其配置的路径，并以他的名字运行make_user命令。对于所有服务，都会为他创建副本。而且，它们不仅是创建的-还提供了一个数据库，开发人员为其指定了凭证，所有这些凭证都用于其他服务。

用户已创建，现在如何部署？这里也没有什么复杂的-我们使用他的名字运行deploy.sh，所有内容都以他的Minikube的默认命名空间形式出现在开发人员中，所有内容都可以在他的域中立即使用。

如果开发人员已编写了某些程序，则他将获取问题ID并将其提供给测试人员。测试人员将复制此分支，启动部署，并且具有新功能的环境将出现在其群集中。

K8s-头盔总成

信息库本身还被编译并内置到CI / CD流程中。这里没什么特别的-仅带有证书和Helm的kubectl。

在项目中，它看起来是这样的：

假设您已部署，并且有一个阶段需要首先进行阶段设计，然后使用Jenkins在此处进行测试。在存储库中，您具有使用Helm编译的映像。我们运行deploy名称空间service_stage run命令，一切就绪。

然后是CI，这里是.drone.yml，但是在GitLab或其他地方也会发生同样的事情。

接下来，詹金斯（Jenkins）开始，它将在阶段进行测试。如果一切正常，那么它将开始几乎相同的部署，但是已经在产品上。也就是说，这种机制不仅使开发人员和测试人员的工作更加轻松，而且还用于向产品交付功能。

我们喜欢开源，我们想投资开发DevOps，因此我们制作了一个可以使用的模板并将其上传到github。我谈论的一切都是：您可以参加，观看，测试和申请。这对于实现微服务，团队遭受微服务，或希望围绕此构建DevOps流程的事实的所有人都将非常有用。

我们的其他相关文章：

该演讲最初是由Mail.ru Cloud Solutions 在@Kubernetes会议上进行的。观看其他表演的视频，并在Mail.ru Group上注册Kubernetes附近的电报活动公告。

秉承盗版精神的Kubernetes：我们通往微服务的道路和现成的实施模板