This page describes how to install the Machine Agent and Network Agents in a Kubernetes cluster where the Cluster Agent Operator is installed.

The Cluster Agent Operator provides a custom resource definition called InfraViz. You can use InfraViz to simplify deploying the Machine and Network Agents as a daemonset in a Kubernetes cluster. Additionally, you can deploy these agents by creating a daemonset YAML which does not require the Cluster Agent Operator. For more information, see these examples

To deploy the Analytics Agent as a daemonset in a Kubernetes cluster, see Kubernetes でのエージェント側コンポーネントのインストール.

Requirements

Before you begin, verify that you have:

Installation Procedure

  1. クラスタエージェントのインストール. From this Alpine Linux example:

    1. Download the Cluster Agent bundle. 

    2. Unzip the Cluster Agent bundle.

    3. Deploy the Cluster Agent Operator using the CLI specifying the correct Kubernetes and OpenShift version (if applicable):

      unzip appdynamics-cluster-agent-alpine-linux-<version>.zip
      kubectl create namespace appdynamics
      BASH
      kubectl create -f cluster-agent-operator.yaml
      BASH
      kubectl create -f cluster-agent-operator-openshift.yaml
      BASH
      kubectl create -f cluster-agent-operator-openshift-1.15-or-less.yaml
      BASH
  2. Create a Cluster Agent secret using the Machine Agent access key to connect to the Controller. If a cluster-agent-secret does not exist, you must create one, see Kubernetes CLI を使用したクラスタエージェントのインストール.

    kubectl -n appdynamics create secret generic cluster-agent-secret --from-literal=controller-key=<access-key>
    BASH
  3. Update the infraviz.yaml file to set the controllerUrlaccount, and globalAccount values based on the information from the Controller's License page.
    To enable Server Visibility, set enableServerViz to true (shown in the infraviz.yaml configuration example).
    To deploy a Machine Agent without Server Visibility enabled, set enableServerViz to false.

    infraviz.yaml Configuration File with Server Visibility Enabled

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: appdynamics-infraviz
      namespace: appdynamics
    ---
    apiVersion: cluster.appdynamics.com/v1alpha1
    kind: InfraViz
    metadata:
      name: appdynamics-infraviz
      namespace: appdynamics
    spec:
      controllerUrl: "https://mycontroller.saas.appdynamics.com"
      image: "docker.io/appdynamics/machine-agent:latest"
      account: "<your-account-name>"
      globalAccount: "<your-global-account-name>"
      enableContainerHostId: true
      enableServerViz: true
      resources:
        limits:
          cpu: 500m
          memory: "1G"
        requests:
          cpu: 200m
          memory: "800M"
    YML

    The infraviz.yaml configuration file example deploys a daemonset that runs a single pod per node in the cluster. Each pod runs a single container from where the Machine Agent, or Server Visibility Agent runs. 

  4. To enable the Network Visibility Agent to run in a second container in the same pod, add the netVizImage and netVizPort keys and values as shown in this configuration file example:

    infraviz.yaml Configuration File with Second Container in a Single Pod

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: appdynamics-infraviz
      namespace: appdynamics
    ---
    apiVersion: cluster.appdynamics.com/v1alpha1
    kind: InfraViz
    metadata:
      name: appdynamics-infraviz
      namespace: appdynamics
    spec:
      controllerUrl: "https://mycontroller.saas.appdynamics.com"
      image: "docker.io/appdynamics/machine-agent:latest"
      account: "<your-account-name>"
      enableContainerHostId: true
      enableServerViz: true
      netVizImage: appdynamics/machine-agent-netviz:latest
      netVizPort: 3892
      resources:
        limits:
          cpu: 500m
          memory: "1G"
        requests:
          cpu: 200m
          memory: "800M"
    YML
  5. Use kubectl to deploy infraviz.yaml 

    For environments where Kubernetes PodSecurityPolicies block certain pod security context configuration, such as privileged pods, you must deploy the infraviz-pod-security-policy.yaml before editing the infraviz.yaml file.

    For environments where OpenShift SecurityContextConstraints block certain pod security context configuration, such as privileged pods, you must deploy the infraviz-security-context-constraint-openshift.yaml before editing the infraviz.yaml file.

    kubectl create -f infraviz.yaml
    BASH
    kubectl create -f infraviz-pod-security-policy.yaml
    kubectl create -f infraviz.yaml
    BASH
    kubectl create -f infraviz-security-context-constraint-openshift.yaml
    kubectl create -f infraviz.yaml
    BASH
  6. Confirm that the appdynamics-infraviz pod is running, and the Machine Agent, Server Visibility Agent, and Network Agent containers are ready:

    kubectl -n appdynamics get pods
    NAME                                    READY   STATUS    RESTARTS   AGE
    appdynamics-infraviz-shkhj                     2/2     Running   0          18s
    
    BASH
  7. To verify that the agents are registering with the Controller, review the logs and confirm that the agents display in the Agents Dashboard of the Controller Administration UI. In the Controller, if Server Visibility is enabled, the nodes are visible under Controller > Servers.

    kubectl -n appdynamics logs appdynamics-infraviz-shkhj -c appd-infra-agent
    ...
    Started AppDynamics Machine Agent Successfully
    BASH

Mixed Operating System Clusters

The Cluster Agent Operator can deploy Machine Agent daemonsets to both Linux and Windows nodes. The value of the nodeOS property determines the deployment strategy in mixed operating system (OS) clusters. You can set this property to one of these options:

  • all
  • linux
  • windows

