开发者的Kubernetes懒人指南( 五 ) _Kubernetes

ReplicaSet：总结ReplicaSet几乎是你想要的，但它们存在一个问题：它们与特定版本的容器镜像绑定（在我们的例子中为 3.85），而这些实际上不应该更改。而且 ReplicaSets 也不能帮助你完成软件的滚动发布过程（考虑零停机时间）。
因此，我们需要一个新的概念来帮助我们管理新版本的发布。见识一下：Deployment（部署）。
apiVersion: apps/v1kind: Deploymentmetadata: "ignore for now"# ...spec:progressDeadlineSeconds: 600replicas: 2revisionHistoryLimit: 10selector: "ignore for now"# ...strategy:rollingUpdate:maxSurge: 25%maxUnavailable: 25%type: RollingUpdatetemplate:"ignore for now"# ...你还需要学习 Deployments 的其他 92387 个 YAML 键值对，而我们已经在本文中进行了相当长时间的探讨。其要点是：Kubernetes 允许你使用不同的软件发布策略（rollingUpdate或recreate）。

Recreate（重新创建）将终止所有旧版本的 pod ，并使用新版本重新创建它们：这会导致用户经历停机时间。
RollingUpdate（滚动更新）将在仍然通过旧 pod 提供流量的情况下执行更新，因此通常更受青睐。

K8s 的静态本质请注意，到目前为止，你所看到的一切基本上是静态的。你有 YAML 文件，即使使用上面的 Deployment 对象，如果你有一个新版本的容器，你需要编辑 .yaml 文件，保存并应用它 - 这涉及相当多的手动工作。
如果你希望事情变得更加动态，你将需要使用额外的工具，比如https://helm.sh/ ，我们将在下面讨论。
滚动更新：过于美好而不真实虽然我们正在谈论部署容器的新版本...
一如既往，魔鬼在细节中。滚动更新在 Kubernetes 存在之前很久就已经完成了，即使只是批处理脚本触发 SSH 命令。
坦率地说，问题并不是能够关闭并启动应用程序的新实例，而是在短时间内（在部署期间）你的应用程序基本上需要优雅地支持两个应用程序版本 - 这总是一个有趣的问题，特别是涉及数据库或前后端 API 之间进行了重大重构的情况。
因此，请注意营销材料，它们向你推销简单的滚动更新 - 它们真正的挑战与 Kubernetes 无关。
附注：自愈能力在类似的背景下，同样适用于“self-healing”（自愈）一词。Kubernetes 能够执行健康检查，然后终止无响应的 pod，安排启动一个新的。这也是某种形式上一直存在的功能。你喜欢的 linux 发行版本质上一直能够通过各种方式监视并重新启动服务 - 尽管限于当前机器。
Kubernetes 不能自动处理错误的数据库迁移导致的应用程序错误，然后通过神奇的方式自愈集群，即修复损坏的数据库列。
我只是觉得关于自愈系统的讨论通常在某种程度上含有后者的意味（也许在管理层之间），而实际上它是更基本的功能。
服务发现、负载均衡和 Ingress到目前为止，我们讨论了动态生成 pod，但从未讨论过网络流量如何实际到达你的应用程序。Kubernetes 本质上是动态的，这意味着你可以在任何时候生成新的 pod 或关闭它们。
Kubernetes 有一些概念可以帮助你解决这个问题，从 Service 对象（允许将集群的部分暴露给外部）到 Ingress 对象（允许进行 HTTP 负载均衡）。同样，这将涉及大量的 YAML 和相当多的阅读，但在一天结束时，Kubernetes 允许你将应用程序接收到的任何流量路由到你的集群，反之亦然。
（有趣的 Ingress 事实：您将需要安装 Ingress 控制器（Kubernetes 没有内置标准控制器），它将为您执行负载平衡。选择很多：在像 AWS 这样的平台上，您可以简单地使用 ELB，如果使用裸金属 Kubernetes，则可以使用Contour，等等。）
最后但同样重要的是：ConfigMap 和 Secret 管理除了您已经看到 Kubernetes 执行的各种任务之外，您还可以使用它存储配置键值对，以及秘密（考虑数据库或 API 凭据）。
（默认情况下，Secrets 以未加密的形式存储，因此有必要遵循此页面上“安全使用 Secrets” 部分的建议，甚至可以完全插入外部 Secrets 存储，从 AWS、GCP 和 Azure 的解决方案到HashiCorp 的 Vault 。）
够了！这些 YAML 文件难道不会变得混乱吗？嗯...如果您考虑使用 Kubernetes 部署WordPress等应用，那么您将需要一个 Deployment，以及一个ConfigMap和可能还有Secret 。然后还有一些其他服务和我们尚未涉及的对象。这意味着，您最终将得到成千上万行的 YAML 。这并不是本质上的混乱，但在这个小阶段，已经涉及了大量的 DevOps 复杂性。