使用 Kubernetes 时的 DevOps 和开发人员责任
DevOps and Developer responsibility when using Kubernetes
我正在使用 Azure AKS 和 Istio 处理微服务架构。
我配置所有，开发人员使用微服务创建网络平台、api 等
但是对此，我有一个疑问。有很多 yaml 可以为 Istio 和 Kubernetes 配置，例如Ingress、VirtualService、Gateway等
此配置是否属于开发人员的责任？他们应该创建和配置这个吗？还是这些配置文件是 DevOps 团队职责的一部分？让开发者只负责创建nodejs项目，DevOps团队配置nodejs项目配置在k8s架构下执行？
开发者需要
- 专注于他的业务逻辑。
- 也知道他的代码要去哪里运行以及在什么样的环境下
1) 在这里很明显。 2) 有时通常不是隐含的，实际上我认为如果开发人员认为他们不拥有 运行 时间配置，那么就像把责任推到墙外。
举例来说，如果应用程序将被入口控制器公开
app-dev需要确保
- 该应用程序可以很好地处理 http 和 https 流量（以防我们进行 ssl 直通）。
- 所有资源 url/paths 和正确的端口都公开并注册到入口。
相同的论点可以扩展到其他资源类型。说虚拟机或部署规范。
现在，如果开发人员认为这些不是他们的责任，即不编写这些 yaml 文件，他们仍然需要记录他们的服务需要与另一个“人”的合同，以使他们能够编写配置。但是 yaml 本身不是那个契约吗？
Kubernetes 的全部意义在于帮助开发人员尽可能快地开发应用程序，而不是陷入pods 部署方式的混乱之中。
话虽如此，开发人员对应用程序负责，正如此处所述，他们应该了解他们的应用程序所在的环境 运行。
由 devops 团队来配置入口、Istio 等。此外（理想情况下），他们应该检查 yaml 是否是由开发人员编写的。开发人员不应该担心需要多少副本集或任何其他 K8s 配置。
话虽这么说，事先标准化此过程（谁拥有什么）始终是一个好习惯。
这是一个很好但很难的问题。
Kubernetes 已经改变了 DevOps 角色的含义，如文章 DevOps Before and After Kubernetes 中所述。
正如您所说，Kubernetes 和 Istio 需要处理很多 Yaml。现在，DevOps 团队需要帮助自动化将应用程序交付到 Kubernetes 的过程：
For an app team, containerizing a typical medium-sized, microservices-based app would require several thousands of lines of K8s manifest files to be written and managed. Each new deployment would need a rebuild of container images and potential modifications of several manifest files. Clearly, DevOps in today’s world will be different from DevOps in the pre-Kubernetes era.
These new-world DevOps teams may do well with an automation process for delivery to Kubernetes so that efficiency gains and economic benefits can be realized sooner while also maintaining reliability and speed. Such automation along with a standardized process will further enable a clean hand-off interface between the IT teams managing the infrastructure and the app teams delivering apps to K8s. For enterprises pursuing agility and frictionless delivery at scale, finding the shortest path to Kubernetes will be at the heart of DevOps in times to come.
这可以通过不同的方式完成。例如。构建抽象或设置 CI/CD 自动化。最后，你如何做到这一点，取决于你的组织在这个自动化上投入了多少。
关于创建 Kubernetes 的抽象 on-top 成为应用程序开发人员的有效平台的演示文稿 Kubernetes is Not Your Platform, It's Just the Foundation 非常有趣。
在一个 很少 自动化的组织中，开发人员将获得一个命名空间并自己完成所有 Yaml。但在自动化程度高且投资于 Kubernetes 平台的组织中，平台团队通常会创建一个 Kubernetes CRD e.g. kind: Application and a controller that configure the Istio VirtualService and Deployment in an opinionated way to reduce the cognitive load for the Developers - so they have very few Yaml-fields to manage. An example of such solution is NAV application Yaml - 他们甚至有用于配置 PostgreSQL 数据库或 Redis 缓存的字段。
我正在使用 Azure AKS 和 Istio 处理微服务架构。
我配置所有，开发人员使用微服务创建网络平台、api 等
但是对此，我有一个疑问。有很多 yaml 可以为 Istio 和 Kubernetes 配置，例如Ingress、VirtualService、Gateway等
此配置是否属于开发人员的责任？他们应该创建和配置这个吗？还是这些配置文件是 DevOps 团队职责的一部分？让开发者只负责创建nodejs项目，DevOps团队配置nodejs项目配置在k8s架构下执行？
开发者需要
- 专注于他的业务逻辑。
- 也知道他的代码要去哪里运行以及在什么样的环境下
1) 在这里很明显。 2) 有时通常不是隐含的，实际上我认为如果开发人员认为他们不拥有 运行 时间配置，那么就像把责任推到墙外。
举例来说，如果应用程序将被入口控制器公开 app-dev需要确保
- 该应用程序可以很好地处理 http 和 https 流量（以防我们进行 ssl 直通）。
- 所有资源 url/paths 和正确的端口都公开并注册到入口。
相同的论点可以扩展到其他资源类型。说虚拟机或部署规范。
现在，如果开发人员认为这些不是他们的责任，即不编写这些 yaml 文件，他们仍然需要记录他们的服务需要与另一个“人”的合同，以使他们能够编写配置。但是 yaml 本身不是那个契约吗？
Kubernetes 的全部意义在于帮助开发人员尽可能快地开发应用程序，而不是陷入pods 部署方式的混乱之中。
话虽如此，开发人员对应用程序负责，正如此处所述，他们应该了解他们的应用程序所在的环境 运行。 由 devops 团队来配置入口、Istio 等。此外（理想情况下），他们应该检查 yaml 是否是由开发人员编写的。开发人员不应该担心需要多少副本集或任何其他 K8s 配置。
话虽这么说，事先标准化此过程（谁拥有什么）始终是一个好习惯。
这是一个很好但很难的问题。
Kubernetes 已经改变了 DevOps 角色的含义，如文章 DevOps Before and After Kubernetes 中所述。
正如您所说，Kubernetes 和 Istio 需要处理很多 Yaml。现在，DevOps 团队需要帮助自动化将应用程序交付到 Kubernetes 的过程：
For an app team, containerizing a typical medium-sized, microservices-based app would require several thousands of lines of K8s manifest files to be written and managed. Each new deployment would need a rebuild of container images and potential modifications of several manifest files. Clearly, DevOps in today’s world will be different from DevOps in the pre-Kubernetes era.
These new-world DevOps teams may do well with an automation process for delivery to Kubernetes so that efficiency gains and economic benefits can be realized sooner while also maintaining reliability and speed. Such automation along with a standardized process will further enable a clean hand-off interface between the IT teams managing the infrastructure and the app teams delivering apps to K8s. For enterprises pursuing agility and frictionless delivery at scale, finding the shortest path to Kubernetes will be at the heart of DevOps in times to come.
这可以通过不同的方式完成。例如。构建抽象或设置 CI/CD 自动化。最后，你如何做到这一点，取决于你的组织在这个自动化上投入了多少。
关于创建 Kubernetes 的抽象 on-top 成为应用程序开发人员的有效平台的演示文稿 Kubernetes is Not Your Platform, It's Just the Foundation 非常有趣。
在一个 很少 自动化的组织中，开发人员将获得一个命名空间并自己完成所有 Yaml。但在自动化程度高且投资于 Kubernetes 平台的组织中，平台团队通常会创建一个 Kubernetes CRD e.g. kind: Application and a controller that configure the Istio VirtualService and Deployment in an opinionated way to reduce the cognitive load for the Developers - so they have very few Yaml-fields to manage. An example of such solution is NAV application Yaml - 他们甚至有用于配置 PostgreSQL 数据库或 Redis 缓存的字段。