More than 3 years have passed since last update.

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

Last updated at 2020-04-02Posted at 2020-03-31

本記事は、Rancher v2.4.0で追加した主要な機能の紹介及び検証を纏めたものです。
・クラスターのセキュリティスキャン（CIS Kubernetes Benchmark）
・k3sクラスターのメンテナンス機能
・ゼロダウンタイムのクラスターのアップグレード
・クラスターのバックアップとロールバックの機能増強
・helm3のサポート
・その他

クラスターのセキュリティスキャン

Kubernetesクラスターに対して、CIS Kubernetes Benchmarkの（チェックリスト）でスキャン実行とレポート生成の機能です。

概要

主なの機能

・クラスターのスキャンの実行
・定期スキャンのスケジュールの設定
・セキュリティレポートの生成と結果通知
・Rancher APIのサポート

制約事項

・v2.3.x以前のバージョンは、CIS Benchmarkチェックマニュアル手順でのチェックとなります。
・v2.4.0の時点は、RKEクラスターのみの対応となります。(import、custom、マネージドk8sクラスター方式で作成されたクラスターは未対応)
・v2.4.0の時点は、CIS_Kubernetes_Benchmark_v1.4.0（Kubernetes 1.13+のクラスターを対象）を対応しております。
・RKEディストリビューションの仕様（k8sコンポネートをコンテナで動くなど）により、一部CIS Benchmarkチェック項目が実施不要（N/A）となっています。

検証Goal

■やること：
　クラスターに対して、スキャン実行とスキャン結果確認を行う
　クラスターに対して、定期スキャン実行スケジュールとスキャン結果通知を設定

■前提条件：
Rancherサーバー上に、スキャン対象のRKEクラスターを用意されたこと（構築手順はこちらをご参照ください）

スキャン実行とスキャン結果確認

・[Cluster名]→[Tools]→[CIS Scans]メニューをクリックし、CIS Scans画面に遷移させ、[Run Scan]ボタンをクリックします。

・CIS Scansのプロファイル選択画面に、下記のようにプロファイルを設定して、[Run]ボタンをクリックします。
　※v2.4.0の現時点に、選択できるプロファイルは下記となります。
　RKE-CIS-1.4 permissive　：一部項目をスキップで実行
　RKE-CIS-1.4 hardened　：スキップなしで実行

・スキャン実行完了まで待ちます。

・スキャン履歴名をクリックし、スキャン結果確認画面に遷移させます。
　結果種類は下記の4種類となります。
「Pass」:成功
「Fail」:失敗（Descriptionに対策が書かれてる）
「N/A」:非該当　✳︎１
「Skipped」:スキップ　✳︎2
　 ✳︎１ RKE固有仕様(k8sコンポネートをコンテナで動くなど)により、実施不要な項目。詳細はこちらをご参照ください。
　 ✳︎2 トレードオフの結果（AlwaysPullImagesにより、帯域幅消費が増えるなど）により、遵守しない方がよい項目。詳細はこちらをご参照ください。

・スキャン結果確認画面に、[Download]ボタンをクリックし、スキャン結果をダウンロードします。

スキャン結果が「Fail」の項目の対応

・スキャン結果に、「Fail」の項目がある場合、「Description」の対策に従い、クラスターの設定変更を行うことで解消できます。

・対策に従い、クラスターのPodSecurityPolicy設定変更を行います。

・クラスターの設定変更後、スキャンを再度実行し、スキャン結果が「Pass」になったことを確認します。

スキャン定期実行、スキャン結果通知を設定

・CIS Scans画面に、[Add Schedule]ボタンをクリックし、クラスター編集画面に遷移させます。
・クラスター編集画面のCIS Scans設定項目のところに、スキャン用プロファイル、スケジュール、保存世帯数を設定して、クラスター変更内容を保存します。

・CIS Scans画面に、[Add Alert]ボタンをクリックし、スキャン結果のアラーム通知設定画面に遷移させます。
・アラーム通知設定画面に、Slackやメールなどの通知先を設定して、設定内容を保存します。
　通知先の作成手順は、こちらをご参照ください。

・スケジュールに指定している時間になったら、通知先のSlackにスキャン実行結果が届いたこと、を確認します。

k3sクラスターのメンテナンス機能

Rancherは、インポートしたk3sクラスターをk3sとして認識できます。また、リモートでk3sクラスターをメンテナンスできるようになりました。
※アップグレード為のコントローラーは、k3sのローカルに動きます。

概要

主な機能

Rancherから、リモートでk3sクラスターのアップグレード処理を行う
Rancherから、k3sクラスターの設定情報などを参照する

制約事項

・v2.4.0時点は、クラスターのアップグレードのみで、クラスターの設定情報がまだ変更できない

検証Goal

■やること：
　k3sクラスターを作成して、Rancherにインポート
　インポートしたk3sクラスターをアップグレード

k3sクラスターを作成して、Rancherにインポート

