The NetQ Agent monitors container environments the same way it monitors physical servers. There is no special implementation. The NetQ Agent pulls data from the container as it would pull data from a Cumulus Linux switch or Linux host. It can be installed on a Linux server or in a Linux VM. NetQ Agent integrates with the Kubernetes container orchestrator.
NetQ monitors many aspects of containers on your network, including their:
- Identity: The NetQ agent tracks every container's IP and MAC address, name, image, and more. NetQ can locate containers across the fabric based on a container's name, image, IP or MAC address, and protocol and port pair.
- Port mapping on a network: The NetQ agent tracks protocol and ports exposed by a container. NetQ can identify containers exposing a specific protocol and port pair on a network.
- Connectivity: NetQ can provide information on network connectivity for a container, including adjacency, and can identify containers that can be affected by a top of rack switch.
NetQ helps answer questions such as:
Where is this container located?
Open ports? What image is being used?
Which containers are part of this service? How are they connected?
Use NetQ with Kubernetes Clusters
The NetQ Agent interfaces with a Kubernetes API server and listens to Kubernetes events. The NetQ Agent monitors network identity and physical network connectivity of Kubernetes resources like Pods, Daemon sets, Service, and so forth. NetQ works with any container network interface (CNI), such as Calico or Flannel.
The NetQ Kubernetes integration enables network administrators to:
- Identify and locate pods, deployment, replica-set and services deployed within the network using IP, name, label, and so forth.
- Track network connectivity of all pods of a service, deployment and replica set.
- Locate what pods have been deployed adjacent to a top of rack (ToR) switch.
- Check what pod, services, replica set or deployment can be impacted by a specific ToR switch.
NetQ also helps network administrators identify changes within a Kubernetes cluster and determine if such changes had an adverse effect on the network performance (caused by a noisy neighbor for example). Additionally, NetQ helps the infrastructure administrator determine how Kubernetes workloads are distributed within a network.
The NetQ Agent supports Kubernetes version 1.9.2 or later.
Due to the higher memory requirements to run containers, Cumulus Networks recommends you run the NetQ Platform on a host with at least 64G RAM.
There is a large set of commands available to monitor Kubernetes configurations, including the ability to monitor clusters, nodes, daemon-set, deployment, pods, replication, and services. Run
netq show kubernetes help to see all the possible commands:
Enable Kubernetes Monitoring
For NetQ to monitor the containers on a host, you must configure the following on the Kubernetes master node:
- Configure the host to point to the NetQ Platform by its IP address. See the Install NetQ (2.1.0 version) topic for details.
Enable Kubernetes monitoring by NetQ. You can specify a polling period between 10 and 120 seconds; 15 seconds is the default.
Restart the NetQ agent:
Next, you must enable the NetQ Agent on all the worker nodes, as described in the Install NetQ topic, for complete insight into your container network.
View Status of Kubernetes Clusters
You can get the status of all Kubernetes clusters in the fabric using the
netq show kubernetes cluster command:
To filter the list, you can specify the hostname of the master before the
Optionally, you can output the results in JSON format:
View Changes to a Cluster
If data collection from the NetQ Agents is not occurring as it once was, you can verify that no changes have been made to the Kubernetes cluster configuration using the around keyword. This example shows the changes that have been made in the last hour.
View Kubernetes Pod Information
You can show configuration and status of the pods in a cluster, including the names, labels, addresses, associated cluster and containers, and whether the pod is running. This example shows pods for FRR, Nginx, Calico, various Kubernetes components sorted by master node.
You can filter this information to focus on a particular pod:
View Kubernetes Node Information
You can view a lot of information about a node, including the pod CIDR and kubelet status.
To display the kubelet or Docker version, append
components to the above command. This example lists all the details of all master and worker nodes because the master's hostname — server11 in this case — was included in the query.
To view only the details for a worker node, specify the hostname at the end of the command after the
You can view information about the replica set:
You can view information about the daemon set:
You can view information about the pod:
You can view information about the replication controller:
You can view information about a deployment:
You can search for information using labels as well. The label search is similar to a "contains" regular expression search. In the following example, we are looking for all nodes that contain kube in the replication set name or label:
View Container Connectivity
You can view the connectivity graph of a Kubernetes pod, seeing its replica set, deployment or service level. The impact/connectivity graph starts with the server where the pod is deployed, and shows the peer for each server interface.
View Kubernetes Service Connectivity and Impact
You can show the Kubernetes services in a cluster:
And get detailed information about a Kubernetes service:
To see the connectivity of a given Kubernetes service, run:
To see the impact of a given Kubernetes service, run:
View Kubernetes Cluster Configuration in the Past
You can use the "time machine" features of NetQ on a Kubernetes cluster, using the
around keyword to go back in time to check the network status and identify any changes that occurred on the network.
This example shows the current state of the network. Notice there is a node named server23. server23 is there because the node server22 went down and Kubernetes spun up a third replica on a different host to satisfy the deployment requirement.
You can see this by going back in time 10 minutes. server23 was not present, whereas server22 was present:
You can determine the impact on the Kubernetes deployment in the event a host or switch goes down. The output is color coded (not shown in the example below) so you can clearly see the impact: green shows no impact, yellow shows partial impact, and red shows full impact.