Kubernetes ve Docker Farkı Nedir? Hangisini Ne Zaman Seçmeli?

Kubernetes ve Docker farkı nedir?

Kubernetes ve Docker farkı, çalıştıkları katmandadır: Docker, uygulamanızı container imajı olarak paketleyip bir makinede çalıştıran araç setidir. Öte yandan Kubernetes, bu container'ları birden çok sunucuya dağıtan, ölçekleyen, çökeni yeniden başlatan ve güncellemeleri yöneten bir orkestrasyon platformudur. Yani ikisi rakip değil, çoğu projede birbirini tamamlar.

Bu soruyu bize en çok iki grup soruyor. Birinci grup, yazılım ekibinden "Kubernetes'e geçelim" önerisi alan site ve e-ticaret sahipleri. İkinci grup ise Docker'ı öğrenmiş, sıradaki adımı merak eden geliştiriciler. İki grubun da asıl derdi aynıdır: bu ek karmaşıklık bize ne kazandırır, ne kaybettirir?

Biz dijital pazarlama ve web ekibiyiz; hosting firması değiliz. Bu nedenle anlatımı Kubernetes ve Docker resmi dokümanlarına dayandırıyoruz ve her teknik iddiaya kaynak gösteriyoruz. Docker'ın temellerini Docker nedir rehberimizde, Kubernetes kurulumunu ise Minikube ve k3s kurulum yazımızda anlattık. Burada o konuları tekrar etmiyor, yalnızca karar vermenizi kolaylaştıran farklara odaklanıyoruz.

Docker tam olarak ne işe yarar?

Docker, uygulamanızı ve bağımlılıklarını tek bir imaj içinde paketlemenizi, sonra bu imajı her ortamda aynı şekilde çalıştırmanızı sağlar. Geliştiricinin dizüstü bilgisayarında çalışan kod, test sunucusunda ve canlı sunucuda da aynı davranır. Kısacası "bende çalışıyordu" sorununu büyük ölçüde ortadan kaldırır.

Docker dediğimizde aslında birkaç parçadan söz ediyoruz:

• İmaj oluşturma: Dockerfile'daki adımları okuyup katmanlı bir imaj üretir.
• Çalıştırma: Docker Engine, imajdan container başlatır, durdurur ve siler.
• Dağıtım: imajları bir registry'ye gönderir ve oradan çeker.
• Yerel çoklu servis: Docker Compose ile birden çok container'ı tek dosyadan ayağa kaldırır.

Docker'ın odak noktası tek bir makinedir. Elbette o makinede onlarca container çalıştırabilirsiniz. Ancak sunucu kapanırsa, Docker kendi başına iş yükünü başka bir sunucuya taşımaz. Öte yandan bu sınırlama küçük ve orta projelerde çoğu zaman sorun yaratmaz; çünkü tek sunucu, iyi yedek ve izleme ile uzun süre yeterli kalır.

Docker'ın bir diğer faydası, geliştirme ve canlı ortam arasındaki farkı küçültmesidir. Yeni katılan bir geliştirici, projeyi birkaç komutla kendi bilgisayarında çalıştırır. Böylece kurulum belgeleriyle geçen saatler kısalır. Üstelik aynı imajı test ve canlı ortama taşıdığınız için sürpriz hata riski azalır.

Kubernetes tam olarak ne işe yarar?

Kubernetes resmi dokümanında kendini, container'lı iş yüklerini ve servisleri yönetmek için taşınabilir, genişletilebilir, açık kaynak bir platform olarak tanımlar. Bildirimsel yapılandırmayı ve otomasyonu destekler. Kaynak: Kubernetes genel bakış sayfası.

"Bildirimsel" kelimesi burada kilit rolü oynar. Siz Kubernetes'e "bu uygulamadan üç kopya çalışsın" dersiniz; Kubernetes de mevcut durumu sürekli izleyip bu hedefe yaklaştırır. Bir kopya düşerse yenisini başlatır. Bir sunucu çökerse oradaki iş yükünü sağlam sunuculara taşır.

Aynı sayfa Kubernetes'in sunduğu başlıca yetenekleri şöyle sıralar:

• Servis keşfi ve yük dengeleme.
• Depolama orkestrasyonu.
• Otomatik dağıtım ve geri alma.
• Kaynağa göre otomatik yerleştirme.
• Kendini onarma (self-healing).
• Gizli bilgi ve yapılandırma yönetimi.
• Yatay ölçekleme.

