Bu makale, modern yazılım geliştirmede uygulama konteynerleştirmeye ve bulut sağlayıcı konteyner orkestrasyonuna odaklanır; bu sayede uygulamalarımızı yinelenebilirlik, sürdürülebilirlik, gözlemlenebilirlik ve yüksek erişilebilirlikle, maliyet etkin bir şekilde ve felaket kurtarma sağlayarak herhangi bir iş yükü talebine göre dağıtıp dinamik olarak ölçeklendirebiliriz.
Kısaca
- Konteynerler, uygulamalarımızı bir platformdan bağımsız, hızlıca başlatılıp kopyalanabilen, hafif imajlar olarak paketlememizi sağlar.
- Konteyner orkestrasyon motorları, öngörülemeyen ve büyük dağıtık hesaplama iş yüklerini dinamik olarak yönetmemize olanak tanır.
- AWS EKS, en popüler konteyner orkestratörlerinden biridir ve çok sayıda AWS hizmetiyle sıkı bir entegrasyon sunar.
- Tek bir komutla karmaşık makine öğrenimi veya veri bilimi Kubernetes uygulamalarını dağıtmak için Helm chart’larını kullanın.
Neden Konteynerler?
“Neden” sorusunu, “ne”yi ele almadan yanıtlamak neredeyse imkânsızdır; bu yüzden konteynerlerin çözmeyi hedeflediği sorunlarla ve bir konteynerin ne olduğuyla başlayalım ki “neden”i yanıtlayabilelim.
Eski yazılım mühendisliği modelinde geliştiriciler kodlarını yerel makinelerinde yazar, ardından test ortamına dağıtım yapılır ve sonrasında üretime çıkarılırdı. Bu modeldeki sorun, ortamlar arasındaki tutarsızlıklar ile çeşitli sunucularda çalışan bağımlılıklar ve kütüphanelerdi.
Dolayısıyla, “benim makinemde çalışıyor” (klasik bir geliştirici sözü) dediğimiz bir uygulama, hedef ortamdan çok farklı sürümlerde çalışma zamanı kütüphanelerine bağlı olabilir ve bu da dağıtım sonrası beklenmedik davranışlara yol açabilir.
Konteynerler bunu, derlenmiş kodu, kütüphaneleri, bağımlılıkları ve çalışma zamanlarını bir “imaj” içinde paketleyerek uygulama katmanını bütünüyle soyutlayarak çözer.
Bir konteyner imajı daha sonra Docker gibi bir konteyner motorunun, herhangi bir ortamda öngörülebilir davranışla hızla dağıtıp çalıştırabileceği bir şablon olarak kullanılabilir.
Konteynerlerin çözdüğü bir sonraki sorunlar ölçeklenebilirlik, sürdürülebilirlik ve maliyet etkinliğidir. Tarihsel olarak, üretim ortamları yüksek hacimli veya iş açısından kritik uygulamaların münhasır kullanımı için ayrılan (pahalı) donanım kaynaklarından oluşurdu. Bu pahalı ortamların sürekli yönetim, bakım ve yamalanması gerekirdi.
Bu tür uygulamalara ayrılan donanım miktarının zirve yükü karşılayacak şekilde en yüksek düzeyde olması gerekirdi; ancak uygulamalar her zaman tutarlı ve öngörülebilir kullanım örüntülerine sahip değildir. Bu da yoğun olmayan zamanlarda büyük miktarda donanımın atıl kalmasına yol açar.
Çözüm, konteyner orkestrasyonudur.
Bir konteyner imajı platformdan bağımsız olduğundan, konteyner hesaplama kaynakları, bir konteyner motorunu çalıştırma kapasitesi olan herhangi bir sunucu kullanılarak, talebe göre artırılıp azaltılabilir; bu da alttaki sunucu işletim sisteminin bakımının uygulamadan ayrıştırılması anlamına gelir.
Bu durum, açıkça maliyet etkinliğini etkiler; çünkü konteynerlerimizi mevcut talebi dinamik olarak karşılayacak şekilde yönetip orkestre edersek, çıplak donanımı en verimli şekilde kullanmış oluruz.
Bu açıklama “kuş bakışı” bir görünüm sunuyor; sonraki bölümlerde derinlere ineceğiz, ancak devam etmeden önce konteynerlerin bazı pratik kullanım alanlarından söz edelim.
Veri Bilimi ve Makine Öğrenimi için Konteynerler
Veri bilimi ve makine öğrenimi uygulamaları yüksek derecede hesaplama yoğun olmaya eğilimlidir
bazen öngörülemeyen kullanım örüntülerine sahiptir ve çok büyük miktarda veriyi işler.
Bu tür uygulamalar, bir problemi böl ve fethet yaklaşımıyla çözmek ve sonuçları bir veri deposunda kalıcı hale getirmek için sıklıkla paralelleştirmeden fayda sağlar. Bu büyük bir sadeleştirme olsa da, bu tarz uygulamaların konteynerler ve konteyner orkestrasyonu için mükemmel bir uyum olduğu hemen açıktır!
Öyleyse, tüm bu bilgilerle donanmışken “nasıl” kısmına geçelim. Bu makalenin sonunda ise Helm’den söz ederken veri bilimi ve makine öğrenimi uygulamaları arasındaki bağlantıya yeniden döneceğiz ve bir konteyner orkestrasyon motoru içinde konteyner olarak dağıtılmış karmaşık uygulamaları asgari çaba ve yapılandırmayla nasıl çalıştırabileceğimizi konuşacağız.
Piyasada birçok konteyner motoru var; ancak bu makalede en popüler olan Docker’ı kullanacağız. Platforma aşinalık kazanmak için Docker’a Giriş eğitimimize göz atabilirsiniz.
Sanal Makineler (VM) ve konteynerler
Sanal makineler fiziksel donanımı soyutlayarak bir sunucuyu bir hipervizör aracılığıyla birden fazlasına dönüştürür ve birden çok VM’in aynı ana makineyi paylaşmasına olanak tanır. Her VM’in bir misafir işletim sistemi (OS) vardır.
Konteynerler ise uygulama katmanında bir soyutlamadır. Üzerine bir konteyner motoru kurulu bir sunucu, aynı anda birden çok konteyneri, alttaki OS’i paylaşarak çalıştırabilir. Konteynerler hakkında daha fazla bilgiyi konteynerleştirme eğitimimizde bulabilirsiniz.
Buradaki temel fark, konteynerlerin ana makinenin OS’ini kullanması ve bir VM’in aksine kendi OS’leriyle paketlenmemesidir. Bu da onları çok daha hafif, kopyalanması, çalıştırılması ve yok edilmesi daha hızlı hale getirir; aynı zamanda konteynerler arasında güvenlik izolasyonu ve hata toleransı avantajlarını da sağlar (bir konteyner çökerse, diğer konteynerleri etkilemez).
Ayrıca daha iyi kaynak kullanımı anlamına gelir; dolayısıyla, benzer alttaki donanım özellikleri göz önüne alındığında, tek bir Docker motorunda VM’lerin bir hipervizörde çalışabileceğinden daha fazla konteyner çalıştırılabilir.
Docker imajı ve konteyner
Bir Docker imajı, yapılandırmayı, kodu, bağımlılıkları ve çalışma zamanını paketler. İmajlar, Docker içinde konteyner örneklerini kopyalayıp çalıştırmak için bir şablon görevi görür. Bir konteyner, Docker’ı destekleyen herhangi bir platformda çalışabilir.
Konteyner orkestrasyonu
Artık konteynerler hakkında her şeyi bildiğimize göre, onları yönetmenin bir yoluna ihtiyacımız var. Piyasada birkaç orkestratör bulunuyor; fakat bu makalede AWS bulutunda Elastic Kubernetes Service (EKS) altında çalışan Kubernetes’e odaklanacağız.
EKS’nin yönettiği bazı temel görevler şunlardır:
- Dağıtım
- Ölçeklendirme
- Yük dengeleme
- İzleme
- Servis keşfi
- Kendini iyileştirme
AWS hizmetleri
EKS’yi açıklamaya başlamadan önce, EKS’nin temelini oluşturan bazı AWS bulut hizmetlerini anlamamız gerekiyor.
CloudWatch
Günlükler, metrikler ve olaylar biçiminde veri toplayan izleme ve gözlemlenebilirlik hizmeti.
VPC
Sanal Özel Bulut, her AWS hesabı için güvenli şekilde korunan ve yönetilen mantıksal olarak ayrılmış bir ağdır.
ELB
Elastic load balancer, trafiği birden çok hedef arasında dağıtabilen, yüksek erişilebilirlikli bir ağ bileşenidir.
IAM
Kimlik ve Erişim Yönetimi, AWS hesapları için ayrıntılı erişim kontrolü sağlar.
ECR
Elastic Container Registry, tamamen yönetilen bir docker imaj konteyner kayıt deposudur.
EC2
Elastic Cloud Compute (iki C harfi nedeniyle kısaltılmıştır), birçok hizmetin temelini oluşturan çekirdek bir AWS hizmetidir. Müşterilerin uygulamalarını çalıştırabilecekleri sanal sunucuları kiralamalarına olanak tanır.
Bölge (Region)
Veri merkezlerinin kümelenebildiği fiziksel bir konumdur; örneğin, EU-WEST-1 (İrlanda) ve EU-WEST-2 (Londra).
AZ
Kullanılabilirlik bölgesi, kendi yedekli güç, ağ ve bağlantısına sahip bir veya daha fazla ayrık veri merkezidir. Bir bölge birden çok AZ’den oluşur.
Route53
Yüksek erişilebilirlikli bir DNS hizmeti.
WAF
Web Uygulama Güvenlik Duvarı; erişilebilirliği etkileyebilecek, güvenliği tehlikeye atabilecek veya aşırı kaynak tüketebilecek yaygın istismar ve botlara karşı uygulamaları korumaya yardımcı olur.
Kubernetes Temelleri
Kubernetes bazen K8s olarak anılır. Bunun nedeni, Kubernetes’te K harfi ile S harfi arasında sekiz harf bulunmasıdır.
Küme (Cluster)
EKS, yönetilen bir K8s kümesi sağlar. Bu, en üst düzey bileşendir ve tüm servisler, düğümler ve pod’lar için bir kapsayıcı görevi görür.
EKS; CloudWatch, Elastic Container Repository (ECR), IAM, API Gateway, Elastic Load Balancer (ELB), CodePipeline, Secrets Manager ve daha fazlasıyla sıkı bir entegrasyona sahiptir.
En temel örneği ele alırsak, konteyner imajlarını ECR’de depolayabilir ve uygulamamızı, birden çok kullanılabilirlik bölgesine dağıtılmış bir VPC içine konuşlandırılan ve tüm sistem ve uygulama günlüklerini CloudWatch’a yayınlayan EKS tarafından yönetilip çalıştırılacak şekilde yapılandırabiliriz.

