Deployment：简化应用部署和更新的艺术

Deployment：简化应用部署和更新的艺术

在 Kubernetes 中，Deployment 是一种重要的资源类型，它被用于管理应用程序的部署和更新。Deployment 提供了一种声明式的方式来定义应用程序的期望状态，并且负责确保集群中的实际状态与所定义的状态保持一致。

本文将深入介绍 Kubernetes 的 Deployment 控制器，帮助你理解它的工作原理、使用方法以及与其他控制器的比较。

Deployment 控制器简介

Deployment 控制器是 Kubernetes 的一种资源类型，它用于声明性地定义应用程序的部署策略和副本数量，并确保部署的应用程序始终处于所期望的状态。

工作原理

Deployment 控制器背后的核心思想是通过 Pod 模板和 ReplicaSet 来管理应用程序的多个副本，从而实现高可用性、自动扩展和滚动更新。

  • 在使用 Deployment 部署应用程序时，Deployment 控制器会创建一个或多个 ReplicaSet 来管理 Pod 的副本。每个 ReplicaSet 都根据 Pod 模板创建和维护 Pod 副本，从而实现 Deployment 指定的副本数量和配置。

  • 当需要更新应用程序版本时，Deployment 会创建一个新的 ReplicaSet，根据新的 Pod 模板创建新的 Pod 副本。随着新的 Pod 副本准备就绪，Deployment 会逐步停止旧的 ReplicaSet 副本，从而实现平滑的滚动更新。

与其他控制器的比较

在 Kubernetes 中，还有其他一些控制器可以用于管理应用程序的部署和伸缩，例如 ReplicaSet 和 StatefulSet。下面是 Deployment 控制器与这些控制器的一些比较：

  • Deployment vs. ReplicaSet： Deployment 在 ReplicaSet 的基础上提供了滚动更新的功能。它可以无缝地实现应用程序的版本更新，而不会中断现有的流量。
  • Deployment vs. StatefulSet： StatefulSet 主要用于有状态应用程序，可以维护每个 Pod 的稳定标识。Deployment 更适合无状态应用程序，它更注重副本数量和滚动更新。

使用 Deployment

要使用 Deployment 控制器，你需要创建一个 Deployment 资源。以下是一个示例的 Deployment YAML 文件：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: nginx:latest

在这个示例中，我们定义了一个名为 my-app-deployment 的 Deployment，它包含了 3 个副本。Deployment 的 Pod 模板中包含了一个名为 my-app-container 的容器，使用了 nginx:latest 镜像。

通过将上述 YAML 文件保存为 my-app-deployment.yaml，然后使用以下命令来创建 Deployment：

➜  ~ kubectl apply -f my-app-deployment.yaml

这将在 Kubernetes 集群中创建一个名为 my-app-deployment 的 Deployment，开始维护 3 个 Pod 副本。

➜  ~ kubectl get pod                   
NAME                                 READY   STATUS    RESTARTS   AGE
my-app-deployment-7499f5d75f-fpxqr   1/1     Running   0          7s
my-app-deployment-7499f5d75f-qlg9q   1/1     Running   0          7s
my-app-deployment-7499f5d75f-x4dwk   1/1     Running   0          7s

➜  ~ kubectl get rs                                                              
NAME                           DESIRED   CURRENT   READY   AGE
my-app-deployment-7499f5d75f   3         3         3       7s

➜  ~ kubectl get deployments.apps                          
NAME                READY   UP-TO-DATE   AVAILABLE   AGE
my-app-deployment   3/3     3            3           11s

更新策略

我们知道，在一个产品的迭代中，升级显得格外重要，并且在未使用k8s之前，应用的更新都需要手动更新，这不仅麻烦而且极易出差错。

在Kubernetes中，Deployment 支持两种主要的更新策略：RollingUpdate （默认值）和 Recreate。

选择适合的更新策略取决于应用程序的需求和对可用性的要求。RollingUpdate 策略适用于大多数情况，它允许逐步替换 Pod，保持一定数量的可用 Pod，从而实现应用程序的连续性。而 Recreate 策略则适用于那些可以承受短暂中断的应用程序，因为它会在更新过程中停止所有旧版本的 Pod。

在配置更新策略时，你可以根据应用程序的特性、用户体验要求和可用性需求来选择适当的策略，并通过调整 maxUnavailable 和 maxSurge 参数来控制更新过程的速率和容忍度。

