率先して行動し、冷静さを保つ: Kubernetes クラスターの積極的な拡張

クラスターリソースが不足している場合、Cluster Autoscaler は新しいノードをプロビジョニングし、クラスターに追加します。 Kubernetes を使用する場合、ノードを作成してクラスターに結合するプロセスに数分かかる場合があります。この間、これ以上の拡張は不可能であるため、アプリケーションは接続で圧倒されやすくなります。

Akamai クラウドコンピューティングの詳細を読む

海外のクラウドサービスならAkamai Linodeをお選びください！

仮想マシンのプロビジョニングには数分かかる場合があり、その間はアプリケーションを拡張できない可能性があります。

このような長い待ち時間をなくすにはどうすればよいでしょうか?

プロアクティブなスケーリング、または:

クラスターオートスケーラーの仕組みを理解し、その効果を最大化します。
Kubernetes スケジューラを使用して、ノードに別の Pod を割り当てます。そして

スケーリングを改善するためにワーカーノードを積極的に構成します。注: この記事のすべてのコードはLearnK8s GitHubに公開されています。

Kubernetes での Cluster Autoscaler の仕組み

Cluster Autoscaler は、自動スケーリングをトリガーするときに使用可能なメモリや CPU をチェックしませんが、イベントに反応して、スケジュールできないすべての Podをチェックします。スケジューラがポッドを収容できるノードを見つけられない場合、そのポッドはスケジュール不可能であると言われます。
これをテストするために、次のようなクラスターを作成できます。

 bash $ linode-cli lke cluster-create \ --label learnk8s \ --region eu-west \ --k8s_version 1.23 \ --node_pools.count 1 \ --node_pools.type g6-standard-2 \ --node_pools.autoscaler.enabled enabled \ --node_pools.autoscaler.max 10 \ --node_pools.autoscaler.min 1 \ $ linode-cli lke kubeconfig-view "insert cluster id here" --text | tail +2 | base64 -d > kubeconfig

以下の詳細にご注意ください:

各ノードには 4GB のメモリと 2 つの vCPU があります (例: 「g6-standard-2」インスタンス)
クラスターにはノードが1つだけあり、
クラスターオートスケーラーは、1 ノードから 10 ノードまでスケーリングするように構成されています。次のコマンドでインストールが成功したことを確認できます。

 bash $ kubectl get pods -A --kubecnotallow=kubeconfig

多くの場合、環境変数を含む kubeconfig ファイルをエクスポートすると便利なので、次のように実行できます。

 bash $ export KUBECONFIG=${PWD}/kubeconfig $ kubectl get pods

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

1GB のメモリと 250m* の CPU を必要とするアプリケーションをデプロイしてみましょう。

注: m = コアの容量の 1000 分の 1 なので、250m = CPU の容量の 25% になります。

 yaml apiVersion: apps/v1 kind: Deployment metadata: name: podinfo spec: replicas: 1 selector: matchLabels: app: podinfo template: metadata: labels: app: podinfo spec: containers: - name: podinfo image: stefanprodan/podinfo ports: - containerPort: 9898 resources: requests: memory: 1G cpu: 250m

次のコマンドを使用して、リソースをクラスターに送信します:bash$ kubectl apply -f podinfo.yamlすぐに何かが見つかります。まず、3 つの Pod がほぼ即座に実行を開始し、1 つの Pod が「保留中」状態になります。

その後すぐに:

数分後、オートスケーラーは追加のポッドを作成し、
4 番目の Pod は新しいノードにデプロイされます。

最後に、4番目のポッドが新しいノードにデプロイされます

4 番目のポッドが最初のノードにデプロイされないのはなぜですか?割り当てられたリソースを見てみましょう。

Kubernetesノードにおけるリソースの割り当て

Kubernetes クラスターにデプロイされたポッドは、メモリ、CPU、およびストレージリソースを消費します。さらに、同じノード上で、オペレーティングシステムと Kubelet もメモリと CPU を消費します。

Kubernetes ワーカーノードでは、メモリと CPU は次のように分割されます。

オペレーティングシステムとシステムデーモン (SSH、Systemd など) を実行するために必要なリソース。
Kubelet、コンテナランタイム、ノード障害検出器などの Kubernetes エージェントを実行するために必要なリソース。
ポッドで利用可能なリソース。
削除しきい値用に予約されたリソース。

