Kubernetes のコストを最適化するにはどうすればよいでしょうか?

この投稿では、Kubernetes コストを最適化するための課題といくつかのベスト プラクティスを紹介します。

たとえば、1. Pod の Quality of Service (QoS) を設定する、2. LimitRanges、3. ResoureQuotas などです。クラウド コンテナは柔軟性を提供し、仮想オペレーティング システムや仮想化ソフトウェアなどを気にすることなく、クラウド、仮想、ベアメタル環境など、あらゆる環境にアプリケーションをシームレスに移行できます。管理の簡素化、迅速な配信、俊敏性により、クラウド開発者はコンテナ化へと傾いています。 Kubernetes (別名 k8s。k8s の意味を知りたい場合は、これは 8 文字の「Kubernetes」を置き換えたものです) は、クラウド開発者に広く採用されている、人気があり広く採用されているオープン ソースのコンテナ化プラットフォームです。最近の CNCF レポートによると、Kubernetes 開発者は世界中で 67% 増加しており、その人気を物語っています。

残念なことに、Kubernetes の採用と使用の急増により、企業の IT インフラストラクチャ予算が犠牲になっています。企業は、計画された目標の達成に役立たない無意味なリソースに、Kubernetes 支出の約 80% を無駄に費やしている可能性があります。このブログ投稿で課題と最適化について見てみましょう。

Kubernetes のコスト最適化の課題 全体的な課金 クラスターには複数のノードが含まれます。各ノードには異なる数のコンテナが含まれます。クラスター内に存在するすべてのノードが同じアプリケーションに属しているわけではありません。各ノードは異なるチームによって処理され、異なるアプリケーションに使用される場合があります。ただし、クラウド サービス プロバイダーは、クラスター全体または複数のクラスターごとに料金を請求します。コンテナがノードにデプロイされた時点で課金が開始されます。 Kubernetes クラスターのメンテナンス、ソフトウェア ライセンス、災害復旧などには、1 日あたり 2.4 ドルの追加料金がかかります。

ショーバックとチャージバックはほぼ不可能です。これら 2 つのプロセスは、企業が財務的に責任を持つために非常に重要です。ショーバックは、特定の期間におけるクラウド リソースの使用に対する支出をビジネス ユニットに可視化するプロセスですが、課金は行われません。チャージバックとは、使用量に基づいて事業部門に通知し、使用量に応じて課金するプロセスです。 Kubernetes クラスターでは、エンジニアがコストを追跡するのに役立つタグを使用することはできません。

私たちがすべてのお金を投資するとき、それが私たちが計画した機能/出力のリストを満たす場合にのみ価値があります。それが支出面だけに留まり、生産とは関係がない場合は、この異常の根本的な原因を突き止める時期です。しかし、Kubernetes クラスターの場合、物事は思ったほど単純ではありません。各コンテナは企業内の異なるチームによって使用される可能性があり、これらのチームは異なる作業を行っている可能性があるためです。同時に、各チームのインフラストラクチャ予算とリソースコストの割り当ても異なります。

マルチクラウドの採用 最近のガートナーの調査によると、回答者の 81% が、ベンダー ロックインの克服、リソース割引、災害復旧などのさまざまなメリットを得るために 2 つ以上のクラウド サービス プロバイダーを使用していると回答しています。Kubernetes クラスターには、AWS、Azure、GCP などのさまざまなクラウド サービス プロバイダーのワークロードが含まれるため、コスト異常検出と Kubernetes コスト最適化プロセスの複雑さがさらに増します。

動的自動スケーリング クラウド エンジニアが Kubernetes クラスターを選択する主な理由は、その自動スケーリング機能です。 Kubernetes は、使用需要に基づいてスケールアップおよびスケールダウンし、リソースがピーク時と谷間のコンピューティング ニーズを満たすことができるようにします。水平自動スケーリングでは、コンテナの数が 1 日で 2 個から 20 個に増加する可能性があります。この予測不可能な自動スケーリングにより、Kubernetes コストの最適化は複雑になります。

Kubernetes コスト最適化のベスト プラクティス 予期しない経費を最適に削減する方法を見てみましょう。

ポッドのサービス品質 (QoS) Kubernetes クラスターは、クラウド実践者にポッドに異なる QoS クラスを設定する柔軟性を提供します。これに基づいて、クラウド実践者にとってポッドのスケジュール設定と削除が容易になります。保証型、バースト型、ベストエフォート型の 3 種類があります。

保証: クラウド エンジニアが極めて重要なアプリケーションを処理できる Pod を必要とする場合、それを保証された QoS クラスとして構成できます。したがって、CPU とメモリの制限と要件は同じに設定されています。名前が示すように、最小限のリソースを提供することを保証します (需要はリソースの最小量、制限は使用できるリソースの最大量です)。

バースト可能: vCPU またはメモリの制限が需要を超えるか、まったく同じでない場合、ポッドにはスケーラブル QoS クラスが割り当てられます。したがって、コンピューティングの需要が増加したときにこれらのリソースを利用できます。

ベストエフォート: 制限も要件も設定されていない場合は、ベストエフォート QoS カテゴリに分類されます。クラウド エンジニアは、重要でないアプリケーションにこれを使用できます。

明らかにわかるように、最初にベストエフォート ポッドが削除され、次にバースト可能ポッド、最後に保証付きポッドが削除されています。

ResourceQuotas と LimitRange これまで見てきたように、Kubernetes クラスターはさまざまなチームによって共有されます。あるチームがポッドの大部分を使用し、他のチームのリソースに負担がかかる可能性があります。名前空間レベルでのポッド制限により、この問題を軽減できます (名前空間は仮想クラスターです)。リソース クォータは、名前空間内での Pod の使用を制限する方法です。

Kubernetes 管理者は、名前空間ごとにリソース クォータを作成します。ユーザーが名前空間内で Pod を作成または更新するたびに、リソース クォータ システムは制限を超えていないかどうかを確認します。制限を超えると、「403 FORBIDDEN」エラーが返され、操作が拒否されます。

LimitRange は、リソース制限の実装に役立つ別のポリシーです。名前が示すように、名前空間内の「制限とリクエスト」の範囲を制限します。