@Mark.Prichard and @Eric.Johanson guide us through a detailed scenario of how to monitor microservices-based applications deployed using Kubernetes. They cover everything you need to know about packaging your microservices with APM agents and deploying to Kubernetes running on AWS, including: sidecars, secrets, persistent storage, and Istio for service routing.
Below is the complete recording of the technical session. Please note that this version is low sound quality. For a higher quality version of the demo portion, we recommend watching the three individual demo videos embedded underneath the full version.
Invididual Demos[Demo 1] Setting up the Cluster and Defining the Application
Linked referenced in this webinar>>
We’re running the AD-Capital-Docker example from the AppDynamics GitHub page, using the Kubernetes branch: https://github.com/Appdynamics/AD-Capital-Kube [Please note this is a new link, it was updated on 6/14/18]
We’re using the AppDynamics APM official base images from the Docker Store: https://store.docker.com/images/appdynamics
You’ll find instructions on how to build your own here:
Istio (https://istio.io/docs/concepts/traffic-management/overview.html) used to provide request routing and timeout/retry error handling.
Server Agent is deployed as a Kubernetes daemonset to run on each worker node: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
A: Yes, through container monitoring you’ll be able to see the processes that are running there. There will be a command process associated with the container that you can see.
A: One place is on the docker store, where we have images for containers with the Java Agent. We also have images with the Machine Agents (server agents). The source code for both is available on the GitHub page. We have specific requirements for ours, so it’s nice to be able to pull it and update it, then push it again. We also included a resource list above for you to reference.
A: We covered that a bit in the previous webinar. Yes, it will work fine. With any orchestrator, you will be getting the same type of information, looking at container metrics, hardware, etc. You can make the adjustment pretty easily from Kubernetes to Swarm.
A: This application is using MySQL, but you could use either. We monitor both using AppD. In this example, I don’t think we deployed the database but it’s very easy. You’d simply put it into its own container. You configure it to point to CassandraDB or MySQL and that would then show up. It’s very easy to do.
A: https://store.docker.com/images/appdynamics. Just log in to dockerhub to pull the image. To build the MA manually via docker image, use this link: https://github.com/Appdynamics/appdynamics-docker-images
A: Yes, as long as it’s 4.4.3
A: No. As long as there is a Machine Agent on the node and an Application Agent on your application, it doesn't matter if it's a VM, container, or microserverice.
A: Yes, and we have extensions here.
A: Kubernetes as an orchestrator is everywhere in the industry and there are a lot of customers wanting to go this direction. What we wanted to show you is that it’s very easy to build in APM best practices or kubernetes-style deployment. There are some things to think about when planning your deployment architecture, like separating application code from infrastructure code. Think about your style of operations and how you want to load the APM agents. Do you want to build them into base images or do you want to load them dynamically using shared storage? Think about application design. You’re probably going to want to look at things like Istio as a service mesh. It’s really straight forward; the key is to not hard code stuff that you can do dynamically!
When you’re going through this, it’s really simple but there are some small things that might catch you up. However, Kubernetes is powerful because of how much it gives you out-of-the-box dynamically and how customizable it is.