├── Ag_Kurallari
└── README.md
├── README.md
├── ReplicaSet
├── README.md
└── uygulama1.yaml
├── annotation
└── Readme.md
├── component
└── Readme.md
├── daemonset
└── Readme.md
├── deployment
└── Readme.md
├── environment-variables
└── Readme.md
├── label
└── Readme.md
├── liveness-probe
└── Readme.md
├── minikube
└── Readme.md
├── namespace
└── Readme.md
├── node-affinity
└── Readme.md
├── persistent-volume
└── Readme.md
├── pod-affinity
└── Readme.md
├── pod
└── Readme.md
├── readiness-probe
└── Readme.md
├── resource-limits
└── Readme.md
├── rollout-ve-rollback
├── README.md
├── uygulama1.yaml
├── uygulama2.yaml
└── uygulama3.yaml
├── service
└── Readme.md
├── statefulset
└── Readme.md
├── storage-class
└── Readme.md
├── taint-ve-tolerations
└── Readme.md
└── volume
└── Readme.md
/Ag_Kurallari/README.md:
--------------------------------------------------------------------------------
1 | # Ağ Kuralları
2 |
3 | ## Ağ Kuralları Nedir?
4 |
5 | Kubernetes ağ kuralları, Kubernetes kümesindeki pod'ların hangi ağ kaynaklarına erişebileceğini kontrol etmek için kullanılır. Ağ kuralları, pod'lar arasındaki ağ trafiğini kontrol etmek, pod'ların dış dünya ile iletişim kurmasını sağlamak ve kümedeki kaynakların güvenliğini sağlamak için kullanılabilir.
6 |
7 | Kubernetes ağ kuralları aşağıdaki şekillerde tanımlanabilir:
8 |
9 | - **Pod seviyesinde:** Pod'a doğrudan erişimi kontrol etmek için pod özelliklerini kullanarak ağ kısıtlamaları tanımlanabilir.
10 | - **Namespace seviyesinde:** Namespace seviyesinde ağ politikaları oluşturularak tüm pod'ların ağ trafiğini kontrol etmek mümkündür.
11 |
12 | - **Küme seviyesinde:** Tüm pod'ların ağ trafiğini kontrol etmek için küme seviyesinde ağ politikaları oluşturulabilir.
13 |
14 | Ağ kısıtlamaları, ağ politikaları aracılığıyla uygulanabilir. Ağ politikaları, belirli bir pod veya pod seti tarafından üretilen trafiği kontrol etmek için kullanılan bir Kubernetes öğesidir. Ağ politikaları, gelen ve/veya giden trafiği filtrelemek ve düzenlemek için belirli kriterlerle tanımlanabilir.
15 |
16 | Örneğin, bir ağ politikası, belirli bir etikete sahip pod'ların sadece belirli bir başka etikete sahip pod'larla iletişim kurmasına izin verebilir. Bu, pod'lar arasındaki trafiği sınırlandırarak ağ güvenliğini artırabilir.
17 |
18 |
19 |
20 | ## Senaryolar
21 |
22 | Konun daha iyi anlaşılması için aşağıdaki yapı üzerinden 3 farklı senaryo oluşturacağız.
23 |
24 | 
25 |
26 | - **pod(sarı):** Kubernetes içindeki en küçük ve en temel uygulama öğesi olan, bir veya birden fazla konteynırdan oluşan ve aynı ağ ve depolama kaynaklarını paylaşan uygulama gruplarıdır.
27 | - **Router:** cluster içerisindeki pod'lara gelen ağ trafiğini doğru pod'a yönlendirmek için kullanılan bir bileşendir.
28 | - **Virtual Bridge (mavi):** Ağdaki sanal makinelerin birbirleriyle iletişim kurabilmesi ve ağ trafiğini yönetebilmek için kullanılan bir sanal ağ bileşenidir.
29 | - **--pord-network-cidr:** Kubernetes cluster'ında Podlar için kullanılacak olan IP adreslerini belirlemek için kullanılır. Bu CIDR notasyonu, Podların IP adreslerinin atanacağı ağ adres aralığını tanımlar.
30 | - **NAT (natlanmak):** Ağ bağlantısı yapılandırması sırasında kullanılan bir terimdir. "NAT" (Network Address Translation) olarak kısaltılan "Ağ Adresi Çevirisi", bir ağ üzerindeki bir bilgisayarın veya cihazın, diğer bir ağa erişmesini sağlar. NAT, özel IP adreslerini internete yönelik genel IP adresleriyle değiştirir ve bu sayede özel ağdaki cihazlar internete bağlanabilir. "Natlanmak" terimi, NAT kullanılarak bir ağdaki cihazların internete erişimini ifade eder.
31 |
32 |
33 |
34 | ### Senaryo - 1
35 |
36 | 
37 |
38 | **Senorya 1 için:** Burada podA'nın dış dünyada bulunan bir sunucu ile iletişimi hedefleniyor.
39 |
40 | Bu durumda podA iletişim paketlerini virtual bridge'e teslim edecek, paket buradan worker node'un eth0 interface'ine ulaşıp natlanacak. Daha sonra paket en son olarak Router'a ulaşıp burada da natlandıktan sonra 1.1.1.1 sunucu ile iletişim sağlanacak. Bu sunucudan geri gelen pakette aynı şekilde natlanıp podA'a ulaşacak. Bu senaryoda bir problem yok.
41 |
42 | > eth0 => Ethernet ağ teknolojisi üzerinden ağ bağlantısı sağlar ve ağa bağlı cihazlarla iletişim kurmak için kullanılır.
43 |
44 |
45 |
46 | ### Senaryo - 2
47 |
48 | 
49 |
50 | **Senaryo 2 için:** Burada podA aynı worker-1 içerisinde bulunan podB ile iletişime geçmesi hedefleniyor.
51 |
52 | podA paketi virtual bridge'e teslim edecek. Virtual Bridge podA'dan gelen paketi sorunsuz bir şekilde podB'e iletecek. podB'den gelen cevapta aynı şekilde; podB cevabı virtual bridge'e iletecek, bridge gelen cevap paketini podA'a iletecek. Bu senaryoda da sıkıntı yok.
53 |
54 |
55 |
56 | ### Senaryo - 3
57 |
58 | 
59 |
60 | Senaryo 3 için: worker-1'de bulunan PodA, worker-2'de bulunan PodC ile iletişime geçmesi hedefleniyor.
61 |
62 | > Podlar birbiri ile NAT'a ihtiyaç duymadan iletişim kurabilmeliydi. Senaryo2'de bunu kanıtladık. Fakat burada, podA'nın Virtual Bridge'e ilettiği paket podC ile aynı worker üzerinde olmadığı için NAT'sız bir iletişim nasıl söz konusu olabiliyor?
63 |
64 | Burada bunu çözecek birkaç düzenlemede olsa bunlar her cluster yapısı için düzgün çalışmayacaktır. Farklı clusterlar arası iletişimde kullanılabilecek Kubernetes içerisinde olan "Container Network Interface (CLI)" bu sorunu çözebilecek en uygun yapıdır.
65 |
66 | CNI, Kubernetes'te kullanılan bir arayüzdür ve ağların podlar arasında iletişim kurmasını sağlar. Podlar arasındaki iletişim, CNI tarafından kurulan ağ arabirimleri sayesinde gerçekleştirilir.
67 |
68 | CNI kullanarak podA ve podC arasında iletişim kurmak için şu adımlar takip edilebilir:
69 |
70 | - **CNI eklentisi kurulur:** Öncelikle, Kubernetes cluster'ında CNI eklentisi yüklenmelidir.
71 | - **Ağ yapılandırması oluşturulur:** Ardından, podA ve podC'nin ağ yapılandırmaları oluşturulmalıdır. Bunun için, CNI tarafından sağlanan konfigürasyon dosyası kullanılabilir.
72 | - **Podlar oluşturulur:** Son olarak, podA ve podC oluşturulmalıdır. Bu podlar, CNI tarafından oluşturulan ağ yapılandırmaları üzerinde çalışacaklardır.
73 |
74 | Böylece podA ve podC arasındaki iletişim, CNI tarafından sağlanan ağ arabirimleri sayesinde gerçekleştirilebilir.
75 |
76 |
77 |
78 | ### Çözüm
79 |
80 | CNI, Kubernetes üzerinde network pluginleri kullanarak network bağlantısını yapılandırır. Podlar arasındaki iletişimi sağlamak için kullanılan CNI pluginlerinden biri olan Multus ile birden fazla ağ arabirimi tanımlanabilir ve podlar bu arabirimler aracılığıyla iletişim kurabilir.
81 |
82 | Multus, Kubernetes CNI arabirimini kullanan bir ağ pluginidir. Multus'un konfigürasyon dosyası Multus CNI CRD (Custom Resource Definition) olarak tanımlanır ve Kubernetes API'sinde saklanır. Örnek bir Multus CNI konfigürasyon dosyası şöyle görünebilir:
83 |
84 | ```yaml
85 | apiVersion: 'k8s.cni.cncf.io/v1'
86 | kind: NetworkAttachmentDefinition
87 | metadata:
88 | name: example-multus-network
89 | annotations:
90 | k8s.v1.cni.cncf.io/resourceName: my-net
91 | spec:
92 | config: '{
93 | "cniVersion": "0.3.1",
94 | "type": "bridge",
95 | "bridge": "mybridge",
96 | "ipam": {
97 | "type": "host-local",
98 | "subnet": "192.168.0.0/16",
99 | "routes": [
100 | { "dst": "0.0.0.0/0" }
101 | ]
102 | }
103 | }'
104 | ```
105 |
--------------------------------------------------------------------------------
/ReplicaSet/README.md:
--------------------------------------------------------------------------------
1 | # ReplicaSet
2 |
3 | ## ReplicaSet Nedir?
4 |
5 | ReplicaSet, Kubernetes'te çalışan bir grup Pod'un belirtilen sayıda çalışmasını sağlamak için kullanılan bir Kubernetes kaynağıdır. ReplicaSet, Pod'ların sağlıklı bir şekilde çalışmasını sağlamak için Pod'ların gereksinimlerini tanımlayan bir şart tanımlar.
6 |
7 |
8 | ## Görevleri Nelerdir?
9 |
10 | - **Belirtilen sayıda kopya oluşturmak:** ReplicaSet, özellikle yüksek kullanılabilirlik gerektiren uygulamalar için kullanılır. Belirtilen sayıda pod oluşturarak uygulamaların yüksek kullanılabilirliğini sağlar.
11 | - **Pod'ların düzgün çalıştığından emin olmak:** ReplicaSet, belirtilen sayıda kopya oluşturarak, pod'ların her zaman düzgün çalıştığından emin olur. Bu sayede, pod'larda oluşabilecek hatalar veya arızalar durumunda, ReplicaSet yeni bir pod oluşturarak uygulamanın düzgün çalışmasını sağlar.
12 | - **Otomatik ölçeklendirme:** ReplicaSet, uygulama trafiğindeki artışları algılayarak, otomatik olarak yeni pod'lar oluşturarak uygulamaların ölçeklendirilmesini sağlar. Böylece, uygulama trafiğindeki artışlar sonucu oluşabilecek performans sorunları önlenir.
13 | - **Pod'ların dağıtımını yönetmek:** ReplicaSet, pod'ların dağıtımını yöneterek, birden fazla node'da çalışan pod'ların belirtilen sayıda kopya oluşturulmasını sağlar. Bu sayede, uygulamaların yüksek kullanılabilirliği artar ve performans sorunları önlenir.
14 | - **Update'leri yönetmek:** ReplicaSet, uygulamaların yeni sürümlerinin yayınlanması durumunda, yeni sürümü pod'lara yükleyerek, update işlemlerini yönetir. Bu sayede, uygulama sürümlerinin yönetimi kolaylaşır ve uygulama güncellemeleri daha hızlı bir şekilde yapılabilir.
15 |
16 |
17 | ## Uygulama
18 |
19 | ```yaml
20 | apiVersion: apps/v1
21 | kind: ReplicaSet
22 | metadata:
23 | name: my-replicaset
24 | spec:
25 | replicas: 3
26 | selector:
27 | matchLabels:
28 | app: my-app
29 | template:
30 | metadata:
31 | labels:
32 | app: my-app
33 | spec:
34 | containers:
35 | - name: my-container
36 | image: nginx
37 | ```
38 |
39 | Bu YAML dosyasında, bir ReplicaSet kaynağı tanımlanıyor. metadata kısmı, ReplicaSet'in ismini içerir. spec kısmı, replikaların sayısını belirler ve hangi pod'ların ReplicaSet'e ait olduğunu belirlemek için bir selector tanımlar.
40 |
41 | Ayrıca, ReplicaSet altındaki tüm pod'lar için bir şablon (template) belirler.
42 |
43 | Şablon kısmında, pod'ların özelliklerini belirleyen bir spec tanımlanır. Bu örnekte, tek bir container'ı olan nginx imajı kullanılmıştır. ReplicaSet'in 3 adet replika ile çalışacağı belirtilmiştir. Bu, ReplicaSet'in her zaman 3 replikaya sahip olacağı anlamına gelir.
44 |
45 | Bu örnek dosyayı kullanarak, kubectl ile ReplicaSet'i Kubernetes kümenize uygulayabilirsiniz:
46 |
47 | ```shell
48 | kubectl apply -f my-replicaset.yaml
49 | ```
50 |
51 | ReplicaSet'i scale etmek için kubectl scale komutu kullanılır. Örneğin, ReplicaSet'inizi üç replica olarak oluşturduysanız, aşağıdaki komutu kullanarak 5 replica'ya scale edebilirsiniz:
52 |
53 | ```shell
54 | kubectl scale rs my-replicaset --replicas=5
55 | ```
56 |
57 | Bu komut, my-replicaset adlı ReplicaSet'in replica sayısını 5'e ayarlar. Eğer ReplicaSet'inizi daha önce isimlendirmediyseniz, kubectl get rs komutu ile ismini öğrenebilirsiniz.
58 |
59 | Yeni replica'lar, ReplicaSet tarafından belirtilen pod template'ine göre oluşturulur ve Kubernetes cluster'ınızın kaynaklarına göre dağıtılır.
60 |
61 | Eğer yapılan değişiklikeri geri almak isterseniz rollout undo komutunu kullanarak ReplicaSet ile uygulanan işlemi geri alabilirsiniz:
62 |
63 | ```shell
64 | kubectl rollout undo deployment my-replicaset
65 | ```
66 |
67 | ## Dikkat Edilmesi Gerekenler
68 |
69 | - ReplicaSet, Pod'ları kontrol eder ve bir kopya sayısı belirtilen durumun özelliğine uygun olarak ölçeklendirir.
70 | - ReplicaSet, Pod'ların sürdürülebilirliğini sağlamak için Pod'ların yeniden başlatılmasını otomatik olarak yönetir.
71 | - ReplicaSet, Pod'ların konumunu veya dağılımını kontrol etmez, sadece belirli bir sayıda kopyanın çalıştırılmasını sağlar.
72 | - ReplicaSet, aynı zamanda RollingUpdate gibi güncelleme stratejileriyle de kullanılabilir.
73 | ReplicaSet'in Pod şablonu, Pod oluşturulduğunda kullanılan şablonu tanımlar.
74 | - ReplicaSet, Pod'ları otomatik olarak oluşturur ve yönetir, bu nedenle Pod'ları doğrudan yönetmek yerine ReplicaSet üzerinden yönetmek daha uygun olabilir.
75 |
--------------------------------------------------------------------------------
/ReplicaSet/uygulama1.yaml:
--------------------------------------------------------------------------------
1 | apiVersion: apps/v1
2 | kind: ReplicaSet
3 | metadata:
4 | name: my-replicaset
5 | spec:
6 | replicas: 3
7 | selector:
8 | matchLabels:
9 | app: my-app
10 | template:
11 | metadata:
12 | labels:
13 | app: my-app
14 | spec:
15 | containers:
16 | - name: my-container
17 | image: nginx
18 |
--------------------------------------------------------------------------------
/annotation/Readme.md:
--------------------------------------------------------------------------------
1 | # Annotation
2 |
3 | Annotation'lar, Kubernetes ortamında kaynaklara (örneğin Pod'lar, Servisler, Deployment'lar vb.) ilişkili olmayan metaveriler eklemek için kullanılan key-value (anahtar-değer) çiftleridir. Annotation'lar, Label'lar gibi kaynaklara metaveri eklemek için kullanılır, ancak Label'ların aksine kaynakların gruplandırılması veya seçilmesinde kullanılmazlar. Annotation'lar, kaynaklara ilgili ek bilgileri eklemek için kullanılır ve genellikle açıklama, sürüm numarası, oluşturma tarihi gibi bilgileri içerir.
4 |
5 | ## Annotation'ların Avantajları
6 |
7 | - **Ek Bilgi Saklama**: Annotation'lar, kaynaklarla ilgili ek bilgileri saklamak için kullanılır. Bu, kaynakların anlaşılmasını ve yönetilmesini kolaylaştırır. Örneğin, bir Pod'un neden oluşturulduğu veya ne işe yaradığı gibi açıklamaları Annotation'lar aracılığıyla ekleyebilirsiniz.
8 |
9 | - **Entegrasyon ve İş Akışı**: Annotation'lar, farklı araçlar, hizmetler veya otomasyon iş akışlarıyla entegrasyon sağlamak için kullanılabilir. Örneğin, CI/CD araçları, Annotation'ları okuyarak ve onlara göre işlem yaparak süreçlerinizi otomatikleştirebilir.
10 |
11 | - **Üçüncü Taraf Araçlar ve Uzantılar**: Annotation'lar, Kubernetes ekosistemindeki üçüncü taraf araçlar veya uzantılar tarafından kullanılmak için kullanılabilir. Bu, farklı hizmetleri veya özellikleri etkinleştirmek veya yapılandırmak için kullanılabilir.
12 |
13 | ## Annotation'ların Kullanımı ve Yönetimi
14 |
15 | Annotation'lar, kaynak tanımlama dosyalarında veya Kubernetes API'si aracılığıyla tanımlanır. Annotation'lar, kaynak oluşturulurken veya daha sonra kaynağa eklenebilir. Ayrıca, Annotation'lar güncellenebilir ve silinebilir.
16 |
17 | Kubernetes, Annotation'ları doğrudan kullanmasa da, üçüncü taraf araçlar veya uzantılar tarafından kullanılarak çeşitli işlemler gerçekleştirilebilir. Örneğin, bir izleme aracı, belirli Annotation'lara sahip olan kaynakları izleyebilir veya bir otomasyon aracı, Annotation'ları kullanarak belirli işlemler gerçekleştirebilir.
18 |
--------------------------------------------------------------------------------
/component/Readme.md:
--------------------------------------------------------------------------------
1 | # Component
2 |
3 | Kubernetes, konteyner tabanlı uygulamaları yönetmek ve dağıtmak için popüler bir açık kaynaklı bir konteyner orkestrasyon platformudur. Kubernetes, uygulamaların güvenilir, ölçeklenebilir ve yüksek performanslı bir şekilde çalışmasını sağlamak için bir dizi özellik ve bileşen sunar. Bu bileşenler, Kubernetes'in komponent yapısını oluşturur.
4 |
5 | ## Master Komponentleri
6 |
7 | Kubernetes cluster'ının kontrol düğümünü oluşturan ve cluster üzerindeki tüm kaynakların yönetimini sağlayan komponentlerdir.
8 |
9 | - API Sunucusu (API Server): Kubernetes cluster'ıyla etkileşime geçmek için kullanılan merkezi bir arabirim sağlar. Kullanıcılar ve diğer komponentler, API sunucusu aracılığıyla Kubernetes ile etkileşimde bulunabilir.
10 | - Etcd: Dağıtılmış bir key-value veritabanıdır ve Kubernetes cluster konfigürasyonu, durumu ve diğer meta verileri saklamak için kullanılır.
11 | - Scheduler: Yeni oluşturulan pod'ların uygun nodlara (çalışma birimlerine) dağıtılmasından sorumludur. Scheduler, kaynak talepleri, afinite (node tercihleri) ve başka kısıtlamalar gibi faktörleri dikkate alarak en uygun nodları seçer.
12 | - Kontrol Yöneticisi (Controller Manager): Pod, replica set, deployment gibi Kubernetes kaynaklarının durumunu sürekli olarak izleyen ve istenen duruma getirmek için gerekli eylemleri gerçekleştiren bir komponenttir.
13 | API İzleyici (API Server'in proxy'si): API sunucusu ile etkileşimde bulunmak için kullanılır ve API sunucusuna gelen talepleri dağıtmak için kullanılır.
14 |
15 | ## Node (İşçi) Komponentleri
16 |
17 | Kubernetes cluster'ının çalıştığı ve uygulama konteynerlerinin çalıştığı fiziksel veya sanal makinelerdir.
18 |
19 | - Kubelet: Her bir node üzerinde çalışan ve Kubernetes API'siyle iletişim kuran ana komponenttir. Kubelet, pod'ların çalışmasını sağlamak, sağlık durumunu kontrol etmek, talepleri node'a iletmek ve container'ları yönetmek gibi görevleri yerine getirir.
20 | - Container Runtime: Konteynerleri çalıştırmak için kullanılan yazılımdır. Docker, Containerd, CRI-O gibi farklı konteyner çalışma zamanları Kubernetes tarafından desteklenir.
21 | - Kube-Proxy: Pod'lara ağ erişimi sağlar ve ağ trafiklerini yönlendirir. Kube-Proxy, Service'lerin load balancing özelliğini de sağlar.
22 |
23 | ## Eklenti Komponentleri
24 |
25 | Ek özellikler sunmak veya özelleştirmeler yapmak için kullanılan komponentlerdir.
26 |
27 | - Network Plugin: Kubernetes cluster'ı içinde pod'ların ağa erişimini sağlayan ve ağ politikalarını uygulayan bir eklentidir. Calico, Flannel, Weave
28 | gibi farklı network plugin'leri kullanılabilir.
29 | - Storage Plugin: Pod'lara kalıcı veri depolamak için kullanılan bir eklentidir. Bu plugin'ler, farklı veri depolama sistemlerini Kubernetes'e entegre etmek için kullanılır.
30 |
31 | Bu komponentler, Kubernetes cluster'ının temel yapıtaşlarını oluşturur ve her biri farklı bir görevi yerine getirir. Birlikte çalışarak uygulama konteynerlerinin güvenilir ve ölçeklenebilir bir şekilde dağıtılmasını, yönetilmesini ve izlenmesini sağlarlar.
32 |
33 | Örnek bir senaryoda, kullanıcılar API sunucusuna talepler göndererek bir uygulamanın dağıtılmasını veya ölçeklendirilmesini isteyebilir. API sunucusu bu talepleri alır, etcd üzerindeki konfigürasyonları günceller ve Scheduler, yeni pod'ları uygun nodlara yerleştirir. Kubelet, pod'ları başlatır ve Kube-Proxy, ağ erişimini sağlar. Kontrol Yöneticisi, uygulama kaynaklarını sürekli olarak izler ve istenen duruma getirmek için gerekli eylemleri gerçekleştirir.
34 |
35 | Bu şekilde, Kubernetes komponent yapısı, bir uygulamanın dağıtılması, ölçeklendirilmesi ve yönetilmesi sürecini sağlamak için birlikte çalışan bir dizi bileşeni içerir. Bu yapı, yüksek kullanılabilirlik, ölçeklenebilirlik ve dayanıklılık gibi önemli özellikleri sunar ve konteyner tabanlı uygulamaların etkili bir şekilde yönetilmesine olanak sağlar.
36 |
--------------------------------------------------------------------------------
/daemonset/Readme.md:
--------------------------------------------------------------------------------
1 | # DaemonSet
2 |
3 | DaemonSet, Kubernetes'in bir kaynak türüdür ve uygulamaları veya sistem bileşenlerini bir Kubernetes kümesindeki her bir düğümde çalıştırmak için kullanılır.
4 |
5 | DaemonSet, her bir düğümde bir Pod oluşturur ve bu Pod'lar belirli bir etiketi karşılar. Her düğümde yalnızca bir Pod çalışır ve yeni bir düğüm eklediğinizde otomatik olarak yeni bir Pod oluşturulur. Aynı şekilde, bir düğüm silindiğinde, ilgili Pod da otomatik olarak kaldırılır.
6 |
7 | DaemonSet'ler, sistem düzeyindeki görevler, log toplama araçları, ağ izleme araçları gibi uygulamaları çalıştırmak için idealdir. Örneğin, bir ağ izleme aracını DaemonSet olarak çalıştırarak her düğümde ağ trafiğini izleyebilir ve merkezi bir şekilde analiz edebilirsiniz.
8 |
9 | DaemonSet'lerin bazı özellikleri şunlardır:
10 |
11 | 1. **Güncelleme Kontrolü:** DaemonSet'ler, Pod'ları güncellemek için Rolling Update stratejisini kullanır. Bu, yeni bir DaemonSet oluştururken mevcut Pod'ları yavaş yavaş güncelleyerek uygulamanızın kesintisiz çalışmasını sağlar.
12 |
13 | 2. **Node Tolerasyonu:** DaemonSet'ler, düğümler üzerinde çalışan Pod'ları hedefler ve belirli düğümlerde DaemonSet çalıştırmamak için tolerans (toleration) özelliklerini kullanabilir.
14 |
15 | 3. Güvenlik: DaemonSet'lerin güvenliği, Pod'larda kullanılan konteyner imajlarına ve Pod'ların düğümler üzerinde çalıştığı erişim haklarına dikkat etmek suretiyle sağlanmalıdır.
16 |
17 | DaemonSet'ler, uygulamalarınızı her düğümde çalıştırmak ve sistem düzeyindeki görevleri yerine getirmek için güçlü bir araçtır. Bu sayede, Kubernetes kümenizdeki tüm düğümlerde tutarlı bir ortam sağlayabilir ve ölçeklenebilirlik ve işlevsellik sunabilirsiniz.
18 |
19 | ## Uygulama
20 |
21 | ### Adım 1: YAML Oluşturma
22 |
23 | İlk adımda, DaemonSet'i tanımlayan bir Kaynak Tanım Dosyası (daemonset.yaml) oluşturmanız gerekmektedir. Örnek olarak aşağıdaki YAML dosyasını kullanabilirsiniz:
24 |
25 | ```yaml
26 | apiVersion: apps/v1
27 | kind: DaemonSet
28 | metadata:
29 | name: my-app-daemonset
30 | spec:
31 | selector:
32 | matchLabels:
33 | app: my-app
34 | template:
35 | metadata:
36 | labels:
37 | app: my-app
38 | spec:
39 | containers:
40 | - name: my-app-container
41 | image: my-app-image:latest
42 | ports:
43 | - containerPort: 8080
44 | ```
45 |
46 | Bu YAML dosyası, "my-app-daemonset" adında bir DaemonSet oluşturur. DaemonSet, tüm düğümlerde "my-app" etiketini karşılayan bir Pod oluşturur. Pod'lar için "my-app-container" adında bir konteyner oluşturulur ve bu konteyner, "my-app-image:latest" adlı bir imajı kullanarak 8080 portunda çalışır.
47 |
48 | ### Adım 2: DaemonSet'i Kubernetes Kümelerine Uygulama
49 |
50 | Oluşturduğunuz daemonset.yaml dosyasını kullanarak DaemonSet'i Kubernetes kümelerine uygulayabilirsiniz. Bunun için aşağıdaki komutu kullanabilirsiniz:
51 |
52 | ```shell
53 | kubectl apply -f daemonset.yaml
54 | ```
55 |
56 | Bu komut, daemonset.yaml dosyasını kullanarak DaemonSet'i Kubernetes kümelerine uygular.
57 |
58 | ### Adım 3: DaemonSet Durumunu Kontrol Etme
59 |
60 | DaemonSet'in başarıyla uygulanıp uygulanmadığını kontrol etmek için aşağıdaki komutu kullanabilirsiniz:
61 |
62 | ```shell
63 | kubectl get daemonsets
64 | ```
65 |
66 | Bu komut, mevcut DaemonSet'leri listeler ve bunların durumunu gösterir. "my-app-daemonset" adında bir DaemonSet listelenmeli ve tüm düğümlerde çalışan Pod'larını göstermelidir.
67 |
68 | ### Adım 4: Pod'ların Durumunu Kontrol Etme
69 |
70 | DaemonSet ile oluşturulan Pod'ların durumunu kontrol etmek için aşağıdaki komutu kullanabilirsiniz:
71 |
72 | ```shell
73 | kubectl get pods
74 | ```
75 |
76 | Bu komut, mevcut Pod'ları listeler ve bunların durumunu gösterir. "my-app-daemonset-" ile başlayan adlara sahip Pod'lar listelenmeli ve durumları "Running" olmalıdır.
77 |
--------------------------------------------------------------------------------
/deployment/Readme.md:
--------------------------------------------------------------------------------
1 | # Deployment
2 |
3 | Deployment, Kubernetes'in temel bileşenlerinden biridir ve uygulamalarınızı Kubernetes kümelerinde çalıştırmak için kullanılır. Deployment'lar, uygulama özelliklerinizi, dağıtım stratejilerinizi ve ölçeklendirme seçeneklerinizi tanımlamanıza yardımcı olan bir YAML dosyası kullanılarak oluşturulur.
4 |
5 | Bir Deployment oluşturduğunuzda, Kubernetes, belirli bir uygulama sürümünü çalıştırmak için bir dizi Pod oluşturur ve yönetir. Bir Pod, birden çok konteynerden oluşabilen en küçük çalıştırılabilir birimdir. Deployment, istediğiniz sayıda Pod'un oluşturulmasını sağlar ve aynı zamanda bu Pod'ların sürekli olarak çalışmasını sağlar.
6 |
7 | Deployment'lar ayrıca hata durumlarına karşı otomatik iyileştirme sağlayabilir. Eğer bir Pod başarısız olursa, Deployment bunu algılar ve otomatik olarak yeni bir Pod oluşturarak hizmetin kesintisiz devam etmesini sağlar.
8 |
9 | Bir Deployment ayrıca güncelleme süreçlerini yönetmenize de olanak tanır. Örneğin, uygulamanızın yeni bir sürümünü yayınlamak istediğinizde, Deployment stratejilerini kullanarak güncellemeyi kontrollü bir şekilde gerçekleştirebilirsiniz. Bu stratejiler, yavaş yavaş güncelleme, aynı anda tümünü güncelleme veya sıfır kesintiyle güncelleme gibi farklı yaklaşımları destekler.
10 |
11 | Son olarak, Deployment'lar, ölçeklendirme işlevselliği sağlar. Uygulamanız yoğun trafik altında daha fazla kaynak talep ederse, Deployment onu otomatik olarak ölçeklendirerek yükü dengeleyebilir. Böylece, uygulamanızın performansı ve kullanılabilirliği artar.
12 |
13 | ## Uygulama
14 |
15 | ### Adım 1: Kaynak Tanım Dosyası (deployment.yaml) Oluşturma
16 |
17 | İlk adımda, Deployment'ı tanımlayan bir Kaynak Tanım Dosyası (deployment.yaml) oluşturmanız gerekmektedir. Örnek olarak aşağıdaki YAML dosyasını kullanabilirsiniz:
18 |
19 | ```yaml
20 | apiVersion: apps/v1
21 | kind: Deployment
22 | metadata:
23 | name: my-app-deployment
24 | spec:
25 | replicas: 3
26 | selector:
27 | matchLabels:
28 | app: my-app
29 | template:
30 | metadata:
31 | labels:
32 | app: my-app
33 | spec:
34 | containers:
35 | - name: my-app-container
36 | image: my-app-image:latest
37 | ports:
38 | - containerPort: 8080
39 | ```
40 |
41 | Bu YAML dosyası, "my-app-deployment" adında bir Deployment oluşturur. Bu Deployment, 3 replika Pod oluşturacak şekilde yapılandırılmıştır. "my-app" adında bir etiket kullanılarak Pod'lar seçilir ve bu Pod'lar için "my-app-container" adında bir konteyner oluşturulur. Konteyner, "my-app-image:latest" adlı bir imajı kullanarak 8080 portunda çalışır.
42 |
43 | ### Adım 2: Deployment'ı Kubernetes Kümelerine Uygulama
44 |
45 | Oluşturduğunuz deployment.yaml dosyasını kullanarak Deployment'ı Kubernetes kümelerine uygulayabilirsiniz. Bunun için aşağıdaki komutu kullanabilirsiniz:
46 |
47 | ```shell
48 | kubectl apply -f deployment.yaml
49 | ```
50 |
51 | Bu komut, deployment.yaml dosyasını kullanarak Deployment'ı Kubernetes kümelerine uygular.
52 |
53 | ### Adım 3: Deployment Durumunu Kontrol Etme
54 |
55 | Deployment'ın başarıyla uygulanıp uygulanmadığını kontrol etmek için aşağıdaki komutu kullanabilirsiniz:
56 |
57 | ```shell
58 | kubectl get deployments
59 | ```
60 |
61 | Bu komut, mevcut Deployment'ları listeler ve bunların durumunu gösterir. "my-app-deployment" adında bir Deployment listelenmeli ve "3/3" gibi bir replika sayısı göstermelidir, bu da 3 Pod'un başarıyla oluşturulduğunu gösterir.
62 |
63 | ### Adım 4: Pod'ların Durumunu Kontrol Etme
64 |
65 | Deployment ile oluşturulan Pod'ların durumunu kontrol etmek için aşağıdaki komutu kullanabilirsiniz:
66 |
67 | ```shell
68 | kubectl get pods
69 | ```
70 |
71 | Bu komut, mevcut Pod'ları listeler ve bunların durumunu gösterir. "my-app-deployment-" ile başlayan adlara sahip 3 adet Pod listelenmeli ve durumları "Running" olmalıdır.
72 |
73 | ### Adım 5: Deployment Güncelleme
74 |
75 | Uygulamanızı güncellemek için deployment.yaml dosyasında ilgili değişiklikleri yapın. Örneğin, imaj sürümünü değiştirin.
76 |
77 | Son olarak, güncellenmiş deployment.yaml dosyasını kullanarak Deployment'ı güncellemek için aşağıdaki komutu kullanabilirsiniz:
78 |
79 | ```yaml
80 | kubectl apply -f deployment.yaml
81 | ```
82 |
83 | Bu komut, güncellenmiş YAML dosyasını kullanarak Deployment'ı günceller.
84 |
85 | ## Dikkat Edilmesi Gerekenler
86 |
87 | - **Güvenliğe Dikkat Edin:** Deployment'larınızda güvenlik en önemli faktörlerden biridir. Konteyner imajlarınızı güvenli ve güncel tutun, ayrıca RBAC (Rol Bazlı Erişim Kontrolü) gibi güvenlik önlemlerini kullanın.
88 |
89 | - **Kaynak Kısıtlamalarını Belirleyin:** Deployment'larınızda kaynak kısıtlamalarını (CPU, bellek vb.) belirleyerek konteynerlerinizin kaynak tüketimini kontrol altında tutun. Bu, kümelerinizin performansını ve istikrarını sağlar.
90 |
91 | - **Otomatik İyileştirme Ayarlarını Yapın:** Deployment'larınızda Pod'larda hata oluştuğunda otomatik olarak iyileştirme yapacak şekilde ayarlar yapın. Bu, hizmet kesintilerini en aza indirir ve uygulamanızın sürekli olarak çalışmasını sağlar.
92 |
93 | - **Dağıtım Stratejilerini Dikkatlice Seçin:** Yeni bir sürümü dağıtırken veya güncellerken, dağıtım stratejilerini dikkatlice seçin. Yavaş yavaş güncelleme, aynı anda tümünü güncelleme veya sıfır kesintiyle güncelleme gibi stratejileri kullanarak uygulamanızın kullanılabilirliğini etkilemeden güncellemeleri yönetin.
94 |
95 | - **İzleme ve Günlükleme:** Deployment'larınızı izlemek için Kubernetes üzerinde uygun izleme araçlarını kullanın. Ayrıca, günlükleri toplamak ve analiz etmek için uygun günlükleme stratejilerini uygulayın.
96 |
--------------------------------------------------------------------------------
/environment-variables/Readme.md:
--------------------------------------------------------------------------------
1 | # Environment Variables
2 |
3 | Kubernetes ortam değişkenleri, bir Kubernetes pod veya container'ına ilişkin değişkenlerdir. Pod veya container'ın çalıştığı zaman çevresel değişkenler olarak kullanılabilirler.
4 |
5 | Bu değişkenler, genellikle önceden tanımlanmış ve sabit değerlerden oluşur ve pod veya container'ın hangi durumda çalıştırılacağına bağlı olarak belirlenir. Kubernetes, podlar ve konteynerler için önceden tanımlanmış bazı ortam değişkenlerini sağlar, ancak kullanıcıların da kendi değişkenlerini tanımlayabileceği esnek bir yapı sunar.
6 |
7 | Örneğin, bir uygulamanın veritabanı bağlantı dizesi genellikle bir ortam değişkeni olarak kullanılır. Böylece uygulamanın farklı veritabanlarına bağlanması gerektiğinde sadece ortam değişkeni değiştirilir ve uygulama yeniden başlatılır.
8 |
9 | Ortam değişkenleri, Kubernetes pod ve container konfigürasyon dosyalarında belirtilir. Bunlar genellikle YAML formatında tanımlanır. Örneğin:
10 |
11 | ```yaml
12 | apiVersion: v1
13 | kind: Pod
14 | metadata:
15 | name: my-pod
16 | spec:
17 | containers:
18 | - name: my-container
19 | image: my-image
20 | env:
21 | - name: MY_ENV_VAR
22 | value: my-env-value
23 | ```
24 |
25 | Yukarıdaki örnekte, MY_ENV_VAR adlı bir ortam değişkeni tanımlanmıştır ve my-env-value değeri atanmıştır. Bu pod başlatıldığında, my-container içindeki herhangi bir işlemin MY_ENV_VAR değişkenini kullanabilmesi için hazır olacaktır.
26 |
--------------------------------------------------------------------------------
/label/Readme.md:
--------------------------------------------------------------------------------
1 | # Label
2 |
3 | Label'lar, Kubernetes ortamında kaynaklara (örneğin Pod'lar, Servisler, ReplicaSet'ler vb.) metaveriler eklemek için kullanılan anahtar-değer çiftleridir. Bir kaynağa bir veya daha fazla Label atanabilir ve bu Label'lar, kaynakların gruplandırılması, sorgulanması ve seçilmesi için kullanılabilir. Label'lar, birçok farklı amaç için kullanılabilir, örneğin çevresel ayrımlar, uygulama bileşenleri, versiyon kontrolü vb.
4 |
5 | Label'lar, kaynak tanımlama dosyalarında veya Kubernetes API'si aracılığıyla tanımlanır. Label'lar, genellikle key-value (anahtar-değer) çifti olarak ifade edilir. Örneğin, bir Pod'a "app=backend" veya "env=production" gibi Label'lar atanabilir.
6 |
7 | ```yaml
8 | metadata:
9 | labels:
10 | key1: value1
11 | key2: value2
12 | ```
13 |
14 | ## Label'ların Avantajları
15 |
16 | - Gruplama ve Kategorizasyon: Label'lar, kaynakların belirli kriterlere göre gruplandırılmasını sağlar. Örneğin, bir uygulama içindeki tüm frontend Pod'larını bir Label aracılığıyla gruplayabilirsiniz.
17 |
18 | - Seçme ve Filtreleme: Label'lar, belirli özelliklere veya koşullara sahip kaynakları seçmek veya filtrelemek için kullanılabilir. Örneğin, "env=production" Label'ına sahip olan tüm kaynakları seçmek istediğinizde bu Label'ı kullanabilirsiniz.
19 |
20 | - Versiyon Kontrolü: Label'lar, kaynakların versiyon kontrolü için kullanılabilir. Örneğin, bir uygulama için farklı sürümleri etiketleyerek, kaynaklarınızı kolayca yönetebilirsiniz.
21 |
22 | ## Uygulama
23 |
24 | Örnek Senaryo: Bir e-ticaret uygulaması için frontend ve backend olmak üzere iki ayrı uygulama bileşeni bulunmaktadır. Bunları Kubernetes ortamında dağıtmak ve yönetmek istiyoruz.
25 |
26 | 1. Öncelikle, frontend ve backend uygulamaları için ayrı ayrı Pod tanımları oluşturuyoruz. Frontend uygulaması için "app=frontend" ve backend uygulaması için "app=backend" şeklinde Label'ları tanımlıyoruz.
27 |
28 | ```yaml
29 | # frontend-pod.yaml
30 | apiVersion: v1
31 | kind: Pod
32 | metadata:
33 | name: frontend-pod
34 | labels:
35 | app: frontend
36 | spec:
37 | containers:
38 | - name: frontend-container
39 | image: frontend-image
40 |
41 | # backend-pod.yaml
42 | apiVersion: v1
43 | kind: Pod
44 | metadata:
45 | name: backend-pod
46 | labels:
47 | app: backend
48 | spec:
49 | containers:
50 | - name: backend-container
51 | image: backend-image
52 | ```
53 |
54 | 2. Kaynak tanımlarını Kubernetes'e uyguluyoruz:
55 |
56 | ```bash
57 | kubectl apply -f frontend-pod.yaml
58 | kubectl apply -f backend-pod.yaml
59 | ```
60 |
61 | 3. Oluşturulan Pod'ları kontrol ederken, Label'ları kullanarak belirli bileşenleri seçebiliriz:
62 |
63 | ```bash
64 | kubectl get pods -l app=frontend
65 | kubectl get pods -l app=backend
66 | ```
67 |
68 | 4. Eğer frontend uygulamasında bir güncelleme yapmak istiyorsak, Pod tanımında değişiklik yaparız ve güncellemeyi uygularız:
69 |
70 | ```bash
71 | kubectl apply -f frontend-pod.yaml
72 | ```
73 |
74 | Bu şekilde, Label'lar sayesinde frontend ve backend uygulamalarını kolayca gruplayabilir, seçebilir ve güncelleyebiliriz. Ayrıca, farklı sürümleri veya çevreleri temsil etmek için ek Label'lar ekleyebilir ve bu şekilde kaynakları daha iyi yönetebiliriz.
75 |
--------------------------------------------------------------------------------
/liveness-probe/Readme.md:
--------------------------------------------------------------------------------
1 | # Liveness Probe
2 |
3 | Kubernetes, bir konteyner orkestrasyon platformudur ve birçok uygulama çalıştırmak için kullanılır. Kubernetes Liveness Probes, bir uygulamanın canlı kalıp kalmadığını denetlemek için kullanılan bir özelliktir.
4 | Liveness Probes, bir uygulamanın çalıştığını doğrulamak için belirli bir aralıkta düzenli olarak kontrol eder. Eğer uygulama yanıt vermezse, Kubernetes uygulamayı otomatik olarak yeniden başlatır veya bir yedek uygulamayı devreye alır. Bu, uygulama çökmelerinin önüne geçerek uygulamanın sürekli çalışmasını sağlar.
5 |
6 | ## Uygulama
7 |
8 | Aşağıdaki örnek, bir Deployment objesi için Liveness Probe özelliğini kullanır. Bu Deployment objesi, bir Nginx web sunucusunu çalıştırmak için kullanılır ve her 10 saniyede bir "/healthz" endpoint'ine HTTP GET isteği göndererek web sunucusunun sağlıklı olup olmadığını denetler. Eğer web sunucusu yanıt vermezse, Kubernetes web sunucusunu yeniden başlatır:
9 |
10 | ```yaml
11 | apiVersion: apps/v1
12 | kind: Deployment
13 | metadata:
14 | name: nginx-web-server
15 | spec:
16 | replicas: 3
17 | selector:
18 | matchLabels:
19 | app: nginx-web-server
20 | template:
21 | metadata:
22 | labels:
23 | app: nginx-web-server
24 | spec:
25 | containers:
26 | - name: nginx
27 | image: nginx:latest
28 | ports:
29 | - containerPort: 80
30 | livenessProbe:
31 | httpGet:
32 | path: /healthz
33 | port: 80
34 | initialDelaySeconds: 30
35 | periodSeconds: 10
36 | ```
37 |
38 | Bu örnekte, "livenessProbe" alanında belirtilen HTTP GET isteği "/healthz" endpoint'ine gönderilir. "initialDelaySeconds" alanı, Deployment objesinin başlatıldıktan sonra kaç saniye bekleyeceğini belirtir. "periodSeconds" alanı, her bir Liveness Probe kontrolü arasındaki zaman aralığını belirtir. Bu örnekte, web sunucusu her 10 saniyede bir kontrol edilir ve eğer yanıt vermezse, Kubernetes otomatik olarak yeniden başlatır.
39 |
40 | ## Dikkat Edilmesi Gerekenler
41 |
42 | - Liveness Probe'un yanlış yapılandırılması, uygulamanın gereksiz yere yeniden başlatılmasına veya hizmet kesintilerine neden olabilir. Bu nedenle, HTTP GET isteği gönderilen endpoint ve istek sıklığı gibi ayarların doğru belirlenmesi gereklidir.
43 | - Liveness Probe'un uygulamanın sağlığını doğru bir şekilde ölçmediği durumlarda, uygulamanın yanlış zamanda yeniden başlatılması veya hatalı olarak çalışması riski vardır. Bu nedenle, Liveness Probe'un, uygulamanın gerçek sağlık durumunu doğru bir şekilde yansıtacak şekilde yapılandırılması önemlidir.
44 | - Liveness Probe, sadece uygulamanın sağlıklı olup olmadığını denetler ve uygulamanın performansı veya kaynak kullanımı hakkında bilgi sağlamaz. Bu nedenle, Liveness Probe, uygulamanın sağlığı hakkında bilgi sağlayan bir araç olmakla birlikte, performans ve kaynak kullanımı için farklı araçlar kullanılmalıdır.
45 | - Liveness Probe'un uygulamanın çalışma süresi ve uygulamanın yapılandırılmasına bağlı olarak farklı ayarları gerekebilir. Bu nedenle, Liveness Probe'un ayarları, uygulamanın ihtiyaçlarına göre özelleştirilmelidir.
46 |
--------------------------------------------------------------------------------
/minikube/Readme.md:
--------------------------------------------------------------------------------
1 | # Minikube
2 |
3 | Minikube, Kubernetes'in yerel bir sürümünü çalıştırmak ve geliştirmek için kullanılan bir araçtır. Minikube, kullanıcıların tek bir bilgisayarda Kubernetes'i keşfetmelerine, uygulamalarını test etmelerine ve yerel olarak geliştirmelerine olanak tanır. Ayrıca, birden fazla Kubernetes versiyonunu destekleyerek farklı versiyonlar arasında geçiş yapmayı da kolaylaştırır.
4 |
5 | Minikube, tek bir düğüm (node) üzerinde çalışan basit bir Kubernetes cluster'ı oluşturur. Bu düğüm, yerel bir sanal makine (Virtual Machine - VM) veya konteyner çalıştırma ortamı (container runtime) üzerinde çalışabilir. Minikube, tüm Kubernetes bileşenlerini (master, etcd, kubelet, kube-proxy vb.) otomatik olarak yapılandırır ve başlatır.
6 |
7 | ## Özellikler
8 |
9 | - Hızlı Kurulum ve Başlatma: Minikube, hızlı bir şekilde kurulabilen ve başlatılabilen basit bir araçtır. Kullanıcılar, tek bir komutla Minikube'ı çalıştırabilir ve hızlıca yerel bir Kubernetes cluster'ını kullanıma hazır hale getirebilir.
10 |
11 | - Esnek Konfigürasyon Seçenekleri: Minikube, çeşitli konfigürasyon seçenekleri sunar. Bellek boyutu, CPU sayısı, Kubernetes versiyonu gibi özellikleri isteğe bağlı olarak ayarlayabilirsiniz. Bu, farklı uygulama senaryolarına uygun cluster'lar oluşturmanızı sağlar.
12 |
13 | - Multi-Node Desteği: Minikube, tek düğüm (node) üzerinde çalışmasının yanı sıra birden fazla düğümü destekleyebilir. Böylece, birden fazla Minikube düğümünü birleştirerek daha karmaşık ve ölçeklenebilir senaryoları simüle edebilirsiniz.
14 |
--------------------------------------------------------------------------------
/namespace/Readme.md:
--------------------------------------------------------------------------------
1 | # Namespace
2 |
3 | Kubernetes'de Namespaces, bir Kubernetes kümesi içinde kaynakların mantıksal olarak izole edilmesini sağlayan bir kavramdır. Bir Namespace, birçok Kubernetes nesnesini (örneğin Pod'ları, Service'leri, Deployment'ları) gruplandırmak için kullanılır ve bu nesnelerin benzersiz bir ad alanında çalışmasını sağlar.
4 |
5 | Namespaces, farklı takımlar, projeler veya ortamlar arasında kaynak çakışmasını önlemek için kullanılabilir. Örneğin, bir firma içindeki farklı ekipler kendi Namespaces'lerinde çalışabilir ve birbirlerinin kaynaklarını etkilemeden kendi uygulamalarını yönetebilirler. Aynı şekilde, farklı ortamlar (örneğin, geliştirme, üretim) için farklı Namespaces'ler oluşturarak bu ortamlar arasında izolasyon sağlanabilir.
6 |
7 | Namespaces, varsayılan olarak "default" adında bir Namespace içerir. Ancak, ihtiyaçlarınıza göre kendi özel Namespaces'lerinizi oluşturabilirsiniz. Bir Namespace oluşturduğunuzda, o Namespace içindeki kaynaklar, diğer Namespaces'lerin kaynaklarından izole edilir. Bu, kaynakların birbirleriyle çakışmadan çalışmasını sağlar.
8 |
9 | Namespaces aynı zamanda erişim kontrolünü kolaylaştırır. Örneğin, farklı ekipler arasında roller ve izinler atanabilir ve bu ekipler sadece kendi Namespaces'leri üzerinde çalışabilir. Bu şekilde, güvenlik artırılır ve bir ekip diğer ekiplerin kaynaklarına erişemez.
10 |
11 | ## Uygulama
12 |
13 | Bir e-ticaret platformu üzerinde çalışan bir Kubernetes kümesini ele alalım. Bu platformda, hem kullanıcı arayüzü hem de arka plandaki hizmetler bulunmaktadır. Projenizde, farklı ekiplerin bu platform üzerinde çalışacağını ve her bir ekibin kendi kaynaklarını izole etmek istediğini varsayalım.
14 |
15 | - Öncelikle, farklı ekiplerin projelerini izole edebilmeleri için her bir ekip için ayrı bir Namespace oluşturun. Örneğin, "frontend-team" ve "backend-team" gibi isimler kullanabilirsiniz.
16 |
17 | - "frontend-team" Namespace'i içinde, kullanıcı arayüzüne ait olan Pod'ları, Service'leri ve Deployment'ları gruplandırın. Bu, frontend ekibinin kendi kaynaklarını yönetebilmesini ve diğer ekiplerin kaynaklarından etkilenmemesini sağlar.
18 |
19 | - Benzer şekilde, "backend-team" Namespace'i içinde, arka plandaki hizmetlere ait olan Pod'ları, Service'leri ve Deployment'ları gruplandırın. Bu, backend ekibinin kendi kaynaklarını yönetebilmesini ve diğer ekiplerin kaynaklarından etkilenmemesini sağlar.
20 |
21 | - Her bir Namespace için uygun rol ve izinler tanımlayın. Örneğin, "frontend-team" için sadece frontend ekibine ait kullanıcıların erişebileceği bir rol tanımlayabilirsiniz. Benzer şekilde, "backend-team" için sadece backend ekibine ait kullanıcıların erişebileceği bir rol tanımlayabilirsiniz. Bu şekilde, her bir ekip kendi Namespace'i içinde çalışabilir ve diğer ekiplerin kaynaklarına erişimi kısıtlanmış olur. İzolasyon ve güvenlik sağlanmış olur.
22 |
23 | - Her bir Namespace içindeki kaynaklar, kendi Namespace'i içindeki diğer kaynaklarla ilişkilidir. Örneğin, "frontend-team" Namespace'i içindeki Pod'lar, sadece aynı Namespace içindeki Service'lere yönlendirilebilir. Bu sayede, bir ekibin kaynakları diğer ekibin kaynaklarından etkilenmez ve her bir ekip kendi Namespace'i içinde kendi kaynaklarını yönetebilir.
24 |
25 | ## Dikkat Edilmesi Gerekenler
26 |
27 | - Mantıklı Adlandırma: Namespaces'i oluştururken, anlaşılır ve tanımlayıcı isimler kullanmaya özen gösterin. İsimlendirme, Namespaces içindeki kaynakların amacını veya sahibini anlatmalıdır. Böylece, başkaları Namespace'in içeriğini daha kolay anlayabilir.
28 |
29 | - İzolasyonu Sağlamak: Namespaces, kaynakları birbirinden izole etmek için kullanılır. Farklı Namespaces'ler arasında kaynak çakışmasını önlemek için her Namespace'e yalnızca ihtiyaç duyduğu kaynakları yerleştirin. Aşırı kaynak yüklemesi veya gereksiz bağımlılıklar, küme performansını etkileyebilir.
30 |
31 | - Güvenlik ve Erişim Kontrolü: Namespaces, güvenlik ve erişim kontrolü sağlamak için kullanılabilir. Farklı ekipler veya kullanıcılar arasında roller ve izinler atanabilir. Her bir Namespace, kaynaklara erişim yetkilerini kısıtlayarak izolasyonu güçlendirir.
32 |
33 | - Kaynakların Gruplandırılması: Kaynakları Namespaces içinde mantıklı bir şekilde gruplandırmak önemlidir.
34 |
--------------------------------------------------------------------------------
/node-affinity/Readme.md:
--------------------------------------------------------------------------------
1 | # Node Affinity
2 |
3 | Kubernetes'de, node affinity, bir pod'un hangi node üzerinde çalışacağını belirlemek için kullanılan bir mekanizmadır. Node affinity, podların belirli bir node'a planlanmasını sağlamak için kullanılan bir yöntemdir.
4 |
5 | Node affinity, bir pod'un belirli bir nod üzerinde çalışmasını sağlamak için iki tür kısıtlama sunar:
6 |
7 | - **RequiredDuringSchedulingIgnoredDuringExecution:** Bu kısıtlama, bir pod'un belirli bir node üzerinde çalışması gerektiğini belirtir. Eğer belirtilen node bulunamazsa, pod çalıştırılmaz. Bu kısıtlama, pod'un belirli bir veri merkezi bölgesinde veya belirli bir donanım özelliğine sahip node üzerinde çalışmasını sağlamak için kullanılabilir.
8 | - **PreferredDuringSchedulingIgnoredDuringExecution:** Bu kısıtlama, bir pod'un belirli bir node üzerinde çalışması tercih edilir ama mutlaka o node üzerinde çalışması gerekmez. Bu kısıtlama, belirli bir node üzerindeki kaynak kullanımını dengeli bir şekilde dağıtmak için kullanılabilir.
9 |
10 | Node affinity, Kubernetes'de ölçeklenebilir uygulamaların dağıtımını ve yönetimini kolaylaştırır. Bu sayede, uygulamanızın performansını artırabilir ve daha verimli bir şekilde çalışmasını sağlayabilirsiniz.
11 |
12 | ## Uygulama
13 |
14 | Aşağıdaki örnekte, bir pod'un belirli bir node üzerinde çalışması için node affinity kullanılır:
15 |
16 | ```yaml
17 | apiVersion: v1
18 | kind: Pod
19 | metadata:
20 | name: my-pod
21 | spec:
22 | containers:
23 | - name: my-container
24 | image: my-image
25 | affinity:
26 | nodeAffinity:
27 | requiredDuringSchedulingIgnoredDuringExecution:
28 | nodeSelectorTerms:
29 | - matchExpressions:
30 | - key: node-type
31 | operator: In
32 | values:
33 | - worker
34 | ```
35 |
36 | Bu örnekte, "my-pod" adında bir pod oluşturuluyor. Pod, "my-image" adlı bir konteyneri çalıştırıyor. Pod, "node-type" adlı bir etiketle belirtilen "worker" tipindeki bir nod üzerinde çalışması için ayarlanmıştır. "requiredDuringSchedulingIgnoredDuringExecution" kısıtlaması kullanılmıştır. Bu, pod'un belirtilen bir node üzerinde çalışması gerektiğini belirtir. Eğer belirtilen node bulunamazsa, pod çalıştırılmaz.
37 |
38 | "nodeSelectorTerms" ve "matchExpressions" kullanılarak bir node seçimi yapılmıştır. "nodeSelectorTerms" bölümü, "matchExpressions" listesinde belirtilen koşullara göre node'ları seçer. "key", "operator" ve "values" özellikleri, koşulların nasıl belirleneceğini tanımlar.
39 |
40 | ## Dikkat Edilmesi Gerekenler
41 |
42 | - Node affinity'yi kullanmadan önce, Kubernetes cluster'ınızdaki tüm nod'ların doğru şekilde etiketlendiğinden emin olun. Doğru etiketler kullanılmazsa, pod'lar doğru şekilde planlanamayabilir ve hatalar oluşabilir.
43 | - Pod'un birden fazla node'a planlanması gerektiği durumlarda, "PreferredDuringSchedulingIgnoredDuringExecution" kısıtlaması kullanılabilir. Bu kısıtlama, pod'un belirli bir node üzerinde çalışması tercih edilir ama mutlaka o node üzerinde çalışması gerekmez.
44 | - Node affinity'yi kullanarak pod'ların belirli bir node üzerinde çalışmasını sağlamak, node üzerindeki yükü dengeli bir şekilde dağıtmak için bir yöntemdir. Ancak, bazen node'ların arızalanması veya kullanılamaz hale gelmesi durumunda pod'ların yeniden planlanması gerekebilir. Bu durumlarda, pod'ların farklı bir node üzerinde çalışacak şekilde ayarlanması gerekir.
45 |
--------------------------------------------------------------------------------
/persistent-volume/Readme.md:
--------------------------------------------------------------------------------
1 | # Persistent Volume
2 |
3 | Kubernetes'te, verilerin kalıcı bir şekilde depolanması için Persistent Volume (PV) ve Persistent Volume Claim (PVC) adı verilen iki önemli kavram kullanılır.
4 |
5 | Persistent Volume (PV):
6 |
7 | - PV, Kubernetes kümesinde uygulamaların kullanabileceği kalıcı bir depolama alanıdır.
8 | - PV'ler, altta yatan fiziksel veya sanal depolama kaynaklarına bağlanarak sağlanır.
9 | - PV'ler, depolama sınıfları (storage class) aracılığıyla belirli özelliklere (hız, boyut, dayanıklılık vb.) sahip olabilir.
10 | - PV'ler, bağımsız olarak oluşturulur ve yönetilir. İhtiyaç duyulduğunda bir PVC ile eşleştirilerek kullanılır.
11 |
12 | Persistent Volume Claim (PVC):
13 |
14 | - PVC, uygulamaların bir PV talep etmesi ve kullanması için oluşturulan bir istektir.
15 | - PVC'ler, uygulamaların depolama ihtiyaçlarını belirtmek için kullanılır.
16 | - PVC'ler, PV'leri talep eder ve uygun olan bir PV ile eşleşirse, PVC'ye bağlanır ve kullanılabilir hale gelir.
17 | - PVC'ler, PV'lerden bağımsız olarak oluşturulur ve yönetilir.
18 |
19 | Bu iki kavramın bir araya gelmesiyle, uygulamaların depolama talepleri dinamik olarak karşılanabilir ve uygulamalar PV'ler üzerinden kalıcı verilere erişebilir.
20 |
21 | Aşağıda, bir örnek YAML dosyası üzerinden PV ve PVC nasıl tanımlanır, oluşturulur ve kullanılır gösterilmektedir:
22 |
23 | PV Tanım Dosyası (pv.yaml):
24 |
25 | ```yaml
26 | apiVersion: v1
27 | kind: PersistentVolume
28 | metadata:
29 | name: my-pv
30 | spec:
31 | capacity:
32 | storage: 5Gi
33 | accessModes:
34 | - ReadWriteOnce
35 | hostPath:
36 | path: /data/my-pv
37 | ```
38 |
39 | PVC Tanım Dosyası (pvc.yaml):
40 |
41 | ```yaml
42 | apiVersion: v1
43 | kind: PersistentVolumeClaim
44 | metadata:
45 | name: my-pvc
46 | spec:
47 | accessModes:
48 | - ReadWriteOnce
49 | resources:
50 | requests:
51 | storage: 2Gi
52 | ```
53 |
54 | Bu örnekte, "my-pv" adında 5GB boyutunda bir PV tanımlanır ve "/data/my-pv" dizinine bağlanır. Ardından, "my-pvc" adında 2GB boyutunda bir PVC tanımlanır.
55 |
56 | PVC'nin kullanılması için bir Pod'a bağlanması gerekmektedir. Bu Pod tanımı aşağıdaki gibi olabilir:
57 |
58 | Pod Tanım Dosyası (pod.yaml):
59 |
60 | ```yaml
61 | apiVersion: v1
62 | kind: Pod
63 | metadata:
64 | name: my-pod
65 | spec:
66 | containers:
67 | - name: my-app
68 | image: my-app-image:latest
69 | volumeMounts:
70 | - name: my-volume
71 | mountPath: /data
72 | volumes:
73 | - name: my-volume
74 | persistentVolumeClaim:
75 | claimName: my-pvc
76 | ```
77 |
78 | Bu Pod tanımında, "my-pvc" adlı PVC'ye bağlanarak "/data" dizinine monte edilen bir konteyner tanımlanmıştır.
79 |
80 | ## Access Modlar
81 |
82 | Persistent Volume (PV)'de üç farklı accessModes çeşidi bulunmaktadır:
83 |
84 | 1. ReadWriteOnce (RWO):
85 |
86 | - Bu accessModes, bir PV'nin aynı anda yalnızca bir Pod tarafından okunup yazılmasına izin verir.
87 | - Yani, bir PV, aynı anda yalnızca bir Pod tarafından monte edilebilir ve üzerinde okuma ve yazma işlemleri gerçekleştirilebilir.
88 | - RWO, genellikle tek bir düğümde veya fiziksel disk üzerinde bağımsız depolama sağlamak için kullanılır.
89 |
90 | 2. ReadOnlyMany (ROX):
91 |
92 | - Bu accessModes, bir PV'nin birden fazla Pod tarafından eşzamanlı olarak okunmasına, ancak yazılmasına izin vermez.
93 | - Yani, birden fazla Pod aynı PV'yi sadece okuma amaçlı olarak kullanabilir, yazma işlemi gerçekleştirilemez.
94 | - ROX, genellikle birden çok Pod'un aynı anda veri okuması gereken senaryolarda kullanılır.
95 |
96 | 3. ReadWriteMany (RWX):
97 | - Bu accessModes, bir PV'nin birden fazla Pod tarafından eşzamanlı olarak hem okunmasına hem de yazılmasına izin verir.
98 | - Yani, birden fazla Pod aynı PV'yi okuma ve yazma işlemleri için kullanabilir.
99 | - RWX, genellikle birden çok Pod'un aynı anda veri okuması ve yazması gereken senaryolarda kullanılır.
100 |
101 | Bu accessModes çeşitleri, farklı uygulama ve kullanım senaryolarına göre depolama kaynaklarının paylaşılabilirliğini ve kullanımını kontrol etmek için kullanılır. PV'lerin accessModes özelliği, bir PVC'nin uygun bir PV'ye bağlanabilmesi için uyumlu accessModes'a sahip olması gerektiği anlamına gelir.
102 |
103 | ## PersistentVolumeReclaimPolicy
104 |
105 | Persistent Volume (PV)'lerde üç farklı PersistentVolumeReclaimPolicy çeşidi bulunmaktadır:
106 |
107 | 1. Retain:
108 |
109 | - Bu politika, PV'nin kullanımdan kaldırılması veya serbest bırakılması durumunda verilerin korunmasını sağlar.
110 | - Bir PV, kullanımdan kaldırıldığında veya bağlantısı kesildiğinde bile verileri korunur ve elle temizlenene kadar kullanılabilir durumda kalır.
111 | - Bu politika, verilerin kalıcı olarak korunması gereken durumlarda tercih edilir. Kullanıcılar, verileri elle temizleyerek PV'yi yeniden kullanabilirler.
112 |
113 | 2. Delete:
114 |
115 | - Bu politika, PV kullanımdan kaldırıldığında veya serbest bırakıldığında otomatik olarak PV'yi temizler.
116 | - PV'ye bağlı veriler de otomatik olarak silinir ve geri dönüşü olmayan bir şekilde kaldırılır.
117 | - Bu politika, verilerin kullanımdan kaldırıldığında otomatik olarak temizlenmesi gereken durumlarda tercih edilir.
118 |
119 | 3. Recycle (Artık önerilmemektedir):
120 | - Bu politika, PV kullanımdan kaldırıldığında veya serbest bırakıldığında verileri silmeden önce temizlemek için bir geri dönüşüm süreci başlatır.
121 | - Geri dönüşüm süreci, PV içindeki verileri silerek veya sıfırlayarak gerçekleştirilebilir.
122 | - Bu politika artık önerilmemektedir ve genellikle kullanımdan kalkmış bir depolama sistemi için geri dönüşüm yapmak isteyen eski uygulamalar için kullanılır.
123 |
124 | PersistentVolumeReclaimPolicy, bir PV'nin kullanımdan kaldırılması veya serbest bırakılması durumunda ne yapılacağını belirler. Bu politikalar, veri yönetimi ve güvenlik gereksinimlerine göre seçilmelidir.
125 |
126 | ## Uygulama
127 |
128 | ### Adım 1: PV Tanımı
129 |
130 | PV için bir YAML dosyası oluşturun. Aşağıdaki örnekte, hostPath kullanılarak basit bir PV tanımlanmaktadır:
131 |
132 | ```yaml
133 | apiVersion: v1
134 | kind: PersistentVolume
135 | metadata:
136 | name: my-pv
137 | spec:
138 | capacity:
139 | storage: 5Gi
140 | accessModes:
141 | - ReadWriteOnce
142 | hostPath:
143 | path: /data/my-pv
144 | ```
145 |
146 | Bu örnekte, "my-pv" adında 5GB boyutunda bir PV tanımlanmıştır. "/data/my-pv" dizinine bağlanan bir hostPath kullanılmaktadır.
147 |
148 | ### Adım 2: PVC Tanımı
149 |
150 | PVC için bir YAML dosyası oluşturun. Aşağıdaki örnekte, önceden tanımlanan PV'ye uygun bir PVC tanımlanmaktadır:
151 |
152 | ```yaml
153 | apiVersion: v1
154 | kind: PersistentVolumeClaim
155 | metadata:
156 | name: my-pvc
157 | spec:
158 | accessModes:
159 | - ReadWriteOnce
160 | resources:
161 | requests:
162 | storage: 2Gi
163 | ```
164 |
165 | Bu örnekte, "my-pvc" adında 2GB boyutunda bir PVC tanımlanmıştır.
166 |
167 | ### Adım 3: PVC'yi Kullanacak Pod Tanımı
168 |
169 | PVC'yi kullanacak bir Pod tanımlayın. Aşağıdaki örnekte, PVC ile birlikte bir Pod tanımlanmaktadır:
170 |
171 | ```yaml
172 | apiVersion: v1
173 | kind: Pod
174 | metadata:
175 | name: my-pod
176 | spec:
177 | containers:
178 | - name: my-app
179 | image: my-app-image:latest
180 | volumeMounts:
181 | - name: my-volume
182 | mountPath: /data
183 | volumes:
184 | - name: my-volume
185 | persistentVolumeClaim:
186 | claimName: my-pvc
187 | ```
188 |
189 | Bu örnekte, "my-pvc" adlı PVC'ye bağlı olarak "/data" dizinine monte edilen bir konteyner tanımlanmaktadır.
190 |
191 | ### Adım 4: Kaynakları Oluşturma
192 |
193 | Önce PV'yi oluşturun:
194 |
195 | ```
196 | kubectl apply -f pv.yaml
197 | ```
198 |
199 | Ardından, PVC'yi oluşturun:
200 |
201 | ```
202 | kubectl apply -f pvc.yaml
203 | ```
204 |
205 | Son olarak, PVC'yi kullanan Pod'u oluşturun:
206 |
207 | ```
208 | kubectl apply -f pod.yaml
209 | ```
210 |
211 | Bu adımları takip ederek PV, PVC ve Pod'u oluşturabilirsiniz. PV, PVC'ye bağlanacak ve PVC, Pod'un içerisindeki mountPath'e monte edilecektir. Böylece Pod, kalıcı verilere PVC aracılığıyla erişebilir.
212 |
--------------------------------------------------------------------------------
/pod-affinity/Readme.md:
--------------------------------------------------------------------------------
1 | # Pod Affinity
2 |
3 | Kubernetes'de Pod Affinity, bir pod'un diğer podlarla ilişkisini belirlemek için kullanılan bir mekanizmadır. Pod Affinity, bir pod'un belirli bir node üzerinde çalışması gerektiği durumlarda kullanılır.
4 |
5 | Pod Affinity'nin kullanımı, pod'ların planlanması sırasında diğer podlarla olan ilişkilerine bağlıdır. Örneğin, bir pod'un belirli bir başka pod'un yakınında çalışması gerektiği durumlarda Pod Affinity kullanılabilir.
6 |
7 | Pod Affinity, "requiredDuringSchedulingIgnoredDuringExecution" ve "preferredDuringSchedulingIgnoredDuringExecution" olmak üzere iki kısıtlama türüne sahiptir. "requiredDuringSchedulingIgnoredDuringExecution" kısıtlaması, bir pod'un belirli bir pod veya pod grubuyla aynı node üzerinde çalışmasını gerektirir. "preferredDuringSchedulingIgnoredDuringExecution" kısıtlaması ise pod'un belirli bir pod veya pod grubuyla aynı node üzerinde çalışmasını tercih eder, ancak mutlaka aynı node üzerinde çalışması gerekmez.
8 |
9 | Pod Affinity, Kubernetes cluster'ında pod'ların doğru şekilde planlanmasına yardımcı olur. Pod'ların doğru şekilde planlanması, uygulamanın performansını artırabilir ve Kubernetes cluster'ının daha verimli çalışmasını sağlayabilir.
10 |
11 | Aşağıda, Pod Affinity kullanarak pod'ların belirli bir pod veya pod grubuyla aynı node üzerinde çalışması sağlanan bir örnek gösterilmektedir:
12 |
13 | ```yaml
14 | apiVersion: v1
15 | kind: Pod
16 | metadata:
17 | name: my-pod
18 | spec:
19 | containers:
20 | - name: my-container
21 | image: my-image
22 | affinity:
23 | podAffinity:
24 | requiredDuringSchedulingIgnoredDuringExecution:
25 | - labelSelector:
26 | matchExpressions:
27 | - key: app
28 | operator: In
29 | values:
30 | - my-app
31 | topologyKey: 'kubernetes.io/hostname'
32 | ```
33 |
34 | Bu örnekte, "my-pod" adında bir pod oluşturuluyor. Pod, "my-image" adlı bir konteyneri çalıştırıyor. Pod, "app" adlı bir etiketle belirtilen "my-app" pod grubuyla aynı node üzerinde çalışması için ayarlanmıştır.
35 |
36 | Bu örnekte, "requiredDuringSchedulingIgnoredDuringExecution" kısıtlaması kullanılmıştır. Bu, pod'un belirtilen bir pod veya pod grubuyla aynı node üzerinde çalışması gerektiğini belirtir. Eğer belirtilen pod veya pod grubuyla aynı node bulunamazsa, pod çalıştırılmaz.
37 |
38 | ## Dikkat Edilmesi Gerekenler
39 |
40 | - **Döngüsel etkileşimlerin önlenmesi:** Pod Affinity, pod'ların birbirleriyle etkileşimde bulunmasını sağlayabilir. Ancak, belirli bir pod grubunda döngüsel etkileşimler oluşabilir. Bu nedenle, Pod Affinity kullanırken döngüsel etkileşimleri önlemek önemlidir.
41 | - **CPU ve hafıza kullanımı:** Pod Affinity, pod'ların belirli bir node üzerinde çalışmasını sağlayabilir. Ancak, bu node'ların CPU ve hafıza kullanımı gibi özelliklerinin pod'ların gereksinimlerini karşılayıp karşılamadığı kontrol edilmelidir. Aksi takdirde, node üzerindeki pod'lar performans sorunlarına neden olabilir.
42 | - **Verimlilik:** Pod Affinity, pod'ların doğru şekilde planlanmasına yardımcı olabilir. Ancak, Pod Affinity kullanımının verimliliği artırmak için doğru şekilde yapılandırılması önemlidir. Yetersiz yapılandırılmış Pod Affinity kısıtlamaları, uygulamanın performansını olumsuz etkileyebilir.
43 | - **Pod sayısı:** Pod Affinity, belirli bir pod grubuyla aynı node üzerinde çalışan pod sayısını kontrol edebilir. Ancak, node üzerindeki pod sayısı kontrol edilmelidir. Aksi takdirde, node üzerindeki pod'ların performans sorunlarına neden olabilir.
44 | - **Topoloji anahtarları:** Pod Affinity, pod'ların belirli bir topoloji anahtarı kullanarak node'lar arasında planlanmasını sağlar. Ancak, doğru topoloji anahtarlarının seçilmesi önemlidir. Yanlış topoloji anahtarları kullanıldığında, pod'ların yanlış node üzerinde çalışmasına neden olabilir.
45 |
--------------------------------------------------------------------------------
/pod/Readme.md:
--------------------------------------------------------------------------------
1 | # Pod
2 |
3 | Pod, Kubernetes ortamında bir veya daha fazla konteynerin bir araya getirildiği en küçük dağıtım birimidir. Pod, aynı evsahibi ortamı paylaşan ve aynı ağ ve depolama kaynaklarını kullanabilen konteynerleri gruplar. Bu sayede birbirleriyle iletişim kurabilir ve birlikte çalışabilirler.
4 |
5 | ## Pod'un Avantajları
6 |
7 | - **İzolasyon**: Her Pod, kendi IP adresi, bellek alanı, dosya sistemleri ve diğer kaynaklarıyla tamamen izole edilmiştir. Bu, Pod içindeki konteynerlerin birbirlerini etkilemeden çalışmasını sağlar.
8 |
9 | - **Birlikte Dağıtım**: Bir Pod içindeki konteynerler, aynı zaman dilimi içinde ve aynı fiziksel veya sanal makinede dağıtılır. Bu, konteynerlerin birlikte çalışma yeteneklerini artırır ve performansı iyileştirir.
10 |
11 | - **İletişim ve Paylaşım**: Pod içindeki konteynerler, localhost üzerinden birbirleriyle iletişim kurabilir. Ayrıca, Pod içindeki konteynerler aynı depolama kaynaklarını ve ağ bileşenlerini paylaşabilir.
12 |
13 | - **Yüksek Erişilebilirlik**: Podlar, birden çok örneğini çalıştırarak yüksek kullanılabilirlik sağlayabilir. Bir Pod'daki bir konteyner çöktüğünde, diğer konteynerler hala çalışmaya devam eder.
14 |
15 | ## Pod Özellikleri
16 |
17 | - **IP Adresi**: Her Pod, Kubernetes ağındaki benzersiz bir IP adresine sahiptir. Pod içindeki tüm konteynerler bu IP adresini kullanarak birbirleriyle iletişim kurabilir.
18 |
19 | - **Konteynerler**: Bir Pod içinde bir veya daha fazla konteyner barındırılabilir. Bu konteynerler, birlikte çalışmak için oluşturulan mikro hizmetlerin parçalarıdır.
20 |
21 | - **Depolama Kaynakları**: Pod, depolama alanı olarak kullanılabilen bir veya daha fazla birimde depolama kaynaklarına sahip olabilir. Bu, pod içindeki konteynerlerin veri paylaşmasını sağlar.
22 |
23 | - **Ağ Ayarları**: Pod'un birincil IP adresi dışında, diğer ağ ayarlarına da sahip olabilir. Bu ayarlar, Pod'un dış dünyayla iletişimini ve diğer Pod'larla iletişimini sağlar.
24 |
25 | - **Hedeflenen Birim**: Bir Pod, Kubernetes tarafından yönetilen bir çalıştırma birimidir ve çeşitli yönetim operasyonlarının hedefidir. Örneğin, ölçeklendirme, otomatik yeniden başlatma ve dağıtım işlemleri Pod üzerinde gerçekleştirilebilir.
26 |
27 | ## Pod'ların Kullanım Senaryoları
28 |
29 | - **Tek Konteyner Pod'ları**: Bir Pod, yalnızca bir konteyner içeriyorsa, tek konteyner Pod'u olarak adlandırılır. Bu senaryoda, konteyner içindeki uygulama doğrudan çalıştırılır.
30 |
31 | - **Çok Konteyner Pod'ları**: Bir Pod, birden çok konteyner içeriyorsa, çok konteyner Pod'u olarak adlandırılır. Bu senaryoda, birincil konteyner yanında yardımcı konteynerler de çalıştırılabilir. Yardımcı konteynerler, birincil konteynerin yan görevlerini gerçekleştirebilir.
32 |
33 | ## Pod Yaratma ve Yönetme
34 |
35 | Pod'lar, Kubernetes API'sini kullanarak tanımlanır ve yönetilir. Pod oluşturulurken, Pod'a ait konteynerler, depolama kaynakları ve ağ ayarları tanımlanır. Bu Pod tanımı, Kubernetes tarafından yorumlanır ve uygun kaynaklar ayrılır. Pod'un durumu izlenir ve gerektiğinde yeniden başlatılır veya ölçeklendirilir.
36 |
37 | Pod'lar, genellikle bir Replication Controller, ReplicaSet veya Deployment gibi daha yüksek seviye bir kaynak tarafından oluşturulur ve yönetilir. Bu, Pod'ların ölçeklenebilirlik, yüksek kullanılabilirlik ve güncelleme yetenekleri sağlar.
38 |
--------------------------------------------------------------------------------
/readiness-probe/Readme.md:
--------------------------------------------------------------------------------
1 | # Readiness Probe
2 |
3 | Readiness Probe, bir Kubernetes Pod'unun çalışmaya hazır olup olmadığını belirlemek için kullanılan bir mekanizmadır. Bir Pod'un Ready olabilmesi için tüm containerların çalışması gerektiği durumlarda, tüm containerların Ready olması gerekmektedir. Ancak bazı durumlarda bir container'ın çalışmaya hazır olması yeterlidir. Bu noktada Readiness Probe devreye girer ve ilgili container'ın belirtilen koşulları karşılayıp karşılamadığını belirleyerek, Kubernetes'e bu bilgiyi bildirir.
4 |
5 | Bir Readiness Probe, bir HTTP isteği göndererek, belirli bir portun açık olup olmadığını kontrol ederek veya bir işlemi kontrol ederek gerçekleştirilebilir. Eğer bir container'in belirtilen koşulları karşılamadığı tespit edilirse, Kubernetes bu container'a yeni istekler göndermeyi durdurabilir. Bu sayede, hatalı container'lardan kaynaklanan servis kesintileri önlenebilir.
6 |
7 | ## Uygulama
8 |
9 | Aşağıdaki örnekte, bir Pod'un içinde çalışan bir konteynırın hazır olup olmadığını belirlemek için bir Readiness Probe tanımlanmıştır. Konteynır, /healthz yoluna GET istekleri alacak ve yanıt olarak HTTP durum kodu 200 verecek.
10 |
11 | ```yaml
12 | apiVersion: v1
13 | kind: Pod
14 | metadata:
15 | name: mypod
16 | spec:
17 | containers:
18 | - name: mycontainer
19 | image: myimage
20 | readinessProbe:
21 | httpGet:
22 | path: /healthz
23 | port: 80
24 | initialDelaySeconds: 5
25 | periodSeconds: 10
26 | ```
27 |
28 | Bu tanım, Pod'un oluşturulmasından 5 saniye sonra ve her 10 saniyede bir /healthz yoluna istek göndererek konteynırın hazır olup olmadığını kontrol edecek. Konteynır yanıt veremezse, Kubernetes tarafından yeniden başlatılacaktır.
29 |
30 | ## Readiness ve Liveness Probe Farkı
31 |
32 | Kubernetes'te Liveness Probe ve Readiness Probe, bir konteynerin durumunu izlemek için kullanılan araçlardır. Ancak ikisi arasında birkaç farklılık vardır:
33 |
34 | - **Liveness Probe:** Bir konteynerin çalışıp çalışmadığını belirler. Eğer konteyner liveness probe tarafından sağlanan testi geçemezse, Kubernetes tarafından yeniden başlatılır. Liveness probe genellikle bir web sunucusunun servis verip vermediğini kontrol eder.
35 |
36 | - **Readiness Probe:** Bir konteynerin isteklere yanıt verebilecek durumda olup olmadığını belirler. Eğer bir konteyner hala başlatılırken olduğu gibi ayarlanıyorsa, ancak isteklere yanıt veremiyorsa, readiness probe tarafından sağlanan testi geçemez ve bu nedenle servis trafiğinden çıkarılır. Readiness probe genellikle bir web sunucusunun isteklere yanıt verip vermediğini kontrol eder.
37 |
38 | Bu nedenle, Liveness Probe bir konteynerin "canlı" olup olmadığını belirlerken, Readiness Probe bir konteynerin "hazır" olup olmadığını belirler.
39 |
40 | ## Dikkat Edilmesi Gerekenler
41 |
42 | - Probenin başarısız olması, pod'un doğrudan silinmesine neden olabilir ve bağlı olduğu hizmetlerin kullanılamaz hale gelmesine sebep olabilir. Bu nedenle, özellikle kritik hizmetlerde, uygun bir bekleme süresi ve yeniden deneme sayısı ayarlamak önemlidir.
43 | - Probenin sıklığı da önemlidir. Sık sık yapılan istekler, gereksiz yere kaynak tüketebilir ve sistemi yavaşlatabilir. Aksine, nadiren yapılan istekler hataların tespit edilmesini geciktirebilir.
44 | - Probenin yapıldığı yol, pod'un durumunu etkileyebilir. Örneğin, bir dosya yoksa veya bir bağlantı sağlanamazsa, pod başarısız olarak işaretlenebilir ve hizmetlerde kesintiye neden olabilir. Bu nedenle, doğru yol belirtilmelidir.
45 |
--------------------------------------------------------------------------------
/resource-limits/Readme.md:
--------------------------------------------------------------------------------
1 | # Resource Limits
2 |
3 | Kubernetes'de, bir konteynerin kullanabileceği maksimum CPU ve bellek miktarını belirlemek için "resource limits" kullanılır. Bu, Kubernetes kubernetes-cluster üzerinde çalışan tüm konteynerlerin adil bir şekilde kaynakları kullanmalarını sağlamaya yardımcı olur. "Resource limits" aynı zamanda konteynerlerin, kullanılabilecek kaynakları aşan yüksek kullanım durumlarında uygulamanın çökmesini veya yavaşlamasını önlemeye yardımcı olur.
4 |
5 | "Resource limits" belirli bir konteyner için iki ayrı değer içerir:
6 |
7 | - **CPU limiti:** Bir konteynerin maksimum kullanabileceği CPU sayısıdır.
8 | - **Bellek limiti:** Bir konteynerin maksimum kullanabileceği bellek miktarıdır.
9 | Kubernetes, "resource limits" özelliği sayesinde belirli bir miktar CPU veya bellek kullanımı aşıldığında otomatik olarak uygulamayı yeniden başlatarak kaynak tükenmesi durumlarını engellemeye yardımcı olur.
10 |
11 | ## Uygulama
12 |
13 | Aşağıdaki örnek, bir Pod'daki konteyner için CPU ve bellek limitlerini belirlemektedir:
14 |
15 | ```yaml
16 | apiVersion: v1
17 | kind: Pod
18 | metadata:
19 | name: resource-limits
20 | spec:
21 | containers:
22 | - name: my-container
23 | image: my-image
24 | resources:
25 | limits:
26 | cpu: '1'
27 | memory: '2Gi'
28 | requests:
29 | cpu: '500m'
30 | memory: '1Gi'
31 | ```
32 |
33 | Bu Pod'da yer alan my-container adlı konteyner için, CPU limiti olarak 1 core ("1") ve bellek limiti olarak 2 gigabayt ("2Gi") tanımlanmaktadır. Ayrıca, CPU isteği olarak yarım core ("500m") ve bellek isteği olarak 1 gigabayt ("1Gi") belirtilmiştir.
34 |
35 | > 1 cpu = cpu="1" = cpu: "1000" = cpu="1000m"
36 |
37 | ## Dikkat Edilmesi Gerekenler
38 |
39 | - Limits değerleri belirlenirken, podların ihtiyaç duyduğu kaynakları doğru şekilde belirlemek ve bu değerlerin yeterli olacağından emin olmak önemlidir. Aksi halde podlar yeterli kaynaklara sahip olmadıklarından dolayı hata verebilir ya da düşük performans sergileyebilirler.
40 | - Limits değerleri, cluster'ın toplam kaynaklarını aşmamalıdır. Aksi halde diğer podlar ve node'lar üzerinde sorunlara yol açabilir.
41 | - Limits değerleri belirlenirken, podların kullanım senaryosu da dikkate alınmalıdır. Örneğin, bir pod'un CPU kullanımı sabit olabilirken, aynı pod'un RAM kullanımı dinamik olabilir. Bu nedenle, Limits değerleri belirlenirken podların özelliklerine göre farklı sınırlar belirlemek gerekebilir.
42 | - Limits değerleri, doğru ölçü birimleri ile belirlenmelidir. Örneğin, CPU kullanımı millicore cinsinden, RAM kullanımı ise gigabyte cinsinden ifade edilir.
43 | - Limits değerleri belirlenirken, podların aynı zamanda Liveness ve Readiness Probe'larına da yeterli kaynak ayrılmalıdır. Aksi halde bu Probe'lar doğru şekilde çalışmayabilir veya yanıltıcı sonuçlar verebilirler.
44 |
--------------------------------------------------------------------------------
/rollout-ve-rollback/README.md:
--------------------------------------------------------------------------------
1 | # Rollout ve Rollback
2 |
3 | ## Rollout Nedir?
4 |
5 | - Bir uygulamanın yeni bir sürümünün dağıtımını başlatmak için kullanılır.
6 | - Bir önceki sürümden farklı olarak yeni bir sürümde yer alan güncellemeleri sağlar.
7 | - Yeni bir sürümün başarılı bir şekilde dağıtımı için bir dizi adımı otomatikleştirir.
8 | - Yeni bir sürümün yavaş yavaş tüm pod'lara dağıtılmasını ve eski sürümün aşamalı olarak kaldırılmasını sağlar.
9 | - Uygulamanın yeni sürümüne geçiş sırasında yaşanabilecek olası kesintileri en aza indirir.
10 |
11 | ## Rollback Nedir?
12 |
13 | - Uygulamanın bir önceki sürümüne geri dönmek için kullanılır.
14 | - Bir uygulama sürümünün yanlışlıkla veya hatalı bir şekilde dağıtıldığı durumlarda kullanılır.
15 | - Uygulama sürümünün hızlı bir şekilde geri alınmasını ve bir önceki çalışan sürüme geçiş yapılmasını sağlar.
16 | - Geri alma işlemini otomatikleştirir ve hızlı bir şekilde tamamlanmasını sağlar.
17 |
18 | ## Uygulama
19 |
20 | ```yaml
21 | apiVersion: apps/v1
22 | kind: Deployment
23 | metadata:
24 | name: myapp-deployment
25 | labels:
26 | app: myapp
27 | spec:
28 | replicas: 3
29 | selector:
30 | matchLabels:
31 | app: myapp
32 | template:
33 | metadata:
34 | labels:
35 | app: myapp
36 | spec:
37 | containers:
38 | - name: myapp
39 | image: myapp:v1
40 | ports:
41 | - containerPort: 80
42 | ```
43 |
44 | Bu deployment nesnesinde image alanı, myapp:v1 olarak tanımlanmıştır. Eğer bu image güncellenmek istenirse, örneğin myapp:v2 sürümüne geçmek istenirse, aşağıdaki komut kullanılabilir:
45 |
46 | ```shell
47 | kubectl set image deployment/myapp-deployment myapp=myapp:v2
48 | ```
49 |
50 | Bu komut, deployment nesnesindeki myapp isimli container için kullanılan image'ı myapp:v2 olarak güncelleyecektir. Bu güncelleme, varsayılan olarak, tüm replica setlerinde aynı anda gerçekleştirilir. Rollout işlemi sırasında, deployment nesnesinin status alanı güncellenir. Aşağıdaki komut kullanılarak deployment nesnesinin rollout durumu takip edilebilir:
51 |
52 | ```shell
53 | kubectl rollout status deployment/myapp-deployment
54 | ```
55 |
56 | Bu komut, deployment nesnesinin rollout işleminin tamamlanıp tamamlanmadığını kontrol eder. Eğer güncelleme işlemi tamamlanmışsa, aşağıdaki komut kullanılarak yeni image sürümüne uygun pod'ların listesi alınabilir:
57 |
58 | ```shell
59 | kubectl get pods -l app=myapp
60 | ```
61 |
62 | Bu komut, app=myapp label'ına sahip pod'ların listesini verir. Artık pod'ların yeni image sürümüne sahip olması beklenir. Eğer güncelleme işlemi hatalı bir şekilde sonuçlanırsa, rollback işlemi kullanılarak önceki sürüme geri dönülebilir.
63 |
64 | ## Strateji Belirleme
65 |
66 | > Deployment'ın yeniden oluşturulma stratejisini strategy adında bir ifade belirler. Bu ifadenin default değeri RollingUpdate
67 |
68 | RollingUpdate stratejisi, yeni bir versiyonu yavaş yavaş deployment'a dahil ederek eski versiyonun yerini değiştirirken, Recreate stratejisi mevcut tüm pod'ları öldürür ve yeni versiyon için tamamen yeni bir set oluşturur. RollingUpdate stratejisi, kullanıcılara sıfır downtime sağlamak için daha çok tercih edilirken, Recreate stratejisi daha basit bir yaklaşım sunar ve eski versiyondan tamamen kurtulmak istenildiğinde kullanılabilir.
69 |
70 | ### Recreate Kullanımı
71 |
72 | ```yaml
73 | apiVersion: apps/v1
74 | kind: Deployment
75 | metadata:
76 | name: rcdeployment
77 | labels:
78 | team: development
79 | spec:
80 | replicas: 3
81 | selector:
82 | matchLabels:
83 | app: recreate
84 | strategy:
85 | type: Recreate # Recreate stratejisi burada tanımlanıyor
86 | template:
87 | metadata:
88 | labels:
89 | app: recreate
90 | spec:
91 | containers:
92 | - name: nginx
93 | image: nginx:1.20 # yeni bir sürüm tanımlanıyor
94 | ports:
95 | - containerPort: 80
96 | ```
97 |
98 | Bu YAML dosyasında strategy bölümünde Recreate stratejisi tanımlandı. Bu durumda güncelleme işlemi sırasında, önceki versiyon silinir ve yeni versiyon oluşturulur. Bu, tüm pod'ların yeniden oluşturulması anlamına gelir ve bu nedenle geçici bir çalışmazlık süresine yol açabilir.
99 |
100 | ### RollingUpdate Kullanımı
101 |
102 | ```yaml
103 | apiVersion: apps/v1
104 | kind: Deployment
105 | metadata:
106 | name: nginx-deployment
107 | spec:
108 | replicas: 3
109 | selector:
110 | matchLabels:
111 | app: nginx
112 | template:
113 | metadata:
114 | labels:
115 | app: nginx
116 | spec:
117 | containers:
118 | - name: nginx
119 | image: nginx:1.19.3
120 | ports:
121 | - containerPort: 80
122 | terminationGracePeriodSeconds: 10
123 | strategy:
124 | type: RollingUpdate
125 | rollingUpdate:
126 | maxUnavailable: 1
127 | maxSurge: 1
128 | ```
129 |
130 | Bu örnekte, Deployment nesnesi, spec bölümünde belirtilen özelliklere sahip bir ReplicaSet oluşturur. ReplicaSet daha sonra bir veya daha fazla Pod'u barındıracak şekilde scale edilir. strategy bölümünde, type: RollingUpdate olarak ayarlandığı için, yeni bir güncelleme yayınlandığında, Kubernetes önce yeni Pod'ları oluşturur ve eski Pod'ları siler, bu sayede sıfır kesinti süresi (zero-downtime) elde edilir. rollingUpdate bölümü, aynı anda kaç tane Pod'un güncellenebileceğini ve kaç tane yeni Pod oluşturulabileceğini belirtir. Bu örnekte, maxUnavailable değeri 1 ve maxSurge değeri de 1 olarak ayarlandı, bu da Kubernetes'in aynı anda sadece bir Pod'u devre dışı bırakacağı ve bir Pod daha oluşturacağı anlamına gelir.
131 |
132 | ### Record Kullanımı
133 |
134 | **--record** parametresi, kubectl komutlarındaki değişikliklerin kaydedilmesine ve bu değişikliklerin sonrasında kullanılabilecek bir kayıt oluşturulmasına olanak tanır. Bu parametre, kubectl kullanarak bir nesne oluşturulduğunda, güncellendiğinde veya silindiğinde, bir kayıt oluşturulmasını sağlar.
135 |
136 | Bu kayıt, sonrasında kubectl rollout history komutu kullanılarak geçmiş değişiklikleri görüntülemek veya bir önceki sürüme geri dönmek gibi işlemlerde kullanılabilir. Özellikle güncelleme işlemleri için kayıt oluşturmak, geri alma işlemlerinde oldukça faydalıdır.
137 |
138 | Örnek olarak, kubectl create veya kubectl apply komutlarının sonuna --record parametresi eklenerek kayıt oluşturulabilir:
139 |
140 | ```yaml
141 | kubectl apply -f deployment.yaml --record
142 | ```
143 |
144 | ### Geçmişe Dönme
145 |
146 | Kubernetes'te Deployment'lar üzerinden kaydedilen kayıtların arasında geçiş yapmak için kubectl rollout undo komutu kullanılabilir. Aşağıdaki örnek, my-deployment adlı bir Deployment'ın son yapılandırmasına geri dönmek için bir kayıt geçişini gerçekleştirir:
147 |
148 | ```shell
149 | kubectl rollout undo deployment/my-deployment
150 | ```
151 |
152 | Bu komut, my-deployment Deployment'ının son yapılandırmasına geri döner. --record seçeneği kullanılarak, geri alma işleminin kaydı tutulabilir:
153 |
154 | ```shell
155 | kubectl rollout undo deployment/my-deployment --to-revision=2 --record
156 | ```
157 |
158 | Bu komut, my-deployment Deployment'ının 2. yapılandırmasına geri döner ve geri alma işleminin kaydını tutar. Daha sonra kubectl rollout history komutu kullanılarak kaydedilen kayıtların listesi görüntülenebilir:
159 |
160 | ```shell
161 | kubectl rollout history deployment/my-deployment
162 | ```
163 |
164 | Bu komut, my-deployment Deployment'ının tarihçesini görüntüler. --revision seçeneği kullanılarak belirli bir kaydın detaylarına bakılabilir:
165 |
166 | ```shell
167 | kubectl rollout history deployment/my-deployment --revision=3
168 | ```
169 |
170 | Bu komut, my-deployment Deployment'ının 3. kaydının detaylarını görüntüler.
171 |
172 | ## Status Kullanımı
173 |
174 | Bu komutlar kullanıldığında, deployment üzerindeki güncelleme işleminin durumu kubectl rollout status komutu ile görüntülenebilir. Bu komut, deployment'in güncelleme işleminin ne durumda olduğunu gösterir ve güncelleme işlemi tamamlanana kadar bekleyebilirsiniz.
175 |
176 | Örnek olarak, aşağıdaki komut ile myapp-deployment deployment'inin güncelleme işlemi durdurulabilir:
177 |
178 | ```shell
179 | kubectl rollout pause deployment/myapp-deployment
180 | ```
181 |
182 | Daha sonra, güncelleme işlemi devam ettirilebilir:
183 |
184 | ```shell
185 | kubectl rollout resume deployment/myapp-deployment
186 | ```
187 |
188 | ## Pause ve Resume Kullanımı
189 |
190 | Kubernetes'te deployment üzerinde yapılan bir güncelleme işlemi sırasında, belirli bir noktada işlemleri durdurmak ve sonra devam ettirmek isteyebilirsiniz. Bu durumda rollout pause ve rollout resume komutları kullanılır.
191 |
192 | - **rollout pause:** Güncelleme işlemini durdurmak için kullanılır.
193 |
194 | Örneğin, aşağıdaki komut ile deployment üzerindeki güncelleme işlemini durdurabilirsiniz:
195 |
196 | ```shell
197 | kubectl rollout pause deployment/myapp-deployment
198 | ```
199 |
200 | - **rollout resume:** Güncelleme işlemini devam ettirmek için kullanılır.
201 |
202 | Örneğin, aşağıdaki komut ile deployment üzerindeki güncelleme işlemini devam ettirebilirsiniz:
203 |
204 | ```shell
205 | kubectl rollout resume deployment/myapp-deployment
206 | ```
207 |
208 | ## Dikkat Edilmesi Gerekenler
209 |
210 | 1. Deployment'ın yaml dosyasındaki strateji kısmı doğru belirlenmelidir. Bu, deployment'ın nasıl yayınlanacağını, kaç pod'un çalışacağını, eski pod'ların nasıl ele alınacağını vb. belirler.
211 | 2. Rollout işlemi sırasında, kubernetes objelerinde yapılan değişikliklerin doğru bir şekilde kontrol edilmesi önemlidir.
212 | 3. Rollout işlemi sırasında, yeni deployment versiyonuna geçerken kaynak tüketimi ve performans konuları göz önünde bulundurulmalıdır.
213 | 4. Rollout sırasında takip edilebilir bir strateji uygulamak için, kubectl gibi araçlar kullanarak rollout sırasında pod'ların ve deployment'ın durumunu takip etmek önemlidir.
214 | 5. Rollout sırasında, hata durumunda geri alma (rollback) işlemi için hazırlıklı olmak gerekir. Bu nedenle, deployment'ın eski versiyonlarına kolayca geri dönülebilmesi için geçmiş versiyonların saklanması önemlidir.
215 |
--------------------------------------------------------------------------------
/rollout-ve-rollback/uygulama1.yaml:
--------------------------------------------------------------------------------
1 | apiVersion: apps/v1
2 | kind: Deployment
3 | metadata:
4 | name: myapp-deployment
5 | labels:
6 | app: myapp
7 | spec:
8 | replicas: 3
9 | selector:
10 | matchLabels:
11 | app: myapp
12 | template:
13 | metadata:
14 | labels:
15 | app: myapp
16 | spec:
17 | containers:
18 | - name: myapp
19 | image: myapp:v1
20 | ports:
21 | - containerPort: 80
22 |
--------------------------------------------------------------------------------
/rollout-ve-rollback/uygulama2.yaml:
--------------------------------------------------------------------------------
1 | apiVersion: apps/v1
2 | kind: Deployment
3 | metadata:
4 | name: rcdeployment
5 | labels:
6 | team: development
7 | spec:
8 | replicas: 3
9 | selector:
10 | matchLabels:
11 | app: recreate
12 | strategy:
13 | type: Recreate # Recreate stratejisi burada tanımlanıyor
14 | template:
15 | metadata:
16 | labels:
17 | app: recreate
18 | spec:
19 | containers:
20 | - name: nginx
21 | image: nginx:1.20 # yeni bir sürüm tanımlanıyor
22 | ports:
23 | - containerPort: 80
24 |
--------------------------------------------------------------------------------
/rollout-ve-rollback/uygulama3.yaml:
--------------------------------------------------------------------------------
1 | apiVersion: apps/v1
2 | kind: Deployment
3 | metadata:
4 | name: nginx-deployment
5 | spec:
6 | replicas: 3
7 | selector:
8 | matchLabels:
9 | app: nginx
10 | template:
11 | metadata:
12 | labels:
13 | app: nginx
14 | spec:
15 | containers:
16 | - name: nginx
17 | image: nginx:1.19.3
18 | ports:
19 | - containerPort: 80
20 | terminationGracePeriodSeconds: 10
21 | strategy:
22 | type: RollingUpdate
23 | rollingUpdate:
24 | maxUnavailable: 1
25 | maxSurge: 1
26 |
--------------------------------------------------------------------------------
/service/Readme.md:
--------------------------------------------------------------------------------
1 | # Service
2 |
3 | ## Service Nedir?
4 |
5 | Kubernetes, containerized uygulamaları yönetmek ve dağıtmak için kullanılan bir açık kaynaklı sistemdir. Service, Kubernetes ortamında çalışan uygulamalar arasında ağ trafiği yönlendirmek için kullanılan bir objedir. Service, belirli bir IP adresi ve port numarasına sahiptir ve podlar gibi diğer Kubernetes objeleriyle birlikte çalışır.
6 |
7 | Bir örnek senaryo ile açıklamak gerekirse, diyelim ki bir e-ticaret uygulaması çalıştırıyorsunuz ve birden fazla podda çalışan bir web uygulamasına sahipsiniz. Bu podlar, uygulamanın farklı özellikleri için hizmet verirler, örneğin kullanıcı hesap sayfaları, ürün sayfaları ve ödeme işlemleri gibi. Her podun kendine ait IP adresi vardır ve podlar arasındaki trafiği yönlendirmek için Service objesi kullanılır.
8 |
9 | Service objesi, podların IP adreslerini dinler ve gelen istekleri doğru podlara yönlendirir. Örneğin, bir kullanıcının ürün sayfasını açmak istediğinde, tarayıcısı Service objesinin IP adresine istek gönderir ve Service objesi isteği doğru pod'a yönlendirir.
10 |
11 | Bu senaryoda Service objesi, web uygulamasının farklı özelliklerini tek bir IP adresi altında birleştirerek, uygulama kullanıcılarına kolay bir erişim sağlar. Ayrıca, yeni bir pod eklenirse veya bir pod kaldırılırsa, Service objesi bu değişiklikleri otomatik olarak algılayacak ve trafiği doğru şekilde yönlendirecektir.
12 |
13 | ## Uygulama
14 |
15 | Bir Kubernetes kümenizde üç adet Apache web sunucusu pod'u çalıştırıyorsunuz. Her pod farklı bir web sitesi için hizmet veriyor ve bir Service objesi kullanarak bu podların trafiğini yönlendirmek istiyorsunuz.
16 |
17 | İlk olarak, Service objesi için bir YAML dosyası oluşturmanız gerekiyor. Aşağıdaki örnek YAML dosyasını kullanabilirsiniz:
18 |
19 | ```yaml
20 | apiVersion: v1
21 | kind: Service
22 | metadata:
23 | name: web-service
24 | spec:
25 | selector:
26 | app: apache
27 | ports:
28 | - name: http
29 | protocol: TCP
30 | port: 80
31 | targetPort: 80
32 | type: ClusterIP
33 | ```
34 |
35 | Bu YAML dosyası, web-service adında bir Service objesi tanımlar. selector özelliği, Service objesinin yönlendireceği podları belirler. Bu örnekte, app: apache etiketi olan podlar seçilir. ports özelliği, Service objesinin dinleyeceği portu belirler. Bu örnekte, HTTP trafiği için 80 numaralı port kullanılır. targetPort özelliği, Service objesinin istekleri yönlendireceği podların hedef portunu belirler. Bu örnekte, podların da 80 numaralı portu dinlediği varsayılmıştır. type özelliği, Service objesinin türünü belirler. Bu örnekte, ClusterIP kullanılır.
36 |
37 | YAML dosyanızı kaydettikten sonra, kubectl apply komutunu kullanarak Service objesini Kubernetes kümenize yükleyebilirsiniz:
38 |
39 | ```bash
40 | kubectl apply -f web-service.yaml
41 | ```
42 |
43 | Bu komut Service objesini yükler ve Kubernetes kümenizdeki tüm podlarla eşleşen app: apache etiketini arar.
44 |
45 | Artık Service objeniz hazır. Bir web tarayıcısı açarak Kubernetes kümenizin IP adresini veya DNS adını kullanarak Service objenize istek gönderebilirsiniz. Service objesi isteği doğru pod'a yönlendirecektir.
46 |
47 | Örneğin, http:/// adresine istek göndererek, Service objesi tarafından yönlendirilen bir Apache pod'unuzda çalışan bir web sitesi görebilirsiniz. Aynı şekilde, http:///site2 adresine istek göndererek, Service objesi tarafından yönlendirilen başka bir Apache pod'unuzda çalışan bir başka web sitesi görebilirsiniz.
48 |
49 | Bu örnekte Service objesi, farklı podların trafiğini tek bir IP adresi altında birleştirerek, uygulama kullanıcılarına kolay bir erişim sağlıyor. Ayrıca, yeni bir pod eklediğinizde veya bir pod kaldırdığınızda, Service objesi bu değişiklikleri otomatik olarak algılayacak ve trafiği doğru şekilde yönlendirecektir.
50 |
51 | ## Service Obje Türleri
52 |
53 | ### ClusterIP
54 |
55 | 
56 |
57 | ClusterIP, Kubernetes Service objelerinin varsayılan türüdür ve yalnızca Kubernetes cluster'ı içinde erişilebilir. Bu Service türü, pod'ları tek bir IP adresi altında gruplandırır ve belirli bir port numarası üzerinden erişilebilir hale getirir.
58 |
59 | Örneğin, bir web uygulaması çalıştırdığınızı ve web uygulamasının arkasında üç farklı pod olduğunu varsayalım. Bu pod'lar, uygulama sunucusu olarak hizmet vermektedir. ClusterIP Service objesi, bu pod'ları tek bir IP adresi altında gruplandırır ve belirli bir port numarası üzerinden erişilebilir hale getirir.
60 |
61 | Aşağıdaki YAML belgesi, bir ClusterIP Service objesi oluşturmak için kullanılabilir:
62 |
63 | ```yaml
64 | apiVersion: v1
65 | kind: Service
66 | metadata:
67 | name: my-webapp-service
68 | spec:
69 | selector:
70 | app: my-webapp
71 | ports:
72 | - name: http
73 | protocol: TCP
74 | port: 80
75 | targetPort: 8080
76 | ```
77 |
78 | Bu Service objesi, my-webapp adlı pod'ları hedef alır ve 80 numaralı bir porttan erişilebilir hale getirir. Service objesi, hedef pod'ların 8080 numaralı portuna yönlendirir.
79 |
80 | Bu ClusterIP Service objesi, diğer pod'lar veya servisler tarafından kolayca erişilebilir hale getirir. Örneğin, bir başka pod, bu Service objesi üzerinden web uygulamasına erişmek istediğinde, my-webapp-service adını kullanarak erişebilir. Bu, web uygulamasının, Service objesi aracılığıyla diğer pod'lar veya hizmetlerle haberleşebileceği anlamına gelir.
81 |
82 | ### NodePort
83 |
84 | 
85 |
86 | NodePort, Kubernetes'teki Service objelerinden biridir ve cluster içindeki herhangi bir node üzerinde özel bir port numarası atar ve bu port numarası üzerinden Service objesine gelen tüm trafiği bu node'a yönlendirir. Bu, cluster dışındaki kaynakların, Service objesi tarafından yönlendirilen trafiğe erişmesini sağlar.
87 |
88 | Örneğin, bir web uygulaması çalıştırdığınızı ve web uygulamasının arkasında üç farklı pod olduğunu varsayalım. Bu pod'lar, uygulama sunucusu olarak hizmet vermektedir. NodePort Service objesi, bu pod'ları tek bir IP adresi altında gruplandırır ve belirli bir port numarası üzerinden erişilebilir hale getirir. Ayrıca, bu Service objesi, her node'a özel bir port numarası atayarak, cluster dışındaki kaynakların bu node'a erişmesine izin verir.
89 |
90 | Aşağıdaki YAML belgesi, bir NodePort Service objesi oluşturmak için kullanılabilir:
91 |
92 | ```yaml
93 | apiVersion: v1
94 | kind: Service
95 | metadata:
96 | name: my-webapp-service
97 | spec:
98 | selector:
99 | app: my-webapp
100 | type: NodePort
101 | ports:
102 | - name: http
103 | protocol: TCP
104 | port: 80
105 | targetPort: 8080
106 | ```
107 |
108 | Bu YAML belgesi, my-webapp-service adlı bir NodePort Service objesi oluşturur. Bu Service objesi, my-webapp adlı pod'ları hedef alır ve 80 numaralı bir porttan erişilebilir hale getirir. Service objesi, hedef pod'ların 8080 numaralı portuna yönlendirir ve her bir node üzerinde rastgele bir port numarası atar.
109 |
110 | Bu NodePort Service objesi, her node üzerinde atanan port numarası üzerinden, cluster dışındaki kaynaklar tarafından da erişilebilir hale getirilir. Örneğin, bir kullanıcı, node_ip:node_port şeklindeki bir URL ile web uygulamasına erişebilir. Bu, web uygulamasının, NodePort Service objesi aracılığıyla cluster dışındaki kaynaklarla haberleşebileceği anlamına gelir.
111 |
112 | > ClusterIP Service objesi, pod'lar arasındaki iletişimi kolaylaştırmak için kullanılırken, NodePort Service objesi, uygulama servislerinin cluster dışından erişilebilir hale getirilmesi için kullanılır.
113 |
114 | ### LoadBalancer
115 |
116 | 
117 |
118 | LoadBalancer, cloud ortamındaki sağlayıcının yönettiği bir yük dengeleyici oluşturur ve uygulama servislerini yük dengeleyici üzerinden dış dünyaya açar.
119 |
120 | Örneğin, bir web uygulaması çalıştırdığınızı ve bu web uygulamasının arkasında üç farklı pod olduğunu varsayalım. Bu pod'lar, uygulama sunucusu olarak hizmet vermektedir. LoadBalancer Service objesi, bu pod'ları tek bir IP adresi altında gruplandırır ve belirli bir port numarası üzerinden erişilebilir hale getirir. Ayrıca, cloud sağlayıcısı tarafından yönetilen bir yük dengeleyici oluşturur ve uygulama servislerini yük dengeleyici üzerinden dış dünyaya açar.
121 |
122 | Aşağıdaki YAML belgesi, bir LoadBalancer Service objesi oluşturmak için kullanılabilir:
123 |
124 | ```yaml
125 | apiVersion: v1
126 | kind: Service
127 | metadata:
128 | name: my-webapp-service
129 | spec:
130 | selector:
131 | app: my-webapp
132 | type: LoadBalancer
133 | ports:
134 | - name: http
135 | protocol: TCP
136 | port: 80
137 | targetPort: 8080
138 | ```
139 |
140 | Bu YAML belgesi, my-webapp-service adlı bir LoadBalancer Service objesi oluşturur. Bu Service objesi, my-webapp adlı pod'ları hedef alır ve 80 numaralı bir porttan erişilebilir hale getirir. Service objesi, hedef pod'ların 8080 numaralı portuna yönlendirir ve cloud sağlayıcısı tarafından yönetilen bir yük dengeleyici oluşturur.
141 |
142 | Bu LoadBalancer Service objesi, cloud sağlayıcısı tarafından yönetilen yük dengeleyici üzerinden dış dünyaya açılabilir hale getirilir. Bu sayede, uygulama servisleri, dış dünyadan gelen isteklere karşılık verebilir hale gelir. Cloud sağlayıcısı, LoadBalancer Service objesi için özel bir IP adresi atar ve uygulama servisleri bu IP adresi üzerinden erişilebilir hale gelir.
143 |
144 | ### ExternalName
145 |
146 | Uygulama servislerine DNS adları üzerinden erişmek için kullanılır. ExternalName Service objesi, cluster içinde bir DNS ismi olarak erişilebilen, farklı bir dış DNS adıyla eşleştirilir.
147 |
148 | Örneğin, bir web uygulaması çalıştırdığınızı ve bu web uygulamasına erişmek için bir DNS adı kullanmak istediğinizi varsayalım. Ancak, web uygulaması bir başka cloud ortamındaki kaynakta çalışıyor ve erişilebilirliği sağlamak için bir DNS adı kullanıyor. ExternalName Service objesi, bu senaryoda kullanılabilir.
149 |
150 | Aşağıdaki YAML belgesi, bir ExternalName Service objesi oluşturmak için kullanılabilir:
151 |
152 | ```yaml
153 | apiVersion: v1
154 | kind: Service
155 | metadata:
156 | name: my-webapp-service
157 | spec:
158 | type: ExternalName
159 | externalName: my-webapp.example.com
160 | ```
161 |
162 | Bu YAML belgesi, my-webapp-service adlı bir ExternalName Service objesi oluşturur. Bu Service objesi, cluster içinde my-webapp.example.com DNS adı olarak erişilebilir hale getirir. Bu DNS adı, dış dünyadaki bir web uygulamasına yönlendirilir ve uygulamaya erişmek için kullanılabilir.
163 |
164 | Bu ExternalName Service objesi, cluster içinde DNS adı olarak kullanılabilir hale gelir. Bu sayede, diğer pod'lar, bu Service objesini hedefleyerek, my-webapp.example.com DNS adı üzerinden uygulamaya erişebilirler. Bu erişim, ExternalName Service objesi tarafından yönlendirilerek, dış dünyadaki uygulamaya yönlendirilir.
165 |
166 | ## Dikkat Edilmesi Gerekenler
167 |
168 | - Pod ve Service objeleri arasındaki etiketleme tutarlılığına dikkat edin. Service objesi, etiketlerle belirlenen podları yönlendirecektir, bu nedenle Service ve pod etiketlerinin örtüşmesi gerekir.
169 | - Service objesi türünü doğru şekilde belirleyin. ClusterIP, NodePort, LoadBalancer veya ExternalName türleri mevcuttur ve her birinin farklı kullanım durumları vardır. Bu nedenle, ihtiyacınıza en uygun olan Service türünü belirlemeniz önemlidir.
170 | - Hedef podların sağlığını kontrol edin. Service objesi, yönlendirdiği podların sağlığını kontrol etmez. Bu nedenle, hedef podlarının sağlığını kontrol eden bir readinessProbe veya livenessProbe belirlemek önemlidir.
171 | - Service objesi konfigürasyonunu güncellediğinizde, podların otomatik olarak yeniden başlatılmayacağına dikkat edin. Bu nedenle, Service objesi konfigürasyonunu değiştirdiğinizde, ilgili podları da manuel olarak yeniden başlatmanız gerekebilir.
172 | - Service objelerinin trafik yönlendirmesi için kullanılan portları iyi bir şekilde belirleyin. Service objelerinin, diğer podlar veya hizmetler ile çakışmadığından emin olmak için benzersiz bir port numarası kullanın.
173 |
--------------------------------------------------------------------------------
/statefulset/Readme.md:
--------------------------------------------------------------------------------
1 | # StatefulSet
2 |
3 | StatefulSet, Kubernetes kümelerinde durumsal (stateful) uygulamaların yönetimi için kullanılan bir kaynak türüdür. Durumsal uygulamalar, her bir örneğin benzersiz bir kimliği veya durumu olan uygulamalardır.
4 |
5 | StatefulSet, ölçeklenebilir ve sıralı dağıtım gerektiren uygulamaların yönetimi için tasarlanmıştır. Örneğin, veritabanı sunucuları veya mesaj sıraları gibi uygulamalar, durumsal uygulama örnekleri olarak kabul edilebilir.
6 |
7 | **StatefulSet, aşağıdaki avantajları sağlar:**
8 |
9 | - **Sabit Kimlik:** Her bir durumsal uygulama örneği (Pod), benzersiz bir kimlik veya isimle tanımlanır. Bu, uygulamanın verileri ve durumu için tutarlılık sağlar.
10 | - **Sıralı Dağıtım:** StatefulSet, uygulama örneklerini belirli bir sıra veya düzen içinde dağıtmak için kullanılabilir. Bu, uygulamanın başlatma, yeniden başlatma veya ölçeklendirme gibi işlemlerinde sıralı ve öngörülebilir davranış sağlar.
11 | - **Stable Network Identity:** Her bir durumsal uygulama örneği, istikrarlı bir ağ kimliğine sahiptir. Bu, diğer uygulamaların ve servislerin uygulamaya güvenli bir şekilde bağlanabilmesini sağlar.
12 | - **Stable Storage:** StatefulSet, her bir durumsal uygulama örneği için kalıcı depolama alanının korunmasını sağlar. Bu, verilerin güvenli bir şekilde saklanmasını ve uygulama örneklerinin verilere erişimini sürdürebilmesini sağlar.
13 |
14 | **StatefulSet, birkaç ana bileşenden oluşur:**
15 |
16 | - **Pod:** Durumsal uygulama örneklerinin çalıştığı temel birimdir.
17 | - **Headless Service:** Durumsal uygulama örneklerine istikrarlı bir ağ kimliği sağlar.
18 | - **Volume Claim Templates:** Her bir durumsal uygulama örneği için kalıcı depolama taleplerini tanımlar.
19 | - **StatefulSet Controller:** Durumsal uygulama örneklerini yönetir ve istenen duruma ulaşmak için gerektiğinde yeni örnekler oluşturur veya var olanları yeniden başlatır.
20 |
21 | **StatefulSet kullanırken dikkate almanız gereken bazı önemli noktalar vardır:**
22 |
23 | - **Podların Benzersiz Kimlikleri:** Her bir durumsal uygulama örneği benzersiz bir kimliğe sahiptir. Bu, uygulama örneklerinin farklı düğümlere veya dağıtım zamanlarında yeniden başlatıldığında aynı veriler ve durumla devam edebilmesini sağlar.
24 | - **Stable Network Identity ve Servisler:** StatefulSet, uygulama örneklerine istikrarlı bir ağ kimliği sağlar. Diğer Kubernetes servisleri veya uygulamaları, bu istikrarlı kimlikleri kullanarak durumsal uygulama örneklerine güvenli bir şekilde erişebilir.
25 | - **Kalıcı Depolama:** Durumsal uygulama örnekleri genellikle kalıcı verileri saklar. Bu nedenle, StatefulSet kullanırken kalıcı depolama taleplerini doğru şekilde yapılandırmalı ve uygun depolama sağlayıcısını seçmelisiniz.
26 | - **Yeniden Başlatma ve Ölçeklendirme:** Durumsal uygulama örneklerini yeniden başlatırken veya ölçeklendirirken, sıralı ve koordineli bir şekilde yapmanız önemlidir. Bu, uygulamanın tutarlılığını ve verilerin bütünlüğünü korumaya yardımcı olur.
27 |
28 | ## Deployment vs StatefulSet
29 |
30 | **Uygulama Yönetimi:**
31 |
32 | - **Deployment**: Deployment, tipik olarak durumsuz (stateless) uygulamaların yönetimi için kullanılır. Bu tür uygulamalar genellikle paylaşılan verilere veya sabit duruma ihtiyaç duymazlar.
33 | - **StatefulSet:** StatefulSet, durumsal (stateful) uygulamaların yönetimi için kullanılır. Bu tür uygulamalar, her bir örneğin benzersiz bir kimliğe, istikrarlı bir ağ kimliğine ve kalıcı depolamaya ihtiyaç duyarlar.
34 |
35 | **Örnekleme ve Kimliklendirme:**
36 |
37 | - **Deployment:** Deployment, örnekleme için otomatik olarak benzersiz bir kimlik atar ve her örnek için farklı bir IP adresi alabilir. Örneğin, yük dengeleyici önünde çalışan bir örnekleme grubu oluşturulabilir.
38 | - **StatefulSet:** StatefulSet, her bir örneğe benzersiz bir kimlik atar ve istikrarlı bir ağ kimliği sağlar. Örneğin, veritabanı sunucuları gibi durumsal uygulama örnekleri, her biri kendi kimliğiyle erişilebilir ve özel ağ bağlantılarına sahip olabilir.
39 |
40 | **Depolama ve Veri Saklama:**
41 |
42 | - **Deployment:** Deployment'lar genellikle geçici (ephemeral) depolama kullanır. Herhangi bir örnek yeniden oluşturulduğunda veya ölçeklendirildiğinde veriler kaybedilebilir.
43 | - **StatefulSet:** StatefulSet'ler, kalıcı depolama talepleriyle kullanılır. Her bir örnek, benzersiz bir veritabanı veya dosya sistemi gibi kalıcı verileri korumak için ayrı bir depolama alanına sahip olabilir.
44 |
45 | **Ölçeklendirme ve Güncelleme:**
46 |
47 | - **Deployment:** Deployment'lar, yatay ölçeklendirme (scale-out) için uygundur. Uygulama örnekleri, yük dengeleyici ile dağıtılarak isteğe bağlı olarak artırılabilir veya azaltılabilir. Güncelleme sırasında eski örnekler kaldırılır ve yeni örnekler eklenir.
48 | - **StatefulSet:** StatefulSet'ler, dikey ölçeklendirme (scale-up) için uygundur. Her bir örneğin ayrı bir kimliği olduğundan, ölçeklendirme işlemleri genellikle el ile yapılır. Güncellemeler sırasında, eski örneklerin sırayla kaldırılması ve yeni örneklerin eklenmesi gerekebilir.
49 |
50 | ## Uygulama
51 |
52 | ### Adım 1: Headless Service Oluşturma
53 |
54 | Öncelikle, StatefulSet için bir Headless Service (istikrarlı hizmet) oluşturmanız gerekmektedir. Bu hizmet, her bir durumsal uygulama örneğine istikrarlı bir ağ kimliği sağlayacaktır:
55 |
56 | ```yaml
57 | apiVersion: v1
58 | kind: Service
59 | metadata:
60 | name: my-app-service
61 | labels:
62 | app: my-app
63 | spec:
64 | clusterIP: None
65 | selector:
66 | app: my-app
67 | ```
68 |
69 | Bu YAML dosyası, "my-app-service" adında bir Headless Service oluşturur. "my-app" etiketine sahip durumsal uygulama örneklerine istikrarlı bir ağ kimliği sağlar.
70 |
71 | ### Adım 2: StatefulSet Oluşturma
72 |
73 | Sonraki adımda, StatefulSet'i oluşturmanız gerekmektedir:
74 |
75 | ```yaml
76 | apiVersion: apps/v1
77 | kind: StatefulSet
78 | metadata:
79 | name: my-app-statefulset
80 | spec:
81 | selector:
82 | matchLabels:
83 | app: my-app
84 | serviceName: my-app-service
85 | replicas: 3
86 | template:
87 | metadata:
88 | labels:
89 | app: my-app
90 | spec:
91 | containers:
92 | - name: my-app-container
93 | image: my-app-image
94 | ports:
95 | - containerPort: 8080
96 | volumeClaimTemplates:
97 | - metadata:
98 | name: data
99 | spec:
100 | accessModes: ['ReadWriteOnce']
101 | resources:
102 | requests:
103 | storage: 1Gi
104 | ```
105 |
106 | Bu YAML dosyası, "my-app-statefulset" adında bir StatefulSet oluşturur. "my-app" etiketine sahip durumsal uygulama örneklerini seçer. "my-app-service" adlı Headless Service'i kullanır. Replica sayısını 3 olarak belirtir. Her bir durumsal uygulama örneği için "my-app-container" adında bir konteyner oluşturur. Ayrıca, her bir uygulama örneği için "data" adında bir volume talebi tanımlar.
107 |
108 | ### Adım 3: StatefulSet'i Kubernetes Kümelerine Uygulama
109 |
110 | StatefulSet YAML dosyasını kullanarak StatefulSet'i Kubernetes kümelerine uygulamak için aşağıdaki komutu kullanabilirsiniz:
111 |
112 | ```shell
113 | kubectl apply -f statefulset.yaml
114 | ```
115 |
116 | Bu komut, statefulset.yaml dosyasını kullanarak StatefulSet'i Kubernetes kümelerine uygular.
117 |
118 | ### Adım 4: StatefulSet Durumunu Kontrol Etme
119 |
120 | StatefulSet'in başarıyla oluşturulduğunu ve çalıştığını kontrol etmek için aşağıdaki komutu kullanabilirsiniz:
121 |
122 | ```yaml
123 | kubectl get statefulset
124 | ```
125 |
126 | Bu komut, mevcut StatefulSet'leri listeler ve durumunu gösterir. "my-app-statefulset" adında bir StatefulSet listelenmeli ve durumu "Running" olarak görünmelidir.
127 |
128 | ### Adım 5: Durumsal Uygulama Örneklerini Kontrol Etme
129 |
130 | Durumsal uygulama örneklerinin başarıyla oluşturulduğunu ve çalıştığını kontrol etmek için aşağıdaki komutu kullanabilirsiniz:
131 |
132 | ```yaml
133 | kubectl get pods
134 | ```
135 |
136 | Bu komut, mevcut Pod'ları listeler ve durumlarını gösterir. "my-app-statefulset-" ile başlayan adlara sahip 3 adet Pod listelenmeli ve durumları "Running" olarak görünmelidir.
137 |
--------------------------------------------------------------------------------
/storage-class/Readme.md:
--------------------------------------------------------------------------------
1 | # Storage Class
2 |
3 | Storage Class, Kubernetes kümelerinde veri depolama kaynaklarını yönetmek için kullanılan bir mekanizmadır. Bu mekanizma, farklı depolama gereksinimlerine sahip uygulamaları desteklemek için esneklik sağlar.
4 |
5 | Storage Class, depolama sağlayıcılarına (örneğin, bulut tabanlı depolama servisleri veya yerel depolama sistemleri gibi) özgü depolama seçeneklerini Kubernetes üzerinde tanımlamak için kullanılır. Depolama kaynaklarının türünü, erişim modunu, boyutunu ve diğer özelliklerini belirlemek için kullanılan bir YAML dosyasıyla yapılandırılır.
6 |
7 | Bu yapılandırma, Kubernetes kullanıcılarına depolama taleplerini kolayca tanımlama ve kullanma imkanı sağlar. Bir kullanıcı bir PVC (Persistent Volume Claim) talebinde bulunduğunda, bu talep, ilgili Storage Class tarafından belirtilen depolama kaynağına eşlenir ve bir PVC oluşturulur. PVC, uygulamanın kullanabileceği kalıcı depolama alanını temsil eder.
8 |
9 | Storage Class'lar ayrıca depolama kaynaklarının dinamik olarak oluşturulmasını da destekler. Bir PVC talep edildiğinde, Storage Class, mevcut depolama kaynaklarını kontrol eder ve uygun olan bir depolama alanını otomatik olarak oluşturur.
10 |
11 | Bu şekilde, Storage Class kullanarak, farklı depolama gereksinimlerine sahip uygulamalar için esnek depolama çözümleri oluşturabilirsiniz. Ayrıca, depolama kaynaklarının dinamik olarak yönetilmesini sağlayarak, kullanıcıların depolama taleplerini daha kolay bir şekilde karşılayabilirsiniz.
12 |
13 | ## Uygulama
14 |
15 | ### Adım 1: Storage Class Oluşturma
16 |
17 | İlk adımda, bir Storage Class oluşturmanız gerekmektedir. Örnek olarak aşağıdaki YAML dosyasını kullanabilirsiniz:
18 |
19 | ```yaml
20 | apiVersion: storage.k8s.io/v1
21 | kind: StorageClass
22 | metadata:
23 | name: fast-storage
24 | provisioner: example.com/fast-storage
25 | parameters:
26 | type: ssd
27 | ```
28 |
29 | Bu YAML dosyası, "fast-storage" adında bir Storage Class oluşturur. "example.com/fast-storage" adlı bir provizyoner kullanılarak depolama alanı sağlanır ve "type: ssd" parametresi, SSD tabanlı bir depolama çözümünü belirtir.
30 |
31 | ### Adım 2: Storage Class'ı Kubernetes Kümelerine Uygulama
32 |
33 | Oluşturduğunuz storageclass.yaml dosyasını kullanarak Storage Class'ı Kubernetes kümelerine uygulayabilirsiniz. Bunun için aşağıdaki komutu kullanabilirsiniz:
34 |
35 | ```shell
36 | kubectl apply -f storageclass.yaml
37 | ```
38 |
39 | Bu komut, storageclass.yaml dosyasını kullanarak Storage Class'ı Kubernetes kümelerine uygular.
40 |
41 | ### Adım 3: PVC (Persistent Volume Claim) Talebi Oluşturma
42 |
43 | Storage Class'ı kullanarak bir PVC talebi oluşturabilirsiniz. Örnek olarak aşağıdaki PVC YAML dosyasını kullanabilirsiniz:
44 |
45 | ```yaml
46 | apiVersion: v1
47 | kind: PersistentVolumeClaim
48 | metadata:
49 | name: my-pvc
50 | spec:
51 | storageClassName: fast-storage
52 | accessModes:
53 | - ReadWriteOnce
54 | resources:
55 | requests:
56 | storage: 5Gi
57 | ```
58 |
59 | Bu YAML dosyası, "my-pvc" adında bir PVC talebi oluşturur. "fast-storage" adlı Storage Class'ı kullanarak depolama alanı talep eder. Ayrıca, "ReadWriteOnce" erişim modunu ve 5GB boyutunda bir depolama talebini belirtir.
60 |
61 | ### Adım 4: PVC'yi Kubernetes Kümelerine Uygulama
62 |
63 | PVC talebini oluşturduktan sonra, aşağıdaki komutu kullanarak PVC'yi Kubernetes kümelerine uygulayabilirsiniz:
64 |
65 | ```shell
66 | kubectl apply -f pvc.yaml
67 | ```
68 |
69 | ### Adım 5: PVC Durumunu Kontrol Etme
70 |
71 | PVC'nin başarıyla oluşturulup oluşturulmadığını kontrol etmek için aşağıdaki komutu kullanabilirsiniz:
72 |
73 | ```shell
74 | kubectl get pvc
75 | ```
76 |
77 | Bu komut, mevcut PVC'leri listeler ve durumunu gösterir. "my-pvc" adında bir PVC listelenmeli ve durumu "Bound" olarak görünmelidir, bu da PVC'nin başarıyla bir depolama alanına bağlandığını gösterir.
78 |
--------------------------------------------------------------------------------
/taint-ve-tolerations/Readme.md:
--------------------------------------------------------------------------------
1 | # Taint ve Tolerations
2 |
3 | Kubernetes Taints ve Tolerations, Kubernetes cluster'ındaki node'lar ve pod'lar arasındaki ilişkiyi belirleyen bir mekanizmadır.
4 |
5 | Taint, bir node üzerinde çalışan pod'ların kabul edilmesini engelleyen bir işaretçidir. Tolerations ise, pod'ların belirli bir Taint'e sahip node'lar üzerinde çalışmasını sağlayan bir yöntemdir.
6 |
7 | Bir node'a Taint eklemek, o node üzerinde çalışan pod'ların sadece belirli tolerasyonlara sahip pod'lar tarafından çalıştırılmasını sağlar. Taints, özellikle belirli bir node'un sadece belirli pod'lar tarafından kullanılmasını gerektiği durumlarda kullanılır. Örneğin, bir node üzerinde özel bir donanım özelliği bulunuyorsa ve bu donanım özelliği yalnızca belirli pod'lar tarafından kullanılabilirse, bu durumda Taints kullanılabilir.
8 |
9 | Tolerations ise, pod'ların belirli bir Taint'e sahip node'lar üzerinde çalışmasını sağlar. Pod'lara toleration ekleyerek, belirli bir Taint'e sahip node'lar üzerinde çalışmalarını sağlayabiliriz. Bu, özellikle pod'ların belirli bir node üzerinde çalışması gerektiği durumlarda kullanılır.
10 |
11 | Taints ve Tolerations, Kubernetes cluster'ında pod'ların doğru şekilde planlanmasına yardımcı olur. Özellikle büyük ölçekli uygulamaların Kubernetes üzerinde çalıştırıldığı durumlarda, Taints ve Tolerations kullanarak pod'ların doğru şekilde planlanması oldukça önemlidir.
12 |
13 | Aşağıda, bir node'a Taint eklemek ve bir pod'a tolerasyon eklemek için kullanılan YAML örnekleri gösterilmiştir:
14 |
15 | Taint ekleme örneği:
16 |
17 | ```bash
18 | kubectl taint nodes node1 app=web:NoSchedule
19 | ```
20 |
21 | Bu örnekte, "node1" adlı bir node'a "app=web" adlı bir Taint ekleniyor. Bu Taint, "NoSchedule" durumu ile belirtiliyor. Bu, node üzerinde çalışan pod'ların sadece belirli tolerasyonlara sahip pod'lar tarafından çalıştırılmasını sağlar.
22 |
23 | Tolerasyon ekleme örneği:
24 |
25 | ```yaml
26 | apiVersion: v1
27 | kind: Pod
28 | metadata:
29 | name: my-pod
30 | spec:
31 | containers:
32 | - name: my-container
33 | image: my-image
34 | tolerations:
35 | - key: 'app'
36 | operator: 'Equal'
37 | value: 'web'
38 | effect: 'NoSchedule'
39 | ```
40 |
41 | Bu örnekte, "my-pod" adında bir pod oluşturuluyor. Pod, "my-image" adlı bir konteyneri çalıştırıyor. Pod'a tolerasyon eklemek için "tolerations" bölümü kullanılıyor. Bu örnekte, "app=web" adlı bir Taint'e tolerasyon ekleniyor. Bu, pod'ların belirli bir node üzerinde çalışmasını sağlar.
42 |
43 | ## Dikkat Edilmesi Gerekenler
44 |
45 | - **Güvenlik:** Taints ve Tolerations, Kubernetes cluster'ındaki pod'ların doğru şekilde planlanmasına yardımcı olur. Ancak, Taints ve Tolerations kullanırken güvenlik konusuna dikkat edilmelidir. Özellikle, Taints ve Tolerations kullanarak pod'ların belirli bir node üzerinde çalışmasını sağladığımızda, bu node üzerindeki diğer pod'ların etkilenebileceğini unutmamalıyız.
46 | - **Verimlilik:** Taints ve Tolerations, pod'ların doğru şekilde planlanmasına yardımcı olur. Ancak, doğru şekilde yapılandırılmazsa, pod'ların performans sorunlarına neden olabilir. Bu nedenle, Taints ve Tolerations kullanımının verimliliğini artırmak için doğru şekilde yapılandırılması önemlidir.
47 | - **Karmaşıklık:** Taints ve Tolerations, Kubernetes cluster'ındaki pod'ların doğru şekilde planlanmasına yardımcı olur. Ancak, Taints ve Tolerations kullanımı, Kubernetes cluster'ını daha karmaşık hale getirebilir. Bu nedenle, Taints ve Tolerations kullanırken, cluster'ın karmaşıklığını kontrol altında tutmak önemlidir.
48 |
--------------------------------------------------------------------------------
/volume/Readme.md:
--------------------------------------------------------------------------------
1 | # Volume
2 |
3 | ## Kubernetes Volume nedir?
4 |
5 | Kubernetes Volume, Kubernetes podları içinde kullanılan veri depolama birimleridir. Bir Kubernetes podu, bir veya daha fazla konteyneri içerebilir ve bu konteynerler arasında veri paylaşımı gerektiğinde, bir pod seviyesinde bir depolama birimi kullanılması gerekmektedir.
6 |
7 | Kubernetes Volume, bir pod içindeki konteynerler arasında veri paylaşımını sağlamak için kullanılan bir Kubernetes kaynağıdır. Bu depolama birimi, podun yaşam döngüsü boyunca kullanılabilir ve verilerin silinmesi, depolanması ve geri yüklenmesi işlemlerini otomatik olarak yönetir.
8 |
9 | Kubernetes Volume'lerinin birçok türü vardır, bunlar arasında Azure Disk, Amazon EBS, NFS, iSCSI, ConfigMap, Secret ve EmptyDir gibi seçenekler bulunur. Podlarda kullanılan Volume'ler, podlar oluşturulurken veya güncellenirken tanımlanabilir ve kullanılan depolama kaynağına göre yapılandırılabilir.
10 |
11 | Kubernetes Volume'lerinin avantajları arasında, veri paylaşımını kolaylaştırması, veri kaybını önlemesi ve podların bağımsızlığını artırması yer alır. Dezavantajları ise, disk alanı tüketebilmesi, veri depolama maliyetlerini artırması ve hata ayıklama işlemlerini zorlaştırması olabilir.
12 |
13 | ## Volume Tipleri
14 |
15 | - EmptyDir
16 | - HostPath
17 | - GitRepo
18 | - ConfigMap
19 | - Secret
20 |
21 | ## EmptyDir
22 |
23 | emptyDir, Kubernetes'te kullanılan bir volume tipidir ve geçici verilerin depolanması için kullanılır. Bu volume türü, bir pod çalıştırıldığında oluşturulur ve bu pod silindiğinde de otomatik olarak temizlenir.
24 |
25 | Bir emptyDir volume'ü oluşturduktan sonra, pod'ların içinde çalışan tüm container'lar bu volume'e erişebilirler. Bu, bir pod'daki container'ların birbirleriyle geçici bir şekilde veri paylaşmasına izin verir. emptyDir volume'ü, özellikle bir pod'da birden fazla container kullanıldığında, container'lar arasında geçici bir veri paylaşımı gerektiğinde veya pod'un bir sonraki aşamasında kullanmak üzere geçici bir depolama alanına ihtiyaç duyulduğunda kullanışlı olabilir.
26 |
27 | Ancak, emptyDir volume'leri pod silindiğinde tamamen silinir, bu nedenle verilerin kalıcı olması gerekiyorsa başka bir volume türü kullanmak gerekmektedir.
28 |
29 | Aşağıdaki YAML konfigürasyon örneğinde, emptyDir adında bir Volume oluşturuluyor ve web adındaki Pod'a bağlanıyor:
30 |
31 | ```yaml
32 | apiVersion: v1
33 | kind: Pod
34 | metadata:
35 | name: web
36 | spec:
37 | containers:
38 | - name: nginx
39 | image: nginx
40 | volumeMounts:
41 | - name: cache-volume
42 | mountPath: /cache
43 | volumes:
44 | - name: cache-volume
45 | emptyDir: {}
46 | ```
47 |
48 | Yukarıdaki örnekte, emptyDir Volume'unun ismi cache-volume olarak belirtiliyor. Pod'un içindeki nginx konteynerinde /cache dizinine bağlanıyor. Bu sayede Pod içindeki konteynerler arasında geçici veri saklamak için kullanılabilir.
49 |
50 | ## HostPath
51 |
52 | hostPath, Kubernetes cluster'ındaki bir node'un dosya sistemi yolunu bir volume olarak kullanmamızı sağlayan bir volume tipidir. Böylece pod'lar doğrudan host makinanın dosya sistemi ile iletişim kurabilir.
53 |
54 | Bu volume tipi, genellikle test, geliştirme veya single-node cluster'ların oluşturulmasında kullanılır. Ancak, multi-node cluster'larında hostPath kullanmak, yüksek kullanılabilirlik ve ölçeklenebilirlik açısından önerilmez.
55 |
56 | ```yaml
57 | apiVersion: v1
58 | kind: Pod
59 | metadata:
60 | name: mypod
61 | spec:
62 | containers:
63 | - name: mycontainer
64 | image: myimage
65 | volumeMounts:
66 | - name: myvolume
67 | mountPath: /mnt/mydata
68 | volumes:
69 | - name: myvolume
70 | hostPath:
71 | path: /var/data
72 | type: Directory
73 | ```
74 |
75 | Yukarıdaki örnekte, mypod adlı pod, /var/data dizinini mycontainer adlı container'da /mnt/mydata mount point'inde kullanır. Bu, host makinanın /var/data dizinindeki tüm dosyaların, mypod pod'unda /mnt/mydata altında kullanılabileceği anlamına gelir.
76 |
77 | ## GitRepo
78 |
79 | GitRepo, bir Git deposundan alınan bir kaynak kodunu Kubernetes pod'una bir volume olarak eklemek için kullanılan bir tipdir. GitRepo volume tipi, bir depo adı, bir branch veya tag adı, bir volume adı ve kullanılacak Git depo kimlik bilgileri gibi birkaç parametre gerektirir. Bu volume tipi, özellikle bir uygulamanın bir Git deposundan alınan kaynak kodunu kullanarak çalıştırılması gerektiğinde yararlıdır.
80 |
81 | Örnek olarak, aşağıdaki YAML, bir Git deposundan bir kaynak kodu alarak bir volume oluşturur ve bu volume'u bir Pod'a bağlar:
82 |
83 | ```yaml
84 | apiVersion: v1
85 | kind: Pod
86 | metadata:
87 | name: my-pod
88 | spec:
89 | containers:
90 | - name: my-container
91 | image: my-image
92 | volumeMounts:
93 | - name: git-volume
94 | mountPath: /my-app
95 | volumes:
96 | - name: git-volume
97 | gitRepo:
98 | repository: https://github.com/my-user/my-repo
99 | revision: master
100 | directory: my-app
101 | ```
102 |
103 | Yukarıdaki örnekte, gitRepo volume tipi kullanılarak my-user/my-repo deposundan master dalındaki my-app dizinindeki kaynak kodu alınır. Bu kaynak kodu, my-pod adlı Pod'da /my-app dizinine bağlanan git-volume adlı bir volume'a eklenir. Bu sayede, my-container adlı konteyner, /my-app dizinindeki kaynak kodunu kullanabilir.
104 |
105 | ## ConfigMap
106 |
107 | Kubernetes'te configMap bir yapılandırma ayarlarını depolamak için kullanılan bir objedir. Bir configMap nesnesi, podların kullanabileceği birden çok yapılandırma ayarını depolayabilir. Her bir ayar, bir anahtar-değer çifti olarak depolanır. configMap ile depolanan ayarlar, env, arg veya bir dosya olarak kullanılabilir.
108 |
109 | Örneğin, bir uygulamanız var ve farklı ortamlarda (geliştirme, test ve prod) kullanmak üzere ayarlarınız var. Bu ayarları her ortam için farklı bir şekilde saklamanız gerekiyor. configMap'leri kullanarak, bu ayarları her ortam için farklı bir configMap objesi olarak depolayabilirsiniz.
110 |
111 | Örneğin, aşağıdaki gibi bir configMap objesi tanımlayabilirsiniz:
112 |
113 | ```yaml
114 | apiVersion: v1
115 | kind: ConfigMap
116 | metadata:
117 | name: app-config
118 | data:
119 | DB_HOST: db.example.com
120 | DB_PORT: '5432'
121 | API_URL: http://api.example.com
122 | ```
123 |
124 | Bu örnekte, app-config adlı bir configMap objesi oluşturulur. DB_HOST, DB_PORT ve API_URL gibi anahtar-değer çiftleri, farklı ortamlarda kullanılmak üzere ayarlar olarak tanımlanır.
125 |
126 | Daha sonra, bu configMap objesi podlarda kullanılabilir. Örneğin, aşağıdaki gibi bir pod tanımı kullanarak configMap objesindeki ayarları env olarak kullanabilirsiniz:
127 |
128 | ```yaml
129 | apiVersion: v1
130 | kind: Pod
131 | metadata:
132 | name: my-pod
133 | spec:
134 | containers:
135 | - name: my-app
136 | image: my-image
137 | env:
138 | - name: DB_HOST
139 | valueFrom:
140 | configMapKeyRef:
141 | name: app-config
142 | key: DB_HOST
143 | - name: DB_PORT
144 | valueFrom:
145 | configMapKeyRef:
146 | name: app-config
147 | key: DB_PORT
148 | - name: API_URL
149 | valueFrom:
150 | configMapKeyRef:
151 | name: app-config
152 | key: API_URL
153 | ```
154 |
155 | Bu örnekte, my-pod adlı bir pod tanımlanır ve app-config adlı configMap objesi kullanılarak pod içindeki konteynerlerin env değişkenleri ayarlanır. configMapKeyRef özelliği, configMap objesindeki ayarların nasıl alınacağını belirtir.
156 |
157 | ## Secret
158 |
159 | Kubernetes'de Secret Volume, verileri şifrelenmiş bir şekilde depolamak için kullanılan bir depolama türüdür. Bu tür bir volume ile veriler, Kubernetes Secret nesnelerinde tutulur ve pod'larda bu secret volume'una bağlanarak kullanılabilir.
160 |
161 | Örneğin, bir uygulama veritabanı şifreleri gibi hassas bilgiler içeriyorsa, bu bilgilerin açık şekilde kaydedilmesi uygun olmaz. Bu tür hassas bilgileri, Kubernetes Secret nesnelerinde saklayabiliriz. Daha sonra bu Secret nesnelerini pod'lara Volume olarak bağlayarak, bu hassas bilgilere pod'larda erişebiliriz.
162 |
163 | Örneğin bir deployment'ta bir container çalıştırdığımızı ve bu container'ın bir secret dosyasına ihtiyacı olduğunu varsayalım. Öncelikle bir secret oluşturmalıyız:
164 |
165 | ```yaml
166 | apiVersion: v1
167 | kind: Secret
168 | metadata:
169 | name: mysecret
170 | type: Opaque
171 | data:
172 | username: dXNlcg==
173 | password: cGFzc3dvcmQ=
174 | ```
175 |
176 | > Kubernetes Secret objesi içerisinde data ve stringData alanlarına sahip olabilir. Her iki alan da Secret objesi içerisinde değer saklamak için kullanılır ancak aralarında bazı farklılıklar vardır.
177 |
178 | > data alanı, Base64 kodlu verileri saklamak için kullanılır. Bu nedenle, verileri kaydetmek için genellikle bir Base64 kodlayıcı kullanmak gerekir. Veriler, anahtar-değer çiftleri şeklinde saklanır. Bu alan, gizli anahtarları ve sertifikaları gibi hassas verileri saklamak için kullanılır.
179 |
180 | > stringData alanı ise Base64 kodlaması yapmadan doğrudan açık metin olarak verileri saklamak için kullanılır. Bu nedenle, verileri saklamak için herhangi bir kodlayıcı kullanmak gerekmez. Veriler yine anahtar-değer çiftleri şeklinde saklanır. Bu alan, genellikle basit metin verileri gibi hassas olmayan verileri saklamak için kullanılır.
181 |
182 | > Özetle, data alanı hassas verileri saklamak için kullanılırken, stringData alanı hassas olmayan verileri saklamak için kullanılır.
183 |
184 | Bu secret dosyasını oluşturduktan sonra, pod'da kullanmak için aşağıdaki şekilde kullanabiliriz:
185 |
186 | ```yaml
187 | apiVersion: v1
188 | kind: Pod
189 | metadata:
190 | name: mypod
191 | spec:
192 | containers:
193 | - name: mycontainer
194 | image: myimage
195 | volumeMounts:
196 | - name: secret-volume
197 | mountPath: /etc/mysecret
198 | readOnly: true
199 | volumes:
200 | - name: secret-volume
201 | secret:
202 | secretName: mysecret
203 | ```
204 |
205 | Bu YAML dosyası, mypod adlı bir pod yaratır ve mycontainer adlı bir container içerir. Bu container, /etc/mysecret yoluna read-only bir volume bağlar. Volume'un adı secret-volume olarak belirtilir ve bu volume, mysecret adlı secret dosyasını kullanarak oluşturulur.
206 |
207 | Artık bu pod çalıştırıldığında, mycontainer adlı container /etc/mysecret yolunda mysecret dosyasına erişebilir ve içerdiği username ve password bilgilerini kullanabilir. Bu şekilde, hassas bilgileri container'ımızın içine gömmek yerine secret dosyaları kullanarak daha güvenli bir yöntemle saklayabiliriz.
208 |
209 | ### ConfigMap vs Secret Volume
210 |
211 | Kubernetes'te ConfigMap ve Secret, uygulama yapılandırması ve gizli bilgilerin depolanması için kullanılan iki kaynak türüdür. ConfigMap, anahtar-değer çiftleri aracılığıyla yapılandırma bilgilerini depolamak için kullanılırken, Secret, duyarlı bilgileri (örneğin, şifreler, API anahtarları) depolamak için kullanılır.
212 |
213 | ConfigMap'lar, bir uygulamanın çeşitli yapılandırma ayarlarını depolamak için kullanışlıdır. Örneğin, bir web uygulamasında kullanılan farklı yapılandırma dosyalarının tümünü tek bir ConfigMap içinde depolayabilirsiniz. Bu, yapılandırma değişikliklerini daha kolay yönetmenizi sağlar. ConfigMap'lar, uygulama yapılandırmasını değiştirmek için manuel olarak veya bir konfigürasyon yönetimi aracı (örneğin, Helm) kullanarak güncellenebilir.
214 |
215 | Secret'lar, gizli verilerin depolanması için kullanılır. Örneğin, bir veritabanı şifresi veya bir API anahtarı gibi duyarlı bilgileri Secret içinde depolayabilirsiniz. Secret'lar, ConfigMap'lar gibi anahtar-değer çiftleri aracılığıyla depolanır ve kullanım sırasında otomatik olarak deşifre edilir. Secret'lar, genellikle bir uygulamanın Pod'larında bulunan konteynerlerin gizli bilgilere erişmesi gerektiğinde kullanılır.
216 |
217 | Özetle, ConfigMap'lar uygulama yapılandırması için, Secret'lar ise duyarlı bilgilerin depolanması için kullanılır.
218 |
219 | ## Dikkat Edilmesi Gerekenler
220 |
221 | - Verilerinizin kaybolmasını önlemek için doğru depolama sınıfını seçin. Örneğin, Ephemeral Volume'ler önbellek için kullanılabilirken, Persistant Volume'ler daha kalıcı veri saklama için tercih edilir.
222 | - Volume'lerin hangi pod'lar tarafından kullanılacağını belirleyin. Pod'larda birden fazla konteyner olduğunda, tüm konteynerlerin aynı volume'ü kullanması gerekiyorsa bunu belirtmelisiniz.
223 | - Farklı sınıflardaki Volume'leri farklı pod'lar kullanıyorsa, birden fazla pod üzerindeki değişiklikleri takip etmek için kaynak kısıtlamalarını tanımlayın.
224 | - Volume'lerin veri bütünlüğünü korumak için doğru şekilde yapılandırıldığından emin olun. Örneğin, veri bütünlüğü sağlamak için hazırda bekletilmiş ve ayrıcalıklı bir konumda depolanması gereken verilerin kullanımı için HostPath Volume kullanmak uygun değildir
225 | - Yapılandırmanızda Volume'lerin temizlenmesi veya silinmesi için gerekli prosedürleri belirleyin. Örneğin, bir Pod veya Deployment silindiğinde Volume'ün otomatik olarak silinmesini sağlayabilirsiniz.
226 |
--------------------------------------------------------------------------------