Kubernetes パフォーマンス最適化の 7 つの簡単なヒント

[51CTO.com クイック翻訳] Kubernetes は複雑なツールです。ほとんどの複雑なツールと同様に、Kubernetes から最高のパフォーマンスを引き出すのは難しい場合があります。ほとんどの Kubernetes ディストリビューション自体は、最大のパフォーマンスが得られるように調整されていません (調整されている場合でも、環境にとってパフォーマンスが最適ではない場合があります)。

[[319734]]

これを踏まえて、Kubernetes のパフォーマンス最適化手法をいくつか紹介します。この記事では、クラスターの構築を始めたばかりの方にも、すでに本番環境をお持ちの方にも、Kubernetes のパフォーマンスを向上させるための簡単な操作を中心に紹介します。

新しいワーカー ノードを作成する前に、既存のワーカー ノードにリソースを追加します。

Kubernetes のパフォーマンスを向上させる最も明白な方法は、おそらくクラスターにワーカーノードを追加することです。ワーカーの数が増えるほど、ワークロードを実行するために利用できるリソースも増えます。また、ノード数が増えると、多くのノードに障害が発生してワークロードが失敗し始める可能性が減るため、可用性も向上します。

ただし、ワーカー ノードの使用率を最大化したい場合は、新しいワーカー ノードを作成するのではなく、既存のワーカー ノードにメモリと CPU リソースを追加した方がよい結果が得られる可能性があります。つまり、それぞれ 8 GB のメモリを搭載したノードを 40 個持つよりも、それぞれ 16 GB のメモリを搭載したノードを 20 個持つ方が適切です。

これには2つの理由があります。まず、ホスト オペレーティング システムにより、ノードごとに一定量のオーバーヘッドが発生します。ノードが少ないということは、このように無駄になるリソースが少なくなることを意味します。 2 番目に、ノードの数が増えるほど、スケジューラ、kube-proxy、その他のコンポーネントがすべてを追跡するのにかかる作業が増えます。

当然のことながら、可用性を考慮し、最小数のワーカー ノードが可用性の目標を満たすようにする必要があります。しかし、そのしきい値を超えると、ノードの総数を増やそうとするのではなく、各ノードにできるだけ多くのリソースを割り当てることで、全体的なパフォーマンスを向上させることができます。ただし、極端なことは避けてください (たとえば、1 つのノードに 24 TB のメモリは必要ないはずです)。ノードに障害が発生すると、それらのリソースが失われる可能性があるためです。

もちろん、ノードのリソース割り当てを決定する際に柔軟性があるかどうかは分かりません。クラウドで実行される仮想マシンであれば、必要な数のリソースを割り当てることができます。オンプレミスの VM または物理サーバーの場合は、少し複雑になります。

複数のマスターノードの使用

Kubernetes クラスターで複数のマスターノードを使用する主な理由は、高可用性を実現することです。マスター ノードの数が多いほど、すべてのマスター ノードが故障してクラスターがダウンする可能性が低くなります。

ただし、マスター ノードを追加すると、マスター ノードでホストされる重要な Kubernetes コンポーネント (スケジューラ、API サーバー、Etcd など) に提供されるホスティング リソースが増えるため、パフォーマンスも向上します。 Kubernetes は、すべてのマスター ノードの集合的なリソースを使用してこれらのコンポーネントをサポートします。

したがって、1 つ以上のマスター ノードを追加することは、Kubernetes クラスターのパフォーマンスを向上させる良い方法です。

ワーカーノードのスコアリング制限を設定する

Kubernetes スケジューラの仕事の 1 つは、ワーカー ノードを「スコアリング」することです。つまり、どのワーカー ノードがワークロードの処理に適しているかを決定します。数十以上のワーカーノードを持つクラスターでは、スケジューラはすべてのワーカーノードをチェックするのに時間を浪費することになります。

この非効率性を回避するには、percentOfNodesToScore パラメータを 100 未満のパーセンテージに設定します。そうすると、スケジューラは指定したノードのサブセットのみをチェックします。

リソースクォータの設定

リソース クォータを設定することは、特に複数のチームで共有される大規模なクラスターにおいて、Kubernetes のパフォーマンスを向上させるシンプルで非常に効果的な方法です。リソース クォータは、名前空間が使用できる CPU、メモリ、およびストレージ リソースの量を制限します。

したがって、クラスターを複数の名前空間に分割し、各チームに異なる名前空間を割り当て、リソース クォータを設定すると、すべてのワークロードに公平なリソースが配分されるようになります。

リソース クォータ自体はパフォーマンスを最適化する方法ではなく、むしろ、ノイジー ネイバー問題を解決する方法のようなものです。ただし、各名前空間がタスクを適切に実行するために必要なリソースを備えていることを確認するのに役立ちます。

制限を設定する

ワークロードによって消費されるリソースを制限したいが、そのワークロードが他のワークロードと同じ名前空間で実行される場合はどうすればよいでしょうか。ここで制限スコープが役に立ちます。

リソース クォータは、各名前空間が消費できるリソースの量を制限し、スコープは各ポッドまたはコンテナーに対して同じことを行います。

簡単にするために、ほとんどの場合、名前空間とリソース クォータを使用してワークロードを分離することが推奨されます。ただし、それが現実的でない場合は、スコープを制限することで、各ポッドまたはコンテナがタスクを実行するために必要なリソースを確保できるようになります。

エンドポイントスライスの設定

エンドポイント スライスは、サービスとポートの組み合わせに基づいてネットワーク エンドポイントをグループ化できる、あまり知られていない Kubernetes 機能です。一度セットアップされると、kube-proxy はトラフィックのルーティング方法を決定するときにエンドポイント スライスを参照します。

エンドポイントの数が多い環境では、エンドポイント スライシングにより、クラスター内でトランジット トラフィックをルーティングするために kube-proxy が実行する必要がある作業量が削減され、パフォーマンスが向上します。

最小限のホストオペレーティングシステムを使用する

最後になりましたが、基本的でありながら効果的なヒントは、Kubernetes クラスターをホストするオペレーティング システムが可能な限り最小限であることを確認することです。 Kubernetes の実行に必要のない追加コンポーネントはリソースの無駄となり、クラスターのパフォーマンスを低下させます。

ホスト オペレーティング システムを選択できるかどうかは、使用する Kubernetes ディストリビューションによって異なります。選択肢がある場合は、リソースを最も少なく消費する Linux ディストリビューションを選択してください。

元のタイトル: Kubernetes パフォーマンス最適化の 7 つの簡単なヒント

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。