必要に応じてオンとオフを切り替えることでコストを節約できます。このような Kubernetes クラスターを望まない人がいるでしょうか?

インフラストラクチャのコストを可能な限り低く抑えるために、使用されていない特定のリソースをシャットダウンすることができます。ただし、ここでの課題は、必要なときにリソースを自動的にオンにする方法を決定することです。この記事では、Linode Kubernetes Engine (LKE) を使用して Kubernetes クラスターをデプロイし、Kubernetes Events-Driven Autoscaler (KEDA) を使用してそれをゼロにスケールダウンし、再度スケールアップする方法を説明します。

Linode が Akamai ソリューション ファミリーに加わったことを記念して、今すぐ Linode に登録して、Linode クラウド プラットフォームが提供するさまざまなサービスを使用するための 100 ドル相当の無料使用クレジットを獲得しましょう。詳細と登録については、ここをクリックしてください↓↓↓

海外クラウドサービスならAkamaiが最適です！

なぜゼロに縮小するのですか?

Kubernetes 上で一般的なリソース集約型アプリケーションが実行されているが、そのアプリケーションを実行する必要があるのは営業時間中だけだとします。全員が退社するときに電源をオフにし、仕事に着いたら自動的に電源をオンに戻すようにしたい場合があります。

使用されていない開発環境をシャットダウンする必要がある場合があります。

この時点では、CronJob を使用してインスタンスをスケーリングできますが、これは一時的な対策にすぎず、事前に設定されたスケジュールに従ってのみ実行できます。

週末は何が起こるでしょうか？祝日はどうですか?チーム全員が病気で出勤できない場合はどうなるでしょうか?

増え続けるルールのリストをコンパイルするのではなく、トラフィックに基づいてワークロードをスケーリングできます。トラフィックが増加すると、レプリカの数を拡張できます。トラフィックがない場合、アプリケーション全体をシャットダウンできます。アプリケーションがシャットダウンされ、新しい着信リクエストを受信すると、Kubernetes はトラフィックを処理するために少なくとも 1 つのレプリカを開始します。

アプリケーションをゼロにスケールダウンするとリソースを節約できます

以下にその方法を説明します。

1. アプリケーションへのすべてのトラフィックを傍受します。
2. トラフィックを監視する。そして
3. レプリカの数を調整したり、アプリケーションをシャットダウンしたりするには、Autoscaler を設定します。

ご参考までに、関連コードが公開されています。 LearnK8s GitHub。

クラスターの作成

まず、Kubernetes クラスターを作成する必要があります。次のコマンドを使用してクラスターを作成し、kubeconfig ファイルを保存します。

 bash $ linode-cli lke cluster-create \ --label cluster-manager \ --region eu-west \ --k8s_version 1.23 $ linode-cli lke kubeconfig-view "insert cluster id here" --text | tail +2 | base64 -d > kubeconfig

次のコマンドを実行すると、インストール プロセスが成功したことを確認できます。

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

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

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

次に、アプリケーションをデプロイする必要があります。

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

yaml apiVersion: apps/v1 kind: Deployment metadata: name: podinfo spec: selector: matchLabels: app: podinfo template: metadata: labels: app: podinfo spec: containers: - name: podinfo image: stefanprodan/podinfo ports: - containerPort: 9898 --- apiVersion: v1 kind: Service metadata: name: podinfo spec: ports: - port: 80 targetPort: 9898 selector: app: podinfo

次のコマンドを使用して YAML ファイルを送信します。

 terminal|command=1|title=bash $ kubectl apply -f 1-deployment.yaml

ブラウザを開いてアプリにアクセスするには、 ローカルホスト:8080。

 bash $ kubectl port-forward svc/podinfo 8080:80

その後、アプリが表示されるはずです。

次に、この例で使用するオートスケーラーである KEDA をインストールする必要があります。

KEDA: Kubernetes イベント駆動型オートスケーラー

Kubernetesが提供するもの Horizo​​ntal Pod Autoscaler (HPA) をコントローラーとして使用して、レプリカの数を動的に増減できます。ただし、HPA にはいくつかの欠点があります。

1. そのままでは使用できず、メトリックを集計して公開するには Metrics Server をインストールする必要があります。
2. コピーをゼロにスケールすることはできません。
3. レプリカはメトリックに基づいてのみスケーリングでき、HTTP トラフィックを傍受することはできません。

幸いなことに、公式の Autoscaler の使用に限定されず、KEDA も使用できます。ケダ 次の 3 つのコンポーネント用に構築されたオートスケーラー:

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

KEDAアーキテクチャ

スケーラーはアダプタに似ており、データベース、メッセージブローカー、テレメトリシステムなどからメトリクスを収集できます。たとえば、HTTPスケーラー このアダプタは HTTP トラフィックを傍受して収集できます。ここで、RabbitMQ を使用した Scaler の例を見ることができます。

メトリック アダプターは、スケーラーによって収集されたメトリックを、Kubernetes メトリック パイプラインで使用できる形式でエクスポートする役割を担います。

