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

Question

我正在使用Azure AKS和Istio的微服务架构。

我配置了所有，开发人员使用微服务来创建web平台、apis等。

但有了这个，我有一个疑问。对于Istio和Kubernetes，有许多yaml需要配置，例如Ingress、VirtualService、Gateway等。

这种配置是开发人员责任的一部分吗？他们应该创建和配置这个吗？或者这些配置文件是DevOps团队责任的一部分？因此，开发人员只负责创建nodejs项目，而DevOps团队将nodejs项目配置为在k8s体系结构中执行？

Answer 1

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

Kubernetes已经改变了DevOps角色的含义，如文章库伯奈特前后的DevOps中所描述的。

就像你说的，有很多Yaml要和Kubernetes和Istio打交道。现在，DevOps团队需要帮助将应用程序交付给Kubernetes的过程自动化：

对于一个应用程序团队来说，包含一个典型的中型、基于微服务的应用程序需要数千行K8s清单文件来编写和管理。每个新的部署都需要重新构建容器映像并对几个清单文件进行可能的修改。显然，当今世界的DevOps将与库伯奈茨时代的DevOps不同.这些新世界的DevOps团队在向Kubernetes交付的自动化过程中可能做得很好，以便在保持可靠性和速度的同时，更快地实现效率和经济效益。这种自动化以及标准化的流程将进一步使管理基础设施的IT团队和向K8s交付应用程序的应用团队之间建立一个干净的交接界面。对于在规模上追求敏捷性和无摩擦交付的企业来说，寻找到Kubernetes的最短路径将是未来DevOps的核心。

这可以用不同的方式来完成。例如建立抽象或设置CI/CD自动化。最后，您是如何做到这一点的，这取决于您的组织对这一自动化投入了多少。

演示文稿库伯内特斯不是你的平台，它只是基金会对于在Kubernetes之上创建抽象作为应用程序开发人员的一个有效平台非常有趣。

在一个自动化程度较低的组织中，开发人员将得到一个名称空间，并自己完成所有的Yaml。但是，在一个高度自动化和投资于Kubernetes平台的组织中，平台团队通常会创建一个Kubernetes CRD (例如kind: Application )和一个控制器，以一种固执己见的方式配置Istio VirtualService和Deployment，以减少开发人员的认知负担--因此他们几乎没有Yaml领域需要管理。这种解决方案的一个例子是NAV应用Yaml --它们甚至有用于提供PostgreSQL数据库或Redis缓存的字段。

Answer 2

开发人员需要

1. 专注于他的商业逻辑。
2. 还知道他的代码将在哪里运行，以及在什么样的env下运行。

这里的情况很明显。这通常不是隐含的，实际上，我认为如果开发人员认为他们不拥有运行时配置，那就像把责任抛到了墙上一样。

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

• 该应用程序适用于http和https流量(万一我们正在进行ssl传输)。
• 所有资源url/路径和正确的端口都公开并向入口注册。

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

现在，如果开发人员认为这些不是他们的职责是不编写这些yaml文件，他们仍然需要记录他们的服务需要与另一个“人”的契约，以使他们能够写这些信任。但山羊犬们自己不就是那个合同吗？

Answer 3

Kubernetes的全部目的是帮助开发人员尽快开发应用程序，而不是深入研究如何部署这些应用程序。

尽管如此，开发人员负责应用程序，正如这里提到的，应该知道他们的应用程序将运行的环境。这是由开发团队来配置入口，Istio等。而且(理想情况下)，如果yamls是由开发人员编写的，他们应该检查它们。开发人员不应该担心需要有多少副本集或任何其他K8s配置。

尽管如此，事先标准化这一过程(谁拥有什么)始终是一种良好的做法。