本文的目的是什么？

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. 集群控制器和集群代理

• 下流のクラスタの中にクラスタエージェントが存在

クラスタエージェント: Rancherサーバ内の対応するクラスタコントローラへのトンネルを開く

1下流クラスタにつき，クラスタエージェント(下流クラスタ内)とクラスタコントローラ(Rancherサーバ内)が1つずつ存在
それぞれのクラスタコントローラは

下流クラスタのリソース変更の監視
下流クラスタの現在の状態を希望する状態に
クラスタやプロジェクトのアクセス制御ポリシを設定
必要なDockerマシンドライバとRKE, GKEなんどのk8sエンジンを呼び出し，クラスタをプロビジョニング

クラスタエージェント:

Rancherが起動したk8sクラスタのK8s APIに接続
各クラスタ内のWorkload, Podの作成，Deploymentの管理
各クラスタのグローバルポリシとして定義されたroleとbindingの適用
event, stats, node_info, healthについて，クラスタとRancherサーバ内で通信

3. 节点代理

• クラスタエージェントが利用できない場合，ノードエージェントを代わりに利用可能

 

• DaemonSetリソースを使ってデプロイ

全てのノードで動作するようにクラスタ操作を実行する際にノードと対話するために利用
例: k8sのバージョンアップグレード，etcdスナップショットの作成，復元

4. 授权的集群终点

• ユーザーはRancher認証プロキシを経由してリクエストをルーティングせずとも，下流のクラスタのKubernetes APIサーバに接続可能

 

• Rancherが起動したクラスタ(RKE)でのみ使用可能

インポートされたクラスタや，AmazonのEKSなどのほすとされたk8sプロバイダのクラスタでは利用不可能

ユーザがこれを必要とする理由

Rancherがダウンしている時に下流のユーザクラスタにアクセスするため
Rancherと下流クラスタの間が長距離であるときのレイテンシを低減

下流クラスタ内のkube-api-authはクラスタのエンドポイントにユーザ認証機能を提供するためにデプロイ
kubectlを利用してユーザクラスタにアクセスするとクラスタのk8s APIサーバががkube-api-authサービスをwebhookとして使用してユーザの認証