Kubernetes Mimari Diyagramı Nasıl Çizilir? (Ücretsiz Şablonla)

Çoğu Kubernetes diyagramı iki şekilde başarısız olur: ya kimsenin okuyamadığı bir Pod ikonu duvarıdır ya da "cluster" yazan ve başka pek bir şey söylemeyen üç kutuluk bir taslak. İşe yarayan bir Kubernetes mimari diyagramı bu ikisinin arasında durur. Trafiğin nereden girdiğini, onu hangi nesnelerin yönlendirdiğini, durumun (state) nerede tutulduğunu ve hangi sınırların önemli olduğunu, okuyan kişiye uygun bir ayrıntı düzeyinde gösterir.

Bu rehberde neleri eklemeniz gerektiğini, ayrıntı düzeyini kitleye göre nasıl seçeceğinizi, diyagramları işe yaramaz hâle getiren hataları ve Archboard'da adım adım nasıl çizeceğinizi bulacaksınız. Ücretsiz şablon, tek tıkla kendi çalışma alanınızda yeni bir diyagram olarak açılır.

İyi bir Kubernetes mimari diyagramı neyi gösterir?

Kubernetes dokümantasyonu cluster bileşenlerini anlatır: control plane, kubelet, kube-proxy vb. Bu, platform görünümüdür. Çoğu ekibin ihtiyacı ise iş yükü görünümüdür: sizin uygulamanızın cluster üzerinde nasıl çalıştığı. Değerin büyük kısmını beş şey taşır.

1. Cluster ve namespace sınırları

Cluster'ı dış sınır, namespace'leri de onun içindeki çerçeveler olarak çizin. RBAC, resource quota'lar ve NetworkPolicy'lerin çoğu namespace düzeyinde uygulanır; bu yüzden insanların ilk sorduğu sınırlar bunlardır ("payments kendi namespace'inde mi?"). Birden fazla cluster çalıştırıyorsanız (prod ve staging ya da bölge başına bir cluster), her birine kendi sınırını verin ve adını ve ortamını yazın.

2. North-south trafik

İstek yolunu cluster'ın dışından içeriye doğru gösterin:

Client → Ingress → Service → Deployment → Pods

Yönü oklarla açıkça belirtin. Ingress'in host ve path kurallarını, Service'in tipini ve port'unu not edin. Bu tek yol, bir olay (incident) sırasında sorulan "bu istek nereye gidiyor?" sorularının çoğunu yanıtlar.

East-west trafik (cluster içinde servisten servise) de önemlidir, ancak seçici çizin: namespace'ler arası geçen ya da kritik yol üzerindeki çağrılar yeterlidir.

3. Yapılandırma ve depolama

ConfigMap, Secret ve PersistentVolumeClaim'leri onları kullanan iş yüklerine bağlayın. Secret ve PVC'si olan bir Deployment okuyucuya iki şey söyler: bu iş yükü kimlik bilgileri taşıyor ve bir Pod'dan daha uzun yaşayan bir durumu var. Yönetilen bir Postgres gibi harici durumu cluster sınırının dışına çizin; böylece cluster'ın neye sahip olduğu ve neye sahip olmadığı netleşir.

4. Ölçekleme

HorizontalPodAutoscaler'ı hedeflediği Deployment'ın yanına koyun; min/max replika sayısını ve metriği adına ya da bir nota yazın ("2–10, CPU %70"). Bu, çizilmiş on Pod'dan daha fazlasını anlatır.

5. NetworkPolicy

NetworkPolicy kullanıyorsanız hangilerinin geçerli olduğunu ve neye izin verdiklerini gösterin. Bir güvenlik incelemecisi "Postgres'e yalnızca api namespace'i erişebilir" bilgisini çıkarım yaparak değil, doğrudan görmek ister.

Manifest'ler diyagram düğümlerine nasıl karşılık gelir?

Üç sıradan nesneyi ele alalım:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders-api
  namespace: shop
spec:
  replicas: 3
  selector:
    matchLabels: { app: orders-api }
  template:
    metadata:
      labels: { app: orders-api }
    spec:
      containers:
        - name: api
          image: registry.example.com/orders-api:1.4.2
          ports: [{ containerPort: 8080 }]
          envFrom: [{ secretRef: { name: orders-db } }]
---
apiVersion: v1
kind: Service
metadata:
  name: orders-api
  namespace: shop
spec:
  selector: { app: orders-api }
  ports: [{ port: 80, targetPort: 8080 }]
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop
  namespace: shop
spec:
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /orders
            pathType: Prefix
            backend:
              service: { name: orders-api, port: { number: 80 } }

Diyagramda şunlara dönüşürler:

Üç replika, üç Pod kutusu değil, "×3" yazan tek bir Deployment düğümü olur. Kenarlar YAML'daki referansları izler: Ingress backend → Service, Service selector → Deployment, envFrom → Secret.

Ayrıntı düzeyini kitleye göre seçin

Tek bir diyagram nadiren herkese hizmet eder. Çizmeden önce kimin için olduğuna karar verin.

İki kitlenin farklı ihtiyaçları varsa, her şeyi yapmaya çalışan tek bir diyagram yerine iki ayrı görünüm çizin.

Sık yapılan hatalar

