This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

コンテナの管理

コンテナ テクノロジーにより、組織には次のようなさまざまなメリットが得られます。

  • コンテナにより、複数のプラットフォームを対象に移行可能なビジネス ロジックの軽量パッケージングが利用できるようになります。
  • 小規模のチームでは基盤となるクラスタの管理が可能である一方、複数のソフトウェア チームではクラスタを共有リソースとして利用することにより、効率化を図ることができます。チームでは、新しい機能を迅速に、しかもスムーズに提供できるようになります。
  • 新しいコンテナは、わずか数ミリ秒で起動されるため、コンテナのスケジュールは必要に応じて決めることができます。

ただし、組織がコンテナ テクノロジーの利用を進めるに伴い、2 つの重要なガバナンスの課題が浮かび上がってきます。

  • 適正サイジング：複数のチームがクラスタに新しいソフトウェアを展開します。各チームの規模が大きくなるに従い、時間の経過とともに変化するソフトウェア ワークロードに応じて適切なハードウェア構成（CPU とメモリ）のプロビジョニングを管理するのが難しくなってきます。
  • リソースの割り当て：ワークロードの要件は急速に変化するため、一定の期間に各チームが共有リソースをどのように利用しているかを追跡することが難しくなります。結果として、組織は使用量とコストを特定のチームや部門に起因すると考える課題に直面し、予算の追跡とガバナンスの定義が困難になります。

VMware Aria Cost は、サービス別およびチーム別のコンテナ リソースの使用率を、長期的かつ可視化されたトレンドで提供します。このモジュールは、最もリソースを消費しているサービスを特定し、最適化に向けた機会を探る際に役立ちます。

モジュールを利用して次のことが可能になります。

  • サービスやチームごとにクラスタ リソースの利用状況を把握する
  • ワークフローを支援するクラスタで各リソースが適切に組み合わせられているかを評価する
  • 支出を削減するために、無駄な領域または使用率の低下している領域を特定する

Container Governance Module では、すべてのクラウド環境でコンテナがサポートされます。このモジュールでサポートされるオーケストレーション ソリューションは次のとおりです。

  • Kubernetes：Community、OpenShift、EKS
  • Amazon ECS

モジュールを使用するには、環境中のクラスタごとにコレクタという軽量コンテナを展開します。個々のノード レベルでのインストールは必要ありません。

VMware Aria Cost での Kubernetes の使用開始

環境内の各クラスタにコレクタと呼ばれる軽量コンテナを展開し、コレクタがコンテナ環境からメタデータを収集できるようにします

Amazon ECS をオーケストレーション ソリューションとして使用している場合は、「VMware Aria Cost での Amazon ECS の使用開始」を参照してください。

VMware Aria Cost で Kubernetes の使用を開始するには、次の 2 つの方法があります。1.環境内の各クラスタに VMware Aria Cost コレクタを自動的に展開するように Helm チャートを設定します。2.展開ファイルを使用して、VMware Aria Cost コレクタを各クラスタに展開します。

オプション 1：VMware Aria Cost コレクタを自動的に展開するように Helm チャートを設定する

Helm チャートを使用して、VMware Aria Cost コレクタ エージェントと呼ばれる軽量コンテナを環境内の各 Kubernetes クラスタに展開します。コレクタは、環境からメタデータを収集してレポートを生成します。

コレクタによって収集されるデータについて

VMware Aria Cost は、コレクタを通じて 2 つのカテゴリのデータを収集します。

  • メモリおよび CPU に関して利用可能なノードレベルのハードウェア リソース。
  • メモリおよび CPU に関して測定される、クラスタで実行されているワークロード、およびそれらのリソース割り当て。

前提条件

  • Kubernetes バージョン 1.12 以降
  • クラスタに VMware Aria Cost コレクタを展開するための管理者権限。
  • Helm 3.0+

Helm チャートのインストール

  1. VMware Aria Cost API トークンを見つけます。クラスタ > クラスタの追加 > Kubernetes (Helm 経由) に移動します。
  2. VMware Aria Cost API トークンは、$ export CHT_API_TOKEN= の行に一覧表示されます。
  3. リリース名 cloudhealth-collector を使用して Helm チャートをインストールします。
    $ helm repo add cloudhealth https://cloudhealth.github.io/helm/
$ helm install cloudhealth-collector --set apiToken=<CloudHealth API Token>,clusterName=<Cluster Name> cloudhealth/cloudhealth-collector

これらのコマンドは、デフォルト構成で Kubernetes クラスタに VMware Aria Cost コレクタを展開します。インストール中に構成可能なパラメータを表示するには、Helm チャート GitHub ページ にアクセスします。

結果：Helm チャートがインストールされ、環境で構成されている新しいクラスタに VMware Aria Cost コレクタが展開されます。

オプション 2：展開ファイルを使用して、VMware Aria Cost コレクタを各クラスタに展開する

