Linode エンジンを使用した Kubernetes 自動スケーリングのベストプラクティス

ご存知のとおり、クラウドサービスのアーキテクチャは、手動で構成を変更したり、コードを 1 行ずつ追加したりすることなく、アプリケーションのニーズに合わせてリアルタイムで拡張できます。その中で、自動スケーリングは、人間の介入なしにアプリケーションの負荷を自動的に増減する機能を保証します。明らかに、適切に調整すれば、自動スケーリングによってアプリケーションの保守コストとプロジェクト実装の難易度が軽減されます。

Kubernetes の場合、自動スケーリングのプロセスは通常、Kubernetes のアプリケーション容量をスケーリングする必要があるタイミングを示す一連の指標を決定することから始まります。次に、アプリケーションを拡大するか縮小するかを決定するために使用される一連のルールを設定します。最後に、さまざまな Kubernetes API を使用して、プログラムの実行とサービスのニーズに合わせてアプリケーションの利用可能なリソースを拡張します。

自動スケーリングは複雑なプロセスのように思えるかもしれませんが、特定のクラスのアプリケーションには他の手法よりも適しています。たとえば、アプリケーションの容量要件が頻繁に変更されない場合は、最大のトラフィックリソースをプロビジョニングするのが最適です。同様に、アプリケーションの負荷を確実に予測できる場合は、容量を自動ではなく手動で調整できます。

自動スケーリング機能は、アプリケーションの負荷の変化に対応するだけでなく、コストと容量の効率的な管理も可能にします。たとえば、クラスターの自動スケーリング機能を使用すると、クラスター内のノードの数を調整することで、パブリッククラウドのレンタル費用を節約できます。さらに、静的なアーキテクチャを使用している場合は、自動調整により、トラフィック負荷に割り当てられた容量を動的に管理できるため、インフラストラクチャをより有効に活用できます。

実際のアプリケーションでは、自動スケーリングは次の 2 つのカテゴリに分けられます。

1. 自動負荷調整：単一負荷の容量を動的に管理し、自動的に配分します。

2. クラスターの自動スケーリング: クラスターの容量を動的に管理します。

まず、Kubernetes での負荷スケーリングの詳細を見てみましょう。現在、Kubernetes 上のワークロードを自動的に調整するために使用できる標準化されたツールには、Horizontal Pod Autoscaler (HPA)、Vertical Pod Autoscaler (VPA)、Cluster Proportional Autoscaler (CPA) などがあります。次に、クラスターと簡単なテストアプリケーションを使用して、Kubernetes の自動スケーリング機能をシミュレートしてみましょう。

Linode-Kubernetes Engine クラスターを作成する

Linode が提供する Linode Kubernetes Engine (LKE) と呼ばれるマネージド Kubernetes サービスは、使い始めるのが非常に簡単です。無料の Linode アカウントにサインアップし、LKE 入門ガイドに従ってクラスターを作成できます。

下の図に示すように、それぞれ 2 つの CPU コアと 4 GB のメモリを備えた 2 つのノード (Linode と呼ばれます) で構成されるクラスターを作成しました。

LKE クラスター

このクラスターを使用するには、クラスターの概要セクションから kubeconfig ファイルをダウンロードする必要があります。 kubeconfig ファイルをマージする方法はいくつかありますが、私は KUBECONDIG 環境変数を kubeconfig ファイルへのパスで更新してマージすることを好みます。

次に、さまざまな自動スケーリングオプションをテストするための簡単なアプリケーションを構築しましょう。

圧力API

Pressure API アプリケーションは 2 つのエンドポイントで実行されます。これは、次の 2 つの方法でポッドに CPU とメモリの負荷をかけることができる .NET REST API です。

1. /memory/{numMegaBytes}/duration/{durationSec}: このエンドポイントは、指定されたメガバイト数をメモリに追加し、指定された期間、圧力をかけ続けます。

2. /cpu/{threads}/duration/{durationSec}: このエンドポイントは、指定された数のスレッドを CPU 上で実行し、指定された期間 CPU に負荷をかけ続けます。

