アプリケーションのスケーリングと負荷分散

KubernetesKubernetesBeginner
今すぐ練習

💡 このチュートリアルは英語版からAIによって翻訳されています。原文を確認するには、 ここをクリックしてください

はじめに

この実験では、Minikube を使ってローカルの Kubernetes クラスタを起動し、サンプルの NGINX アプリケーションをデプロイし、その後、要求に応じてスケーリングします。複数のポッド間での負荷分散を観察し、クラスタのイベントを監視し、将来のスケーリング自動化のための Horizontal Pod Autoscaler (HPA) について簡単に学びます。この実験は、Kubernetes のスケーリングと負荷分散を理解するための包括的な実践的な経験を提供することを目的としています。


Skills Graph

%%%%{init: {'theme':'neutral'}}%%%% flowchart RL kubernetes(("Kubernetes")) -.-> kubernetes/BasicCommandsGroup(["Basic Commands"]) kubernetes(("Kubernetes")) -.-> kubernetes/AdvancedCommandsGroup(["Advanced Commands"]) kubernetes(("Kubernetes")) -.-> kubernetes/AdvancedDeploymentGroup(["Advanced Deployment"]) kubernetes(("Kubernetes")) -.-> kubernetes/TroubleshootingandDebuggingCommandsGroup(["Troubleshooting and Debugging Commands"]) kubernetes/BasicCommandsGroup -.-> kubernetes/get("Get") kubernetes/BasicCommandsGroup -.-> kubernetes/create("Create") kubernetes/AdvancedCommandsGroup -.-> kubernetes/apply("Apply") kubernetes/AdvancedDeploymentGroup -.-> kubernetes/scale("Scale") kubernetes/TroubleshootingandDebuggingCommandsGroup -.-> kubernetes/describe("Describe") kubernetes/TroubleshootingandDebuggingCommandsGroup -.-> kubernetes/exec("Exec") subgraph Lab Skills kubernetes/get -.-> lab-434648{{"アプリケーションのスケーリングと負荷分散"}} kubernetes/create -.-> lab-434648{{"アプリケーションのスケーリングと負荷分散"}} kubernetes/apply -.-> lab-434648{{"アプリケーションのスケーリングと負荷分散"}} kubernetes/scale -.-> lab-434648{{"アプリケーションのスケーリングと負荷分散"}} kubernetes/describe -.-> lab-434648{{"アプリケーションのスケーリングと負荷分散"}} kubernetes/exec -.-> lab-434648{{"アプリケーションのスケーリングと負荷分散"}} end

Kubernetes クラスタを起動する

このステップでは、Minikube を使ってローカルの Kubernetes クラスタを起動し、検証する方法を学びます。これは、Kubernetes 環境でコンテナ化されたアプリケーションをデプロイして管理するための必須の最初のステップです。

まず、Minikube クラスタを起動します。

minikube start

出力例:

😄  minikube v1.29.0 on Ubuntu 22.04
✨  Automatically selected the docker driver
📌  Using Docker driver with root permissions
🔥  Creating kubernetes in kubernetes cluster
🔄  Restarting existing kubernetes cluster
🐳  Preparing Kubernetes v1.26.1 on Docker 20.10.23...
🚀  Launching Kubernetes...
🌟  Enabling addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace

複数のコマンドを使ってクラスタの状態を検証します。

minikube status
kubectl get nodes

minikube status の出力例:

minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

kubectl get nodes の出力例:

NAME       STATUS   ROLES           AGE   VERSION
minikube   Ready    control-plane   1m    v1.26.1

これらのコマンドは、以下のことを確認します。

  1. Minikube が正常に動作している。
  2. ローカルの Kubernetes クラスタが作成された。
  3. クラスタが使用可能になっている。
  4. コントロールプレーン機能を備えた単一ノードのクラスタがある。

サンプルアプリケーションをデプロイする

このステップでは、Kubernetes Deployment を使って単一のレプリカを持つ単純なウェブアプリケーションをデプロイする方法を学びます。NGINX ウェブサーバー用の YAML マニフェストを作成し、Minikube クラスタに適用します。アプリケーションをデプロイする方法を理解することは、Kubernetes を使う上での基本です。

まず、Kubernetes マニフェスト用のディレクトリを作成します。

mkdir -p ~/project/k8s-manifests
cd ~/project/k8s-manifests

デプロイ用の新しい YAML ファイルを作成します。