Kubernetes ノードに割り当てられたリソースと予約されたリソース

クラスターが DaemonSet (kube-proxy など) を実行している場合、使用可能なメモリと CPU の量はさらに減少します。

したがって、すべてのポッドを同じノードに配置できるように要件を下げましょう。

 yaml apiVersion: apps/v1 kind: Deployment metadata: name: podinfo spec: replicas: 4 selector: matchLabels: app: podinfo template: metadata: labels: app: podinfo spec: containers: - name: podinfo image: stefanprodan/podinfo ports: - containerPort: 9898 resources: requests: memory: 0.8G # <- lower memory cpu: 200m # <- lower CPU

次のコマンドを使用してこのデプロイメントを変更できます。

 bash $ kubectl apply -f podinfo.yaml

インスタンスの動作を最適化するために適切な量の CPU とメモリを選択することは、難しい作業です。 Learnk8s の計算ツールを使用すると、これをより迅速に行うことができます。

1 つの問題は解決しましたが、新しいノードを作成するのにかかる時間はどうでしょうか?

遅かれ早かれ 4 つ以上のレプリカが必要になりますが、新しい Pod を作成する前に本当に数分間待つ必要がありますか?

一言で言えば：はい！ Linode は、新しい仮想マシンを最初から作成して構成し、クラスターに接続する必要があります。このプロセスには 2 分以上かかることがよくあります。

しかし、代替手段があります。必要なときに、構成済みのノードを事前に作成することができます。

たとえば、常に予備ノードを準備しておくように Autoscaler を構成できます。 Pod がスタンバイノードにデプロイされると、Autoscaler はプロアクティブに別のスタンバイノードを作成できます。 Autoscaler にはそのような機能は組み込まれていませんが、簡単に再作成できます。

ノードリソースと同じ数のリクエストを持つ Pod を作成できます。

 yaml apiVersion: apps/v1 kind: Deployment metadata: name: overprovisioning spec: replicas: 1 selector: matchLabels: run: overprovisioning template: metadata: labels: run: overprovisioning spec: containers: - name: pause image: k8s.gcr.io/pause resources: requests: cpu: 900m memory: 3.8G用下列命令将资源提交至集群： bash kubectl apply -f placeholder.yaml

このポッドはまったく何もしません。

プレースホルダーポッドを使用してノード上のすべてのリソースを保護する

このノードの役割は、ノードが完全に利用できるようにすることだけです。

次に、ワークロードを拡張する必要があるときに、このプレースホルダー Pod をすぐにクリアできるようにする必要があります。このためにPriority Classを使用できます。

 yaml apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: overprovisioning value: -1 globalDefault: false description: "Priority class used by overprovisioning." --- apiVersion: apps/v1 kind: Deployment metadata: name: overprovisioning spec: replicas: 1 selector: matchLabels: run: overprovisioning template: metadata: labels: run: overprovisioning spec: priorityClassName: overprovisioning # <-- containers: - name: pause image: k8s.gcr.io/pause resources: requests: cpu: 900m memory: 3.8G

次のコマンドを使用してクラスターに送信します。

 bash kubectl apply -f placeholder.yaml

この時点で設定作業は完了です。

Autoscaler がノードを作成するまでしばらく待つ必要がある場合があります。その後、2 つのノードが作成されます。

4つのポッドを持つノード
プレースホルダーポッドを含むノード

デプロイメントを 5 つのレプリカに拡張するとどうなりますか?オートスケーラーが別の新しいノードを作成するまで待機しますか?

次のコマンドでテストします。

 bash kubectl scale deployment/podinfo --replicas=5

様子を見よう：

5 番目の Pod はすぐに作成され、10 秒以内に実行状態に変わります。
プレースホルダー Pod はクリアされ、5 番目の Pod のためのスペースが確保されます。

プレースホルダーポッドは、通常のポッドのためのスペースを確保するためにクリアされます

それから：

クラスターオートスケーラーは保留中のプレースホルダーポッドを認識し、新しいノードをプロビジョニングします。
プレースホルダー Pod は新しく作成されたノードにデプロイされます。

保留中のポッドは、クラスタオートスケーラーをトリガーして新しいノードを作成します。

より多くのノードを持つことができるのに、なぜ積極的にノードを作成するのでしょうか?

