同时部署副本

Simultaneous deploying of replicas

使用默认设置,由 n 个服务副本组成的部署在部署期间将遵循以下顺序:

启动 pod 1 -> 等待 pod 1 就绪
pod 1 就绪后,启动 pod 2 -> 等待 pod 2 就绪
...
pod n-1 就绪后,启动 pod n -> 等待 pod n 就绪

在我的应用程序中,服务需要几分钟才能接受流量(准备就绪)。因此,我想配置我的部署以遵循:
启动 pod 1 -> 启动 pod 2 ... -> 启动 pod n
一旦所有 pods 启动,等待 pods 1n 准备就绪。

    ---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-webservice
spec:
  replicas: n
  selector:
    matchLabels:
      app.kubernetes.io/name: my-webservice
  template:
    metadata:
      labels:
        app: my-webservice
        app.kubernetes.io/name: my-webservice
    spec:
      securityContext:
        runAsNonRoot: true
      containers:
      - name: my-webservice
        image: "my.docker.repo/my-webservice:latest"
        ports:
        - containerPort: 5000
        readinessProbe:
          httpGet:
            path: /ready
            port: 5000
          initialDelaySeconds: 10
          periodSeconds: 10
          timeoutSeconds: 5
          failureThreshold: 360

我该如何配置?

一种方法是放弃 readinessProbe 并仅使用 livenessProbe 和更适合您的 use-case.

的 initialDelaySeconds

如果使用 readinessProbe,根据设计,仅当第一个副本被识别为就绪时,部署才会移动到下一个副本。

因此,通过使用 livenessProbe,所有这些都将立即开始,但您可以利用 initialDelaySeconds 来确定何时开始检查 pod 是否处于活动状态。

您可以尝试在 deployment.yml 中添加 .spec.strategy.rollingUpdate.maxSurge 字段(检查 here

我想你需要的是设置 maxSurge: n

在你的例子中:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-webservice
spec:
  replicas: n
  strategy:
    rollingUpdate:
      maxSurge: n
  selector:
    matchLabels:
      app.kubernetes.io/name: my-webservice
  template:
    metadata:
      labels:
        app: my-webservice
        app.kubernetes.io/name: my-webservice
    spec:
      securityContext:
        runAsNonRoot: true
      containers:
      - name: my-webservice
        image: "my.docker.repo/my-webservice:latest"
        ports:
        - containerPort: 5000
        readinessProbe:
          httpGet:
            path: /ready
            port: 5000
          initialDelaySeconds: 10
          periodSeconds: 10
          timeoutSeconds: 5
          failureThreshold: 360

因此,当您应用更新时,将同时创建 n 个新 pods。