Rancherとは何か ―― Kubernetesクラスタを一元管理するための基盤

Kubernetesクラスタは、kubectlや各クラウドの管理画面から個別に管理できます。しかし、クラスタや利用者が増えてくると、接続先や権限の管理、各環境の状態確認に手間がかかるようになります。

Rancherは、複数のKubernetesクラスタの管理を一つの基盤にまとめるためのソフトウェアです。 クラスタの場所や種類が異なっていても、対応する環境を登録すれば、共通の画面から状態を確認し、利用者のアクセスを管理できます。

この記事では、Rancherの役割と基本構成を確認したうえで、実際の画面で何ができるのかを見ていきます。

この記事で扱う「Rancher」について

Rancherという名称は、文脈によって複数の製品や提供形態を指すことがあります。

本記事で扱うのは、Kubernetesクラスタを管理するRancher Managerです。ローカルPC上でコンテナやKubernetes環境を動かすRancher Desktopとは用途が異なります。

Rancher Managerにはオープンソースのコミュニティ版があり、SUSEはエンタープライズ向けに、サポートや関連する機能・サービスを含むSUSE Rancher Primeを提供しています。

ここでは、Rancher Managerの基本的な仕組みを「Rancher」と表記します。利用できる機能や提供バージョン、サポート範囲は提供形態によって異なるため、採用時には個別に確認してください。[Rancherの概要][ref-what-is-rancher]・[リリースノート][ref-release-notes]

RancherはKubernetesの代わりになるものではない

Rancherの役割を理解するには、アプリケーションを動かす基盤と、それを管理する仕組みを分けて考えると分かりやすくなります。

アプリケーションを実行するのはKubernetesクラスタです。Rancherを導入しても、Pod、Deployment、Service、Ingress、ConfigMap、Secretなどの基本的な役割は変わりません。

Rancherは、そのクラスタに対して、作成・登録、アクセス制御、状態確認、アプリケーション配布などの管理機能を提供します。

例えば、Rancherの画面からDeploymentを作成すると、対象クラスタのKubernetes APIへリソースが作成されます。別の方法でアプリケーションが動くわけではないので、画面で確認した内容はkubectlを使う際にも役立ちます。

Kubernetesの知識は引き続き必要ですが、状態確認や定型的な操作をGUIから行えるため、利用者が最初からすべてのコマンドに習熟している必要はありません。

Rancherの基本構成

まず押さえたいのが、Rancher Serverを動かす管理クラスタと、アプリケーションを動かす下流クラスタの関係です。

この図は、Rancherを経由する管理操作と、Agentによる接続の関係を示しています。アプリケーションの通信がRancherを経由することを示すものではありません。

Rancher管理クラスタ

Rancher Serverは、通常Kubernetesクラスタ上にデプロイします。このクラスタが管理クラスタで、Rancherの画面では通常、localという名前で表示されます。

開発・検証向けには単一のDockerコンテナで実行する方法もありますが、本番環境では高可用性を備えたKubernetesクラスタに導入します。公式ドキュメントでは、性能とセキュリティの観点から、管理用の専用クラスタを用意し、利用者のアプリケーションとは分ける構成が推奨されています。

管理クラスタには、Rancherの設定、ユーザーや権限、管理対象クラスタに関する情報などが保存されます。そのため、Rancherを復旧できるよう、管理情報のバックアップも必要です。

なお、Rancher Serverが停止しても、そのことだけで下流クラスタのアプリケーションが停止するわけではありません。 下流クラスタは、独立したKubernetesクラスタとして動作を続けます。一方、Rancherの画面や認証プロキシを経由した操作は利用できなくなります。
障害時の手順では、Rancherを経由せずにクラスタへ接続できる経路と認証情報を確認しておきます。Rancherの認証プロキシを使うkubeconfigを手元に保存するだけでは、Rancher停止時の対策にはなりません。

下流クラスタ

Rancherが管理する、管理クラスタ以外のKubernetesクラスタを、**下流クラスタ（downstream cluster）**と呼びます。

下流クラスタには、Rancherから構築したRKE2・K3sのほか、Amazon EKS、Azure Kubernetes Service（AKS）、Google Kubernetes Engine（GKE）などのマネージドKubernetesや、外部で構築済みのKubernetesクラスタを含められます。

ただし、構築・登録できる環境やサポートされるバージョンは、Rancherのバージョンによって異なります。導入前には、使用するパッチバージョンに対応するSupport Matrix（対応構成一覧）を確認します。

Rancherと下流クラスタをつなぐAgent

下流クラスタには、cattle-cluster-agentなどの管理用コンポーネントが配置されます。cattle-cluster-agentは下流クラスタからRancher Serverへ接続し、Kubernetes APIへの操作やクラスタ情報の取得に使う通信経路を提供します。
また、Rancherから構築するRKE2・K3sクラスタでは、各ノード上のサービスとしてrancher-system-agentが動作します。Rancherから受け取った実行計画に従い、Kubernetesのインストールや更新など、ノード上の処理を行います。

