Kubernetes Compute Resources Explained

Kubernetes コンピュートリソースの説明

  • ITOps・DevOps
6分で読めます 更新日 Oct 15, 2019

ポイント: Kubernetes コンピュートリソースは、ポッドの CPU とメモリの割り当てを管理し、効率的なリソースの使用を確保します。このガイドは、アプリケーションのパフォーマンスを維持するためのリソースリクエスト、制限、およびサービスの質 (QoS) クラスを概説します。

  • コンピュートリソースには、ポッド用の測定可能な CPU およびメモリが含まれます。
  • QoS クラスは、リソースの可用性に基づいてポッドの終了優先度を決定します。

Kubernetes の世界では、リソースには 2 種類あります:

  • コンピュートリソース、CPU(ユニット)やメモリ(バイト)など、測定可能なリソースです。
  • API リソース、ポッドやサービスなど、単なる K8s オブジェクトです。

この記事では、コンピュートリソースについて説明します。

サービスの質 (QoS)

デフォルトでは、ポッドをデプロイすると、ポッドコンテナは基本的にそのワーカーノードインスタンスで利用可能なコンピュートリソースを消費します。それは素晴らしいことです—何も心配する必要はありません、正しいですか?

一方のコンテナが他のコンテナよりも多くの CPU およびメモリリソースを消費した場合はどうなるでしょうか?ノード上で実行されている他のポッドコンテナはどうなりますか?リソース不足により、一部のコンテナが失敗する可能性が高くなります。もし私たちが質の悪いコードベースのアプリケーションを運用している場合、それはビジネスに影響を与える可能性があります。

この問題を解決するために、Kubernetes にはリソースリクエストと制限があり、ポッドコンテナが消費するリソースの量を制御し、サービスの質 (QoS) の最高レベルを確保します。QoS(リクエストと制限)がポッドだけでなく、名前空間にも適用されることを指摘することが重要です。これにより、複数の開発チームがクラスターにデプロイする場合、サービスの優先度に応じてリソース消費を制御できます。

リソースリクエストと制限の仕組み

基本的に、ワーカーノードまたはインスタンスはポッドが使用する全体のコンピュートリソースの一部をのみ割り当てます。そのため、その部分はノード上でスケジュールされたすべてのポッドで共有されます。Kubernetes スケジューラは、インスタンス上で実行されているコンテナのすべてのコンピュートリソースの合計が、ポッドのために割り当てられた全体のリソースを超えないようにします。リクエストと制限の違いを知ることが重要です。

  • リクエストは、Kubernetes がポッドに保証するリソースの量です。
  • 制限は、Kubernetes がポッドに許可するリソースの最大量です。

ポッドスケジューリングはリクエストに基づいて行われますが、ポッドとそのコンテナは指定された制限を超えることは許可されません。ポッドをデプロイすると、容量チェックにより、要求されたコンピュートリソースの合計がノードが割り当てられることができる量を超えていないことが確認されます。

リクエストと制限の施行方法

リクエストと制限の施行方法は、リソースが圧縮可能か圧縮不可能かに基づいています。圧縮可能なリソースは制限される可能性がありますが、圧縮不可能なリソースはそうではありません。たとえば、CPU は圧縮可能と見なされ、メモリは圧縮不可能です。

ポッドは、リクエストされた CPU の量を保証されます。他のポッドが実行されている場合、より多くの CPU を得るかもしれませんし、得ないかもしれません。また、制限を超えた場合、スロットリングされます。ポッドメモリリクエストも保証されますが、ポッドがメモリ制限を超えた場合、最も多くのメモリを使用しているコンテナ内のプロセスが終了します。ポッドは終了しませんが、メモリを使用しているコンテナ内のプロセスが終了します。

ノードがコンピュートリソースを完全に使い果たしている場合があります。実行中のすべてのコンテナの合計コンピュートリソースがノード自体のコンピュートリソースを超えています。このような極端な場合、ノード上で実行中のコンテナを終了し始める必要があります。理想的には、まず重要度の低いコンテナを削除してリソースを解放します。それでは、すべてのリソースが枯渇した場合、Kubernetes にどのポッドを最初に終了させるかをどのように伝えるのでしょうか?QoS クラスを使用します。