RollingUpdate 更新策略

RollingUpdate 策略是默认的更新策略，它会逐步替换旧版本的 Pod 为新版本的 Pod。通过 maxUnavailable 和 maxSurge 参数，可以进一步控制更新的速率和容忍度。

  • maxUnavailable（最大不可用）：指定在任何给定时间内允许的最大不可用 Pod 数量。这是为了确保在更新过程中仍然保持足够的可用 Pod，以提供服务。该值支持数字、百分比，默认情况下，此值为 25%。
  • maxSurge（最大峰值）：指定在任何给定时间内允许的额外 Pod 副本数，以便更快地部署新版本。该值支持数字、百分比，默认情况下，此值为 25%。

下面是一个使用 RollingUpdate 策略的 Deployment 配置示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app-container
          image: nginx:1.24.0

需要关注的是spec.strategy参数，在这个示例中，maxUnavailable 设置为 1，即在更新过程中允许最多一个不可用 Pod。maxSurge 也设置为 1，允许最多一个额外的 Pod 副本。这意味着在更新期间，最多有一个 Pod 不可用，同时可以多一个 Pod 副本。

接下来更新 deploy 使用 nginx:1.25.0 镜像，来替换原来的 nginx:1.24.0 镜像。

kubectl set image deployment my-app-deployment my-app-container=nginx:1.25.0

监听pod的变化：

➜  ~ kubectl get pod -w
NAME                                 READY   STATUS    			  RESTARTS   AGE
my-app-deployment-64cbd59b5-5r72r    1/1     Running  			  0          63s
my-app-deployment-64cbd59b5-jrd4r    1/1     Running  			  0          63s
my-app-deployment-64cbd59b5-mdzbz    1/1     Running   			  0          63s
my-app-deployment-5bcbb7bd86-c7l6t   0/1     Pending   			  0          0s
my-app-deployment-5bcbb7bd86-c7l6t   0/1     Pending   			  0          0s
my-app-deployment-64cbd59b5-mdzbz    1/1     Terminating   		  0          92s
my-app-deployment-5bcbb7bd86-c7l6t   0/1     ContainerCreating    0          0s
my-app-deployment-5bcbb7bd86-cb4gd   0/1     Pending              0          0s
my-app-deployment-5bcbb7bd86-cb4gd   0/1     Pending              0          0s
my-app-deployment-5bcbb7bd86-cb4gd   0/1     ContainerCreating    0          0s
my-app-deployment-64cbd59b5-mdzbz    0/1     Terminating          0          93s
my-app-deployment-64cbd59b5-mdzbz    0/1     Terminating          0          93s
my-app-deployment-64cbd59b5-mdzbz    0/1     Terminating          0          93s
my-app-deployment-5bcbb7bd86-cb4gd   1/1     Running              0          50s
my-app-deployment-64cbd59b5-jrd4r    1/1     Terminating          0          2m22s
my-app-deployment-5bcbb7bd86-jr4wh   0/1     Pending              0          0s
my-app-deployment-5bcbb7bd86-jr4wh   0/1     Pending              0          0s
my-app-deployment-5bcbb7bd86-jr4wh   0/1     ContainerCreating    0          0s
my-app-deployment-64cbd59b5-jrd4r    0/1     Terminating          0          2m22s
my-app-deployment-64cbd59b5-jrd4r    0/1     Terminating          0          2m22s
my-app-deployment-64cbd59b5-jrd4r    0/1     Terminating          0          2m22s
my-app-deployment-5bcbb7bd86-c7l6t   1/1     Running              0          52s
my-app-deployment-64cbd59b5-5r72r    1/1     Terminating          0          2m24s
my-app-deployment-64cbd59b5-5r72r    0/1     Terminating          0          2m25s
my-app-deployment-64cbd59b5-5r72r    0/1     Terminating          0          2m25s
my-app-deployment-64cbd59b5-5r72r    0/1     Terminating          0          2m25s
my-app-deployment-5bcbb7bd86-jr4wh   1/1     Running              0          51s