アプリの完全なソースコードは次のとおりです。

 C #
 System.Xml を使用します。

 var ビルダー= WebApplication 。 CreateBuilder ( 引数);

 ビルダー。 サービス。 エンドポイントApiExplorerを追加します。
 ビルダー。 サービス。 SwaggerGen を追加します();

 var app = builder.Build () ;

 if ( app . Environment . IsDevelopment ())
 {
 app.UseSwagger () ;
 app.UseSwaggerUI () ;
 }

 アプリ。 MapPost ( "/memory/{numMegaBytes}/duration/{durationSec}" 、 ( long numMegaBytes 、 intdurationSec ) =>
 {
 // ReSharper は CollectionNeverQueried.Local を一度無効にします
リスト< XmlNode > memList = new ();

 試す
 {
 while ( GC . GetTotalMemory ( false ) <= numMegaBytes * 1000 * 1000 )
 {
 XmlDocument doc = new ();
 for ( var i = 0 ; i < 1000000 ; i ++ )
 {
 メモリリスト。 doc . CreateNode ( XmlNodeType . Element , "node" , string . Empty ) を追加します。
 }
 }
 }
 // メモリが利用できない場合は失敗しない
catch ( OutOfMemoryException ex )
 {
 Console.WriteLine (例) ;
 }

 糸。 スリープ( TimeSpan . FromSeconds ( 期間秒));
 memList.Clear () ;
 GC 。 集める（）;
 GC 。 ファイナライザーの待機();
 結果を返します。 わかりました（）;
 })
 .WithName ( "メモリをロード" );

 アプリ。 MapPost ( "/cpu/{threads}/duration/{durationSec}" , ( int スレッド数, int 継続時間秒) =>
 {
 キャンセルトークンソースcts = new ();
 ( var counter = 0 ; counter < threads ; counter ++ ) の場合
 {
 スレッドプール。 QueueUserWorkItem ( トークンイン=>
 {
 #pragma warning enable CS8605 // null の可能性がある値をアンボックス化します。
 var token = ( cancelToken ) tokenIn ;
 #pragma warning restore CS8605 // null の可能性がある値をアンボックス化しています。
 while ( ! token . IsCancellationRequested )
 {
 }
 }、 cts 。 トークン);
 }

 糸。 スリープ( TimeSpan . FromSeconds ( 期間秒));
 cts.Cancel () ;
 糸。 スリープ( TimeSpan.FromSeconds ( 2 ));
 cts.Dispose () ;
 結果を返します。 わかりました（）;
 })
 .WithName ( "LoadCPU" );


 app.Run () を実行します。

アプリケーションの詳細について心配する必要はありません。コンテナイメージと関連コンポーネントを GitHub リポジトリにダウンロード用に公開しました。このイメージはさまざまな K8s 仕様で使用できます。同時に、以下で使用するさまざまな Kubernetes 仕様がコードリポジトリの spec フォルダーに保存されます。ここでは、次の仕様を使用してアプリケーションを LKE クラスターにデプロイします。

ヤム
APIバージョン:アプリ/v1
 種類:デプロイメント
メタデータ:
  名前: pressure-api-deployment
 仕様:
  セレクター:
  マッチラベル:
  アプリ:圧力API
  レプリカ： 1
  テンプレート：
  メタデータ:
  ラベル:
  アプリ:圧力API
  仕様:
  コンテナ:
  - 名前: pressure-api
  画像: ghcr.io/rahulrai-in/dotnet-pressure-api :最新
 ポート:
  - コンテナポート: 80
  リソース：
  制限:
  CPU : 500m
  メモリ: 500Mi
 ---
 APIバージョン: v1
 種類:サービス
メタデータ:
  名前: pressure-api-service
  ラベル:
  実行: php-apache
 仕様:
  ポート:
  - ポート: 80
  セレクター:
     アプリ:圧力API

アプリケーションは現在リクエストを受け入れることができますが、クラスター内でのみアクセスできます。後で一時的なポッドを使用して、さまざまなリクエストを API に送信します。ただし、まずは自動スケーリングの最も一般的なコンポーネントである水平ポッド自動スケーリング (HPA) について説明しましょう。

水平ポッド自動スケーリング (HPA)

Horizontal Pod Autoscaling を使用すると、現在の負荷に基づいてクラスター内のポッドの数を動的に調整できます。 Kubernetes は、HorizontalPodAutoscaler リソースと kube-controller-manager にバインドされたコントローラーを通じて、水平自動スケーリングをネイティブにサポートします。 HPA は主に Kubernetes Metrics Server に依存して PodMetrics を提供します。 Metrics Server は、クラスター内の各ノードから CPU とメモリの使用状況を収集し、Metrics API を通じて利用できるようにします。次の図は、プロセスに関係するさまざまなコンポーネントを示しています。

