Docker – Kubernete Bileşenleri ve İlişkileri

Docker – Kubernete Bileşenleri ve İlişkileri

Start-up bir projede Monolithic yapıdan vazgeçip Microservisler üzerinde kurulması ve ilerlenmesi için alt yapı gerekliliklerinde yola çıktığım araştırmalarda karşılaştığım teknolojiler, mimarlar, yapılar ve bunların birbirleri ile olan ilişkilerini yazıya dökmek istedim.

Docker

Docker gerçekleştirilecek olan uygulamaları altyapıdan ayırarak, geliştirme, taşıma, test ve production ortamlarında takım arkadaşlarına hız, esneklik ve kolaylıklar sağlayan açık platformdur.
Docker vs. Virtual Machine
Peki VM’lerimize ne oldu? Hypervisor ile Docker’ı birbirinden ayıran özellik nedir?
Docker runC(libcontainer) kullanarak host işletim sistemi dosyalarının ortak kullanılmasını sağlıyor. Bu sayede işletim sistemi kaynaklarını tekrar tekrar oluşturmayarak saniyeler içinde yüzlerce container oluşturturabilir olur ve çok az bir alan kapladığını görebilirsiniz.
Ayrıca Docker, Continuous Delivery, Continuos Integration(CD/CI) iş akışları için kullanımı yaygın ve büyük avantajdır.
VM’lerde ise bilindiği üzere her bir VM birbirinden tamamen izoledir, herbiri için işletim sistemi dosyaları tekrar oluşturulacak ve dolayısıyla kaynak tüketimi fazla olacaktır.
Avantajları ve dezavantajları vardır. Burada seçim, yapınızın ihtiyacına ve önceliğinize bağlıdır. VM’ler ile full izole bir altyapı oluşturur güvenilirliği daha ön planda tutabilirsiniz. Fakat processlere önem veriyor ve esneklik istiyor iseniz Docker ile devam etmeniz daha uygun olabilir.

Docker Engine

Docker Daemon dockerd komutlarını kullanarak müdahale ettiğimiz yapının en temel birimi. Fakat genellikle docker CLI komutları ile REST API katmanına parametreleri kullanarak istekler atacağız ve daemondan gerekli işlemlerini yapmasını isteyeceğiz.

 

Docker Architecture

Images:

Image’lar basit olarak Docker containerlarını oluşturmak maksadı ile gerek Docker Hub’dan, registry’den gerekse kendiniz oluşturarak kullanabileceğiniz read-only template’lerdir. Örn. Ubuntu, Apache, Nginx vs.

Containers:

Containerlar base image alınarak oluşturulan, birbilerinden ve host’dan izole olarak çalışan, Docker API ile kontrol edilebilen instancelardır. Ayrıca oluşturulmuş bir container’dan da dockerfile ile base image yaratabilirsiniz.

Kubernete

Yapınızda Containerlar kurdunuz, Microservis platformu kullanıyorsunuz, cloud ortamında seri ve etkili hareket etmek ve üzerinizdeki iş yükünü otomize etmek istiyorsunuz. Yapınızdaki oluşturulmuş containerları ne ile otomizasyona bağlayacak, thresholdlar belirleyip aksiyonlar alacak, scale-up-horizantal yapacaksınız. Burada bir orchestrator ihtiyacı doğmaktadır.
Kubernete google geliştiricileri tarafından oluşturulmuş, container yapılarının yönetimi, iletişimi, konfigurasyonu ve otomasyonu gibi işlemleri yerine getirir.
Peki Docker kendisi bu süreci yönetecek bir ürün geliştirmedimi evet “Docker Swarm” fakat rakamlar gösteriyorki son zamanlarda tercih edilen ürün genel olarak Kubernete platformu olmaktadır. Tabi teknoloji savaşından ziyade maksadımız teknolojiyi anlamak devam ediyoruz.

Pods:

Podlar Kubernete içindeki deployable en küçük birimdir. Pod bir veya daha fazla containerdan oluşur, genel kullanımı bir container olsada kaynakların paylaşımlası gereken bazı durumlarda birden fazla container da içerebilir.
Podları bir kağıt ile sarılmış container olarak düşünebilirsiniz ve controller ile yönetilmektedir. Bir pod manuel veya controller ile oluşturulduğunda otomatik Clusterınız içerisindeki Node içerisinde koşmaya başlar. Eğer Node silinir veya bir şekilde fail olur ise içerisindeki pod’lar da yani data da silinmektedir.
Controller’lar aracılığı ile bir Node üzerindeki hata durumunda içerisindeki Pod yeni bir Node üzerine taşınabilmektedir.

Pod template örnek:

Deployments:

Deploymentlar cluster’ınızda yapının arzu edilen durumunu yerine getirir. Parametreler belirleyerek Podlar oluşturabilir, Podları replika saylarını belirleyebilir, yük aşımı durumunda Podları ölçeklendirebilir, upgrade veya downgradeler yapabilirsiniz. Deploymentlar sadece istediğiniz konfigürasyonları yerine getirmekle kalmaz aynı zamanda clusterınızı belirlediğiniz standartlarda monitor ve maintain işlemlerini de gerçekleştirir.
Örneğin oluşturduğumuz nginx-deployment.yaml dosyası ile 3 adet nginx bir araya getirerek replica oluşturulmaktadır.

 

Services:

Servisler podlarımızı mantıksal gruplaramalarda yardımcı olur ve farklı Node’lardaki Pod’ların haberleşmesini sağlar. Bir önceki örneğimizde Node fail olması durumunda Pod un Node değiştirmesinden bahsetmiştik. Bu durumun gerçekleşmesi için gerekli ana yapılardan birisi deployment haricinde servislerdir de. Her bir pod unique IP’ye sahiptir, aynı Node içerisindekiler dahil. Serviceler aracılığı ile Podlar arası network iletişimi sağlanmaktadır ve load balance yapılabilmektedir.
Servisler ise Pod’ları “Selector” ve “Label” aracılığı ile tanır. Bu tanımlamayı Deployment(.YAML) içerisinde yaparız.
Aşağıdaki .yaml servis dosyası “php” selector’e sahip podların 80 TCP üzerinden hizmet vereceğini yani “expose” edileceğini belirlemektedir.

 

 

Aşağıdaki resimde Node, Service, Label ilişkisini görebilirsiniz.