Dikkat edin, Kubernetes imaj üretmez ve kaynak kodunuzu derlemez. Resmi doküman bunu açıkça belirtir: Kubernetes bir CI/CD aracı değildir. Dolayısıyla imajı yine Docker ya da benzeri bir araçla siz üretirsiniz.

Aynı sayfa Kubernetes'in geleneksel bir PaaS olmadığını da vurgular. Yani hazır veritabanı, önbellek ya da mesaj kuyruğu sunmaz; bu bileşenleri siz seçip kümeye eklersiniz. Kısacası Kubernetes size güçlü bir temel verir, ama binanın geri kalanını yine sizin ekibiniz inşa eder.

Katman benzetmesiyle iki araç nerede durur?

Farkı akılda tutmanın en kolay yolu, işi katmanlara ayırmaktır. Kubernetes blogundaki "Don't Panic: Kubernetes and Docker" yazısı Docker'ı tek bir parça değil, bütün bir teknoloji yığını olarak anlatır. Aynı yazıya göre Docker, container'ları çalıştırmak için kendi içinde containerd kullanır. Kaynak: Kubernetes resmi blogu.

Bu bilgiyle yığını şöyle düşünebilirsiniz:

1. İmaj katmanı: uygulamanızı paketlersiniz. Burada Docker ve Dockerfile devreye girer.
2. Runtime katmanı: imajı gerçek bir container olarak çalıştırırsınız. Burada containerd ya da CRI-O gibi bir container runtime çalışır.
3. Orkestrasyon katmanı: çok sayıda container'ı çok sayıda sunucuda yönetirsiniz. Burada Kubernetes görev alır.

Bir benzetmeyle anlatalım: Docker, malı standart bir konteynere yükleyen liman vincidir. Kubernetes ise hangi konteynerin hangi gemiye bineceğine, gemi batarsa yükün nereye aktarılacağına karar veren liman yönetimidir. Bu yüzden "Docker mı, Kubernetes mi?" sorusu çoğu zaman yanlış kurulmuş bir sorudur. Asıl soru, orkestrasyon katmanına bugün ihtiyacınız olup olmadığıdır.

Kubernetes ve Docker farkı tabloda nasıl görünür?

Aşağıdaki tablo, Kubernetes ve Docker farkını karar verirken en çok işe yarayan başlıklarda özetliyor. Docker sütununu tek sunucuda Docker Engine ve Compose kullanımı olarak okuyun.

Tablodaki "Docker" satırları Swarm modunu kapsamıyor; Swarm'ı aşağıda ayrıca ele alıyoruz. Ayrıca bu tablo bir kalite sıralaması değildir. Örneğin bakım yükü satırı, küçük bir ekip için Kubernetes'in neden çoğu zaman fazla geldiğini açıklar.

Kubernetes container'ları Docker ile mi çalıştırıyor?

Güncel Kubernetes sürümlerinde hayır. Kubernetes, container runtime ile Container Runtime Interface (CRI) adlı bir arayüz üzerinden konuşur. Docker Engine bu arayüzü doğrudan desteklemediği için Kubernetes eskiden araya "dockershim" adlı bir köprü koyuyordu.

Kubernetes projesi bu köprüyü kaldırdı. Resmi dockershim SSS sayfasına göre kaldırma duyurusu v1.20 sürümüyle geldi, kaldırma işlemi ise v1.24 sürümünde gerçekleşti. Kaynak: Kubernetes dockershim SSS.

Bugün Kubernetes düğümlerinde çoğunlukla şu runtime'lardan birini görürsünüz:

• containerd: Docker'ın da kendi içinde kullandığı runtime.
• CRI-O: doğrudan Kubernetes için geliştirilmiş, CRI uyumlu runtime.
• Docker Engine ve cri-dockerd: Docker Engine'i bırakmak istemeyenler için ayrı bir adaptör.

Bu tablo size şunu söyler: Kubernetes, Docker'a bağımlı değildir. Öte yandan Docker'ın ürettiği imajları sorunsuz çalıştırır. Bu ayrım, bir sonraki bölümdeki yanlış anlaşılmanın kaynağıdır.