Master/kontrol düzlemi
Master düğüm, K8s’in kalbidir ve düğümlerin yönetilmesine, izlenmesine, zamanlanmasına ve planlanmasına yardımcı olur. Birkaç alt bileşeni vardır.
ETCD
Tüm kritik küme verilerini kalıcı hale getiren bir anahtar-değer deposudur
Kube scheduler
Zamanlayıcı, konteynerleri düğümlere dağıtır
Kube controller manager
Küme bileşenlerinin doğru durumda olmasını sağlar; istenen iş yükünün fiili iş yüküne eşit olduğundan emin olur.
API
Küme dışından yapılan tüm etkileşimler K8s API üzerinden gerçekleşir.

Düğümler (işçi düğümler)
Bir EKS işçi düğümü bir EC2 örneğidir. Her düğüm, konteynerleri çalıştırmak için kurulu docker runtime’a, master ile tüm iletişimleri yöneten Kubelet ajanına ve düğümler arası iletişime olanak tanıyan K-proxy’ye sahiptir.
Düğümlerin CloudWatch ile entegre olabilmesi için düğümün IAM rolünün CloudWatchLogsFullAccess ilkesini içermesi gerekir.

Pod
Bir pod, dağıtılabilir en küçük birimdir. Gerekebilecek yardımcı (sidecar) konteynerlerle birlikte tek bir uygulama konteyneri çalıştırır. Her pod geçicidir ve benzersiz bir IP adresine sahip olacaktır.

