how-to-autoscale-your-workloads-on-digitalocean-kubernetes

投稿日: 2019-11-08 2019-11-19
タグ: Kubernetes, Scaling

前書き

Kubernetesで構築されたアプリケーションを使用する場合、開発者は追加のhttps://kubernetes.io/docs/conceptsをスケジュールする必要があります。 / workloads / pods / pod / [pods]を使用して、トラフィックのピーク時または負荷処理の増加を処理します。デフォルトでは、これらの追加ポッドのスケジューリングは手動の手順です。開発者は、希望するhttps://kubernetes.io/docs/concepts/workloads/controllers/replicaset/[replicas]の数をhttps://kubernetes.io/docs/concepts/workloads/controllers/deployment/ [展開オブジェクト]増加したトラフィックを考慮し、追加のポッドが不要になったときに元に戻します。手動介入へのこの依存は、多くのシナリオで理想的とは言えません。たとえば、誰も目を覚ましてポッドのスケーリングを行っていない夜中にワークロードがピーク時間に達する可能性があります。また、手動応答では負荷に十分に対応できない場合、Webサイトで予期しないトラフィックの増加が発生する可能性があります。これらの状況では、最も効率的でエラーが発生しにくいアプローチは、https：//kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/ [Horizontal Pod Autoscaler（HPA）]を使用してクラスターのスケーリングを自動化することです。。

Metrics Serverからの情報を使用することにより、HPAはリソース使用量の増加を検出し、ワークロードをスケーリングして対応します。これは特にマイクロサービスアーキテクチャで役立ち、KubernetesクラスターがCPU使用率などのメトリックに基づいて展開をスケーリングできるようになります。 DigitalOcean Kubernetes（DOKS）と組み合わせると、HPAを使用してコンテナ化されたアプリケーションを展開するためのプラットフォームを開発者に提供する管理Kubernetesオファリングは、迅速に調整する自動インフラストラクチャを作成できますトラフィックと負荷の変化に。

このチュートリアルでは、DOKSにサンプルhttps://www.nginx.com/[Nginx]デプロイメントをセットアップします。これは、CPU負荷の増加に対応するために水平方向に自動スケーリングできます。これを実現するには、Metrics Serverをクラスターにデプロイして、HPAがスケーリングのタイミングを決定するときに使用するポッドメトリックを収集します。

前提条件

このガイドを始める前に、次のものが必要です。

接続が `+ kubectl `デフォルトとして設定されたDigitalOcean Kubernetesクラスター。 ` kubectl +`を設定する方法の手順は、クラスターを作成するときに[* Connect to the cluster *]ステップの下に表示されます。 DigitalOceanでKubernetesクラスターを作成するには、https：//www.digitalocean.com/docs/kubernetes/quickstart/ [Kubernetes Quickstart]を参照してください。
ローカルマシンにインストールされたHelmパッケージマネージャー、およびクラスターにインストールされたTiller。これを行うには、https：//www.digitalocean.com/community/tutorials/how-to-install-software-on-kubernetes-clusters-with-the-helm-package-manager [How Helm Package Managerを使用してKubernetesクラスターにソフトウェアをインストールするには]チュートリアル。

手順1-テスト展開の作成

HPAの効果を示すために、最初にオートスケールに使用するアプリケーションをデプロイします。このチュートリアルでは、標準のhttps://docs.docker.com/samples/library/nginx/[Nginx Docker image]を展開として使用します。これは、並行して動作することができ、Kubernetes内でhttpsなどのツールで広く使用されているためです。：//github.com/kubernetes/ingress-nginx [Nginx Ingress Controller]。セットアップが簡単です。このNginx展開は、ベースイメージに標準で付属する静的な* Welcome to Nginx！*ページを提供します。既に展開を行っている場合は、その展開を自由に使用して、この手順をスキップしてください。

次のコマンドを発行して、Nginxベースイメージを使用してサンプル展開を作成します。デプロイメントに別の名前を付けたい場合は、名前「++」を置き換えることができます。

kubectl create deployment  --image=nginx:latest

`+-image = nginx：latest +`フラグは、Nginxベースイメージの最新バージョンからデプロイを作成します。

数秒後、「++」ポッドがスピンアップします。このポッドを表示するには、次のコマンドを実行します。これにより、現在のネームスペースで実行されているポッドが表示されます。

kubectl get pods

これにより、次のような出力が得られます。

OutputNAME                                                   READY   STATUS             RESTARTS   AGE
                                  1/1     Running            0          11s

元々デプロイされているポッドは1つだけであることに注意してください。自動スケーリングがトリガーされると、より多くのポッドが自動的にスピンアップします。