随后根据pod的更新情况，我们可以看出：

  1. 首先，在更新开始时，Deployment中存在3个旧版本的Pod（由ReplicaSet “my-app-deployment-64cbd59b5” 管理）和1个新版本的Pod（由ReplicaSet “my-app-deployment-5bcbb7bd86” 管理）。
  2. 逐步更新开始，新版本的Pod逐渐引入。在更新过程中，您会注意到一些Pod处于不同的状态，如 “Pending”（等待创建）、“Running”（运行中）和 “Terminating”（正在终止）。
  3. 控制循环根据 maxSurge 和 maxUnavailable 参数的定义，逐步引入新版本的Pod。在这个例子中，最多允许1个新Pod和1个不可用的Pod。
  4. 旧版本的Pod逐渐终止，直到它们全部被替换为新版本的Pod。这个过程中，确保了在更新过程中至少有一个旧版本的Pod保持可用，以及最多有1个新版本的Pod处于不可用状态。
  5. 更新过程完成时，所有的Pod都是新版本的Pod，旧版本的Pod已经终止。此时，滚动更新成功完成，应用程序已经成功地从旧版本更新到新版本。

Kubernetes 滚动更新配置

Recreate更新

Recreate 策略是另一种更新策略，它会首先删除所有旧版本的 Pod，然后再创建新版本的 Pod。这意味着在更新过程中应用程序会短暂地停止提供服务，因为所有的 Pod 都会被同时删除。

修改deploy的strategy部分：

spec:
  strategy:
    type: Recreate

接下来采取同样的方法更新 deploy 使用 nginx:1.26.0 镜像，来替换原来的 nginx:1.26.0 镜像。

kubectl set image deployment my-app-deployment my-app-container=nginx:1.26.0

监听pod的变化：

➜  ~ kubectl get pod -w                                                          
NAME                                 READY   STATUS              RESTARTS   AGE
my-app-deployment-5bcbb7bd86-c7l6t   1/1     Running             0          37m
my-app-deployment-5bcbb7bd86-cb4gd   1/1     Running             0          37m
my-app-deployment-5bcbb7bd86-jr4wh   1/1     Running             0          36m
my-app-deployment-5bcbb7bd86-c7l6t   1/1     Terminating         0          37m
my-app-deployment-5bcbb7bd86-jr4wh   1/1     Terminating         0          36m
my-app-deployment-5bcbb7bd86-cb4gd   1/1     Terminating         0          37m
my-app-deployment-5bcbb7bd86-cb4gd   0/1     Terminating         0          37m
my-app-deployment-5bcbb7bd86-cb4gd   0/1     Terminating         0          37m
my-app-deployment-5bcbb7bd86-cb4gd   0/1     Terminating         0          37m
my-app-deployment-5bcbb7bd86-jr4wh   0/1     Terminating         0          37m
my-app-deployment-5bcbb7bd86-c7l6t   0/1     Terminating         0          37m
my-app-deployment-5bcbb7bd86-jr4wh   0/1     Terminating         0          37m
my-app-deployment-5bcbb7bd86-c7l6t   0/1     Terminating         0          37m
my-app-deployment-5bcbb7bd86-jr4wh   0/1     Terminating         0          37m
my-app-deployment-5bcbb7bd86-c7l6t   0/1     Terminating         0          37m
my-app-deployment-64cbd59b5-z584k    0/1     Pending             0          0s
my-app-deployment-64cbd59b5-zchj8    0/1     Pending             0          0s
my-app-deployment-64cbd59b5-z584k    0/1     Pending             0          0s
my-app-deployment-64cbd59b5-vvxp8    0/1     Pending             0          0s
my-app-deployment-64cbd59b5-zchj8    0/1     Pending             0          0s
my-app-deployment-64cbd59b5-vvxp8    0/1     Pending             0          0s
my-app-deployment-64cbd59b5-zchj8    0/1     ContainerCreating   0          0s
my-app-deployment-64cbd59b5-vvxp8    0/1     ContainerCreating   0          0s
my-app-deployment-64cbd59b5-z584k    0/1     ContainerCreating   0          0s
my-app-deployment-64cbd59b5-zchj8    1/1     Running             0          1s
my-app-deployment-64cbd59b5-vvxp8    1/1     Running             0          2s
my-app-deployment-64cbd59b5-z584k    1/1     Running             0          2s