プレースホルダーポッドを複数のレプリカに拡張することができ、各レプリカには標準のワークロードを受け入れる準備が整った事前構成済みの Kubernetes ノードが含まれます。ただし、これらのノードはアイドル状態ですが、それによって発生する料金はクラウドサービスの料金に含まれます。したがって、ノードを作成しすぎないように注意してください。

水平ポッドオートスケーラーとクラスターオートスケーラーの使用

このテクノロジーが何を意味するのかを理解するために、クラスターオートスケーラーと水平ポッドオートスケーラー (HPA) を組み合わせることができます。 HPA を使用すると、デプロイメント内のレプリカの数を増やすことができます。

アプリケーションが受信するトラフィックが増えるにつれて、Autoscaler でリクエストを処理するレプリカの数を調整できるようになります。ポッドが利用可能なリソースをすべて使い果たすと、クラスターオートスケーラーがトリガーされ、新しいノードが作成されます。

このようにして、HPA はさらに多くのレプリカを作成し続けることができます。

上記の効果をテストするために新しいクラスターを作成できます。

 bash $ linode-cli lke cluster-create \ --label learnk8s-hpa \ --region eu-west \ --k8s_version 1.23 \ --node_pools.count 1 \ --node_pools.type g6-standard-2 \ --node_pools.autoscaler.enabled enabled \ --node_pools.autoscaler.max 10 \ --node_pools.autoscaler.min 3 \ $ linode-cli lke kubeconfig-view "insert cluster id here" --text | tail +2 | base64 -d > kubeconfig-hpa

次のコマンドを使用して、インストールプロセスが成功したことを確認します。

 bash $ kubectl get pods -A --kubecnotallow=kubeconfig-hpa

環境変数を使用して kubeconfig ファイルをエクスポートすると便利です。これを行うには、次のコマンドを実行します。

 bash $ export KUBECONFIG=${PWD}/kubeconfig-hpa $ kubectl get pods

次に、Helm を使用して Prometheus をインストールし、このデプロイメントに関連するメトリックを表示します。 Helm の詳しいインストール方法は公式ウェブサイトで確認できます。

 bash $ helm repo add prometheus-community https://prometheus-community.github.io/helm-charts $ helm install prometheus prometheus-community/prometheus

Kubernetes は HPA 用のコントローラーを提供し、レプリカの数を動的に増減できます。ただし、HPA にはいくつかの制限もあります。

箱から出してすぐには使用できません。メトリックを集約して公開するには、Metrics Server をインストールする必要があります。
PromQL クエリはそのままでは機能しません。

幸いなことに、KEDA を使用できます。KEDA は、いくつかの便利な機能 (Prometheus からのメトリックの読み取りを含む) によって HPA コントローラーの使用を拡張します。 KEDA は、次の 3 つのコンポーネントに適用できるオートスケーラーです。

スケーラー
メトリックスアダプター
コントローラ

KEDAアーキテクチャ

Helm 経由で KEDA をインストールできます。

 bash $ helm repo add kedacore https://kedacore.github.io/charts $ helm install keda kedacore/keda

Prometheus と KEDA をインストールしたら、デプロイメントを作成しましょう。

この実験では、1 秒あたり一定数のリクエストを処理できるアプリケーションを使用します。各ポッドは 1 秒あたり最大 10 件のリクエストを処理できます。 Pod が 11 番目のリクエストを受信した場合、リクエストを一時停止し、後で処理します。

 yaml apiVersion: apps/v1 kind: Deployment metadata: name: podinfo spec: replicas: 4 selector: matchLabels: app: podinfo template: metadata: labels: app: podinfo annotations: prometheus.io/scrape: "true" spec: containers: - name: podinfo image: learnk8s/rate-limiter:1.0.0 imagePullPolicy: Always args: ["/app/index.js", "10"] ports: - containerPort: 8080 resources: requests: memory: 0.9G --- apiVersion: v1 kind: Service metadata: name: podinfo spec: ports: - port: 80 targetPort: 8080 selector: app: podinfo使用下列命令将资源提交至集群： bash $ kubectl apply -f rate-limiter.yaml