水平ポッド自動スケーリング

Metrics Server は、kubelet エンドポイントの Summary API をポーリングして、ポッドで実行されているコンテナのリソース使用状況メトリックを収集します。デフォルトでは、HPA コントローラーはメトリックサーバーをプロキシし、Kubernetes API サーバーのメトリック API エンドポイントを 15 秒ごとにポーリングします。さらに、HPA コントローラーは、自動スケーリング構成を維持するために、HorizontalPodAutoscaler リソースを継続的に監視します。次に、HPA コントローラーは、さまざまな構成 (またはその他の構成済みリソース) に基づいて、対応する要件に合わせてデプロイメント内のポッドの数を更新します。最後に、デプロイメントコントローラーは、ReplicaSet を更新してポッドの数を調整することで変更に応答します。

HPA および VPA の前提条件として、公式ガイドに記載されている手順に従って、クラスターに Metrics Server をインストールできます。インストール中に TLS の問題が発生した場合は、次のようにリポジトリの spec ディレクトリにある metrics-server.yaml 仕様を使用します。

シェル
kubectl apply -f spec/metrics-server.yaml

ここで、次の yaml コンテンツに従って HorizontalPodAutoscaler オブジェクトを構成して、メモリリソースの平均使用率に基づいてデプロイメントを 5 つのレプリカにスケールし、1 つのレプリカにスケールダウンしてみましょう。

ヤム
apiバージョン: autoscaling/v2beta2
 種類: HorizontalPodAutoscaler
 メタデータ:
  名前: pressure-api-hpa
 仕様:
  スケールターゲット参照:
  APIバージョン:アプリ/v1
  種類:デプロイメント
 名前: pressure-api-deployment
  最小レプリカ数: 1
  最大レプリカ数: 5
  メトリクス:
  - タイプ:リソース
 リソース：
  名前:メモリ
 ターゲット:
  タイプ:利用
          平均使用率: 40

平均メモリ使用率が 40% を超えたままの場合、HPA はレプリカの数を増やし、逆の場合も同様です。このルールは CPU 使用率にも適用できます。この場合、HPA コントローラーはルールの組み合わせに基づいてレプリカの最大数を決定して使用します。

始める前に、次のコマンドを実行して、2 つの異なるターミナルウィンドウで HPA とそのデプロイメントを観察し、レプリカの数がリアルタイムで変化するのを確認しましょう。

シェル
kubectl で hpa pressure-api-hpa --watch を取得します。

 kubectl デプロイメントの取得pressure-api-deployment --watch

HPA をトリガーするには、一時的なポッドを起動し、/memory/{numBytes}/duration/{durationSec} エンドポイントにリクエストを送信します。次のコマンドは、HPA をトリガーしてポッドをスケールアップし、メモリ負荷を軽減します。

シェル
kubectl run -i --tty mem-load-gen --rm --image = busybox --restart = Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- --post-data= http://pressure-api-service/memory/1000/duration/180; done"

ターミナルウィンドウで、HPA がデプロイメントのレプリカの数を更新するのを確認できます。次のグラフは、アクティビティの使用率が目標に対してどのように増加したかを示しています。

HPAの活用

同時に、次の図からレプリカの変更も確認できます。

HPA によってトリガーされるレプリカ数の増加

HPA を使用する場合は、次の点に注意してください。

アプリケーションは、異なるインスタンス間で負荷を共有できる必要があります。
クラスターには、増加したポッド数に対応できる十分な容量が必要です。これは、必要な容量を事前にプロビジョニングし、アラートを使用してプラットフォームオペレーターにクラスターに容量を追加するように促すことで実現できます。もちろん、クラスターの自動スケーリングを使用してこれを行うこともできます。これについては後で説明します。
CPU とメモリは、アプリケーションのスケーリングを決定するための適切な指標ではない可能性があります。この場合、HPA (または VPA) をカスタムメトリックと組み合わせて使用し、Kubernetes Metrics Server の代わりにカスタムメトリックアダプターを使用してスケーリングを自動化できます。その中で、よく使用されるカスタムメトリックアダプターは、Prometheus アダプターと Kubernetes イベント駆動型オートスケーラー (KEDA) です。