随后根据pod的更新情况，我们可以看出：

  1. 旧版本的 Pod（来自 “my-app-deployment-5bcbb7bd86” 的 ReplicaSet）正在被终止。这些 Pod 正在一个接一个地停止，直到它们全部被终止。
  2. 终止过程中的 Pod 状态从 “Running” 变为 “Terminating”。这表示它们正在被逐步关闭。
  3. 一旦所有旧版本的 Pod 都被终止，现在处于 “Terminating” 状态的 Pod 最终会消失。
  4. 在旧版本的 Pod 终止后，新版本的 Pod 开始创建。您可以看到有一些 Pod 状态为 “Pending”，然后逐渐变为 “ContainerCreating”，最终变为 “Running”。
  5. 新版本的 Pod 逐个创建，直到所有新版本的 Pod 都处于 “Running” 状态。

Kubernetes 滚动更新配置

使用

Deployment 控制器的一个重要功能是管理滚动更新。当你需要更新应用程序时，你可以简单地更新 Deployment 的 Pod 模板中的容器镜像版本，然后使用 kubectl apply 命令来应用更新：

➜  ~ kubectl set image deployment/my-app-deployment my-app-container=nginx:1.25.2

这将触发一个滚动更新过程，Deployment 控制器会逐步创建新的 Pod 副本，然后逐渐替代旧的 Pod 副本。你可以使用以下命令来监视滚动更新的进度：

➜  ~ kubectl rollout status deployment/my-app-deployment
Waiting for deployment "my-app-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "my-app-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "my-app-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "my-app-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "my-app-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "my-app-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "my-app-deployment" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "my-app-deployment" rollout to finish: 1 old replicas are pending termination...
deployment "my-app-deployment" successfully rolled out

如果在更新过程中发现问题，你可以回滚到之前的版本：

➜  ~ kubectl rollout undo deployment/my-app-deployment

暂停和恢复更新

Kubernetes Deployment 还支持暂停和恢复滚动更新。当你需要中断更新过程时（例如，发现问题或需要执行紧急修复），可以使用以下命令暂停更新：

➜  ~ kubectl rollout pause deployment/my-app-deployment

暂停后，Deployment 控制器将停止创建新的 Pod，保持当前状态。一旦问题解决，你可以使用以下命令恢复更新：

➜  ~ kubectl rollout resume deployment/my-app-deployment

Horizontal Pod Autoscaler（HPA）与 Deployment

Horizontal Pod Autoscaler (HPA) 🔗 通常用于 Kubernetes 中的 Deployment 和 ReplicaSet 资源。这两个资源类型是在 Kubernetes 集群中进行应用程序的部署和管理的主要方式。HPA 的目标是自动调整 Pod 副本数量，以便根据指定的条件来满足资源利用率或其他性能指标。以下是关于 HPA 在这两种资源中的应用情况：

  1. Deployment： Deployment 是 Kubernetes 中用于部署应用程序的资源类型。它允许定义一个应用程序的副本数量、更新策略以及其他相关属性。HPA 可以与 Deployment 配合使用，根据指定的条件，自动调整 Deployment 中 Pod 的副本数量，以实现水平扩展和收缩。这在应对流量峰值或负载变化时非常有用。
  2. ReplicaSet： ReplicaSet 是 Kubernetes 早期版本中用于管理 Pod 副本数量的资源类型。尽管在实际使用中，更常见的是使用 Deployment 来管理应用程序的部署，但在某些情况下，仍然可以使用 ReplicaSet。HPA 也可以应用于 ReplicaSet，自动调整其 Pod 副本数量以满足资源利用率或性能指标的要求。

那么，趁着了解Deploy的同时，一起了解一下HPA吧。

模式

水平扩展和收缩：在 Kubernetes 中，水平扩展和收缩是应对变化负载的关键策略。这些策略旨在自动调整应用程序的副本数量，以实现高效的资源利用和响应性能。

  1. 水平扩展： 当负载增加时，水平扩展允许系统自动增加应用程序的副本数量，以满足增加的请求和工作负载。这有助于保持响应性能并减少延迟。水平扩展的过程是自动的，它根据指定的规则和配置来调整副本数量。

  2. 水平收缩： 当负载减少时，水平收缩允许系统自动减少应用程序的副本数量，以节省资源并降低成本。水平收缩的过程同样是自动的，它会根据规则和配置来减少不再需要的副本。

