概念 - 部署应用程序

  • 5 分钟

在将应用程序部署到 Kubernetes 之前，让我们回顾一下 Kubernetes 部署，并讨论一下其在我们的方案中的局限性。

什么是 Kubernetes 部署？

A diagram that shows a Kubernetes Deployment with a label and three pods.

Kubernetes 部署由 Pod 演变而来。 部署将 Pod 包装到一个智能对象中，使它们可以横向扩展。无需配置复杂的网络规则，即可轻松地复制和缩放应用程序以支持更多负载。

部署让你只需更改映像标记即可更新应用程序，而无需任何停机时间。 更新部署会逐个关闭联机应用，并将其替换为最新版本，而不是删除所有应用并创建新应用，这意味着部署可以更新其中的 Pod，而不会对可用性产生明显影响。

虽然在 Pod 上使用部署有很多好处，但部署无法充分胜任我们的方案。

此方案涉及事件驱动的应用程序，该应用程序会在各种时间接收大量事件。 如果没有 KEDA Scaler 对象或 HPA，则需要手动调整副本数以处理相应数量的事件，并在负载恢复正常时纵向缩减部署。

示例部署清单

下面是我们的部署清单的示例片段：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: contoso-microservice
spec:
  replicas: 10                      # Tells K8S the number of pods needed to process the Redis list items
  selector:                         # Define the wrapping strategy
    matchLabels:                    # Match all pods with the defined labels
      app: contoso-microservice     # Labels follow the `name: value` template
  template:                         # Template of the pod inside the deployment
    metadata:
      labels:
        app: contoso-microservice
    spec:
      containers:
        - image: mcr.microsoft.com/mslearn/samples/redis-client:latest
          name: contoso-microservice

在该示例清单中，我们将 replicas 设置为 10，这是我们可以为处理峰值数量的事件所需的副本设置的最高数量。 但是，这会导致应用程序在非峰值时间消耗过多的资源，从而可能会使群集中的其他部署处于缺乏资源的状态。

一种解决方案是使用独立的 HPA 来监视 Pod 的 CPU 使用情况，这比手动缩放要好。 但是，HPA 并不关注 Redis 列表中接收到的事件数。

最佳解决方案是使用 KEDA 和 Redis 缩放程序来查询列表，并确定是否需要更多或更少的 Pod 来处理事件。