はじめに
この実験では、Minikube を使ってローカルの Kubernetes クラスタを起動し、サンプルの NGINX アプリケーションをデプロイし、その後、要求に応じてスケーリングします。複数のポッド間での負荷分散を観察し、クラスタのイベントを監視し、将来のスケーリング自動化のための Horizontal Pod Autoscaler (HPA) について簡単に学びます。この実験は、Kubernetes のスケーリングと負荷分散を理解するための包括的な実践的な経験を提供することを目的としています。
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
これらのコマンドは、以下のことを確認します。
- Minikube が正常に動作している。
- ローカルの Kubernetes クラスタが作成された。
- クラスタが使用可能になっている。
- コントロールプレーン機能を備えた単一ノードのクラスタがある。
サンプルアプリケーションをデプロイする
このステップでは、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: nginx**：app: 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
このデプロイに関する要点：
- 単一のレプリカを持つ Deployment を作成しました。
- デプロイは最新の NGINX イメージを使用しています。
- コンテナはポート 80 を公開しています。
- デプロイには識別用のラベル
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
スケーリングに関する要点：
- YAML ファイルの
replicasを変更するか、kubectl scaleコマンドを使います。 - YAML ファイルを変更する際は、
kubectl applyを使ってデプロイを更新します。 - Kubernetes が希望するレプリカ数が実行されていることを確認します。
- スケーリングは増やす（レプリカを増やす）こともできれば、減らす（レプリカを減らす）こともできます。
複数のポッド応答を確認することで負荷分散を検証する
このステップでは、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: nginx**：app: 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-test：curl-testという名前の新しいポッドを作成します。--image=curlimages/curl：curlがインストールされた 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
負荷分散に関する要点：
- サービスは一致するすべてのポッドにトラフィックを分散させます。
- 各要求は異なるポッドに当たる可能性があります。
- Kubernetes はデフォルトでルーンロビン方式を使用します。
ClusterIPサービスタイプは内部負荷分散を提供します。- 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
スケーリングに関する要点：
- 迅速な一時的なスケーリングには
kubectl scaleを使用します。 - 永続的な構成には YAML を更新します。
- Kubernetes は最小限の混乱でスムーズなスケーリングを保証します。
- コマンドと構成の両方を使って、アプリケーションのニーズに応じて拡大または縮小できます。
変更に対するデプロイとポッドのイベントを監視する
このステップでは、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
監視に関する要点：
kubectl describeは詳細なリソース情報を提供します。kubectl get eventsはクラスタ全体のイベントを表示します。- Kubernetes は削除されたポッドを自動的に置き換えます。
- イベントはデプロイの問題のトラブルシューティングに役立ちます。
- 詳細なオブジェクト情報を取得するには
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 番目のターミナルでは、いくつかのコマンドを使用して、リアルタイムで自動スケーリングを観察することができます：
- HPA の状態を監視する (数秒ごとに更新):
kubectl get hpa -w
- HPA がスケールアップする際にポッドが作成されるのを監視する：
kubectl get pods -w
- スケーリングアクティビティに関連するイベントを追跡する：
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 に関する要点：
- リソース使用率に基づいてポッドを自動的にスケーリングすることで、アプリケーションの回復力を向上させます。
- CPU、メモリ、またはカスタムメトリクスに基づいてスケーリングすることができます。
- 最小および最大レプリカ数を定義することで、バランスの取れた効率的なスケーリングを保証します。
- HPA は、さまざまな負荷下でアプリケーションのパフォーマンスと可用性を維持するための重要なコンポーネントです。
- kubectl コマンドに
-w(watch) フラグを使用すると、クラスターの変更をリアルタイムで監視することができます。
まとめ
この実験では、Kubernetes でのスケーリングと負荷分散に関する実践的な経験を得ました。まず、Minikube を使ってローカルの Kubernetes クラスタを作成し、基本的な NGINX ウェブアプリケーションをデプロイしました。その後、デプロイ YAML ファイルを変更することや、kubectl scale を使ってポッドレプリカの数を調整することなど、さまざまなスケーリング方法を探りました。Kubernetes サービスと一時的なテストポッドを使って負荷分散を検証する方法を学びました。
さらに、kubectl describe と kubectl get events コマンドを使ってデプロイとポッドを監視する方法を学びました。最後に、php-apache イメージを使った例を基に、Horizontal Pod Autoscaler (HPA) について基本的な理解を得ました。HPA は、リソースの利用状況に基づいてアプリケーションを自動的にスケーリングできる仕組みです。この実験は、Kubernetes のスケーリング、負荷分散、監視、およびオートスケーリング技術に関する包括的な紹介を提供し、Kubernetes でより複雑なアプリケーションを管理するための基礎を築きます。