在 Kubernetes 中，使用 Deployment 控制器可以轻松地实现水平扩展和收缩：

  1. 副本数量配置： 在创建 Deployment 时，您可以通过指定 replicas 字段来设置初始的副本数量。这表示 Deployment 首次启动时将具有的 Pod 副本数量。
  2. 自动扩展： 您可以使用 Kubernetes 提供的 Horizontal Pod Autoscaler (HPA) 来自动实现水平扩展。HPA 可以根据 CPU 使用率、内存使用率等指标自动调整 Deployment 的副本数量。您可以定义最小和最大副本数量以及目标资源使用率。
  3. 手动调整： 除了自动扩展外，您还可以手动调整 Deployment 的副本数量。通过更新 Deployment 的 YAML 文件或使用 kubectl 命令，您可以立即增加或减少副本数量。然后，Kubernetes 控制器将根据您的更改进行调整。

水平扩展和收缩的好处包括：

  • 弹性： 应用程序可以根据实际负载需求进行弹性调整，以满足用户需求。
  • 性能稳定性： 随着负载的增加，自动扩展可以保持应用程序的性能稳定性。
  • 资源利用率： 自动收缩可以减少资源浪费，节省成本。

metrics-server

由于HPA本身无法获取指标数据，所以HPA往往需要搭配其他的组件来实现自动伸缩的功能。

metrics-server 🔗是最流行的解决方案，Metrics Server 提供的指标数据，比如 CPU 利用率、内存使用量等，被 HPA 用来决定是否需要增加或减少 Pod 的副本数量。

例如，如果 CPU 利用率高于一定阈值，HPA 可能会决定增加 Pod 的副本数量，从而应对负载的增加。相反，如果资源使用率较低，HPA 可能会决定减少副本数量以节省资源。

要安装，您只需运行：（镜像可使用bitnami 🔗替代）

➜  ~ kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

metrics-server收集第一个指标可能需要几秒钟的时间，但您可以通过运行以下命令来验证它是否正常工作：

# 查看节点资源使用情况
➜  ~ kubectl top nodes

# 查看 Pod 资源使用情况
➜  ~ kubectl top pods

HPA原理

img

  1. 指标服务metrics-server通过 kubelet 从所有 pod 收集指标，并通过 Kubernetes Metrics API 提供它们。
  2. HPA 将循环调用Metrics API获取其管理的 Pod 的当前指标，默认情况下每 15 秒发生一次。
  3. HPA 将当前指标与目标指标进行比较，并决定是扩展应用程序（增加 Pod 副本数量）还是收缩应用程序（减少 Pod 副本数量）。
  4. 如果 HPA 决定扩展或者收缩应用程序，它将更新spec.replicas为目标值，然后将触发滚动更新。

关于 HorizontalPodAutoscaler (HPA) 您需要了解的所有信息 🔗

示例

要在 Kubernetes 中看到 Nginx Deployment 的水平扩展效果，您可以按照以下步骤操作：

  1. 创建 Nginx Deployment及Service： 首先，创建一个 Nginx 的 Deployment、Service 配置文件，如下所示：
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: nginx:latest
        resources:
          requests:
            cpu: 10m
---
apiVersion: v1
kind: Service
metadata:
  name: my-app-deployment
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: my-app
  type: ClusterIP

注意：资源描述spec.resources.requests指标是必须的，否则HPA无法无法实现自动伸缩

  1. 为Deploy设置HorizontalPodAutoscaler， my-app-hpa 根据 CPU 使用率自动进行水平扩展和收缩。
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app-deployment
  minReplicas: 1
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50

或者使用命令：

➜  ~ kubectl autoscale deployment my-app-deployment --cpu-percent=50 --min=1 --max=10 --name my-app-hpa

这个yaml/命令创建了一个 HPA，将监控 my-app-deployment 中的Pod，如果它们的CPU利用率达到 50%，则会自动调整Pod的副本数量，保持在 1 到 10 之间，以满足资源利用率的目标。

  1. 监控hpa的变化
➜  ~ kubectl get hpa -w
  1. 模拟负载增加： 为了触发水平扩展，您可以模拟一个负载增加的情况。可以使用以下命令在一个或多个 Pod 中创建一个简单的负载：
➜  ~ kubectl run --rm -it load-generator --image=busybox /bin/sh

在打开的 shell 中，使用以下命令向 Nginx 服务发送请求：

while true; do wget -q -O- http://my-app-deployment.default.svc.cluster.local; done
  1. 查看pod的变化以及hpa的更新
