Dağıtık yapıları ve özellikle konteyner üzerinden otomatik yönetilen mikroservis uygulamalarını cluster(küme) içerisinde barındıran, uygulamaların yüklenmelerini(deployment) ve bu yüklemeler üzerinde uygulamaların servis olarak sunulmasını kolaylaştıran bir yapıdır Kubernetes. Tüm bu özellikleri farklı yapılar üzerinden hızlı bir şekilde yerine getirebilmektedir.
Örneğin, klasik uygulama geliştirme yaşam döngüsünden bizler genelde çok kapsamlı uygulamalar geliştirdikten sonra uygulamanın canlı ortama alınması için sistemcilerle veya konfigürasyon işlerini yürüten kişilerle yoğun görüşmeler yaparız. İşte uygulama için şöyle güçlü makine gerekli, uygulamanın yeni versiyonları canlıya alınırken veya başka işler yaparken de sürekli ayakta kalmasını sağlamak için dengeleyici unsurları(load-balancing) şöyle olmalı, uygulamanın önünde güvenlik katmanı olmalı gibi birçok durumu da uygulamaya veya uygulatmaya çalışırız. Kubernetes gibi yapılarla network gibi, firewall gibi konuların konfigürasyon yapısını bilen yazılım geliştirici kişiler de çok kapsamlı uygulamaları neredeyse sistemciler gibi ayağa kaldırabilme ve uygulamanın birçok yük altında hayatta kalabilmesini sağlayabilme becerisine sahip oluyorlar. Yazılım yönü güçlü olan ve çoğunlukla sistem ve network işleriyle uğraşan insanların da işlerini çok çok kolaylaştırıyor tabi ki Kubernetes gibi yapılar. Elbette, Kubernetes yapısına ne kadar hakim olmaya başlasak da hem güvenlik açısından hem birçok açıdan sistemsel gereksinimlerini sistem alt yapısını bilen uzman kişilerle çalışarak Kubernetes kümesi(cluster) oluşturmak en sağlıklısı olacaktır.
Sürekli entegrasyon(Continuous Integration — CI) kurgusu üzerinden yürütülen uygulama geliştirme çalışmalarında da geliştirilen uygulamaların çok kolay bir şekilde hemen geliştirme veya canlı ortamlara aktarılması ve hemen uygulamaların hayata geçirilmesi sağlanabiliyor. Uygulamaların mikroservis yapısında kurgulanması da önemli değil Kubernetes açısından. Sonuçta bir network yönetimi Kubernetes, birçok özelliği ve işlevi içerisinde barındıran.
Ayrıca, Kubernetes yapıları, bulut teknolojilerini sunan sağlayıcıların ortamlarına da oldukça uyumlu olarak geliştirildiklerinden - örneğin Amazon, Azure ortamları - kendi ortamınızda geliştirilen Kubernetes üzerine kurulu yapılar-uygulamalar oldukça hızlı şekilde, birkaç konfigürasyon değişikliğiyle bulut ortamlarına taşınabilir.
Kubernetes’a biraz biraz alıştıkça şöyle durumlar aklınıza gelmeye başlıyor. Örneğin, node (düğüm) yapısıyla ilgili olarak, node’ları Kubernetes ortamına tek tek tanıtmamız gerekiyor, yani sanal ya da gerçek makineleri Kubernetes kümesine(cluster) eklememiz gerekiyor. Bunun bir sonucu olarak bu makineler(node’lar) üzerinden uygulamalarımızı servis olarak sunan ve yöneten Kubernetes içerisinde makinelerin yetersiz kalması durumunda yeni makinelere ihtiyaç olacaktır. Kubernetes, kendisine tanımlanan tüm makineler üzerinden her türlü yük dengeleme işlerini otomatik olarak yönetirken henüz kendisine tanımlanmayan makineleri nasıl keşfedecektir? Anlamsız gibi görünebilir bu ifade. Zaten tanımlı olmayan makinayı nasıl bulabilir ki diyebiliriz. Ama diyelim, belli bir IP aralığında olan tüm makineleri node(düğüm) olarak kullanabilirsin gibi bir özellik belki olabilirdi. Yani bu konuya ingilizce olarak Node-Scaling (düğüm ölçümleme)— Node-Autoscaling deniyor. Farklı çözümler, çalışma ortamları mevcut ve geliştirilmeye devam ediliyor, fakat hemen hepsi bulut çözümler sunan sistemler içerisinde yapılabiliyor. Şu ana kadar benim keşfedebildiğim ve anladığım kadarıyla Kubernetes küme(cluster) içerisinde node ölçümlemesine göre node eklenip çıkarılması özelliğini bulut çözümler harici sunan şöyle bir örnek mevcut: https://thenewstack.io/kube-node-let-k8s-cluster-auto-manage-nodes/
Ek bir konu daha, Kubernetes yapısında en tepede bir tane Master-Node(Yönetici Düğüm) makinesi bulunmakta (sanal makine de olabilir). Her otomatik işlemin yürütülmesi, yani tüm dengeleme işlemleri, servislerin bulunması gibi işler bu yönetici düğüm üzerinden idare ediliyor ve Kubernetes kümesi bu yönetici düğüm üzerinden dallanıyor. Bu nedenle Kubernetes yapısının doğal olarak bazı sınırları mevcut. Şu linkten detaylara ulaşılabilir: https://kubernetes.io/docs/setup/best-practices/cluster-large/
Örneğin bir Kubernetes kümesinde maksimum 5000 node(düğüm) bulunabilir. Bu kadar çok düğüm içeren bir küme yapısı ihtiyacı hiç oluşmasa bile de yine belli bir node sayısına ulaşıldığında bir tane Kubernetes küme yapısı yeterli kalmayabilir. Bu durumda çoklu küme(multi cluster) yapıları kurgulama gerekebilir. Bunlarla ilgili birçok çözüm internetten araştırılabilir.
Çok genel olarak Kubernetes nedir bahsetmiş olduk. Şimdi de uygulamaların hayat bulduğu POD içerisindeki konteyner yapılarında uygulama geliştirmecilerin işlerini kolaylaştıracak ve çalışma zamanında bile kimi yapıları ekleme çıkarma olanaklarına eriştiren yapılar da bulunmakta. Örneğin uygulamamızı geliştirirken RabbitMQ gibi yapıları kullanıyoruz ve isteğe bağlı olarak RabbitMQ yerine Azure Event Bus sistemlerini isteğe bağlı olarak kullanacak şekilde genel-geçişken, esnek geliştirmeler yapıyoruz. Bu sadece queue(kuyruk) mekanizmaları için ortaya konan esnek bir yapıydı. Güvenlik için de başka esnek yapılarımız da olabilir. Kayıt tutma(Logging) işleri için de esnek yapılarımızı uygulamalarımıza ekliyor olabiliriz. Diyelim queue için RabbitMQ yapısını kullanırken bir konfigürasyon ayarı değiştirip uygulamamızı tekrar yükleyip Azure Event Bus yapılarını kullanmak isteyebiliriz. Kodumuzu oldukça esnek yaparak sadece konfigürasyon değeri değiştirerek ve bu değişikliği uygulamayı tekrar yükleyerek gerçekleştirebiliyoruz. Şu anda öyle eklentiler var ki, örneğin DAPR (Distributed Application Runtime) gibi, tüm bu yan eklentileri çalışma zamanında bile değiştirilebilmesini sağlayabiliyoruz. Çünkü DAPR gibi yapılar uygulamalarımızın içinde değil uygulamalarımıza yapışarak böyle bir esnekliği sunuyorlar. Yani uygulamamızda herhangi bir değişiklik yapmadan DAPR konfigürasyon değişikliği ile çalışma ortamında hızlı değişiklikler elde edilebiliyor. Bu yapıların görebildiğim kadarıyla tek eksi yönü, ihtiyaca yönelik olarak otomatik şekilde oluşturulan ve yok edilen POD’lar içerisinde ek bir maliyet oluşturmalarıdır. Ama zaten milisaniyeler içerisinde yapılan bu işlemler en fazla birkaç milisaniye yük getirdiğinden göz ardı edilebilir bir maliyet olarak karşımıza çıkıyor. Yine ek olarak uygulamamızda kodsal ve konfigürasyon olarak bazı değişikliler yapmamız gerekecektir, uygulamamızın ve DAPR tarafının iletişim içerisinde olabilmesi için.
Bu yazıda özellikle Kubernetes’ın diğer temel kavramlarına girmedim. POD nedir, Node tam olarak nedir, Servis nedir. Bu yazıda Kubernetes’in ne olduğuna, ne amaçla kullanıldığına ve bir iki faydalı özelliğe değinmek istedim. Örneğin servis oluşturmadan yüklediğimiz uygulamaların dışardan erişilemez olduğu gibi konulara değinmedim, gerçi değinmiş oldum şu anda :) Zaten Kubernetes’ın kendi sitesinde sunulan kılavuzları incelenirse tonla terim ve detay var (özellikle network ve sistemsel işlerler ilgili olarak). Umarım, çok genel bir anlatım olsa bile, Kubernetes’in ne olduğunu anlatabilen bir yazı olmuş olur :)
M Cem Yaşar