3 つのクラス—ベストエフォート、保証、バースト可能—を指定して、どのポッドを最初に終了させるかをシステムに指示できます。

  • ベストエフォート。 リクエストや制限が設定されていないポッドで、リソース枯渇時に最初に終了されます。
    Containers:
  name: foo
    Resources:
  name: bar
    resources:
  • 保証。すべてのリソース(CPU およびメモリ)についてリミットと(オプションで)リクエストが設定されているポッドで、値は同じです。これらのポッドは高優先度であり、制限を超え、かつ終了すべき優先度の低いポッドが存在しない場合のみ終了されます。
    containers:
  name: pong
    resources:
      limits:
        cpu: 100m
        memory: 100Mi
      requests:
        cpu: 100m
        memory: 100Mi
  • バースト可能。1 つ以上のリソース(CPU および/またはメモリ)について、リクエストと(オプションで)制限が設定されているポッドで、値は同じではありません。これらのポッドは、終了すべきベストエフォートポッドがない場合に終了されます。
    containers:
  name: foo
    resources:
      limits:
        memory: 1Gi

  name: bar
    resources:
      limits:
        cpu: 100m

アプリケーションの稼働時間はビジネス SLA の一部であるため、これらのアプリケーションに適切なリソースを適用することが重要です。これらのリソースを適切に計画する方法を理解することは、ビジネスにとって重要です。リクエストと制限を使用すると、チームは重要なアプリケーションにリソースを適切に割り当てることができ、QoS はワーカーノードでリソース枯渇が発生した場合のアプリケーションのライフサイクルを制御するのに役立ちます。チームは名前空間レベルでこれらのリクエストと制限を定義することもできるため、リソースは開発チームに基づいて分割できます。

Kubernetes ガイド

  1. Kubernetes (K8s) とは?Kubernetes 基礎チュートリアル
  2. Kubernetes クラスター効率を向上させるためのベストプラクティス
  3. ベストプラクティス:Kubernetes 用にアプリケーションをアーキテクチャする方法
  4. Kubernetes Pods:入門
  5. Kubernetes ReplicaSets:簡単な紹介
  6. Kubernetes デプロイメントの完全な説明
  7. Kubernetes DaemonSets の使用と管理
  8. Kubernetes サービスの仕組み
  9. Kubernetes ポート、TargetPort、および NodePort の使用
  10. Kubernetes での ConfigMaps の作成と使用
  11. Kubernetes Secrets の紹介
  12. Kubernetes ネットワーキングの基本
  13. Kubernetes Ingress の説明
  14. Kubernetes Helm チャートの紹介
  15. Kubernetes オペレーターパターンとは?
  16. Kubernetes で StatefulSet として PostgreSQL をデプロイ
  17. Kubernetes カスタムリソース定義 (CRDs) の説明
  18. クラウドネイティブアプリケーションのための 3 つの Kubernetes パターン
  19. Kubernetes コンピュートリソースの説明
  20. DevOps パイプラインのための Kubernetes セキュリティ
  21. Kubernetes と Spinnaker を使用した継続的デリバリー
  22. Kubernetes マルチクラスター:使用方法と理由
  23. Kubernetes 監視:包括的ガイド
  24. Kubernetes vs Docker:簡単な比較
  25. Kubernetes vs Docker Swarm:コンテナオーケストレーションツールの比較
  26. Kubernetes vs OpenShift:違いは何か?
  27. Kubernetes 認証:どのようにして認定を取得するか、なぜ取得するか

これらの投稿は私自身の意見であり、BMCの立場、戦略、または意見を必ずしも表すものではありません。

ITOps・DevOpsの関連記事

The Briefを購読する

このオファーに登録することで、あなたはBMCのプライバシーポリシーを読み、同意したことを確認します。

ありがとう

あなたはThe Briefに登録されました
The Briefはメインフレームとエンタープライズオーケストレーション—BMC AMIとControl-M—および、両者に関するアナリストの研究、顧客の展開、イベントをカバーしています。