](https://1.bp.blogspot.com/-p_x0bLRdFJo/Vkz8IPR5q4I/AAAAAAAAAtg/D9UU2MfPmcI/s1600/sisdig%2B4.png)




* All containers run inside **pods**. A pod can host a single container, or multiple cooperating containers; in the latter case, the containers in the pod are guaranteed to be co-located on the same machine and can share resources. 
* Pods typically sit behind **services** , which take care of balancing the traffic, and also expose the set of pods as a single discoverable IP address/port. 
* Services are scaled horizontally by **replication controllers** (“RCs”) which create/destroy pods for each service as needed. 
* **Namespaces** are virtual clusters that can include one or more services. 

So just to be clear, multiple services and even multiple namespaces can be scattered across the same physical infrastructure.  



After talking to hundreds of Kubernetes users, it seems that the typical cluster administrator is often interested in looking at things from the physical point of view, while service/application developers tend to be more interested in seeing things from the logical point of view. 



With both these use cases in mind, Sysdig Cloud’s support for Kubernetes works like this: 

* By automatically connecting to a Kubernetes’ cluster API Server and querying the API (both the regular and the watch API), Sysdig Cloud is able to infer both the physical and the logical structure of your microservice application. 
* In addition, we transparently extract important metadata such as labels. 
* This information is combined with our patent-pending ContainerVision technology, which makes it possible to inspect applications running inside containers without requiring any instrumentation of the container or application. 
Based on this, Sysdig Cloud can provide rich visibility and context from both an **infrastructure-centric** and an **application-centric** point of view. Best of both worlds! Let’s check out what this actually looks like.