Helm の運用と Argo CD の移行

静的な Kubernetes マニフェストを Helm に移し、さらに Argo CD に移すことは、テンプレートだけでなく所有権も変更します。稼働中のリソースを棚卸しし、不変の名前とストレージを保持し、自動プルーニングを有効にする前に望ましい状態を再現可能にします。

Helm のリリースモデルを理解する #

直接の Helm リリースでは、アップグレードによって以前のリリースマニフェスト、新しくレンダリングされたマニフェスト、稼働中のオブジェクトが比較されます。両方のマニフェストに存在するリソースは、フィールドが許す場合に更新され、新しいマニフェストだけに存在するリソースは作成され、チャートから削除されたリソースは通常削除されます。不変フィールドには明示的な置換戦略が必要になることがあります。

helm upgrade --install web ./chart \
  --namespace web --create-namespace \
  --values environments/production.yaml \
  --dry-run --debug

既存のツールチェーンで利用できる場合は helm diff を使用し、アップグレード後に helm get manifest と helm history を確認します。helm.sh/resource-policy: keep アノテーションはアンインストール時にリソースを保持できますが、一般的な安全策ではなく、意図的なライフサイクル上の判断にしてください。

静的マニフェストを段階的に移行する #

まず、ソース管理から実際に望ましい仕様を取得し、稼働中のオブジェクトと比較します。イメージバージョン、ホスト名、リソース制限、ストレージクラスなど、本当の環境差だけをパラメーター化し、すべてのフィールドをパラメーター化しないでください。チャートをレンダリングし、既存のリソースと比較します。

最初の移行では、安定した metadata.name、名前空間、セレクター、永続ボリューム要求名を維持します。セレクターを変更すると Pod が取り残される可能性があり、PVC 名を変更すると新しい要求が作成され、データは移動しません。ステートフルワークロードでは、所有権を移行する前に、本番環境ではないクラスターでバックアップ、リストア、ロールバック手順をリハーサルします。

Argo CD に安全に引き渡す #

Argo CD が Helm チャートをレンダリングするときは、同じリソースに対して別の helm upgrade を実行しないでください。Application を設定し、レンダリングされたマニフェストと差分を確認し、最初はプルーニングなしで同期してから、アプリケーションが正常で、範囲内に無関係なリソースがないことを確認した後にのみプルーニングを有効にします。

リソース名の変更や削除ガードを伴う依存関係グラフには、段階的な移行を使用します。

1. 古いリソースを保持したまま新しいリソースを追加する。
2. 利用者を更新し、ヘルスチェックを待つ。
3. 古い依存リソースを削除する。
4. 後の同期で古い親リソースを削除する。

Argo CD の同期ウェーブは通常の適用とプルーンの順序を設定できますが、データ移行、アドミッション Webhook、外部クライアントが関係する場合は、段階的な変更の方が明確です。