Rancher 2.x ドキュメント雑記

本記事の目的

RancherはRancher Lab社が主体となって開発を行っているオープンソースのコンテナプラットフォームです．バージョン1.xについてはKubernetesに加え，様々なオーケストレーションツールをサポートしていましたが，バージョン2.0からはkubernetesを主眼において開発が行われています．
今回はRancherのドキュメントのOverviewとArchitectureをまとめた結果を載せます．また，読むのがめんどくさい人はスライドをSlideShareに載せたのでよければどうぞ．

Overview

• Rancherは，本番環境でコンテナをデプロイする組織向けに構築されたコンテナ管理プラットフォーム
  • 簡単にどこでもkubernetesを実行し，IT要件を満たし，DevOpsチームを強化することが可能

どこでもKubernetesを実行する

• Kubernetesはコンテナオーケストレーションツールの標準
  • 現在，ほとんどのクラウドや仮想化ベンダが標準インフラストラクチャとして提供
  • Rancherユーザは，Rancher Kubernetes Engine （RKE）を使ってKubernetesクラスタを作成するか，GKE，AKS，EKSなどのクラウドKubernetesサービスを使ってKubernetesクラスタを作成するかを選択すること可能
  • Rancherユーザは，任意のKubernetesディストリビューションやインストーラを使用して作成した既存のKubernetesクラスタをインポートして管理することも可能

IT要件を満たす

• Rancherは，その管理下にあるすべてのKubernetesクラスタの集中認証，アクセス制御，監視をサポート
  • 例えば，以下

• Active Directoryの資格情報を使用して，GKEなどのクラウドベンダーがホストするKubernetesクラスタにアクセス
• すべてのユーザ，グループ，プロジェクト，クラスタ，およびクラウド全体のアクセス制御とセキュリティポリシを設定し，強制する．
• Kubernetesクラスタの健全性と容量を一枚のガラス越しに確認可能

DevOpsチームを強化する

• Rancherは直感的なユーザインターフェースを提供

  • DevOpsエンジニアがアプリケーションのワークロードを管理するため

• ユーザは，Rancherの使用を開始するためにKubernetesの概念に関する深い知識を持っている必要はない

• Rancherのカタログには便利なDevOpsツールのセットがある

  • e.g., セキュリティツール，監視システム，コンテナレジストリ，ストレージやネットワークドライバなど

• 次の図は，ITおよびDevOps組織においてRancherが果たす役割

• IT管理者は，すべてのユーザ，クラスタ，およびクラウドにまたがるポリシを可視化し，実施可能

Rancher APIサーバの特徴

• Rancher APIサーバはKubernetes APIサーバとetcdデータベースの上に構築

認証と役割ベースのアクセス制御

• ユーザー管理 : Rancher API サーバは, ローカルユーザだけでなく，Active Directory や GitHub などの外部認証プロバイダに対応するユーザ ID を管理
• 認証 : Rancher API サーバは，アクセス制御とセキュリティポリシを管理

Kubernetesとの連携

• Kubernetes クラスタのプロビジョニング : Rancher API サーバは既存のノードでKubernetesをプロビジョニングやKubernetesのアップグレードを実行可能
• カタログ管理 : アプリケーションの繰り返しデプロイを容易にするHelmチャートのカタログを使用する機能を提供
  • Helm : Kubernetes のパッケージマネージャという認識
• プロジェクトの管理 : 複数のネームスペースをグループとして管理し，その中でKubernetesを操作可能
  • プロジェクトとはクラスタ内の複数のネームスペースとアクセス制御ポリシーのグループ
  • プロジェクトはKubernetesの概念ではなくRancherの概念
  • RancherのUIとしてプロジェクト管理のための機能やプロジェクト内のアプリケーションを管理するための機能を用意
• Istio (サービスメッシュ) : Istio を用いてセキュリティポリシーの実施，問題のトラブルシューティング，グリーン/ブルーデプロイメント，カナリアデプロイメント，A/B テストのトラフィック管理などが可能
  • サービスメッシュ : アプリケーションのさまざまな部分が互いにデータをどのように共有するかを制御する方法

クラウドインフラストラクチャとの連携

• ノード追跡 : すべてのクラスタ内のすべてのノードの ID を追跡
• インフラのセットアップ : クラウドプロバイダを利用することで新しいノードと永続的なストレージをクラウドに動的にプロビジョニング

クラスタの可視性

• ロギング : Kubernetesクラスタの外に存在する様々な一般的なロギングサービスやツールと統合可能
  • クラスタレベルまたはプロジェクトレベルで設定可能