Dağıtımlar ve Kopya setleri

Bir kopya seti, pod’ları etiketle yönetir ve belirli bir iş yükü için her zaman kararlı bir pod kümesinin çalışır durumda olmasını sağlar. Bir pod düşerse, o pod’u geri yüklemek kopya setinin görevidir.
Dağıtımlar, kopya setlerini yönetir. Bir kopya seti düşerse onu geri yüklemek dağıtımın görevidir. Dağıtımlar, aşamalı (rolling), kademeli (ramped), yeniden oluşturma (re-create) veya kanarya (canary) olarak yapılandırılabilir (dağıtım türlerinin ayrıntıları bu makalenin kapsamı dışındadır).
Servisler
Bu makalenin amacı doğrultusunda, bir servisin doğrudan bir AWS Application Load Balancer’a (ALB) —bir ELB türü— eşlendiğini düşünebiliriz. Aslında bundan biraz daha fazlası var; fakat ALB’nin masaya getirdiği bazı faydaları anlamak önemli:
- Bir DNS adı ilişkilendirme
- Sağlık kontrolleri
- Birden çok AZ boyunca yüksek erişilebilirlik
- WAF
- Erişim günlükleri
Bir servisin birincil işlevi, trafiği düğümler/pod’lar arasında dağıtmaktır.
Konteyner Ölçeklendirme
ASG ve EC2
EC2’nun temel bir bileşeni Otomatik Ölçeklendirme Grubudur (ASG). Bu AWS bileşeni, genellikle bir yük dengeleyicinin arkasında, bir bölge içindeki birden çok AZ’ye yayılmış şekilde, arzu edilen iş yükünde bir EC2 örnek filosunu sürdürür.
CloudWatch metrikleri, ölçeğin artırılıp azaltılmasına yönelik tetikleyicileri sağlar.
Bu tür ölçeklendirme, uygulama sunucuları filosunun trafik taleplerini karşılamak üzere “yatay” olarak genişleyip daralabilmesi nedeniyle yatay ölçeklendirme olarak bilinir. Örnek bir ölçeklendirme politikası, tüm örnekleri %50 CPU kullanımının altında tutmak olabilir. Bu düzeyde, ASG normalde AZ başına eşit sayıda EC2 örneğini yönetecek şekilde yapılandırılır; ancak bu makalenin kapsamı dışında olan başka yapılandırmalar da mevcuttur.
HPA
EC2 düzeyinde ölçeklendirme ile pod düzeyindeki ölçeklendirme arasındaki farkı ayırt etmek çok önemlidir. Yatay Pod Otomatik Ölçekleyici (HPA), her düğüm içindeki pod’ların ölçeklendirilmesinden sorumludur. HPA, Metrics Server aracılığıyla toplanan K8s metriklerini kullanır (küme içinde kurulması gerekir ve EKS için varsayılan küme dağıtımının parçası değildir) ve pod’ları düğüm metriklerine göre ölçeklendirir. Örnek bir ölçeklendirme politikası, sanal CPU kullanımını %50 hedeflemek olabilir.
EKS Küme otomatik ölçekleyicisi
Küme otomatik ölçeklendirme, K8s servisini bir AWS ASG ile birlikte ölçeklendirmekten sorumlu, açık kaynaklı bir EKS küme otomatik ölçekleyicisinin kurulmasını gerektirir; ASG de sırayla, küme için sağlanan fiziksel örneklerin ölçeklendirilmesini yönetir.
Bir düğüm HPA ölçeklendirme politikasına göre maksimum kapasitesine ulaştığında, küme otomatik ölçekleyicisi başka bir EC2 örneği oluşturur ve bunu ASG’ye ekler.
Tüm Resim

