スケールでのSUSE Rancher Primeの調整とベストプラクティス

一般的なRancherの推奨事項に示されている推奨事項は、大規模な環境において特に重要です。

EtcdはKubernetesおよびRancherのバックエンドデータベースです。データベースは、最終的に保存できる単一のKubernetesリソースタイプの数に制限に直面する可能性があります。正確な制限はさまざまな要因に依存します。しかし、経験上、単一のリソースタイプのオブジェクト数が60,000を超えると、パフォーマンスの問題が頻繁に発生することが示されています。そのタイプはしばしば`RoleBinding`です。

これはRancherでは典型的で、多くの操作が上流クラスターで新しい`RoleBinding`オブジェクトを副作用として作成します。

アップストリームクラスターの`RoleBindings`の数を以下の方法で減らすことができます：

ユーザーが50人以上いる場合は、外部認証プロバイダーを設定する必要があります。これは、より良いパフォーマンスのために必要です。

外部認証を設定した後は、個々のユーザーではなくグループに権限を割り当てることを確認してください。これにより、`RoleBinding`オブジェクトの数が減少します。

特定の設定が生成する`RoleBinding`オブジェクトの数を予測することは複雑です。しかし、以下の考慮事項が大まかな推定を提供することができます：

Rancherは2つのKubernetesアプリリソースを使用します：apps.projects.cattle.io`と`apps.cattle.cattle.io。レガシーアプリは`apps.projects.cattle.io`で表され、以前のクラスターマネージャーUIで導入され、現在は時代遅れです。現在のアプリは`apps.catalog.cattle.io`で表され、それぞれのクラスターのクラスターエクスプローラーUIにあります。`Apps.cattle.cattle.io`アプリは、データがダウンストリームのクラスターに存在するため、アップストリームのクラスターのリソースを解放するので好ましいです。

クラスター・マネージャーUIに表示される残りのレガシーアプリを削除し、クラスター・エクスプローラーUIのアプリに置き換えるべきです。新しいアプリはクラスター・エクスプローラーUIでのみ作成してください。

認可されたクラスター・エンドポイント（ACE）は、Rancherが提供するRKE2およびK3sクラスターのKubernetes APIへのアクセスを提供します。有効にすると、ACEはクラスタ用に生成されたkubeconfigファイルにコンテキストを追加します。このコンテキストは、クラスターへの直接エンドポイントを使用し、Rancherをバイパスします。これは、仲介されていないAPIアクセスが許可されるか好ましい場合に、Rancherへの負荷を軽減します。詳細情報と設定手順については、Authorized Cluster Endpointを参照してください。

Rancherのロジックの大部分は、イベントハンドラーで発生します。これらのイベントハンドラーは、オブジェクトが更新されるたび、またRancherが起動されるときにオブジェクト上で実行されます。さらに、Rancherがキャッシュを同期する際に、10時間ごとに実行されます。スケールされたセットアップでは、これらのスケジュールされた実行は大きなパフォーマンスコストを伴います。なぜなら、すべてのハンドラーがすべての適用可能なオブジェクトで実行されるからです。ただし、スケジュールされたハンドラーの実行は、`CATTLE_SYNC_ONLY_CHANGED_OBJECTS`環境変数を使用して無効にできます。10時間ごとにリソース割り当てのスパイクが見られる場合、この設定が役立ちます。

`CATTLE_SYNC_ONLY_CHANGED_OBJECTS`の値は、以下のオプションのカンマ区切りリストであることができます。これらの値は、ハンドラーおよびコントローラーのタイプを指します（ハンドラーを含み実行する構造体）。コントローラーのタイプを変数に追加すると、そのコントローラーのセットがキャッシュの再同期の一部としてハンドラーを実行しないようになります。

要するに、10時間ごとにCPU使用率のピークが見られる場合は、`CATTLE_SYNC_ONLY_CHANGED_OBJECTS`環境変数をRancherのデプロイメントに追加してください（`spec.containers.env`リスト内）し、値を`mgmt,user`に設定します。

Rancherはアップストリームクラスターに対して非常に要求が厳しいため、特にスケールが大きい場合は、クラスターの設定とノードに対する完全な管理権限を持っているべきです。リソース消費のルート原因を特定するために、標準的なLinuxのトラブルシューティング手法とツールを使用してください。これにより、Rancher、Kubernetes、またはオペレーティングシステムのコンポーネントが問題を引き起こしているかどうかを区別するのに役立ちます。

管理されたKubernetesサービスはKubernetesクラスターをデプロイして運用するのを容易にしますが、高スケールのシナリオではアップストリームクラスターには推奨されません。管理されたKubernetesサービスは、通常、個々のノードやサービスに対する設定や洞察へのアクセスを制限します。

大規模なユースケースにはRKE2を使用してください。

高可用性を提供するために、Kubernetesは異なるゾーンでノードと制御コンポーネントを実行するように設計されています。ただし、ノードと制御プレーンコンポーネントが異なるゾーンにある場合、ネットワークトラフィックが遅くなる可能性があります。

RancherコンポーネントとKubernetes API間のトラフィックは、低レイテンシに特に敏感であり、ノード間のetcdトラフィックも同様です。

パフォーマンスを向上させるために、すべてのアップストリームクラスターのノードを同じ場所で実行してください。特に、etcdノードとRancher間の遅延ができるだけ低くなるようにしてください。

ローカルのKubernetesクラスターを最新の状態に保つべきです。これにより、クラスターには利用可能なすべてのパフォーマンス向上とバグ修正が適用されていることが保証されます。

etcdはKubernetesとRancherのバックエンドデータベースです。それはRancherのパフォーマンスに非常に重要な役割を果たします。

etcdのパフォーマンスに対する主なボトルネックは、ディスクとネットワークの速度です。etcdは、高速ネットワーク設定と高い入出力回数/秒（IOPS）を持つSSDを備えた専用ノードで実行する必要があります。etcdのパフォーマンスに関する詳細情報は、 遅いetcdのパフォーマンス（パフォーマンステストと最適化）および大規模インストールのためのetcdの調整を参照してください。ディスクに関する情報は、インストール要件にもあります。

etcdは正確に3つのノードで実行するのが最良であり、ノードを追加すると操作速度が低下します。これは一般的なスケーリングアプローチに反するかもしれませんが、etcdの レプリケーションメカニズムによるものです。

etcdのパフォーマンスは、ノード間のネットワーク遅延によっても悪影響を受け、ネットワーク通信が遅くなります。etcdノードはRancherノードと一緒に配置する必要があります。

高スケールでは、Rancherはアップストリームクラスターからブラウザで実行されているUIコンポーネントにより多くのデータを転送し、これらのコンポーネントもより多くの処理を行う必要があります。

最良のパフォーマンスを得るために、ハードウェアを実行しているホストがこれらの要件を満たしていることを確認してください：