Rancher v2.3の主要機能を触ってみた

本記事は、Rancher v2.3で追加した主要な機能の紹介及び検証を纏めたものです。
・Windows GA Support
・クラスターのテンプレート機能
・Istio機能のデフォルト搭載
・ノードのセルフヒーリング機能
・K8Sバージョンアップの為のRancherバージョンアップが不要になった

Windows GA Support

KubenertesクラスターにWidowsノードの追加、Widowsアプリのデプロイ

概要

Rancherでのサポート内容

現状できないこと

基本は、kubernetesのWidowsコンテナからの制約事項です。詳細は、Windows制約事項からご参照ください。

検証Goal

■やること：
　WindowsとLinuxのMixedのクラスタを作成し、WindowsノードにIISアプリをデプロイする

■検証用のノード構成：

ノード	役割	数	OS/MW
master node	etcdとControlPlane	１台	Ubuntu 18.04/Docker 18.09（1例）
worker node	Linux	１台	Ubuntu 18.04/Docker 18.09（1例）
worker node	Windows	１台	Windows Server 2019/Docker EE-basic 19.03（1例）
※AWS使用の場合は、[Microsoft Windows Server 2019 Base with Containers]のAMIから、Windowsノードを作成できます。

windows対応のMixedクラスタの構築

・[Cluster]方式で、クラスタ作成画面に、windows対応クラスタのパラメータは、下記のように設定します。
　※現時点、[Cluster]方式+[kubernetesV1.15]+[Flannel]の設定しか、windows対応クラスタが作成できない

・事前に用意したVMに、master node構成するためのDockerコマンドを実行します。

・master nodeの構築が完了後に、事前に用意したVMに、worker node(linux)構成するためのDockerコマンドを実行します。

・worker node(linux)の構築が完了後に、事前に用意したwindows VMに、worker node(windows)構成するためのDockerコマンドを実行します。

・クラスタ構築後のノード一覧は下記となります。

Widowsアプリのデプロイ

・[microsoft/iis]をwindowsノードにデプロイします。

・デプロイが完了したら、WindowsノードのPublic IPとNodePortのポート番号で、アクセスします。

クラスターのテンプレート機能

事前に決めたクラスター設定（セキュリティポリシーやベストプラクティス設定）をテンプレート化し、クラスター作成時は、指定のテンプレートを使用してクラスターを作成

概要

制約事項

・クラスターテンプレート機能を使用せず作成したクラスター（V2.3以外のバージョンで生成したクラスター含む）は、作成後にクラスターテンプレート機能を利用して、クラスターの設定変更ができない
・クラスターテンプレートの設定を変更したい場合は、既存のテンプレートのバージョンの設定変更ができないため、既存バージョンをクローンして新しいバージョンを生成します。その後、新しいバージョンの設定を、クラスターに適用できる

検証Goal

■やること：
　クラスターテンプレートを作成して、クラスター作成時に、クラスターテンプレートを使用して作成する。
　クラスターテンプレートをバージョンアップし、作成したクラスターも、クラスターテンプレートの新しいバージョンに更新して、クラスター設定を更新する。

クラスターテンプレートの作成して、クラスター作成時に適用

・[RKE Templates]メニューから、クラスターテンプレート作成画面を開きます。


・クラスターテンプレート作成画面に、クラスター設定項目を設定します。
　※設定項目のところの切替ボタンの押下により、テンプレート利用者がクラスター作成時に、該当項目に対して、設定の上書きができるようになります。

・クラスターテンプレート配下に、v1のテンプレートバージョンが作成されました。

・クラスターテンプレートを指定して、クラスターを作成します。
　※クラスターテンプレートとバージョンを指定するだけで、クラスターの設定項目が自動に入力されてています。

クラスターテンプレートをバージョンアップして、クラスター編集時に新しいテンプレートのバージョン設定を適用

・テンプレート配下の既存のバージョンをクローンして、新しいバージョンを作成します。

・ここでは、kubernetesのデフォルトのバージョンのみを変更しました。※必要に応じて、いろんなクラスター設定変更できます。


・クラスターテンプレートを適用しているクラスターにも、アップデート催促の通知アイコンが表示されます。

・クラスターテンプレートの最新のバージョンを選択したら、クラスターの設定項目が自動に更新されてています。

・最新のテンプレートのバージョンを適用したら、アップデート催促の通知アイコンが消えます。

Istio機能のデフォルト搭載

サービスメッシュ機能を提供するIstioをデフォルト搭載