Ölçeklendirme politikaları son derece esnek, özelleştirilebilir ve yapılandırılabilirdir; ancak genellikle, düzensiz ve dalgalı trafik talepleri nedeniyle gereksiz ölçeklendirmeyi önlemek için bir küçültme/içe ölçekleme gerçekleşmeden önce bir soğuma süresi içerir.
Bir pod vCPU sınırını aşarsa Kubernetes’in o pod’da çalışan uygulamayı kısacağını; ancak bir pod bellek sınırını aşarsa Kubernetes’in konteyneri yeniden başlatacağını not etmek önemlidir.
Maliyet optimizasyonu
m5.large örnek türünü kullanarak örnek içinde pod’ları nasıl sınırlayabileceğimize bir örnek:
2 * vCPU = 2000m (millicore)
8 GiB bellek
Pod kaynak kısıtlamaları:
- Ayrılan vCPU miktarı, örn. 500m
- vCPU üst sınırı, örn. 1000m
- Ayrılan bellek miktarı, örn. 256Mi
- Bellek üst sınırı, örn. 512Mi
Gözlemlenebilirlik
EKS Kaynak Görünümü
Kümede çalışan tüm kaynakları gösterir.

CloudWatch Container Insights
- İzleme
- Alarmlar
- Lambda fonksiyonlarını tetikleme
- Önceden oluşturulmuş panolar ve metrikler
- Tek tıkla kurulum

