14 RKE2 #
RKE2の公式ドキュメントを参照してください。
RKE2は、以下によってセキュリティとコンプライアンスに重点を置いた、完全準拠のKubernetesディストリビューションです。
クラスタがCIS Kubernetes Benchmark v1.6またはv1.23に合格できるデフォルト値と設定オプションを、オペレータの介入を最小限に抑えながら提供する
FIPS 140-2準拠を可能にする
trivyを使用し、コンポーネントを定期的にスキャンしてRKE2ビルドパイプラインにCVEがないかどうかを確認する
RKE2は、コントロールプレーンコンポーネントを、kubeletによって管理される静的Podとして起動します。組み込みコンテナランタイムはcontainerdです。
メモ: RKE2はRKE Governmentとしても知られます。これは、RKE2が現在ターゲットにしている別のユースケースと分野を表すためです。
14.1 RKE2とK3s #
K3sは完全準拠の軽量なKubernetesディストリビューションであり、エッジ、IoT、ARMや、K8sのクラスタ技術では博士号を取得できそうにない状況に焦点を合わせています。
RKE2は、RKEの1.xバージョン(以下「RKE1」)とK3sの両方の長所を兼ね備えています。
RKE2は、K3sから使いやすさ、操作のしやすさ、およびデプロイメントモデルを継承しています。
RKE1から継承しているのは、アップストリームのKubernetesとの緊密な連携です。K3sはエッジデプロイメントに合わせて最適化されているため、アップストリームのKubernetesとは各所で異なりますが、RKE1とRKE2はアップストリームと緊密な連携を保つことができます。
14.2 SUSE EdgeでのRKE2の用途 #
RKE2はSUSE Edgeスタックの基礎を成す部分です。RKE2はSUSE Linux Micro (第7章 「SLE Micro」)上に位置し、Edgeワークロードを最小限のフットプリントでデプロイするために必要な標準Kubernetesインタフェースを提供します。
14.3 ベストプラクティス #
14.3.1 インストール #
RKE2をSUSE Edgeスタックの一部としてインストールする場合に推奨される方法は、Edge Image Builder (EIB)を使用することです。RKE2をデプロイするようにEIBを設定する方法の詳細については、EIBのドキュメント(第9章 「Edge Image Builder」)を参照してください。
EIBは十分な柔軟性を備えているため、RKE2のバージョン、サーバ、またはエージェント設定の指定など、RKE2で要求されるあらゆるパラメータをサポートすることができ、Edgeのすべてのユースケースに対応できます。
Metal3に関連する他のユースケースでも、RKE2が使用およびインストールされます。このような特定のケースでは、Cluster API Provider RKE2によって、Edgeスタックを使用してMetal3でプロビジョニングされるクラスタにRKE2が自動的にデプロイされます。
このような場合、関係する各種のCRDにRKE2設定を適用する必要があります。RKE2ControlPlane
CRDを使用して異なるCNIを提供する方法の例は、次のようになります。
apiVersion: controlplane.cluster.x-k8s.io/v1alpha1
kind: RKE2ControlPlane
metadata:
name: single-node-cluster
namespace: default
spec:
serverConfig:
cni: calico
cniMultusEnable: true
...Metal3のユースケースの詳細については、第8章 「Metal3」を参照してください。
14.3.2 高可用性 #
HAデプロイメントの場合、EIBはMetalLB (第17章 「MetalLB」)とEndpoint Copier Operatorを自動的にデプロイして設定し、RKE2 APIエンドポイントを外部に公開します。
14.3.3 ネットワーキング #
EdgeスタックでサポートされているCNIはCiliumで、オプションでmeta-plugin Multusを追加できますが、RKE2ではほかにもいくつかのプラグインがサポートされています。
14.3.4 ストレージ #
RKE2は、どのような種類の永続ストレージクラスやオペレータも提供していません。複数のノードにまたがるクラスタの場合は、Longhorn (第15章 「Longhorn」)を使用することをお勧めします。