Kubernetes Operator Geliştirme: Custom Resource ve Controller

CNCF 2025 Annual Survey verilerine göre üretimdeki Kubernetes cluster’larının %57’si en az bir custom Operator çalıştırıyor; OperatorHub.io kataloğundaki community operator sayısı 380’i aştı ve Red Hat OpenShift Marketplace 240+ sertifikalı Operator listeliyor. Doğru tasarlanmış bir Operator, stateful workload yönetiminde manuel runbook süresini %71 azaltırken yanlış reconcile döngüsü API server’da dakikada 12.000+ gereksiz çağrı üretip cluster instabilitesine yol açabiliyor. 2026’da veritabanı, mesaj kuyruğu, AI workload ve hatta multi-cloud kontrol düzlemi yönetimi için Operator pattern, “tıklamasız” üretim operasyonunun temel yapı taşına dönüştü.

Bu kapsamlı rehberde Operator pattern’in temellerini, Custom Resource Definition (CRD) tasarım prensiplerini, controller reconcile döngüsünün iç işleyişini, Kubebuilder ile Operator SDK karşılaştırmasını, Red Hat Operator Capability Level modelini ve üretim-grade Operator inşa etmek için ihtiyacınız olan tüm operasyonel kararları detaylıca inceleyeceğiz. 2026 itibarıyla Operator pattern; Crossplane, ArgoCD ve service mesh kontrol düzlemleri dahil Kubernetes ekosisteminin omurgası haline gelmiş durumda.

Operator Pattern Nedir ve Neden 2026’da Standart Oldu?

CoreOS’un 2016’da tanımladığı Operator pattern, “uygulama-spesifik operasyonel bilgiyi yazılım olarak ifade etme” yaklaşımıdır. Kubernetes’in deklaratif modelini stateful uygulamalara genişletir: kullanıcı “istenen durum”u CRD ile bildirir, controller bu durumu sürekli reconcile eder. CNCF 2025 anketine göre Kubernetes kullanıcılarının %63’ü en az üç farklı Operator çalıştırıyor; Postgres, Kafka, MongoDB, Elasticsearch ve Redis bu listenin başında geliyor. Kubernetes Operator pattern dokümantasyonu bu yaklaşımı resmi olarak “domain-specific knowledge’ın kodla ifadesi” olarak tanımlıyor.

Operator pattern, klasik Helm chart yaklaşımının ötesine geçerek day-2 operasyonları (backup, upgrade, failover, scaling, rebalancing) otomatize eder. Docker’dan Kubernetes’e geçiş rehberi Operator pattern’i benimsemeden önce container fundamental’larını sağlamlaştırmanız gerektiğini hatırlatır; özellikle StatefulSet, PersistentVolumeClaim ve readiness probe kavramlarına hakim olmak şarttır.

• CRD (Custom Resource Definition): Kubernetes API’sine yeni nesne tipi ekleyen OpenAPI v3 şeması; declarative spesifikasyonun kök yapısıdır.
• Custom Resource (CR): CRD’nin somut örneği — kullanıcının kubectl apply ile gönderdiği YAML manifest.
• Controller: CR instance’larını watch eden, event handler tetikleyen ve reconcile yapan kontrol döngüsü.
• Reconciler: “Mevcut durum != istenen durum” olduğunda yakınsama sağlayan idempotent fonksiyon.
• Informer / Lister cache: Etcd’ye gereksiz baskı uygulamadan local cache üzerinden CR’ları okuyan abstraksiyon.

CRD ve Controller Pattern: Yapısal Bileşenler

Operator’un anatomik kalbini, CRD ile Controller arasındaki kontratın net tanımlanması oluşturur. Aşağıdaki tablo bir Operator’un kanonik bileşenlerini ve sorumluluklarını özetler; bu mimariyi anlamak, üretim hatalarının %80’ini önler.

Bileşen	Sorumluluk	Yazma Yetkisi	Tipik Yapı
CRD Schema	OpenAPI v3 validation, alan tipleri, required field tanımı	Cluster admin (apply zamanı)	YAML manifest + spec/status ayrımı
Spec alanı	Kullanıcı niyetini bildirir (desired state)	Son kullanıcı	Strongly-typed struct (Go), pydantic (Python)
Status alanı	Reconciler tarafından bildirilen mevcut durum	Controller (subresource)	Conditions array, ObservedGeneration
Reconcile fonksiyonu	Spec ile Status arasındaki uçurumu kapatır	Operator binary	Idempotent, hata toleranslı, requeue destekli
Watcher / Informer	CR event’lerini (Create/Update/Delete) tetikler	controller-runtime	Workqueue + rate limiter
Webhook (validating / mutating)	Apply anında manifest validation ve default değer ataması	Operator pod’u	cert-manager ile TLS otomasyonu
Finalizer	Delete operasyonunda cleanup blokları	Controller	String list; sıralı kaldırma garantisi

Kubernetes API Conventions belgesine göre spec ve status ayrı subresource’lardır; status’u kullanıcı yazamaz, sadece controller günceller. OpenAPI v3 şeması ile validation eklemek apply zamanında hatalı manifest’leri %94 oranında engeller; conversion webhook’lar v1alpha1’den v1’e geçişte downtime’sız upgrade sağlar. Bu disiplin Kubernetes Network Policy ve mikrosegmentasyon tarafında olduğu kadar Operator dünyasında da güvenlik denetimlerinin sıfır bulguyla geçmesinin temelidir.

Operator SDK Dilleri: Go, Ansible, Helm, Java, Python

Operator SDK 2025 sürümü beş ana dili destekliyor; her birinin kendine has güçlü ve zayıf yanları var. Doğru dil seçimi ekip becerisi, performans gereksinimi ve üretim olgunluğu hedefiyle eşleştirilmelidir. Aşağıdaki tablo 2026 itibarıyla beş resmi seçeneği karşılaştırır.

Dil	Tipik Reconcile Süresi	Bellek Footprint	Öğrenme Eğrisi	Üretim Olgunluğu	İdeal Kullanım
Go (controller-runtime)	5-20 ms	40-120 MB	Orta-Yüksek	Çok Yüksek	Performans kritik, kurumsal operatör
Ansible	800-3000 ms	180-400 MB	Düşük	Orta	Mevcut Ansible playbook’ları sarmalama
Helm	200-700 ms	60-150 MB	Çok Düşük	Düşük-Orta	Sadece kurulum + basit upgrade
Java (Quarkus / JOSDK)	15-40 ms	150-300 MB	Orta	Yüksek	Mevcut JVM ekipleri, Spring entegrasyon
Python (Kopf)	40-200 ms	80-200 MB	Düşük	Orta	Veri bilimi, AI workload operatörü

Go, üretim Operator dünyasında facto standardıdır: Kubernetes’in kendisinin de Go ile yazılmış olması ekosistem desteğini maksimize ediyor. Go ile yüksek performanslı backend yazısında bahsedilen goroutine ve channel modeli, controller-runtime’ın workqueue mimarisinin de temelidir; aynı concurrency primitiv’leri Operator binary’sinin onlarca CR’ı paralel reconcile etmesini sağlar.

Kubebuilder vs Operator SDK: Hangisi Sizin İçin?

İki framework de controller-runtime kütüphanesini temel alır; aralarındaki fark plumbing’in ne kadarını sizin için hazırladığında ve hangi ekosistemle (Kubernetes üst projesi mi, Red Hat OpenShift mi) sıkı entegre olduğunda. Aşağıdaki karşılaştırma 2026 sürümlerini referans alır.

Kriter	Kubebuilder 4.x	Operator SDK 1.39+
Sponsor	Kubernetes SIG API Machinery	Red Hat (CNCF Sandbox)
Desteklenen diller	Sadece Go	Go, Ansible, Helm, Java (JOSDK)
OLM (Operator Lifecycle Manager)	Manuel manifest	Yerleşik scaffolding
OperatorHub.io entegrasyonu	Manuel bundle hazırlama	make bundle ile otomatik
Webhook scaffolding	kubebuilder create webhook	operator-sdk create webhook
Test araçları	envtest, Ginkgo örnekleri	envtest + scorecard
Topluluk büyüklüğü	Çok geniş (Kubernetes core)	Geniş (Red Hat ekosistem)
Öğrenme materyali	The Kubebuilder Book (referans)	Red Hat OpenShift docs

Pratik öneri: Vendor-neutral bir operatör yazıyorsanız The Kubebuilder Book referansını takip edin; OpenShift’e satılacak veya Red Hat sertifikasyonu hedefleyen operatör için Operator SDK dokümantasyonu daha düşük sürtünme sağlar. GitOps ile Kubernetes yönetimi tarafında ArgoCD ve Flux, kendileri de Operator pattern üzerine kurulu birer kontrol düzlemi olarak bu kararı verirken tipik referans noktalardır.