Peki bu ayrıntı sizi neden ilgilendirir? Çünkü bir hosting ya da bulut sağlayıcısı "Kubernetes düğümlerinde containerd kullanıyoruz" dediğinde, bu Docker imajlarınızın çalışmayacağı anlamına gelmez. Sorulması gereken soru, imajlarınızın OCI uyumlu olup olmadığıdır; Docker ile ürettiğiniz imajlar zaten öyledir.

Dockershim kaldırıldı diye Docker artık çalışmıyor mu?

Çalışıyor. Bu, internette en sık tekrarlanan yanlış anlamalardan biridir. Dockershim'in kaldırılması yalnızca Kubernetes düğümünde container'ı hangi runtime'ın çalıştıracağını değiştirdi. Docker'ın kendisi, imaj üretme yeteneği ve tek sunucudaki kullanımı olduğu gibi devam ediyor.

Kubernetes'in resmi kaynakları üç noktayı net biçimde söylüyor:

• Docker ile ürettiğiniz imajlar çalışmaya devam eder; çünkü bu imajlar OCI standardına uyar ve her CRI uyumlu runtime onları çalıştırır.
• docker build komutuyla imaj üretmeyi sürdürebilirsiniz.
• Değişiklik geliştiriciyi değil, küme yöneticisini ilgilendirir; düğümlerdeki runtime'ı değiştirmek altyapı tarafının işidir.

Pratikte bunun anlamı şudur: Geliştirici olarak Dockerfile yazmaya, imaj üretmeye ve registry'ye göndermeye aynen devam edersiniz. Kendi kümenizi yönetiyorsanız düğümlerdeki runtime'ı kontrol edersiniz. Yönetilen bir Kubernetes hizmeti kullanıyorsanız bu geçişi genellikle sağlayıcı üstlenir. Yine de sağlayıcınızın sürüm notlarını okumanızı öneririz.

Docker Compose bu karşılaştırmanın neresinde?

Docker Compose, birden çok container'dan oluşan bir uygulamayı tek bir YAML dosyasıyla tanımlamanızı sağlar. Resmi Docker dokümanına göre Compose dosyasında uygulamanın hesaplama parçalarını servis, aralarındaki iletişimi ağ, kalıcı veriyi de volume olarak tanımlarsınız. Kaynak: Docker Compose uygulama modeli.

Basit bir örnek, bir web uygulaması ile veritabanını aynı dosyada tanımlar:

services:
  web:
    image: example/web:1.0
    ports:
      - "8080:80"
    depends_on:
      - db
  db:
    image: postgres
    volumes:
      - dbdata:/var/lib/postgresql/data
volumes:
  dbdata:

Ardından docker compose up -d komutuyla iki servisi birlikte başlatırsınız. Veritabanını container içinde çalıştırmanın ayrıntılarını Docker ile PostgreSQL ve MySQL kurulumu yazımızda bulabilirsiniz.

Compose, çoğu küçük ve orta ölçekli proje için "orkestrasyon" ihtiyacının büyük kısmını tek sunucuda karşılar. Bu nedenle Kubernetes'i düşünmeden önce Compose'un neden yetmediğini somut olarak yazmanızı öneririz.

Docker Swarm, Kubernetes'in alternatifi mi?

Bir ölçüde evet. Docker dokümanı Swarm modunu, Docker Engine kümesini yerel olarak yönetmeye yarayan gelişmiş bir özellik olarak tanımlar. Swarm ile ek orkestrasyon yazılımı kurmadan birden çok sunucuyu tek küme gibi kullanırsınız. Kaynak: Docker Swarm modu dokümanı.

Resmi dokümana göre Swarm şu yetenekleri sunar:

• İstenen durumu bildirimsel olarak tanımlama ve bu durumu sürekli koruma.
• Servis başına kopya sayısını belirleme ve ölçekleme.
• Birden çok sunucuyu kapsayan overlay ağ.
• Servis keşfi, yük dengeleme ve kademeli güncelleme.

Yani Swarm, Kubernetes'in temel fikirlerinin daha sade bir uygulamasıdır. Compose dosyasına benzeyen tanımları kullandığı için Docker bilen bir ekip Swarm'a hızlı geçer. Buna karşılık Kubernetes çok daha geniş bir ekosisteme, genişletme olanağına ve yönetilen hizmet seçeneğine sahiptir. Karar verirken yalnız bugünkü ihtiyaca değil, ekibinizin hangi aracı uzun vadede sürdürebileceğine de bakın.