• 監視 : クラスタノード，Kubernetes コンポーネント，ソフトウェアデプロイメントの状態やプロセスを監視 (e.g., Prometheus)
  • クラスタレベルまたはプロジェクトレベルで設定可能
• アラート機能 : クラスタとプロジェクトで発生しているイベントすべての情報を入手
  • クラスタレベルまたはプロジェクトレベルで設定可能

Rancherによる下流クラスタの編集

• RKEによってプロビジョニングされたクラスタにのみ編集可能なクラスタオプションがある
• Rancherでクラスタを作成した後，クラスタ管理者はクラスタメンバーシップの管理，ポッドセキュリティポリシーの有効化，ノードプールの管理などのオプションを使用可能
• 下表は各クラスタタイプで利用可能な設定

アーキテクチャ

Rancherサーバアーキテクチャ

• 図はRKEによって作成された1つとAmazon EKS（Elastic Kubernetes Service）によって作成された2つのダウンストリームKubernetesクラスタを管理するRancher サーバのインストールを示す
• Rancher 専用サーバには専用のk8sクラスタを推奨
  • Rancherサーバにユーザワークロードを実行するのはパフォーマンスとセキュリティの観点からやめるべし
  • Rancherをデプロイした後，ワークロードを実行するためのクラスタを作成またはインポートが可能
• Rancherサーバは管理する下流のユーザークラスタとは別のノードで常に実行する必要がある

下流のクラスタとのコミュニケーション

• 次の図では，クラスタコントローラ，クラスタエージェント，ノードエージェントによって Rancher が下流のクラスタを制御する方法を示す

1. Authentication Proxy

• ユーザBobがユーザクラスタ1の下流のユーザクラスタ上で実行されている全てのPodを見たいとき
• BobはRancher内からkubectlコマンドを実行してPodを見ることが可能
  • これはRancherの認証プロキシによって認証されているから
• 認証プロキシは全てのK8s APIコールを下流のクラスタに転送
  • 認証サービス : ローカル認証，Active Directory，Github
  • 認証後，k8s になりすましたヘッダを設定し，k8sマスタにコールを転送
• Kubeconfig
  • 下流ユーザのK8sAPIサーバに接続するためにRancherサーバをプロキシする資格情報を含む

2. Cluster Controllers and Cluster Agents

• 下流のクラスタの中にクラスタエージェントが存在
  • クラスタエージェント: Rancherサーバ内の対応するクラスタコントローラへのトンネルを開く
• 1下流クラスタにつき，クラスタエージェント(下流クラスタ内)とクラスタコントローラ(Rancherサーバ内)が1つずつ存在
• それぞれのクラスタコントローラは
  • 下流クラスタのリソース変更の監視
  • 下流クラスタの現在の状態を希望する状態に
  • クラスタやプロジェクトのアクセス制御ポリシを設定
  • 必要なDockerマシンドライバとRKE, GKEなんどのk8sエンジンを呼び出し，クラスタをプロビジョニング
• クラスタエージェント:
  • Rancherが起動したk8sクラスタのK8s APIに接続
  • 各クラスタ内のWorkload, Podの作成，Deploymentの管理
  • 各クラスタのグローバルポリシとして定義されたroleとbindingの適用
  • event, stats, node_info, healthについて，クラスタとRancherサーバ内で通信

3. Node Agents

• クラスタエージェントが利用できない場合，ノードエージェントを代わりに利用可能
• DaemonSetリソースを使ってデプロイ
  • 全てのノードで動作するようにクラスタ操作を実行する際にノードと対話するために利用
    • 例: k8sのバージョンアップグレード，etcdスナップショットの作成，復元

4. Authorized Cluster Endpoint

• ユーザーはRancher認証プロキシを経由してリクエストをルーティングせずとも，下流のクラスタのKubernetes APIサーバに接続可能
• Rancherが起動したクラスタ(RKE)でのみ使用可能
  • インポートされたクラスタや，AmazonのEKSなどのほすとされたk8sプロバイダのクラスタでは利用不可能
• ユーザがこれを必要とする理由
  • Rancherがダウンしている時に下流のユーザクラスタにアクセスするため
  • Rancherと下流クラスタの間が長距離であるときのレイテンシを低減
• 下流クラスタ内のkube-api-authはクラスタのエンドポイントにユーザ認証機能を提供するためにデプロイ
• kubectlを利用してユーザクラスタにアクセスするとクラスタのk8s APIサーバががkube-api-authサービスをwebhookとして使用してユーザの認証