Reconciliation Loop: Desired State vs Actual State

Reconcile döngüsü Operator’un kalbidir: deklaratif niyet (spec) ile gözlemlenen gerçeklik (status + cluster objeleri) arasındaki farkı kapatan idempotent fonksiyon. Aşağıdaki tablo bir reconcile çağrısının kanonik adımlarını ve her adımda olabilecek hata sınıflarını gösterir.

Adım	İşlem	Olası Hata	Tipik Eylem
1. Get CR	NamespacedName ile CR’ı cache’ten çek	NotFound (silinmiş)	Reconcile sonlandır, requeue: false
2. DeletionTimestamp kontrolü	Finalizer cleanup mantığı tetikle	External resource silmedi	Requeue + status: Terminating
3. Spec parse + validate	İş kuralı validation (webhook ötesi)	Anlamsal hata (port range, ref ID)	Status: Degraded, event yay
4. Child resource list	Owned StatefulSet, Service, ConfigMap	API throttling	Exponential backoff requeue
5. Diff hesapla	desired vs actual	Drift (manuel kubectl edit)	Patch / recreate
6. Apply child resources	CreateOrUpdate çağrıları	Conflict (resource version)	Optimistic retry
7. Status update	Conditions + ObservedGeneration	Status subresource conflict	Retry with backoff
8. Requeue karar	RequeueAfter (polling) veya event-driven	Tight loop riski	Min interval guard

Idempotency mutlak şarttır: Aynı CR için reconcile çağrısı 1 kez veya 100 kez çalışsın, sonuç (yan etki dahil) aynı olmalı. Datadog 2025 Operator telemetri verisine göre üretimdeki crash’lerin %42’si reconcile fonksiyonundaki side effect biriktirmesinden (örneğin her çağrıda yeni event kaydı, her çağrıda counter artırma) kaynaklanıyor.

Red Hat Operator Capability Levels: 5 Olgunluk Seviyesi

Red Hat’in Operator Maturity modeli, bir Operator’un day-2 yetenek olgunluğunu beş seviyede sınıflandırır. Bu çerçeve, üretim risk değerlendirmesinde ve roadmap planlamasında ekosistemin ortak dilidir.

Level	İsim	Yetenek	Üretim Yüzdesi (CNCF 2025)	Örnek Operator
L1	Basic Install	CRD apply, deployment, ConfigMap yönetimi	%31	Basit web app operatörü
L2	Seamless Upgrades	Patch ve minor versiyon geçişleri, rolling update	%24	Redis Operator (basic)
L3	Full Lifecycle	Backup, restore, failover, point-in-time recovery	%23	MongoDB Community Operator
L4	Deep Insights	Prometheus metrik, alert kuralı, log agregasyonu	%14	Strimzi Kafka Operator
L5	Auto Pilot	Horizontal scaling, anomaly detection, self-tuning	%8	CrunchyData Postgres, K8ssandra

Çoğu kurumsal ekip Level 1-2 ile başlar; her seviye yaklaşık 4-8 mühendis-haftası ek yatırım gerektirir. Level 5’e ulaşan Operator’lar tipik olarak 12-24 ay olgunlaşma sürecinden geçer ve observability mimarisi (Logs/Metrics/Traces) ile derinden entegredir; Deep Insights seviyesinin önkoşulu zaten olgun bir observability stack’idir.

OperatorHub.io ve Ekosistem: 380+ Operatörün Kataloğu

OperatorHub.io 2025 sonu itibarıyla 380+ community Operator listeliyor; Red Hat OpenShift Marketplace ise 240+ sertifikalı Operator sunuyor. Bu katalog 2026 itibarıyla Kubernetes ekosisteminin “uygulama mağazası” rolünü üstleniyor.

Kategori	Operator Sayısı	Popüler Örnekler	Tipik Capability
Databases	78	Postgres, MySQL, MongoDB, Cassandra	L3-L5
Streaming & Messaging	54	Kafka (Strimzi), RabbitMQ, NATS	L3-L4
AI / ML	41	Kubeflow, Seldon, MLflow	L2-L4
Security	36	cert-manager, Falco, Kyverno	L3-L5
Networking & Mesh	33	Istio, Cilium, MetalLB	L4-L5
Storage	28	Rook, OpenEBS, Longhorn	L3-L4
Monitoring	26	Prometheus, Grafana, Loki	L4-L5
Cloud Provider	22	AWS Controllers, Crossplane, Azure SO	L3-L4
Diğer	62	Backup, IDP, GitOps tooling	Karışık