nano nginx-deployment.yaml

次のデプロイ構成を追加します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80

ファイルを保存します(Ctrl+X で次に Y を押し、その後 Enter)。

YAML 構成の解説

  • apiVersion: apps/v1:Deployments の API バージョンを指定します。
  • kind: Deployment:これは、複製アプリケーションを管理するために使用される Deployment オブジェクトであることを示します。
  • metadata:Deployment に関するメタデータを含みます。
    • name: nginx-deployment:デプロイの名前。
    • labels: app: nginx:このデプロイを識別するために使用されるラベル。
  • spec:デプロイ仕様を含みます。
    • replicas: 1:ポッドインスタンス(レプリカ)の希望数。この初期デプロイでは、レプリカは 1 つだけです。
    • selector:デプロイが管理するポッドを選択する方法を定義します。
      • matchLabels: app: nginxapp: nginx というラベルが付いたポッドは、このデプロイによって管理されます。
    • template:ポッドテンプレート。これは、デプロイが作成するポッドの構成を指定します。
      • metadata.labels: app: nginx:このデプロイによって管理されるポッドに適用されるラベル
      • spec.containers:ポッド内のコンテナを定義します
        • name: nginx:コンテナの名前。
        • image: nginx:latest:コンテナ用の Docker イメージ(最新の NGINX イメージを使用)。
        • ports: containerPort: 80:コンテナ内のポート 80 を公開します。

このデプロイを Kubernetes クラスタに適用します。

kubectl apply -f nginx-deployment.yaml

出力例:

deployment.apps/nginx-deployment created

デプロイの状態を検証します。

kubectl get deployments
kubectl get pods

kubectl get deployments の出力例:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   1/1     1            1           30s

kubectl get pods の出力例:

NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-xxx-yyy            1/1     Running   0          30s

このデプロイに関する要点:

  1. 単一のレプリカを持つ Deployment を作成しました。
  2. デプロイは最新の NGINX イメージを使用しています。
  3. コンテナはポート 80 を公開しています。
  4. デプロイには識別用のラベル app: nginx があります。

デプロイの詳細を調べます。

kubectl describe deployment nginx-deployment

出力例には、デプロイ構成、イベント、および現在の状態が表示されます。

増える負荷に対応するためにデプロイをスケーリングする

このステップでは、アプリケーションをスケーリングしてより多くのトラフィックを処理する方法を学びます。現実の世界では、アプリケーションが人気を博してくるにつれて、1 つのレプリカだけでは負荷を処理するのに不十分になることがあります。これに対処するために、Kubernetes を使えば、ポッドインスタンス(レプリカ)の数を増やすことで簡単にアプリケーションを拡大できます。

スケーリングする前に、複数のレプリカが必要な理由について簡単に説明しましょう。アプリケーションの単一のレプリカでは、一定量の同時要求しか処理できません。トラフィックがその容量を超えると、アプリケーションが遅くなったり応答しなくなったりする可能性があります。複数のレプリカを持つことで、負荷を異なるポッドインスタンスに分散させることができ、アプリケーションが応答性を保ち、利用可能な状態を維持できます。この概念は、拡張可能なアプリケーションを作成するために欠かせないものです。

ここでは、YAML マニフェストの replicas フィールドを変更することで、また kubectl scale コマンドを使うことで、Kubernetes デプロイをどのようにスケーリングするか学びます。

先ほど作成したデプロイマニフェストを開きます。

nano ~/project/k8s-manifests/nginx-deployment.yaml

replicas フィールドを 1 から 3 に変更します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3 ## 1 から 3 に変更
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80

ファイルを保存します(Ctrl+X で次に Y を押し、その後 Enter)。

更新されたデプロイを適用します。

kubectl apply -f ~/project/k8s-manifests/nginx-deployment.yaml

出力例:

deployment.apps/nginx-deployment configured

スケーリングされたデプロイを検証します。

kubectl get deployments
kubectl get pods

kubectl get deployments の出力例:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           5m

kubectl get pods の出力例:

NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-xxx-yyy            1/1     Running   0          5m
nginx-deployment-xxx-zzz            1/1     Running   0          30s
nginx-deployment-xxx-www            1/1     Running   0          30s

kubectl scale を使った別のスケーリング方法:

kubectl scale deployment nginx-deployment --replicas=4

出力例:

deployment.apps/nginx-deployment scaled

