Azure Kubernetes Service (AKS) でリソースを管理するアプリケーション開発者のベスト プラクティス

Azure Kubernetes Service (AKS) でアプリケーションを開発して実行する際に、考慮すべき主な領域がいくつかあります。 アプリケーション デプロイの管理方法によっては、提供するサービスのエンド ユーザー エクスペリエンスに悪影響を与える可能性があります。

この記事では、アプリケーション開発者の観点からクラスターとワークロードを実行することに焦点を当てています。 管理のベスト プラクティスについては、Azure Kubernetes Service (AKS) での分離とリソース管理に関するクラスター オペレーターのベスト プラクティスに関するページを参照してください。

この記事では、次のトピックについて説明します。

ポッドのリソースの要求と制限を定義する

ベスト プラクティスのガイダンス

YAML マニフェストですべてのポッドにポッドの要求と制限を設定します。 AKS クラスターで "リソース クォータ" を使用しており、これらの値を定義していない場合に、デプロイが拒否される場合があります。

ポッドの要求と制限を使用して、AKS クラスター内のコンピューティング リソースを管理します。 ポッドの要求と制限によって、ポッドに割り当てるコンピューティング リソースを Kubernetes スケジューラに通知します。

ポッドの CPU とメモリ要求

"ポッドの要求" により、ポッドに通常必要な一定量の CPU およびメモリを定義します。

ポッド仕様で、上記の情報に基づいてこれらの要求と制限を定義することが重要です。 これらの値を含めないと、Kubernetes スケジューラで、スケジュールの決定を支援するためにアプリケーションに必要なリソースを考慮できません。

アプリケーションのパフォーマンスを監視し、ポッドの要求を調整します。 ポッドの要求を過小評価すると、ノードのスケジュールが過剰になるため、アプリケーションのパフォーマンスが低下するおそれがあります。 要求を過大に見積もると、アプリケーションでスケジューリングがより困難になるおそれがあります。

ポッドの CPU とメモリの制限

"ポッドの制限" により、ポッドで使用できる CPU とメモリの最大量が設定されます。 "メモリの制限" により、リソース不足でノードが不安定になったときに、どのポッドを削除するかを定義します。 適切な制限が設定されていないと、リソース不足が解消するまでポッドが削除されます。 ポッドは定期的に "CPU の制限" を超えることがありますが、CPU の制限を超えたからといってポッドが削除されることはありません。

ポッドの制限により、ポッドがいつリソース消費の制御を失うかを定義します。 制限を超えると、ポッドには削除のマークが付けられます。 この動作により、ノードの正常性が維持され、ノードを共有するポッドへの影響が最小限に抑えられます。 ポッドの制限を設定しない場合、既定で、特定のノードで使用可能な最大値に設定されます。

ポッドの制限を、ノードでサポートできる制限より高く設定しないでください。 各 AKS ノードでは、主要な Kubernetes コンポーネント用に一定量の CPU とメモリが予約されます。 アプリケーションでは、ノードで他のポッドを正常に実行するのに過剰なリソースの使用が試行される場合があります。

1 日または 1 週間の異なる時間にアプリケーションのパフォーマンスを監視します。 需要のピーク時を判断し、最大のニーズを満たすために必要なリソースにポッドの制限を合わせます。

スケジューラによって、リソースが不足しているノードにポッドが配置されると、アプリケーションのパフォーマンスが低下します。 クラスター管理者は、リソースの要求と制限を設定するために必要な名前空間に、"リソース クォータ" を設定する必要があります。 詳細については、AKS クラスターでのリソース クォータに関する記事を参照してください。

CPU の要求または制限を定義する場合、値は CPU 単位で測定されます。

• 1.0 CPU は、ノード上の 1 つの基になる仮想 CPU コアに相当します。
  • これと同じ測定が GPU で使用されます。
• 端数は、ミリコア単位で測定できます。 たとえば、100 m は、基になる vCPU コアの 0.1 です。

1 つの NGINX ポッドの次の基本的な例では、ポッドで 100 m の CPU 時間と、128Mi のメモリが要求されます。 ポッドのリソース制限は、250 m CPU および 256Mi メモリに設定されます。

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 250m
        memory: 256Mi

リソースの測定と割り当ての詳細については、「コンテナーのコンピューティング リソースの管理」を参照してください。

AKS クラスターに対するアプリケーションの開発とデバッグを行う

ベスト プラクティスのガイダンス

開発チームでは、Bridge to Kubernetes を使用して AKS クラスターに対するデプロイおよびデバッグを行う必要があります。

Bridge to Kubernetes を使用すると、AKS クラスターに対して直接アプリケーションを開発、デバッグ、テストできます。 チーム内の開発者は共同作業でアプリケーション ライフサイクル全体を通してビルドとテストを行います。 Visual Studio や Visual Studio Code などの既存のツールを Bridge to Kubernetes 拡張機能で引き続き使用することができます。

Bridge to Kubernetes を使用するこの統合された開発とテストのプロセスを使用すると、minikube などのローカル テスト環境の必要性が低くなります。 代わりに、AKS クラスターを開発してテストします。これは、セキュリティで保護され、分離されたクラスターであっても同様です。

Kubernetes 用の Visual Studio Code (VS Code) 拡張機能を使用する

ベスト プラクティスのガイダンス

YAML マニフェストを記述する場合、Kubernetes 用の VS Code 拡張機能をインストールして使用します。 統合されたデプロイ ソリューション用の拡張機能を使用することもできます。これは、AKS クラスターをあまり操作しないアプリケーション所有者に役立つ場合があります。

Kubernetes 用の Visual Studio Code 拡張機能は、アプリケーションの開発と AKS へのデプロイに役立ちます。 拡張機能には、次の機能が用意されています。

• Kubernetes リソース、Helm chart、およびテンプレートの IntelliSense。

• VS Code 内から Kubernetes リソースを閲覧、デプロイ、編集する機能。

• ポッド仕様で設定されているリソースの要求や制限に関する IntelliSense チェック。

  

次のステップ

この記事では、クラスター オペレーターの観点からクラスターとワークロードを実行する方法に重点を置きました。 管理のベスト プラクティスについては、Azure Kubernetes Service (AKS) での分離とリソース管理に関するクラスター オペレーターのベスト プラクティスに関するページを参照してください。

これらのベスト プラクティスの一部を実装するには、「Bridge to Kubernetes を使用した開発」を参照してください。