188

configmap が変更/更新されたときに、デプロイに関連付けられている Kubernetes ポッドおよびポッドを自動的に再起動するにはどうすればよいですか?

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

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

4

11 に答える 11

163

この問題に対する現在の最善の解決策 (兄弟の回答にリンクされているhttps://github.com/kubernetes/kubernetes/issues/22368で深く参照されている) は、展開を使用し、ConfigMap を不変と見なすことです。

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

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

于 2016-11-16T04:20:14.933 に答える
86

構成マップの更新時にポッドにシグナルを送ることは、機能中の機能です ( https://github.com/kubernetes/kubernetes/issues/22368 )。

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

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

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

于 2016-05-19T18:27:55.483 に答える
15

展開に関係のないメタデータ アノテーションを更新できます。ローリング更新をトリガーします

例えば：

    spec:
      template:
        metadata:
          annotations:
            configmap-version: 1
于 2018-07-19T11:28:45.557 に答える
-2

もう 1 つの方法は、Deployment のコマンド セクションに貼り付けることです。

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

または、より ConfigMap に似たものにするために、追加の Deployment を使用します。これは、セクションでその構成をホストし、その名前に一意の「バージョン」を追加しながらcommand実行し (コンテンツのハッシュを計算するなど)、すべてを変更します。kubectl createその構成を使用する展開:

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

kubectl-apply-config.shそれが機能するようになったら、おそらく投稿します。

（そうしないでください。見栄えが悪いです）

于 2017-10-12T08:08:19.560 に答える