既存のRKE2・K3sクラスタを登録する場合は、構築時からRancherで管理する場合と同じ仕組みになるわけではありません。登録クラスタのバージョン管理には、後述するsystem-upgrade-controllerが使われます。

一般的な管理通信では、接続を開始するのは下流クラスタ側のAgentです。閉域環境やプロキシ、ファイアウォールのある環境では、AgentからRancherのURLへ接続できることを確認します。これとは別に、クラスタ構築や各機能に必要な通信も、公式の要件に沿って整理します。

Rancherではクラスタをどのように追加するのか

管理対象を追加する方法は、大きく分けて「新しく構築する」「既存のクラスタを登録する」の二つです。

Rancherからクラスタを構築する

Rancherでクラスタ構成を定義し、RKE2やK3sなどのクラスタを構築します。用意したLinuxノードで登録コマンドを実行する方法のほか、対応するインフラと連携して仮想マシンの作成から行う方法もあります。

Rancherから構築したRKE2・K3sクラスタでは、構成変更やKubernetesの更新など、構築後の管理も行えます。etcdを利用する構成では、スナップショットによるバックアップや復元も扱えます。[クラスタの構築と管理範囲][ref-cluster-capabilities]

既存クラスタを登録する

一般的な既存クラスタの登録では、Rancherが生成したマニフェストを対象クラスタへ適用します。EKS・AKS・GKEなどには、クラウドとの連携を利用する登録手順もあります。

登録のために、既存のワークロードを作り直す必要はありません。ただし、参照先を追加するだけの操作ではなく、Agentや権限設定などがクラスタへ追加されます。登録には必要な管理権限を用意し、適用する内容を確認します。

登録後にRancherから実行できる操作は、クラスタの種類によって異なります。RKE2・K3sでは、バージョン管理を有効にすると、system-upgrade-controllerと更新計画を表すPlanリソースが配置され、Kubernetesを更新できます。Rancherから構築したクラスタのrancher-system-agentとは別の仕組みです。

一方、登録したetcd利用クラスタのスナップショット取得は、Rancher UIの外で行います。既存クラスタを登録しても、構築済み環境のライフサイクル管理を丸ごと引き継げるとは限りません。

Rancherの画面で確認できること

Rancherでは、管理対象全体の確認から、個々のKubernetesリソースの操作までを同じUIから行えます。ここでは、最初に使うことが多い画面を紹介します。

なお、メニューや表示項目は、パッチバージョン、利用者の権限、導入した機能によって異なる場合があります。

1. クラスタ一覧

クラスタ一覧では、Rancherが管理しているクラスタの状態やKubernetesバージョンなどを確認できます。対象を選ぶ際や、接続が失われているクラスタを調べる際の起点になる画面です。

ノードやリソースの詳しい情報は、対象クラスタの詳細画面で確認します。CPUやメモリの使用状況などは、メトリクスを取得できる構成であることが前提です。

2. Cluster Explorer

対象クラスタのExploreを選択すると、Cluster Explorerが開きます。

Workloads、Service Discovery、Storage、Appsなどのメニューから、Deployment、Pod、Service、Ingress、PVC、Secretといったリソースを確認できます。画面に表示される範囲と実行できる操作は、利用者の権限に従います。

前述の通り、RancherのUIで行うリソースの変更も対象クラスタのKubernetes APIへ反映されるため、画面で作成したリソースをkubectlで確認することも、CLIで作成したリソースを画面から調べることもできます。

3. WorkloadsとPod

Workloadsでは、Deployment、DaemonSet、StatefulSet、Jobなどを確認できます。Deploymentを開くと、設定したレプリカ数、Podの稼働・準備状況、コンテナイメージ、関連するPodなどを調べられます。

Podの詳細では、状態、再起動回数、イベント、ログなどを確認できます。必要な権限があり、コンテナイメージにシェルが含まれていれば、ブラウザからコンテナ内のシェルを開くこともできます。

例えば、Podが起動しないときは、まず状態とイベントを確認し、コンテナが起動していればログも調べる、といった使い方ができます。Rancherは、日常的な確認だけでなく、トラブルシューティングの最初の調査にも利用できます。

Rancher独自の「Project」とは

Projectは、一つのクラスタ内にある複数のNamespaceをまとめるための管理単位です。Kubernetes標準のリソースではなく、Rancherが追加する概念です。

Cluster
├── Project: 開発チーム
│   ├── Namespace: application-dev
│   └── Namespace: application-test
│
└── Project: 運用チーム
    ├── Namespace: monitoring
    └── Namespace: logging

Projectには、利用者やグループをメンバーとして追加し、ロールを割り当てられます。例えば、「開発チーム」のProjectにメンバーを追加すれば、そのProjectに属するNamespaceへまとめて権限を付与できます。Namespaceごとに同じ権限設定を繰り返す負担を減らせます。

また、Project単位でResourceQuotaを設定し、所属するNamespaceのリソース使用量に上限を設けることもできます。これは使用量を制限する仕組みであり、物理的なCPUやメモリを専有・予約する機能ではありません。[ProjectとNamespaceの管理][ref-projects]

