anilozgok/pod genel bakis (#62)

* Update init-container.md

* feat: skeleton template created and content added

* forgot to stage unstaged files ffs

* feat: translate content to turkish

---------

Co-authored-by: Anıl Özgök <anil.ozgok@trendyol.com>

Author: anilozgok

docs/_sidebar.md

@@ -40,12 +40,11 @@
     * [ReplicaSets](replicasets.md)
 
 * Pod Genel Bakış
-    * **Pod Yaşam Döngüsü**
-        * [Container Statüleri](container-faz.md)
+    * [Pod Yaşam Döngüsü](pod-yasam-dongu.md)
         * [Pod Durumları](pod-durum.md)
+        * [Container Statüleri](container-faz.md)
         * [Init Container](init-container.md)
-    * [Pod Preset](pod-preset.md)
-    * [Static Pod](static-pod.md)
+    * [Sidecar Container](sidecar-container.md)
     * [Ephemeral Container](ephemeral-container.md)
 * **Podların Çalışacağı Nodeları Belirleme - Scheduling**
     * [NodeSelector Alanı](nodeselector.md)

docs/container-faz.md

@@ -0,0 +1,11 @@
+# Container Statüleri
+
+Kubernetes Pod'un içerisindeki her container'ın statüsünü takip eder. Scheduler oluşturlacak Pod'u bir Node'a atasığı zaman Kubelet Pod içerisindeki containerları, container runtime kullanarak oluşturmaya başlar. Bır container'ın olası 3 statüsü vardır ve her statünün kendine özel anlamları vardır.
+
+- **Waiting:** Eğer container Running ve ya Terminated statüsünde değilse bu statüdedir. Bu statüde bulunan bir container, başlamayı tamamlamak için ihtiyaç duyduğu işlemleri hala yürütüyor olabilir: örneğin, registry'den container image'ini çekmek ya da secretları dosya sistemine yazmak. Bir container'ın neden bu statüde olduğunu öğrenmek için <kubectl> kullanarak Pod'a sorgu atabiliriz. 
+
+- **Running:** Eğer container Running statüsünde ise herhangi bir sorun olmadan ayağa kalkmış ve çalışıyor demektir. <kubectl> ile Pod'a sorgu atarak container'ın ne zaman Running statüsüne girdiği öğrenilebilir.
+
+- **Terminated:** Eğer container Termintaed statüsünde ise bir problemden kaynaklı container ayağa kalkıp çalışamadı ve bu statüye düştü demektir. <kubectl> ile Pod'a sorgu atarak Terminated olan container hakkında hata sebebi, hata kodu, başlangıç ve bitiş saatleri hakkında bilgiler öğrenilebilir.
+
+Bir Pod'un container'larının statüleri hakkında detaylı bilgiye ulaşmak için kubectl describe <name-of-pod> komutunu çalıştırılabilir. Bu komut Pod içerisindeki her container'ın statüleri hakkında detaylı bir çıktı verir.

docs/ephemeral-container.md

@@ -0,0 +1,26 @@
+# Ephemeral Container
+
+## Ephemeral Container'ları Anlamak
+Pod'lar, Kubernetes uygulamalarının temel yapı taşıdır. Pod'lar geçici ve değiştirilebilir olarak tasarlandığından, bir Pod oluşturulduktan sonra ona bir container ekleyemezsiniz. Bunun yerine, genellikle Pod'ları kontrollü bir şekilde siler ve değiştirirsiniz.
+
+Ancak bazen mevcut bir Pod'un durumunu incelemek gerekebilir, örneğin, tekrarlanması zor bir hatayı gidermek için. Bu durumlarda, mevcut bir Pod'da geçici bir container çalıştırarak durumunu inceleyebilir ve rastgele komutlar çalıştırabilirsiniz.
+
+## Ephemeral Container Nedir?
+Ephemeral container'lar, kaynaklar veya yürütme için garantiler içermediklerinden ve asla otomatik olarak yeniden başlatılmayacaklarından diğer container'lardan farklıdır, bu nedenle uygulama oluşturmak için uygun değillerdir. Ephemeral container'lar, normal container'larla aynı ContainerSpec kullanılarak tanımlanır, ancak birçok alan uyumsuzdur ve ephemeral container'lar için izin verilmez.
+
+- Ephemeral container'lar portlara sahip olamaz, bu nedenle ports, livenessProbe, readinessProbe gibi alanlara izin verilmez.
+- Pod kaynak tahsisleri değiştirilemez olduğundan, kaynak ayarlamak izin verilmez.
+- İzin verilen alanların tam listesi için EphemeralContainer referans dökümantasyonuna bakın.
+- Ephemeral container'lar, API'deki özel ephemeralcontainers işleyicisi kullanılarak oluşturulur, bu nedenle doğrudan pod.spec'e eklenerek eklenmeleri mümkün değildir, bu yüzden kubectl edit kullanarak ephemeral container eklemek mümkün değildir.
+
+Normal container'lar gibi, bir Pod'a ekledikten sonra ephemeral container'ı değiştiremez veya kaldıramazsınız.
+
+Not:
+Ephemeral container'lar statik pod'lar tarafından desteklenmez.
+
+## Ephemeral Container Kullanım Alanları
+Ephemeral container'lar, bir container çöktüğünde veya bir container görüntüsü hata ayıklama araçları içermediğinde kubectl exec yetersiz olduğunda etkileşimli hata ayıklama için kullanışlıdır.
+
+Özellikle, distroless görüntüler, saldırı yüzeyini ve hata ve güvenlik açıklarına maruz kalmayı azaltan minimal container görüntüleri dağıtmanıza olanak tanır. Distroless görüntüler bir kabuk veya herhangi bir hata ayıklama aracı içermediğinden, distroless görüntüleri yalnızca kubectl exec kullanarak hata ayıklamak zordur.
+
+Ephemeral container'ları kullanırken, diğer container'lardaki işlemleri görebilmeniz için işlem ad alanı paylaşımını etkinleştirmek faydalıdır.

docs/init-container.md

@@ -1,6 +1,6 @@
 # Init Container nedir?
 
-InitContainer; pod içerisinde bulunan, containerlar ile aynı tipte fakat containerlar başlamadan önce çalışan bir yapıdır.
+InitContainer'lar uygulamanın ana container'ı ayağa kalkmadan önce çalışan, pod içerisinde bulunan, containerlar ile aynı tipte fakat ana containerlar başlamadan önce çalışan özelleştirilmiş öncül containerlardır. InitContainer kullanımına örnek olarak uygulamanın ayağa kalkması için gereken config ve secretlerı Pod'un dosya sistemine yazmamıza yardımcı olacak bir uygulama ya da bazı kurulum scriptleri barındıran bir uygulama olarak düşünebiliriz. 
 
 Bir pod içerisinde birden fazla container olabildiği gibi birden fazla initContainer da olabilir. Pod içerisinde 'initContainers' fieldında dizi olarak tanımlanırlar.
 
@@ -9,7 +9,7 @@ InitContainerlar sıralı olarak çalışırlar. InitContainer içerisindeki pro
 Eğer bir initContainer başarılı olmazsa pod yeniden başlatılır. Pod'un restartPolicy'si 'Never' ise pod 'Failed' statüsüne geçer.
 
 ## InitContainer ve Container farkları nelerdir?
-- InitContainerlarda lifecycle, livenessProbe, readinessProbe ve startupProbe desteği bulunmamaktadır çünkü podun sağlıklı bir şekilde çalışıyor olması için initContainerların çalışıp başarılı bir şekilde tamamlanmış olmaları gereklidir.
-- Pod içerisinde birden fazla initContainer varsa bunlar sıralı olarak çalışırlar. Bütün initContainerlar başarılı bir şekilde çalışıp tamamlandıktan sonra Containerlar aynı anda çalışmaya başlarlar.
+- InitContainer'larda lifecycle, livenessProbe, readinessProbe ve startupProbe desteği bulunmamaktadır çünkü podun sağlıklı bir şekilde çalışıyor olması için initContainer'ların çalışıp başarılı bir şekilde tamamlanmış olmaları gereklidir.
+- Pod içerisinde birden fazla initContainer varsa bunlar sıralı olarak çalışırlar. Bütün initContainer'lar başarılı bir şekilde çalışıp tamamlandıktan sonra Containerlar aynı anda çalışmaya başlarlar.
 
-InitContainerlar genellikle diğer containerlar çalışmaya başlamadan önce pod içerisinde yapılması gereken işleri yapmak veya uygulama containerının başlamasını bekletmek gibi ihtiyaçları karşılamak için kullanılabilirler.
+InitContainer'lar genellikle diğer containerlar çalışmaya başlamadan önce pod içerisinde yapılması gereken işleri yapmak veya uygulama containerının başlamasını bekletmek gibi ihtiyaçları karşılamak için kullanılabilirler.

docs/pod-durum.md

@@ -0,0 +1,22 @@
+# Pod Durumlari
+
+Bir Pod'un durum alanı, bir phase alanına sahip olan bir PodStatus nesnesidir.
+
+Bir Pod'un phase'i, Pod'un yaşam döngüsünde nerede olduğunun basit ve yüksek düzeyde bir özetidir. Phase, container veya Pod durumunun kapsamlı bir gözlemi veya kapsamlı bir durum makinesi olması amaçlanmamıştır.
+
+Pod phase değerlerinin sayısı ve anlamları sıkı bir şekilde korunur. Burada belgelenenler dışında, belirli bir phase değerine sahip Pod'lar hakkında hiçbir varsayımda bulunulmamalıdır.
+
+Phase için olası değerler şunlardır:
+
+| Değer      | Açıklama |
+|------------|----------|
+| Pending    | Pod, Kubernetes cluster'ı tarafından kabul edilmiştir, ancak bir veya daha fazla container kurulmamış ve çalışmaya hazır hale getirilmemiştir. Bu, bir Pod'un zamanlanmayı beklerken geçirdiği zamanı ve ağ üzerinden container görüntülerini indirirken geçirdiği zamanı içerir. |
+| Running    | Pod bir node'a bağlanmış ve tüm containerlar oluşturulmuştur. En az bir container hala çalışıyor veya başlatılıyor ya da yeniden başlatılıyor. |
+| Succeeded  | Pod'daki tüm containerlar başarıyla sonlanmış ve yeniden başlatılmayacaktır. |
+| Failed     | Pod'daki tüm containerlar sonlanmış ve en az bir container başarısızlıkla sonlanmıştır. Yani, container sıfır olmayan bir durum kodu ile çıkmış veya sistem tarafından sonlandırılmış ve otomatik olarak yeniden başlatılmak üzere ayarlanmamıştır. |
+| Unknown    | Bir nedenle Pod'un durumu elde edilememiştir. Bu phase tipik olarak Pod'un çalışması gereken node ile iletişimde bir hata olduğunda ortaya çıkar. |
+
+Not:
+Bir Pod silinirken, bazı kubectl komutları tarafından Terminating olarak gösterilir. Bu Terminating durumu, Pod phase'lerinden biri değildir. Bir Pod'a, gracefully bir şekilde terminate edilmesi için bir süre verilir ve bu varsayılan olarak 30 saniyedir. Bir Pod'u zorla sonlandırmak için --force bayrağını kullanabilirsiniz. Kubernetes 1.27'den beri, kubelet, statik Pod'lar ve finalizer olmadan zorla silinen Pod'lar hariç, silinmiş Pod'ları API sunucusundan silinmeden önce bir terminal phase'e (Pod containerlarının çıkış durumlarına bağlı olarak Failed veya Succeeded) geçirir.
+
+Bir node ölürse veya cluster'dan düşerse, Kubernetes, kaybolan node'daki tüm Pod'ların phase'ini Failed olarak ayarlamak için bir politika uygular.

docs/pod-yasam-dongu.md

@@ -0,0 +1,30 @@
+# Pod Yaşam Döngüsü
+
+Podlar belirli bir yaşam döngüsünü takip eder, bu döngü Pending aşamasıyla başlar ve containerlardan biri çalışı durumunda ise Running aşamasına doğru ilerler. Daha sonrasında Pod'da bulunan bır containerın fail olup terminate olup olmama durumuna bağlı olarak Failed ya da Succeeded aşamasına geçer.
+
+Bireysel uygulama containerları gibi, Pod'lar da nispeten geçici (kalıcı olmaktan ziyade) varlıklar olarak kabul edilir. Pod'lar oluşturulur, benzersiz bir kimlik (UID) atanır ve Node'larda çalışmak üzere zamanlanır; burada sonlandırılana (yeniden başlatma politikasına göre) veya silinene kadar kalırlar. Bir Node ölürse, o Node üzerinde çalışan (veya çalışmak üzere zamanlanmış) Pod'lar silinmek üzere işaretlenir. Kontrol düzlemi, bir zaman aşımı süresinden sonra Pod'ları kaldırmak üzere işaretler.
+
+## Pod lifetime
+
+Bir Pod çalışırken, kubelet bazı türdeki hataları ele almak için konteynerleri yeniden başlatabilir. Bir Pod içinde, Kubernetes farklı container durumlarını izler ve Pod'u tekrar sağlıklı hale getirmek için ne tür bir eylem yapması gerektiğine karar verir.
+
+Kubernetes API'sinde, Pod'ların hem bir spesifikasyonu hem de gerçek bir durumu vardır. Bir Pod nesnesinin durumu, bir dizi Pod koşulundan oluşur. Ayrıca, uygulamanız için yararlıysa, bir Pod'un durum verilerine özel hazır olma bilgilerini ekleyebilirsiniz (readiness probes).
+
+Pod'lar yaşamları boyunca yalnızca bir kez zamanlanır; bir Pod'u belirli bir node'a atamaya binding denir ve hangi node'un kullanılacağını seçme sürecine scheduling denir. Bir Pod zamanlandığında ve bir node'a bağlandığında, Kubernetes o Pod'u node'da çalıştırmaya çalışır. Pod, durana kadar veya Pod sonlandırılana kadar o node'da çalışır; Kubernetes seçilen node'da Pod'u başlatamazsa (örneğin, node Pod başlamadan önce çökerse), o belirli Pod asla başlamaz.
+
+Pod Scheduling Readiness'i kullanarak bir Pod'un zamanlanmasını, tüm scheduling gates kaldırılana kadar erteleyebilirsiniz. Örneğin, bir dizi Pod tanımlamak isteyebilir ancak tüm Pod'lar oluşturulduğunda zamanlamayı tetiklemek isteyebilirsiniz.
+
+
+## Pods and fault recovery
+
+Pod içindeki container'lardan biri başarısız olursa, Kubernetes belirli bir containerı yeniden başlatmayı deneyebilir. 
+
+Ancak, Pod'lar cluster'ın geri kazanamayacağı bir şekilde fail olabilir ve bu durumda Kubernetes Pod'u daha fazla iyileştirmeye çalışmaz; bunun yerine, Kubernetes Pod'u siler ve otomatik iyileştirme sağlamak için diğer bileşenlere güvenir.
+
+Bir Pod bir node'a zamanlanmışsa ve o node daha sonra fail olursa, Pod sağlıksız olarak kabul edilir ve Kubernetes sonunda Pod'u siler. Bir Pod, kaynak yetersizliği veya Node bakımından dolayı tahliyeden sağ çıkamaz.
+
+Kubernetes, nispeten geçici Pod örneklerini yönetme işini üstlenen bir controller adlı daha yüksek düzeyde bir soyutlama kullanır.
+
+Belirli bir Pod (UID ile tanımlanmış) asla farklı bir node'a "yeniden zamanlanmaz"; bunun yerine, o Pod yeni, neredeyse aynı bir Pod ile değiştirilebilir. Bir yedek Pod oluşturursanız, eski Pod'un sahip olduğu aynı adı (.metadata.name) bile kullanabilir, ancak yedek Pod eski Pod'dan farklı bir .metadata.uid'ye sahip olur.
+
+Kubernetes, mevcut bir Pod için bir yedeğin, değiştirilen eski Pod ile aynı node'a zamanlanacağını garanti etmez.

docs/sidecar-container.md

@@ -0,0 +1,43 @@
+# Sidecar Container
+
+Sidecar container'ları, aynı Pod içinde ana uygulama container'ı ile birlikte çalışan ikincil container'lardır. Bu container'lar, ana uygulama container'ının işlevselliğini genişletmek veya artırmak için ek hizmetler veya işlevler (örneğin, günlük kaydı, izleme, güvenlik veya veri senkronizasyonu) sağlar, ana uygulama kodunu doğrudan değiştirmeden.
+
+Genellikle, bir Pod'da sadece bir uygulama container'ı bulunur. Örneğin, yerel bir web sunucusu gerektiren bir web uygulamanız varsa, yerel web sunucusu bir sidecar olarak kabul edilir ve web uygulamasının kendisi uygulama container'ıdır.
+
+## Kubernetes'te Sidecar Container'ları
+
+Kubernetes, sidecar container'larını, init container'larının özel bir durumu olarak uygular; sidecar container'ları, Pod başlatıldıktan sonra çalışmaya devam eder. Bu belgede, yalnızca Pod başlatma sırasında çalışan container'ları açıkça belirtmek için düzenli init container'ları terimi kullanılır.
+
+Kümenizde SidecarContainers özelliği etkinleştirilmişse (bu özellik Kubernetes v1.29'dan itibaren varsayılan olarak etkindir), bir Pod'un initContainers alanında listelenen container'lar için bir restartPolicy belirleyebilirsiniz. Bu yeniden başlatılabilir sidecar container'ları, aynı pod içindeki diğer init container'larından ve ana uygulama container'larından bağımsızdır. Bu container'lar, ana uygulama container'ını ve diğer init container'larını etkilemeden başlatılabilir, durdurulabilir veya yeniden başlatılabilir.
+
+Ayrıca, init veya sidecar container'ları olarak işaretlenmemiş birden fazla container ile bir Pod çalıştırabilirsiniz. Bu, Pod içindeki container'ların Pod'un genel olarak çalışması için gerekli olduğu, ancak hangi container'ların önce başlatılıp durdurulması gerektiğini kontrol etmenize gerek olmadığı durumlarda uygundur. Bu, container düzeyinde restartPolicy alanını desteklemeyen daha eski Kubernetes sürümlerini desteklemeniz gerektiğinde de yapılabilir.
+
+## Uygulama Container'larından Farkları
+
+Sidecar container'ları, aynı pod içindeki uygulama container'larının yanında çalışır. Ancak, ana uygulama mantığını yürütmezler; bunun yerine ana uygulamaya destekleyici işlevler sağlarlar.
+
+Sidecar container'larının kendi bağımsız yaşam döngüleri vardır. Uygulama container'larından bağımsız olarak başlatılabilir, durdurulabilir ve yeniden başlatılabilirler. Bu, sidecar container'larını güncelleyebileceğiniz, ölçeklendirebileceğiniz veya bakımını yapabileceğiniz anlamına gelir, bu da ana uygulamayı etkilemez.
+
+Sidecar container'ları, ana container ile aynı ağ ve depolama ad alanlarını paylaşır. Bu birlikte yerleştirme, onların yakın etkileşimde bulunmasına ve kaynakları paylaşmasına olanak tanır.
+
+## Init Container'larından Farkları
+
+Sidecar container'ları, ana container ile birlikte çalışarak işlevselliğini genişletir ve ek hizmetler sağlar.
+
+Sidecar container'ları, ana uygulama container'ı ile eşzamanlı olarak çalışır. Pod'un yaşam döngüsü boyunca aktiftirler ve ana container'dan bağımsız olarak başlatılabilir ve durdurulabilirler. Init container'larının aksine, sidecar container'ları yaşam döngülerini kontrol etmek için probları destekler.
+
+Sidecar container'ları, ana uygulama container'ları ile doğrudan etkileşime geçebilir, çünkü init container'ları gibi her zaman aynı ağı paylaşırlar ve isteğe bağlı olarak aynı hacimleri (dosya sistemlerini) de paylaşabilirler.
+
+Init container'ları, ana container'lar başlamadan önce durur, bu nedenle init container'ları bir Pod'daki uygulama container'ı ile mesaj alışverişinde bulunamaz. Herhangi bir veri aktarımı tek yönlüdür (örneğin, bir init container'ı boş bir emptyDir hacmine bilgi koyabilir).
+
+## Container'lar Arasında Kaynak Paylaşımı
+
+Init, sidecar ve uygulama container'larının yürütme sırası göz önüne alındığında, kaynak kullanımı için aşağıdaki kurallar geçerlidir:
+
+- Tüm init container'larında tanımlanan belirli bir kaynak isteği veya limitinin en yükseği, etkili init isteği/limiti olarak kabul edilir. Herhangi bir kaynak için limit belirtilmemişse, bu en yüksek limit olarak kabul edilir.
+- Pod'un bir kaynak için etkili isteği/limiti, pod overhead'in ve aşağıdakilerin toplamıdır:
+  - Tüm non-init container'larının (uygulama ve sidecar container'ları) bir kaynak için isteği/limitinin toplamı
+  - Bir kaynak için etkili init isteği/limiti
+- Zamanlama, etkili isteklere/limitlere göre yapılır, bu da init container'larının Pod'un yaşam süresi boyunca kullanılmayan kaynakları ayırabileceği anlamına gelir.
+- Pod'un QoS (hizmet kalitesi) seviyesi, tüm init, sidecar ve uygulama container'ları için geçerli olan QoS seviyesiyle aynıdır.
+- Kota ve limitler, etkili Pod isteği ve limitine göre uygulanır.