マルチクラスターKubernetesをマスターする：開発・ステージング・本番環境のためのRancher実践ガイド

Table of Contents

マルチクラスター管理の混乱

1つのKubernetesクラスターを運用するのはそれほど難しくありません。kubeconfig、いくつかのIDEプラグイン、そしてローカルスクリプトがあれば十分です。しかし、チームが成長するにつれ、AWS、GCP、オンプレミスなど、5、10、あるいは20ものクラスターを使い分けることになります。kubectl config use-contextに頼る運用は、非常にリスクの高いロシアンルーレットのようなものです。ターミナルのタブでの入力ミス一つで、日常的な開発環境の更新が、本番環境の障害報告書（ポストモーテム）作成へと変わってしまう可能性があります。

一元管理は単なる贅沢ではなく、セーフティネットです。健全性の監視、ロールベースのアクセス制御（RBAC）の適用、一貫したアップデートの配信を行うための単一の司令塔が必要です。私はこれまで200ノードを超える環境の管理にRancherを使用してきましたが、その安定性は画期的です。Rancherは、基盤となるインフラの複雑な詳細を隠し、統一されたインターフェースを提供してくれます。

Rancher管理サーバーのデプロイ

環境を同期する前に、Rancherサーバー専用の「ホーム」が必要です。既存のクラスターにHelm経由でRancherをインストールすることもできますが、概念実証（PoC）のために素早く立ち上げるならDockerが最も簡単です。

本番環境では、少なくとも3つのノードを持つ高可用性RKE（Rancher Kubernetes Engine）クラスターを推奨します。最大10個のダウンストリームクラスターを処理する管理プレーンの場合、2 vCPUと8GBのRAMを搭載した Linuxホストが最適です。次のコマンドを使用してサーバーを起動します。

docker run -d --restart=unless-stopped \
  -p 80:80 -p 443:443 \
  --privileged \
  rancher/rancher:latest

コンテナが起動したら、ブラウザで https://<your-server-ip> にアクセスしてください。ログインにはブートストラップパスワードが必要です。コンテナのログを確認して取得しましょう。

docker logs <container_id> 2>&1 | grep "Bootstrap Password:"

開発、ステージング、本番環境のオンボーディング

Rancherでは、既存クラスターのインポートが驚くほど簡単です。AWS上のEKSであっても、自宅のベアメタル構成であっても、ワークフローは同じです。Rancher UIで Import Existing Cluster を選択し、Generic を選びます。

クラスターには prod-us-east-01 のように分かりやすい名前を付けます。Rancherが専用の kubectl コマンドを生成するので、それを対象クラスターのマスターノードで実行します。

kubectl apply -f https://<rancher-url>/v3/import/<token>.yaml

このコマンドにより cattle-cluster-agent がデプロイされます。このエージェントが管理サーバーへのブリッジとして機能します。ステージング環境や開発環境でも同様の操作を繰り返してください。60秒ほどで、CPU使用率、メモリ負荷、ノードの健全性などのリアルタイム統計がダッシュボードに表示されます。

プロジェクト機能による効率化

私は、標準のKubernetesにはないRancherの「プロジェクト（Projects）」機能を多用しています。Kubernetesにはネームスペースしかありませんが、Rancherでは複数のネームスペースを1つの「プロジェクト」にグループ化できます。これはマルチテナンシーにおいて非常に便利です。例えば「決済サービス」プロジェクトに20GBのメモリクォータを設定すれば、その制限が開発、テスト、サンドボックスの各ネームスペースに自動的に適用されます。

ストレスのないアプリデプロイ

Rancherの真骨頂は、複数のクラスターに対して同時にアプリケーションをプッシュできる点にあります。高度なチーム向けには、大規模運用を想定したGitOpsエンジンであるFleetが組み込まれています。初心者であれば、標準の「Apps & Marketplace」の方が使いやすいでしょう。

例えば、3つの環境すべてに標準化されたNginxインingressコントローラーをデプロイする必要があるとします。もう3つの異なるターミナルにログインする必要はありません。代わりに「Continuous Delivery」メニューを使用します。

Helmチャートを含む Gitリポジトリ を接続します。
クラスターラベル（例：env=prod）を使用して ターゲット を定義します。
Rancherがインフラ全体のステートを同期するのを見守ります。

CLIを好む場合は、UIから直接、特定のクラスターにスコープされた Kubeconfig ファイルをダウンロードできます。このファイルはRancherの権限設定を継承します。ジュニアデベロッパーがRancherで「読み取り専用」権限しか持っていない場合、彼らの kubectl コマンドも自動的に制限されます。

モニタリングとグローバルな可視性

ポッドの内部で何が起きているかが見えなければ、一元管理は意味をなしません。RancherはPrometheusとGrafanaのワンクリックセットアップを提供しています。新しいクラスターごとに手動でスクレイパーを設定する必要はありません。「Cluster Tools」メニューで有効にするだけです。

# モニタリングスタックが正常に動作しているか確認
kubectl get pods -n cattle-monitoring-system

有効にすると、運用全体を俯瞰できるようになります。本番環境のノードがメモリしきい値の90%に達すると、メインダッシュボードに赤いアラートが表示されます。これにより、ユーザーが遅延を感じる前にスケールアップすることが可能になります。

また、ログの一元管理も推奨します。Rancherは各クラスターのログを単一のElasticsearchやSplunkインスタンスに転送できます。これによりデバッグの時間を大幅に短縮でき、1つの検索バーからすべてのクラスターにわたる特定のトレースIDを検索できるようになります。

実戦で学んだベストプラクティス

数多くの本番クラスターを管理してきた経験から、いくつかの重要な教訓を得ました：

管理プレーンの隔離： 顧客向けのアプリをRancherが動作しているのと同じクラスターで実行してはいけません。アプリが原因でクラスターがクラッシュすると、修正するための手段も失ってしまいます。
ローカルユーザーを廃止する： すぐにRancherをOkta、GitHub、またはActive Directoryに接続してください。15人のDevOpsチームで個別のパスワードを管理するのはセキュリティリスクです。
積極的にラベルを付ける： region=eu-west-1 や compliance=pci といったラベルを活用しましょう。これにより、特定のクラスター群に対してセキュリティパッチを数秒で自動適用できるようになります。

複数のKubernetesクラスターの管理は、断片的でストレスの溜まる経験である必要はありません。Rancherを中央制御プレーンとして使用することで、可視性を高め、より強固なセキュリティを適用できます。私のワークフローは「火消し」から「エンジニアリング」へと変わりました。あなたの環境でも同じことが実現できるはずです。