Set nodeOS: all when both Linux and Windows daemonsets share the same properties that you can configure in a single infraviz.yaml file. When nodeOS is set to all or windows, you must set the imageWin property to a Windows Machine Agent image.

In this example, a single infraviz.yaml file is used to configure the Machine Agents that run on Windows and Linux nodes.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: appdynamics-infraviz
  namespace: appdynamics
---
apiVersion: cluster.appdynamics.com/v1alpha1
kind: InfraViz
metadata:
  name: appdynamics-infraviz
  namespace: appdynamics
spec:
  controllerUrl: "https://mycontroller.saas.appdynamics.com"
  image: "docker.io/appdynamics/machine-agent:latest"
  account: "<your-account-name>"
  globalAccount: "<your-global-account-name>"
  enableContainerHostId: true
  enableServerViz: true
  netVizImage: appdynamics/machine-agent-netviz:latest
  netVizPort: 3892 
  resources:
    limits:
      cpu: 500m
      memory: "1G"
    requests:
      cpu: 200m
      memory: "800M"
  imageWin: docker.io/appdynamics/machine-agent-analytics:win-latest  
  nodeOS: all
YML

Set nodeOS: windows or nodeOS: linux when the Windows and Linux daemonsets properties differ and must be defined in separate infraviz.yaml files. Depending on the value of nodeOS, the Cluster Agent Operator assigns a nodeSelector value to the Machine Agent that determines its placement.
For nodeOS: windows, it sets "kubernetes.io/os" to windows.
For nodeOS: linux, it sets kubernetes.io/os to linux

To override this default behavior, specify a nodeSelector in infraviz.yaml. For example:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: appdynamics-infraviz
  namespace: appdynamics
---
apiVersion: cluster.appdynamics.com/v1alpha1
kind: InfraViz
metadata:
  name: appdynamics-infraviz
  namespace: appdynamics
spec:
  # ... content removed for brevity  
  nodeOS: windows
  imageWin: docker.io/appdynamics/machine-agent-analytics:win-latest  
  nodeSelector:
    kubernetes.io/os: my-windows-node-selector
YML

InfraViz Configuration Settings

To configure Infrastructure Visibility, you can modify these parameters in the infraviz.yaml file included with the download package. After changing the file, delete and re-create the InfraViz deployment to ensure the changes are applied.

ParameterDescriptionRequired/OptionalDefault
accountAppDynamics account nameRequiredN/A
argsList of command argumentsOptionalN/A
controllerUrlURL of the AppDynamics ControllerRequiredN/A
enableContainerHostIdFlag that determines how container names are derived; specify either pod name or container id.Requiredfalse
enableMastersBy default, only Worker nodes are monitored. When set to true, Server Visibility is provided for Master nodes. For managed Kubernetes providers, the flag has no effect because the Master plane is not accessible.Optionalfalse
enableServerVizEnable Server VisibilityRequired
false
enableDockerVizEnable Docker VisibilityRequiredfalse
envList environment variablesOptionalN/A
eventServiceUrlEvent Service EndpointOptionalN/A
globalAccountGlobal account nameRequiredN/A
imageRetrieves the most recent version of the Machine Agent image.Optionalappdynamics/machine-agent:latest
imagePullSecretName of the pull secret imageOptionalN/A
imageWinMachine Agent image for Windows nodesRequired when nodeOS is set to all or windowsappdynamics/machine-agent-analytics:win-latest
logLevelLevel of logging verbosity. Valid options are: info or debug.Optionalinfo
metricsLimitMaximum number of metrics that the Machine Agent sends to the Controller.OptionalN/A
netVizImageRetrieves the most recent version of Network Agent image.Optionalappdynamics/machine-agent-netviz:latest
netVizPortWhen > 0, the Network Agent is deployed in a sidecar with the Machine Agent. By default, the Network Visibility Agent works with port 3892.Optional3892
nodeSelectorOS specific label that identifies nodes for scheduling of the daemonset pods.Optionalall

overrideVolumeMounts

The list of volumeMounts.Optional

overrideVolumeMounts:

- proc
- sys
- etc

priorityClassName

Name of the priority class that determines priority when a pod needs to be evicted.OptionalN/A
propertyBagString with any other Machine Agent parametersOptionalN/A
proxyUrlURL of the proxy server (protocol://domain:port)OptionalN/A
proxyUserProxy user credentials (user@password)OptionalN/A
resourcesDefinitions of resources and limits for the Machine Agent

Optional

N/A
resourcesNetVizSet resources for the Network Visibility (NetViz) containerOptional

Request

  • CPU: 100m
  • Memory: 150Mi

Limit

  • CPU: 200m
  • Memory: 300Mi
runAsUser

The UID (User ID) to run the entry point of the container process. If you do not specify the UID, this defaults to the user id specified in the image.

docker.io/appdynamics/machine-agent

 docker.io/appdynamics/machine-agent-analytics:latest

If you require to run on any other UID, change the UID for runAsUser without changing the group ID.

Optional

UID: 1001

Username: appdynamics

runAsGroupThe GID (Group ID) to run the entry point of the container process. If you do not specify the ID, this uses the UID specified in the image, 

docker.io/appdynamics/machine-agent

docker.io/appdynamics/machine-agent-analytics:latest

OptionalUID: 1001
Username: appdynamics
stdoutLoggingDetermines if logs are saved to a file or redirected to the Console.Optionalfalse
tolerationsList of tolerations based on the taints that are associated with nodes.OptionalN/A
uniqueHostIdUnique host ID in AppDynamics. Valid options are: spec.nodeNamestatus.hostIP.Optionalspec.nodeName