Kubernetes 構成ホットアップデートリローダー

背景

構成センターの問題:

configmap や secret オブジェクトなどのクラウド ネイティブの構成センターでは、リソース オブジェクトを直接更新できます。

• これらの多少変化しない構成への参照はイメージにパッケージ化できますが、可変構成の場合はどうでしょうか?
• 情報漏洩は、特にパスワードやキーなどの機密情報の場合、簡単にセキュリティ リスクにつながる可能性があります。
• 構成が更新されるたびに、アプリケーションを再パッケージ化してアップグレードする必要があります。イメージのバージョンが多すぎると、イメージ管理やイメージセンターのストレージに大きな負担がかかります。
• カスタマイズが多すぎて、拡張性が低く、再利用が容易ではありません。

方向：

Configmap または Secret を使用するには、env システム変数に値を割り当てる方法と、ボリュームマウントに値を割り当てる方法の 2 つの方法があります。 env によってシステムに書き込まれた configmap はホット アップデートされませんが、ボリューム書き込み方式ではホット アップデートがサポートされます。

• env 環境の場合、有効にするにはポッドをロールアウトする必要があります。つまり、古いポッドを削除し、イメージを再度使用して新しいポッドをプルアップし、環境変数をロードして有効にする必要があります。
• ボリューム方式の場合、コンテンツが変更されても、アプリケーションは configmap の変更を直接監視するか、環境変数を更新し続け、この場合のホット アップデートの目的を達成する必要があります。
• アプリケーションがホット アップデートをサポートしていない場合は、ビジネス コンテナーでサイドカー コンテナーを起動して、configmap の変更を監視したり、構成ファイルを更新したり、ポッド アップデートをロールアウトして構成を更新したりできます。

解決

ConfigMap と Secret は、Kubernetes が構成データを保存するためによく使用するオブジェクトです。ニーズに応じて適切なオブジェクトを選択してデータを保存できます。 Volume 経由で Pod にマウントされ、kubelet によって定期的に更新されます。ただし、環境変数を通じてコン​​テナに注入されるため、ConfigMap や Secret の内容の更新は認識できません。

現在、Pod 内のビジネスに ConfigMap または Secret の変更を認識させる方法は、まだ解決されていない問題です。しかし、まだいくつかの回避策があります。

ビジネス自体が nginx -s reload などのリロード構成をサポートしている場合は、inotify を通じてファイルの更新を検出したり、定期的にリロードを実行したりできます (これは、readinessProbe と組み合わせて使用​​できます)。

私たちのビジネスにこの機能がない場合、不変のインフラストラクチャの考え方を考慮して、ローリング アップグレード アプローチを採用できますか?はい、これは非常に良い方法です。現在、このアプローチを使用する Reloader と呼ばれるオープンソース ツールがあります。 ConfigMap と Secret を監視することで、オブジェクトの更新が見つかると、Deployment や StatefulSet などのワークロード オブジェクトのローリング アップグレードが自動的にトリガーされます。

リローダーの紹介

リローダーの紹介:

Reloader は、ConfigMap と Secret の変更を監視し、関連する deployconfiggs、deploymentconfiggs、deploymonset、statefulset を通じて Pod のローリング アップグレードを実行できます。

リローダーのインストール:

helmのインストール:

 helm repo add stakater https://stakater.github.io/stakater-charts helm repo update helm install stakater/reloader

カスタマイズ:

 kubectl apply -k https://github.com/stakater/Reloader/deployments/kubernetes

リソース リストのインストール:

 kubectl apply -f https://raw.githubusercontent.com/stakater/Reloader/master/deployments/kubernetes/reloader.yaml # 在此安装在common-service 名称空间下， [root@master reloader]# kubectl apply -f reloader.yaml clusterrole.rbac.authorization.k8s.io/reloader-reloader-role created clusterrolebinding.rbac.authorization.k8s.io/reloader-reloader-role-binding created deployment.apps/reloader-reloader created serviceaccount/reloader-reloader created [root@master reloader]# kubectl get all -n common-service NAME READY STATUS RESTARTS AGE pod/reloader-reloader-66d46d5885-nx64t 1/1 Running 0 15s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/reloader-reloader 1/1 1 1 16s NAME DESIRED CURRENT READY AGE replicaset.apps/reloader-reloader-66d46d5885 1 1 1 16s

構成を無視:

リーダー デプロイで spec.template.spec.containers.args を構成することにより、リローダーが cm または secrets リソースを無視するように構成できます。両方とも無視される場合は、デプロイを 0 に減らすか、リローダーをデプロイしないでください。

構成：

自動更新:

reloader.stakater.com/search と reloader.stakater.com/auto は連携して動作しません。デプロイメントに reloader.stakater.com/auto : " true " アノテーションがある場合、そのリソースによって参照されるすべての configmap またはシークレットを変更すると、 reloader.stakater.com/match : " true " アノテーションがあるかどうかに関係なく、そのリソースが再起動されます。

 kind: Deployment metadata: annotations: reloader.stakater.com/auto: "true" spec: template: metadata:

開発アップデート:

特定の configmap または secret を指定すると、指定した configmap または secret が変更された場合にのみローリング アップグレードがトリガーされるため、デプロイメント、バックエンド ログイン、または状態設定で使用されるすべての configmap または secret のローリング アップグレードはトリガーされません。

構成マップまたはシークレットを指定するデプロイメント リソース オブジェクトは、reloader.stakater.com/match: "true" が true の場合にのみ更新されます。 false またはマークされていない場合、リソース オブジェクトは構成の変更を監視せず、再起動します。

 kind: Deployment metadata: annotations: reloader.stakater.com/search: "true" spec: template:

cm構成:

 kind: ConfigMap metadata: annotations: reloader.stakater.com/match: "true" data: key: value

cm を指定:

デプロイメントが複数の CMS とともにマウントされている場合、または特定の CMS のみを更新するシナリオでは、デプロイメントはロールオーバーされ、デプロイメントを更新せずに他の CMS が更新されます。このシナリオでは、cm はデプロイメント内の単一の cm またはリストとして指定できます。

たとえば、デプロイには nginx-cm1 と nginx-cm2 の 2 つの configmap がマウントされています。 nginx-cm1 が更新されたときにのみデプロイでローリング アップデートを実行する場合は、2 つの cms でアノテーションを構成する必要はありません。デプロイでは configmap.reloader.stakater.com/reload:nginx-cm1 と記述するだけです。 nginx-cm1 が更新されると、デプロイによってローリング アップデートがトリガーされます。

複数の cm を区切る場合は、カンマを使用します。

 # configmap对象kind: Deployment metadata: annotations: configmap.reloader.stakater.com/reload: "nginx-cm1" spec: template: metadata:

 # secret对象kind: Deployment metadata: annotations: secret.reloader.stakater.com/reload: "foo-secret" spec: template: metadata:

cm または secret に注釈を追加する必要はなく、参照リソース オブジェクトに注釈を追加するだけです。

テスト検証

展開する：

 apiVersion: apps/v1 kind: Deployment metadata: annotations: # reloader.stakater.com/auto: "true" reloader.stakater.com/search: "true" labels: run: nginx name: nginx namespace: default spec: replicas: 1 selector: matchLabels: run: nginx template: metadata: labels: run: nginx spec: containers: - image: nginx name: nginx volumeMounts: # 必须匹配volumes的名称,定义configmap - name: nginx-cm mountPath: /data/cfg readOnly: true volumes: # 定义逻辑卷的名称- name: nginx-cm configMap: # 使用configmap资源的名称name: nginx-cm items: # 使用configmap中到那个key - key: config.yaml # 使用configmap中到key映射到容器中到文件名称path: config.yaml mode: 0644

設定マップ:

 apiVersion: v1 data: config.yaml: | # project settings # go2cloud_api service config DEFAULT_CONF: port: 8888 # data disk api UNITTEST_TENCENT_ZONE: ap-chongqing-1 kind: ConfigMap metadata: name: nginx-cm annotations: reloader.stakater.com/match: "true"

テスト：

 [root@master ns-default]# kubectl get po NAME READY STATUS RESTARTS AGE nginx-68c9bf4ff7-9gmg6 1/1 Running 0 10m [root@master ns-default]# kubectl get cm NAME DATA AGE nginx-cm 1 28m # 更新cm内容[root@master ns-default]# kubectl edit cm nginx-cm configmap/nginx-cm edited # 查看po发生了滚动更新，重新加载配置文件[root@master ns-default]# kubectl get po NAME READY STATUS RESTARTS AGE nginx-66c758b548-9dllm 0/1 ContainerCreating 0 4s nginx-68c9bf4ff7-9gmg6 1/1 Running 0 10m

予防

• Reloader はグローバル リソース オブジェクトです。他の NS でもリローダー機能を正常に使用できるように、パブリック サービス NS の下に展開することをお勧めします。
• Reloader.stakater.com/auto : 構成 configmap または secret が、deploymentconfigmap/deployment/daemonsets/Statefulsets にある場合
• アノテーションで secret.reloader.stakater.com/reload または configmap.reloader.stakater.com/reload が使用されている場合、configmap または secret が使用されているかどうかに関係なく、true はポッドのみをリロードします。
• reloader.stakater.com/search と reloader.stakater.com/auto は同時に使用できません。デプロイメントに reloader.stakater.com/auto : "true" アノテーションがある場合は、 reloader.stakater.com/match : "true" アノテーションの有無に関係なく、configmaps を変更したりシークレットを使用したりすると、デプロイメントは常に再起動されます。

反射

Reloader は ConfigMap と Secret を監視し、オブジェクトが更新されたことを検出すると、Deployment や StatefulSet などのワークロード オブジェクトのローリング アップグレードを自動的にトリガーします。

アプリケーションが構成ファイルをリアルタイムで監視しない場合は、この方法を使用して構成のホット アップデートを簡単に実装できます。