使用Kubernetes时的DevOps和开发人员责任

Question

我正在使用带Istio的Azure AKS处理微服务体系结构。

我全部配置完毕，开发人员使用微服务来创建Web平台，API等。

但是，我对此表示怀疑。为Istio和Kubernetes配置了很多Yaml，例如Ingress，VirtualService，Gateway等

此配置是否属于开发人员责任？他们应该创建并配置它吗？还是这些配置文件属于DevOps团队的职责？以便开发人员仅负责创建nodejs项目，而DevOps团队将nodejs项目配置配置为在k8s架构中执行？

Answer 1

开发人员需要

1. 专注于他的业务逻辑。
2. 也知道他的代码将在何处以及在哪种环境下运行。

1）在这里很明显。 2）通常有时不是隐式的，实际上，我认为如果开发人员认为他们不拥有运行时配置，那么就像把责任扔在墙上一样。

例如，假设应用程序要由入口控制器公开，则 app-dev需要确保

• 该应用程序可以很好地处理http和https流量（以防我们进行ssl直通）。
• 所有资源url /路径和正确的端口均已公开，并已在入口中注册。

相同的参数可以扩展到其他资源类型。说虚拟机或部署规范。

现在，如果开发人员认为这些不是他们的责任而不是不编写这些yaml文件，则他们仍需要与另一个“人员”记录其服务需求的合同，以使他们能够编写配置。但是，那只签订合同的山寨人不是吗？

Answer 2

Kubernetes的全部目的是帮助开发人员尽可能快地开发应用程序，而不是沉迷于Pod的部署方式。

话虽这么说，开发人员负责应用程序，并且如此处所述，应该了解运行应用程序的环境。 由devops团队来配置ingress，Istio等。同样（理想情况下），他们应该检查yaml是否由开发人员编写。开发人员不必担心要有多少个副本集或任何其他K8s配置。

话虽如此，预先标准化此过程（谁拥有什么）始终是一个好习惯。

Answer 3

这是一个很好但是很困难的问题。

Kubernetes改变了DevOps角色的含义，如文章DevOps Before and After Kubernetes中所述。

正如您所说，Kubernetes和Istio需要处理许多Yaml。现在，DevOps团队需要帮助自动化将应用交付到Kubernetes的过程：

对于一个应用程序团队而言，将一个典型的基于中型微服务的中型应用程序进行容器化将需要编写和管理数千行K8s清单文件。每个新的部署都需要重建容器映像并可能需要修改几个清单文件。显然，当今世界的DevOps将与Kubernetes之前的时代的DevOps不同。

这些新世界的DevOps团队在将自动化过程交付给Kubernetes方面可能做得很好，因此可以在保持可靠性和速度的同时更快地实现效率提高和经济利益。这种自动化以及标准化的流程将进一步在管理基础架构的IT团队与向K8交付应用程序的应用程序团队之间实现干净的交接界面。对于追求敏捷性和无摩擦交付的企业来说，找到通往Kubernetes的最短路径将是DevOps的核心。

这可以通过不同的方式完成。例如。建立抽象或设置CI / CD自动化。最后，如何执行此操作取决于您的组织在自动化方面的投入。

演示文稿Kubernetes is Not Your Platform, It's Just the Foundation对于在Kubernetes之上创建抽象以成为应用程序开发人员的有效平台非常有趣。

在具有 little 自动化的组织中，开发人员将获得一个命名空间，并自行完成所有Yaml。但是在一个对Kubernetes平台具有高度自动化和投资的组织中，平台团队通常会创建一个Kubernetes CRD例如kind: Application和一个控制器，该控制器以修正的方式配置Istio VirtualService和Deployment，以减轻开发人员的认知负担-因此他们几乎没有Yaml字段要管理。 NAV application Yaml是这种解决方案的一个示例-它们甚至具有用于配置PostgreSQL数据库或Redis缓存的字段。