Kubernetesでconfigmapが更新されたときにポッドを再起動しますか？

構成マップが変更/更新されたときに、Kubernetesポッドとデプロイメントに関連付けられたポッドを自動的に再起動するにはどうすればよいですか？

構成マップが変更されたときにポッドを自動的に再起動する機能について話がありましたが、私の知る限り、これはKubernetes 1.2ではまだ利用できません。

つまり、私がやりたいことは、構成マップを使用するポッドに関連付けられたデプロイメントリソースの「ローリングリスタート」です。実際のテンプレートで何も変更せずに、Kubernetesでデプロイメントのローリング再起動を強制することは可能ですか？これは現在それを行うための最良の方法ですか、それともより良いオプションがありますか？

構成マップの更新時にポッドに信号を送ることは、機能（https://github.com/kubernetes/kubernetes/issues/22368）の機能です。

いつでも、confimapが変更されたことを通知してアプリを再起動するカスタムpid1を作成できます。

たとえば、同じ構成マップを2つのコンテナーにマウントし、構成マップの内容のハッシュが変更された場合に失敗する2番目のコンテナーでhttpヘルスチェックを公開し、それを最初のコンテナーの活性プローブとして押し出します（ポッドは同じネットワーク名前空間を共有します）。プローブが失敗すると、kubeletは最初のコンテナを再起動します。

もちろん、ポッドがどのノードにあるかを気にしない場合は、それらを削除するだけで、レプリケーションコントローラーがポッドを「再起動」します。

この問題に対する現在の最善の解決策（兄弟の回答でリンクされているhttps://github.com/kubernetes/kubernetes/issues/22368で詳細に参照されています）は、Deploymentsを使用して、ConfigMapが不変であると見なすことです。

構成を変更する場合は、必要な変更を加えた新しいConfigMapを作成し、デプロイメントを新しいConfigMapに向けます。新しい構成が壊れている場合、Deploymentは作業中のReplicaSetのスケールダウンを拒否します。新しい構成が機能する場合、古いレプリカセットは0レプリカにスケーリングされて削除され、新しいポッドが新しい構成で開始されます。

ConfigMapを適切に編集するほど速くはありませんが、はるかに安全です。

私がそれをするために見つけた最良の方法は、リローダーを実行することです

監視する構成マップまたはシークレットを定義して、それらが更新されると、デプロイメントのローリング更新が実行されます。次に例を示します。

デプロイfooとと呼ばれるConfigMapがありfoo-configmapます。configmapが変更されるたびにデプロイメントのポッドをロールしたいとします。あなたはリローダーを実行する必要があります：

kubectl apply -f https://raw.githubusercontent.com/stakater/Reloader/master/deployments/kubernetes/reloader.yaml

次に、デプロイメントでこの注釈を指定します。

kind: Deployment
metadata:
  annotations:
    configmap.reloader.stakater.com/reload: "foo-configmap"
  name: foo
...

https://github.com/kubernetes/helm/blob/master/docs/charts_tips_and_tricks.md#user-content-automatically-roll-deployments-when-configmaps-or-secrets-change

多くの場合、configmapsまたはシークレットはコンテナー内の構成ファイルとして挿入されます。アプリケーションによっては、後続ので更新する必要がある場合に再起動が必要になることがありますhelm upgradeが、デプロイメント仕様自体が変更されなかった場合、アプリケーションは古い構成で実行され続け、デプロイメントに一貫性がなくなります。

このsha256sum関数を関数と一緒に使用すると、include別の仕様が変更された場合にデプロイメントテンプレートセクションが確実に更新されます。

kind: Deployment
spec:
  template:
    metadata:
      annotations:
        checksum/config: {{ include (print $.Template.BasePath "/secret.yaml") . | sha256sum }}
[...]

私の場合、いくつかの理由で機能$.Template.BasePathしませんでしたが、$.Chart.Name機能します：

spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: admin-app
      annotations:
        checksum/config: {{ include (print $.Chart.Name "/templates/" $.Chart.Name "-configmap.yaml") . | sha256sum }}

デプロイメントに関連しないメタデータラベルを更新できます。ローリング更新をトリガーします

例えば：

metadata:
  labels:
    configmap-version: 1

Deploymentがサブチャートにあり、それを制御する値が親チャートの値ファイルにあるというこの問題がありました。これは、再起動をトリガーするために使用したものです。

spec:
  template:
    metadata:
      annotations:
        checksum/config: {{ tpl (toYaml .Values) . | sha256sum }}

これは明らかに、再起動をトリガする任意の値の変化が、それは我々の状況のために働きます。元々子チャートにあったものは、子チャート自体のconfig.yamlが変更された場合にのみ機能します。

    checksum/config: {{ include (print $.Template.BasePath "/config.yaml") . | sha256sum }}

私は量子の解決を行い、それは完全に機能します。しかし、ポッドが実際に再起動していないということを理解していません...ポッドはまだ同じですが、変更があります！

例：ポッドは50分から実行されており、何かを変更してオンラインで変更すると、ブラウザで確認できますが、ポッドはまだ+50分実行されています。Helm3を使用しています... configmapの更新を再開せずにこれが可能になる理由を知っていますか？

別の方法は、それをデプロイメントのコマンドセクションに挿入することです。

...
command: [ "echo", "
  option = value\n
  other_option = value\n
" ]
...

または、それをConfigMapのようにするには、commandセクションでその構成をホストkubectl createし、その名前に一意の「バージョン」を追加し（コンテンツのハッシュの計算など）、すべての変更を加えながら実行する追加のDeploymentを使用します。その構成を使用するデプロイメント：

...
command: [ "/usr/sbin/kubectl-apply-config.sh", "
  option = value\n
  other_option = value\n
" ]
...

kubectl-apply-config.shうまくいったら投稿します。

（それをしないでください、それはあまりにも悪く見えます）