我正在使用带有 Istio 的 Azure AKS 处理微服务架构。
我全部配置，开发者使用微服务创建web平台、api等
但是，我对此表示怀疑。有很多 yaml 需要为 Istio 和 Kubernetes 配置，例如Ingress、VirtualService、Gateway等
此配置是开发人员责任的一部分吗？他们应该创建和配置它吗？还是这些配置文件是 DevOps 团队责任的一部分？让开发者只负责创建nodejs项目，DevOps团队配置nodejs项目配置在k8s架构中执行？
【问题讨论】：
标签： kubernetes devops istio azure-aks
开发者需要
1) 在这里很明显。 2) 通常有时不是隐含的，实际上我认为如果开发人员认为他们不拥有运行时配置，那么就像把责任推到了墙边。
例如，如果应用程序将被入口控制器公开 app-dev 需要确保
相同的参数可以扩展到其他资源类型。比如说虚拟机或部署规范。
现在，如果开发人员认为不编写这些 yaml 文件不是他们的责任，他们仍然需要与另一个“人”记录他们的服务需求合同，以使他们能够编写配置。但是 yamls 本身不就是契约吗？
【讨论】：
Kubernetes 的全部意义在于帮助开发人员尽可能快地开发应用程序，而不是纠结于如何部署 pod。
话虽如此，开发人员对应用程序负责，并且如此处所述，他们应该知道他们的应用程序将运行的环境。 由 devops 团队来配置 ingress、Istio 等。此外（理想情况下），如果 yaml 是由开发人员编写的，他们应该检查它们。开发人员不必担心需要多少副本集或任何其他 K8s 配置。
话虽如此，事先标准化此过程（谁拥有什么）始终是一个好习惯。
【讨论】：
这是一个很好但很难的问题。
Kubernetes 改变了 DevOps 角色的含义，如文章 DevOps Before and After Kubernetes 中所述。
正如您所说，Kubernetes 和 Istio 需要处理很多 Yaml。现在，DevOps 团队需要帮助将应用交付到 Kubernetes 的过程自动化：
对于应用团队而言，将典型的中型、基于微服务的应用容器化需要编写和管理数千行 K8s 清单文件。每个新的部署都需要重建容器镜像和几个清单文件的潜在修改。显然，当今世界的 DevOps 将不同于前 Kubernetes 时代的 DevOps。
这些新世界的 DevOps 团队可能会在交付给 Kubernetes 的自动化流程方面做得很好，这样可以更快地实现效率提升和经济效益，同时保持可靠性和速度。这种自动化以及标准化流程将进一步在管理基础设施的 IT 团队和向 K8s 交付应用程序的应用程序团队之间建立一个干净的交接界面。对于追求敏捷性和大规模无摩擦交付的企业而言，找到通往 Kubernetes 的最短路径将是未来 DevOps 的核心。
这可以通过不同的方式完成。例如。构建抽象或设置 CI/CD 自动化。最后，您如何做到这一点，取决于您的组织在这种自动化方面投入了多少。
Kubernetes is Not Your Platform, It's Just the Foundation 的演讲非常有趣，它讲述了在 Kubernetes 之上创建抽象以成为应用开发人员的有效平台。
在一个很少自动化的组织中，开发人员将获得一个命名空间并自己完成所有 Yaml。但在自动化程度高且对 Kubernetes 平台进行投资的组织中，平台团队通常会创建一个Kubernetes CRD，例如kind: Application 和一个控制器以 自以为是 的方式配置 Istio VirtualService 和 Deployment 以减少开发人员的认知负荷 - 所以他们只有很少的 Yaml -要管理的字段。这种解决方案的一个例子是NAV application Yaml - 他们甚至有用于配置 PostgreSQL 数据库或 Redis 缓存的字段。
【讨论】：