- 01AKS control plane işletimini azaltır ancak production Kubernetes day-2 operasyonunu tamamen ortadan kaldırmaz.
- 02Node pool, kapasite, autoscaling, resource request/limit, network, security ve application reliability kararları platform ekibinin sorumluluğunda kalır.
- 03Production upgrade'leri preproduction test, maintenance window, PDB ve compatibility kontrolüyle planlanmalıdır.
- 04Monitoring node CPU ile sınırlı kalmamalı; Kubernetes ve application-level sinyaller birlikte izlenmelidir.
- 05AKS Automatic daha fazla managed default, AKS Standard ise networking, node pool ve upgrade kararlarında daha fazla kontrol sağlar.
Kısaca
Azure Kubernetes Service (AKS), Microsoft Azure üzerinde Kubernetes cluster'larını çalıştırmak için sunulan yönetilen Kubernetes hizmetidir. AKS control plane işletimini azaltır ancak production operasyonunu tamamen ortadan kaldırmaz. Node pool tasarımı, kapasite, network, security policy, observability, upgrade, backup ve workload reliability kararlarının önemli bölümü hâlâ platform veya DevOps ekibinin sorumluluğundadır.
AKS production operasyonunda sorumluluk nasıl paylaşılır?
AKS kullanırken Microsoft Kubernetes control plane'in önemli bölümünü yönetir. Ancak production cluster'ın güvenilirliği yalnız control plane'in ayakta olmasına bağlı değildir.
Operasyon ekibinin karar verdiği alanlar arasında şunlar bulunur:
- cluster mode
- node pool yapısı
- VM size ve kapasite
- availability zones
- autoscaling
- network ve ingress
- identity
- workload resource request/limit
- pod disruption budget
- upgrade cadence
- observability
- backup/recovery
- incident response
Bu nedenle "managed Kubernetes kullanıyoruz, cluster artık operasyon gerektirmiyor" yaklaşımı doğru değildir.
AKS Automatic ve AKS Standard
Microsoft güncel AKS guidance'ında iki ana çalışma modelini ayırır.
AKS Automatic
Daha fazla production-ready default sağlar. Node management, autoscaling, security baseline ve common production defaults alanlarında daha opinionated bir modeldir.
AKS Standard
Networking, node pool, upgrade, policy ve cluster topology üzerinde daha fazla kontrol sağlar.
Şu senaryolarda daha uygun olabilir:
- özel network topolojisi
- gelişmiş CNI gereksinimi
- farklı node pool'lar
- sıkı change-management
- regulated workload
- platform engineering standardı
- özel upgrade cadence
Karar yalnız "hangisi daha kolay?" sorusuyla verilmemelidir. Workload ve operasyon olgunluğu birlikte değerlendirilmelidir.
Node pool tasarımı production güvenilirliğini etkiler
Microsoft AKS baseline architecture system workload ile application workload'un farklı node pool'larda tutulmasını önerir.
Bu ayrım şu riskleri azaltır:
- application pod'larının system component kaynaklarını tüketmesi
- upgrade sırasında kapasite baskısı
- scheduling karmaşası
- troubleshooting zorluğu
Production başlangıcında node sayısı workload'a göre ölçülmelidir. Microsoft baseline guidance system node pool için üç node, user node pool için en az iki node ile başlamayı önerir. Gerçek ihtiyaç availability zone, workload replica sayısı, upgrade surge, maintenance ve peak traffic ile birlikte hesaplanmalıdır.
Availability zone tasarımı
AKS cluster'ı tek failure domain'e bağımlı bırakmak production riskini artırabilir.
Availability zone desteklenen region'larda node'ları farklı fiziksel zone'lara dağıtmak zone failure etkisini azaltabilir. Ancak yalnız node'ları farklı zone'a dağıtmak yeterli değildir.
Uygulamanın da:
- birden fazla replica
- topology spread
- readiness probe
- Pod Disruption Budget
- zone-aware storage
gibi kontrollerle tasarlanması gerekir.
Resource request ve limit olmadan kapasite yönetimi zorlaşır
Kubernetes scheduler pod'ları node'lara resource request değerlerine göre yerleştirir.
Request değerleri gerçek kullanımdan çok düşükse runtime contention yaşanabilir. Çok yüksek request tanımlanırsa da cluster gereksiz büyüyebilir.
CPU ve memory için historical utilization, p95/p99 workload davranışı, burst pattern ve startup ihtiyacı ölçülmelidir.
Kubernetes maliyeti rehberinde cost ve rightsizing tarafını ayrıca ele alıyoruz.
Autoscaling tek başına kapasite stratejisi değildir
AKS ortamında farklı scaling katmanları bulunabilir:
- Horizontal Pod Autoscaler
- Vertical Pod Autoscaler
- Cluster Autoscaler
- KEDA
Bu araçların birlikte nasıl çalıştığı anlaşılmadan yapılan konfigürasyon oscillation veya gereksiz maliyet yaratabilir.
Autoscaling için minimum replica, maximum replica, scale metric, stabilization window, node min/max ve quota önceden belirlenmelidir.
Upgrade production operasyonunun önemli parçasıdır
AKS cluster üç farklı update katmanına sahiptir:
- Kubernetes version
- node image
- işletim sistemi update'leri
Microsoft production cluster upgrade'lerinin preproduction ortamında test edilmesini, maintenance window kullanılmasını ve Pod Disruption Budget gibi kontrollerin upgrade sürecini engellemeyecek şekilde tasarlanmasını önerir.
Upgrade öncesinde deprecated API, ingress/controller uyumluluğu, service mesh, security agent, CSI driver ve workload compatibility kontrol edilmelidir.
Pod Disruption Budget neden önemlidir?
PDB, planlı disruption sırasında minimum application availability seviyesini korumaya yardımcı olur.
Ancak agresif PDB konfigürasyonu node drain'i engelleyebilir, upgrade süresini uzatabilir ve maintenance operasyonunu bloke edebilir.
Örneğin iki replica çalışan kritik bir uygulamada minAvailable değerini 2 yapmak node maintenance sırasında pod taşımasını engelleyebilir.
Readiness ve liveness probe farklı amaç taşır
Readiness probe pod'un trafik almaya hazır olup olmadığını; liveness probe ise pod'un sağlıklı olup olmadığını belirler.
Yanlış probe çalışan uygulamayı sürekli restart edebilir veya trafik hazır olmayan pod'a gidebilir. Startup probe ise yavaş başlayan uygulamalarda liveness kontrolünün çok erken devreye girmesini önlemeye yardımcı olabilir.
Monitoring yalnız node CPU değildir
AKS production monitoring'i üç katmanda ele alınmalıdır.
Infrastructure
- node CPU/RAM
- disk
- network
- node condition
- autoscaler event
Kubernetes
- pod restart
- pending pod
- deployment replica
- scheduling failure
- ingress error
Application
- request rate
- error rate
- latency
- dependency
- business metric
Microsoft Container Insights, Prometheus ve Azure Monitor entegrasyonları kullanılabilir.
Azure Monitor içeriğinde Azure observability tarafını ayrıca ele alıyoruz.
Security shared responsibility olarak ele alınmalıdır
AKS managed service olsa da workload security otomatik çözülmez.
Platform ekibi RBAC, workload identity, secret, network policy, container image, admission/policy, vulnerability, node access ve namespace separation alanlarını yönetmelidir.
Azure Policy ve Defender for Containers gibi servisler yardımcı olabilir ancak security ownership'i ortadan kaldırmaz.
Backup neyi kapsamalıdır?
AKS backup yalnız node VM snapshot almak değildir.
Cluster yeniden oluşturulabilir bir infrastructure-as-code modeline sahip olsa bile stateful workload ve persistent data ayrıca korunmalıdır.
Backup kapsamı persistent volume, database, application config, secret-management recovery, Git/IaC repository ve external service config gibi alanları kapsayabilir.
Production cluster kaybında hedef cluster + workload + data üçlüsünü tekrar ayağa kaldırabilmektir.
Incident response runbook olmadan operasyon eksik kalır
AKS incident'ları yalnız Kubernetes kaynaklı olmayabilir.
Örnek kaynaklar:
- Azure quota
- IP exhaustion
- DNS
- container registry
- certificate
- ingress
- database
- identity
- application deployment
Runbook içinde alarm owner, escalation, cluster access, rollback, node replacement, pod troubleshooting, deployment rollback ve network kontrolü tanımlanmalıdır.
Kubernetes production sorunları içeriğinde sık karşılaşılan operasyon problemlerini ayrıca ele alıyoruz.
AKS kullanırken Microsoft neyi yönetir, ekip neyi yönetir?
| Alan | Microsoft | Operasyon ekibi |
|---|---|---|
| Kubernetes control plane altyapısı | Büyük ölçüde | Konfigürasyon/erişim kararları |
| Node VM kapasitesi | Azure altyapısı | Size, pool, scale |
| Kubernetes version | Sürümü sunar | Upgrade stratejisi |
| Node image | Image sağlar | Update cadence |
| Workload | Hayır | Evet |
| Resource request/limit | Hayır | Evet |
| Network policy | Platform imkânı | Policy tasarımı |
| Monitoring | Servis sunar | Alarm/SLO/runbook |
| Security | Platform kontrolleri | Workload ve policy |
| Backup | Araç/entegrasyon | Recovery tasarımı |
Bu ayrım deployment modeline göre değişebilir; AKS Automatic daha fazla default yönetebilir ancak uygulama ve business operasyon sahipliği yine ekipte kalır.
Dynamis'te AKS production yönetimi
Dynamis'te AKS operasyonu yalnız cluster deployment ile başlamaz.
Önce workload inventory, availability hedefi, node pool, network, identity, ingress, storage, autoscaling, upgrade, observability, security, backup ve cost birlikte değerlendirilir.
Ardından day-2 operasyon için monitoring, incident response, upgrade, capacity, security patch, cost review ve backup test cadence'i belirlenir.
Kubernetes platform operasyonunu dış kaynakla yürütmek için DevOps Consulting ve Managed Kubernetes hizmetini inceleyebilirsiniz.
Azure subscription ve platform kaynaklarının yönetimi için Managed Azure hizmeti secondary destination olarak değerlendirilebilir.
Sık yapılan hatalar
Managed Kubernetes = operasyon yok sanmak: AKS control plane yükünü azaltır, workload operasyonunu kaldırmaz.
Tek node pool kullanmak: System ve application workload kaynak rekabetine girebilir.
Upgrade'i plansız bırakmak: Version skew ve deprecated API riski büyür.
PDB'yi aşırı agresif tanımlamak: Node drain ve maintenance bloke olabilir.
Request/limit vermemek: Scheduling ve cost optimizasyonu zorlaşır.
Yalnız node monitoring yapmak: Application ve Kubernetes-level sinyaller görünmez kalır.
Sırada ne var
- Kubernetes nedir?
- Kubernetes production sorunları
- Kubernetes'e geçiş rehberi
- Kubernetes maliyeti
- Azure Monitor
- DevOps Consulting
- Managed Azure
Kaynaklar
Kaynaklar
- 1.Baseline architecture for an AKS clusterMicrosoft Learn · 2026-10-12
- 2.AKS cluster reliability best practicesMicrosoft Learn · 2026-10-12
- 3.AKS architecture best practicesMicrosoft Learn · 2026-10-12
- 4.AKS best practicesMicrosoft Learn · 2026-10-12
- 5.AKS planningMicrosoft Learn · 2026-10-12
Sık sorulan sorular
AKS nedir?
Azure Kubernetes Service (AKS), Microsoft Azure üzerinde Kubernetes cluster'larını oluşturmak ve işletmek için sunulan yönetilen Kubernetes hizmetidir. Control plane Microsoft tarafından yönetilir; workload, node pool, ağ, güvenlik, upgrade ve day-2 operasyon kararlarının önemli kısmı müşteri veya operasyon ekibinde kalır.
AKS Automatic ile AKS Standard arasındaki fark nedir?
AKS Automatic daha fazla production-ready default ve otomatik node/upgrade/security yönetimi sunar. AKS Standard ise networking, node pool, upgrade cadence ve cluster konfigürasyonunda daha fazla kontrol isteyen ekipler için uygundur.
AKS production cluster için kaç node gerekir?
Tek doğru sayı yoktur. Microsoft baseline guidance system node pool için üç node, user node pool için en az iki node ile başlamayı önerir; gerçek sayı availability zone, workload kapasitesi, upgrade surge ve failure-domain gereksinimine göre belirlenir.
AKS upgrade'lerini kim yönetir?
AKS control plane Microsoft tarafından yönetilir ancak cluster version, node image, maintenance window, compatibility testleri ve workload disruption kararları deployment modeline göre operasyon ekibinin sorumluluğunda kalabilir. Production upgrade'leri preproduction testleriyle planlanmalıdır.
AKS kullanmak Kubernetes operasyonunu tamamen ortadan kaldırır mı?
Hayır. AKS control plane işletimini azaltır ancak node pool sizing, application deployment, resource limits, observability, security policy, backup, upgrade planning ve incident response gibi day-2 operasyonlar devam eder.