kubectl 而不是 yaml 文件在生产中？

Question

我试图找到在生产中使用 kubernetes 的最简单方法。 YAML 模板对我来说看起来像是开销。 例如，我想要的只是公开简单的后端服务。 我可以使用带有 2 个精益命令的 kubectl 来做到这一点：

kubectl create deployment hello-server --image=gcr.io/google-samples/hello-app:1.0
kubectl expose deployment hello-server --type LoadBalancer --port 80 --target-port 8080

但是在生产中使用它可以吗？ 我想使用基础设施即代码方法。

有没有办法避免直接使用 kubernetes 模板文件并仍然遵循最佳实践？ 例如，从 docker-compose 文件或类似文件生成 Yaml 文件？

生产中预期的 kubectl 使用量是多少？ 只是

kubectl apply -f <folder> 

而在<folder>中维护模板文件是开发人员的工作？ 是否有使用 kubectl 的声明式管理而无需自己编写 kubernetes 模板？ 例如，一些文件包含生成模板所需的最少信息。

真的很想用Kubernetes，请指教最简单的方法！

Answer 1

我在这里引用原始问题：

kubectl create deployment hello-server --image=gcr.io/google-samples/hello-app:1.0 kubectl expose deployment hello-server --type LoadBalancer --port 80 --target-port 8080

但是在生产中使用它可以吗？ 我想使用基础设施即代码方法。

您的第一种方法是命令列表，必须按特定顺序执行。 此外，所有这些命令都不是幂等的，因此您不能多次运行这些命令。

同样来自原始问题：

有没有办法避免直接使用 kubernetes 模板文件并仍然遵循最佳实践？ 例如，从 docker-compose 文件或类似文件生成 Yaml 文件？

生产中预期的 kubectl 使用量是多少？ 只是

kubectl apply -f <folder>

第二种方式是声明式的，你只描述你想要的，并且命令是幂等的，所以可以多次运行没有问题。 您所需的 state 是用文本文件编写的，因此可以使用版本控制系统（例如 Git）管理任何更改，并且可以通过 CI/CD 管道中的验证来完成该过程。

对于生产环境，最佳实践是使用 git 之类的版本控制系统来处理集群所包含的内容。 这使得恢复或重新创建系统变得容易。