・k3sクラスターを用意します
　k3sクラスターの構築手順はこちらをご参照ください。
　k3sクラスターは、下記の構成(master:1台、worker:３台)となります。

・Rancherで、import方式でクラスターを作成し、k3sクラスター上にimport用のkubectlコマンドを実行します。

・インポートしたk3sを確認します。
　＜クラスターのDashboard＞

　＜クラスターのノード一覧＞

インポートしたk3sクラスターをアップグレード

・クラスターのDashboard画面に、右上の「Edit」メニューをクリックして、クラスター編集画面に遷移させます。

・「Kubernetes Version」項目に、最新のバージョンを選択し、「Save」ボタンをクリックします。
　その他の設定項目は必要に応じて設定してください。
　　「Drain Control Plane Nodes」項目：アップグレード前にDrain実施要否
　　「Drain Worker Nodes」項目：アップグレード前にDrain実施要否
　　「Control Plane Concurrency」項目：同時にアップデート可能のNode数（ローリングアップデートのバッチサイズ）
　　「Worker Concurrency」項目：同時にアップデート可能のNode数（ローリングアップデートのバッチサイズ）

・クラスターがUpgradingモードに入り、しばらく待つと、クラスターが選択したバージョンに更新されます。

ゼロダウンタイムのクラスターのアップグレード

v2.3以前のバージョンでのクラスターアップグレード処理には、クラスターのノードを並行でアップデートを行う為、ダウンタイムが発生します。（※kube-proxy変更によるiptables書き換えにより、対象ノード上のPODに一時アクセスできないなどが原因）
v2.4からは、ノードのローリングアップデータ方式を採用し、アプリケーションを中断せず、Kubernetesのクラスタとノードをアップグレードすることができるようになりました。

概要

主なの機能

各ノードのアップデータ方式の変更
・etcdノード　（変更なし）

v2.3	v2.4
1つずつ	1つずつ

・control Planeノード　

v2.3	v2.4
並行（max 50）	指定したサイズでローリングアップデータ

・workerノード　

v2.3	v2.4
並行	指定したサイズでローリングアップデータ

ノードのステータス遷移は、下記となります。
Active → Cordoned → Draining (if drain is enabled) → Drained (if drain is enabled) → Upgrading → Upgraded → Active

検証Goal

■やること：
　ローリングアップデータのバッチサイズを指定して、 control Planeノードとworkerノードのアップデータ動作を検証します。

※RKE CLIもゼロダウンタイムのクラスターのアップグレード機能が対応されておりますが、今回は、検証対象外とします。

検証用のクラスターを作成

・検証用のクラスターの作成画面に、各種類のノードプールを下記のような構成で設定します。
　クラスター構築の詳細手順はこちらをご参照ください。
　etcdノード：３台
　control Planeノード：３台
　workerノード：３台

・後のアップグレード処理が行えるように、「Kubernetes Version」をv1.15.11に設定します。

・「Advanced Options」の設定ところに、Workerノードの１回の最大同時アップデート数（ローリングアップデータのバッチサイズ）を設定します。
　「Maxiumum Worker Nodes Unavailable」（最大同時アップデート数）：１
　「Drain nodes」（アップデート前のDrain処理要否）：no

・control Planeノードの１回の最大同時アップデート数は、「Edit as YAML」ボタンから開くyaml設定画面から設定します。
　「max_unavailable_controlplane」（最大同時アップデート数）：１　※デフォルト値のまま

クラスターのアップグレード処理を実施

・クラスター作成後、クラスター編集画面に、「Kubernetes Version」をv1.15.11からv1.16.8に変更し、保存します。
　クラスター設定変更の詳細手順はこちらをご参照ください。

・control Planeノードが１台ずつでアップデートされていくことを確認します。

・workerノードが１台ずつでアップデートされていくことを確認します。

クラスターのバックアップとロールバックの機能増強

v2.3以前のバージョンでは、etcdデータしかバックアップできなくて、クラスターのアップグレード処理を行ったら、etcdのスナップショットだけで処理前の状態に戻れないです。
v2.4.0は、k8sバージョン情報とクラスター設定情報も、etcdデータと一緒にバックアップでき、またセットでロールバックすることもできます。

概要

主なの機能

・クラスターのバックアップ機能
　「etcdデータ」 + 「k8sバージョン情報」 + 「クラスター設定情報」をセットでバックアップ
・クラスターのロールバック機能
　下記の3つの方式でロールバックを行うことができる
　　「etcdデータ」のみのロールバック
　　「etcdデータ」 + 「k8sバージョン情報」のロールバック
　　「etcdデータ」 + 「k8sバージョン情報」 + 「クラスター設定情報」のロールバック

検証Goal

■やること：
・検証用クラスターを作成します。
・検証用クラスターに変更を加えます
・「etcdデータ」 + 「k8sバージョン情報」 + 「クラスター設定情報」のロールバック方式を検証します。

検証用のクラスターを作成