VPA に進む前に、作成した HPA を削除し、次のコマンドを使用してデプロイされたレプリカの数をリセットします。

シェル
kubectl で hpa/pressure-api-hpa を削除します。

 kubectl スケール--replicas = 2デプロイメント/プレッシャー API デプロイメント

垂直ポッド自動スケーリング (VPA)

垂直ポッド自動スケーリングを使用すると、単一インスタンスのリソース容量を動的に調整できます。ポッドのコンテキストでは、ポッドが使用できる CPU およびメモリリソースの量を変更することになります。 HPA とは異なり、VPA では、メトリックサーバーに加えて 3 つのコントローラーコンポーネントをインストールする必要があります。次の図は、Kubernetes コンポーネントと VPA との相互作用を示しています。

垂直ポッド自動スケーリング

Recommender: ポッドのリソース使用量に基づいて最適な CPU とメモリの値を決定します。
アドミッションプラグイン: Recommender の推奨に基づいてポッドが作成されるときに、ポッドのリソース要求と制限を変更します。
Updater: Admission プラグインが再構築要求をインターセプトできるようにポッドを削除します。

クラスターを準備するには、VPA ガイドのインストール手順に従ってください。インストールが完了したら、次のコマンドを実行して VPA コンポーネントの動作ステータスを確認できます。

シェル
kubectl get pods -l "app in (vpa-recommender,vpa-admission-controller,vpa-updater)" -n kube-system

VPAポッドの健全性

次に、VPA スケーリング操作がどのように機能するかを理解しましょう。まず、リソース要求はポッド仕様の宣言を介して渡され、Kubernetes がポッドに必要な最小限のリソースを予約できるようにします。その後、VPA はポッドがリソース消費の限界に近づいていることを検出すると、新しい、より適切な値のセットを自動的に計算します。ポッド仕様でリソース要求とリソース制限を定義すると、VPA は値を更新するときに要求と制限の比率を維持します。さらに、VPA がリソース要求を更新するたびに、リソース制限が変更されます。

次の YAML に示すように、負荷を処理するためにポッドを追加せずに、CPU とメモリの要求を自動的に調整する VPA ポリシーを定義します。

ヤム
apiバージョン: "autoscaling.k8s.io/v1"
 種類: VerticalPodAutoscaler
 メタデータ:
  名前: pressure-api-vpa
 仕様:
  ターゲットリファレンス:
  apiバージョン: "apps/v1"
  種類:デプロイメント
 名前: pressure-api-deployment
  更新ポリシー:
  更新モード:再作成
 リソースポリシー:
  コンテナポリシー:
  - コンテナ名: "*"
  最小許容値:
  CPU : 0分
 メモリ: 0Mi
  最大許容数:
  CPU : 1
  メモリ: 2000Mi
  制御リソース: [ "CPU" 、 "メモリ" ]
         制御された値:リクエストと制限

この仕様はデプロイメント内のすべてのコンテナに適用され、その最小および最大のしきい値により、VPA が妥当な制限内で動作することが保証されます。 managedResources フィールドは、VPA によって自動的にスケーリングされるリソースを指定します。

現在、VPA は 4 つの更新モードをサポートしています。このうち、自動スケーリングを有効にするには、再作成モードと自動モードのみを使用します。ただし、実際の使用例はより限定されています。初期モードでは、リソース値が作成されるときにその値に対するアドミッションコントロールが強制され、もちろん Updater がポッドを排除するのを防ぎます。オフモードが最も実用的です。このモードでは、VPA はリソースをスケーリングしませんが、リソース値を推奨します。したがって、アプリケーションが本番環境に入る前に、このモードを使用して、アプリケーションの包括的な負荷テストと分析中に最適なリソース値を計算し、それを本番展開の仕様に適用してエンジニアリングの労力を節約することができます。

これに、以前の仕様を適用し、次のコマンドを実行して自動スケーリングを監視できます。

シェル
kubectl で vpa/pressure-api-vpa を取得します--watch

次に、次のコマンドを使用して CPU に負荷をかけ、VPA をアクティブ化します。

シェル
kubectl run -i --tty mem-load-gen --rm --image = busybox --restart = Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- --post-data= http://pressure-api-service/cpu/10/duration/180; done"

しばらくすると、次のコマンドを実行して、VPA によって生成された推奨事項を表示できます。

シェル
kubectl で vpa/pressure-api-vpa を記述します。

