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 Install Agent-Side Components in Kubernetes.

Requirements

Before you begin, verify that you have:

• Installed kubectl >= 1.16
• Cluster Agent >= 21.3.1
• Met these requirements: Cluster Agent Requirements and Supported Environments.
• If Server Visibility is required, sufficient Server Visibility licenses based on the number of worker nodes in your cluster. 
• Permissions to view servers in the Controller.

Installation Procedure

1. Install the Cluster Agent. 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

      kubectl create -f cluster-agent-operator.yaml kubectl create -f cluster-agent-operator-openshift.yaml kubectl create -f cluster-agent-operator-openshift-1.15-or-less.yaml

      You can also install Cluster Agent Operator from OpenShift OperatorHub in your OpenShift cluster.

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 Install the Cluster Agent with the Kubernetes CLI.

   kubectl -n appdynamics create secret generic cluster-agent-secret --from-literal=controller-key=<access-key>

3. (Optional) Create an Infrastructure Visibility secret by using the keystore credentials.

   1. Run the following command to import your CA certificate from custom-ssl.pem file:
      

      keytool -import -alias rootCA -file custom-ssl.pem -keystore cacerts.jks -storepass <your-password>

   2. Create keystore file secret.
      

      kubectl -n appdynamics create secret generic <cacertinfraviz> --from-file=cacerts.jks

   3. Create Keystore password secret

      kubectl -n appdynamics create secret generic <kspassinfraviz> --from-literal=keystore-password="<your-password>"

      Here, cacertinfraviz is the keystore filename and kspassinfraviz is the keystore password of Infrastructure Visibility.

      The the keystore file and password that you specify here should be included in the infraviz.yaml file to apply the custom SSL configuration. For example, keyStoreFileSecret: cacertinfraviz keystorePasswordSecret: kspassinfraviz

4. Update the infraviz.yaml file to set the controllerUrl, and account 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.

   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"

   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. 

5. 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:

   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"

6. Use kubectl to deploy infraviz.yaml 

   For environments where Kubernetes >=1.25, PodSecurityPolicy is removed from Kubernetes >= 1.25 (https://kubernetes.io/blog/2022/08/23/kubernetes-v1-25-release/#pod-security-changes). Pod security restrictions are now applied at the namespace level (https://kubernetes.io/docs/concepts/security/pod-security-admission/) using Pod Security Standard levels . Therefore you must set the level as Privileged to the namespace in which Infrastructure Visibility pod is running. For environments where Kubernetes <1.25, 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. You must attach PodSecurityPolicy to appdynamics-infraviz service account explictly. 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 kubectl create -f infraviz-pod-security-policy.yaml kubectl create -f infraviz.yaml Specify the following Kubernetes labels to the namespace where Infrastructure Visibility is installed: pod-security.kubernetes.io/<MODE>: <LEVEL> (Required) pod-security.kubernetes.io/<MODE>-version: <VERSION> (Optional) For more info see, https://kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/. apiVersion: v1 kind: Namespace metadata: name: appdynamics labels: pod-security.kubernetes.io/enforce: privileged pod-security.kubernetes.io/enforce-version: v1.27 pod-security.kubernetes.io/audit: privileged pod-security.kubernetes.io/audit-version: v1.27 pod-security.kubernetes.io/warn: privileged pod-security.kubernetes.io/warn-version: v1.27 Run the following command: kubectl create -f infraviz.yaml kubectl create -f infraviz-security-context-constraint-openshift.yaml kubectl create -f infraviz.yaml

7. 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

8. 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 Machine Agent Successfully

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.