It’s easy to see why Kubernetes has quickly become the de facto standard for container orchestration and one of the most loved platforms among developers. Before Kubernetes, also known as K8s, it could take months to deploy applications and services. Now, this open-source platform allows us to run containers on clusters of physical or virtual machines with a simplified orchestration process, both on-prem and in cloud-native environments.
However, Kubernetes environments are highly dynamic, scalable, and distributed in nature. This requires a new approach to monitoring the Kubernetes infrastructure and applications.
AppDynamics provides several powerful ways to monitor your application and infrastructure in a Kubernetes environment. In this blog post, I’ll discuss some of the best practices to get the most out of your favorite monitoring platform quickly. If you’ve just launched (or are planning to launch) your first Kubernetes cluster, this post will help you understand where to get started with monitoring.
We’ve added several new features and improvements over the last year that will make your AppDynamics implementation in a k8 environment really simple. To name a few:
- We introduced the new AppDynamics Cluster Agent to give you an easy and streamlined way to collect cluster-level metrics.
- We introduced Agentless Analytics (currently in Java) that enables Transaction Analytics without the need to deploy a separate standalone analytics agent or machine agent extension.
- We added auto-instrumentation capability to the Cluster Agent which makes deploying APM agents to large applications a brisk experience and doing manual updates to the deployment spec thing of the past.
- The new user experience throughout the AppDynamics controller gives you quick ways to navigate and correlate between transaction <-> network <-> node <-> pod <-> container level metrics and pinpoint the root cause of the performance issue.
Let’s Get Started
In the following examples, I’m using a cluster that’s running on Google Cloud Platform.
(You’ll find links throughout this post to our official documentation, which goes into much more detail.)
The cluster consists of 3 nodes and there is a Java application running which includes a few different services running under the namespace “prod”:
The application running in the “prod” namespace:
Step 1: Deploy the AppDynamics Operator
The first step is to deploy the AppDynamics Operator, which is a client for the Kubernetes API that acts as controllers for a Custom Resource in the cluster. You can download the cluster-agent-operator.yaml when downloading Cluster Agent from download.appdynamics.com.
The operator and all the related pods will be deployed under the “appdynamics” namespace, which you can customize. Always make sure that your application is running under a different namespace than “appdynamics”.
Step 2: Deploy the Cluster Agent
Once you have the operator up and running, the next step is to deploy the cluster agent that helps you monitor and understand how k8 infrastructure affects your application and business performance.
You deploy only one cluster agent in each cluster. Please note that you should not run Server Visibility with Docker Monitoring enabled and the Cluster Agent concurrently (see next section about infrastructure visibility). All the steps required before deploying the cluster agent (like creating secret, etc.) are covered in the documentation. You should already have the cluster-agent.yaml in the same directory that you downloaded for the operator.
Within minutes you’ll start seeing cluster-level metrics and events getting populated in the controller:
Step 3: Deploy Infrastructure Visibility
The easiest way to get node-level hardware metrics is by deploying the Server Visibility agent (machine agent with SIM license) on each of the nodes in your cluster.
This is done by deploying our standalone machine agent as a DaemonSet. This ensures that every node in the cluster that exists today or in the future will run a copy of this machine agent pod and collect hardware metrics. You can find details about all the configuration settings on our git repo. Here’s an example:
As mentioned earlier, if you’re using InfraViz along with the cluster agent, add enableDockerViz: “false”. Also, note that you can enable the Network Visibility or Analytics machine agent extension and the configuration while deploying InfraViz, like in this example.
You should now start seeing hardware metrics for each of the nodes in your AppDynamics Controller:
Step 4: Enable Auto-Instrumentation
One of the most exciting features in the cluster agent is the ability to auto-instrument or dynamically add the APM agent to the application deployed in the Kubernetes cluster.
Currently, the java agent is supported. You also have the option to go with the init container approach but it’s only recommended if auto-instrumentation is not possible. In the following spec, I’m simply pointing the cluster agent to auto-instrument pods running in the “prod” namespace by using the latest java agent image, and have that report to the controller under an application named “my-k8-app”. You can find different examples and all available options for auto-instrumentation here.
Once you apply this YAML and apply some traffic to the application, you’ll start seeing the application flow map and metrics on the controller:
Remember, we also enabled Network Visibility (NetViz) while deploying the InfraViz, so you should also see the Network Flow Map as well:
As I mentioned before, the latest Java Agent comes with an agentless analytics feature. So, once you enable transaction analytics in the controller UI, you will start seeing events getting collected for the same application that you just instrumented with the cluster agent auto-instrumentation feature.
That’s all for now.
For more information on how to use AppDynamics to monitor the health and capacity of your Kubernetes components and resources, you can visit our on-demand demo and session available at KubeCon + CloudNativeCon Europe 2020 Virtual and watch our webinar, Optimize Microservices Performance with AppDynamics Cluster Agent.