Visualizador de Recursos K8s

Visualizing Kubernetes Resource Relationships

Kubernetes applications are composed of interconnected resources — Deployments create Pods, Services route traffic to Pods via label selectors, Ingress resources expose Services externally, ConfigMaps and Secrets inject configuration into containers. Understanding how these resources relate to each other is essential for debugging networking issues, planning capacity changes, and onboarding new team members to complex cluster topologies. The Resource Visualizer parses multi-document YAML manifests and builds a relationship graph showing how resources connect through selectors, references, volume mounts, and service bindings.

Rather than mentally tracing label selectors across hundreds of lines of YAML, the visualizer presents a hierarchical view of your application topology. See which Services front which Deployments, which ConfigMaps are consumed by which Pods, and which Ingress rules route to which Services — all derived automatically from your manifest definitions without requiring cluster access.

Resource Relationship Detection

The visualizer detects relationships between Kubernetes resources using the same mechanisms that Kubernetes itself uses to bind them at runtime:

• Label selector matching: Services select Pods via spec.selector, Deployments manage Pods via spec.selector.matchLabels, and NetworkPolicies target Pods by label — the visualizer traces all these selector-to-label connections.
• Volume references: Pods reference ConfigMaps and Secrets through volumes[].configMap.name and volumes[].secret.secretName.
• Environment references: Container env vars referencing ConfigMaps and Secrets via valueFrom.configMapKeyRef and valueFrom.secretKeyRef.
• Ingress backend services: Ingress rules reference Services by name in their backend configuration, establishing the external-to-internal routing chain.
• Service account bindings: Pods referencing ServiceAccounts that have associated RoleBindings and ClusterRoleBindings.

Understanding Application Topology

The visual topology reveals architectural patterns and potential issues that are invisible when reading individual manifest files:

• Orphaned resources: ConfigMaps or Secrets that exist in your manifests but are not referenced by any Pod — indicating unused configuration that should be cleaned up.
• Missing dependencies: Pods referencing a ConfigMap or Secret that does not exist in the manifest set — the Pod will fail to schedule until that resource is created.
• Service selector mismatches: A Service whose selector labels do not match any Pod's labels — traffic will not be routed and health checks will fail.
• Single points of failure: A Service backed by only one Pod replica with no autoscaling — any pod failure causes complete service unavailability.

These insights are particularly valuable during manifest reviews where the complete picture of resource interdependencies is difficult to hold mentally across multiple files.

Use Cases for Resource Visualization

Teams use resource visualization across several workflows:

• Onboarding: New team members understand application architecture by viewing the resource graph rather than reading dozens of YAML files individually.
• Incident response: During outages, quickly identify which resources are affected by a failing component by tracing the dependency chain.
• Migration planning: When splitting a monolith into microservices, visualize current resource relationships to understand what needs to be separated.
• Manifest review: During PR reviews, generate a topology diff showing how the proposed changes modify the resource relationship graph.
• Documentation: Export the topology as structured data for inclusion in architecture documentation that stays synchronized with actual manifests.

Code Examples

Multi-Resource Manifest with Relationships

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  labels:
    app: web
spec:
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: myapp:1.2.0
          envFrom:
            - configMapRef:
                name: web-config
---
apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web              # → matches Deployment pods
  ports:
    - port: 80
      targetPort: 8080
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: web-config        # → referenced by Deployment
data:
  API_URL: "https://api.example.com"
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
spec:
  rules:
    - host: app.example.com
      http:
        paths:
          - backend:
              service:
                name: web-service  # → references Service
              port:
                number: 80

# Visualized topology:
# Ingress(web-ingress) → Service(web-service) → Deployment(web-app)
#                                                    ↓
#                                              ConfigMap(web-config)