Ölçeklemede Kubernetes ve Docker farkı nedir?

Ölçeklemede Kubernetes ve Docker farkı, kararı kimin verdiğidir. Tek sunucuda Docker kullanırken kopya sayısını siz değiştirirsiniz ve tüm kopyalar aynı makinenin kaynaklarını paylaşır. Makine dolduğunda daha büyük bir sunucuya geçersiniz; buna dikey ölçekleme diyoruz.

Kubernetes ise yatay ölçeklemeyi merkeze koyar. Resmi dokümana göre uygulamanızı bir komutla, arayüzden ya da CPU kullanımına bağlı olarak otomatik ölçeklersiniz. Örneğin bir Deployment'ın kopya sayısını şu komutla değiştirirsiniz:

kubectl scale deployment/web --replicas=3

Kubernetes yeni kopyaları kümedeki uygun düğümlere yerleştirir. Bu yerleştirmeyi yaparken her container'ın istediği CPU ve bellek miktarını hesaba katar. Dolayısıyla trafik artışında tek bir sunucunun sınırına takılmazsınız; kümeye düğüm ekleyerek kapasiteyi büyütürsünüz.

Ancak burada dürüst olmak gerekiyor. Otomatik ölçekleme, uygulamanızın birden çok kopya halinde çalışabilmesini şart koşar. Oturum bilgisini sunucu belleğinde tutan, dosyaları yerel diske yazan bir uygulama, Kubernetes'e taşındığında ölçeklenmez; önce mimariyi düzeltmeniz gerekir. Önbellek tarafını Redis ve Memcached yazımızda ele aldık.

Kendini onarma (self-healing) iki araçta nasıl çalışır?

Docker tek sunucuda temel bir onarım sunar: restart politikası. Container beklenmedik şekilde kapanırsa Docker onu aynı makinede yeniden başlatır. Bu, basit çökmeler için çoğu zaman yeterlidir. Fakat sunucunun kendisi kapanırsa, o sunucudaki tüm container'lar da onunla birlikte durur.

Kubernetes'in kendini onarma yeteneği daha kapsamlıdır. Resmi dokümana göre Kubernetes şunları yapar:

• Başarısız olan container'ları yeniden başlatır.
• Gerektiğinde container'ları yenileriyle değiştirir.
• Sizin tanımladığınız sağlık kontrolüne yanıt vermeyen container'ları sonlandırır.
• Hazır olmayan container'ları, hazır hale gelene kadar trafiğe açmaz.

Bir düğüm tamamen erişilemez hale gelirse, Kubernetes o düğümdeki iş yükünü kümedeki sağlam düğümlerde yeniden oluşturur. Böylece tek bir sunucu arızası, sitenizin tamamen kapanması anlamına gelmez.

Yine de bu koruma bedava değildir. En az iki, tercihen daha fazla düğüm, düzgün yazılmış sağlık kontrolleri ve kalıcı verinin doğru yönetimi gerekir. Sitenizin erişilebilir olup olmadığını dışarıdan hızlıca görmek için site çöktü mü aracımızı kullanabilirsiniz.

Kademeli güncelleme ve geri almada fark nedir?

Tek sunucuda Docker ile güncelleme genellikle şöyle ilerler: yeni imajı çekersiniz, eski container'ı durdurursunuz ve yenisini başlatırsınız. Compose ile bu iş tek komuta iner. Ancak eski container durduğu ile yenisi hazır olduğu an arasında kısa bir kesinti yaşanabilir. Bu kesintiyi sıfıra indirmek ek kurulum ister, örneğin önde bir ters vekil sunucu ve iki kopya.

Kubernetes'te ise kademeli güncelleme (rolling update) varsayılan dağıtım yöntemidir. Resmi doküman bu yeteneği, gerçek durumu istenen duruma kontrollü bir hızda yaklaştırmak olarak anlatır. Kubernetes yeni kopyaları başlatır, hazır olduklarında eskileri kapatır. Yeni sürüm sorun çıkarırsa önceki sürüme dönersiniz:

kubectl rollout undo deployment/web

