Konteyner teknolojisi bilişim sektöründe dengeleri hızla değiştirmeye devam ediyor. Yeni nesil projeler konteyner üzerinde hızla inşaa edilip büyürken, eski nesil sistemler kenara atılmaya devam ediyor.
Peki konteyner teknolojisine nasıl geldik? Hangi aşamalardan geçildi, teknolojinin gelişmesine ne yöne doğru evriliyor, bunları geçmişten bugüne doğru inceleyelim.
1979: Unix V7
Unix işletim sisteminin 7. sürümü 1979’da piyasa sürüldüğünde chroot sistem çağrısı tanıtılmıştı. Chroot komutu bir işlemin ana klasörünü değiştirmeyi sağlıyordu. Bu gelişme işlem izolasyonunun başlangıcıydı. Her bir işlemin dosya erişimi kontrol altınabiliyordu. Chroot BSD’ye de 1982’de eklendi.
2000: FreeBSD Jails
2000’lere gelindiğinde ise FreeBSD jail özelliği ile küçük paylaşımlı barındırma alanları imkanına kavuşuldu. Bu sayede bir servisin kullanıcıları ile bağlantısı kesin olarak ayrılabilir hale gelmiş ve yönetim kolaylığı sağlanmıştı. FreeBSD Jail özelliği sistem yöneticilerine aynı sistem üzerinde jail adı verilen bağımsız küçük sistemler oluşturmayı her birine ayrı IP adresi ve konfigürasyonu vermeyi mümkün kılmıştı.
2001: Linux VServer
Bir yıl sonra Linux camiası da FreeBSD’deki Jails özelliğini Linux VServer olarak dahil etti. Böylece dosya sistemleri, ağ adresleri ve bellek gibi kaynaklar jail mekanizması ile ayırabiliyor. Bu işlem Linux çekirdeği üzerinde yapılabiliyordu. Bu özellik 2006’ya kadar geliştirilmeye devam etti.
2004: Solaris Containers
2004’te ilk betası yayınlanan Solaris Containers ile container ismi ilk kez kullanılmış oldu. Solaris Containers sistem kaynaklarını ve sınırlarını ayrı bölgelere ayırmaya yardım etmişti. Böylece ZFS dosya sistemi üzerinde klonlama ya da kopya alma gibi özellikleri mümkün kılıyordu.
2005: Open VZ (Open Virtuzzo)
İşletim sistemi seviyesindeki bu sanallaştırma teknolojisi yamalanmış bir Linux çekirdeğine sahip olup sanallaştırma, izolasyon, kaynak yönetimi ve kontrol kontası özellikleri sunuyordu. Ancak kaynak kodu hiç bir zaman Linux çekirdeğinin resmi bir parçası haline gelmedi.
2006: İşlem Konteynerları
2006’da Google tarafında yayınlanan Process Containers özelliği işlemci, bellek, disk okuma yazma ve ağ gibi bileşenlerin sınırlaması, hesaplaması için geliştirilmişti. Daha sonra adı cgroups yani control groups olarak değiştirildi. Linux çekirdeğine 2.6.24 ile eklenmiş oldu.
2008: LXC
LXC (LinuX Containers) kelimesinin kısaltmasıydı. Linux için ilk defa tam bir konteyner yönetim uygulaması yapılmıştı. 2008’Deki ilk sürümü cgroups ve Linux namespaceler kullanılarak aynı Linux çekirdeği üzerinde ek bir yama gerektirmeden farklı işlemleri çalıştırmaya olanak sağlıyordu.
2011: Warden
CloudFoundry, 2011’de Waren projesine başladı. Bu proje LXC’yi kullanırken daha sonra kendi uygulamasını dahil etti. Warden herhangi bir işletim sistemi üzerinde izole ortamlar oluşturabiliyordu. Sistem servisi olarak çalışıp API vasıtasıyla konteyner yönetimi sağlıyordu. Konteynerlara sunucu-istemci mimarisiyle yönetimin ilk örneği olarak birden çok sunucu üzerinde yönetimin iyi bir fikir olduğunu ispatlamış oldu.
2013: LMCTFY
Tam adı Let Me Container That For You idi. Bu ifadenin kısaltması olan LMCTFY, 2013’de Google’ın konteyner mimarisi üzerine açık kaynak olarak geliştirildi. Uygulamalar konteyner farkında olarak oluşturulabiliyor kendi alt konteynerlarını yönetebiliyorlardı. LMCTFY’nin geliştirilmesi 2015’te sonlandırılarak, buradaki çekirde konsept şimdi Open Container Foundation bünyesindeki libcontainer projesine aktarıldı.
2013: Docker
2013’te Docker piyasaya sürüldüğünde büyük bir hızla yaygınlaştı. Docker ve konteyner teknolojilerinin patlaması bir tesadüf değildi. Konteyner kullanımı çok kolaylaşmıştı.
Docker, Warden’ın yaptığı gibi ilk sürümlerinde LXC tabanlı çalıştı. Daha sonra bu kütüphaneyi libcontainer ile değiştirdi. Docker sektörde tüm konteyner ekosistemini yönetecek tek bir ürün olarak geldiği için diğer alternatiflerden hızla ayrılmayı başardı.
2016: Konteyner Güvenliğinin Önemi Anlaşıldı
Konteyner temelli uygulamaların yaygınlaşması, sistemleri daha karmaşık hale getirirken riski de arttırdı. Konteyner güvenliği alanında bir çalışma alanı oluşmasına sebep oldu. Dirty COW gibi ortaya çıkan zaafiyetler bu düşünceyi geliştirdi. Bu durum yazılım geliştirme döngüsü içinde de güvenliğin ön plana alınmasına sebep olarak DevSecOps adı verilen kavramın ortaya çıkmasına sebep oldu. Bu yaklaşımla yazılımlar henüz geliştirildi. Aynı zamanda güvenlik düşünülerek ürünün pazara ulaşmasına etki etmeden güvenli bir şekilde hazırlanmasına sebep oldu.
2017: Konteyner Araçlarının Olgunlaşması
Konteyner yönetimini kolaylaştırmak için yüzlerce farklı araç hazırlandı. Bu tür araçlar pazarda yıllar içinde oluşurken, 2017 bir dönüm noktası oldu. Sadece Kubernetes’in Cloud Native Computing Foundation (CNCF) tarafında sahiplenilmesi, VMware, AWS, Azure ve Docker’ın bu gelişmeye desteklerini açıklamasına bakılarak da bu durum anlaşılabilir.
Bir yandan market büyürken konteyner topluluğuna yeni ürünler gelmeye başladı. Ceph ve REX-Ray gibi firmalar konteyner veri saklama alanında standartları oluşturdu. Flannel ise farklı veri merkezlerindeki milyonlarca konteynerı bir araya getirdi. CI/CD tarafında Jenkins yeniliklerle uygulama geliştirme ve yayınlamadaki yaklaşımı tamamen değiştirdi.
rkt ve Containerd’nin CNCF Saflarına Geçmesi
Konteyner ekosistemi topluluk çapındaki efor ve destekler bakımında eşsiz bir ekosistem var. Ekosistemin açık kaynak teknolojiler üzerinde yoğun bir desteği var. Docker’ın CNCF’in Containerd projesine 2017’deki bağışı ile CNCF’nin Rocket olarak okunan rkt konteyner çalıştırma projesini sahiplenişi önemli bir gösterge. Bu tür iş birlikleri kullanıcılar için daha fazla seçeneğe imkan sunuyor. Üstelik konteyner ekosisteminin büyümesi konusunda da destekte bulunuyor.
Kubernetes’in Yükselişi
2017’de Kubernetes açık kaynak projesi olarak çok daha yüksek seviyede teknolojik olgunluk seviyesine gelinebileceğini gösterdi. Kubernetes karmaşık türdeki uygulamaların tanımlanarak hem hibrit bulut hem de mikro servisler için kurumsal geçiş sürecini sağlayan bir ortam oluşmasını sağladı. Kopenhag’daki DockerCon’da, Docker Kubernetes projesini konteyner orkestrasyon aracı olarak destekleyeceğini açkladı. AWS ve Azure gibi bulut sağlayıcılar da peşinden Azure Kubernetes Service (AKS) ve AWS EKS servislerini açıkladılar. Bu proje ayrıca CNCF tarafından sahiplenilen ilk proje oldu. Günümüzde de üçüncü parti sistem entegratörleri listesi hızla büyüyen bir ekosistem haline geldi.
2018: Altın Standart
2018’de konteynerlaşma modern yazılım mimarilerinin temeli haline geldi. Kubernetes pek çok kurumsal konteyner projesi için tercih edilir oldu. 2018’de Github’daki Kubernetes projesi 1500’den fazla geliştiriciye sahip olarak öne çıktı. Kısa adıyla K8S, 27000 yıldızla sektörün desteğini de arkasına almıştı. Kubernetes’in yaygın entegrasyonu AWS, Google Cloud, Azure ve Oracle gibi sağlayıcılardaki servislerle arttı. Hatta VMWare, RedHat ve Racher Kubernetes temelli yönetim platformlarını da yayın aldılar.
Altyapı sağlayıcı VMWare Kubernetes’e desteğini arttırken 2018’de Heptio isimli girişimine yatırım yaptığını açıkladı. Heptio şirketlere kurumsal Kubernetes kullanımı konusunda danışmanlık veren bir şirket olarak yoluna devam ediyor.
Ayrıca sanal makine türü izolasyonu konteyner hızında sağlayan bazı ürünler de bu dönemde ortaya çıktı. Kata containers, gVisor ve Nabla gibi projeler hafif sanal makineleri konteyner kolaylığında çalıştırmak üzere piyasaya sürülen projeler oldular.
2019: Dönüşüm
2019’da konteyner ekosisteminde bir dönüşüm zamanı olarak ortaya çıktı. Bazı servisler arkaplandaki konteyner motorlarını değiştirme kararı aldılar. Dockerın çalışma zamanı motoru yani containerd ve Kubernetes için tasarlanmış CRI-O motorları idi.
2019’da Docker’ın satışı ile Docker Swarm’ın 2 yıl sonra pazardan kalkacağı açıklandı. Aynı zaman CNCF bünyesindeki rkt projesi de hızla popülerliğini yitirdi.
VMWare Heptio satın alması ardından Pivotal’ı da satın alarak Kubernetes’e bağımlılığını daha da arttırdı. Bu iki hareket üzerinden VMWare, müşterilerine daha fazla bulut tabanlı uygulama sağlanması yönünde çalışmalar yapmayı amaçlıyor.
Ayrıca bu yılda sunucusuz mimari tarafında Knative gibi uygulamaların Kubernetes temeli sunucusuz mimarilar oluşturulması için yayınlandığını da gördük.
2019’de IBM Cloud Paks, Google Anthos, AWS Outposts ve Azure Arc gibi teknolojilerle Kubernetes temelli hibrit bulut çözümlerinin de piyasaya çıktığına şahit olduk. Bu bulut platformları geleneksel anlamda bulut ile yerinde çalıştırma (on-premise) çözümleri arasındaki çizgiyi belirsiz hale getirdi. Artık uygulamalar hem bulutta hem de yerinde benzer mantıklarla yönetilebilir hale geldi.
Bu yeni yeteneklerin ortaya çıkmasının Kubernetes’in evriminde bir sonraki adımı temsil ettiğine inanıyoruz. Anthos, Arc ve Outposts gibi yeni bulut yetenekleri, iş yüklerini yönetildikleri yerden ayıran Kubernetes’in çalışmasına benzer şekilde, işlem kaynaklarının yönetim katmanından ayrıldığı hiper soyutlamanın geleceğine işaret ediyor.
Günümüzün Kuberneteslerinde ana düğüm, çalışan düğümle aynı fiziksel kümede bulunur. Hiper soyutlama ile iş yükü yönetimi düzlemi, birkaç bilgi işlem altyapısı arasında dağıtılabilen düğümlerdeki iş yüklerini yönetecek ve kullanıcı, fiziksel olarak nerede çalıştıklarını bilmeyecek veya umursamayacaktır.