• Her Pod replikasını çizmek. Replikalar mimari değil, bir sayıdır. Replika sayısı yazan tek bir Deployment düğümü (ölçekleniyorsa yanında bir HPA), birbirinin aynısı kutulardan oluşan bir ızgaradan daha kolay okunur.
• Mantıksal ve fiziksel görünümü karıştırmak. Worker node'lar, zone'lar ve Pod yerleşimi fiziksel görünümdür; Ingress → Service → Deployment mantıksal görünümdür. İkisini aynı tuvale koyarsanız hiçbiri okunmaz. Fiziksel görünüme ihtiyacınız varsa ayrı bir diyagram yapın.
• Trafik yönü olmaması. Oksuz çizgiler kimin kimi çağırdığını söylemez. Yönlü kenarlar kullanın ve ana istek akışını tek yönde tutun: soldan sağa ya da yukarıdan aşağıya.
• Güncelliğini yitirmiş diyagramlar. Geçen yılın servislerini gösteren bir diyagram, hiç olmamasından daha çok zarar verir. Tuvale bir sahip ve "son kontrol" tarihi ekleyin; bir değişiklik kutu eklediğinde ya da kaldırdığında diyagramı güncelleyin.
• Açıklamasız kenarlar. "Service → Deployment" açıktır; ama "orders-api → payments-api" bir protokolü ve port'u hak eder.

Archboard'da adım adım çizim

Archboard'un Kubernetes paketinde, Namespace (frame olarak çizilir), Node, Pod, Deployment, StatefulSet, Job ve CronJob'dan Service, Ingress, Gateway API route'ları, ConfigMap, Secret, PersistentVolumeClaim, HPA, NetworkPolicy ve RBAC'ye kadar portlu 33 birinci sınıf node türü var. Genel şekiller arasında serbest çizgiler çekmek yerine portları bağlarsınız. YAML’dan içe aktar… ile manifest'lerinizden başlayabilir ya da her node'u elle yerleştirebilirsiniz; her iki durumda da bu rehberin konusu olan "burada ne önemli?" kararı sizde kalır.

1. Örnekleri inceleyin. Kubernetes mikroservis örneğini (Ingress → Service → Deployment/Pod → PVC → Postgres) ve Ingress akışı örneğini açın. Yerleşime dikkat edin: trafik tek yönde akar ve durum en sonda yer alır.
2. Çalışma alanınızda bir diyagram oluşturun ve cluster için, cluster ve ortam adını taşıyan bir Frame ekleyin.
3. Namespace ekleyin: önemli her namespace için cluster çerçevesinin içine bir Namespace yerleştirin.
4. İstek yolunu yerleştirin: soldan sağa Ingress, Service, ardından Deployment. Port'ları birbirine bağlayın ve host/path ile port'lar için kısa Text etiketleri ekleyin.
5. Yapılandırmayı ve durumu bağlayın: ConfigMap ve Secret'ı onları okuyan Deployment'ın yanına, kalıcı depolama için bir PVC'yi ve yönetilen Postgres için cluster çerçevesinin dışına bir veritabanı düğümü koyun.
6. Ölçekleme ve politika ekleyin: Deployment'ının yanına min/max ve metrik bilgisiyle bir HPA, koruduğu namespace sınırlarına da NetworkPolicy düğümleri.
7. Tuvale bağlam ekleyin: sahip, son kontrol tarihi ve repo ya da runbook bağlantılarını içeren bir Markdown bloğu. Tuvalde kod blokları da kullanılabilir; böylece ilgili manifest parçası düğümlerinin hemen yanında durabilir.
8. Paylaşın: bir tasarım dokümanı için SVG ya da PNG olarak dışa aktarın veya herkese açık bir bağlantı paylaşın. Otomatik kayıt ve revizyon anlık görüntüleri, bir düzenleme ters giderse geri dönmenizi sağlar.

Birden fazla cluster'ı çoklu hesap görünümünde göstermek için Cloud paketinde bir Kubernetes Cluster düğümü bulunur.

Free plan tüm yerleşik paketleri içerir ve diyagram başına 15 diyagram node'una, ayrıca 150 not ve metne izin verir; bu, tek bir servisin istek yoluna yeter. Çok servisli tam bir harita için büyük olasılıkla Pro gerekir.

Ücretsiz şablon

Ücretsiz şablon /templates/kubernetes-architecture sayfasındadır: Bu şablonu kullan onu çalışma alanınızda yeni bir diyagram olarak açar. Daha kapsamlı bir yerleşim için /examples/kubernetes-microservices sayfasındaki Bu örneği kullan diyagramı kopyalar; böylece düğümleri kendi servislerinize göre yeniden adlandırabilirsiniz. Yalnızca trafik yolu için /examples/kubernetes-ingress-flow daha küçük bir başlangıç noktasıdır. Daha fazla kalıp için Kubernetes kullanım senaryosu sayfasına bakın.

SSS

Control plane'i çizmeli miyim? Yalnızca diyagram platformun kendisiyle ilgiliyse; örneğin bir platform ekibi ya da bir yükseltme planı için. Uygulama diyagramlarında control plane gürültüdür; okuyucular onun var olduğunu zaten varsayar.

Pod mu, Deployment mı? Replika sayısıyla birlikte Deployment. Tek tek Pod'ları yalnızca belirli bir Pod önemli olduğunda çizin: bir sidecar düzeni, bir hata ayıklama oturumu ya da bir Job veya CronJob çalıştırması.

Diyagramı nasıl güncel tutarım? Ona bir sahip atayın, tuvale son kontrol tarihini yazın ve gösterdiği servisleri değiştiren pull request'lerle birlikte gözden geçirin. Diyagramın JSON dışa aktarımı, repoda manifest'lerin yanında durabilir.

Tek bir diyagram birden fazla cluster'ı kapsayabilir mi? Evet, daha üst bir düzeyde: her cluster için bir sınır ve yalnızca cluster'lar arası trafik. Cluster başına ayrıntıyı ayrı diyagramlarda tutun.

Ücretsiz başlayın — bir kullanıcı, kredi kartı gerekmez