・後のアップグレード処理が行えるように、検証用のクラスターの作成画面に、「Kubernetes Version」をv1.15.11に設定します。
　クラスター構築の詳細手順はこちらをご参照ください。

・作成したクラスターの各ステータスは下記となります。
＜ノード情報＞：１ノードのみ

＜Kubernetes Version＞：v1.15.11
＜1ノードあたり最大のPOD数＞：110

＜defaultプロジェクト配下のワークロード＞：なし

検証用クラスターに変更を加え

・「etcdデータ」に更新を加える為、任意のプロジェクトに1つのワークロードを作成します。
　ワークロード作成の詳細手順はこちらをご参照ください。

・クラスターのアップグレードと、クラスター設定変更処理を同時に行います。
　クラスター設定変更の詳細手順はこちらをご参照ください。
　「k8sバージョン情報」に更新を加える為、クラスター編集画面に、「Kubernetes Version」をv1.15.11からv1.16.8に変更します。

　「クラスター設定情報」に更新を加える為、「Edit as YAML」ボタンから開くyaml設定画面に、kubelet設定のところに、「1ノードあたり最大POD数：２５０」のパラメータを追加します。

・クラスター設定変更後に、「k8sバージョン情報」と「クラスター設定情報」が更新されたことがDashboard画面から確認します。

ロールバックを実施

・ロールバックの選択画面に、下記のように、スナップショットとロールバック方式を選択して、「Restore」ボタン押下でロールバックを実施します。
　ロールバックの詳細手順はこちらをご参照ください。
　「Available Snapshots」（スナップショット）：v1.15.11-rancher1-3　※クラスター構築直後に自動生成したスナップショット
　「Restoration Type」（ロールバック方式）：「etcd, Kubernetes Version and cluster config」　※全てをロールバックする方式

ロールバックした後の結果検証

・「etcdデータ」が、クラスター構築直後の状態に戻ったこと確認します。
＜defaultプロジェクト配下のワークロード＞：なし

・「k8sバージョン情報」が、クラスター構築直後の状態に戻ったこと確認します。
＜1ノードあたり最大のPOD数＞：110
・「クラスター設定情報」が、クラスター構築直後の状態に戻ったこと確認します。
＜Kubernetes Version＞：v1.15.11

helm3のサポート

RancherのCatalog機能のベースとなっているHelmのバージョンについて、v2.4からは、既存のhelm2以外に、helm3もサポート開始です。

概要

主なの機能

・helmのChartをhelm2/helm3バージョン指定で、Catalogにアプリを追加できる
・helm3バージョン指定で追加したCatalogアプリは、helm3でライフサイクル管理（インストール、アップグレードなど）される
・helm2バージョン指定で追加したCatalogアプリは、helm2でライフサイクル管理（インストール、アップグレードなど）される

制約事項

・v2.3.x以前のバージョンに追加したCatalogアプリについて、v.2.4.0にバージョンアップしても、helm2バージョンのままで、管理されます。

検証Goal

■やること：
　helmのChartをhelm3バージョン指定で、Catalogに追加します。
　Catalog機能で、追加したCatalogアプリをクラスターにインストール、アップグレードします。

helmのChartをCatalogに追加

・Catalog追加画面に、検証用のhelmのChart情報を設定します。
　Catalog追加の詳細手順はこちらをご参照ください。
　「Helm Version」：Helm v3　※helm3バージョン指定

Catalogアプリをインストールとアップグレード

・Catalog画面に、先ほど追加したCatalogアプリを選択して、アプリバージョン=０．９でインストールします。
　Catalogアプリのインストールの詳細手順はこちらをご参照ください。

・インストールしたCatalogアプリを選択して、アップグレード（バージョン:0.9→1.0）します。※操作手順はv2.3以前のバージョンと変わらないです
　Catalogアプリのアップグレードの詳細手順はこちらをご参照ください。

その他

一部な機能だけを説明と検証させて頂きました。残りの下記のv2.4追加機能も簡単に紹介せていただきます。

スケーラビリティの改善

v2.4はスケーラビリティが大幅に改善されてました。最大に2000クラスターと100000ノードを管理できるようになりました。
今後、マルチクラウド上のクラスター管理や、各エッジローケーション上の大量な小さいラスターを管理する場合には活用できます。

k3sベースのrancherのインストール方式

既存の「RKEクラスター」と「Dockerコンテナー」ベースのインストール方式以外に、k3sクラスターベースのrancherのインストール方式もサポート開始です。
メリットとしては、下記となります。
・構築作業は、RKEクラスターベースの構築より、簡単になりました。
・k3sのメモリ使用量は、Vanilla Kubernetesの半分ぐらいになり、またHAクラスター構成は、２ノードからも可能になりました。
・クラスターのストレージは、etcd以外にPostgreSQL、MySQLなどもサポートしておりますので、既にDB環境がお持ちの場合は、そのまま活用できます。

アーキテクチャ構成は下記となります。