以下は、VPA からの推奨事項を示す上記のコマンドの出力です。

VPAの推奨事項

ご覧のとおり、CPU およびメモリ要求のベースラインとしてターゲット値を使用することが推奨されています。 VPA 仕様で定義されている上限と下限が最適でない場合は、Uncapped Target をベースラインとして使用し、minAllowed 制約と maxAllowed 制約なしでターゲット推定値を表します。

さらに、垂直自動スケーリングが有効になっているため、新しく作成されたポッドには、アドミッションコントローラーによって実行される VPA のさまざまな注釈が含まれます。次のコマンドを使用して、ポッドの注釈を表示できます。

シェル
kubectl get pod <ポッド名> -o jsonpath = '{.metadata.annotations}'

上記のコマンドの出力は次のとおりです (K9s コンソールから、https://github.com/derailed/k9s):

ポッド注釈

次のタイプの自動スケーリングについて説明する前に、次のコマンドを使用して現在のデプロイメントを削除してリセットしましょう。

シェル
kubectl で vpa/pressure-api-vpa を削除します。
 kubectl スケール--replicas = 1デプロイメント/圧力 API デプロイメント

クラスター比例自動スケーリング (CPA)

クラスター比例自動スケーリング (CPA) は、水平ポッド自動スケーリングの一種です。クラスター内のノードの数に基づいてレプリカをスケーリングします。他の自動スケーリングとは異なり、Metrics API に依存せず、Metrics Server も必要ありません。さらに、CPA はスケーリングを実装するために Kubernetes リソースを使用せず、代わりにさまざまなフラグを使用してターゲット負荷を識別し、ConfigMap を使用してスケーリング構成を行います。次の図は、CPA のさまざまなコンポーネントを示しています。

クラスターの比率を自動的に調整する

CPA の使用例はより限定されています。たとえば、CPA は、クラスター化された DNS などのスケールアウトプラットフォームサービスによく使用されます。多くの場合、デプロイ先のクラスターの負荷に応じて自動的にスケーリングする必要があります。 CPA のもう 1 つの使用例は、Metrics Server や Prometheus アダプターを使用する必要がないため、シンプルなメカニズムを通じてさまざまな負荷に合わせてスケーリングできることです。

CPA の Helm チャートを使用し、クラスターに CPA をインストールし、次のコマンドを使用して cluster-proportional-autoscaler の Helm リポジトリを追加できます。

シェル
helm リポジトリに cluster-proportional-autoscaler を追加します https://kubernetes-sigs.github.io/cluster-proportional-autoscaler
 helm リポジトリの更新

チャート値ファイルで自動スケーリングのルールを定義して、指定した構成に基づいて構成マップを作成できます。これにより、チャートを再インストールしなくても、後続の ConfigMap を編集して自動スケーリングの動作を変更できるようになります。

cpa-values.yaml という名前のファイルを作成し、次の内容を追加してください。

ヤム
設定:
  はしご：
  レプリカノード:
  - [ 1 , 3 ]
  - [ 2 , 5 ]
 オプション:
  名前空間:デフォルト
  ターゲット: "deployment/pressure-api-deployment"

次のいずれかのスケーリング方法を使用するように CPA を指定できます。

線形: クラスター内のノードまたはコアの数に正比例してアプリケーションをスケーリングします。
ラダー: ステップ関数を使用して、ノード:レプリカおよび/またはコア:レプリカの比率を決定します。

上記の例では、クラスター内にノードが 1 つある場合、CPA はデプロイメントを 3 つのレプリカに拡張します。次のコマンドを使用してチャートをインストールし、設定を行うことができます。

シェル
helm アップグレード--install cluster-proportional-autoscaler \
    クラスター比例オートスケーラー / クラスター比例オートスケーラー--values cpa-values.yaml

CPA のインストールが完了すると、クラスターに 2 つのノードがあるため、pressure-api-deployment を 5 つのレプリカに拡張できることがわかります。

また、自動クラスタースケーリングについて説明する前に、次のコマンドを使用して既存のデプロイメントを削除しましょう。

シェル
helm クラスター比例オートスケーラーを削除します

コア Kubernetes とコミュニティによって構築されたアドオンを使用して負荷分散を自動化する方法について説明しました。次に、Kubernetes クラスター自体をスケーリングする方法について説明します。

クラスター自動スケーリング (CA)

Kubernetes クラスターの容量を手動で増減すると、クラスターの管理コストとエンジニアリングの作業負荷が大幅に増加するため、CA を HPA と組み合わせて使用する必要があります。 HPA がコンピューティングリソースの限界に近づき始めると、CA は満たす必要のあるノードの数を計算し、クラスターに新しいノードを追加できます。さらに、CA は、一部のノードが長時間完全に使用されていないことを検出した場合、ポッドを他のノードに再スケジュールし、十分に使用されていないノードをクラスターから削除することができます。

クラスターの自動スケーリングの具体的な実装は、クラウドサービスプロバイダーによって異なります。たとえば、Azure や AWS などのクラウドサービスプロバイダーは Cluster API をサポートし、Kubernetes オペレーターを使用してクラスターアーキテクチャを管理します。クラスターの自動スケーリングは、ノード数をクラスター API コントローラーにオフロードすることによっても実現できます。自動クラスターチューニングを実装する前に、次の点を慎重に検討してください。

1. 負荷がかかった状態でアプリケーションがどのように動作するかを理解し、アプリケーションの水平方向のスケーリングを妨げるボトルネックを排除します。

2. クラウドサービスプロバイダーが適用するスケーリング上限を理解します。

3. クラスターがオンデマンドでどれだけ速く拡張できるかを把握します。

LKE でクラスターの自動スケーリングを有効にするのは非常に簡単です。まず、クラスターの概要ページに移動し、次の図に示すように、[Autoscale Pool] ボタンをクリックします。

LKE クラスターの概要ページ

次に、次のダイアログで、LKE が維持するノードの最小数と最大数を入力します。

LKE による自動クラスタースケーリングを有効にする

LKE のクラスター自動スケーリングは、コンピューティングリソースが不足しているためにスケジュールできない保留中のポッドに対応できるほか、十分に活用されていないノードを監視してクラスターから削除することで、クラスターの全体的なサイズを縮小することもできます。

以下では、2 つの CPU コアと 4 GB のメモリが割り当てられた 2 ノードクラスターについて説明します。クラスターの自動スケーリングをトリガーするには、次のコマンドを使用してアプリケーションにレプリカを追加します。

シェル
kubectl スケール--replicas = 15デプロイメント/プレッシャー API デプロイメント

コマンドを実行すると、次の図に示すように、デプロイされたポッドが停止状態になっていることがわかります。

スケジュール待ちのポッド

次の図に示すように、LKE はすぐにクラスターにノードを追加し、新しいノード上でそれらをスケジュールします。

LKE 拡張クラスター

LKE を最大 4 つのノードにスケールアウトするように指定したため、一部のポッドがまだ保留中であることがわかります。最後に、以下のコマンドで環境をクリーンアップしましょう。

シェル
kubectl デプロイメント/圧力 API デプロイメントを削除します

まとめ

要約すると、水平自動スケーリング、垂直自動スケーリング、クラスター自動スケーリングの概念、ユースケース、考慮事項について説明しました。 LKE などのマネージド Kubernetes サービスは、組み込みの自動調整ツールを通じて、さまざまな手動管理の作業負荷を軽減できます。要約すれば：

アプリケーションの容量要件が頻繁に変更される場合は、HPA を使用して水平方向にスケーリングできます。
VPA は、アプリケーションに最適なリソース値を決定するのに役立ちます。
CPA は、クラスター内の負荷に合わせて拡張する必要があるアプリケーションのニーズを満たすのに役立ちます。
負荷がクラスター自体の容量を超えて拡大する可能性がある場合には、クラスター自体を自動的にスケーリングするために CA が必要になります。

翻訳者について

51CTO コミュニティの編集者である Julian Chen 氏は、IT プロジェクトの実装において 10 年以上の経験を持っています。社内外のリソースとリスクの管理に長けており、ネットワークと情報セキュリティの知識と経験の普及に注力しています。彼は、ブログ投稿、特別トピック、翻訳の形で最先端のテクノロジーと新しい知識を共有し続けています。彼はオンラインとオフラインで情報セキュリティのトレーニングや講義を頻繁に行っています。

原題: Linode Kubernetes Engine を使用した Kubernetes 自動スケーリングツールの実践的な入門、著者: Rahul Rai

<<: 3大事業者が共同で躍進：中国のパブリッククラウド市場が急成長

>>: クラウドサービスの費用管理を最適化するための4つのヒント