概要

主要な機能

・UIからのIstioの設定機能
・namespaceへのIstioサイドカー自動注入の設定機能
・kiali(Istio可視化ツール)、jaegar（分散トレーシング）もデフォルトでUI搭載

検証Goal

■やること：
　Istio機能を有効化してから、サンプルアプリケーションをデプロイし、UI画面上に、トラフィック情報確認などを行う

■事前準備
下記のようなテスト用クラスターを用意します。※リソースは多めにしました
　master node(2Cpu+8GB)×1
　worker node(2Cpu+8GB)×4
※Istioは結構リソースを消費します。最低（CPU：3950m | メモリ：5546Mi）を消費します。詳細情報は、Istio's Prerequisitesをご参照ください。

Istio機能を有効化

・[Istio]メニューから、Istio画面を開き、デフォルトの設定のままで機能を有効化します。

サンプルアプリケーションをデプロイ

・下記のサンプルアプリのchart URLをプライベートカタログとして追加します。
https://github.com/qiang1981cn/bookinfo-chart

・[default]namespaceをistioサイドカー自動注入のnamespaceとして設定します。

・カタログ機能で、上記で設定したプライベートカタログのアプリを選択して、[default]namespaceにデプロイします。
　Review画面機能は、v1とv2の2つのバージョンを同時にリリースさせ、ユーザーリクエストのトラフィック制御はそれぞれ５０％にするように設定します。

サンプルアプリのトラフィック情報を確認

・トラフィックのデータを生成させるため、サンプルアプリの対象reviews画面を複数回をアクセスします。

・UI画面上に、サンプルアプリのトラフィック情報を確認します。

ノードのセルフヒーリング機能

クラスターを構成するノード数を指定した数に自動維持
※Rancher経由で、AWS,Azure,Vsphereなどのクラウドに、Node Driversで構築したクラスタをサポート対象とする

概要

主要な機能

・Node Pool単位で維持するノード数を指定
・Node Pool単位でunreachableの時間を指定
　※unreachableの時間：ノードと通信取れない時間。この時間経過後に、対象ノードが削除され、新しいノードが自動再作成される

検証Goal

■やること：
　クラスターを構成する[Node Pool]を2つ作成する。１つの[Node Pool]は、ノードのセルフヒーリング設定ありにし、もう１つは、セルフヒーリング設定なしにします。それぞれの[Node Pool]中のノードを手動で停止して、セルフヒーリング有無を確認する

テスト用クラスターを作成

■事前準備
下記のようなテスト用クラスターを用意します。
　master node ： (2Cpu+8GB)×1
　worker node（with-selfhealing） : (2Cpu+8GB)×2 　※ノードのセルフヒーリング設定あり＋[Auto Replace]が1分指定
　worker node（without-selfhealing） : (2Cpu+8GB)×2 　※ノードのセルフヒーリング設定なし

※[Auto Replace]が0以外の値（分単位）を指定している場合、指定した時間にノードと通信取れない時にノードのセルフヒーリングが行われる

ノードの手動停止とセルフヒーリング有無を確認

・それぞれの[Node Pool]中の1つのノードを手動で停止します。


・停止処理の１分間後に、セルフヒーリング有無を確認します。
　結果1：ノードのセルフヒーリング設定ありの[with-selfhealing]が、通信取れないノードを削除し、新しいノードを作成しました。
　結果2：ノードのセルフヒーリング設定なしの[without-selfhealing]が、何の復旧処理も行わないです。

K8Sバージョンアップの為のRancherバージョンアップが不要になった

K8Sバージョンアップを行いたい場合、通常は、Rancherバージョンアップを行ってから、新しいバージョンのRancherから、K8Sバージョンアップを行います。
V2.3以降、K8sのpatchバージョンアップ(CVE緊急対応など)の場合は、Rancherバージョンアップが不要となり、
下記のクラスタ編集画面から、定期的に自動更新されたK8sリストから最新バーションを選択してにアップデートできます。

おわり

主要な機能だけを説明と検証させて頂きましたが、上記以外も、ノードへのtaints追加機能や、UI上のHPA管理機能など、いくつかの機能が追加されています。
詳細な変更情報（バージョンアップ時の注意事項合わせて）は、リリースノートをご参照ください。

今後のリリースですが、kubernetes 1.16 GA対応は、V2.3.x以降で対応されます。
また、当初、V2.3にリリースする予定の、クラスターのセキュリティスキャンとアラーム機能は、V2.4になりそうです。