このページでは、Docker の可視性を有効にしたマシンエージェントを設定し、Kubernetes クラスタで DaemonSet として実行する方法について説明します。

コンテナの可視性により、Kubernetes ポッド内で実行されているコンテナ化されたアプリケーションをモニタし、アプリケーションのパフォーマンスに影響を与えるコンテナの問題を特定できます。Kubernetes クラスタのすべてのノードで、マシンエージェントを Kubernetes DaemonSet として展開します。マシンエージェントを DaemonSet として展開すると、すべての Kubernetes ワーカーノードがマシンエージェントを実行して、ノードホストおよび関連付けられた Docker コンテナの両方から重要なリソースメトリックを収集するようになります。 

Kubernetes コンテナをモニタするための Docker の可視性の使用は、推奨オプションではなくなり、廃止されます。「 クラスタエージェントを使用した Kubernetes のモニタリング」の説明に従って、代わりにクラスタエージェントを使用します。クラスタエージェントは、クラスタの正常性とキャパシティに対する可視性だけでなく、Kubernetes コンテナの可視性もサポートします。

Kubernetes を使用したコンテナの可視性

Docker 対応モードでマシンエージェントを展開します。Docker を使用してマシンエージェントを設定および実行するには、「Docker の可視性の設定」を参照してください。 

マシンエージェント：

  • Kubernetes によって管理されているコンテナを特定します。
  • これらのコンテナにアプリケーション サーバ エージェントが含まれているかどうかを確認します。
  • アプリケーション サーバ エージェントが含まれるコンテナを、そのアプリケーションの APM ノードと関連付けます。

次の図は、Kubernetes でのコンテナの可視性の展開シナリオを示しています。

Container Visibility Deployment Scenario

  • マシンエージェントコンテナ（）を各 Kubernetes ノードの DaemonSet としてインストールします。
  • ポッド内の任意のコンテナから APM メトリックを収集するには、ポッドを展開する前に、正しいアプリケーション サーバ エージェント（）をコンテナにインストールします。
  • マシンエージェントは、モニタ対象（）の各コンテナのリソース使用率メトリック、およびホストのマシンとサーバのメトリックを収集し、このメトリックをコントローラに転送します。
  • （オプション）モニタするノードでネットワークエージェント（）を DaemonSet としてインストールします。ネットワークエージェントは、モニタ対象のアプリケーション コンポーネント間のすべてのネットワーク接続のメトリックを収集し、そのメトリックをコントローラに送信します。

はじめる前に

Kubernetes を使用したコンテナの可視性については、次の要件を確認します。

  • マシンエージェントは、モニタするすべての Kubernetes ノードで DaemonSet として実行する必要があります。

  • モニタ対象のすべてのノードにサーバの可視性ライセンスが必要です。

  • 各マシンエージェントで Docker の可視性を有効にする必要があります。

  • アプリケーション サーバ エージェントとマシンエージェントの両方が同じアカウントによって登録されていて、同じコントローラを使用します。
  • 同じポッドで複数のアプリケーション サーバ エージェントを実行している場合は、アプリケーション サーバ エージェントとマシンエージェントのそれぞれで、ホスト ID としてコンテナ ID を登録します。

制限

  • Docker コンテナランタイムのみがサポートされています。
  • ポッドと ReplicaSet ラベルのみがサポートされています。

手順

  1. コンテナの可視性の有効化
  2. ホスト ID としてコンテナ ID を登録する
  3. クラスタロールの設定
  4. Kubernetes でのマシンエージェントの展開

マシンエージェントが Kubernetes に展開されたら、アプリケーション サーバ エージェントをイメージに追加できます。

コンテナの可視性の有効化

コントローラを 4.4.3 以降に更新します。

環境での Kubernetes の可視性を有効にするには、次のパラメータを編集します。 

  • コントローラ
    • sim.machines.tags.k8s.enabled：値のデフォルトは true です。グローバルタグに対応するフラグはこれよりも優先されます。 
    • sim.machines.tags.k8s.pollingInterval：値のデフォルトは 1 分です。ポーリング間隔に設定できる最小値は 30 秒です。
  • マシンエージェント
    • k8sTagsEnabled：値のデフォルトは true に設定され、ServerMonitoring.yml ファイルに指定されます。 