Crossplane gibi çok-bulut yönetim katmanları Operator pattern’i temel alır ve AWS, Azure, GCP kaynaklarını CRD üzerinden yönetir. Crossplane vs Terraform Kubernetes-native IaC karşılaştırması bu yaklaşımı detaylandırır; pratik olarak Crossplane “her şey bir CR” felsefesini multi-cloud sınırına taşıyor. OperatorHub.io kataloğu Operator keşfi için 2026’da hâlâ birincil giriş kapısı.

Kubebuilder ile Adım Adım Uygulama

Kubebuilder ile bir Operator’u sıfırdan üretime taşımanın altı kanonik adımı vardır. Aşağıdaki workflow, üretim olgunluğu hedeflenen Level 3+ bir Operator için temel iskeleti çıkarır.

1. Proje iskeleti: kubebuilder init --domain example.com --repo example.com/myop komutuyla go.mod, Dockerfile, Makefile ve manager binary’sini hazırlayın.
2. API tanımı: kubebuilder create api --group apps --version v1alpha1 --kind MyApp ile CRD ve controller iskeletini üretin; OpenAPI v3 validation şemasını strict tipler ve +kubebuilder:validation: marker’ları ile doldurun.
3. Reconcile mantığı: Reconcile(ctx, req) fonksiyonunda idempotent eylem zinciri yazın; her aşamada error wrapping ve structured logging (logr) kullanın.
4. RBAC marker’ları: // +kubebuilder:rbac:groups=apps,resources=deployments,verbs=get;list;watch;create;update;patch;delete şeklinde minimum gereksinimleri imzalayın; cluster-admin tuzağına düşmeyin.
5. Webhook eklentisi: kubebuilder create webhook --defaulting --programmatic-validation ile validating + mutating webhook iskeletini oluşturun; cert-manager ile TLS sertifikasını otomatize edin.
6. Test ve dağıtım: envtest ile unit + integration test yazın, make docker-build docker-push deploy ile cluster’a deploy edin; CI’da kind cluster üzerinde e2e koşturun.

Reconcile fonksiyonunun varsayılan rate-limit’i exponential backoff ile 5 ms’den başlayıp 1000 saniyeye kadar büyür; bu davranış API server’ı korur ama “tight loop” hatalarınızda gizli gecikmelere de yol açabilir. Service mesh Istio/Linkerd/Consul karşılaştırması tarafında olduğu gibi, control plane bileşenleri için requeue/retry stratejisi gözlemlenebilir olmalıdır — reconcile_total ve reconcile_errors metriklerini Prometheus’a expose edin.

Hata Yönetimi, Status Conditions ve Event Tasarımı

Bir Operator’un kullanıcı deneyimi büyük ölçüde nasıl hata raporladığında belirir. Conditions array’i (Ready, Progressing, Degraded, Available), kullanıcılara standart bir kubectl describe çıktısı sunar; Kubernetes event API’si ise debug deneyimini insan-okunabilir hale getirir.

Hata Sınıfı	Belirti	Reconcile Stratejisi	Status Condition
Transient (API throttle)	429 / 503 cevap	Exponential backoff requeue	Progressing=True, Reason=Retrying
Validation (yanlış spec)	Webhook ötesi anlamsal hata	Requeue: false, kullanıcı düzeltmeli	Ready=False, Reason=InvalidSpec
External dependency	Veritabanı ulaşılamaz	RequeueAfter: 30s, circuit breaker	Degraded=True, Reason=DepDown
Drift (manuel kubectl edit)	Child resource fark	Reconcile içinde patch	Progressing=True, Reason=Drifting
Permanent (RBAC, quota)	403 / quota exceeded	Event yay, no requeue	Ready=False, Reason=Forbidden
Unknown / panic	Beklenmedik exception	Recover + log + requeue	Degraded=True, Reason=Unknown

• Conditions: ObservedGeneration ile birlikte rapor edilmeli; eski generation’a ait status değerlerinden kaçınılmalı.
• Events: kubectl get events ile görünür; FieldRef ile CR’a bağlanmalı, normal vs warning sınıfı doğru seçilmeli.
• Metrics: controller-runtime varsayılan olarak reconcile_total, reconcile_errors, reconcile_time_seconds Prometheus metriklerini expose eder.
• Leader election: HA dağıtımda iki replica çalışsa bile sadece biri reconcile yapar; split-brain önlenir. Lease objesi varsayılan namespace’te tutulur.
• Tracing: OpenTelemetry instrumentasyon, reconcile span’lerini external API çağrıları ile ilişkilendirir; root cause analizi hızlanır.