Kubernetes クラスタごとにコレクタを構成します。次に、コレクタを展開して、VMware Aria Cost がコンテナ環境に関するメトリックの収集を開始できるようにします。

  1. VMware Aria Cost プラットフォームで左側のメニューから セットアップ > コンテナ > クラスタ > クラスタの追加 の順に選択します。
  2. 表示されるダイアログ ボックスで、クラスタのわかりやすい名前を入力します。VMware Aria Cost は、この名前を使用してインストール手順をカスタマイズします。名前は VMware Aria Cost のインタラクティブ レポートにも表示されます。
  3. クラスタの追加 をクリックします。
  4. ポップアップに表示される指示に従って、クラスタにコレクタを展開します。手順には、クラスタ固有の詳細が含まれています。

変数と値の間に、等号は使用できません。また、変数は %VARIABLENAME% ではなく $VARIABLENAME として参照される必要があります。

コレクタの展開の手順にはいつでも戻ることができます。作成されたクラスタは セットアップ > コンテナ > クラスタ のページに表示されます。

結果：VMware Aria Cost コレクタがクラスタに展開されます。

コレクタのステータス

コレクタが展開されると、すぐにクラスタからのメトリックの収集を開始しますが、履歴情報のバックフィルは行われません。VMware Aria Cost がコレクタからのデータの受信を開始すると、クラスタのステータスが [正常] に切り替わります。

コレクタが展開された後、VMware Aria Cost プラットフォーム内に可視化された意味のある情報が表示されるまでに最大 24 時間かかることがあります。

セットアップ > コンテナ > クラスタ ページには、クラスタの次の 3 つの状態が表示されます。

  • 不明：コレクタがデータを一度も VMware Aria Cost に送信していないか、2 日以上データを VMware Aria Cost に送信していません。
  • 正常：コレクタは Kubernetes コンテナ クラスタに正常に展開され、過去 15 分間にデータを VMware Aria Cost に正常にプッシュしました。
  • 異常：コレクタは過去 2 日以内に VMware Aria Cost に接続しましたが、直近 15 分間は接続していません。

コレクタがメトリックを収集していることを確認するには、メトリック 列を使用します。

  • アクティブ：
  • 非アクティブ：

（オプション）クラスタ コストのグループ化と配分

VMware Aria Cost プラットフォームを使用し、パースペクティブを使用してコンテナの資産を編成します。この編成の目的は、特定のコンテナ タスクを、実際に実行するコンテナ資産にマッピングすることにあります。

  • クラスタをサポートするハードウェアを 1 つ以上のパースペクティブ グループに収集します。専用のコンピューティング リソースとストレージ リソース、および共有リソースを含めます。
  • コンテナ化されたワークロードを、意味のあるパースペクティブ グループに収集します。このグループが、ハードウェア リソースの以前のグループを含む同じパースペクティブに属している必要はありません。
  • 1 つ以上のコンテナ コスト配分ルールを定義して、ワークロード グループにハードウェア グループのコストを割り当てます。配分よりも細かく調整したコントロールに対するルールを定義します。

クラスタ コストのグループ化と配分の詳細については、コスト分析のためのコンテナ インフラストラクチャの構成を参照してください。

Kubernetes の構成の問題に関するトラブルシューティング

コレクタが正常に機能していることを確認する

構成を確認する

kubectl get --namespace cloudhealth pods

コレクタ ログを確認する

  1. ポッドの名前を特定します。
    kubectl get --namespace cloudhealth pods
  2. 次のコマンドでポッドの名前を指定して、ポッドのログを取得します。ポッド名は実行時に Kubernetes によって生成されます。
    kubectl logs --namespace cloudhealth <pod-name>

メトリック収集の確認

コレクタが最新バージョンで、メトリックを収集できることを確認します。[コンテナ クラスタ] ページで メトリック 列が 正常 であることを確認します。

メトリック 列に 異常 ステータスが表示される場合は、コレクタを手動で、または Helm を使用して更新します。

  • Helm：$ helm upgrade cloudhealth-collector cloudhealth/cloudhealth-collector
  • 手動更新：既存のコレクタを削除して再インストールします。詳細については、クラスタ > コレクタの展開手順 を選択し、手動によるコレクタの更新 の手順に従ってください。

Kubernetes コレクタ エージェントのトラブルシューティング

コレクタ エージェントのログの確認

  1. ポッドの名前を特定します。
    kubectl get --namespace cloudhealth pods
  2. 次のコマンドでポッドの名前を指定して、ポッドのログを取得します。ポッド名は実行時に Kubernetes によって生成されます。
    kubectl logs --namespace cloudhealth <pod-name>

出力例：


  CHT Containers Collector Environment

  CHT_API_TOKEN: ****

  CHT_CLUSTER_NAME: testCluster

  JAVA_OPTS:
    -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap
    -XX:MaxRAMFraction=1 -XX:+ExitOnOutOfMemoryError -Xms10M -Xmx891M

  CHT_INTERVAL: 900

