📝 YAML Manifestler — Uygulamalı

YAML Manifestler — Uygulamalı: Kubernetes'te her şey "manifest" adı verilen YAML dosyaları olarak tanımlanır — YAML'ı cluster'a yazdığın bir mektup gibi düşün: "Sevgili K8s, lütf

Kubernetes'te her şey "manifest" adı verilen YAML dosyaları olarak tanımlanır — YAML'ı cluster'a yazdığın bir mektup gibi düşün: "Sevgili K8s, lütfen uygulamamın 3 kopyasını çalıştır, 8080 portuna bağla ve sağlıklı kalmalarını sağla." YAML girintisi kesinlikle 2 boşluk olmalıdır; yanlış girinti mektubu bozar. Peki `kubectl create` komutlarını sırayla çalıştıran imperative bir script yerine neden declarative YAML kullanıyoruz? Çünkü bir script ADIMLARI tarif eder ve adımlar eskir — onu iki kez çalıştırmak aynı Deployment'ı iki kez oluşturmaya çalışıp başarısız olabilir. Bir YAML manifest ise İSTENEN DURUMU tarif eder, bu yüzden onu 100 kez uygulamak bir kez uygulamakla aynı sonucu verir (`kubectl apply` idempotent'tir) — bu, bir Java REST API'sinin PUT'u idempotent tasarlarken POST'u tasarlamamasıyla aynı prensiptir. QA riski şu: bozuk girintili bir manifest genellikle gürültülü bir şekilde başarısız olmaz — sessizce amaçlanandan FARKLI bir yapıya parse edilebilir (bir seviye fazla içeri girintilenmiş bir alan görmezden gelinir); bu yüzden her gerçek apply'dan önce `kubectl apply --dry-run=client` çalıştırmak güzel bir ekstra değil, vazgeçilmez bir alışkanlıktır.

YAML Yapısı — Her K8s Nesnesi 4 Kök Alana Sahiptir

Her K8s YAML'ında 4 zorunlu alan

Micro Lab: Kubernetes YAML manifest repair

TODO satirini beklenen cozumdeki kritik satirla degistir. Bu gercek runtime degil; amac dogru yapinin yazilmasini kontrollu olarak pekistirmek.

4 Zorunlu Alandan Biri Eksikse kubectl apply Neden Anında Reddeder?

apiVersion şema versiyonunu seçer

API Server bu alana bakarak nesneyi HANGİ API versiyonuna göre doğrulayacağını belirler.

kind hangi controller'ı belirler

"Deployment" mi "Service" mi yazdığın, isteğin HANGİ controller'a yönlendirileceğini belirler.

metadata.name gerçek kimliktir

Bu isim, namespace İÇİNDE benzersiz olmalıdır — objenin cluster'daki tek gerçek kimliği budur.

spec YALNIZCA nesneye özgü kısımdır

İlk 3 alan her nesnede aynı şablonu izler; spec içeriği ise Pod ile Service arasında TAMAMEN farklıdır.