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

マシンエージェント：

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

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

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

ネットワークエージェントは、モニター対象のアプリケーション コンポーネント間のネットワーク接続すべてのメトリックを収集し、それらのメトリックをコントローラに送信します。

次に、さまざまな 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

ロールを定義したら、クラスタ ロール バインディングを作成して、そのロールをサービスアカウントに関連付ける必要があります。この 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

マシンエージェントは、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

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

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

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

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

その他のオプションについては、「Deploying 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"）を使用してマシンエージェントを構成できます。