Güvenlik, RBAC ve Tedarik Zinciri

Operator’lar yüksek ayrıcalıklı bileşenlerdir; CRD instance’larını yönettikleri için tipik olarak Deployment, Service, Secret, ConfigMap ve hatta PersistentVolume objeleri üzerinde write yetkisine ihtiyaç duyarlar. Bu ayrıcalık doğru sınırlanmadığında, tek bir kompromize Operator pod’u tüm cluster’ı tehlikeye atabilir. Datadog 2025’e göre üretim operatörlerinin %38’i hâlâ aşırı izinli; OPA/Gatekeeper veya Kyverno politikaları ile bu yakalanmalıdır.

RBAC minimizasyonu için kubebuilder rbac marker’larını kullanın ve cluster-wide kaynaklar zorunlu değilse namespace-scoped Role tercih edin. Container güvenliği Docker ve Kubernetes rehberi, Operator pod’unun runtime korumalarını (seccomp, AppArmor, read-only root filesystem, runAsNonRoot) detaylandırır; bu disiplin Operator binary’sinin tedarik zinciri saldırılarında patlama yarıçapını minimize eder. Azure Container Apps karşılaştırması ise managed control plane tarafındaki paralel disiplini gösterir.

Maliyet, Ölçek Sınırları ve ROI

Datadog 2025 K8s metriklerine göre kötü yazılmış bir Operator API server CPU’sunda %23’e varan artış üretir; iyi tasarlanmış olanlarda bu rakam %2 altındadır. Operatörün geliştirme maliyeti tipik 6-12 mühendis-haftasıdır; ancak veritabanı operatörü manuel operasyon süresini ekip başına aylık 80 saatten 12 saate düşürür ve birinci yılda yaklaşık 5.4x ROI üretir. Üretimde 5.000+ CRD instance’ı yöneten operatörlerde sharded controller mimarisi önerilir; her shard belirli bir namespace alt kümesini izler.

controller-runtime’ın MaxConcurrentReconciles parametresi varsayılan 1, üretim için tipik olarak 5-20 aralığında ayarlanır. Kontrol döngüsünde dış API’ye blocking çağrı yapmak reconciler queue’sunu kilitler ve cluster-wide gecikmeye yol açar; bu nedenle uzun süren işlemler asenkron pattern’lere (status: Pending → external job → status: Ready) ayrılmalıdır. Cloud-native mimari best practices tarafında bu yaklaşım “yarı-eşzamansız reconcile” olarak adlandırılır ve modern Operator tasarımının altın kuralıdır.

Sık Sorulan Sorular

Sonuç: Hangi SDK ve Stack Seçilmeli?

Kubernetes Operator pattern, 2026’da stateful workload otomasyonunun standart yaklaşımıdır. Doğru CRD tasarımı, idempotent reconcile döngüsü ve minimum RBAC, üretim güvenilirliğinin üç temel sütunudur. Bizim 2026 verdict’imiz net: Vendor-neutral yeni Operator için Kubebuilder + Go + controller-runtime kombinasyonu; çünkü Kubernetes core ekosistemine en yakın, performans karakteristiği en iyi ve topluluk büyüklüğü en geniş olan seçim budur. Red Hat OpenShift’e satışı veya OperatorHub.io üzerinde sertifika hedefliyorsanız Operator SDK 1.39+ Go modu daha düşük sürtünme sağlar; OLM ve bundle scaffolding’i hazırdır.

Pratik özet: Level 1-2 hedefiyle başlayın, idempotency’yi ilk günden uygulayın, RBAC’ı namespace-scoped tutun, envtest tabanlı CI kurun ve metrik/event/condition trilojisini gözlemlenebilirlik için baseline kabul edin. Bu disiplinle inşa edilen Operator’lar kurumsal ölçekte 5.4x ROI ve manuel operasyon süresinde %71 tasarruf sağlayan kanıtlanmış pattern’i takip eder; 2026 itibarıyla “Operator yazmasak da bir tane kuralım” rahatlığının ardındaki mühendislik disiplini de tam olarak budur.