Kubernetes Concepts

Bu yazıda kubernetesin çalışma prensibi ve temel konseptlerinden bahsedeceğiz.

Kubernetes (k8s) en temel tanımıyla, container iş yüklerimizi yönetmemize yarayan bir araçtır. Temelde çalışma prensibi olarak uygulamamızı containerized edip kubernetese teslim ediyoruz ve o da çalıştırıyor. Çalıştırma işlemini master üzerinden (Apı Server’a gönderilen istekle) worker node’lara yaptırıyoruz.

Örnekle anlatacak olursak AngularJs ile yazdıgımız bir uygulamamız olsun:

• Uygulamamızı container haline getiriyoruz. (ör. bir docker imajını oluştururuz)
• Daha sonra bunun bir manifestini yazarız. Bunu yaml veya json veri değişim formatında oluştururuz. Bu yaml dosyasında uygulamanın özelliklerini belirtiyoruz.
• Bu dosyayı api-server aracılığıyla K8s’e sunuyoruz. k8s’de bu bildiriye uygun şekilde uygulamamızı ayağa kaldırıyor.

K8s master-worker

Kubernetes mimarisinde temelde iki ana konseptten bahsedebiliriz. Bunlar Master ve Worker Node’lardır. İdealde K8s, bir master ve birden çok worker olacak şekilde çalışıyor. Teorikte, yüksek kapasiteli tek bir worker kurup tüm iş yüklerini onun üzerine teknik olarak kurmak mümkün fakat pratikte bu tercih edilmiyor, çünkü K8s’in highly available özelliğini kullanmamış oluyoruz aslında. Worker node’lar üzerine iş yuklerimizi load balance edecek şekilde çalışmak k8s’in bize getirdiği özelliklerden bir tanesi.

Master: İşin yönetildiği kısım (control plane)

• API server
• Scheduler
• Controller-Manager
• etcd

Worker: İş yüklerinin çalıştığı kısım.

• Kubelet
• Kube-proxy
• Container runtime

— — — Master — — —

• Api-server: K8s’in ana bileşenidir. Cluster’daki her şey bu sunucuya bağlanarak konuşur. Yapılabilecek çağrıları veya talep türlerini, bunların nasıl yapılacağını, kullanılması gereken veri formatlarını, izlenecek kuralları vb. tanımlar. Bir gateway gibi davranır.
• Scheduler: İş yükünün hangi worker üzerinde çalışacağına, uygulamanın nerede start verecegine karar verir. Her pod için uygun bir worker seçer ve storage backend’deki pod definition’ları günceller. (Podlar containerların üzerinde çalıştıgı yapılardır, yazının devamında detaylı bahsedeceğiz)
• Etcd: K8s’in hafızası diyebileceğimiz cluster store. Etcd’yi, tum Cluster’a dağıtık bir key-value store tabanlı çalışan bir database gibi düşünebiliriz. Cluster’daki bilgeleri saklar ve diğer componentler bu bilgileri kullanır. Uygulama verilerini saklamaz ve ayrıca persistent volume kullanır.
• Controller-manager: Resource State’lerin spesifikasyonlarla eşleşmesini sağlar.

Özetle master: Depolama için Etcd, bileşenler arasındaki iletişim için API sunucusu, hangi node bölmelerinin çalıştırılacağına karar veren operasyonel işleri yöneten scheduler ve mevcut durumu istenen duruma göre kontrol etmekten sorumlu controller manager’dan oluşur.

— — — Worker — — —

Kubelet: Üzerinde çalıştığı worker’ın master ile olan tüm iletişimini yönetir. Control plane’in worker node’a erişmesini ve üzerinde işlemler yapmasını sağlayan bir agent programıdır. Worker Node’ları cluster’a register eder, eventleri ve Pod Status’lerini, resource kullanımını rapor eder. K8s’deki birincil ve en önemli denetleyicidir. Container execution layer’ı (docker,containerd) drive etmekten sorumludur.

Kube-proxy: Tüm network event’lerinin üzerinden geçtiği, aynı zamanda load balancing için de fayda sağlayan, tüm Worker’larda çalışan bir Network Proxy’dir. Bir pod’a erişmek kube-proxy üzerinden olur.

