概念 - 部署应用程序

已完成

在将应用程序部署到 Kubernetes 之前,让我们查看 Kubernetes 部署,并在我们的方案中讨论其限制。

什么是 Kubernetes 部署?

一张显示 Kubernetes 部署(带有一个标签和三个 Pod)的示意图。

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 来处理事件。