Helm
Helm, uygulamaların paketlenmesini, yapılandırılmasını ve dağıtımını otomatikleştiren bir Kubernetes paket yöneticisidir. Helm chart’ları, karmaşık Kubernetes uygulamaları oluşturmanıza, paylaşmanıza, sürümlendirmenize ve yayımlamanıza olanak tanır.
Veri bilimi ve makine öğrenimi alanında ilgi çekici bazı chart örnekleri şunlardır:
- Ml-workspace
- Mlflow
- Tensorflow
- Hive
- Spark
Bu K8s uygulamaları, tek bir komutla Helm aracılığıyla EKS kümenize dağıtılabilir!
Sonuç
Bu kapsamlı rehberde, AWS Elastic Kubernetes Service (EKS) ile konteyner orkestrasyonunun temellerini inceledik. Konteynerlerin temellerini ve veri bilimi ile makine öğrenimindeki gerçek dünya uygulamalarını anlamaktan başlayıp, AWS hizmetlerinin ve Kubernetes bileşenlerinin inceliklerine dalarak pek çok konuyu ele aldık. Konteyner orkestrasyonu dünyası karmaşık ama son derece ödüllendiricidir; ölçeklenebilirlik, sürdürülebilirlik ve maliyet etkinliği sunar.
İster geliştirici, ister veri bilimci, ister BT uzmanı olun, konteyner orkestrasyonunu öğrenmek araç setinizde tartışmasız değerli bir beceri olacaktır. İşletmeler bulut tabanlı çözümlere geçmeye ve mikro servis mimarilerini benimsemeye devam ettikçe, bu alanlarda uzmanlığa sahip profesyonellere olan talep de artacaktır.
Bilginizi pratiğe dökmeye hazır mısınız? DataCamp, Kubernetes, Docker ve bulut bilişim konularındaki anlayışınızı derinleştirmenize yardımcı olacak çeşitli kurslar sunuyor. Başlangıçtan ileri seviyeye, etkileşimli dersler, gerçek dünya zorlukları ve uzman eğitmenli eğitimlerle becerilerinizi geliştirebilirsiniz.
Faydalı bağlantılar
- En sık kullanılan komutlarla Kubectl kopya kâğıdı
- Yönetilen ölçeklendirmeli bir uygulamayı adım adım anlatan HPA eğitimi
- Basit bir uygulamayı küme otomatik ölçeklendirmesiyle kurup çalıştırmak için Küme otomatik ölçekleyici eğitimi
- Helm chart’ları
- AWS fiyatlandırma hesaplayıcısı
Öğrenmeye ve veriye tutkuyla bağlı, Tam Yığın Yazılım Mühendisi ve Çözüm Mimarıyım!

