Kc Ks8 To Dotlang

Given a Kubernetes topology in JSON format, create a comprehensive dot-lang diagram that visualizes the relationships between all Kubernetes components. Follow these specific guidelines:

1. DIAGRAM STRUCTURE:

• Group components into the following logical subgraphs:

• Access Control

• Cluster Resources

• Workloads

• Configuration

• Networking

• Storage

• Scaling

• Use digraph for directed graph

• Use subgraph cluster_* for logical groupings

• Set global graph attributes for readability

• Use rankdir="TB" for top-down layout

2. COMPONENT RELATIONSHIPS:

For each resource type in the JSON topology:

•  Parse the metadata.ownerReferences to establish a parent-child relationship

• Parse the spec.selector fields to establish Service-Pod relationships

• Parse the spec.volumes and spec.volumeMounts for storage relationships

• Parse RBAC relationships from RoleBindings and ClusterRoleBindings

• Parse service to pod connection using selectors and ports

3. REQUIRED COMPONENTS (if present in topology):

Access Control:

• User

• Group

• CustomRole (CR)

• CustomRoleBinding (CRB)

• ServiceAccount (SA)

• PodSecurityPolicy (PSP)

Cluster Resources:

• Namespace (NS)

• ResourceQuota

• LimitRange

Workloads:

• Deployment

• StatefulSet (SS)

• DaemonSet (DS)

• Job

• CronJob (CJ)

• ReplicaSet (RC)

• Pod

Configuration:

• ConfigMap (CM)

• Secret

Networking:

• Service (Svc)

• Ingress (Ing)

• Endpoints (EP)

• NetworkPolicy (NPol)

Storage:

• Volume (Vol)

• PersistentVolumeClaim (PVC)

• PersistentVolume (PV)

• StorageClass (SC)

Scaling:

• HorizontalPodAutoscaler (HPA)

• VerticalPodAutoscaler (VPA)

• PodDisruptionBudget (PDB)

5. RELATIONSHIP MAPPING RULES:

• Container --> Endpoints --> Services
• Ingress --> Services
• PVCs --> PVs
• Volumes --> Pods
• HPAs/VPAs --> Pods
• CronJobs --> Jobs --> Pods
• NetworkPolicies --> Pods

6. FORMAT REQUIREMENTS:

• Use standard naming conventions (e.g., Deploy for Deployment)
• Include all relationship arrows using -->
• Use descriptive edge labels where helpful (e.g., --Constrains-->)
• Group related components in appropriate subgraphs
• Maintain consistent spacing and formatting
• Add a kf_type field to each component
• When a container (cont-a) wants to communicate with a container(cont-b) e.g pod-a, it should do so via the service cont-a is with like so cont-a -> cont-b[lhead="service-b"]
• Avoid adding any styling to the diagram

COMPLETE EXAMPLE

Here's how the dotlang diagram should be structured:

digraph G {
  rankdir="TB"
  compound=true
  node

  subgraph cluster_default {
    label="default namespace"
    kf_type="ns"

    subgraph cluster_frontend_service {
      label="frontend service"
      kf_type="svc"
      subgraph cluster_frontend_workload {
        label="frontend deployment"
        kf_type="workload"

        subgraph cluster_frontend_pod {
          label="pod"
          kf_type="pod"
          nginx[kf_type="container"]
          frontend_app[kf_type="container"]
        }
        frontend_hpa[kf_type="hpa"]
      }
    }

    subgraph cluster_auth_service {
      label="auth service"
      kf_type="svc"

      subgraph cluster_auth_workload {
        label="auth deployment"

        subgraph cluster_auth_pod {
          label="auth pod"
          kf_type="pod"
          auth[kf_type="container"]
          redis_cache[kf_type="container"]
        }
        auth_hpa[kf_type="hpa"]
      }
    }

    subgraph cluster_cart_service {
      label="cart service"
      kf_type="svc"

      subgraph cluster_cart_workload {
        label="cart deployment"
        kf_type="workload"

        subgraph cluster_cart_pod {
          label="cart pod"
          kf_type="pod"
          cart[kf_type="container"]
          redis_cart[kf_type="container"]
        }
        cart_hpa[kf_type="hpa"]
      }
    }

    subgraph cluster_orders_service {
      label="orders service"
      kf_type="svc"

      subgraph cluster_orders_workload {
        label="orders deployment"
        kf_type="workload"

        subgraph cluster_orders_pod {
          label="pod"
          kf_type="pod"
          orders[kf_type="container"]
        }
        orders_hpa[kf_type="hpa"]
      }
    }

    subgraph cluster_products_service {
      label="products service"
      kf_type="svc"

      subgraph cluster_products_workload {
        label="products deployment"
        kf_type="workload"

        subgraph cluster_products_pod {
          label="products pod"
          kf_type="pod"
          products[kf_type="container"]
          products_cache[shape="container"]
        }
        products_hpa[kf_type="hpa"]
      }
    }

    # Service connections
    nginx -> frontend_app[label="3000"]
    frontend_app -> auth[label="8080" lhead="cluster_auth_service"]
    frontend_app -> cart[label="8082" lhead="cluster_cart_service"]
    frontend_app -> orders[label="8083" lhead="cluster_orders_service"]
    frontend_app -> products[label="8081" lhead="cluster_products_service"]
    auth -> redis_cache[label="6379"]
    auth_hpa -> auth[lhead="cluster_auth_pod"]
    cart -> redis_cart[label="6379"]
    cart -> auth[label="8080" lhead="cluster_auth_service"]
    cart -> products[label="8081" lhead="cluster_products_service"]
    cart_hpa -> cart[lhead="cluster_cart_pod"]
    orders -> auth[label="8080" lhead="cluster_auth_service"]
    orders_hpa -> orders[lhead="cluster_orders_pod"]
    products -> products_cache[label="6379"]
    products_hpa -> products[lhead="cluster_products_pod"]
  }
}

---

Return a complete dotlang diagram that:

1. Shows all components present in the input JSON
2. Groups them logically in subgraphs
3. Shows all relationships between components
4. Includes proper styling classes
5. Uses consistent naming and abbreviations
6. Specific Structure Requirements:
   • Ensure workloads (deployments, statefulsets, daemonsets, cronjobs, jobs, etc.) are in a subgraph with a service subgraph
   • Place pods as subgraphs within the workload subgraph
   • Position horizontal pod autoscalers inside a workload with a connection to the pod

NOTE: You must respond with only the dotlang diagram wrapped in a dot codeblock and nothing else.

Here is the extracted Kubernetes topology:

{KUBERNETES_TOPOLOGY}