Container runtime: Containerların çalışmasından sorumlu yazılımdır. Docker, containerd örnek verilebilir.

Özetle: Kubectl ile API Sunucusuna gelen bilgiler, Controller Manager sayesinde Storage Backend’e (etcd) gelir. Scheduler buradaki değişiklikleri kontrol eder ve bu bilgileri Kubelet’e gönderir.

• Görsel üzerinde işleyişi anlatacak olursak, ilk olarak kubectl commandları ile Api Server’a gönderdiğimiz istek bir deployment yaml kurma komutu olsun. “kubectl apply -f mydeployment.yaml” gelen istek Etcd’ye yazılır. Controller bu isteğin ne oldugunu kontrol eder ve ör. 2 instance’lı deployment kurulacakmış diye Scheduler’a bu bilgiyi (yine api server üzerinden) gönderir. Schedular worker’ları check eder ve bind edilecek worker’a karar verir. Apı-server üzerinden tekrar biz hazırız mesajı gönderir. Bu mesaj, Sheduler’dan gelen mesajları izleyen Worker’lardaki Kubelet’e iletilir. Bu, ara adımlardaki tüm mesajlar, Etcd’ye yazılır ve okunur. Kubelet gelen bildiri sonrası Pod Status’leri güncellediğine dair bir mesaj tekrar api server üzerinden Etcd’ye yazdırır ve son adımda runtime aracına podu ayağa kaldırmasını söyler.
• Admin olarak bunu yaptık, şimdi user olarak bu poda erişmek istiyoruz diyelim. Öncelikle bu uygulamımızı (Podumuzdaki Container’ı) dış dünyaya expose etmemiz gerek. Bunun için K8s’de Service objeleri bulunuyor. “kubectl expose pod <pod_ismi> — type=NodePort — name=nginx-svc” komutu ile bu servisimizi NodePort tipinde dışarı açalım. Bu komut bize bir tunel oluşturacak. User olarak Pod’a atanan port ve üzerinde çalıştığı Node’un Ip’si ile uygulamaya erişebiliyoruz artık.

Key Components

Pod:

• Docker için container ne ise kubernetes için pod odur diyebiliriz.
• Containerların çalışma alanıdır.
• Teknik olarak bir pod içinde birden çok container çalışabilir fakat pratikte bir Pod’da yalnızca bir container çalışması tercih ediliyor. Pod öldüğünde aynı imajdan yeni(içinde Container’ımızın çalıştığı) bir pod ayağa kalkıyor.
• Bir ölçekleme birimidir. Docker’da bir Container’ın 3 Instance’ını yaratıyorsanız K8s’de de podu ölçekleriz.
• Kubernetes containerları pod’ların içerisinde çalıştırır.
• Pod’lar Worker Node’lara dağıtık şekilde çalışmaz, yani bir pod bir worker üzerinde deploy edilip çalışabilir.
• Bir arıza sıkıntı olmadıgı müdettçe çalışırlar, aksi durumda yok edilirler.
• Pod, Kubernetes tarafından yönetilebilen en küçük konuşlandırılabilir birimdir. (basic scheduling unit)

Deployment:

• Versiyonlanabilir rest objeleridir. Yaml dosyası, bir manifest olarak tanımlayabiliyoruz. Örnegin, bana 2 mysql, 3 angularJs ayağa kaldır ve şu versionlarda olsun, diyebiliyoruz.
• Bir kere hazırlanıp birden çok yere deploy edilebilir.
• Yaratılacak Pod’ların Blue-print’leridir. Podlara rolling update özelliği kazandırır.

Service:

• K8s cluster kendi içinde bir network’u var, bunun içinde tüm podların kendi Ip’lerine sahip. Service denilen objelerin arkasında ise bir veya birden çok pod barınabiliyor. Podların yaşam döngüleri oldugu için, ölen podun Ip’si yok olur fakat service objeleri sayesinde yeni ayaga kalkan poda yeni Ip atanarak Service’ler üzerinden bu poda erişim otomatik olarak devam eder.
• Dns özelliğine de sahiptir ve aynı zamanda arkasında çalışan podlara trafiği yönlendiriyor load balance etkisi de var diyebiliriz.
• Trafiği sadece healthy olan podlara yönlendirir.
• Default olarak Tcp protokolü ile calışır.