Bu özellik özellikle gün içinde sık sürüm çıkaran ekipler için değerlidir. Öte yandan haftada bir güncelleme yapan, gece trafiği düşük bir kurumsal site için kısa bir bakım penceresi çoğu zaman yeterlidir. Kısacası kesintisiz dağıtımın ne kadar önemli olduğu, işinizin trafik düzenine bağlıdır.

Sürüm yönetimini sağlam kurmak için kod tarafında da düzen gerekir. Bunun için Git ve GitHub rehberimize göz atabilirsiniz.

Servis keşfi ve yük dengeleme nasıl ayrışır?

Bir uygulama birden çok servisten oluştuğunda, servislerin birbirini bulması gerekir. Docker Compose bu işi tek sunucuda basitçe çözer: aynı Compose ağındaki servisler birbirine servis adıyla ulaşır. Örneğin web servisi veritabanına "db" adıyla bağlanır.

Kubernetes'te ise container'lar sürekli yer değiştirebilir. Bir kopya bir düğümde kapanır, başka bir düğümde yeni IP adresiyle açılır. Bu nedenle Kubernetes, değişmeyen bir giriş noktası olarak Service nesnesini kullanır. Resmi dokümana göre Kubernetes container'ları DNS adı ya da kendi IP adresiyle dışarı açar ve trafik yüksekse yükü kopyalar arasında dağıtır.

Bu farkın pratik sonucu şudur:

• Tek sunucu ve az sayıda servis: Compose ağı yeterlidir, ek bileşen gerekmez.
• Çok sunucu ve sık değişen kopyalar: Kubernetes Service yapısı işinizi ciddi ölçüde kolaylaştırır.
• Dış trafik: Kubernetes'te dış dünyaya açılmak için ayrıca bir yük dengeleyici ya da ingress katmanı kurarsınız.

Mikroservis mimarisi düşünüyorsanız dil seçimi de bu tabloya etki eder. Bu konuyu Python ve Go mikroservis karşılaştırmamızda ele aldık.

Öğrenme eğrisi ve bakım yükü ne kadar farklı?

Docker'ı temel düzeyde kullanmak için birkaç kavram yeter: imaj, container, volume, ağ ve Compose dosyası. Bir geliştirici bu kavramlarla kısa sürede çalışan bir ortam kurar. Yönetimi görsel bir arayüzle kolaylaştırmak isterseniz Portainer kurulum rehberimiz işinize yarar.

Kubernetes'te ise kavram listesi uzar. Pod, Deployment, ReplicaSet, Service, Ingress, ConfigMap, Secret, PersistentVolume, namespace ve RBAC bunlardan yalnızca birkaçıdır. Üstelik kümenin kendisinin de bakımı vardır:

• Kubernetes sürüm yükseltmeleri ve uyumluluk kontrolü.
• Kontrol düzleminin yedeklenmesi ve erişilebilirliği.
• Düğümlerin güvenlik güncellemeleri.
• İzleme, günlük toplama ve uyarı altyapısı.
• Ağ eklentisi ve depolama sürücüsü yönetimi.

Resmi doküman da Kubernetes'in günlük, izleme ve uyarı için hazır bir çözüm dayatmadığını belirtir. Yani bu parçaları siz seçer, kurar ve bakımını yaparsınız. Bu yüzden Kubernetes'i "bir kere kurulur, sonra kendi döner" diye düşünmeyin. Ekibinizde bu işe ayıracak zamanı olan biri yoksa, yönetilen hizmet ya da daha sade bir çözüm daha akıllıca olur.

Maliyet açısından Kubernetes daha mı pahalı?

Çoğu senaryoda evet, en azından başlangıçta. Burada maliyeti iki kalemde düşünmenizi öneririz: altyapı maliyeti ve insan emeği. İkincisi genellikle birincisinden daha belirleyicidir.

Altyapı tarafında Kubernetes'in anlamlı olması için birden çok düğüm gerekir. Tek düğümlü bir küme kurabilirsiniz, ancak o zaman kendini onarmanın en değerli kısmını, yani sunucu arızasına dayanıklılığı kaybedersiniz. Buna ek olarak izleme, günlük toplama ve yük dengeleyici gibi bileşenler de kaynak tüketir.

İnsan emeği tarafında ise küme bakımı, sürüm yükseltme ve sorun giderme düzenli zaman ister. Docker ve Compose ile tek sunucu yöneten bir geliştirici, bu işleri çoğu zaman günlük işinin yanında halleder. Kubernetes'te ise bu yük belirgin biçimde artar.