新しいレプリカ数を検証します。

kubectl get deployments
kubectl get pods

スケーリングに関する要点:

  1. YAML ファイルの replicas を変更するか、kubectl scale コマンドを使います。
  2. YAML ファイルを変更する際は、kubectl apply を使ってデプロイを更新します。
  3. Kubernetes が希望するレプリカ数が実行されていることを確認します。
  4. スケーリングは増やす(レプリカを増やす)こともできれば、減らす(レプリカを減らす)こともできます。

複数のポッドの応答を確認することで負荷分散を検証する

このステップでは、Kubernetes での負荷分散を検証する方法を学びます。サービスを作成し、複数のポッドからの応答を確認することで負荷分散を検証します。負荷分散は、複数のレプリカにトラフィックを分散させるために重要で、単一のポッドが圧倒されないようにします。Kubernetes のサービスはこのプロセスを自動的に処理します。

デプロイを公開するためのサービスを作成します。

nano ~/project/k8s-manifests/nginx-service.yaml

次のサービス構成を追加します。

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  type: ClusterIP
  ports:
    - port: 80
      targetPort: 80

ファイルを保存します(Ctrl+X で次に Y を押し、その後 Enter)。

YAML 構成の解説

  • apiVersion: v1:サービスの API バージョンを指定します。
  • kind: Service:これは、サービスオブジェクトであることを示します。
  • metadata:サービスに関するメタデータを含みます。
    • name: nginx-service:サービスの名前。
  • spec:サービス仕様を含みます。
    • selector:このサービスがトラフィックをルーティングするポッドを定義します。
      • app: nginxapp: nginx というラベルが付いたポッドを選択します。これは、前のステップで作成したポッドと一致します。
    • type: ClusterIP:クラスタ内で内部通信に使用するクラスタ IP アドレスを持つ内部サービスを作成します。このサービスタイプは、Kubernetes クラスタ内でのみアクセス可能です。
    • ports:サービスがトラフィックをマッピングする方法を定義します。
      • port: 80:サービスが公開するポート。
      • targetPort: 80:コンテナ内のアプリケーションがリッスンしているポート。

サービスを適用します。

kubectl apply -f ~/project/k8s-manifests/nginx-service.yaml

出力例:

service/nginx-service created

サービスを検証します。

kubectl get services

出力例:

NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
kubernetes      ClusterIP   10.96.0.1       <none>        443/TCP   30m
nginx-service   ClusterIP   10.96.xxx.xxx   <none>        80/TCP    30s

次に、本当に負荷分散を検証するために、一時的なポッドを作成してサービスに複数の要求を送信します。これにより、要求が異なる NGINX ポッドに分散されていることがわかります。

負荷分散をテストするための一時的なポッドを作成します。

kubectl run curl-test --image=curlimages/curl --rm -it -- sh

このコマンドは次のことを行います。

  • kubectl run curl-testcurl-test という名前の新しいポッドを作成します。
  • --image=curlimages/curlcurl がインストールされた Docker イメージを使用します。
  • --rm:ポッドが終了したときに自動的に削除します。
  • -it:疑似端末を割り当てて標準入力を開いたままにします。
  • -- sh:ポッド内でシェルセッションを開始します。

一時的なポッド内で、複数の要求を実行します。

for i in $(seq 1 10); do curl -s nginx-service | grep -q "Welcome to nginx!" && echo "Welcome to nginx - Request $i"; done

このループは、nginx-service に 10 回の要求を送信します。各要求は利用可能な NGINX ポッドの 1 つにルーティングされます。成功した各要求に対して、出力に Welcome to nginx - Request $i が表示されます。

出力例:

Welcome to nginx - Request 1
Welcome to nginx - Request 2
Welcome to nginx - Request 3
...

一時的なポッドを終了します。

exit

負荷分散に関する要点:

  1. サービスは一致するすべてのポッドにトラフィックを分散させます。
  2. 各要求は異なるポッドに当たる可能性があります。
  3. Kubernetes はデフォルトでルーンロビン方式を使用します。
  4. ClusterIP サービスタイプは内部負荷分散を提供します。
  5. curl テストは、複数の NGINX インスタンスに負荷が分散されていることを示しています。

必要に応じてデプロイのスケールを動的に調整する

