Network Visibility for Kubernetes
Air-Date October 23, 2018
Run Time: 60 minutes
Resource links referenced in the session:
AD-Capital-Kube Project on Github
AppD Network Visibility Docs
AppD Monitoring Cloud Applications Docs
@Mark.Prichard and @Eric.Johanson focus on the Network, in this deep dive session in our monitoring Kubernetes applications series. AppDynamics Network Visibility adds an important new weapon to your application monitoring arsenal, allowing you to isolate and troubleshoot network-related performance issues. Currently in beta, Eric and Mark will walk thru the new Network Visibility with Kubernetes feature in AppDynamics.
In this session, you will see how to configure Kubernetes and automate deployments to include Network Visibility. In addition, Eric and Mark will explain the extra dimension this adds to APM, and explore some of the application performance issues it can help to troubleshoot.
Are you using Google Cloud? If so, this session should be of interest... as a live deployment using Google Kubernetes Engine (GKE) will be shown too.
Q&A Transcript
Q: What is the anticipated release date?
A: Soon, so keep an eye out!
Q: What environment do the agents need to run in (e.g., OS, language support, etc)?
A: Right now we support only Java applications and Linux hosts. We're working to extend our support.
Q: Does the system work with Docker Swarm or Docker UCP?
A: Yes, there is no dependency on the type of Docker you are using. It’s just the deployment model and if you have a container that can run the Network Agent, then that's all that matters. In one of our early webinars, we actually showed a deployment using Swarm. Check out our previous webinars.
Q: Do I have a choice of the base Docker image?
A: Yes, you can use any image. All you need is the Network Agent package and the way it is executed. In this scenario, we chose Kubernetes but you can use any orchestrator as long as you can run Docker.
Q: Does the Network Agent or Server Agent require elevated privileges to obtain metrics?
A: The Network Agent requires elevated privileges for the installation part, but once you’ve done the installation, it relinquishes privileges and works like any other process. In the YAML descriptor, they have the roles that are required so you just have to specify those (that's standard for a Kuberentes configuration). There are two ways to give priveleges. One is through Capabilities, so you're just giving the capabilities on the network infrastructure. But on a system that doesn't have capabilities, like older Linux versions, it defaults into the secure ID. In any case, once the agent boots up, it relinquishes any priveleges.
Q: If we're using a CNI implementation that uses an overlay (e.g., VXLAN), would the Network Visibility Agent show both the overlay and underlay metrics?
A: Yes, since it is indepenedent of the CNI implementation. CNI is how you route packets between these different parts but from the Network Agent perspective, if it's able to see the packet, it can see the whole thing. We have tested both the overlay network and the router network, so it will work out of the box.
Q: When a service that runs in Kubernetes communicates with a service that runs outside of the Kubernetes cluster, what kind of visibility is provided?
A: Just like in a normal monitoring environment, if there's a Cloud service, you will see one side of the metrics but you won't see the complete metrics on both sides because our agent is not running on the other side. If you want to monitor something, you have to have an agent on it. You are able to view the connection going out to the service, which allows you to see send and receive metrics, even if you don't see the other end of the flow. That's the same for App and Server monitoring. The Network Agent captures metrics as far as that TCP goes, so no matter where the TCP goes, you'll get the metrics for those TCP connections.
Q: If we use an external service discovery tool (e.g. Hashicorp Consul), can we detect issues related to such tools (like a slowdown to the DNS queries against Consul)?
A: We should be able to get metrics for anything using a TCP connection, so any service using a TCP connection from the application should work.
Q: The only network elements in this demo seem to be load balancers. Do you have examples of other network elements such as routers/switches, firewalls, proxies, etc.?
A: Right now our focus is on data flow components rather components like routers and switches. However, we're looking at an integration between this and CISCO ACI, so there will be things to talk about there in the future.
Q: How difficult is it to install Network Visibility into elements if they are appliances?
A: Installation is not a big deal because it's a very native agent that runs on a wide variety of things. The only tricky part is how it communicates with the application itself, because we are looking at metrics that are directly in correlation with the application. We don't have a focus on making it deployable on individual appliances at this time.
Q: What containers are you monitoring? I have one Machine Agent and an App Agent that has been installed as a DaemonSet on my concerned container only. Will Network Visibility give me a picture of all the containers or only the specific application container where the App Agent is installed?
A: What we are focusing on specifically are the containers that have application components that are being monitored by APM. We are working to extend that and provide an equivalent but different view of what's going on in all containers. We also want to be able to troubleshoot and diagnose issues with pure infrastructure containers and things that are not part of the application flow in the future, but that would be a different type of information. The model there is like a security camera - it wouldn't be capturing everything and keeping it forever. We want to be able to detect if there are issues (e.g., container goes into a crash loop), look at the problem, understand what's happening, and move on. We don't have that type of information today but we're working on it!
Q: What are some final thoughts on this topic?
A: This is a great topic to get exposure to since the Network Agent is very easy to deploy. Do a POV to see what type of value it's going to bring to you organization, what type of capabilities we provide, and what kind of use case it's going to help you solve. This is a very rich and complex area, so we’d love to hear your feedback. Work with us and let us guide you because this is a very powerful tool.
Additionally, when you look at these rich Cloud environments, there are going to be a number of pieces to the solution. The key thing is being able to have a handle on how your applications are performing and understand what’s affecting that performance is critical. This Network Visibility piece gives you an additional tool in your arsenal.
Finally, look at our workflows and examples for guidance. We understand that you’re trying to make sure you have views into everything. With this piece of the puzzle, you can verify if there issue is on the network side.
