本記事は、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環境がお持ちの場合は、そのまま活用できます。
アーキテクチャ構成は下記となります。
詳細のドキュメントはこちらをご参照ください。
Shibboleth認証プロバイダーの対応
Shibboleth認証プロバイダー経由で、Rancherにログインすることが可能になりました。
詳細のドキュメントはこちらをご参照ください。
ユーザーグループへのグローバルロール権限の付与
ユーザーグループにグローバルロール権限を付与することが可能になりました。
※この機能は、ユーザーグループの作成管理機能を持つ認証プロバイダーに限って、利用できます。
詳細のドキュメントはこちらをご参照ください。
サポート対象OS追加
下記のOSがサポート対象となりました。
・SLES 12 SP5（SUSE Linux Enterprise Server 12 SP5）
・Oracle Linux 7.7
OPA GateKeeper統合（体験版）、新しい管理UI(体験版)
★体験版の為、今後仕様大きく変更される可能性が高いです。★
OPA GateKeeperは、Kubernetes環境におけるポリシの適用とガバナンス強化を支援するCNCF配下のOSSプロジェクトです。
V2.4に統合され、クラスターに対しての制約テンプレート定義と制約定義を、UIから管理できるようになりました。
・「Try Dashboard」ボタン押下で、新しい管理UIに遷移させます。
・OPA GateKeeperの管理メニューは、左側にあります。
・コンテナーイメージのリポジトリなどの制約テンプレートをUIから管理できます。
おわり
V2.4.0の主要な機能を説明と検証させて頂きました。詳細な変更情報は、リリースノートをご参照ください。
今後、エッジ向けの大量なクラスターをグループ化して管理する機能や、Rioとの統合機能は、新しいバージョンでリリースされていきます。