=========================================================================

CHT Containers Collector : version DIRTY starting
I, [2021-02-01T23:19:39.211985 #11]  INFO -- : loaded K8S config from  with master @ https://kubernetes.default.svc/ with ca certificate /var/run/secrets/kubernetes.io/serviceaccount/ca.crt with client_cert_file  with client key file  with trust_certs false with trust store file  with proxy username
D, [2021-02-01T23:19:39.732649 #11] DEBUG -- : Ensuring cache directory is present: /tmp/cache
D, [2021-02-01T23:19:39.793997 #11] DEBUG -- : Fetching state...
D, [2021-02-01T23:19:39.798196 #11] DEBUG -- : Connecting to URL: https://kubernetes.default.svc/api/v1/nodes
D, [2021-02-01T23:19:40.588497 #11] DEBUG -- : Connecting to URL: https://kubernetes.default.svc/api/v1/pods
D, [2021-02-01T23:19:40.610918 #11] DEBUG -- : Connecting to URL: https://kubernetes.default.svc/api/v1/services
D, [2021-02-01T23:19:40.618938 #11] DEBUG -- : Posting state...
D, [2021-02-01T23:19:40.622422 #11] DEBUG -- : Posting state from 2021-02-01 23:19:39 +0000: /tmp/cache/kubernetes_nodes_1612221579 (size: 1685)
E, [2021-02-01T23:19:40.703980 #11] ERROR -- : Not Found [404]: Failed to post cluster state to http://10.108.1.248:9292/v1/containers/kubernetes/state?auth_token=API_TOKEN_REDACTED&cluster_id=testCluster&sample_time=1612221579.0. Error: Could not find: http://127.0.0.1:8500/v1/kv/customer_container/blobs/

上記のログの例から、次の情報を取得できます。

  • ノード、ポッド、およびサービスのデータを収集するために、3 つの特定のエンドポイントに対する Kubernetes API からの状態が取得されます。このデータは、/tmp/cache にある 3 つの個別のキャッシュ ファイルに格納されます。
  • 次の手順では、3 つの要求が VMware Aria Cost 収集エンドポイントに戻され、これらのキャッシュ ファイルからノード、ポッド、およびサービスが投稿されます。最初の投稿状態では、(size: 1685) に示されたサイズのキャッシュ ファイル /tmp/cache/kubernetes_nodes_1612221579 からノード データを送信しようとします。この値が 0 の場合、Kubernetes からのデータはなく、クラスタの問題を調査する必要があります。
  • 最後のエラー行は、VMware Aria Cost 収集エンドポイントに対する要求の作成に関する問題を示します。

Kubernetes クラスタの検証

Kubernetes クラスタを検証するには、次のコマンドを実行します。

  1. ポッドが実行中か確認します。kubectl get pods --all-namespaces -o wide | grep cloudhealth
  2. Kubernetes API を手動で要求して、アクセス可能であることを確認します。例：https://kubernetes.default.svc/api/v1/nodes。

コレクタ エージェントの接続の検証

収集エンドポイントへのコレクタ エージェントの接続を検証するには、次のコマンドを実行します。

  1. nmap または netcat を使用してポート 443 に ping を送信します。

    • nmap -p 443 api.cloudhealthtech.com
    • nc -zv api.cloudhealthtech.com 443

  2. 収集エンドポイントに対して CURL コマンドを手動で実行します。

    • curl -v -X GET https://containers-api.edge.cloudhealthtech.com/api/v1/health：収集健全性エンドポイントを要求します。
      想定される応答：{"status":"healthy","time":"Fri, 29 Jan 2021 22:48:10 GMT"}
    • curl --header "Content-Type: application/json" --request POST --data '{"auth_token":"INSERT_AUTHENTICATION_TOKEN_HERE","cluster_id":"INSERT_CLUSTER_ID_HERE"}' https://containers-api.edge.cloudhealthtech.com/v1/containers/kubernetes/state：コレクタ エージェントによって行われた正確な要求をモックします（k8s データ キャッシュ ペイロードがない場合を除く）。必要に応じて、auth_token と cluster_id を置き換えます。
      想定される応答（ペイロードを送信しなかったため）：{"result":null}

よくある問題を回避する方法

クラスタの元のアドレスが次のようになっていることを確認します。

  • クラスタ内で解決できる（DNS 名である場合）。
  • クラスタ内からアクセスできる（ファイアウォールやその他のネットワークの制約を確認）。

コレクタが次のようになっていることを確認します。

  • 正常にスケジュール設定されており、クラスタ内に十分なリソースがある。
  • OOM エラーによって停止しない。コレクタが停止する場合は、コンテナのメモリ制限値を大きい値に変更します。
  • 最新バージョンを実行している。
check-circle-line exclamation-circle-line close-line
Scroll to top icon