このステップでは、kubectl scale コマンドを使って、Kubernetes デプロイのスケールを動的に調整して、変化するアプリケーションのニーズに対応する方法を練習します。このステップでは、YAML ファイルを直接変更することなく、実行中のレプリカ数を調整する実際の側面を強調しており、トラフィックの急増に対応するための迅速な調整に役立ちます。

まず、現在のデプロイの状態を確認します。

kubectl get deployments

出力例:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   4/4     4            4           45m

kubectl コマンドを使ってデプロイをスケーリングします。

kubectl scale deployment nginx-deployment --replicas=5

出力例:

deployment.apps/nginx-deployment scaled

新しいレプリカ数を検証します。

kubectl get deployments
kubectl get pods

デプロイの出力例:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   5/5     5            5           46m

ポッドの出力例:

NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-xxx-yyy            1/1     Running   0          1m
nginx-deployment-xxx-zzz            1/1     Running   0          1m
nginx-deployment-xxx-www            1/1     Running   0          1m
nginx-deployment-xxx-aaa            1/1     Running   0          1m
nginx-deployment-xxx-bbb            1/1     Running   0          1m

次に、永続的なスケーリングのためにデプロイ YAML を更新します。

nano ~/project/k8s-manifests/nginx-deployment.yaml

replicas フィールドを変更します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 5 ## 前の値から更新
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80

更新された構成を適用します。

kubectl apply -f ~/project/k8s-manifests/nginx-deployment.yaml

出力例:

deployment.apps/nginx-deployment configured

需要の減少に伴う縮小をシミュレートします。

kubectl scale deployment nginx-deployment --replicas=2

出力例:

deployment.apps/nginx-deployment scaled

縮小されたレプリカ数を検証します。

kubectl get deployments
kubectl get pods

スケーリングに関する要点:

  1. 迅速な一時的なスケーリングには kubectl scale を使用します。
  2. 永続的な構成には YAML を更新します。
  3. Kubernetes は最小限の混乱でスムーズなスケーリングを保証します。
  4. コマンドと構成の両方を使って、アプリケーションのニーズに応じて拡大または縮小できます。

変更を追跡するためのデプロイとポッドのイベントを監視する

このステップでは、Kubernetes のデプロイとポッドを監視する方法を学びます。変更を追跡し、問題をトラブルシューティングし、アプリケーションのライフサイクルを理解するために、様々な kubectl コマンドを使用します。アプリケーションの健全性とパフォーマンスを確保するために、監視可能性は重要です。

現在のデプロイの詳細情報を取得します。

kubectl describe deployment nginx-deployment

出力例:

Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      [timestamp]
Labels:                 app=nginx
Replicas:               2 desired | 2 updated | 2 total | 2 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx:latest
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   nginx-deployment-xxx (2/2 replicas created)
Events:          <some deployment events>

個々のポッドの詳細情報を取得します。

kubectl describe pods -l app=nginx

出力例には、各ポッドの詳細が表示されます。これには、以下が含まれます。

  • 現在の状態
  • コンテナ情報
  • イベント
  • IP アドレス
  • ノード情報

クラスタ全体のイベントを表示します。

kubectl get events

出力例:

LAST SEEN   TYPE      REASON              OBJECT                           MESSAGE
5m          Normal    Scheduled           pod/nginx-deployment-xxx-yyy    Successfully assigned default/nginx-deployment-xxx-yyy to minikube
5m          Normal    Pulled              pod/nginx-deployment-xxx-yyy    Container image "nginx:latest" already present on machine
5m          Normal    Created             pod/nginx-deployment-xxx-yyy    Created container nginx
5m          Normal    Started             pod/nginx-deployment-xxx-yyy    Started container nginx

特定のリソースに関するイベントをフィルタリングします。

kubectl get events --field-selector involvedObject.kind=Deployment

出力例には、デプロイに関連するイベントのみが表示されます。

ポッドを削除することでイベントをシミュレートします。

## ポッド名を取得
POD_NAME=$(kubectl get pods -l app=nginx -o jsonpath='{.items[0].metadata.name}')

## ポッドを削除
kubectl delete pod $POD_NAME

イベントとポッドの再作成を観察します。

kubectl get events
kubectl get pods

監視に関する要点:

  1. kubectl describe は詳細なリソース情報を提供します。
  2. kubectl get events はクラスタ全体のイベントを表示します。
  3. Kubernetes は削除されたポッドを自動的に置き換えます。
  4. イベントはデプロイの問題のトラブルシューティングに役立ちます。
  5. 詳細なオブジェクト情報を取得するには describe を使用し、アクションを追跡するには events を使用します。

