Kubernetes, container'ları birden fazla sunucu üzerinde dağıtan, ölçekleyen ve arıza anında yeniden ayağa kaldıran bir orkestrasyon sistemi. Kısaca söylersek: "şu uygulamadan üç kopya çalışsın" dersiniz, o üçünün nerede çalışacağına, biri düştüğünde ne olacağına ve yeni sürüme nasıl geçileceğine Kubernetes karar verir. Adı bazen K8s diye kısaltılır.
Hangi sorunu çözüyor
Container'lar tek başına bir sunucuda çalışırken sorun çıkarmaz. Sorun, uygulamanız tek sunucuya sığmadığında başlar. Beş sunucuda otuz container çalıştırıyorsanız birileri şu soruların cevabını vermek zorunda: hangi container hangi sunucuda çalışacak, bir sunucu çöktüğünde üzerindekiler nereye taşınacak, yeni sürüme geçerken kaç kopya aynı anda güncellenecek, trafik hangi kopyalara dağıtılacak.
Bu soruların cevabını elle vermek küçük ölçekte mümkün, ama ölçek büyüdükçe insan hatası kaçınılmaz hale gelir. Kubernetes bu kararları sizin yazdığınız bir tanıma bakarak sürekli veriyor. Siz istenen durumu yazıyorsunuz, o gerçek durumu ona yaklaştırıyor. Bir pod öldüğünde yenisini açması, sizin bir şey yapmanızı gerektirmiyor.
Parçaları: control plane, node, pod
Node, cluster'ı oluşturan tek bir sunucu. Fiziksel ya da sanal olabilir. Üzerinde iş yükleri çalışır. Kapasite artırmak genelde yeni node eklemek demektir.
Pod, Kubernetes'in çalıştırdığı en küçük birim. İçinde bir ya da birkaç container vardır ve bunlar aynı ağ ile depolama alanını paylaşır. Uygulamanızın bir kopyası genelde bir pod'a karşılık gelir.
Control plane, cluster'ın karar veren katmanı. Hangi pod'un hangi node'da çalışacağını o belirler, durumu izler, sapma gördüğünde düzeltir. Control plane çökerse çalışan uygulamalarınız bir süre ayakta kalmaya devam eder ama cluster artık kendini onaramaz: yeni dağıtım yapılamaz, düşen pod yerine yenisi açılmaz. Bu yüzden üretimde control plane'in yedekli kurulması tercih değil zorunluluktur.
Control plane'in altında etcd durur. Cluster'ın tüm durumunu tutan dağıtık veri deposudur; cluster'ın hafızası odur. Kaybedilirse cluster yeniden kurulamaz, çünkü neyin nasıl çalışması gerektiğine dair kayıt orada. Neden ayrıca ele alınması gerektiğini etcd yedekleme ve kurtarma yazısında ölçümlerle anlattık.
Ne zaman gerekli, ne zaman fazla
Kubernetes'in en çok yanlış kullanıldığı yer, gerekmediği yerde kullanılması. Teklif görüşmelerinde sıkça karşımıza çıkıyor: tek bir web uygulaması ve tek bir veri tabanı çalıştıran bir ekip, üç node'luk bir cluster istiyor. Böyle bir kurulum çalışır ama getirdiği işletim yükü, çözdüğü sorundan büyük olur.
Kubernetes şu durumlarda karşılığını veriyor:
- Birbirinden bağımsız dağıtılan birden fazla servisiniz varsa
- Yük gün içinde ciddi biçimde değişiyorsa ve otomatik ölçekleme istiyorsanız
- Sık dağıtım yapıyorsanız ve her dağıtımda kesinti istemiyorsanız
- Aynı uygulamayı birden fazla ortamda birebir aynı şekilde çalıştırmanız gerekiyorsa
Şu durumlarda gerekmiyor:
- Tek bir uygulama ve tek bir veri tabanı çalıştırıyorsanız
- Ayda birkaç kez dağıtım yapıyorsanız
- Cluster'ı işletecek bir ekip ya da hizmet sağlayıcı yoksa
Son madde en kritik olanı. Kubernetes kurmak bir günlük iş, işletmek sürekli bir iş. Sürüm yükseltmeleri, sertifika yenileme, kaynak limitlerinin ayarı ve etcd yedeğinin doğrulanması bırakıldığında cluster sessizce çürür.
Bizde nasıl çalışıyor
Yönettiğimiz cluster'larda control plane'i yedekli kuruyoruz ve etcd yedeğini uygulama yedeğinden ayrı ele alıyoruz. İkisini aynı işlemin parçası saymak yaygın bir hata; uygulama verisi geri gelse bile cluster durumu gelmezse kurtarma yarım kalıyor.
Sürüm yükseltmelerini kesintisiz yürütüyoruz: node'lar sırayla boşaltılıp yükseltiliyor, iş yükleri bu sırada diğer node'larda çalışmaya devam ediyor. Bu işin nasıl planlandığını ve hangi adımda ne yanlış gidebileceğini sürüm yükseltme yazımızda adım adım yazdık.
Control plane'in kimde olacağı sözleşme aşamasında netleşiyor. Bizde olduğunda cluster'ın kendi sağlığı, etcd yedeği ve yükseltmeler bizim işimiz; namespace içindeki deployment'lar, kaynak limitleri ve uygulama yapılandırması sizde kalıyor. Bu sınırın tamamı sorumluluk paylaşımı sayfasında katman katman yazılı. Hizmetin kapsamı için Kubernetes cluster yönetimi sayfasına bakabilirsiniz.
Node sayısı konusunda sık sorulan bir soru var: kaçla başlamalı? Üretim için control plane'in yedekli olması gerektiğinden alt sınır pratikte üç düğüm oluyor. Bunun altına inen kurulumlar test ortamı olarak anlamlı, üretim için değil; tek düğümlü bir cluster, Kubernetes'in çözdüğü sorunların hiçbirini çözmez, sadece karmaşıklık ekler.
Sık karıştırılanlar
Kubernetes ile Docker aynı şey değil. Docker container üretir ve çalıştırır; Kubernetes bu container'ları birden fazla sunucu üzerinde yönetir. Biri olmadan diğeri anlamsız değildir ama işleri farklıdır.
Kubernetes bir bulut sağlayıcısı değildir. Kendi donanımınızda da, herhangi bir bulutta da çalışır. "Kubernetes'e geçtik" demek "buluta geçtik" demek değildir.
Yönetilen Kubernetes, Kubernetes'i öğrenmeden kullanmak anlamına gelmez. Cluster'ı biz işletsek de uygulamanızın kaynak ihtiyacını ve dayanıklılık gereksinimlerini birlikte tanımlamamız gerekiyor. Container düzeyinde tam yönetilen bir model istiyorsanız Container as a Service daha uygun olabilir; katmanlar arasındaki farkı IaaS, PaaS ve SaaS karşılaştırmasında açtık.
Terimlerin kısa tanımları için sözlüğe dönebilirsiniz.