☰

Kubernetes - ローリングアップデートで古いポッドが削除され、新しいポッドが起動されない 質問する

tag-icon • tag-icon kubernetes kubernetes-health-check
Kubernetes - ローリングアップデートで古いポッドが削除され、新しいポッドが起動されない 質問する

現在、Deployments を使用して K8S クラスター内のポッドを管理しています。

私のデプロイメントには、2 つのポッド/レプリカが必要なもの、3 つのポッド/レプリカが必要なもの、1 つのポッド/レプリカのみが必要なものがあります。私が抱えている問題は、ポッド/レプリカが 1 つの場合です。

私のYAMLファイルは次のとおりです:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: user-management-backend-deployment
spec:
  replicas: 1
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 2
  selector:
    matchLabels:
      name: user-management-backend
  template:
    metadata:
      labels:
        name: user-management-backend
    spec:
      containers:
      - name: user-management-backend
        image: proj_csdp/user-management_backend:3.1.8
        imagePullPolicy: IfNotPresent
        ports:
          - containerPort: 8080
        livenessProbe:
          httpGet:
            port: 8080
            path: /user_management/health
          initialDelaySeconds: 300
          timeoutSeconds: 30
        readinessProbe:
          httpGet:
            port: 8080
            path: /user_management/health
          initialDelaySeconds: 10
          timeoutSeconds: 5
        volumeMounts:
          - name: nfs
            mountPath: "/vault"
      volumes:
        - name: nfs
          nfs:
            server: kube-nfs
            path: "/kubenfs/vault"
            readOnly: true

古いバージョンは問題なく動作しています。

# kubectl get po | grep  user-management-backend-deployment
user-management-backend-deployment-3264073543-mrrvl               1/1       Running        0          4d

ここで画像を更新したいと思います:

# kubectl set image deployment  user-management-backend-deployment  user-management-backend=proj_csdp/user-management_backend:3.2.0

現在、RollingUpdate の設計に従って、K8S は古いポッドを稼働させながら新しいポッドを起動し、新しいポッドがトラフィックを受け入れる準備ができたら、古いポッドを削除する必要があります。しかし、古いポッドはすぐに削除され、新しいポッドが作成され、その後トラフィックを受け取り始めるまでに時間がかかるため、トラフィックをドロップする必要があります。

# kubectl get po | grep  user-management-backend-deployment
user-management-backend-deployment-3264073543-l93m9               0/1       ContainerCreating   0          1s

# kubectl get po | grep  user-management-backend-deployment
user-management-backend-deployment-3264073543-l93m9               1/1       Running            0          33s

maxSurge: 2&を使用しましたmaxUnavailable: 1が、機能していないようです。

なぜこれが機能しないのか、何か考えはありますか?

ベストアンサー1

それは のようですmaxUnavailable: 1。その値を設定することであなたの経験を簡単に再現することができ、それを に設定することで正しい経験を簡単に達成することができました。maxUnavailable: 0

スケジューラがどのようにしてあなたが経験している動作に到達したかについての私の「疑似証明」は次のとおりです。

なのでreplicas: 1、k8s の望ましい状態は にちょうど 1 つのポッドがあることですReady。あなたが要求した戦略であるローリング更新操作中に、新しいポッドが作成され、合計は 2 になります。しかし、k8s に 1 つのポッドを残す許可を与えました。ポッド1個利用できない状態になり、望ましいポッドの数は 1 です。したがって、RU 戦略によって許可された、1 つのポッド、目的の数、使用不可の状態、というすべての制約が満たされました。

をゼロに設定することで、たとえ短期間でmaxUnavailableポッド数が上限を超えて急増することになったとしても、ポッドが利用できなくなることがないようにk8sに正しく指示します。replica

おすすめ記事