「Red Hat OpenShift での Docker の可視性の使用」に進みます。DaemonSet の例、マシンエージェントのサンプル Docker イメージ、およびサンプル Docker 開始スクリプトを使用すると、マシンエージェントを設定できます。

ホスト ID としてコンテナ ID を登録する

アプリケーションメトリックを収集するには、Kubernetes ポッド内のすべてのコンテナにアプリケーション サーバ エージェントをインストールします。たとえば、RedHat OpenShift プラットフォームで複数のアプリケーション サーバ エージェントが同じポッドで実行されている場合、ポッドからコンテナ固有のメトリックを収集するために、アプリケーション サーバ エージェントとマシンエージェントの両方で、コンテナ ID を一意のホスト ID として登録する必要があります。Kubernetes ポッドには複数のコンテナを含めることができ、同じホスト ID を共有することができます。マシンエージェントは、各コンテナ ID がホスト ID として登録されていない限り、ポッドで実行されているさまざまなコンテナを識別できません。 

コンテナ ID をホスト ID として登録するには、次のようにします。

  1. cgroup からコンテナ ID を取得します。

    cat /proc/self/cgroup | awk -F '/' '{print $NF}'  | head -n 1
    CODE

  2. アプリケーション サーバ エージェントを登録します。

    -Dappdynamics.agent.uniqueHostId=$(sed -rn '1s#.*/##; 1s/(.{12}).*/\1/p' /proc/self/cgroup)
    CODE

  3. マシンエージェントを登録します。

    -Dappdynamics.docker.container.containerIdAsHostId.enabled=true
    CODE

クラスタロールの設定

次に、さまざまな Kubernetes リソースへの読み取りアクセスを提供するクラスタロール定義の例を示します。これらの権限によって、マシンエージェントおよびポッドメタデータの収集に対して Kubernetes 拡張機能を有効にします。ロールは appd-cluster-reader という名前ですが、変更することもできます。クラスタロールの定義には、このロールのメンバーが使用できるさまざまな API グループの概要が表示されます。各 API グループに対して、アクセスできるリソースとアクセス方式のリストを定義します。これらの API エンドポイントから情報を取得する必要があるため、"get"、"list"、および "watch" の動詞で表される読み取り専用アクセスが必要になります。

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: appd-cluster-reader
rules:
- nonResourceURLs:
      - '*'
  verbs:
      - get
- apiGroups: ["batch"]
  resources:
    - "jobs"
  verbs: ["get", "list", "watch"]
- apiGroups: ["extensions"]
  resources:
    - daemonsets
    - daemonsets/status
    - deployments
    - deployments/scale
    - deployments/status
    - horizontalpodautoscalers
    - horizontalpodautoscalers/status
    - ingresses
    - ingresses/status
    - jobs
    - jobs/status
    - networkpolicies
    - podsecuritypolicies
    - replicasets
    - replicasets/scale
    - replicasets/status
    - replicationcontrollers
    - replicationcontrollers/scale
    - storageclasses
    - thirdpartyresources
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources:
    - bindings
    - componentstatuses
    - configmaps
    - endpoints
    - events
    - limitranges
    - namespaces
    - namespaces/status
    - nodes
    - nodes/status
    - persistentvolumeclaims
    - persistentvolumeclaims/status
    - persistentvolumes
    - persistentvolumes/status
    - pods
    - pods/binding
    - pods/eviction
    - pods/log
    - pods/status
    - podtemplates
    - replicationcontrollers
    - replicationcontrollers/scale
    - replicationcontrollers/status
    - resourcequotas
    - resourcequotas/status
    - securitycontextconstraints
    - serviceaccounts
    - services
    - services/status
  verbs: ["get", "list", "watch"]
- apiGroups:
  - apps
  resources:
    - controllerrevisions
    - daemonsets
    - daemonsets/status
    - deployments
    - deployments/scale
    - deployments/status
    - replicasets
    - replicasets/scale
    - replicasets/status
    - statefulsets
    - statefulsets/scale
    - statefulsets/status
  verbs:
    - get
    - list
    - watch
- apiGroups:
  - apiextensions.k8s.io
  resources:
    - customresourcedefinitions
    - customresourcedefinitions/status
  verbs:
    - get
    - list
    - watch