将来の学習のために Horizontal Pod Autoscaler (HPA) を簡単に紹介する

このステップでは、Horizontal Pod Autoscaler (HPA) という強力な Kubernetes の機能について紹介します。HPA は、リソースの使用率に基づいてアプリケーションを自動的にスケーリングすることができます。HPA を使用すると、CPU 使用率、メモリ使用量、またはカスタムメトリクスなどの指標に基づいてスケーリングルールを定義することができます。

HPA の理解:

HPA は、観測された CPU またはメモリの使用量、あるいはアプリケーションが提供するカスタムメトリクスに基づいて、Deployment、ReplicaSet、または StatefulSet で実行中のポッドレプリカの数を自動的に調整します。これにより、アプリケーションはトラフィック負荷の変化に自動的に対応してスケーリングし、パフォーマンスと可用性を向上させることができます。

Minikube でメトリクスサーバーアドオンを有効にする:

minikube addons enable metrics-server

出力例:

* The 'metrics-server' addon is enabled

メトリクスサーバーは、Kubernetes にリソースの使用状況データを提供し、HPA が機能するために不可欠です。

リソース要求を持つデプロイメントを作成する:

nano ~/project/k8s-manifests/hpa-example.yaml

以下の内容を追加します:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: php-apache
spec:
  selector:
    matchLabels:
      run: php-apache
  replicas: 1
  template:
    metadata:
      labels:
        run: php-apache
    spec:
      containers:
        - name: php-apache
          image: k8s.gcr.io/hpa-example
          ports:
            - containerPort: 80
          resources:
            limits:
              cpu: 500m
            requests:
              cpu: 200m
---
apiVersion: v1
kind: Service
metadata:
  name: php-apache
  labels:
    run: php-apache
spec:
  ports:
    - port: 80
  selector:
    run: php-apache

デプロイメントを適用する:

kubectl apply -f ~/project/k8s-manifests/hpa-example.yaml

YAML 構成の説明:

  • この YAML ファイルは、PHP アプリケーションの Deployment と対応する Service を定義しています。
  • Deployment の構成は、NGINX のものと非常に似ていますが、以下の点が異なります。
    • name: php-apache: デプロイメントとポッドコンテナの名前。
    • image: k8s.gcr.io/hpa-example: コンテナの Docker イメージ。
    • resources: このセクションは、コンテナのリソース要件を指定します。
      • limits.cpu: 500m: コンテナが使用できる最大 CPU 量。
      • requests.cpu: 200m: コンテナに割り当てられる保証された CPU 量。
  • サービスは標準的なサービス構成で、デプロイメントを内部で公開します。

HPA 構成を作成する:

nano ~/project/k8s-manifests/php-apache-hpa.yaml

以下の HPA マニフェストを追加します:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50

HPA 構成を適用する:

kubectl apply -f ~/project/k8s-manifests/php-apache-hpa.yaml

YAML 構成の説明:

  • apiVersion: autoscaling/v2: HorizontalPodAutoscaler の API バージョンを指定します。
  • kind: HorizontalPodAutoscaler: これが HPA オブジェクトであることを示します。
  • metadata: HPA に関するメタデータを含みます。
    • name: php-apache: HPA の名前。
  • spec: HPA の仕様を含みます。
    • scaleTargetRef: スケーリング対象の Deployment を定義します。
      • apiVersion: apps/v1: 対象リソースの API バージョン。
      • kind: Deployment: 対象リソースのタイプは Deployment です。
      • name: php-apache: スケーリング対象の Deployment の名前。
    • minReplicas: 1: 実行中に維持する最小レプリカ数。
    • maxReplicas: 10: スケーリングする最大レプリカ数。
    • metrics: スケーリングメトリクスの決定方法を定義します。
      • type: Resource: リソースメトリクスに基づいてスケーリングします。
      • resource.name: cpu: CPU 使用量に基づいてスケーリングします。
      • resource.target.type: Utilization: ポッドが要求した CPU の割合に基づいてスケーリングします。
      • resource.target.averageUtilization: 50: すべてのポッドの平均 CPU 使用量が要求量の 50% を超えたときにスケーリングします。

HPA 構成を検証する:

kubectl get hpa

出力例:

