Kubernetesにイメージを強制的に再プルさせるにはどうすればよいですか？

GKEのKubernetesに次のレプリケーションコントローラがあります。

apiVersion: v1
kind: ReplicationController
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 2
  selector:
    app: myapp
    deployment: initial
  template:
    metadata:
      labels:
        app: myapp
        deployment: initial
    spec:
      containers:
      - name: myapp
        image: myregistry.com/myapp:5c3dda6b
        ports:
        - containerPort: 80
      imagePullPolicy: Always
      imagePullSecrets:
        - name: myregistry.com-registry-key

今、私が言うなら

kubectl rolling-update myapp --image=us.gcr.io/project-107012/myapp:5c3dda6b

ローリング更新は実行されますが、再プルは行われません。どうして？

Kubernetesは、次の場合にポッドの作成をプルします（updated-images docを参照）：

• タグ付けされた画像の使用 :latest
• imagePullPolicy: Always 指定されている

これは、常にプルしたい場合に最適です。しかし、オンデマンドで実行したい場合はどうなりますか。たとえば、使用しsome-public-image:latestたいが、要求されたときに手動で新しいバージョンのみをプルしたい場合。現在できること：

• またはに設定imagePullPolicyして事前にプル：各クラスターノードのイメージを手動でプルして最新のキャッシュを作成し、次にa または類似の操作を行ってポッドを再起動します（醜い簡単に壊れたハック！）IfNotPresentNeverkubectl rolling-update
• 一時的に変更imagePullPolicy、実行kubectl apply、ポッドの再起動（例kubectl rolling-update：）imagePullPolicy、元に戻す、やり直しkubectl apply（醜い！）
• some-public-image:latestプライベートリポジトリにプルしてプッシュし、kubectl rolling-update（重い！）

オンデマンドプルに適したソリューションはありません。変更された場合はコメントしてください。この回答を更新します。

imagePullPolicyスペックデータ内ではなく、コンテナデータ内でグループ化する必要があります。しかし、私はそれが奇妙だと思うので、これについて問題を提出しました。また、エラーメッセージはありません。

したがって、このスペックスニペットは機能します。

spec:
  containers:
  - name: myapp
    image: myregistry.com/myapp:5c3dda6b
    ports:
    - containerPort: 80
    imagePullPolicy: Always
  imagePullSecrets:
    - name: myregistry.com-registry-key

開発中のハックは、Deploymentマニフェストを変更して最新のタグを追加し、常にそのようにプルすることです

image: etoews/my-image:latest
imagePullPolicy: Always

次に、ポッドを手動で削除します

kubectl delete pod my-app-3498980157-2zxhd

これはデプロイであるため、Kubernetesはポッドを自動的に再作成し、最新のイメージをpullします。

一般的な回避策は、ダミーのアノテーション（またはラベル）を使用してデプロイメントにパッチを適用することです。

kubectl patch deployment <name> -p \
  "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"date\":\"`date +'%s'`\"}}}}}"

デプロイメントがこれらの要件を満たしていると仮定すると、K8は新しいイメージをプルして再デプロイします。

それを直接行うための新しいコマンドがあります：

kubectl rollout restartデプロイメントのローリング再起動を実行する新しいコマンドを作成します。

プルリクエスト GOTが合併しました。バージョンの一部になります1.15（changelog）

どうやら--image、既存のコンテナイメージと同じ引数を使用してローリングアップデートを実行するときは、も指定する必要があります--image-pull-policy。次のコマンドは、コンテナイメージと同じ場合、イメージを強制的にプルします。

kubectl rolling-update myapp --image=us.gcr.io/project-107012/myapp:5c3dda6b --image-pull-policy Always

# Linux

kubectl patch deployment <name> -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"date\":\"`date +'%s'`\"}}}}}"

# windows

kubectl patch deployment <name> -p (-join("{\""spec\"":{\""template\"":{\""metadata\"":{\""annotations\"":{\""date\"":\""" , $(Get-Date -Format o).replace(':','-').replace('+','_') , "\""}}}}}"))

コマンドkubectl rollout restart deploy YOUR-DEPLOYMENTとimagePullPolicy: Alwaysポリシーを組み合わせると、すべてのポッドを最新バージョンのイメージで再起動できます。

ローリング更新コマンドは、イメージ引数が指定されている場合、イメージが現在レプリケーションコントローラに存在するものとは異なると想定します。

imagePullPolicy: Alwaysデプロイメントファイルで定義できます。

イメージプルポリシーは、新しいポッドが作成されるたびに実際にイメージをプルするのに常に役立ちます（これは、レプリカのスケーリングやポッドダイの作成や新しいポッドの作成など、どのような場合でも可能です）。

ただし、現在実行中のポッドのイメージを更新する場合は、デプロイが最良の方法です。それはあなたに問題なく完璧な更新を残します（主にポッドに永続的なボリュームが接続されている場合）:)