Bulut kontrol düzlemi
Bulut kontrol düzlemi, altyapıyı sağlamanızı (provision), yapılandırmanızı ve yönetmenizi sağlayan arayüzler, API'ler ve hizmetler katmanıdır — iş yüklerinizi fiilen çalıştıran ve trafiğinizi taşıyan veri düzleminden ayrıdır. Her sağlayıcı kendi kontrol düzlemini sunar; terim aynı zamanda birden fazla sağlayıcıyı tek bir düzlem olarak yöneten sistemleri de kapsar.
Her altyapı parçasının iki ayrı katmanı vardır. Veri düzlemi altyapının kendisidir: uygulamanızı çalıştıran sanal makineler, aralarında paket taşıyan ağ, okuma ve yazma isteklerine hizmet eden disk. Kontrol düzlemi ise o altyapının nasıl görüneceğine karar vermek ve onu değiştirmek için kullandığınız her şeydir — API, konsol, CLI, kimin değişiklik yapmasına izin verildiğine karar veren yetki sistemi. Bir bulut konsolunda bir VM oluşturduğunuzda, bir diski yeniden boyutlandırdığınızda veya bir güvenlik duvarı portu açtığınızda kontrol düzlemini işletiyorsunuzdur. Başlatılan örnek, kullanıma açılan ek gigabaytlar, akmaya başlayan trafik — bunların hepsi veri düzleminin, kontrol düzleminin söylediğine verdiği yanıttır.
Bu ayrım, bir ekip birden fazla sağlayıcı işlettiğinde daha da önem kazanır. AWS'nin bir kontrol düzlemi vardır. Google Cloud'un, Azure'un, Hetzner'in ve diğer her sağlayıcının da vardır — her birinin kendi konsolu, kendi API yapısı, kendi kimlik bilgileri, bir 'security group'un veya 'firewall rule'un ne olarak adlandırıldığına dair kendi anlayışı vardır. Üç bulut ve yirmi bare-metal sunucu işleten bir ekip, aslında yan yana üç veya dört ayrı kontrol düzlemini, artı hiçbir bulutta olmayan sunucuları yönetmek için kullandıkları her neyse onu işletiyordur. Hiçbir şey bu kontrol düzlemlerini birbiriyle uyumlu olmaya zorlamaz ve kendi sürecinizin dışında hiçbir şey, birinde yapılan bir değişikliği diğerine bakan birine görünür kılmaz.
'Bulut kontrol düzlemi' terimi daha dar bir anlamda da kullanılır — Kubernetes içinde kontrol düzlemi, pod'ların nerede çalışacağına karar veren API sunucusu, zamanlayıcı (scheduler) ve controller-manager'dır; bunlar, pod'ları node'larda fiilen çalıştıran kubelet'lerden ve container'lardan ayrıdır. 'Çoklu bulut' veya 'birleşik' bir kontrol düzlemi aynı fikri sağlayıcılar arasında genişletir: her sağlayıcı için ayrı bir arayüz yerine, fiziksel olarak birden fazla farklı hesapta, bölgede ve tedarikçide bulunan altyapıyı görmek ve üzerinde işlem yapmak için tek bir yer. Bu, temeldeki sağlayıcı kontrol düzlemlerinin yerini almaz — bir istek yine de AWS'ye, Hetzner'e veya bare-metal bir sunucudaki fleet agent'a yapılan bir API çağrısı olarak sonuçlanır — sadece bunların önünde durarak değişikliği yapan kişinin yalnızca tek bir sistemi öğrenmesini sağlar.
Bu ayrım operasyonel olarak neden önemli
Çoğu altyapı olayı ve denetim boşluğu, veri düzlemi değil kontrol düzlemi sorunlarına dayanır: kimsenin kaydetmediği bir değişiklik, kimsenin iptal etmediği bir yetki, ekipteki başka kimsenin göremediği bir sağlayıcı konsolunda açılan bir güvenlik duvarı kuralı. Her bulutun kendi kontrol düzlemi ve kendi denetim izi olduğunda, "bunu kim, ne zaman değiştirdi" sorusu, üç veya dört farklı konsola giriş yapıp zaman damgalarını elle karşılaştırarak — ya da hiç yanıtlamayarak — cevapladığınız bir soru haline gelir. NIS2 gibi uyumluluk çerçevelerine tabi ekipler için bu boşluk yalnızca sıkıntı verici değildir: değişiklik geçmişi, erişim kontrolü ve olay kanıtı, bir denetçinin veya düzenleyicinin ilk isteyeceği şeylerdir ve parçalanmış bir kontrol düzlemi, bu kanıtların çoğunlukla tek bir yerde bulunmamasının nedenidir.
Sencai bu tabloya nasıl uyuyor
Sencai, yerel kontrol düzlemlerinin üzerinde yer alan bir kontrol düzlemidir: on bir bulut sağlayıcısındaki hesaplara ve hafif bir fleet agent aracılığıyla on-premise ile bare-metal sunuculara bağlanır ve bir hesap bağlandığı anda üzerinde zaten çalışmakta olanların envanterini çıkarır — geçiş (migration) gerekmez. Buradan itibaren, örneklerin sağlanması, başlatılması, durdurulması, yeniden boyutlandırılması ve yok edilmesi sağlayıcıdan bağımsız olarak aynı şekilde işler. Mevcut hesapları bağlayabilirsiniz (hiçbir şey taşınmaz, kimlik bilgileri sağlayıcı tarafında iptal edilebilir kalır) veya Sencai'nin kapasiteyi doğrudan sağlamasına ve faturalandırmasına izin verebilirsiniz; ikisini de tek bir organizasyonda birleştirebilirsiniz. Bağlı her sağlayıcıdaki her işlem, tek bir yalnızca-ekleme (append-only), hash zincirli denetim günlüğüne düşer; böylece "bunu kim, ne zaman değiştirdi" bir soruşturma değil, bir sorgudur.
Envanter ve sağlamayı inceleyin →