produced by stylez

Sign in Subscribe
Rancher

Rancherの「local」クラスタと下流クラスタは何が違う？

この記事では、localクラスタと下流クラスタの役割を整理します。

Rancherの「local」クラスタと下流クラスタは何が違う？

Rancherへログインすると、クラスタ一覧にlocalという名前のクラスタが表示されます。

このlocalクラスタと、RKE2、K3s、EKSなどの管理対象クラスタは、同じ一覧に並んでいても役割が異なります。

違いを理解せずに運用すると、Rancher Serverが動作するクラスタへ業務アプリケーションを配置したり、Rancherのバックアップで下流クラスタのデータまで保護できると誤解したりする可能性があります。

この記事では、localクラスタと下流クラスタの役割を整理します。

localクラスタはRancher Serverが動く管理クラスタ

localクラスタは、Rancher Serverを実行しているKubernetesクラスタです。公式ドキュメントでは、管理クラスタやupstream clusterと表現されることもあります。

HelmでRancherをインストールした場合、RancherのDeployment、Service、Ingress、Secret、CRDなどは、このクラスタ上に作成されます。

代表的には、次のようなリソースを確認できます。

  • cattle-system Namespace上のRancher Server
  • RancherのWebhookや各種Controller
  • Rancher Backup Operator
  • Rancherの管理情報を保持するKubernetesリソース
  • Rancher Server用クラスタのetcd、Control Plane、Node

localクラスタは、単に最初から登録されている業務クラスタではありません。Rancherという管理基盤そのものを動かすクラスタです。

下流クラスタはアプリケーションを実行するクラスタ

下流クラスタは、Rancherが作成または登録して管理するKubernetesクラスタです。公式ドキュメントではdownstream clusterやdownstream user clusterと呼ばれます。

実際の業務アプリケーション、開発環境、AI基盤、社内サービスなどは、原則として下流クラスタへ配置します。

Rancherは下流クラスタへcattle-cluster-agentなどを配置し、そのAgentを通じてクラスタの状態確認や管理操作を行います。

役割の違い

項目 localクラスタ 下流クラスタ
主な目的 Rancher Serverを実行する 利用者のアプリケーションを実行する
Rancher画面上の位置付け 管理基盤そのもの Rancherの管理対象
代表的なNamespace cattle-system、cattle-resources-systemなど 利用者が作成したProject、Namespace
障害時の主な影響 Rancher UI、API、認証Proxy、一元管理操作 そのクラスタ上のアプリケーションとKubernetes機能
Rancher Backupの対象 Rancher関連リソース 原則として対象外
業務ワークロード 原則として配置しない 配置する

同じKubernetesクラスタであっても、責任範囲と保守方法が異なります。

なぜlocalクラスタへ業務ワークロードを置かないのか

Rancher Serverと業務ワークロードを同じクラスタへ配置すると、障害範囲と保守範囲が重なります。

例えば、次のような問題が起こりやすくなります。

  • 業務アプリケーションのCPU・メモリ・Disk負荷がRancherへ影響する
  • Rancherのアップグレードや管理クラスタ保守が業務へ影響する
  • 業務側の設定変更でlocalクラスタ全体を不安定にする
  • Rancher管理者とアプリケーション管理者の権限境界が曖昧になる
  • 障害時に、管理基盤と業務基盤のどちらが原因か切り分けにくい

本番環境では、Rancher Server専用の管理クラスタを用意し、業務ワークロードとは分離する構成が推奨されます。

小規模な検証環境で一時的に混在させる場合も、あくまでPoC上の割り切りであることを明確にします。

localクラスタが停止しても、下流クラスタは直ちに停止しない

Rancher Serverやlocalクラスタが停止しても、下流クラスタのKubernetes Control Planeと既存ワークロードが正常であれば、アプリケーションは通常そのまま動作します。

ただし、次の機能には影響します。

  • Rancher UIとRancher APIへのアクセス
  • Rancher経由のkubectl接続
  • Rancherの認証Proxyを経由する操作
  • Rancherからのクラスタ設定変更
  • Rancherによるプロビジョニングやライフサイクル操作
  • Agentを通じた状態同期

つまり、「Rancherが停止した」と「下流クラスタが停止した」は同じではありません。

一方で、Rancherを経由しない直接接続手段を用意していなければ、障害中に下流クラスタを操作できない可能性があります。管理クラスタとは別に、元のkubeconfigやAuthorized Cluster Endpointなどの緊急用経路を設計しておくことが重要です。

Rancher Backupが保護するのはRancherの管理情報

Rancher Backup Operatorは、localクラスタ上に存在するRancher関連リソースをバックアップします。

主な対象は、次のような情報です。

  • Rancherへ登録されたクラスタの管理情報
  • ユーザー、Role、RoleBinding
  • ProjectやNamespaceに関するRancher側の設定
  • RancherのGlobal Settings
  • Rancher関連のCRDとCustom Resource

一方で、下流クラスタ上の次のデータをバックアップするものではありません。

  • 下流クラスタのetcd全体
  • PersistentVolume内の業務データ
  • データベースの内容
  • アプリケーション固有の設定やバックアップ

下流クラスタには、クラスタスナップショット、PVバックアップ、アプリケーションバックアップを別途設計します。

localクラスタで確認するもの

Rancherの運用では、localクラスタを隠して触らないのではなく、管理基盤として適切に監視します。

最低限、次を確認します。

  • Rancher Podが期待するレプリカ数でRunningか
  • IngressとServiceが正常か
  • 管理クラスタのNodeがReadyか
  • etcd、Control Plane、Diskに異常がないか
  • TLS証明書の期限が近づいていないか
  • Rancher Backupが成功しているか
  • cattle-systemでWarning Eventが発生していないか

運用ルールとして決めておきたいこと

localクラスタと下流クラスタの違いを理解したうえで、次のルールを文書化すると安全です。

  1. localクラスタへ配置してよいコンポーネントを限定する
  2. Rancher管理者と業務クラスタ管理者の権限を分ける
  3. Rancher Backupと下流クラスタのバックアップを別に設計する
  4. 管理クラスタ停止時の直接アクセス方法を保管する
  5. localクラスタの保守・アップグレード手順を独立させる
  6. Rancher URL、DNS、TLS証明書を管理基盤として監視する

まとめ

localクラスタはRancher Serverを動かす管理クラスタであり、下流クラスタは実際のアプリケーションを動かす管理対象です。

重要な違いは次のとおりです。

  • localクラスタはRancher管理基盤そのもの
  • 業務ワークロードは原則として下流クラスタへ配置する
  • Rancher停止と下流クラスタ停止は同じではない
  • Rancher Backupは下流クラスタの業務データを保護しない
  • 本番では管理クラスタと業務クラスタを分離する

この区別が分かると、Rancherの可用性、バックアップ、権限、アップグレードの設計を整理しやすくなります。

参考資料

Read next

Comments ()