Öte yandan ölçek büyüdükçe denge değişebilir. Çok sayıda servisi elle yönetmenin maliyeti, bir noktadan sonra Kubernetes'in otomasyonunu daha ekonomik hale getirir. Dolayısıyla doğru soru "hangisi ucuz?" değil, "bizim ölçeğimizde hangisi toplamda daha az emek ister?" sorusudur. Bu hesabı yaparken kendi ekip saatlerinizi gerçekçi tahmin edin.

Hangi proje için hangisini seçmelisiniz?

Seçimi teknolojinin popülerliğine göre değil, işinizin gerçek ihtiyacına göre yapmanızı öneririz. Aşağıdaki liste saha tecrübesine dayalı bir başlangıç çerçevesidir, kesin kural değildir:

• Kurumsal site, blog, küçük e-ticaret: çoğu zaman paylaşımlı hosting ya da tek VPS yeterlidir; container bile şart değildir.
• Tek sunucuda çalışan, birkaç servisten oluşan web uygulaması: Docker ve Compose en dengeli seçimdir.
• Birkaç sunucuya yayılması gereken ama ekibi küçük bir proje: önce Swarm ya da yönetilen bir platform değerlendirin.
• Çok sayıda servis, çok sunucu, yüksek erişilebilirlik ve sık sürüm: Kubernetes gerçek değer üretir.

Sunucu türü seçiminde kararsızsanız VPS, VDS ve bulut sunucu farkı yazımız iyi bir başlangıç noktasıdır. Hosting tarafının genel kriterlerini ise web sitesi için hosting seçimi rehberimizde topladık.

Unutmayın, Docker ile başlayan bir proje ileride Kubernetes'e geçebilir. İmajlarınız iki ortamda da çalıştığı için bu geçiş, sıfırdan yazmak anlamına gelmez.

Ne zaman Kubernetes kurmamalısınız?

Kubernetes'in güçlü yanlarını anlattık; şimdi dürüst tarafa geçelim. Aşağıdaki durumlarda Kubernetes'i kendiniz kurmanızı önermiyoruz:

• Tek bir sunucu tüm trafiğinizi rahatça taşıyorsa.
• Ekibinizde küme bakımına düzenli zaman ayıracak biri yoksa.
• Uygulamanız oturumu bellekte tutuyor ve yerel diske yazıyorsa, yani henüz birden çok kopyayla çalışamıyorsa.
• Asıl sorununuz yavaş veritabanı sorgusu ya da şişkin sayfalarsa.

Son madde özellikle önemlidir. Sitenin yavaş olmasının nedeni çoğu zaman altyapı değil, uygulamanın kendisidir. Bu durumda Kubernetes sorunu çözmez, yalnızca daha pahalı ve karmaşık bir ortamda aynı sorunu yaşarsınız.

Ayrıca Kubernetes kümesini internete açmak ciddi bir güvenlik sorumluluğudur. API sunucusunun erişimi, gizli bilgilerin yönetimi ve rol tabanlı yetkiler doğru ayarlanmazsa risk büyür. Bu sorumluluğu taşıyacak bilgi ekipte yoksa, işi hosting sağlayıcınıza ya da yönetilen bir Kubernetes hizmetine bırakmak daha güvenli bir tercihtir.

Kalıcı veri iki ortamda nasıl yönetilir?

Container'lar doğası gereği geçicidir; silinip yeniden oluşturulabilirler. Bu yüzden veritabanı ve yüklenen dosyalar gibi kalıcı verinin nerede durduğu, iki araçta da en kritik karardır.

Docker'da kalıcı veriyi volume ile saklarsınız. Volume, container silinse bile sunucunun diskinde kalır. Tek sunucuda bu yaklaşım basit ve anlaşılırdır. Ancak yedekleme sorumluluğu tamamen sizdedir; sunucu diski arızalanırsa volume de onunla gider.

Kubernetes'te ise resmi dokümanın "depolama orkestrasyonu" dediği yetenek devreye girer. Yerel disk, bulut sağlayıcısının diski ya da ağ depolaması gibi sistemleri container'lara otomatik bağlarsınız. Bu esneklik güçlüdür; fakat pod başka bir düğüme taşındığında verinin de oraya erişilebilir olması gerekir. Dolayısıyla depolama seçimini kümeyi kurmadan önce yapmalısınız.