➜  ~ kubectl get hpa -w
NAME         REFERENCE                      TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
my-app-hpa   Deployment/my-app-deployment   0%/50%    1         10        1          24s
my-app-hpa   Deployment/my-app-deployment   50%/50%   1         10        1          30s
my-app-hpa   Deployment/my-app-deployment   110%/50%   1         10        1          45s
my-app-hpa   Deployment/my-app-deployment   100%/50%   1         10        3          60s
my-app-hpa   Deployment/my-app-deployment   50%/50%    1         10        3          75s
my-app-hpa   Deployment/my-app-deployment   45%/50%    1         10        3          90s
my-app-hpa   Deployment/my-app-deployment   43%/50%    1         10        3          105s


➜  ~ kubectl get pod
NAME                                 READY   STATUS    RESTARTS   AGE
my-app-deployment-6df56c8d67-9hwxx   1/1     Running   0          14s
my-app-deployment-6df56c8d67-nbl92   1/1     Running   0          14s
my-app-deployment-6df56c8d67-vvph5   1/1     Running   0          1m27s

  • 第一个时间点：资源利用率为 0%/50%，表示当前的资源利用率为 0%，目标是达到 50% 的利用率。此时只有 1 个Pod在运行。

  • 第二个时间点：资源利用率为 50%/50%，此时资源利用率达到了 50%，正好达到目标 50% 的利用率。仍然只有 1 个Pod在运行。

  • 第三个时间点：资源利用率为 110%/50%，这是由于不断发送请求导致cpu使用率超过了目标利用率，但HPA会根据配置尝试进行扩展。仍然只有 1 个Pod在运行。

  • 第四个时间点：资源利用率为 100%/50%，HPA触发了扩展，将副本数从 1 增加到 3，以满足目标资源利用率。此时有 3 个Pod在运行。

  • 后续的时间点：副本数仍然保持为 3，资源利用率逐渐降低。由于目标利用率仍然满足，没有进一步的扩展或缩容。

  1. 暂停之前的请求命令，资源利用率下降，HPA触发收缩，逐步缩减副本数量，最终变为1（HPA设置的最小值）。
➜  ~ kubectl get hpa -w
NAME         REFERENCE                      TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
my-app-hpa   Deployment/my-app-deployment   0%/50%    1         10        1          24s
my-app-hpa   Deployment/my-app-deployment   50%/50%   1         10        1          30s
my-app-hpa   Deployment/my-app-deployment   110%/50%   1         10        1          45s
my-app-hpa   Deployment/my-app-deployment   100%/50%   1         10        3          60s
my-app-hpa   Deployment/my-app-deployment   50%/50%    1         10        3          75s
my-app-hpa   Deployment/my-app-deployment   45%/50%    1         10        3          90s
my-app-hpa   Deployment/my-app-deployment   43%/50%    1         10        3          105s
my-app-hpa   Deployment/my-app-deployment   33%/50%    1         10        3          2m15s
my-app-hpa   Deployment/my-app-deployment   0%/50%     1         10        3          2m30s
my-app-hpa   Deployment/my-app-deployment   0%/50%     1         10        3          7m
my-app-hpa   Deployment/my-app-deployment   0%/50%     1         10        2          7m15s
my-app-hpa   Deployment/my-app-deployment   0%/50%     1         10        1          7m30s

结论

Deployment 控制器是 Kubernetes 中用于管理应用程序部署和更新的重要资源类型。通过声明性的方式定义应用程序的期望状态，Deployment 控制器确保集群中的实际状态与所定义的状态保持一致。它提供了滚动更新、自动扩展等功能，使得应用程序的管理更加简化和可靠。

通过本文的介绍，你已经了解了 Deployment 控制器的工作原理、使用方法以及与其他控制器的比较。在实际的 Kubernetes 集群中，你可以灵活地使用 Deployment 控制器来管理你的应用程序，实现高可用性和灵活的更新策略。

希望本文能够帮助你更好地理解和使用 Kubernetes 中的 Deployment 控制器！

kubernetes文档-Deployments 🔗

lomtom

标题：Deployment：简化应用部署和更新的艺术

作者：lomtom

链接：https://lomtom.cn/cemqf17imgtij

Deployment 控制器简介
工作原理
与其他控制器的比较
使用 Deployment
更新策略
RollingUpdate 更新策略
Recreate更新
使用
暂停和恢复更新
Horizontal Pod Autoscaler（HPA）与 Deployment
模式
metrics-server
HPA原理
示例
结论

Similar Posts

CKA（一）注意

CKA（一）注意

CKA（二）题库一

CKA（二）题库一