最後に、コントローラーはこれらすべてのコンポーネントを結び付けます。

1. メトリックはアダプタを使用して収集され、メトリック API に公開されます。
2. ScaledObject、TriggerAuthentication など、KEDA 指定のカスタム リソース定義 (CRD) を登録および管理します。
3. 当社に代わって Horizo​​ntal Pod Autoscaler を作成および管理します。

理論的な紹介はこれですべてです。実際にどのように機能するかを見てみましょう。

Helm を使用すると、コントローラーをすばやくインストールできます。詳しい手順と紹介については、 Helm公式サイト。

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

KEDA にはデフォルトで HTTP Scaler が含まれていないため、別途インストールする必要があります。

 bash $ helm install http-add-on kedacore/keda-add-ons-http

その後、アプリケーションを拡張できます。

自動スケーリングポリシーの定義

KEDA の HTTP アドオンは、アプリケーションを拡張する方法を記述できる CRD を公開します。例を見てみましょう:

 yaml kind: HTTPScaledObject apiVersion: http.keda.sh/v1alpha1 metadata: name: podinfo spec: host: example.com targetPendingRequests: 100 scaleTargetRef: deployment: podinfo service: podinfo port: 80 replicas: min: 0 max: 10

このファイルはインターセプターに http://example.com リクエストは podinfo サービスに転送されます。

KEDA と HTTP インターセプター

拡張する必要があるデプロイメントの名前も含まれています。この場合は ポッドインフォ。

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

 bash $ kubectl apply -f scaled-object.yaml

上記の定義を送信した後、Pod は削除されました。なぜこのようなことが起こるのでしょうか?

HTTPScaledObject を作成した後、現時点ではトラフィックがないため、KEDA はすぐにデプロイメントをゼロにスケールダウンします。

スケーリングするには、アプリケーションに HTTP リクエストを送信する必要があります。サービスに接続してリクエストしてみてください。

 bash $ kubectl port-forward svc/podinfo 8080:80

このコマンドはハングしています。

現在、リクエストを処理できる Pod がないため、この動作は妥当です。しかし、Kubernetes はこのデプロイメントを 1 にスケールしなかったのはなぜでしょうか?

KEDAインターセプターのテスト

Helm を使用してアドオンをインストールすると、keda-add-ons-http-interceptor-proxy という Kubernetes サービスが作成されます。自動スケーリングが適切に機能するには、まず HTTP トラフィックをこのサービス経由でルーティングする必要があります。これを kubectl port-forward でテストできます。

 shell $ kubectl port-forward svc/keda-add-ons-http-interceptor-proxy 8080:8080

今回はブラウザでURLにアクセスできません。

Ingress での KEDA HTTP アドインの使用

Helm を使用して Nginx-ingress コントローラーをインストールできます。

 bash $ helm upgrade --install ingress-nginx ingress-nginx \ --repo https://kubernetes.github.io/ingress-nginx \ --namespace ingress-nginx --create-namespace

次に、トラフィックを podinfo にルーティングするための Ingress マニフェストを記述します。

 yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: podinfo spec: ingressClassName: nginx rules: - host: example.com http: paths: - path: / pathType: Prefix backend: service: name: keda-add-ons-http-interceptor-proxy # <- this port: number: 8080

次のコマンドを実行すると、ロード バランサーの IP アドレスを取得できます。

 bash LB_IP=$(kubectl get services -l "app.kubernetes.io/compnotallow=controller" -o jsnotallow="{.items[0].status.loadBalancer.ingress [0].ip}" -n ingress-nginx)

最後に、次のコマンドを使用してアプリケーションにリクエストを発行します。

 bash curl $LB_IP -H "Host: example.com"

それは動作します！十分に長く待つと、デプロイメントが最終的にゼロに縮小されることにも気付くでしょう。

これは Kubernetes 上の Serverless とどう違うのでしょうか?

この構成は、Kubernetes 上のサーバーレス フレームワーク (OpenFaaS など) とはいくつかの重要な違いがあります。

1. KEDA を使用する場合、アプリケーション アーキテクチャを調整する必要はなく、SDK を使用してアプリケーションをデプロイする必要もありません。
2. サーバーレス フレームワークはリクエストのルーティングと処理を担当するため、私たちはアプリケーション ロジックにのみ集中する必要があります。
3. KEDA を使用する場合、通常のコンテナがデプロイされます。 Serverless フレームワークを使用する場合、これは必ずしも当てはまりません。

この記事の内容は大丈夫でしょうか？今すぐ Linode プラットフォームで試してみませんか?今すぐ登録すると、100 ドル相当の無料クレジットを獲得できることをお忘れなく。早速、この記事で紹介した機能やサービスを実際に体験してみましょう↓↓↓

海外クラウドサービスならAkamaiが最適です！

フォローを歓迎します アカマイ 、高可用性 MySQL/MariaDB リファレンス アーキテクチャと豊富なアプリケーション例を初めて知ることができます。