Kullanım alanı

Kubernetes mimari diyagramları

Platform ekipleri için Kubernetes canvas: çerçeve olarak namespace’ler, okunur iş yükleri, işaret edebileceğiniz servisler.

Senaryo

Platform ekibi yeni bir kümeyi devreye alıyor: default ve payments namespace’leri, genel bir Ingress, iki Deployment ve bir HPA. Nöbetçi, stand-up’tan sonra da açık kalacak bir harita istiyor, whiteboard fotoğrafı değil.

Kubernetes node’larını Bulut ve Ağ pack’leriyle aynı sonsuz canvas’a bırakın. Portlar bağlanır. Topoloji hazır olunca markalı public bağlantı paylaşın veya SVG/PNG alın. Pro gömme ve filigransız PDF/JPEG ekler.

Elinizde YAML mı var?

Manifestlerinizi ücretsiz Kubernetes YAML’dan diyagrama aracına yapıştırın ve çizmeye başlamadan önce diyagram olarak görün.

YAML aracını dene

Ne çizilir

Kubernetes mimari diyagramları

  • Çerçeve olarak Namespace
  • Node, Pod, Deployment, StatefulSet, DaemonSet, Job, CronJob
  • Service, Ingress ve Gateway API route’ları
  • ConfigMap, Secret, PVC, PersistentVolume, StorageClass
  • HPA, PodDisruptionBudget, NetworkPolicy ve RBAC rolleri
  • Hesaplar arası haritada iş yüklerinin yanında cloud.k8s-cluster

Neden Archboard

Archboard barındırılan bir Kubernetes mimari canvas’tır: node’lar kontrol düzlemine benzer, portlar trafik gibi bağlanır, aynı tahtada bulut bölgesi veya C4 bağlam görünümü durabilir. Kubernetes pack ile ücretsiz başlayın; sınırsız node, gömme ve filigransız dışa aktarım için Pro’ya abone olun.

Bu canvas’taki pack’ler

Kubernetes · Bulut · Ağ · Docker

Tüm yerleşik pack’ler Free’dedir (3 diyagram, her birinde 15 diyagram node’u + 150 not, metin, çıkartma ve zihin haritası konusu, markalı public share, AI ajanlarınızla canlı düzenleme). Pro sınırsız diyagram ve node, ekip arkadaşlarınızın canlı düzenlemesi için koltuk, gömme ve filigransız dışa aktarım ekler ($10/koltuk/ay).

Oturum nasıl akar

  1. Google veya GitHub ile giriş yapın ve bir canvas açın

  2. Namespace çerçevesi bırakın; içine Deployment, Service ve Ingress koyun

  3. Kuzey-güney trafik için portları bağlayın; hikâye gerektiriyorsa HPA ve NetworkPolicy ekleyin

  4. Markalı public bağlantı paylaşın veya gömme ve filigransız dışa aktarım için Pro’ya geçin

Kubernetes diagrams that survive the sprint

Most Kubernetes architecture diagrams die as whiteboard photos. Someone sketches Namespace boxes during planning, the photo goes stale before the next deploy, and the on-call is left reading YAML to answer a simple question: what talks to what. A Kubernetes canvas fixes this by making the diagram the map the team keeps open. Namespace frames hold Deployments, Services, and Ingress the way the cluster holds them; ports connect like traffic; labels carry the names kubectl shows. When the topology changes, the same canvas changes, and nobody redraws it from a photo.

Start with one namespace and the public path into it: Ingress, then the Service behind it, then the Deployment and its Pods. Add ConfigMaps, Secrets, and PersistentVolumeClaims only where the story needs them, because a diagram that shows everything shows nothing. HorizontalPodAutoscalers and NetworkPolicies belong on the same board because scaling and policy are the questions reviewers actually ask. Keep cloud region frames next to the cluster when workloads span accounts; the canvas holds Kubernetes, cloud, and network packs together, so the map never splits across tools.

From cluster map to design review

A good Kubernetes diagram earns its keep in reviews. Share a branded public link when the topology is ready and let reviewers pan and zoom instead of squinting at a screenshot. Save a revision snapshot before each rollout so the previous shape is one click away, and export structured JSON when the platform team wants the model, not just the picture. SVG and PNG snapshots cover tickets and docs; Pro adds embed for runbooks plus watermark-free PDF and JPEG.

The same board can carry the C4 context view above the cluster: Person and Software System at the top, Namespace frames below, so product and platform point at one picture. That is the difference between a drawing file and an architecture workspace: the Kubernetes canvas stays current because it is where the conversation already happens. Sign in with Google or GitHub, open the Kubernetes pack on Free, and draw the namespace you are shipping this week.

Open a published example

Questions

Do I need a running cluster to draw Kubernetes diagrams?

No. The Kubernetes pack is a drawing surface with 33 resource types, from Namespace, Pod, Deployment, StatefulSet, Service, and Ingress to Gateway API routes, RBAC roles, persistent volumes, and custom resources. Draw first, or paste your manifests into the Kubernetes YAML to diagram tool, then compare against the live cluster during review.

How is a Kubernetes canvas different from a whiteboard?

Whiteboards are wiped. An Archboard canvas autosaves, keeps revision snapshots, exports JSON plus SVG, PNG, JPEG, and PDF, and shares branded public links, so the map survives the meeting it was drawn in.

Can platform and product teams share one diagram?

Yes. Put the C4 context or a wireflow next to the Namespace frames on the same infinite canvas. Organizations, seats, and roles keep the workspace shared without sharing a whiteboard photo.

Bir dakikada canvas açın

Google veya GitHub ile giriş yapın. Tek koltuk ücretsiz; ekip katılınca planı yükseltin.