これで、クラスター内で基本的な展開が実行されました。これは、自動スケーリング用に構成する展開です。次のステップは、このデプロイメントを構成して、リソース要求と制限を定義することです。

手順2-展開でのCPU制限と要求の設定

このステップでは、https：//kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container [requests andデプロイメントのCPU使用率の制限]。 Kubernetesの_Limits_は、ポッドが使用できるリソース（CPUまたはメモリ）の最大量を記述するためにデプロイメントに設定されます。 _Requests_は、そのノードがスケジューリングに有効なノードと見なされるために、ノード上で必要なリソースの量を記述するためにデプロイメントに設定されます。たとえば、Webサーバーのメモリ要求が1GBに設定されている場合、少なくとも1GBの空きメモリがあるノードのみがスケジューリングの対象になります。自動スケーリングの場合、スケーリングとスケジューリングの決定を行う際にHPAがこの情報を必要とするため、これらの制限と要求を設定する必要があります。

要求と制限を設定するには、作成したデプロイメントに変更を加える必要があります。このチュートリアルでは、次のhttps://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#kubectl-edit[+kubectl edit + `]コマンドを使用して、クラスターに保存されているAPIオブジェクト設定を変更します。 `+ kubectl edit +`コマンドは、 `+ KUBE_EDITOR +`または `+ EDITOR +`環境変数で定義されたエディターを開くか、https：//www.digitalocean.com/community/tutorials/installing-and-using-にフォールバックしますデフォルトでは、-vim-text-editor-on-a-cloud-server＃editing [Linuxの場合は `+ vi +]、Windowsの場合は `+ notepad +`です。

展開を編集します。

kubectl edit deployment

展開の構成が表示されます。デプロイメントのCPU使用率に指定されたリソース制限とリクエストを設定できるようになりました。これらの制限により、この展開のポッドが個別に使用できる各リソースの量のベースラインが設定されます。これを設定すると、ポッドが酷使されているかどうかを知るための参照フレームがHPAに与えられます。たとえば、ポッドに100ミリコアのCPUの「+ limit +」の上限があると予想し、現在ポッドが95ミリコアを使用している場合、HPAは95％の容量であることを認識します。 100ミリコアという制限を設けないと、HPAはポッドの全容量を解読できません。

`+ resources`セクションで制限とリクエストを設定できます：

展開構成ファイル

. . .
 template:
   metadata:
     creationTimestamp: null
     labels:
       app: web
   spec:
     containers:
     - image: nginx:latest
       imagePullPolicy: Always
       name: nginx

       terminationMessagePath: /dev/termination-log
       terminationMessagePolicy: File
     dnsPolicy: ClusterFirst
     restartPolicy: Always
     schedulerName: default-scheduler
     securityContext: {}
     terminationGracePeriodSeconds: 30
status:
 availableReplicas: 1
. . .

このチュートリアルでは、CPUの「+ requests 」を「 100m 」に、メモリを「 250Mi +」に設定します。これらの値は、デモンストレーションを目的としています。すべてのワークロードは異なるため、これらの値は他のワークロードには意味がない場合があります。一般的なルールとして、これらの値は、このワークロードのポッドが使用すると予想される最大値に設定する必要があります。これらの値を決定するには、アプリケーションを監視し、低い時間とピーク時間でのアプリケーションのパフォーマンスに関するリソース使用状況データを収集することをお勧めします。これらの値はいつでも調整および変更できるため、いつでも戻ってデプロイメントを最適化できます。

先に進み、Nginxコンテナの `+ resources`セクションの下に次の強調表示された行を挿入します。

展開構成ファイル

. . .
 template:
   metadata:
     creationTimestamp: null
     labels:
       app: web
   spec:
     containers:
     - image: nginx:latest
       imagePullPolicy: Always
       name: nginx
       resources:





       terminationMessagePath: /dev/termination-log
       terminationMessagePolicy: File
     dnsPolicy: ClusterFirst
     restartPolicy: Always
     schedulerName: default-scheduler
     securityContext: {}
     terminationGracePeriodSeconds: 30
status:
 availableReplicas: 1
. . .

これらの行を挿入したら、ファイルを保存して終了します。構文に問題がある場合、「+ kubectl +」はファイルを再度開きます。詳細についてはエラーが投稿されます。

制限とリクエストを設定したら、HPAがこれらの制限を監視して正しく遵守できるように、メトリックが収集されていることを確認する必要があります。これを行うには、CPUメトリックを収集するサービスを設定します。このチュートリアルでは、Metrics Serverプロジェクトを使用してこれらのメトリックを収集し、Helmチャートとともにインストールします。

ステップ3-Metricsサーバーのインストール

次に、https：//github.com/kubernetes-incubator/metrics-server [Kubernetes Metric Server]をインストールします。これは、ポッドメトリックをスクレイピングするサーバーです。ポッドメトリックは、HPAが自動スケーリングが必要かどうかを判断するために使用するメトリックを収集します。

Helmを使用してMetrics Serverをインストールするには、次のコマンドを実行します。

helm install stable/metrics-server --name metrics-server

これにより、Metrics Serverの最新の安定バージョンがインストールされます。 +-name of`フラグは、このリリースに + metrics-server`を指定します。

このポッドが初期化されるのを待ったら、 `+ kubectl top pod +`コマンドを使用してポッドのメトリックを表示してみてください。

kubectl top pod

このコマンドは、クラスター内のリソース使用量をポッドレベルで表示することを目的としていますが、DOKSがDNSを処理する方法のため、このコマンドはこの時点でエラーを返します。

OutputError: Metrics not available for pod

Error from server (ServiceUnavailable): the server is currently unable to handle the request (get pods.metrics.k8s.io)

このエラーは、DOKSノードが自身のDNSレコードを作成せず、Metrics Serverがホスト名を介してノードに接続するため、ホスト名が適切に解決されないために発生します。この問題を修正するには、次のコマンドを使用してMetrics Serverコンテナにランタイムフラグを追加して、Metrics Serverがノードと通信する方法を変更します。

kubectl edit deployment metrics-server

`+ command +`セクションの下にフラグを追加します。

メトリックサーバー構成ファイル

. . .
 template:
   metadata:
     creationTimestamp: null
     labels:
       app: metrics-server
       release: metrics-server
   spec:
     affinity: {}
     containers:

       - /metrics-server
       - --cert-dir=/tmp
       - --logtostderr
       - --secure-port=8443
       image: gcr.io/google_containers/metrics-server-amd64:v0.3.4
       imagePullPolicy: IfNotPresent
       livenessProbe:
         failureThreshold: 3
         httpGet:
           path: /healthz
. . .

追加するフラグは、「-kubelet-preferred-address-types = InternalIP +」です。このフラグは、ホスト名ではなく「 internalIP +」を使用してノードに接続するようにメトリックサーバーに指示します。このフラグを回避策として使用して、内部IPアドレスを介してノードと通信できます。

また、 `-metric-resolution +`フラグを追加して、Metrics Serverがメトリックをスクレイピングするデフォルトのレートを変更します。このチュートリアルでは、Metrics Serverが「 60s 」ごとにデータポイントを作成するように設定しますが、より多くのメトリックデータが必要な場合は、Metrics Serverに「 10s 」または「 20s +」ごとにメトリックをスクレイプするように依頼できます。これにより、期間ごとのリソース使用量のデータポイントが増えます。ニーズに合わせてこの解像度を自由に微調整してください。

次の強調表示された行をファイルに追加します。

メトリックサーバー構成ファイル

. . .
 template:
   metadata:
     creationTimestamp: null
     labels:
       app: metrics-server
       release: metrics-server
   spec:
     affinity: {}
     containers:
     - command:
       - /metrics-server
       - --cert-dir=/tmp
       - --logtostderr
       - --secure-port=8443


       image: gcr.io/google_containers/metrics-server-amd64:v0.3.4
       imagePullPolicy: IfNotPresent
       livenessProbe:
         failureThreshold: 3
         httpGet:
           path: /healthz
. . .

フラグを追加したら、エディターを保存して終了します。

Metrics Serverが実行されていることを確認するには、数分後に「+ kubectl top pod +」を使用します。前と同様に、このコマンドはポッドレベルでのリソース使用量を提供します。今回は、稼働中のメトリックサーバーにより、各ポッドのメトリックを表示できます。

kubectl top pod

これにより、Metrics Serverポッドが実行された状態で、次の出力が得られます。

OutputNAME                             CPU(cores)   MEMORY(bytes)

web-555db5bf6b-f7btr             0m           2Mi

これで、Metrics Serverが機能し、クラスター内のポッドのリソース使用状況を表示および監視できるようになりました。次に、このデータを監視し、CPU使用率が高い期間に対応するようにHPAを構成します。

手順4-水平ポッドオートスケーラーの作成と検証

最後に、展開用の水平ポッドオートスケーラー（HPA）を作成します。 HPAは、Metrics Serverから収集されたCPU使用率データを定期的にチェックし、ステップ2で設定したしきい値に基づいて展開をスケーリングする実際のKubernetesオブジェクトです。

`+ kubectl autoscale +`コマンドを使用してHPAを作成します。

kubectl autoscale deployment   --max=4 --cpu-percent=80

このコマンドは、 “デプロイメントのHPAを作成します。また、「+-max +」フラグを使用して、「」をスケーリングできる最大レプリカを設定します。この場合、「+ 4+」として設定します。

