Help us understand the problem. What is going on with this article?

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

本記事は、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]ボタンをクリックします。
image.png

image.png

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

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

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

image.png
image.png

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

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

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

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

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

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

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

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

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

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:3台)となります。
image.png

・Rancherで、import方式でクラスターを作成し、k3sクラスター上にimport用のkubectlコマンドを実行します。
image.png
image.png
・インポートしたk3sを確認します。
 <クラスターのDashboard>
image.png
 <クラスターのノード一覧>
image.png

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

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

・「Kubernetes Version」項目に、最新のバージョンを選択し、「Save」ボタンをクリックします。
 その他の設定項目は必要に応じて設定してください。
  「Drain Control Plane Nodes」項目:アップグレード前にDrain実施要否
  「Drain Worker Nodes」項目:アップグレード前にDrain実施要否
  「Control Plane Concurrency」項目:同時にアップデート可能のNode数(ローリングアップデートのバッチサイズ)
  「Worker Concurrency」項目:同時にアップデート可能のNode数(ローリングアップデートのバッチサイズ)
image.png
・クラスターがUpgradingモードに入り、しばらく待つと、クラスターが選択したバージョンに更新されます。
image.png
image.png

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

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ノード:3台
 control Planeノード:3台
 workerノード:3台
image.png

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

・「Advanced Options」の設定ところに、Workerノードの1回の最大同時アップデート数(ローリングアップデータのバッチサイズ)を設定します。
 「Maxiumum Worker Nodes Unavailable」(最大同時アップデート数):1
 「Drain nodes」(アップデート前のDrain処理要否):no
image.png
・control Planeノードの1回の最大同時アップデート数は、「Edit as YAML」ボタンから開くyaml設定画面から設定します。
 「max_unavailable_controlplane」(最大同時アップデート数):1 ※デフォルト値のまま
image.png

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

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

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

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

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

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に設定します。
 クラスター構築の詳細手順はこちらをご参照ください。
image.png
・作成したクラスターの各ステータスは下記となります。
<ノード情報>:1ノードのみ
image.png
<Kubernetes Version>:v1.15.11
<1ノードあたり最大のPOD数>:110
image.png
<defaultプロジェクト配下のワークロード>:なし
image.png

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

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

・クラスターのアップグレードと、クラスター設定変更処理を同時に行います。
 クラスター設定変更の詳細手順はこちらをご参照ください。
 「k8sバージョン情報」に更新を加える為、クラスター編集画面に、「Kubernetes Version」をv1.15.11からv1.16.8に変更します。
image.png
 「クラスター設定情報」に更新を加える為、「Edit as YAML」ボタンから開くyaml設定画面に、kubelet設定のところに、「1ノードあたり最大POD数:250」のパラメータを追加します。
image.png

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

ロールバックを実施

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

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

・「etcdデータ」が、クラスター構築直後の状態に戻ったこと確認します。
<defaultプロジェクト配下のワークロード>:なし
image.png
・「k8sバージョン情報」が、クラスター構築直後の状態に戻ったこと確認します。
<1ノードあたり最大のPOD数>:110
・「クラスター設定情報」が、クラスター構築直後の状態に戻ったこと確認します。
<Kubernetes Version>:v1.15.11
image.png

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バージョン指定
image.png
image.png

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

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

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

その他

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

スケーラビリティの改善

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

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

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

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

詳細のドキュメントはこちらをご参照ください。

Shibboleth認証プロバイダーの対応

Shibboleth認証プロバイダー経由で、Rancherにログインすることが可能になりました。
image.png
詳細のドキュメントはこちらをご参照ください。

ユーザーグループへのグローバルロール権限の付与

ユーザーグループにグローバルロール権限を付与することが可能になりました。
※この機能は、ユーザーグループの作成管理機能を持つ認証プロバイダーに限って、利用できます。
image.png
image.png
詳細のドキュメントはこちらをご参照ください。

サポート対象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に遷移させます。
image.png
・OPA GateKeeperの管理メニューは、左側にあります。
image.png
・コンテナーイメージのリポジトリなどの制約テンプレートをUIから管理できます。
image.png

おわり

V2.4.0の主要な機能を説明と検証させて頂きました。詳細な変更情報は、リリースノートをご参照ください。

今後、エッジ向けの大量なクラスターをグループ化して管理する機能や、Rioとの統合機能は、新しいバージョンでリリースされていきます。

cheng_rancher
Field Engineer at Rancher Labs. ■Favorite technologies: Rancher, Kubernetes, AWS, Docker, Jenkins. ■Certifications: AWS SAP, CKA, CKAD. http://slack.rancher.jp/
http://www.rancher.co.jp/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした