Kubernetes kullanmalı mıyız?

İlk yazıda kubernetes konseptlerinden bahsedip genel mimariye göz atmıştık. Bu yazıda kubernetesin avantajları ve getirdiği çözümlerden kısaca bahsedeceğiz ve şu soruların çözümünü arayacağız; Gerçekten Kubernetese ihtiyacımız var mı? Kullanmamıza değer mi?

K8s getirileri:

Kubernetes, ekiplerin modern yazılım geliştirme gereksinimlerine ayak uydurmasını sağlıyor. K8s olmadan, büyük ekiplerin kendi deployment workflowları manuel olarak yazması gerekiyor. Bir orchestration aracıyla (k8s)combine edilen containerlar, sizin için makinelerin ve hizmetlerin yönetimini sağlıyor. DevOps’ta harcanan zaman ve kaynak miktarını azaltırken uygulamanızın daha reliable olmasını sağlıyor. K8s’in uygulamalarımızı daha hızlı dağıtmamıza olanak sağlayan bazı özellikleri olarak şunları söyleyebiliriz:

• Horizontal infrastructure scaling : Yeni sunucular kolayca eklenebilir veya kaldırılabilir.
• Auto-scaling: CPU kullanımına veya uygulama tarafından sağlanan diğer metriklere göre çalışan containerların otomatik scale-up veya scale-down olması sağlanabiliyor. Bu yetenek ile anlık yoğun bir yük altında sistemin herhangi bir darboğaza girmesi de önleniyor. Manual-scaling: Bir command veya interface aracılığıyla çalışan containerların sayısını el ile ölçeklendirebilir. Aynı zamanda dikey ve yatay ölçeklendirme yapılabiliyor.
• Traffic routing and load balancing: Traffic routing, istekleri uygun containerlara gönderir. Kubernetes ayrıca, yerleşik Load-balancer’larla birlikte gelir, trafik yüksekse dağıtımın kararlı olması için ağ trafiğini yükleyip dağıtabiliyor.
• Automated Rollout-Rollback: K8s, containerların durumunu izlerken yeni sürümler veya güncellemeleri downtime olmadan kullanıma sunar. Dağıtımın iyi gitmemesi durumunda, otomatik olarak geri alabiliyor. Version Control ile Rollout ve Rollback’i kolaylaştırıyor. Konuşlandırılmış containerlar için istenen durumu tanımlayıp, Current State’i, istenen State’e kontrollü bir hızda değiştirebiliyoruz. Kısaca rollout-rollback işlemi, Continuous Deployment’da blue-green ve canary gibi deployment metodlarına imkan sağlıyor. Yeni version deploy edildiğinde saglıklı çalıştığını kontrol edip onaylayana kadar diğer versiyonu saklaması, veya başarısız olması durumunda öncekini yeniden ayağa kaldırması Downtime’ları azaltıyor.
• K8s, Namespace yapısı sayesinde örneğin Staging ve Production gibi ortamlar birbirlerinden izole bir şekilde aynı Kubernetes Cluster’ı üzerinde çalışabiliyor. Cluster’ı farklı Clusterlar’a bölüyor gibi düşünebiliriz. Farklı geliştiriciler kendi Namespace’inde bağımsız çalışabiliyor.

Hangi senaryoda K8s’e ihtiyaç oluyor:

Production ortamlarında, birden fazla server üzerinde birden fazla uygulama çalıştığında, sunucu kaynaklarının takip edilebilmesi ve çalıştırılması gereken containerların kaynak olarak en uygun server üzerinde çalıştırılması gibi çözümlere ihtiyaç duyuluyor. Örneğin tek bir host makina üzerinde çalıştırılan bir Docker Engine ile yönetildiği durum, bu senaryolarda yetersiz kalıyor.

K8s bu noktada farklı ortamlarda çalışan birden çok containerı yönetmeyi ve takip etmeyi sistemli bir hale getiriyor. Containerları düzenlemek ve kullanıcı etkileşimini yönetmek için kolaylık sağlıyor. Container tabanlı uygulamaları dağıtmaya ve altyapıyı daha verimli kullanmaya olanak sağlıyor. Containerlerın çalıştıgı DevOps pipelinelar’ı otomatikleştirilebiliyor. Yazılım mimarisine yönelik mevcut yaklaşımlarda önde gelen bir teknoloji şuanda.

Kurumların sürekli olarak artan iş kapasitesi ile kendi başlarına bu yükleri kontrol etmesi zorlaştıkça Kubernetese ihtiyaç oluyor.

Peki K8s zorlukları neler?

Buraya kadar her şey tamam, fakat bu getirilerinin yanında, zorlukları neler? Duruma bir de şu açıdan bakalım:

Kubernetes güçlü bir araçtır, ama bu her ekip ve her uygulama için doğru seçim olduğu anlamına gelmez. Kubernetes’in çözmeyi amaçladığı sorunlarla karşı karşıya değilseniz, bu, değerinden daha fazla sorun demektir.

Çoğu uygulama hayatlarına monolit olarak başlar, tüm application tek bir yerdeyken, değişiklikleri yapmak ve dağıtmak hızlı ve kolaydır. Ancak uygulamanız belirli bir aşamaya ulaşır ve büyürse, onu ölçeklendirmenin yollarını bulmanız gerekecektir. Peki tam burada Kubernetes imdadınıza yetişiyor mu? Muhtemelen bunun cevabı hayır.

Scaling, genellikle üst düzey mimari ve araçlardan çok uygulamanın dahili özellikleriyle ilgilidir. Örneğin, affinity flags destekleyen bir load balancer ile birden çok instance’ı dağıtarak bir monoliti ölçeklendirebilirsiniz. Ek olarak, bir monolitin ölçeğini büyütmeye başladığınızda, Chef ve Ansible gibi configuration management araçları kullanışlı olabilir. Yeni sunucuları otomatik olarak yapılandırmak için bunları kullanabilirsiniz. Hatta bir adım daha ileri gidebilir ve yeni sunucu Vm’leri sağlamaya yardımcı olması için Terraform gibi bir araç kullanabilirsiniz, böylece bunları manuel olarak oluşturmak zorunda kalmazsınız.

AWS Elastic Beanstalk, Google App Engine veya Azure App Service gibi bulut hizmetlerini kullanarak monolitik uygulamaları bile otomatik olarak ölçeklendirebilirsiniz. Bunların tümü Kubernetes’ten çok daha az yönetim yükü getirir ve hepsi CI/CD araçlarıyla stabil çalışır.

Hangi çözümü seçmeliyim?

Kubernetes populer bir hale gelmesinden sonra bazı developer ve DevOps takımları K8s’e geçmezlerse development Pipeline’larının outdated olacağını düşünmeye başladı. Sağladığı bir çok kolaylık var evet ama microservise veya Kubernetese geçiş sihirli bir değnek değil. Gerçekten ihtiyacınız yoksa monoliti güçlendirme çözümüne gidebilirsiniz.

Birbirine bağlı hizmetlerin her zaman çalışır durumda olduğundan ve birbirlerine görünür olduğundan emin olmanız gerekiyor. Ek olarak müşterileriniz sizden, birden çok kullanılabilirlik bölgesinde, hatta muhtemelen birden çok Cloud Vendor’de çalışmanızı isteyen türden bir uptime ve reliability talep edebiliyor. Bu durumda kubernetes yukarı bahsettiğimiz avantajları ile çözüm olarak gelecektir. Burada şunu da söylemekte fayda var. K8s gelirken, aşağıdaki gibi bazı requirementları da beraberinde getiriyor:

• Bir kaç sanal makine çalıştırmak
• Kubernetes’in yapılandırmasını ve bakımını yapacak kişileri atamak.
• Birden çok servis ile ilgilenmek veya provider desteği almak.

Cluster oluşturmak ve yönetmek, podları define etmek ve Kubernetes’e dağıtım için uygun containerized uygulamalar oluşturmak zaman ve mühendislik kaynakları gerektirir. Özetle uygulamanız K8s kullanacak kadar büyüdüyse, bu yönetim yükü (administrative overhead) buna değer.

K8s neden zorlu, Provider desteği almak gerekli mi?

Kubernetes aslında bir Google projesiydi. Google tarafından bir ihtiyaç sonucu ortaya çıktı. Asılında Google yıllardır container orchestre ettikleri bu sistemin bir benzerini kendi production ortamlarında farklı isimlerle (borg) kullanıyorlardı. Daha sonra Kubernetes adıyla 2014 de açık kaynak haline getirdiler. Neden ihtiyaç duydular peki buna? Çünkü kendi ortamlarında çalışan belkide on binlerce containerları var ve bunları yönetmesi gerekiyor. Yani yazılımın çıktığı noktadaki karmaşıklık seviyesi bu. Evet K8s popular ama yönetimi, kurulumu basit olan bır yazılım degil. K8s güzel yanlarını almak istiyorsak bu karmaşıklığa, bunun yönetimine gerek olmayabilir. Bu iş yükünü manage service olarak saglayan Google, Amazon, Microsoft, Rancher gibi providerlara yüklemek mantıklı olabilir.

K8s’in temelde iki yapısı var; Control Plane (alt yapıyı yöneten kısmı) ve Workload (iş yüklerini yöneten kısmı). Bizim esas benefit alacağımız kısım bu workload yöneten kısım. Control plane kısmını providerlara bırakıp, burayla ilgilenmek mantıklı bir çözüm olarak görünüyor.

Karar aşaması:

Kubernetes’e deep-dive girmeden önce, mimariniz nasıl? Örneğin monolitic ortamda suan bır orcehstrasyon sorununuz var mı veya yaşayacak mısınız? Örnegin uygulamalarınızı farklı ortamlara 50–60 kez kuracak mısınız? Bu orchectrasyona ve yukarıdaki getirilere ihtiyac varsa, çözüm Kubernetes. Ama ihtiyaç oluşmadıysa veya ne zaman oluşacağını kestiremiyorsak gerek olmayabilir.

Uygulamanız bir mikroservice mimarisi kullanıyorsa veya bir mikroservice mimarisine geçiş yapmak istiyorsanız, Kubernetes size çok uygun olacaktır çünkü uygulamanızı zaten containerized etmişsinizdir.

K8s’e geçmeliyim:

Yavaş development ve deployment sorunu yaşıyorsanız. Bu sebeple müşteri taleplerini karşılayamıyorsanız, K8s sizin için operasyonel iş yüklerinize yardımcı olabilir. Takımınızın development ve deployment lifecycle için harcadığı zamanı sizin için etkili bir şekilde yönetebilir, böylece developerlar bununla ilgilenmez ve kendi zamanlarını production için harcayabilirler.

Daha düşük altyapı maliyetleri Kubernetes, container, pod ve cluster düzeyinde verimli bir kaynak yönetimi modeli kullanır ve clusterlarınızın uygulamaları çalıştırmak için yeteri kadar kullanılabilir kaynaklara sahip olmasını sağlayarak, eğer bulutdaysanız, bulut altyapısı maliyetlerini düşürmenize yardımcı olur.

K8s’e geçmemeliyim:

Simple, lightweight applicationlar ile çalışıyorsanız. Uygulamanız monolitik bir mimariyi kullanıyorsa, containerların ve bunları orkestre etmek için kullanılan bir aracın gerçek faydalarını görmek zor olabilir. Bunun nedeni, monolitik bir mimarinin doğasının, uygulamanın her parçasının iç içe geçmiş olmasıdır. Böyle bir mimaride gerek olmayabilir.

Kubernetes’in herkesin bildiği gibi dik bir öğrenme eğrisi vardır; bu, ekipleri eğitmek ve yeni bir çözümün zorluklarını ele almak vb. için çok fazla zaman harcayacağınız anlamına gelir. Denemeye ve risk almaya istekli bir ekibiniz yoksa, muhtemelen uygun seçim değildir.