+-cpu-percent +`フラグは、ステップ2で設定した制限の使用率をHPAに通知して、オートスケールをトリガーさせます。これは、リクエストを使用して、最初のリソース割り当てに対応できるノードにスケールアップされたポッドをスケジュールするのにも役立ちます。この例では、手順1で展開に設定した制限が100ミリコア（ `+ 100m +）の場合、ポッドが平均CPU使用率で `+ 80m +`に達すると、このコマンドは自動スケールをトリガーします。これにより、展開はCPUリソースを使い果たす前に自動スケーリングできます。

展開が自動的にスケーリングできるようになったので、次はこれをテストします。

検証するには、クラスターをしきい値を超える負荷を生成し、オートスケーラーが引き継ぐのを監視します。開始するには、2番目のターミナルを開いて、現在スケジュールされているポッドを監視し、2秒ごとにポッドのリストを更新します。これを実現するには、この2番目のターミナルで `+ watch +`コマンドを使用します。

watch "kubectl top pods"

`+ watch `コマンドは、引数として指定されたコマンドを継続的に発行し、ターミナルに出力を表示します。繰り返しの間隔は、「-n +」フラグでさらに設定できます。このチュートリアルでは、デフォルトの2秒の設定で十分です。

端末は最初に `+ kubectl top pods +`の出力を表示し、その後2秒ごとにコマンドが生成する出力を更新します。これは次のようになります。

OutputEvery 2.0s: kubectl top pods

NAME                              CPU(cores)   MEMORY(bytes)
metrics-server-6fd5457684-7kqtz   3m           15Mi
web-7476bb659d-q5bjv              0m           2Mi

`++`に現在デプロイされているポッドの数に注意してください。

元の端末に切り替えます。これで、 + kubectl exec +`を使用して現在の `++`ポッド内でターミナルを開き、人為的な負荷を作成します。これを実行するには、ポッドに移動してhttps://packages.ubuntu.com/xenial/devel/stress [+ stress +` CLIツール]をインストールします。

`+ kubectl exec `を使用してポッドを入力し、強調表示されたポッド名を `+`ポッドの名前に置き換えます。

kubectl exec -it  /bin/bash

このコマンドの概念は、「+ ssh 」を使用して別のマシンにログインすることに非常に似ています。 ` / bin / bash +`はポッドにbashシェルを確立します。

次に、ポッド内のbashシェルから、リポジトリメタデータを更新し、 `+ stress +`パッケージをインストールします。

apt update; apt-get install -y stress

次に、 `+ stress +`コマンドを使用してポッドにCPU負荷を生成し、実行させます：

stress -c 3

次に、2番目のターミナルの「+ watch 」コマンドに戻ります。 Metrics ServerがHPAの定義済みのしきい値を超えるCPUデータを収集するまで数分待ちます。デフォルトでは、メトリックスは、メトリックスサーバーを設定するときと同じ「-metric-resolution +」に設定したレートで収集されます。使用メトリックが更新されるまで、1分程度かかる場合があります。

約2分後、追加の `++`ポッドがスピンアップします。

OutputEvery 2.0s: kubectl top pods

NAME                             CPU(cores)   MEMORY(bytes)
metrics-server-db745fcd5-v8gv6   6m           16Mi

これで、HPAがMetrics Serverによって収集されたCPU負荷に基づいて新しいポッドをスケジュールしたことがわかります。この検証に満足したら、 `+ CTRL + C `を使用して最初のターミナルで ` stress +`コマンドを停止し、ポッドのbashシェルを終了します。

結論

この記事では、CPU負荷に基づいて自動スケーリングするデプロイメントを作成しました。 CPUリソースの制限とリクエストをデプロイメントに追加し、Helmを使用してクラスターにMetrics Serverをインストールおよび構成し、スケーリングの決定を行うためにHPAを作成しました。

これは、Metrics ServerとHPAの両方のデモ展開です。これで、特定のユースケースに合わせて構成を調整できます。 Kubernetes HPAのドキュメントをhttps://kubernetes.io/docs/concepts/で参照してください。 configuration / manage-compute-resources-container / [リクエストと制限]。また、https：//github.com/kubernetes-incubator/metrics-server [Metrics Serverプロジェクト]をチェックして、ユースケースに適用される可能性のある調整可能な設定をすべて確認してください。

Kubernetesをさらに活用したい場合は、https：//www.digitalocean.com/community/tags/kubernetes？type = tutorials [Kubernetes Community page]にアクセスするか、https：//www.digitalocean.comをご覧ください。 / products / kubernetes / [マネージドKubernetesサービス]。

getdocs

13036