- apiGroups:
  - apiregistration.k8s.io
  resources:
    - apiservices
    - apiservices/status
  verbs:
    - get
    - list
    - watch
- apiGroups:
  - events.k8s.io
  resources:
    - events
  verbs:
    - get
    - list
    - watch
CODE

ロールを定義したら、クラスタ ロール バインディングを作成して、そのロールをサービスアカウントに関連付ける必要があります。この ClusterRoleBinding の仕様例では、appd-cluster-reader サービスアカウントがプロジェクト "myproject" 内の appd-cluster-reader-role のメンバーになります。命名は単に偶然によるものです。サービスアカウントとクラスタロールの名前が一致している必要はありません。

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cluster-reader-role-binding
subjects:
- kind: ServiceAccount
  name: appd-cluster-reader
  namespace: myproject
roleRef:
  kind: ClusterRole
  name: appd-cluster-reader
  apiGroup: rbac.authorization.k8s.io
CODE

Kubernetes でのマシンエージェントの展開

AppDynamics マシンエージェントは、init コンテナを必要としない単一のコンテナイメージで展開できます。デフォルトでは、マシンエージェントは DaemonSet としてクラスタに展開され、すべてのクラスタノードに対してすべてのエージェントインスタンスを均等に分散します。必要に応じて、ノードのアフィニティルールまたはアンチアフィニティルールを使用して DaemonSet を構成し、クラスタ全体ではなく、必要なノードセットに展開されるようにすることができます。ノードアフィニティについては、「Assigning Pods to Nodes」を参照してください。

ポッドメタデータを収集するには、マシンエージェントの展開に使用されるサービスアカウントに OpenShift の cluster-reader  ロールが必要です。マシンエージェントへの Kubernetes 拡張機能には、cluster-reader ロールも必要です。

# assigning cluster-reader role in OpenShift
oc adm policy add-cluster-role-to-user cluster-reader -z appd-account
BASH

vanilla Kubernetes ディストリビューションを使用している場合は、OpenShift の cluster-reader に類似したビルド済みクラスタロールがない可能性があります。「ClusterRole の設定」を参照してください。

Kubernetes を使用したアプリケーションのインストゥルメント化

Kubernetes を使用して展開されたアプリケーションのインストゥルメント化にはいくつかの方法があり、選択する方法は、特定の要件と DevOps プロセスによって異なります。AppDynamics を使用してアプリケーションコンテナをモニタするには、次の方法でそのコンテナにアプリケーション サーバ エージェントを含める必要があります。

  • アプリケーション サーバ エージェントが事前にインストールされている適切なベースイメージを使用する。
  • init コンテナを使用して、コンテナの起動の一部としてアプリケーション サーバ エージェントを動的にロードする。
  • アプリケーション サーバ エージェントをロードして、実行中のプロセスへ動的に接続する（言語ランタイムをサポートしている場合）。

3 つ目のオプションは、通常、Java ベースのアプリケーションにのみ適用されます。これは、JVM がダイナミック接続をサポートし、AppDynamics Java APM エージェントの標準機能だからです。「Dynamic Java Instrumentation」を参照してください。

その他のオプションについては、「Deploying AppDynamics Agents to OpenShift Using Init Containers」で説明されているように、Init コンテナ、ConfigMaps、および Secrets などの標準的な Kubernetes 機能を使用することが一般的な方法です。

リソース制限値

モニタ対象のメインアプリケーションでは、リソース制限が定義されている必要があります。CPU に 2% のパディングを提供し、最大 100 MB のメモリを追加します。

最大 500 個のコンテナをサポートするために、次のリソースの要求（Mem = 400M, CPU = "0.1"）と制限（Mem = 600M, CPU = "0.2"）を使用してマシンエージェントを構成できます。

AppDynamics には、Kubernetes クラスタの正常性をモニタするための Kubernetes スナップショット拡張機能が用意されています。この拡張を展開する場合は、1 つのバージョンの拡張だけをクラスタに展開する必要があります。重複や潜在的なクラスタの過負荷を回避するために、DaemonSet には含めないでください。その代わり、DaemonSet に加えて、この拡張機能を備えたマシンエージェントのインスタンスを、サーバの可視性のために 1 つのレプリカを持つ個別の展開として展開することを検討してください。この場合、マシンエージェントの SIM と Docker を無効にして、メモリ要求を 250 M に下げることができます。