Rancher独自の概念だからといって、Projectをkubectlで扱えないわけではありません。Project自体は管理クラスタ上のカスタムリソースとして保存されており、必要な権限でそのAPIへ接続すれば、kubectlでも確認・操作できます。Projectに所属するNamespaceは、対象の下流クラスタに存在します。

つまり、「Projectの管理情報を見る接続先」と「Namespaceやアプリケーションを見る接続先」が異なる点を押さえておくと、UIとCLIを併用するときに混乱しにくくなります。

なお、Projectを分けるだけで、Namespace間のネットワーク分離まで保証されるわけではありません。通信を制限する要件がある場合は、NetworkPolicyと、それを適用できるネットワークプラグインも含めて設計します。

ユーザーと権限を一か所で管理する

Rancherでは、ローカルユーザーに加え、対応する外部の認証基盤と連携できます。認証したユーザーやグループに対し、操作を許可する範囲とロールを割り当てます。[認証と権限管理][ref-auth]

例えば、クラスタ管理者にはCluster Owner、アプリケーション担当者には担当ProjectのMember、状態を確認する担当者には対象範囲のRead Onlyを割り当てる、といった使い分けができます。実際のロールは、必要な操作を確認して選びます。

Rancherから取得するkubeconfigでは、通常、Rancherの認証プロキシを経由して下流クラスタへ接続します。この経路を利用すれば、Web UIと同様に、kubectlからの操作にもRancherのユーザーと権限を利用できます。

ただし、Rancherを介さない別の認証情報を使っている場合、そのアクセス権の管理も必要です。「Rancher上で権限を外せば、どの経路からも接続できなくなる」とは限らない点に注意します。

アプリケーション配布と運用機能

Rancherは、リソースの表示だけでなく、アプリケーションの導入や運用機能を追加するための入口も提供します。

AppsによるHelm Chartの導入

Appsでは、Helm Chartを使ってアプリケーションを導入できます。Chartの設定値を画面やYAMLで指定し、インストール、更新、削除を行います。

複数のマニフェストを個別に適用する代わりに、アプリケーションを一つのリリースとして管理できるため、運用アドオンの導入にも利用できます。

MonitoringとLogging

MonitoringやLoggingのアプリケーションを追加すると、メトリクスの収集・可視化やログの収集・転送などを行えます。

Rancherをインストールしただけで、すべてのメトリクスやログが長期間保存されるわけではありません。特にLoggingは、収集したログの転送先を設定して利用するため、保存・検索する仕組みは別途用意します。

必要な保存期間、保存先、使用するストレージ、収集によるリソース消費を考え、既存の監視・ログ基盤との役割分担を決めておきます。

FleetによるContinuous Delivery

Rancherには、GitOpsによる継続的な配布を行うFleetが統合されています。KubernetesのYAMLマニフェスト、Helm Chart、Kustomizeの構成をもとに、対象クラスタへリソースを配布できます。

例えば、複数クラスタへ共通設定を配布する場合、Gitに配布したい構成を保存し、変更をレビューしてから反映する運用を組み立てられます。クラスタごとに同じコマンドを繰り返す代わりに、配布対象と設定をまとめて管理できます。

Fleetの仕組みと具体的な操作は、別のコラムで詳しく扱います。

Rancherを使うと何が楽になるのか

複数クラスタの状態を確認するとき、利用者の権限を見直すとき、共通設定を配布するとき。Rancherは、クラスタごとに繰り返していた作業を整理するために使えます。

オンプレミスとクラウドが混在していたり、複数の部署やチームへクラスタを提供していたりする場合は、管理方法をそろえる効果を検討しやすいでしょう。GUIを利用する人とCLIを利用する人が、同じ権限管理のもとで作業できる点も利点です。

一方、単一の小規模クラスタを少人数で使うだけであれば、Rancher Serverの保守が増えることも考慮しなければなりません。

Rancherを導入する前に確認したいこと

本番環境では、Rancher自体も重要な管理システムになります。少なくとも、次の点は事前に設計しておきます。

バックアップには特に注意が必要です。Rancher Backup Operatorが対象にするのは、管理クラスタ内のRancherに関するリソースです。下流クラスタ全体や、アプリケーションの永続ボリュームのデータまで保存するものではありません。それぞれに適したバックアップを別途設計します。

構成を決める際は、導入要件とSupport Matrixを参照し、実際の通信経路や復旧手順を検証しておきます。

まとめ

Rancherは、Kubernetesクラスタそのものを置き換えるのではなく、複数クラスタの管理をまとめるためのソフトウェアです。

Rancher Serverは管理クラスタで動作し、下流クラスタのAgentと通信します。利用者はRancherの画面や認証プロキシを通じて、権限に応じたリソースの確認・操作を行います。ProjectでNamespaceの権限をまとめ、AppsやFleetでアプリケーションの導入・配布を管理することもできます。

まずは、localと下流クラスタの違いを確認し、対象クラスタのPodやNamespaceを画面とkubectlの両方で見比べてみると、RancherとKubernetesの関係をつかみやすくなります。