トラフィックを生成するには、 Locustを使用できます。次の YAML 定義は、分散負荷テストクラスターを作成します。

 yaml apiVersion: v1 kind: ConfigMap metadata: name: locust-script data: locustfile.py: |- from locust import HttpUser, task, between class QuickstartUser(HttpUser): @task def hello_world(self): self.client.get("/", headers={"Host": "example.com"}) --- apiVersion: apps/v1 kind: Deployment metadata: name: locust spec: selector: matchLabels: app: locust-primary template: metadata: labels: app: locust-primary spec: containers: - name: locust image: locustio/locust args: ["--master"] ports: - containerPort: 5557 name: comm - containerPort: 5558 name: comm-plus-1 - containerPort: 8089 name: web-ui volumeMounts: - mountPath: /home/locust name: locust-script volumes: - name: locust-script configMap: name: locust-script --- apiVersion: v1 kind: Service metadata: name: locust spec: ports: - port: 5557 name: communication - port: 5558 name: communication-plus-1 - port: 80 targetPort: 8089 name: web-ui selector: app: locust-primary type: LoadBalancer --- apiVersion: apps/v1 kind: DaemonSet metadata: name: locust spec: selector: matchLabels: app: locust-worker template: metadata: labels: app: locust-worker spec: containers: - name: locust image: locustio/locust args: ["--worker", "--master-host=locust"] volumeMounts: - mountPath: /home/locust name: locust-script volumes: - name: locust-script configMap: name: locust-script

次のコマンドを実行してクラスターに送信します。

 bash $ kubectl locust.yaml

Locust は、ConfigMap に保存されている次の locustfile.py ファイルを読み取ります。

 py from locust import HttpUser, task, between class QuickstartUser(HttpUser): @task def hello_world(self): self.client.get("/")

このファイルは特別なことは何もせず、URL にリクエストを送信するだけです。 Locust ダッシュボードに接続するには、ロードバランサーの IP アドレスを指定する必要があります。これを行うには、次のコマンドを使用してアドレスを取得します。

 bash $ kubectl get service locust -o jsnotallow='{.status.loadBalancer.ingress[0].ip}'

次にブラウザを開いて IP アドレスにアクセスします。

注意が必要な問題が 1 つあります。それは、Horizontal Pod Autoscaler です。 KEDA オートスケーラーは、 ScaledObjectと呼ばれる特殊なオブジェクトを使用して、水平オートスケーラーをカプセル化します。

 yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: podinfo spec: scaleTargetRef: kind: Deployment name: podinfo minReplicaCount: 1 maxReplicaCount: 30 cooldownPeriod: 30 pollingInterval: 1 triggers: - type: prometheus metadata: serverAddress: http://prometheus-server metricName: connections_active_keda query: | sum(increase(http_requests_total{app="podinfo"}[60s])) threshold: "480" # 8rps * 60s

KEDA は、Prometheus によって収集されたメトリックに接続し、Kubernetes に送信できます。最後に、これらのメトリックを使用してHorizontal Pod Autoscaler (HPA)も作成します。

次のコマンドを使用して、HPA を手動で確認できます。

 bash $ kubectl get hpa $ kubectl describe hpa keda-hpa-podinfo

次のコマンドを使用してオブジェクトを送信します

bash $ kubectl apply -f scaled-object.yaml

次に、拡張効果をテストできます。 Locust ダッシュボードで次の設定で実験を開始します。

ユーザー数: 300
出現率: 0.4
ホスト: http://podinfo

クラスターと水平ポッドオートスケーラーを組み合わせる

ご覧の通り、レプリカの数が増えました！

効果は良いのですが、気づいたかどうか分からない問題があります。

デプロイメントが 8 つのポッドに拡張された後、新しいノードに新しいポッドが作成されるまでに数分かかります。この間、現在の 8 つのレプリカはそれぞれ 10 件のリクエストしか処理できないため、1 秒あたりに処理されるリクエストの数は増加していません。

ボリュームを縮小して実験を繰り返してみましょう。

 bash kubectl scale deployment/podinfo --replicas=4 # or wait for the autoscaler to remove pods

今回は、プレースホルダー Pod を使用してオーバープロビジョニングを実装します。

 yaml apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: overprovisioning value: -1 globalDefault: false description: "Priority class used by overprovisioning." --- apiVersion: apps/v1 kind: Deployment metadata: name: overprovisioning spec: replicas: 1 selector: matchLabels: run: overprovisioning template: metadata: labels: run: overprovisioning spec: priorityClassName: overprovisioning containers: - name: pause image: k8s.gcr.io/pause resources: requests: cpu: 900m memory: 3.9G

次のコマンドを実行してクラスターに送信します。