NAME         REFERENCE              TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache  0%/50%          1         10        1          30s

負荷をシミュレートし、リアルタイムで自動スケーリングを観察する

高負荷をシミュレートして自動スケーラーをトリガーするには、1 つのターミナルで負荷ジェネレーターを実行し、別のターミナルでスケーリングアクティビティを監視します。

まず、負荷ジェネレーター用のターミナルを開きます:

kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

負荷ジェネレーターを実行しているターミナルを閉じないでください。別のターミナルを開いて、スケーリングアクティビティを監視します。

2 番目のターミナルでは、いくつかのコマンドを使用して、リアルタイムで自動スケーリングを観察することができます:

  1. HPA の状態を監視する (数秒ごとに更新):
kubectl get hpa -w
  1. HPA がスケールアップする際にポッドが作成されるのを監視する:
kubectl get pods -w
  1. スケーリングアクティビティに関連するイベントを追跡する:
kubectl get events --sort-by='.lastTimestamp' -w

これらのコマンドのいずれかを実行して、自動スケーリングプロセスのさまざまな側面を観察することができます。たとえば、-w フラグを使用してポッドを監視すると、システムがスケーリングする際にポッドがリアルタイムで作成されるのを確認できます:

kubectl get pods -w の出力例:

NAME                         READY   STATUS    RESTARTS   AGE
php-apache-xxxxxxxxx-xxxxx   1/1     Running   0          2m
load-generator               1/1     Running   0          30s
php-apache-xxxxxxxxx-yyyyy   0/1     Pending   0          0s
php-apache-xxxxxxxxx-yyyyy   0/1     ContainerCreating   0          0s
php-apache-xxxxxxxxx-yyyyy   1/1     Running   0          3s
php-apache-xxxxxxxxx-zzzzz   0/1     Pending   0          0s
php-apache-xxxxxxxxx-zzzzz   0/1     ContainerCreating   0          0s
php-apache-xxxxxxxxx-zzzzz   1/1     Running   0          2s

HPA が負荷の増加に応じてポッドの数をスケールアップするのを確認できます。メトリクスの更新には 1 分以上かかる場合があります:

kubectl get hpa -w の出力例:

NAME         REFERENCE               TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache   0%/50%    1         10        1          30s
php-apache   Deployment/php-apache   68%/50%   1         10        1          90s
php-apache   Deployment/php-apache   68%/50%   1         10        2          90s
php-apache   Deployment/php-apache   79%/50%   1         10        2          2m
php-apache   Deployment/php-apache   79%/50%   1         10        4          2m15s

観察が終了したら、Ctrl+C を押して監視コマンドを停止し、最初のターミナルに戻って Ctrl+C を押して負荷ジェネレーターを停止します。

HPA に関する要点:

  1. リソース使用率に基づいてポッドを自動的にスケーリングすることで、アプリケーションの回復力を向上させます。
  2. CPU、メモリ、またはカスタムメトリクスに基づいてスケーリングすることができます。
  3. 最小および最大レプリカ数を定義することで、バランスの取れた効率的なスケーリングを保証します。
  4. HPA は、さまざまな負荷下でアプリケーションのパフォーマンスと可用性を維持するための重要なコンポーネントです。
  5. kubectl コマンドに -w (watch) フラグを使用すると、クラスターの変更をリアルタイムで監視することができます。

まとめ

この実験では、Kubernetes でのスケーリングと負荷分散に関する実践的な経験を得ました。まず、Minikube を使ってローカルの Kubernetes クラスタを作成し、基本的な NGINX ウェブアプリケーションをデプロイしました。その後、デプロイ YAML ファイルを変更することや、kubectl scale を使ってポッドレプリカの数を調整することなど、さまざまなスケーリング方法を探りました。Kubernetes サービスと一時的なテストポッドを使って負荷分散を検証する方法を学びました。

さらに、kubectl describekubectl get events コマンドを使ってデプロイとポッドを監視する方法を学びました。最後に、php-apache イメージを使った例を基に、Horizontal Pod Autoscaler (HPA) について基本的な理解を得ました。HPA は、リソースの利用状況に基づいてアプリケーションを自動的にスケーリングできる仕組みです。この実験は、Kubernetes のスケーリング、負荷分散、監視、およびオートスケーリング技術に関する包括的な紹介を提供し、Kubernetes でより複雑なアプリケーションを管理するための基礎を築きます。