Kubernetes Nedir?
Bu yazımızda container orchestration konusunda de-facto konumuna gelmiş, CNCF (Cloud Native Computing Foundation)’ ın ilk mezun projesi olan Kubernetes hakkında konuşacağız. Kubernetes; Google mühendisleri tarafından Borg adı altında geliştirilen ve daha sonradan open-source community’e bağışlanmış Go programlama dili ile yazılmış bir “Container Orchestration” yazılımıdır. Tabii Kubernetes’in mikroservis mimarisi için gereken özellikleri sunması, cloud-native uygulamaların ihtiyaç duyduğu platformu sağlaması popülerleşmesini iyice hızlandırdı. Kubernetes’in her bileşeni ayrı bir makale oluşturulabilecek derinliğe sahip olduğu için bu yazıdaki amaç yazıyı okuyan kişilerin Kubernetes hakkında high-level olarak bilgi sahibi olmasıdır. Kubernetes’den bahsetmeden önce üzerine inşa edildiği Containerization teknolojisine kısaca değinmek faydalı olacaktır.
Containerization Nedir?
Containerization sözlük anlamı olarak “Full Machine Virtualization”a alternatif olarak ortaya çıkmış, machine virtualization’a nazaran daha lightweight bir çözüm sağlayan, uygulamaların containerlar içerisine bağımlı oldukları kütüphaneler ile enkapsüle edilip, izole bir şekilde çalışmasını sağlayan bir teknolojidir.
Container teknolojisi ortaya çıkmadan önce yazılımların ölçeklenebilmesi için Virtual Machine’ler kullanılırdı. VM’lerin yönetimi, izlenebilirliği, kaynak tüketimi, birbirleri arasındaki iletişim containerlara nazaran çok daha zahmetli ve masraflıdır. Temel olarak, Virtualization’da makinaların üzerinde bir Hypervisor çalışır. Hypervisor üzerinde çalışan her VM’de ise ayrı bir Guest OS vardır.
Virtualization’ın bu sorunlarından dolayı büyük yazılım firmaları uzun bir süredir container teknolojisi kullanır oldular. Enterprise dünyada ise Containerization “Docker” ile kullanılmaya başlandı diyebiliriz.
Docker Nedir?
Docker, Linux Kernel üzerinde çalışan bir containerization teknolojisidir.
Docker’in Docker Daemon ve Docker Client olmak üzere başlıca iki bileşeni vardır. Komut satırından yazdığımız docker build, docker run gibi methodlar REST çağrısı olarak Docker Daemon’a iletilir. Docker Daemon da aldığı bu istekleri ilgili host makina üzerinde gerçekleştirir ve client’a cevabı döner.
Docker üzerinde çalıştırılan containerlar aynı linux kernel’ini paylaşır. Örnek olarak, Ubuntu 18.04 dağıtımı üzerinde çalışan bir container ile CentOS 7.6 dağıtımı üzerinde çalışan bir container ayağa kaldırdığımızı varsayalım. Her iki container’a giriş yapıp kernel versiyonlarını kontrol ettiğimiz zaman Docker Engine’in üzerinde çalıştığı host makinanın kernel versiyonuyla aynı olduğunu görürüz.
Docker ve Kernel
İlk çıktığı zamanlarda Docker containerization yeteneklerini LXC containerlardan almaktaydı. 2014 senesinden sonra Docker, LXC yerine kendi geliştirdiği libcontainer kütüphanesi ile containerization sağlamaya devam etti. İlk çıktığı zamanlar Docker büyük bir monolithic uygulamaydı. Tabii Docker modüllere parçaladıktan sonra container çağrıları containerd üzerinden gerçekleştirilmeye başlandı. Docker containerları ise opencontainers/runc (runC) üzerinde çalışmaktadır.
Bütün bu yeteneklerin temelinde ise Linux Kernel’in başlıca namespaces ve Control Groups (cgroups) özellikleri vardır.
Namespaces
Containerlar arasındaki isolation’ı sağlamak için aşağıda listenen namespacelerden faydalanılmaktadır.
- PID namespace (process isolation)
- MNT namespace (filesystem mount points)
- IPC namespace (IPC resources)
- UTS namespace (Kernel and version identifiers)
- NET namespace (Network interfaces)
Control Groups (cgroups)
Control Groups ile de containerların kullandığı kaynaklar kontrol edilebilmektedir.
- CPU
- Memory
- Network Bandwith
- Disk
- Priority
Belirtilen cgroups ve namespaces özellikleri sayesinde Docker tarafından oluşturulan containerlar birbirlerinden izole, kaynakları izlenebilir ve kontrol edilebilir şekilde çalışabilmektedir.
Peki neden Container Orchestration’a ihtiyaç duyuyoruz?
Şu ana kadar anlattığımız senaryolarda tek bir host makina üzerinde çalıştırılan bir Docker Engine ile containerization yapıldığı durum hakkında konuştuk. Ne yazık ki bu durum Production ortamları için gerçekten uzak bir durumdur. Production ortamlarında birden fazla server üzerinde birden fazla uygulama çalıştığından dolayı sunucu kümesinin kaynaklarının takip edilebilmesi ve çalıştırılması gereken containerların kaynak olarak en uygun server üzerinde çalıştırılması gibi akıllı kararlara ihtiyaç vardır. İşte bu akıllı kararları vermek için bir container orchestration yazılımı kullanılır.
Container Orchestration Çözümleri
Container orchestration çözümü olarak olarak aşağıdaki ürünleri sayabiliriz.
- Kubernetes
- Docker Swarm
- CoreOS Fleet
- Mesosphere Marathon
- Amazon Elastic Container Service
- CloudFoundry’s Diego
Aslında container orchestration ilk ortaya çıktığı zaman orchestration konusunda CoreOS ürünü çok öne çıkmıştı. Öyle ki containerization çözümü için Docker, orchestration çözümü için CoreOS paket halinde tavsiye edilirdi. Sonradan bu iki community birbirleriyle ters düştü ve Docker da kendi orchestration çözümü olan Docker Swarm’ı ortaya çıkardı, CoreOS ise kendi container çözümü olan rkt’i geliştirdi.
Her ne kadar Kubernetes harici ürünlerde container orchestration çözümü sağlasa da önceden belirttiğimiz gibi son zamanlarda Kubernetes container orchestration’da de-facto durumuna geldi. Firmalarda bu trend sonucunda kendi container orchestration ürünlerini geliştirmekten ziyade Kubernetes’e destek vermeye başladılar. Örneğin; CoreOS artık Fleet üzerinde geliştirme yapmayacağını duyurdu ve kullanıcılarına Kubernetes kullanmalarını tavsiye etmeye başladı. Docker kendi ürünü olan Docker Swarm geliştirmesine rağmen native olarak Kubernetes’i desteklemeye başladı. Örneğin; Docker for Mac indirildiğinde Kubernetes direk olarak Docker Desktop arayüzünden aktif hale getirilebiliyor, AWS’de Elastic Container Service (ECS) olmasına karşın AWS AKS (Amazon Kubernetes Engine) servisini ortaya çıkardı.
Kubernetes Objeleri
Pod
Kubernetes’de en küçük deployment unit Pod’dur. İçerisinde bir veya birden fazla container bulunabilir. Sözlük anlamı olarak “balina sürüsü” anlamını taşır. İlk duyduğumda Docker’in simgesi balina olduğu için ve birden fazla docker containeri içerisinde bulundurabilen Kubernetes bileşenini “balina sürüsü” anlamına gelen Pod’u kullanmak çok akılcı gelmişti. Bir başka önemli özelliği ise Kubernetes’in her Pod’a unique bir IP vermesidir.
Service
Service, podların mantıksal olarak gruplayıp servis olarak dışarıya sunmamızı sağlayan objedir. Buradaki mantıksal gruplama ise Kubernetes’in sunduğu Labels & Selectors ile mümkündür. Podları etiketleyip service olarak tanımlarken seçiciler kullanarak gruplayabiliyoruz.
Bir service NodePort, LoadBalancer, ClusterIP veya externalName yöntemleri ile expose edilebilir. Örnek olarak aşağıdaki resimde 3 Node’lu bir Kubernetes Clusteri gözükmektedir. İlgili Service ise NodePort üzerinden expose edilmiştir. Her bir Kubernetes Node’unda 30000 portu belirtilen servise bağlanmıştır.
Headless Service
Normal şartlarda bir service oluşturulduğunda service’e bir clusterIP atanır. Dolayısıyla service DNS üzerinden sorgulandığı zaman service’e atanan clusterIP’si döner.
Peki biz service’e bağlı olan podların IPlerinin hepsini dönmek istiyorsak yada client, service’e bağlı olan bütün podlara erişmek istiyorsa ne yapmalıyız? İşte bu gibi durumlarda headless service kullanılmaktadır. Headless service clusterIP ataması yapılmamış olan servistir. Headless Service DNS üzerinden sorgulandığı zaman bağlı olduğu bütün podların IPlerini cevap olarak döner.
Persistent Volume & Persistent Volume Claims
Containerlar üzerinde olan dosyalar (ephemeral data) bir yere persist edilmediği için containerin açıp kapanması sonrasında veri kaybedilir. Bu sebepten dolayı containera yazılan verilerin bir yere persist edilmesi gerekir. Örneğin; Bir Pod crash olursa, yeni bir Pod kubelet tarafından tekrar ayağa kaldırılır ama container içerisine yazılan veriyi kaybetmiş oluruz. Bu soruna çözüm olarak Kubernetes PersistentVolume (PV) objesini kullanmaktadır. PersistentVolume’lar ise PersistentVolumeClaim (PVC)’ler aracılığı ile kullanılabilmektedir. Persistent Volume’ların tıp ki podlar gibi bir hayat döngüsü vardır.
PersistentVolume cluster içerisinde kurulan herhangi bir storage’ı kullanacak şekilde yaratılabilir. Örnek: NFS, iSCSI, host-path. Oluşturduğumuz PersistentVolume ilgili Pod veya Deploymentlara PersistentVolumeClaim ile mount edilir. Cloud’da kullanılan Kubernetes Clusterlarda PersistentVolumeClaim ile mount edilen storage direk olarak provision edilir. Dolayısıyla Cloud’da sıradışı bir durum olmadıkça herhangi bir PersistentVolume yaratmaya gerek yoktur.
DaemonSet
DaemonSet objesi ile bütün Kubernetes workerlarında bir pod olarak çalışacak uygulama ayağa kaldırılabilir. Buradaki kritik nokta her bir Kubernetes workerında sadece bir podun çalıştırılmasıdır. ReplicaSet’de böyle bir kıstas yoktur. ReplicaSet’de oluşturulacak podlar herhangi bir node’a da schedule edilebilir.
DaemonSet’e örnek vermek gerekirse, Kubernetes Clusterımızda çalışan bütün servislerin loglarını toplamak istediğimizi farzedelim. Bunun için EFK (ElasticSearch-Fluentd-Kibana) stackini kullanmaya karar verdik. Bu stackde Fluentd logları toplayıp ElasticSearch’e ileten agent rolünü üstlenir. Bütün sistem üzerindeki containerları dinlemek için fluentd’yi DaemonSet olarak tanımlarız ve bütün kubernetes workerlar da otomatik olarak ayağa kalkmasını sağlarız. Monitoring gibi durumlar için gerçekten çok kullanışlı bir objedir.
ReplicaSet
Yatay olarak ölçeklendireceğimiz podların çalışması gereken replica sayılarını vererek ReplicaSet olarak çalıştırabiliriz. Örnek vermek gerekirse, replica:3 olarak verilmiş bir ReplicaSet belirtilen poddan kesinlikle 3 tane çalışacağını garanti eder. Podlar zaman zaman hata verse bile tekrar ayağa kaldırmaya çalışır.
Deployment
Deployment ReplicaSet’in yanında rolling update yapma imkanı veren ilgili podu ve replica sayılarını belirttiğimiz bir Kubernetes objesidir. Deployment, arka tarafta ReplicaSet kullanmaktadır. Birden fazla ReplicaSet kullanabildiği için de rolling update yapma şansına sahiptir. Aynı şekilde bir önceki versiyona rollback yapma imkanı da verir. Bir nevi Blue/Green deployment yeteneği kazandırır.
Örneğin; yeni bir versiyona geçerken bütün pod’ları öldürüp downtime yaratarak yeni versiyona sahip podları ayağa kaldırmaz. Ayarlanabilen rolling update oranı ile yeni versiyon’a sahip podları ayağa kaldırır ve eski versiyona sahip olan podları öldürür.
3 replica’lı bir deploymenti 5 replicaya da çıkartabiliriz yada 2 replicaya da düşürebiliriz. Hatta çeşitli metrikler dinleyerek auto-scaling yeteneği de kazandırabiliriz.
StatefulSet
Şu ana kadarki konuştuğumuz konular herhangi bir state tutmayan stateless servisleri kapsıyordu. Ama DB gibi state tutma ihtiyacı duyan uygulamalar için Kubernetes’de StatefulSet kullanılması önerilir. Biliyoruz ki Kubernetes’de persist etmek istediğimiz veriyi PersistentVolume şeklinde tutuyoruz. Persist ettiğimiz veri ile Pod ayrı node’a schedule olursa veri pod tarafından erişilemez duruma gelir. Clustered olarak çalışan bir uygulama göz önüne alındığında ise bu çok olası bir durumdur. Bu durumun engellenmesi için de StatefulSet kullanırız.
StatefulSet, scaling-up ve scaling-down işlemlerinde podları sıralı olarak ayağa kaldırır ve sıralı olarak siler. Ayrıca oluşturulan podların tekilliğini garanti eder. 3 replicalı bir StatefulSet yarattığımızı düşünelim. Deployment’ in aksine StatefulSette podlar X-1, X-2, X-3 gibi belirli bir identity ile isimlendirilir.Podlar ayağa kalkarken ilk X-1, sonra X-2 sonra X-3 ayağa kalkacağını biliriz. Aynı şekilde StatefulSeti silerken de ilk olarak X-3 kill edilir, sonra X-2 en son da X-1 kill edilir. Bu isimlendirmeyi yapabilmek için de StatefulSet bir Headless Serviceden faydalanılır.
Data integrity’sini sağlamak içinde yaratılan StatefulSet’ler silindiği zaman kullandıkları PersistentVolumelar silinmez.
Kubernetes Bileşenleri Nelerdir?
Kubernetes’de başlıca Kubernetes Master ve Kubernetes Worker olarak iki tip bileşenden oluşur. Aşağıdaki resimde de gözüktüğü gibi Kubernetes master kube-apiserver, scheduler ve controller manager’dan, Kubernetes Worker ise kubelet, kube-proxy ve container runtime ‘dan meydana gelir. Container runtime olarak resimde Docker gösterilmektedir ama rkt gibi farklı tip containerları da kullanilabilmektedir. Kubernetes tıpkı Docker gibi Server-Client mimarisi üzerinde çalışır. Kubernetes Client’i olarak kubectl, server olarakta Kubernetes Master’da bulunan kube-apiserver istekleri dinlemektedir.
Kubernetes Master Bileşenleri
kube-apiserver
Kubernetes; API Server ile REST bir servis sağlar ve client ile yapılan istekleri dinler. kubectl ile yaptığımız işlemler ile API Server’ındaki endpointleri çağırmış oluruz bir nevi. Başka bir deyiş ile, biz her kubectl komutu çalıştırdığımızda API Server’a bir REST çağrısı yapmış oluruz ve API server’dan dönen cevabı da çıktı olarak görürüz.
etcd
Kubernetes üzerinde persist edilen bütün konfigürasyon ve durumların tutulduğu high-available modda çalışabilen consistent bir key-value store’dur.
kube-scheduler
Kubernetes Master üzerinde çalışan ve yeni yaratılan Pod’ların atanacağı Node’ları karar veren bileşendir.
Yaratılan Pod’un kaynak gereksinimleri, hardware/software/policy kısıtları, affinity & anti-affinity gibi spesifikasyonlar, inter-workload interference, data locality, Job Deadline gibi maddelerin hangi node’a atanacağı konusundaetkisi vardır.
kube-controller-manager
Kube-controller-manager Kubernetes Master üzerinde Controller sınıflarını çalıştıran bileşendir. Başlıca kullanılan controllerlar aşağıda listelenmiştir.
- Node Controller: Node’ların ayakta olup olmadığını kontrol eder.
- Replication Controller: Pod’ların olması gereken replica sayısına gelmesini sağlar.
- Endpoints Controller: Pod ve Services’lerin Endpoint’lerini yaratır.
- Service Account & Token Controllers: Yeni namespaceler için default accounts ve API Access tokenları yaratır.
Kubernetes Node Bileşenleri
kubelet
Her bir kubernetes node’unda çalışan agent’tır. İlk işi bulunduğu node’u API Server’a Node resource olarak kayıt ederek Kubernetes tarafından görülmesini sağlamaktır. Bu işlemden sonra sürekli olarak API server’i dinleyerek bulunduğu node’a herhangi bir Pod schedule edip edilmediğini kontrol eder. Schedule eden bir Pod varsa bulunduğu node üzerinde Pod’un içerisindeki tanımlanan containerları çalıştırır. Kubernetes haricinde yaratılan containerları yönetemez.
Buna ek olarak sürekli olarak node’da çalışan containerların ayakta olup olmadığını kontrol ederek erişilebilir olmalarını sağlar.
kube-proxy
Kubernetes Service ve Endpoint objelerinin erişebilirliğini sağlamak için node üzerindeki network kurallarını ayarlar ve connection forwarding işlemini gerçekleştirir. Görevlerinden biride Kubernetes Service’lere virtual IP atamasıdır.
Userspace, iptables ve IPVS (IP Virtual Server) olarak üç modu vardır.
Aslında ilk çıktığında kube-proxy userspace modu ile tam bir proxy gibi davranırdı. Client ile pod’ların arasında girip birbirleri ile iletişimlerini sağlar.
iptables modu ile proxy olmak yerine iptables ayarlarını ayarlayan bileşen halini aldı. kube-proxy’nin default modu iptables modudur. netlink interface’ini kullanır ve Service clusterIP ve Port’una gelen istekleri ilgili podlara yönlendirmek için iptables kuralları ekler.
Bunlara ek olarak bir de IPVS moduna sahiptir. IPVS ise iptables’ın daha performanslı halidir. Iptables modu 5000 node’dan sonra Kubernetes’de bir darboğaz oluşturur. Iptables’in ölçeklenemediği durumlar için IPVS modu tercih edilir. IPVS; Kernel space içerisinde çalışan bir Layer 4 load-balancerdir.
Container Runtime
Containerları ayağa kaldıracak container runtime’ı belirtir. Kubernetes Docker, containerd, cri-o, rktlet container runtime’larını destekler.
Kubernetes’in Yetenekleri
Kubernetes tabii tek başına container orchestration yapmanın yanı sıra bir çok özellikte sağlamaktadır. Mikroservis mimarisi kullanıyorsanız, cloud-native uygulamalar geliştiriyorsanız veya 12-factor apps’e uygun SaaS yazılım geliştirmek için platform arıyorsanız Kubernetes bu ihtiyaçlarınıza çözüm olabilir. Aşağıda Kubernetes’in yetenekleri detaylandırılmıştır.
Container Scheduling
Eğer birden fazla host makineye sahip bir deployment ortamınız var ise oluşturulacak containerların hangi node üzerinde çalışacağına karar verir.
Networking
Dağıtık bir server mimarisinde servisleri birbirleri arasındaki iletişimi sağlamak kolay bir problem değildir. Kubernetes podların birbirleri ile iletişimini CNI (Container Network Interface) üzerinden çözümler. CNI, containerlar üzerindeki network interfacesleri ayarlamak için gerekli olan spesifikasyonları ve kütüphaneleri sunan bir projedir. Buradaki amaç container networking gibi kompleks bir konuda çıkacak ürünler arasında standardı sağlamaktır.
Implemente edilecek CNI standartları dışında CNI plugin’ler Metod ve yaklaşım itibariyle farklılık gösterir. Popüler olarak kullanılan CNI pluginler aşağıda listelenmiştir.
Burada en önemli konu Kubernetes CNI plugin ile Pod’a tekil bir clusterIP atamasıdır. Her pod cluster içerisinden out-of-the-box erişebilir şekilde ayağa kalkmaktadır. Bu konuya ek olarak kube-proxy sayesinde Service objesi kullanılarak servislerin dışarıdan veya içeriden erişilebilir durumda olması sağlanır. Basitçe anlatmak gerekirse, Service’e bir tane virtual IP tanımlanır ve bu virtual IP’ye karşı bir veya birden fazla Pod bağlanır.
Service Registry & Discovery
Service Registry & Discovery servislerinin birbirleri ile iletişim için ihtiyaç duydukları bir özelliktir. Deployment ortamları dinamik olduğu için ve servislerin belli bir statik IPleri olmadığı için, dinamik olarak atanan IPlerin bir şekilde sorgulanabilmesi gerekecektir. Burada Kubernetes’in Service objesi aracılığıyla servisler birbirlerinin adreslerini IP olarak çözümleyebilmektedir.
Kubernetes’de Service Discovery için ise DNS kullanılır. Servisler birbirlerinin IP’lerini resolve etmesi için DNS üzerinden sorgulama yaparlar. Bu altyapıyı sağlamak için kube-dns veya CoreDNS kullanılır. DNS Controller, API server aracılığı ile pod ve servicelerin durumlarını takip eder ve otomatik olarak DNS kayıtlarını ayarlar.
Örneğin; mikroservis mimarisi üzerine geliştirilen müşteri ile ilgili bilgileri tutan customer-service adında bir servisimiz olduğunu düşünelim. Bu servisi başka servisler üzerinden çağırmanın en pratik yöntemi http://customer-service:8080 formatında bir URL ile çağırıp, ilgili servisin IP’sini DNS üzerinden çözülmesini beklemektir. İşte bu durumda customer-service service olarak ayağa kalktığı zaman DNS Controller tarafından DNS’e kayıt edilir ve başka servisler tarafından bulunması sağlanır.
Environment Management
Namespaces ve Authorization objeleri sayesinde Kubernetes Clusterı içerisinde uygulamaları, servisleri birbirinden ayırabiliriz. Bu özellik sayesinde Staging, Production gibi ortamlar birbirlerinden izole bir şekilde aynı Kubernetes Cluster’i üzerinde çalışabilir.
Resource Management
Linux Kernel’in sunduğu cgroups özelliği sayesinde ve ilgili containerization teknolojilerinin desteklediğinden ötürü podlara atanacak CPU, Memory gibi kaynaklar üzerinde çeşitli istekler veya kısıtlamalar LimitsRange objesi üzerinden belirtilebilir. Hatta ilgili namespace üzerinde ResourceQuota objesi üzerinden kısıtlamalar uygulanabilir. Örneğin; staging ortamı 40 GB RAM’den fazla kaynak tüketmesin gibi. Özetle, sadece podların kaynak yönetimi için LimitRange, Namespace’deki ilgili bütün podlar için ResourceQuota kullanılır.
Load Balancing
Kubernetes Service tanımladığımız zaman otomatik olarak Load Balancing özelliğini de eklemiş oluruz. Örneğin; payment-service olarak 3 ayrı pod oluşturduk ve bu podları Kubernetes Service ile expose ettik diyelim. Service objesi üzerinden üretilen endpoint ile gelen istekler otomatik olarak bu 3 poda load balanced bir şekilde iletilecektir. Serviceler arası load balancing yapmak için de Kubernetes Ingress objesinde faydalanılır.
API Gateway
Kubernetes Ingress objesi ile oluşturduğumuz servisleri dış dünyada açabiliriz. Gelen isteğin context pathine, user-agentına yada gelen request üzerinde herhangi bir değere göre servis yönlendirmesi yapabiliriz.
Configuration Management
Kubernetes’in içerisinde bulunan etcd componenti ve Kubernetes ConfigMap objesi sayesinde uygulamalarımızın konfigürasyonunu parametrik olarak ayarlayabiliriz. Bu sayede bir konfigürasyon değiştirmek için uygulama tekrar deploy etmek zorunda değildir ve bu özellik runtime’da konfigürasyon değiştirmemize olanak sağlar. Bunu ister environment variable olarak ilgili podlara veririz ister direk olarak dosya bazında konfigurasyon dosyalarını volume olarak atarız. Bir başka deyişle, ConfigMap objesi ile ise Kubernetes kullanıcılarına out-of-the-box bir configuration management altyapısı sağlamaktadır.
Aşağıdaki şemada nginx konfigurasyonu fortune-config adındaki ConfigMap’de my-nginx-config.conf anahtarı ile tutulmaktadır. Bu konfigurasyon volume ile ilgili poda dinamik olarak mount edilir.
Secret Management
Kubernetes secret objesi ile verinin base64 ile encode edilip saklanmasına imkan verir. Tabii burada secret data encryption’ı da uygulayarak verinin tamamen güvenli olması sağlanabilir. Unutmamak gerekir ki base64 bir encryption değildir. Verinizi şifrelemez.
Örnek kullanım senaryosu olarak da Nexus Private Docker Registry’den docker image indirdiğimiz durumu ele alabiliriz. Burada deployment dosyasında podlara imagePullSecrets: üzerinden vereceğimiz bir secret anahtarı ile private docker registrye login olmuş oluruz.
Resilience & Fault Tolerance
Kubernetes Master’da bulunan Replication Controller bileşeni sayesinde, yaratılan podlar minimum kaç replica ile çalışacağı kontrol edilir. Herhangi bir pod hatasında, ilgili Replication Controller tekrar bir pod ayağa kaldırır. ReplicaSet, StatefulSet gibi objeler de Fault-Tolerant servisler yaratmamıza olanak verir.
Bunun yanı sıra Kubernetes’in livenessProbe ve readinessProbe özelliklerine sahip health-checking mekanizması sayesinde servisler daha güvenilir şekilde hizmet verir.
LivenessProbe bir servis endpointinin client tarafından erişilebilir olup olmadığını kontrol eder, readinessProbe ise ilgili servisin functional durumda olup olmadığını kontrol eder.
Server tarafından ele alınmayan bir hata durumunda serverin sürekli “HTTP 500 Internal Server Error” cevabı verdiğini farzedelim. Bu örnekte de gördüğümüz gibi bir servisin ayakta olması onun fonksiyonlarının sorunsuz bir şekilde çalıştığını garanti etmez. Bu durumu engellemek için de readinessProbe üzerinden servisin fonksiyonel olup olmadığı kontrol edilir.
Auto-Scaling
CPU, RAM ve I/O gibi çeşitleri sistem metrikleri incelenip Kubernetes clusterındaki uygulamaların horizontal olarak scale-up veya scale-down olması sağlanabilir. Bu yetenek ile anlık yoğun bir yük altında sistemin herhangi bir darboğaza girmemesi sağlanır.
Job Management
Kubernetes üzerinde Job objesi ile batch olarak çeşitli işler yapmak üzere görevler tanımlanabilir. CronJob objesi ile de aynı Unix’de olduğu gibi belirli periyotlarda tetiklenecek işler tanımlanabilir
