├── .gitbook └── assets │ ├── Screen Shot 2021-12-12 at 18.26.50.png │ ├── Screen Shot 2021-12-12 at 18.48.28.png │ ├── Screen Shot 2021-12-12 at 19.23.15.png │ ├── Screen Shot 2021-12-12 at 23.53.55.png │ ├── Screen Shot 2022-01-03 at 10.58.07.png │ ├── Screen Shot 2022-01-03 at 10.58.24.png │ ├── Screen Shot 2022-01-03 at 11.02.20.png │ ├── Screen Shot 2022-07-19 at 12.17.04.png │ ├── image (23).png │ ├── image (24) (1).png │ ├── image (25).png │ ├── image-20211230020644173.png │ ├── image-20220101232209717.png │ └── image-20220101232320593.png ├── README.md ├── SUMMARY.md ├── ingress.md ├── intro-components.md ├── k8s-ag-yapisi-service.md ├── kubectl.md ├── kurulum.md ├── label-selector-annotation.md ├── liveness-readiness-resource-limits-env.-variables.md ├── namespace-deployment-replicaset.md ├── pod.md ├── rollout-ve-rollback.md ├── volume-secret-configmap.md └── wip-prometheus-efk-stack.md /.gitbook/assets/Screen Shot 2021-12-12 at 18.26.50.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/berksafran/kubernetes-notlari/50f5d751cd71581c2f63e7f5c11002e657d1d0a2/.gitbook/assets/Screen Shot 2021-12-12 at 18.26.50.png -------------------------------------------------------------------------------- /.gitbook/assets/Screen Shot 2021-12-12 at 18.48.28.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/berksafran/kubernetes-notlari/50f5d751cd71581c2f63e7f5c11002e657d1d0a2/.gitbook/assets/Screen Shot 2021-12-12 at 18.48.28.png -------------------------------------------------------------------------------- /.gitbook/assets/Screen Shot 2021-12-12 at 19.23.15.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/berksafran/kubernetes-notlari/50f5d751cd71581c2f63e7f5c11002e657d1d0a2/.gitbook/assets/Screen Shot 2021-12-12 at 19.23.15.png -------------------------------------------------------------------------------- /.gitbook/assets/Screen Shot 2021-12-12 at 23.53.55.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/berksafran/kubernetes-notlari/50f5d751cd71581c2f63e7f5c11002e657d1d0a2/.gitbook/assets/Screen Shot 2021-12-12 at 23.53.55.png -------------------------------------------------------------------------------- /.gitbook/assets/Screen Shot 2022-01-03 at 10.58.07.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/berksafran/kubernetes-notlari/50f5d751cd71581c2f63e7f5c11002e657d1d0a2/.gitbook/assets/Screen Shot 2022-01-03 at 10.58.07.png -------------------------------------------------------------------------------- /.gitbook/assets/Screen Shot 2022-01-03 at 10.58.24.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/berksafran/kubernetes-notlari/50f5d751cd71581c2f63e7f5c11002e657d1d0a2/.gitbook/assets/Screen Shot 2022-01-03 at 10.58.24.png -------------------------------------------------------------------------------- /.gitbook/assets/Screen Shot 2022-01-03 at 11.02.20.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/berksafran/kubernetes-notlari/50f5d751cd71581c2f63e7f5c11002e657d1d0a2/.gitbook/assets/Screen Shot 2022-01-03 at 11.02.20.png -------------------------------------------------------------------------------- /.gitbook/assets/Screen Shot 2022-07-19 at 12.17.04.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/berksafran/kubernetes-notlari/50f5d751cd71581c2f63e7f5c11002e657d1d0a2/.gitbook/assets/Screen Shot 2022-07-19 at 12.17.04.png -------------------------------------------------------------------------------- /.gitbook/assets/image (23).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/berksafran/kubernetes-notlari/50f5d751cd71581c2f63e7f5c11002e657d1d0a2/.gitbook/assets/image (23).png -------------------------------------------------------------------------------- /.gitbook/assets/image (24) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/berksafran/kubernetes-notlari/50f5d751cd71581c2f63e7f5c11002e657d1d0a2/.gitbook/assets/image (24) (1).png -------------------------------------------------------------------------------- /.gitbook/assets/image (25).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/berksafran/kubernetes-notlari/50f5d751cd71581c2f63e7f5c11002e657d1d0a2/.gitbook/assets/image (25).png -------------------------------------------------------------------------------- /.gitbook/assets/image-20211230020644173.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/berksafran/kubernetes-notlari/50f5d751cd71581c2f63e7f5c11002e657d1d0a2/.gitbook/assets/image-20211230020644173.png -------------------------------------------------------------------------------- /.gitbook/assets/image-20220101232209717.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/berksafran/kubernetes-notlari/50f5d751cd71581c2f63e7f5c11002e657d1d0a2/.gitbook/assets/image-20220101232209717.png -------------------------------------------------------------------------------- /.gitbook/assets/image-20220101232320593.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/berksafran/kubernetes-notlari/50f5d751cd71581c2f63e7f5c11002e657d1d0a2/.gitbook/assets/image-20220101232320593.png -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # ✍ Hakkında 2 | 3 | Merhaba, 4 | 5 | Bu e-book, [Özgür Öztürk'ün Kubernetes Temelleri](https://www.udemy.com/course/kubernetes-temelleri/) kursunun notlarından oluşmaktadır. Bazı konular kısa kısa geçilse de genel olarak K8s konularının önemli noktalarını notlar içerisinde bulabilirsiniz. Zaman içerisinde farklı konularda eklenecektir. 6 | 7 | Notlar içerisinde herhangi bir anlaşılmayan veya yanlış olan bir bilgi gördüğünüzde e-book için açtığım GitHub Repository'si üzerinden "Issue"; katkı sağlamak isterseniz "Pull Request" açabilirseniz çok memnun olurum. 8 | 9 | {% embed url="https://github.com/berksafran/kubernetes-notlari" %} 10 | E-book GitHub Repository 11 | {% endembed %} 12 | 13 | Özgür Bey'e bu detaylı kursu hazırlarken harcadığı emeklerinden dolayı ve notları paylaşmamı kabul ettiği için, Ali Atalay Cebeci'ye de katkılarından dolayı **** teşekkür ederim. 14 | 15 | 16 | 17 | Sevgiler, 18 | 19 | **Berk Safranbolulu** 20 | 21 | **** 22 | 23 | 24 | 25 | ## Kaynak Repository 26 | 27 | Notlar içerisindeki **yaml** dosyalarının kaynağı için Özgür Bey'in kurs için oluşturduğu aşağıdaki repository'i kullanabilirsiniz: 28 | 29 | {% embed url="https://www.udemy.com/course/kubernetes-temelleri" %} 30 | 31 | {% embed url="https://github.com/aytitech/k8sfundamentals" %} 32 | 33 | -------------------------------------------------------------------------------- /SUMMARY.md: -------------------------------------------------------------------------------- 1 | # Table of contents 2 | 3 | * [✍ Hakkında](README.md) 4 | * [⛵ Nedir, Components, Nodes](intro-components.md) 5 | * [📀 Kurulum](kurulum.md) 6 | * [🚃 Kubectl](kubectl.md) 7 | * [🟡 Pod](pod.md) 8 | * [🏷 Label, Selector, Annotation](label-selector-annotation.md) 9 | * [🌟 Namespace, Deployment, ReplicaSet](namespace-deployment-replicaset.md) 10 | * [👈 Rollout ve Rollback](rollout-ve-rollback.md) 11 | * [☀ K8s Ağ Yapısı, Service](k8s-ag-yapisi-service.md) 12 | * [🔑 Liveness, Readiness, Resource Limits, Env. Variables](liveness-readiness-resource-limits-env.-variables.md) 13 | * [⚡ Volume, Secret, ConfigMap](volume-secret-configmap.md) 14 | * [🎺 Ingress](ingress.md) 15 | * [\[WIP\] Prometheus, EFK Stack](wip-prometheus-efk-stack.md) 16 | -------------------------------------------------------------------------------- /ingress.md: -------------------------------------------------------------------------------- 1 | # 🎺 Ingress 2 | 3 | ## Ingress 4 | 5 | * Uygulamalarımızın dış dünyaya erişebilmesi/dış dünyadan erişilebilmesi için kullandığımız yapıdır. 6 | 7 | **Örnek Senaryo** 8 | 9 | ![](<.gitbook/assets/Screen Shot 2022-01-03 at 10.58.07.png>) 10 | 11 | Azure gibi bir cloud service kullandığımızı varsayalım. Servisin içerisine bir LoadBalancer service’ı tanımlayalım. Azure, bizim adımıza bu LoadBalancer servisine bir IP atıyor ve bu IP’ye gelen tüm istekler bu LoadBalancer tarafından karşılanıyor. Biz de bu IP adresi ile DNS sayesinde domainimizi eşleştirerek, kullanıcıların kolay bir şekilde erişmesini sağlayalım. 12 | 13 | Aynı k8s cluster içerisinde bir tane daha app ve aynı servisleri tanımladığımızı düşünelim. Hatta abartalım 2, 3, 4 derken her bir LoadBalancer için **Azure’a ekstradan para ödemem ve ayarlarını manuel yapmam gerekiyor.** 14 | 15 | **Örnek Senaryo - 2** 16 | 17 | ![](<.gitbook/assets/Screen Shot 2022-01-03 at 10.58.24.png>) 18 | 19 | Bu örnekte ise; kullanıcı **example.com**‘a girdiğinde A uygulaması; **example.com/contact**’a girdiğinde ise B uygulaması çalışsın. Bu durumu, DNS’te **/contact** path’i tanımlayamadığımız için LoadBalancer ile kurgulama şansımız yoktur. Fakat, bizim bir gateway gibi çalışan; kullanıcıyı her halükarda karşılayan bir load balancer’a ihtiyacım var. 20 | 21 | İşte bu 2 örnekte/sorunu da **Ingress Controller ve Ingress Object** ile çözüyoruz: 22 | 23 | ## Ingress Controller ve Ingress Object 24 | 25 | ![](<.gitbook/assets/Screen Shot 2022-01-03 at 11.02.20.png>) 26 | 27 | * **Ingress Controller**, Nginx, Traefik, KrakenD gibi kullanabileceğimiz bir load balancer uygulamasına denir. Bu uygulamalardan birini seçip; k8s cluster’ımıza deploy edebilir ve LoadBalancer servisini kurarak dışarıya expose edebiliriz. Böylelikle, uygulamamız **public bir IP**’e sahip oluyor ve userlar ile tamamen bu IP üzerinden iletişim kurabiliriz. 28 | * **Peki, gelen istekleri nasıl yönlendiriyoruz?** İşte bu esnada **Ingress Object**‘leri devreye giriyor. (_YAML dosyalarında tanımlanan yapılar_) Ingress Controller’larda yapacağımız konfigürasyonlarla Ingress Object’lerimizi ve Ingress Controller’ların gelen requestlere karşı nasıl davranması gerektiğini belirleyebiliriz. 29 | * **Load balancing, SSL termination ve path-name based routing** gibi özelliklere sahiptir. 30 | 31 | ## Local’de Ingress Uygulama 32 | 33 | ### 1) minikube’ü Ayarlama 34 | 35 | * Ingress’i çalıştırmak için minikube driver’ını değiştirmemiz gerekmektedir; 36 | * Windows için **Hyper-V**, macOS ve linux için **VirtualBox** seçebiliriz. Seçmeden önce kurulum yapmayı unutmayalım. 37 | 38 | ```shell 39 | minikube start --driver=hyperv 40 | ``` 41 | 42 | ### 2) Ingress Controller Seçimi ve Kurulumu 43 | 44 | * Biz nginx ile devam edeceğiz. Her ingress controller’ın kurulumu farklıdır. Kurulum detaylarını uygulamanın kendi web sitesinden öğrenebilirsiniz. 45 | 46 | **Kurulum detayları –>** https://kubernetes.github.io/ingress-nginx/deploy/ 47 | * minikube, yoğun olarak kullanılan nginx gibi bazı ingress controller’ı daha hızlı aktif edebilmek adına addon olarak sunmaktadır. 48 | 49 | ```shell 50 | minikube addons enable ingress # ingress addonunu aktif eder. 51 | minikube addons list # tüm addon'ları listeler. 52 | ``` 53 | 54 | * :point\_right: **Nginx** kurulduğu zaman kendisine **ingress-nginx** adında bir **namespace yaratır.** 55 | 56 | ```shell 57 | # ingress-nginx namespace'ine ait tüm objectlerini listelemek için: 58 | kubectl get all -n ingress-nginx 59 | ``` 60 | 61 | ### 3) Ingress Uygulamalarımızı Deploy Etmek 62 | 63 | * **blueapp, greenapp, todoapp** için hem podlarımızı hem de servicelerimizi yaratan yaml dosyamızı deploy edelim. 64 | * **Tüm service’lerin ClusterIP tipinde birer service olduğunu unutmayalım.** 65 | 66 | ```yaml 67 | apiVersion: apps/v1 68 | kind: Deployment 69 | metadata: 70 | name: blueapp 71 | labels: 72 | app: blue 73 | spec: 74 | replicas: 2 75 | selector: 76 | matchLabels: 77 | app: blue 78 | template: 79 | metadata: 80 | labels: 81 | app: blue 82 | spec: 83 | containers: 84 | - name: blueapp 85 | image: ozgurozturknet/k8s:blue 86 | ports: 87 | - containerPort: 80 88 | livenessProbe: 89 | httpGet: 90 | path: /healthcheck 91 | port: 80 92 | initialDelaySeconds: 5 93 | periodSeconds: 5 94 | readinessProbe: 95 | httpGet: 96 | path: /ready 97 | port: 80 98 | initialDelaySeconds: 5 99 | periodSeconds: 3 100 | --- 101 | apiVersion: v1 102 | kind: Service 103 | metadata: 104 | name: bluesvc 105 | spec: 106 | selector: 107 | app: blue 108 | ports: 109 | - protocol: TCP 110 | port: 80 111 | targetPort: 80 112 | --- 113 | apiVersion: apps/v1 114 | kind: Deployment 115 | metadata: 116 | name: greenapp 117 | labels: 118 | app: green 119 | spec: 120 | replicas: 2 121 | selector: 122 | matchLabels: 123 | app: green 124 | template: 125 | metadata: 126 | labels: 127 | app: green 128 | spec: 129 | containers: 130 | - name: greenapp 131 | image: ozgurozturknet/k8s:green 132 | ports: 133 | - containerPort: 80 134 | livenessProbe: 135 | httpGet: 136 | path: /healthcheck 137 | port: 80 138 | initialDelaySeconds: 5 139 | periodSeconds: 5 140 | readinessProbe: 141 | httpGet: 142 | path: /ready 143 | port: 80 144 | initialDelaySeconds: 5 145 | periodSeconds: 3 146 | --- 147 | apiVersion: v1 148 | kind: Service 149 | metadata: 150 | name: greensvc 151 | spec: 152 | selector: 153 | app: green 154 | ports: 155 | - protocol: TCP 156 | port: 80 157 | targetPort: 80 158 | --- 159 | apiVersion: apps/v1 160 | kind: Deployment 161 | metadata: 162 | name: todoapp 163 | labels: 164 | app: todo 165 | spec: 166 | replicas: 1 167 | selector: 168 | matchLabels: 169 | app: todo 170 | template: 171 | metadata: 172 | labels: 173 | app: todo 174 | spec: 175 | containers: 176 | - name: todoapp 177 | image: ozgurozturknet/samplewebapp:latest 178 | ports: 179 | - containerPort: 80 180 | --- 181 | apiVersion: v1 182 | kind: Service 183 | metadata: 184 | name: todosvc 185 | spec: 186 | selector: 187 | app: todo 188 | ports: 189 | - protocol: TCP 190 | port: 80 191 | targetPort: 80 192 | ``` 193 | 194 | ### 4) Ingress Object’lerini Deploy Etme ve Ayarlama 195 | 196 | * Load balancer için gerekli olan Ingress Controller’ımızı Nginx olarak seçtik ve kurduk. 197 | * Her bir app için gerekli olan ClusterIP tipinde servislerimizi de kurduktan sonra, sıra kullanıcıların **example.com/a** yazdığında A service’ine gitmesi için gerekli **Ingress object’lerimizi** de deploy etmeye geldi. 198 | 199 | > _**Araştırma Konusu:** –> Layer 7 nedir? Ne işe yarar?_ 200 | 201 | **blue, green app’ler için Ingress Object tanımlaması:** 202 | 203 | * `pathType` kısmı `exact`veya `Prefix` olarak 2 şekilde ayarlanabilir. Detaylı bilgi için: https://kubernetes.io/docs/concepts/services-networking/ingress/ 204 | 205 | ```shell 206 | apiVersion: networking.k8s.io/v1 207 | kind: Ingress 208 | metadata: 209 | name: appingress 210 | annotations: 211 | # Nginx üzerinde ayarlar, annotations üzerinden yapılır. 212 | nginx.ingress.kubernetes.io/rewrite-target: /$1 213 | spec: 214 | rules: 215 | - host: k8sfundamentals.com 216 | http: 217 | paths: 218 | - path: /blue 219 | pathType: Prefix 220 | backend: 221 | service: 222 | name: bluesvc 223 | port: 224 | number: 80 225 | - path: /green 226 | pathType: Prefix 227 | backend: 228 | service: 229 | name: greensvc 230 | port: 231 | number: 80 232 | ``` 233 | 234 | * Farklı bir `path` kullanarak hazırlanan Ingress Objecti: 235 | 236 | ```yaml 237 | apiVersion: networking.k8s.io/v1 238 | kind: Ingress 239 | metadata: 240 | name: todoingress 241 | spec: 242 | rules: 243 | - host: todoapp.com 244 | http: 245 | paths: 246 | - path: / 247 | pathType: Prefix 248 | backend: 249 | service: 250 | name: todosvc 251 | port: 252 | number: 80 253 | ``` 254 | 255 | ### 5) Tanımlanan Ingress Object’leri test etme: 256 | 257 | ```yaml 258 | kubectl get ingress 259 | ``` 260 | 261 | * Eğer URL’ler ile simüle etmek istersek, **hosts** dosyasını editlememiz gerekir. 262 | -------------------------------------------------------------------------------- /intro-components.md: -------------------------------------------------------------------------------- 1 | # ⛵ Nedir, Components, Nodes 2 | 3 | ## Neden Gerekli? 4 | 5 | Örnek üzerinden gidelim: 6 | 7 | Birden fazla microservice’in çalıştığı bir docker environment’ı düşünelim. Her bir microservice bir docker container içerisinde çalıştığını ve uygulamamızı kullanıcılara açtığımızı düşünelim. Uygulamamız, şuan tek bir sunucu üzerinde koşuyor ve sunucu üzerinde güncelleme yaptığımızda sistemde kesintiler oluşmaya başlayacaktır. 8 | 9 | Bu sorunumuzu çözmek adına, yeni bir sunucu kiralayıp, aynı docker environment’ını kurgulayıp (clonelayıp), bir de **load balancer** kurarak dağıtık bir mimariye geçiş yaptık. Buna rağmen, docker container’lar kendiliğinden kapanıyor ve bu duruma manuel müdahale etmemiz gerekir. Daha fazla trafik aldığımız için, 2 sunucu daha kiraladık. 2 sunucu daha, 2 sunucu daha.. 10 | 11 | Tüm bu sunucuları **manuel yönetmeye devam ediyoruz.** Zamanla DevOps süreçlerine manuel müdahaleden dolayı çok fazla zaman harcamaya başladık, geriye kalan işlere zaman kalmadı. 12 | 13 | Peki bu durumu çözecek durum nedir? Cevap -> **Container Orchestration!** 14 | 15 | Tüm sistem konfigürasyonlarını ayarlayıp, bu karar mekanizmasını bir orkestra şefine emanet edebiliriz. İşte bu şef **Kubernetes’tir!** 16 | 17 | Diğer alternatifler -> Docker Swarm, Apache H2o 18 | 19 | ## K8s Tarihçesi 20 | 21 | * Google tarafından geliştirilen Orchestration sistemi. 22 | * Google, çok uzun yıllardır Linux containerlar kullanıyor. Tüm bu containerları yönetmek için **Borg** adında bir platform geliştirmiş. Fakat, zamanla hatalar çıkmış ve yeni bir platform ihtiyacı duyulmuş ve **Omega** platformu geliştirilmiş. 23 | * 2013 yılında 3 Google mühendisi open-source bir şekilde GitHub üzerinde Kubernetes reposunu açtı. _Kubernetes: Deniz dümencisi_ _(k8s)_ 24 | * 2014 senesinde proje, Google tarafından CNCF’e bağışlandı. (Cloud Native Computing Foundation) 25 | 26 | ## Kubernetes nedir? 27 | 28 | * Declarative (_beyan temelli yapılandırma_), Container orchestration platformu. 29 | * Proje, hiç bir şirkete bağlı değil, bir vakıf tarafından yönetilmektedir. 30 | * Ücretsizdir. Rakip firmalarda **open-source**’dur. 31 | * Bu kadar popüler olmasının sebebi, platformun tasarımı ve çözüm yaklaşımı. 32 | * Semantic versioning izler (_x.y.z. -> x: major, y: minor, z: patch_) ve her 4 ayda bir minor version çıkartır. 33 | * Her ay patch version yayınlar. 34 | * Bir kubernetes platformu en fazla 1 yıl kullanılır, 1 yıldan sonra güncellemek gerekmektedir. 35 | 36 | ![](<.gitbook/assets/Screen Shot 2021-12-12 at 18.26.50.png>) 37 | 38 | ### Kubernetes Tasarımı ve Yaklaşımı 39 | 40 | Birden fazla geliştirilebilir modüllerden oluşmaktadır. Bu modüllerin hepsinin bir görevi vardır ve tüm modüller kendi görevlerine odaklanır. İhtiyaç halinde bu modüller veya yeni modüller geliştirilebilir. (extendable) 41 | 42 | K8s, “_Şunu yap, daha sonra şunu yap_” gibi adım adım ne yapmamız gerektiğini söylemek yerine _**(imperative yöntem);** “Ben şöyle bir şey istiyorum” **(declarative yöntem)**_ yaklaşımı sunmaktadır. **Nasıl yapılacağını tarif etmiyor, ne istediğimizi söylüyoruz.** 43 | 44 | * Imperative yöntem, bize zaman kaybettirir, tüm adımları tasarlamak zorunda kalırız. 45 | * Declarative yöntem’de ise sadece ne istediğimizi söylüyoruz ve sonuca bakıyoruz. 46 | 47 | Kubernetes bize ondan istediğimizi soruyor, biz söylüyoruz ve bizim istediklerimizin dışına çıkmıyor. Örneğin, **Desired State (Deklara Edilen Durum - \_İstekler gibi düşünebiliriz**\_**)** şu şekilde olsun: 48 | 49 | * Berksafran/k8s:latest isimli imaj yaratıp, 10 containerla çalıştır. Dış dünyaya 80 portunu aç ve ben bu service’e bir güncelleme geçtiğimde aynı anda 2 task üzerinde yürüt ve 10sn beklensin. 50 | 51 | Kubernetes, 9 container çalışır durumda kalırsa hemen bir container daha ayağa kaldırır ve isteklerimize göre platformu **optimize eder.** Bu bizi, çok büyük bir işten kurtarıyor. _(Docker’da manuel olarak ayağa kaldırıyorduk, hatırlayın.)_ 52 | 53 | ## Kubernetes Componentleri 54 | 55 | K8s, **microservice mimarisi dikkate alınarak** oluşturulmuştur. 56 | 57 | ![](<.gitbook/assets/Screen Shot 2021-12-12 at 19.23.15.png>) 58 | 59 | ### **Control Plane** (Master Nodes) 60 | 61 | Aşağıdaki, 4 component k8s yönetim kısmını oluşturur ve **master-node** üzerinde çalışır. 62 | 63 | * **Master-node** -> Yönetim modullerinin çalıştığı yerdir. 64 | * **Worker-node** -> İş yükünün çalıştığı yerdir. 65 | 66 | 67 | 68 | ![](<.gitbook/assets/Screen Shot 2022-07-19 at 12.17.04.png>) ![](<.gitbook/assets/Screen Shot 2021-12-12 at 18.48.28.png>) 69 | 70 | * **kube-apiserver** **(api) –>** K8s’in beyni, **ana haberleşme merkezi, giriş noktasıdır**. Bir nev-i **Gateway** diyebiliriz. Tüm **componentler** ve **node**’lar, **kube-apiserver** üzerinden iletişim kurar. Ayrıca, dış dünya ile platform arasındaki iletişimi de **kube-apiserver** sağlar. Bu denli herkesle iletişim kurabilen **tek componenttir**. **Authentication ve Authorization** görevini üstlenir. 71 | * **etcd** **->** K8s’in tüm cluster verisi, metada bilgileri ve Kubernetes platformunda oluşturulan componentlerin ve objelerin bilgileri burada tutulur. Bir nevi **Arşiv odası.** etcd, **key-value** şeklinde dataları tutar. Diğer componentler, etdc ile **direkt haberleşemezler.** Bu iletişimi, **kube-apiserver** aracılığıyla yaparlar. 72 | * **kube-scheduler (sched) ->** K8s’i çalışma planlamasının yapıldığı yer. Yeni oluşturulan ya da bir node ataması yapılmamış Pod’ları izler ve üzerinde çalışacakları bir **node** seçer. (_Pod = container_) Bu seçimi yaparken, CPU, Ram vb. çeşitli parametreleri değerlendirir ve **bir seçme algoritması sayesinde pod için en uygun node’un hangisi olduğuna karar verir.** 73 | * **kube-controller-manager (c-m) ->** K8s’in kontrollerinin yapıldığı yapıdır. **Mevcut durum ile istenilen durum arasında fark olup olmadığını denetler.** Örneğin; siz 3 cluster istediniz ve k8s bunu gerçekleştirdi. Fakat bir sorun oldu ve 2 container kaldı. kube-controller, burada devreye girer ve hemen bir cluster daha ayağa kaldırır. Tek bir binary olarak derlense de içerisinde bir çok controller barındırır: 74 | * Node Controller, 75 | * Job Controller, 76 | * Service Account & Token Controller, 77 | * Endpoints Controller. 78 | 79 | ### **Worker Nodes** 80 | 81 | Containerlarımızın çalıştığı yerlerdir. Container veya Docker gibi container’lar çalıştırır. Her worker node’da **3 temel component** bulunur: 82 | 83 | 1. **Container runtime ->** Varsayılan olarak Docker’dır. Ama çeşitli sebeplerden dolayı **Docker’dan Containerd‘ye** geçmiştir. Docker ve containerd arasında fark yok nedebilecek kadar azdır. Hatta Docker kendi içerisinde de containerd kullanır. Diğer desteklenen container çeşidi **CRI-O’dur.** 84 | 2. **kubelet ->** API Server aracılığıyla etcd’yi kontrol eder ve sched tarafından bulunduğu node üzerinde çalışması gereken podları yaratır. Containerd’ye haber gönderir ve belirlenen özelliklerde bir container çalışmasını sağlar. 85 | 3. **kube-proxy ->** Nodelar üstünde ağ kurallarını ve trafik akışını yönetir. Pod’larla olan iletişime izin verir, izler. 86 | 87 | Tüm bunların dışında GUI hizmeti sağlayan vb. pluginler de kurulmaktadır. 88 | -------------------------------------------------------------------------------- /k8s-ag-yapisi-service.md: -------------------------------------------------------------------------------- 1 | # ☀ K8s Ağ Yapısı, Service 2 | 3 | ## K8s Temel Ağ Altyapısı 4 | 5 | Aşağıdaki üç kural dahilinde K8s network yapısı ele alınmıştır (_olmazsa olmazdır_): 6 | 7 | 1. K8s kurulumda pod’lara ip dağıtılması için bir **IP adres aralığı** (`--pod-network-cidr`) belirlenir. 8 | 2. K8s’te her pod bu cidr bloğundan atanacak **unique bir IP adresine sahip olur.** 9 | 3. **Aynı cluster içerisindeki Pod’lar** default olarak birbirleriyle herhangi **bir kısıtlama olmadan ve NAT (Network Address Translation) olmadan haberleşebilir.** 10 | 11 | > _**TODO: Buraya K8s’in Nasıl Network konusunu işlediğini yazılacak.**_ 12 | 13 | * K8s içerisindeki containerlar 3 tür haberleşmeye maruz bırakılır: 14 | 1. Bir container k8s dışındaki bir IP ile haberleşir, 15 | 2. Bir container kendi node içerisindeki başka bir container’la haberleşir, 16 | 3. Bir container farklı bir node içerisindeki başka bir container’la haberleşir. 17 | * İlk 2 senaryoda sorun yok ama 3. senaryo’da NAT konusunda problem yaşanır. Bu sebeple k8s containerların birbiri ile haberleşme konusunda **Container Network Interface (CNI)** projesini devreye almıştır. 18 | * **CNI, yanlızca containerların ağ bağlantısıyla ve containerlar silindiğinde containerlara ayrılan kaynakların drop edilmesiyle ilgilenir.** 19 | * **K8s ise ağ haberleşme konusunda CNI standartlarını kabul etti ve herkesin kendi seçeceği CNI pluginlerinden birini seçmesine izin verdi.** Aşağıdaki adreslerden en uygun olan CNI pluginini seçebilirsiniz: 20 | 21 | {% embed url="https://github.com/containernetworking/cni" %} 22 | 23 | {% embed url="https://kubernetes.io/docs/concepts/cluster-administration/networking" %} 24 | 25 | **Container’ların “Dış Dünya” ile haberleşmesi konusunu ele aldık. Peki, “Dış Dünya”, Container’lar ile nasıl haberleşecek?** 26 | 27 | Cevap: **Service** object’i. 28 | 29 | ## Service 30 | 31 | * K8s network tarafını ele alan objecttir. 32 | 33 | ### Service Objecti Çıkış Senaryosu 34 | 35 | 1 Frontend (React), 1 Backend (Go) oluşan bir sistemimiz olduğunu düşünelim: 36 | 37 | * Her iki uygulama için **birer deployment** yazdık ve **3’er pod** tanımlanmasını sağladık. 38 | * 3 Frontend poduna dış dünyadan nasıl erişim sağlayacağım? 39 | * Frontend’den gelen istek backend’de işlenmeli. Burada çok bir problem yok. Çünkü, her pod’un bir IP adresi var ve K8s içerisindeki her pod birbiriyle bu IP adresleri sayesinde haberleşebilir. 40 | * Bu haberleşmeyi sağlayabilmek için; Frontend podlarının Backend podlarının IP adreslerini **bilmeleri gerekir.** Bunu çözmek için, frontend deployment’ına tüm backend podlarının IP adreslerini yazdım. Fakat, pod’lar güncellenebilir, değişebilir ve bu güncellemeler esnasında **yeni bir IP adresi alabilir. Yeni oluşan IP adreslerini tekrar Frontend deployment’ında tanımlamam gerekir.** 41 | 42 | İşte tüm bu durumları çözmek için **Service** objecti yaratırız. **K8s, Pod’lara kendi IP adreslerini ve bir dizi Pod için tek bir DNS adı verir ve bunlar arasında yük dengeler.** 43 | 44 | ## Service Tipleri 45 | 46 | ### **ClusterIP** (Container’lar Arası) 47 | 48 | –> Bir ClusterIP service’i yaratıp, bunu label’lar sayesinde podlarla ilişkilendirebiliriz. Bu objecti yarattığımız zaman, Cluster içerisindeki tüm podların çözebileceği unique bir DNS adrese sahip olur. Ayrıca, her k8s kurulumunda sanal bir IP range’e sahip olur. (Ör: 10.0.100.0/16) 49 | 50 | –> ClusterIP service objecti yaratıldığı zaman, bu object’e bu IP aralığından **bir IP atanır** ve **ismiyle bu IP adresi Cluster’ın DNS mekanizmasına kaydedilir.** Bu IP adresi **Virtual (Sanal) bir IP adresidir.** 51 | 52 | –> Kube-proxy tarafından tüm node’lardaki IP Table’a bu IP adresi eklenir. Bu IP adresine gelen her trafik Round Troppin algoritmasıyla Pod’lara yönlendirilir. Bu durum bizim 2 sıkıntımızı çözer: 53 | 54 | 1. Ben Frontend node’larına bu IP adresini tanımlayıp (ismine de `backend`dersem), Backend’e gitmen gerektiği zaman bu IP adresini kullan diyebilirim. (**Selector = app:backend**) Tek tek her seferinde Frontend podlarına Backend podlarının IP adreslerini eklemek zorunda kalmam! 55 | 56 | :tada: :tada: **Özetle: ClusterIP Service’i Container’ları arasındaki haberleşmeyi, Service Discovery ve Load Balancing görevi üstlenerek çözer!**\\ 57 | 58 | *** 59 | 60 | ### NodePort Service (Dış Dünya -> Container) 61 | 62 | –> Bu service tipi, **Cluster dışından gelen bağlantıları** çözmek için kullanılır. 63 | 64 | –> `NodePort` key’i kullanılır.\\ 65 | 66 | ### LoadBalancer Service (Cloud Service’leri İçin) 67 | 68 | –> Bu service tipi, sadece Agent K8s, Google K8s Engine gibi yerlerde kullanılır.\\ 69 | 70 | ### ExternalName Service (Şuan için gereksiz.) 71 | 72 | ## Service Objecti Uygulaması 73 | 74 | ### Cluster IP Örneği 75 | 76 | ```shell 77 | apiVersion: v1 78 | kind: Service 79 | metadata: 80 | name: backend # Service ismi 81 | spec: 82 | type: ClusterIP # Service tipi 83 | selector: 84 | app: backend # Hangi podla ile eşleşeceği (pod'daki labella aynı) 85 | ports: 86 | - protocol: TCP 87 | port: 5000 88 | targetPort: 5000 89 | ``` 90 | 91 | Herhangi bir object, cluster içerisinde oluşan `clusterIP:5000` e istek attığında karşılık bulacaktır. 92 | 93 | **Önemli Not:** Service’lerin ismi oluşturulduğunda şu formatta olur: `serviceName.namespaceName.svc.cluster.domain` 94 | 95 | Eğer aynı namespace’de başka bir object bu servise gitmek istese core DNS çözümlemesi sayesinde direkt `backend` yazabilir. Başka bir namespaceden herhangi bir object ise ancak yukarıdaki **uzun ismi** kullanarak bu servise ulaşmalıdır. 96 | 97 | ### NodePort Örneği 98 | 99 | * Unutulmamalıdır ki, tüm oluşan NodePort servislerinin de **ClusterIP’si** mevcuttur. Yani, içeriden bu ClusterIP kullanılarak bu servisle konuşulabilir. 100 | * **`minikube service –url `** ile minikube kullanırken tunnel açabiliriz. Çünkü, biz normalde bu worker node’un içerisine dışardan erişemiyoruz. _Bu tamamen minikube ile alakalıdır._ 101 | 102 | ```shell 103 | apiVersion: v1 104 | kind: Service 105 | metadata: 106 | name: frontend 107 | spec: 108 | type: NodePort 109 | selector: 110 | app: frontend 111 | ports: 112 | - protocol: TCP 113 | port: 80 114 | targetPort: 80 115 | ``` 116 | 117 | ### Load Balancer Örneği 118 | 119 | Google Cloud Service, Azure üzerinde oluşturulan cluster’larda çalışacak bir servistir. 120 | 121 | ```shell 122 | apiVersion: v1 123 | kind: Service 124 | metadata: 125 | name: frontendlb 126 | spec: 127 | type: LoadBalancer 128 | selector: 129 | app: frontend 130 | ports: 131 | - protocol: TCP 132 | port: 80 133 | targetPort: 80 134 | ``` 135 | 136 | ### Imperative Olarak Service Oluşturma 137 | 138 | ```shell 139 | kubectl delete service 140 | 141 | # ClusterIP Service yaratmak 142 | kubectl expose deployment backend --type=ClusterIP --name=backend 143 | 144 | kubectl expose deployment backend --type=NodePort --name=backend 145 | ``` 146 | 147 | ### Endpoint Nedir? 148 | 149 | Nasıl deployment’lar aslında ReplicaSet oluşturduysa, Service objectleride arka planda birer Endpoint oluşturur. Service’lerimize gelen isteklerin nereye yönleneceği Endpoint’ler ile belirlenir. 150 | 151 | ```shell 152 | kubectl get endpoints 153 | ``` 154 | 155 | Bir pod silindiğinde yeni oluşacak pod için, yeni bir endpoint oluşturulur. 156 | -------------------------------------------------------------------------------- /kubectl.md: -------------------------------------------------------------------------------- 1 | # 🚃 Kubectl 2 | 3 | ## Kubectl 4 | 5 | ![](<.gitbook/assets/Screen Shot 2021-12-12 at 23.53.55.png>) 6 | 7 | * kubectl ile mevcut cluster’ı yönetimini **config** dosyası üzerinden yapmamız gerekir. Minikube gibi tool’lar config dosyalarını otomatik olarak oluşturur. 8 | * **Default config** dosyasına `nano ~/.kube/config` yazarak ulaşabiliriz. 9 | * VSCode’da açmak için 10 | 11 | ``` 12 | cd ~/.kube 13 | code . 14 | ``` 15 | 16 | * **context ->** Cluster ile user bilgilerini birleştirerek context bilgisini oluşturur. “_Bu cluster’a bu user’la bağlanacağım._” anlamına geliyor. 17 | 18 | ### Kubectl Config Komutları 19 | 20 | **`kubectl config`** 21 | 22 | –> Config ayarlarının düzenlenmesini sağlayan komuttur. 23 | 24 | **`kubectl config get-contexts`** 25 | 26 | –> Kubectl baktığı config dosyasındaki mevcut contextleri listeler. 27 | 28 | #### **Current Context** 29 | 30 | Current sütununda minikube’un yanında bir yıldız (\*) işareti görünür. Bunun anlamı: birden fazla context tanımlansa da **o an kullanılan context** anlamına gelir. Yapacağımız tüm işlemleri bu context’in içerisinde gerçekleşecektir. 31 | 32 | **`kubectl config current-context`** 33 | 34 | –> Kubectl baktığı config dosyasındaki current context’i verir. 35 | 36 | **`kubectl config use-context `** 37 | 38 | –> Current context’i contextName olarak belirtilen context’i ile değiştirir. 39 | 40 | ÖR: `kubectl config use-context docker-desktop` –> docker-desktop context’ine geçer. 41 | 42 | ## Kubectl Kullanım Komutları 43 | 44 | * kubectl’de komutlar belli bir şemayla tasarlanmıştır: 45 | 46 | ``` 47 | kubectl ​ 48 | 49 | # = get, delete, edit, apply 50 | # = pod 51 | ``` 52 | 53 | * kubectl’de aksi belirtilmedikçe tüm komutlar **config’de yazılan namespace’ler** üzerinde uygulanır. Config’de namespace belirtilmediyse, **default namespace** geçerlidir. 54 | 55 | ### `kubectl cluster-info` 56 | 57 | –> Üzerinde işlem yaptığımız **cluster** ile ilgili bilgileri öğreneceğimiz komut. 58 | 59 | ### `kubectl get pods` 60 | 61 | –> **Default namespace**‘deki pod’ları getirir. 62 | 63 | ### `kubectl get pods testpod` 64 | 65 | –> **testpod** isimli pod’u getirir. 66 | 67 | ### **`kubectl get pods -n kube-system`** 68 | 69 | –> **kube-system** isimli namespace’de tanımlanmış pod’ları getirir. 70 | 71 | ### `kubectl get pods -A` 72 | 73 | –> **Tüm namespacelerdeki** pod’ları getirir. 74 | 75 | ### `kubectl get pods -A -o ` 76 | 77 | –> **Tüm namespacelerdeki** pod’ları **istenilen output formatında** getirir. 78 | 79 | ```shell 80 | # jq -> json query pluginin kur. 81 | # brew install jq 82 | 83 | kubectl get pods -A -o json | jq -r ".items[].spec.containers[].name" 84 | ``` 85 | 86 | ### `kubectl apply --help` 87 | 88 | –> **apply** komutunun nasıl kullanılacağı ile ilgili bilgi verir. Ama `kubectl pod –-help` yazsak, bu pod ile ilgili **bilgi vermez.** Bunun yerine aşağıdaki **explain** komutu kullanılmalıdır. 89 | 90 | ### `kubectl explain pod` 91 | 92 | \--> **pod** objesinin ne olduğunu, hangi field’ları aldığını gösterir. 93 | 94 | \--> Çıkan output'ta **Version** ile hangi namespace’e ait olduğunu anlayabiliriz. 95 | 96 | ### `kubectl get pods``-w` 97 | 98 | \--> kubectl'i izleme (watch) moduna alır ve değişimlerin canlı olarak izlenmesini sağlar. 99 | 100 | ### `kubectl get all``-A` 101 | 102 | \--> Sistemde çalışan **tüm object'lerin durumunu** gösterir. 103 | 104 | ### `kubectl exec -it -c -- bash` 105 | 106 | \--> Pod içerisinde çalışan bir container'a bash ile bağlanmak için. 107 | 108 | ## Hızlı Kubectl Config Değiştirme 109 | 110 | Hızlıca config değiştirmek için aşağıdaki bash scriptten yararlanabiliriz: 111 | 112 | {% code title="change.sh" %} 113 | ```bash 114 | #! /bin/bash 115 | 116 | CLUSTER=$1 117 | 118 | if [ -z "$1" ] 119 | then 120 | echo -e "\n##### No argument supplied. Please select one of these configs. #####" 121 | ls ~/.kube |grep config- | cut -d "-" -f 2 122 | echo -e "######################################################################\n" 123 | #array=($(ls -d * |grep config_)) 124 | read -p 'Please set config file: ' config 125 | cp -r ~/.kube/config_$config ~/.kube/config 126 | echo -e '\n' 127 | kubectl cluster-info |grep -v "To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'." 128 | kubectl config get-contexts 129 | kubectl get node -o wide |head -n 4 130 | else 131 | cp -r ~/.kube/config-$CLUSTER ~/.kube/config 132 | if [ $? -ne 0 ]; 133 | then 134 | exit 1 135 | fi 136 | echo -e '\n' 137 | # kubectl cluster-info |grep -v "To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'." 138 | kubectl config get-contexts 139 | echo -e '\n' 140 | kubectl get node -o wide |head -n 4 141 | echo -e '\n' 142 | fi 143 | ``` 144 | {% endcode %} 145 | 146 | Kullanım: 147 | 148 | \--> Config dosyası `config-minikube` şeklinde oluşturulmalıdır. Script çalıştırırken config prefix'i ekliyor. 149 | 150 | ``` 151 | ./change.sh 152 | 153 | ./change.sh minikube 154 | ``` 155 | -------------------------------------------------------------------------------- /kurulum.md: -------------------------------------------------------------------------------- 1 | # 📀 Kurulum 2 | 3 | Tüm komutlar, kube-apiserver üzerinden verilir. Bu komutlar 3 şekilde verilebilir: 4 | 5 | 1. **REST Api** aracılığıyla (terminalden curl olarak vb.), 6 | 2. **Kubernetes GUI** (Dashboard, Lens, Octant) üzerinden, 7 | 3. **Kubectl** aracılığıyla (CLI). 8 | 9 | ## Kubectl Kurulumu 10 | 11 | * Homebrew ile aşağıdaki komutu yazıyoruz. (kubernetes.io’da farklı kurulumlar mevcut) 12 | 13 | ``` 14 | brew install kubectl 15 | ``` 16 | 17 | * Test için `kubectl version` yazabilirsiniz. (Server bağlantısı yapılmadığı için o kısımda hata alınabilir, normaldir.) 18 | 19 | ## Kubernetes Kurulumu 20 | 21 | ### Hangi version’u kuracağız? 22 | 23 | * En light-weight version için -> **minikube**, **Docker Desktop (Single Node K8s Cluster)** 24 | * Diğer seçenekler -> **kubeadm, kubespray** 25 | * Cloud çözümler -> **Azure Kubernetes Service (AKS), Google Kubernetes Engine, Amazon EKS** 26 | 27 | ### Docker Desktop 28 | 29 | * Docker Desktop, Single Node Kubernetes Cluster ayağa kaldırmaya imkan tanıyor. Bu durum, **başka bir araca duymadan Kubernetes üzerinde işlem yapabilme yeteneği kazandırıyor.** Ama tavsiye olarak **minikube kullanılmasıdır!** 30 | * Docker Desktop içerisinde K8s kurulumu için, Settings > Kubernetes’e gidip install etmeniz gerekiyor. 31 | 32 | ### :large\_blue\_diamond: Minikube 33 | 34 | * Bir çok addon ile gelebiliyor. Tek bir komut ile cluster’ı durdurup, çalıştırabiliyoruz. 35 | 36 | ``` 37 | brew install minikube 38 | ``` 39 | 40 | * **minikube kullanabilmek için sistemde Docker yüklü olması gerekiyor.** Çünkü, Minikube background’da Docker’ı kullanacaktır. VirtualBox gibi bir çok tool’u da background olarak kullanabiliriz. 41 | * Test için `minikube status` 42 | 43 | #### **Minikube üzerinde K8s Cluster Kurulumu** 44 | 45 | Varsayılan olarak Docker’ı background’da kullanır. 46 | 47 | ```shell 48 | minikube start 49 | 50 | minikube start --driver=virtualbox # VirtualBox background'ında çalıştırmak için. 51 | ``` 52 | 53 | Test için 54 | 55 | ```shell 56 | minikube status 57 | kubectl get nodes 58 | ``` 59 | 60 | **Kubernetes cluster’ı ve içeriğini (tüm podları) silmek için** 61 | 62 | ```shell 63 | minikube delete 64 | ``` 65 | 66 | **Kubernetes cluster’ını durdurmak için** 67 | 68 | ```shell 69 | minikube stop 70 | ``` 71 | 72 | ## :warning::warning:\[WIP] kubeadm Kurulumu 73 | 74 | \-> Kubernetes cluster’ı oluşturmamızı sağlayan başka bir platformdur. minikube’e göre daha gelişmiştir. Rassbery Pi üzerinde de çalışabilir :) 75 | 76 | > **Buraya yazılacak diğer tutorial’lar:** 77 | > 78 | > * Google Cloud Platform’unda Kurulum, 79 | > * AWS'de Kurulum, 80 | > * Azure'da Kurulum. 81 | 82 | ## Play-with-kubernetes Kurulumu 83 | 84 | * Eğer cloud için kredi kartınızı vermek istemiyorsanız ya da hızlıca bazı denemeler yapmak istiyorsanız, **play-with-kubernetes** tam size göre. 85 | * 4 saatlik kullanım sınırı var. 4 saat sonra sistem sıfırlanıyor, ayarlar gidiyor. 86 | * Browser based çalışır. 87 | * Toplam max 5 tane node oluşturabiliyorsunuz. 88 | 89 | ## Tools 90 | 91 | * **Lens -->** Kubernetes için çok iyi hazırlanmış bir yönetim tool'u. 92 | * **kubectx -->** Hızlı config/context geçişi için. 93 | * **Krew -->** kubectl için plugin-set'leri 94 | -------------------------------------------------------------------------------- /label-selector-annotation.md: -------------------------------------------------------------------------------- 1 | # 🏷 Label, Selector, Annotation 2 | 3 | ## Label Nedir? 4 | 5 | * Label -> Etiket 6 | * Selector -> Etiket Seçme 7 | 8 | ÖR: `example.com/tier:front-end` –>`example.com/` = Prefix (optional) `tier` = **key**, `front-end` = **value** 9 | 10 | * `kubernetes.io/`ve `k8s.io/` Kubernetes core bileşenler için ayrılmıştır, kullanılamazdır. 11 | * Tire, alt çizgi, noktalar içerebilir. 12 | * Türkçe karakter kullanılamaz. 13 | * **Service, deployment, pods gibi objectler arası bağ kurmak için kullanılır.** 14 | 15 | ## Label & Selector Uygulama 16 | 17 | * Label tanımı **metadata** tarafında yapılır. Aynı object’e birden fazla label ekleyemeyiz. 18 | * Label, gruplandırma ve tanımlama imkanı verir. CLI tarafında listelemekte kolaylaşır. 19 | 20 | ### Selector - Label’lara göre Object Listelemek 21 | 22 | * İçerisinde örneğin “app” key’ine sahip objectleri listelemek için: 23 | 24 | ```yaml 25 | --- 26 | apiVersion: v1 27 | kind: Pod 28 | metadata: 29 | name: pod8 30 | labels: 31 | app: berk # app key burada. berk ise value'su. 32 | tier: backend # tier başka bir key, backend value'su. 33 | ... 34 | --- 35 | ``` 36 | 37 | ```shell 38 | kubectl get pods -l --show-labels 39 | 40 | ## Equality based Syntax'i ile listeleme 41 | 42 | kubectl get pods -l "app" --show-labels 43 | 44 | kubectl get pods -l "app=firstapp" --show-labels 45 | 46 | kubectl get pods -l "app=firstapp, tier=front-end" --show-labels 47 | 48 | # app key'i firstapp olan, tier'ı front-end olmayanlar: 49 | kubectl get pods -l "app=firstapp, tier!=front-end" --show-labels 50 | 51 | # app anahtarı olan ve tier'ı front-end olan objectler: 52 | kubectl get pods -l "app, tier=front-end" --show-labels 53 | 54 | ## Set based ile Listeleme 55 | 56 | # App'i firstapp olan objectler: 57 | kubectl get pods -l "app in (firstapp)" --show-labels 58 | 59 | # app'i sorgula ve içerisinde "firstapp" olmayanları getir: 60 | kubectl get pods -l "app, app notin (firstapp)" --show-labels 61 | 62 | kubectl get pods -l "app in (firstapp, secondapp)" --show-labels 63 | 64 | # app anahtarına sahip olmayanları listele 65 | kubectl get pods -l "!app" --show-labels 66 | 67 | # app olarak firstapp atanmış, tier keyine frontend değeri atanmamışları getir: 68 | kubectl get pods -l "app in (firstapp), tier notin (frontend)" --show-labels 69 | ``` 70 | 71 | * İlk syntax’ta (equality based) bir sonuç bulunamazken, 2. syntax (set based selector) sonuç gelir: 72 | 73 | ```yaml 74 | kubectl get pods -l "app=firstapp, app=secondapp" --show-labels # Sonuç yok! 75 | kubectl get pods -l "app in (firstapp, secondapp)" --show-labels # Sonuç var :) 76 | ``` 77 | 78 | ### Komutla label ekleme 79 | 80 | ```shell 81 | kubectl label pods