Pratikte pek çok ekip veritabanını Kubernetes dışında, yönetilen bir veritabanı hizmetinde tutar ve kümede yalnızca durumsuz uygulama servislerini çalıştırır. Bu yaklaşım küme bakımını sadeleştirir. Hangisini seçerseniz seçin, yedeklerin geri yüklenebildiğini düzenli olarak test edin.

Yönetilen Kubernetes ne zaman mantıklı?

Büyük bulut sağlayıcıları ve bazı hosting firmaları yönetilen Kubernetes hizmeti sunar. Bu modelde kontrol düzlemini, yani kümenin beynini sağlayıcı işletir. Siz yalnızca uygulamalarınızı ve düğüm havuzunuzu yönetirsiniz.

Yönetilen hizmetin size kazandırdıkları şunlardır:

• Kontrol düzleminin kurulumu, yedeklenmesi ve erişilebilirliği sağlayıcıda kalır.
• Sürüm yükseltmeleri çoğunlukla birkaç adımla tamamlanır.
• Yük dengeleyici ve kalıcı disk gibi bileşenler sağlayıcının altyapısıyla entegre gelir.

Buna karşılık bazı sorumluluklar sizde kalır. Uygulama mimariniz, kaynak tanımlarınız, güvenlik ayarlarınız ve maliyet kontrolü yine sizin işinizdir. Ayrıca sağlayıcıya özgü özelliklere fazla bağlanırsanız, ileride başka bir sağlayıcıya geçmek zorlaşır.

Bizim önerimiz şudur: Kubernetes'e gerçekten ihtiyacınız varsa ve ekibiniz küçükse, kendi kümenizi sıfırdan kurmak yerine yönetilen hizmetle başlayın. Öğrenme amaçlı denemeler için ise Minikube ve k3s rehberimizdeki yerel kurulumlar yeterlidir.

Docker'dan Kubernetes'e geçişe nereden başlamalı?

Geçiş kararını verdiyseniz, adımları sırayla atmanız riski azaltır. Önerdiğimiz sıra şöyledir:

1. Uygulamayı durumsuz hale getirin: oturumu ve dosyaları container dışına taşıyın.
2. Yapılandırmayı ortam değişkenlerine ayırın; parolaları imajın içine gömmeyin.
3. Her servis için sağlık kontrolü uç noktası ekleyin.
4. İmajlarınızı sürüm etiketiyle bir registry'ye gönderin.
5. Kubernetes'i önce yerel ortamda ya da test kümesinde deneyin.
6. Önce kritik olmayan bir servisi taşıyın, sonra diğerlerine geçin.

İlk üç adım, Kubernetes'e hiç geçmeseniz bile uygulamanızı iyileştirir. Örneğin durumsuz bir uygulama tek sunucuda da daha kolay yedeklenir ve taşınır. Bu yüzden bu adımları "Kubernetes hazırlığı" değil, genel bir sağlık çalışması olarak görün.

Uygulama mimarisini birlikte değerlendirmek isterseniz özel yazılım geliştirme hizmetimiz kapsamında ekibimizle bu adımları planlayabilirsiniz.

Kubernetes ve Docker farkını kısaca nasıl özetleriz?

Kubernetes ve Docker farkını tek cümlede toplarsak: Docker container'ı üretir ve çalıştırır, Kubernetes ise çok sayıda container'ı çok sayıda sunucuda yönetir. İkisi aynı yığının farklı katmanlarında durur ve çoğu zaman birlikte kullanılır.

Akılda tutmanız gereken noktaları şöyle sıralayabiliriz:

• Dockershim'in kaldırılması Docker'ı öldürmedi; yalnızca Kubernetes düğümlerindeki runtime değişti.
• Tek sunucu için Docker ve Compose çoğu zaman yeterli ve daha sadedir.
• Kubernetes'in değeri, çok sunucu ve yüksek erişilebilirlik ihtiyacında ortaya çıkar.
• Kubernetes'in bakım yükü gerçektir; ekip kapasitesi yoksa yönetilen hizmet seçin.

Son olarak, altyapı kararını teknik moda değil, iş hedefi belirlemeli. Önce sitenizin ya da uygulamanızın gerçek darboğazını ölçün, sonra bu darboğazı çözen en sade aracı seçin.