Containerd ve Docker: Kapsayıcı Çalışma Zamanlarını Anlamak

Kapsayıcı ekosisteminde, geliştiriciler Docker’ı (kapsamlı bir platform) aslında odaklı bir çalışma zamanı bileşeni olan containerd ile karşılaştırdığında sık görülen bir kafa karışıklığı ortaya çıkar. Bu karşılaştırma, bütün bir otomobili motoruyla kıyaslamaya benzer: her ikisi de gereklidir, ancak farklı soyutlama düzeylerinde farklı amaçlara hizmet ederler.

Bu rehberde, bu iki teknoloji arasındaki ilişkiyi netleştirerek mimarilerini, Kubernetes entegrasyonunu ve her bir aracın parladığı belirli senaryoları inceleyeceğim. İster yerelde kapsayıcılar oluşturuyor olun ister üretim Kubernetes kümelerini yönetin, Docker ile containerd’ı ne zaman kullanacağınızı anlamak altyapı kararlarınızı önemli ölçüde etkileyebilir.

Bu makalenin sonunda, Docker ve containerd’ın birbirini nasıl tamamladığını ve hızlı yerel geliştirmeden büyük ölçekli üretim dağıtımlarına kadar özel ihtiyaçlarınız için doğru aracı nasıl seçeceğinizi net bir şekilde kavramış olacaksınız.

Kapsayıcılaştırmaya yeniyseniz, Containerization and Virtualization Concepts kursumuzu hararetle tavsiye ederim.

Docker Nedir?

Docker, kapsayıcılaştırmayı günlük geliştiriciler için erişilebilir ve pratik hale getirerek yazılım geliştirme dünyasında devrim yarattı. Kapsamlı bir platform olarak Docker, kapsayıcılaştırılmış uygulamaları oluşturmak, göndermek ve çalıştırmak için gereken her şeyi sağlar.

Yeni başlayanlar için bu Kapsayıcılara Pratik Rehber Docker ve kapsayıcılara dair harika bir başlangıç sunar.

Kapsamlı bir kapsayıcı platformu

Docker, kapsayıcı yaşam döngüsünün çoğunu kapsayan entegre bir araç seti sunan hepsi bir arada bir kapsayıcı platformu olarak çalışır. Docker, özünde, uygulamaları tüm bağımlılıklarıyla birlikte, bir geliştiricinin dizüstü bilgisayarından üretim sunucularına kadar her ortamda tutarlı şekilde çalışabilen taşınabilir, kendi kendine yeterli imajlar halinde paketler.

Bu kapsamlı yaklaşım, Docker’ı yerel geliştirme ve geliştirici deneyimi için sektör standardı haline getirdi. Başlıca avantajlardan bazıları şunlardır:

Geniş ekosistem: Docker Hub, veritabanlarından web sunucularına kadar milyonlarca hazır imaj barındırır ve karmaşık kurulum süreçlerini ortadan kaldırır
Evrensel taşınabilirlik: macOS’ta oluşturulan bir kapsayıcı, Docker yüklü olduğu sürece Linux veya Windows’ta aynı şekilde çalışır
Geliştirici odağı: Altyapı farklılıklarını soyutlayarak geliştiricilerin dağıtım karmaşıklıkları yerine uygulamalarına odaklanmasını sağlar
Hızlı işe başlangıç: Yeni ekip üyeleri geliştirme ortamlarını saatler yerine dakikalar içinde ayağa kaldırabilir

Temel bileşenler ve iş akışı

Docker’ın mimarisi, birbiriyle sorunsuz çalışan birkaç birbirine bağlı bileşenden oluşur.

Docker CLI, geliştiricilerin komut verdiği kullanıcıya dönük arayüzü sağlar. docker run gibi bir komut çalıştırdığınızda, CLI, kapsayıcıları, imajları, ağları ve volumeleri yöneten çekirdek hizmet olan Docker daemon’ı (dockerd) ile iletişim kurar.

Windows ve macOS kullanıcıları için Docker Desktop, grafiksel bir arayüzle ek bir kolaylık katmanı sunar ve komut satırı araçlarında kendini daha az rahat hissedenler için bile kapsayıcı yönetimini erişilebilir kılar. Bu entegre ortam, Kubernetes desteğinden volume yönetimine kadar yerel geliştirme için gereken her şeyi içerir.

Tipik iş akışı net bir deseni izler:

Geliştiriciler Dockerfile’lar kullanarak imajlar oluşturur
Bu imajları Docker Hub gibi kayıtlara gönderirler
Son olarak, imajlar Docker etkin herhangi bir host üzerinde kapsayıcı olarak çalıştırılır

Birçok geliştirici, Docker’ın kapsayıcıları doğrudan yürütmediğinin farkında değildir. Bunun yerine, dockerd, kapsayıcıları fiilen çalıştırma işini arka planda ayrı bir süreç olarak çalışan containerd’a devreder.

Docker’ın düşük seviye işlemler için containerd’ı kullandığı bu modüler tasarım, her bir bileşenin en iyi yaptığı şeye odaklanmasını sağlar: Docker, geliştirici dostu arayüz ve ekosistemi sunarken containerd, kapsayıcı yürütmenin ince ayrıntılarını üstlenir.

Docker’a yeni başlıyor ya da bir adım ileri gitmek istiyorsanız, her seviyeye uygun 10 Docker Proje Fikri yazımıza göz atın.

Containerd Nedir?

Docker’ın kapsamlı platform yaklaşımını inceledikten sonra, şimdi de hem Docker içinde hem de daha geniş ekosistemde kapsayıcı yürütmesini güçlendiren uzmanlaşmış çalışma zamanı containerd’a bakalım.

Sektör standardı bir kapsayıcı çalışma zamanı

Containerd, Cloud Native Computing Foundation (CNCF) tarafından mezun edilmiş, hafif ve sektör standardı çekirdek bir kapsayıcı çalışma zamanıdır; bu da olgunluğunu, güvenilirliğini ve yaygın benimsenmesini gösterir. Aslen Docker’ın bir parçası olan containerd, 2017’de ayrıştırılarak daha geniş ekosistem benimsenmesini sağlamak üzere CNCF’ye bağışlandı.

Docker’ın kapsamlı özellik setinin aksine, containerd’ın kapsamı bilerek sınırlıdır: başlatma, durdurma, duraklatma ve silme gibi çekirdek kapsayıcı yaşam döngüsü işlemlerini yönetir ve imaj aktarımı ile depolamayı ele alır. Bu odaklı yaklaşım, containerd’ı üretim ortamları için gereken olağanüstü kararlı ve verimli bir hale getirir.

Containerd’ı bir “tesisat” olarak düşünün: İnsanlar tarafından doğrudan kullanılmak yerine daha büyük sistemlere gömülmek üzere tasarlanmış altyapı. Kubernetes, AWS Fargate ve Google Kubernetes Engine gibi büyük platformların tümü, kullanıcılar bu platformlarla kendi arayüzlerinden etkileşime geçse de, kapsayıcıları yürütmek için containerd’a güvenir.

Mimari ve tasarım

Containerd’ın üretim sistemlerinde bu kadar yaygın benimsenmesini anlamak için mimari ilkelerini incelememiz gerekir.

Containerd’ın mimarisi, modüler tasarım ilkelerini örnekler. Çekirdeğinde Open Container Initiative (OCI) standartları üzerine inşa edilen containerd, tüm kapsayıcı ekosistemi genelinde uyumluluk sağlar. Bu da, OCI uyumlu herhangi bir imajın, hangi araçla oluşturulduğundan bağımsız olarak containerd ile çalışacağı anlamına gelir.

Mimari, birkaç kilit katmandan oluşur:

gRPC API katmanı: Birden çok istemcinin (Docker, Kubernetes, özel araçlar) tek bir containerd örneğiyle iletişim kurduğu istemci-sunucu modeli sağlar
Containerd daemon: Çalışan kapsayıcılar hakkında durum bilgisini tutar, snapshotter’lar aracılığıyla imaj depolamayı yönetir ve eklentiler üzerinden ağ iletişimini koordine eder
runc çalışma zamanı: Linux çekirdek özellikleriyle doğrudan arayüz yapan, ad alanları oluşturan, kaynak sınırları için cgroup’ları ayarlayan ve kapsayıcı süreçlerini başlatan hafif, OCI uyumlu bir çalışma zamanı
Modüler eklentiler: Özel depolama için özelleştirilmiş snapshotter’lar, alternatif çalışma zamanları (gVisor, Kata Containers) ve ağ eklentileri, containerd’ı değiştirmeden entegre edilebilir

Containerd bir kapsayıcıyı başlatması gerektiğinde runc’u oluşturur; runc, yalıtılmış ad alanları yaratma, kaynak sınırları için cgroup’ları kurma ve kapsayıcı sürecini başlatma işini fiilen gerçekleştirir.

Bu görev ayrımı, containerd’ı son derece genişletilebilir kılar. Kuruluşlar, çekirdek containerd koduna dokunmadan neredeyse her yönü özelleştirebilir.

Containerd ve Docker Arasındaki Temel Farklar

Her aracın ne yaptığını sağlam biçimde anladıktan sonra, mimariden entegrasyon kalıplarına kadar pratikte nasıl farklılaştıklarını inceleyelim.

Kapsayıcı çalışma zamanı vs platform

Temel fark, kapsam ve amaçta yatar.

Docker, dockerd’ın aşağıdakiler gibi birçok farklı unsuru koordine ettiği merkezi bir daemon mimarisi kullanır:

İmaj oluşturma
Kapsayıcı yürütme
Ağ iletişimi
Volume yönetimi

Bu hepsi bir arada tasarım, geliştirici deneyimini basitleştirir ancak birden çok soyutlama katmanı nedeniyle ek yük getirir.

Buna karşılık containerd, yalnızca kapsayıcı yürütmeye odaklanır. İmaj oluşturma yetenekleri, orkestrasyon özellikleri veya grafik arayüz içermez. Ağ için Docker, daemon’ına gömülü Libnetwork’ü barındırırken containerd, gereksinimlere göre değiştirilebilen harici Container Network Interface (CNI) eklentilerine dayanır.

Bu mimari fark, performans üzerinde etkiler doğurur. Kapsayıcıların sıkça başlatılıp durdurulduğu, otomatik ölçeklenen Kubernetes kümeleri gibi yüksek devirli ortamlarda, containerd’ın yalın tasarımı daha hızlı başlatma süreleri ve daha düşük kaynak tüketimi sağlayabilir. Azalan ek yük, containerd’ın daha az bellek ve CPU kullanması anlamına gelir ki bu da ölçek büyüdükçe önemli hale gelir.

Kubernetes entegrasyonu

Kubernetes’ten söz açılmışken, kapsayıcı çalışma zamanları ile orkestrasyon platformları arasındaki ilişki, özellikle Kubernetes’in containerd’a nasıl bağlandığı konusunda önemli ölçüde evrildi.

Kubernetes ile kapsayıcı çalışma zamanları arasındaki ilişki, 2022’de yayınlanan Kubernetes 1.24 ile büyük bir değişim geçirdi. Bu sürüm, Kubernetes’in kapsayıcı çalışma zamanı olarak Docker’ı kullanmasına imkân veren uyumluluk katmanı “Dockershim”i kaldırdı.

Dockershim, her zaman geçici bir köprü olarak tasarlanmıştı. Kubernetes, çalışma zamanlarıyla iletişimi standartlaştırmak için Container Runtime Interface’i (CRI) tanıttığında, Docker CRI tasarımından önce geldiği için bunu doğrudan uygulayamadı. Dockershim, Kubernetes ile Docker arasında çeviri yaparak zamanla gereksiz hale gelen bir çeviri katmanı ekliyordu.

Modern Kubernetes sürümleri, CRI aracılığıyla containerd ile doğrudan iletişim kurar ve Docker çeviri katmanını tamamen ortadan kaldırır. Bu sadeleşme somut faydalar getirir:

Azaltılmış gecikme: Doğrudan iletişim, kapsayıcı işlemlerindeki çeviri ek yükünü ortadan kaldırır
Artan kararlılık: Daha az hareketli parça, daha az olası arıza noktası demektir
Daha iyi performans: Yalın çalışma zamanı yığını, özellikle büyük ölçekli dağıtımlarda fayda sağlar
Basitleştirilmiş hata ayıklama: Doğrudan CRI entegrasyonu, sorun gidermeyi daha sade hale getirir

Kubernetes kullanıcıları için bu değişim büyük ölçüde şeffaftır. Docker imajları, OCI standartlarına uydukları için tamamen uyumluluğunu korur. Pratik etkisi, üretim Kubernetes kümelerinin artık containerd’ı doğrudan kullanarak daha verimli çalışması; geliştiricilerin ise imaj oluşturma ve test için yerelde Docker’ı kullanmaya devam edebilmesidir.

İlk etapta Kubernetes kullanmanın artı ve eksilerinden emin değilseniz, Docker Compose ve Kubernetes karşılaştırmasını inceleyin.

İmaj oluşturma ve yönetimi

Çalışma zamanı entegrasyonu orkestrasyon için kritik olsa da, geliştirici iş akışı her aracın imaj oluşturma ve depolamayı nasıl ele aldığına büyük ölçüde bağlıdır. İmaj oluşturma, Docker ile containerd arasında önemli bir yetenek farkını temsil eder.

Docker, Dockerfile’lar ve BuildKit aracılığıyla entegre bir derleme sistemi sunar ve geliştiricilerin önbellekleme, paralelleştirme ve build secret’ları ile SSH agent yönlendirme gibi gelişmiş özelliklerle karmaşık çok aşamalı derlemeler yapmasına olanak tanır.

Containerd, tasarımı gereği yerleşik bir imaj derleme iş akışı içermez. Containerd ile imaj oluşturmak için geliştiricilerin harici araçlar kullanması gerekir. Seçenekler arasında BuildKit’i ayrı bir daemon olarak çalıştırıp komut satırı derlemeleri için buildctl kullanmak veya BuildKit’i entegre eden, Docker uyumlu bir CLI olan nerdctl’i benimsemek bulunur.

Depolama mekanizmaları da felsefe olarak farklıdır. Docker’ın volume yönetimi, geliştiricilere doğal gelen bir soyutlama sunar; adlandırılmış volumeler, verilerin kapsayıcı yaşam döngülerinden bağımsız olarak kalıcı olmasını sağlar. Containerd ise daha düşük seviyeli bir snapshotter sistemi kullanır; farklı snapshot sürücüleri, altta yatan depolama gereksinimlerine bağlı olarak katmanlı dosya sistemlerini farklı şekilde ele almak üzere takılabilir.

Bu fark, araçların hedef kitlelerini yansıtır:

Docker, yerleşik kolaylıklarla geliştirici verimliliğini optimize eder
Containerd, platform geliştiricilerinin özel ihtiyaçlarına göre bir araya getirebileceği esnek ilkeller sağlar

CLI, geliştirici deneyimi ve nerdctl

Mimari ve özelliklerin ötesinde, günlük geliştirici deneyimini en doğrudan şekillendiren unsur, her aracın sağladığı komut satırı arayüzüdür. Komut satırı deneyimi, farklı tasarım felsefelerini en berrak şekilde ortaya koyar.

Docker’ın CLI’ı kullanıcı dostuluğuyla bilinir. docker run, docker build ve docker logs gibi komutlar sezgiseldir, iyi belgelenmiştir ve insanlar için tasarlanmıştır. CLI, yardımcı varsayılanlar, net hata iletileri ve çoğu kullanım senaryosunu kapsayan kapsamlı seçenekler içerir.

Containerd, yalnızca düşük seviyeli containerd işlevlerini hata ayıklama ve test etme amaçlı, minimal bir CLI olan ctr ile gelir. ctr aracı bilerek geliştirici dostu değildir. Port eşleme kısaltması, otomatik yeniden başlatma ilkeleri ve kimlik bilgisi yardımcılarıyla entegrasyon gibi yaygın özelliklerden yoksundur. Containerd geliştiricileri için tasarlanmıştır; uygulama geliştiricileri için değil.

Nerdctl ile arayı kapatma

Bu kullanılabilirlik açığı, containerd için Docker uyumlu bir CLI olan nerdctl’in yaratılmasına yol açtı. nerdctl kullanmak, Docker kullanmakla neredeyse aynıdır; aynı komut sözdizimi, aynı bayraklar, aynı iş akışı, ancak altta yatan çalışma zamanı olarak containerd ile. Bu da nerdctl’i, geliştirme ortamlarında Docker’dan containerd’a geçiş yapan ekipler için mükemmel bir köprü haline getirir.

Pratikte geliştiriciler, containerd ile nadiren doğrudan etkileşime girer. Gerek duyduklarında, nerdctl bekledikleri tanıdık arayüzü sağlar; platform operatörleri ve yöneticiler ise Kubernetes gibi orkestrasyon sistemleri üzerinden containerd’ın API’lerini programlı olarak kullanır.

Farkları pratikte göstermek için, yaygın kapsayıcı işlemlerinin üç CLI aracı arasında nasıl karşılık geldiği şöyledir:

Görev	Docker	nerdctl	ctr
Kapsayıcı çalıştır	`docker run -d -p 8080:80 nginx`	`nerdctl run -d -p 8080:80 nginx`	`ctr run --net-host -d docker.io/library/nginx:latest nginx_id`
Kapsayıcıları listele	`docker ps`	`nerdctl ps`	`ctr tasks list`
İmaj derle	`docker build -t myapp .`	`nerdctl build -t myapp .`	Desteklenmiyor
Günlükleri görüntüle	`docker logs <container>`	`nerdctl logs <container>`	Desteklenmiyor
Kapsayıcıyı incele	`docker inspect <container>`	`nerdctl inspect <container>`	`ctr containers info <container>`
İmaj çek	`docker pull nginx`	`nerdctl pull nginx`	`ctr images pull docker.io/library/nginx:latest`
Compose desteği	`docker compose up`	`nerdctl compose up`	Desteklenmiyor

Dikkat: ctr port eşlemeyi (-p) desteklemez ve servisleri dışa açmak için host ağını (--net-host) gerektirir. Ayrıca imajları otomatik olarak çekmez.

Temel farklara genel bakış

Belirli kullanım durumlarına yönelik önerilere girmeden önce, şimdiye kadar ele aldığımız farkları özetleyelim. Aşağıdaki tablo, Docker ile containerd arasındaki temel işlevsel farkları özetleyerek farklı yeteneklerini ve hedef kitlelerini vurgular:

Özellik	Docker	Containerd
İmaj Oluşturma	Entegre (Dockerfile’lar, BuildKit)	Harici araçlar gerektirir (buildctl, nerdctl)
Orkestrasyon	Docker Swarm / Kubernetes	Yok (Kubernetes tarafından kullanılır)
Depolama Yönetimi	Volume yönetimi	Snapshotter sistemi
Grafik Arayüz	Docker Desktop	Yok
Kapsayıcı Yaşam Döngüsü	Tam yönetim (containerd üzerinden)	Çekirdek odak (CRI uyumlu)
Birincil Kullanıcılar	Uygulama Geliştiricileri	Küme Operatörleri, Platform Geliştiricileri

Neden Docker’ı Seçmeli?

Teknik farkları ele aldığımıza göre, her bir aracın parladığı pratik senaryoları inceleyelim. Containerd’ın üretim ortamlarında yükselişine rağmen, geliştirici deneyimi ve kapsamlı araç setinin önemli olduğu belirli senaryolarda Docker üstün seçenek olmaya devam ediyor.

Yerel geliştirme ve prototipleme için

Kod yazma ve test için “hepsi bir arada” bir çözüme ihtiyaç duyduğunuzda Docker mükemmeldir. Entegre araç zinciri, geliştiricilerin birden çok bileşeni bir araya getirmesine veya karmaşık ağ yapılandırmaları yapmasına gerek kalmadan sıfırdan dakikalar içinde çalışan kapsayıcılara geçebilmesini sağlar.

Docker ekosistemi, büyük verimlilik kazanımları sağlar:

Docker Hub: Veritabanları, mesaj kuyrukları ve web sunucuları için milyonlarca kullanıma hazır imaj
Docker Compose: Çoklu kapsayıcı uygulamaları tek bir YAML dosyasında tanımlayın ve tek komutla tüm geliştirme ortamlarını ayağa kaldırın
Docker Desktop GUI: Görsel kapsayıcı yönetimi, volume gezinme, kaynak sınırı ayarlamaları ve entegre Kubernetes desteği
Daha düşük giriş bariyeri: Grafik araçlar ve sezgisel komutlar, kapsayıcıları teknolojiye yeni geliştiriciler için erişilebilir kılar

Docker Desktop kullanan ekipler için GUI, işe alıştırmayı ve günlük iş akışlarını önemli ölçüde hızlandıran ek kolaylıklar sunar.

Karmaşık derleme hatları için

Geliştirmenin ötesinde, Docker’ın derleme yetenekleri, gelişmiş sürekli entegrasyon ve dağıtım iş akışları için doğal bir tercih olmasını sağlar.

Docker’ın entegre BuildKit’i, modern CI/CD hatları için kritik gelişmiş özellikler sunar. Çok aşamalı derlemeler, Dockerfile’ları okunabilir tutarken imaj boyutlarını en aza indirir. BuildKit’in önbellekleme mekanizmaları, katmanları derlemeler arasında akıllıca yeniden kullanarak sürekli entegrasyon ortamlarında derleme sürelerini dramatik biçimde azaltır.

GitHub Actions, GitLab CI, Jenkins ve diğerleri gibi çoğu otomasyon platformu, olgun ve sahada kanıtlanmış Docker entegrasyonlarına sahiptir. Bu entegrasyonlar, kimlik doğrulama, önbellekleme ve imaj yayımını sorunsuz şekilde ele alır.

Diğer araçlar benzer sonuçlar elde edebilse de, Docker’ın yaygınlığı çözümlere ve sorun giderme yardımlarına kolay erişim anlamına gelir ki bu da önemli bir artıdır.

Neden Containerd’ı Seçmeli?

Containerd, entegre araçların sağladığı kolaylığın önüne minimalizm, performans ve kararlılığın geçtiği üretim senaryolarında parıldar.

Üretim Kubernetes kümeleri için

Kubernetes düğümleri için çalışma zamanı olarak containerd’ı kullanmak ölçülebilir faydalar getirir:

Azaltılmış ek yük: Docker daemon’ını ortadan kaldırmak, düğüm başına daha düşük kaynak tüketimi ve ölçekte anlamlı tasarruf sağlar
Geliştirilmiş kararlılık: Daha az hareketli parça, altyapınızda daha az olası arıza noktası demektir
Daha küçük saldırı yüzeyi: Daha az denetlenecek kod ve daha az potansiyel güvenlik açığı
Basitleştirilmiş hata ayıklama: Doğrudan CRI entegrasyonu, dockershim çeviri katmanını kaldırarak sorun gidermeyi sadeleştirir
Daha iyi performans: Yalın çalışma zamanı yığını, kapsayıcı başlatma sürelerini ve tepkiselliği iyileştirir

Containerd’ın CNCF mezuniyet statüsü, olgunluğunu ve güvenilirliğini gösterir. AWS, Google Cloud ve Azure dahil büyük bulut sağlayıcıları, yönetilen Kubernetes hizmetleri için containerd’ı standartlaştırmıştır; bu da kritik altyapı için üretime hazır oluşuna duyulan güveni gösterir.

Uzmanlaşmış, minimal ortamlar için

Kubernetes en yaygın üretim kullanım durumu olsa da, containerd’ın hafif yapısı, Docker’ın pratik olmayacağı dağıtım senaryolarının kapısını aralar.

Edge bilişim ve IoT cihazları sıklıkla ciddi kaynak kısıtlarıyla çalışır. Containerd’ın hafif tasarımı, Docker’ın tam yığınının engelleyici olacağı bu ortamlarda uygulanabilir kılar. Gömülü donanımda çalışırken her megabayt bellek ve her CPU döngüsü önemlidir.

Gelişmiş güvenlik senaryoları, containerd’ın modüler çalışma zamanı mimarisinden fayda sağlar. Kuruluşlar, ek güvenlik sınırları gerektiren iş yükleri için izole çalışma zamanlarını entegre edebilir. Örnekler:

gVisor: güçlü çekirdek izolasyonu sağlar
Kata Containers: kapsayıcıları hafif VM’ler içinde çalıştırır

Bu entegrasyonlar, kapsamlı değişiklikler gerektirmeden containerd’a takılabilir.

Docker’dan Containerd’a Geçiş

Hangi aracı ne zaman kullanacağınızı anlamak önemlidir; ancak aralarında nasıl geçiş yapılacağını bilmek de aynı derecede kritiktir. Mevcut ortamlarda Docker’dan containerd’a geçiş dikkatli planlama gerektirir; ancak süreç iyi belgelenmiştir ve düzgündür.

Kubernetes düğümlerini taşıma

Kubernetes düğümlerini Docker’dan containerd’a taşımak için operasyon adımları standart bir deseni izler:

Düğümü kordonlayın: Yeni pod’ların zamanlanmasını önleyin (kubectl cordon <node-name>)
Mevcut pod’ları boşaltın: İş yüklerini diğer düğümlere taşıyın (kubectl drain <node-name>)
Kubelet yapılandırmasını güncelleyin: Containerd’ın CRI soketine işaret edin: /run/containerd/containerd.sock
CNI eklentilerini doğrulayın: Containerd’ın gerekli ağ eklenti ikililerine sahip olduğundan emin olun
Kubelet’i yeniden başlatın: Yeni çalışma zamanı ile kaydolun ve kümeye yeniden katılın

Önce üretim dışı düğümlerde geçişi test etmek, küme genelinde değişiklikleri yaymadan önce ortama özgü sorunları belirlemeye yardımcı olur. Yaygın tuzaklardan kaçınmak için şu en iyi uygulamalara uyduğunuzdan emin olun:

Günlük yolu değişiklikleri: Docker ve containerd varsayılan olarak farklı günlük konumları kullanır; bu nedenle günlükleme altyapınızı buna göre güncelleyin
Eksik CNI eklentilerini kurun: Containerd, ağ için CNI eklenti ikililerini gerektirir; bunlar her zaman varsayılan olarak kurulmaz
İmaj çekme farklılıklarına dikkat edin: Kimlik doğrulama ve kayıt yapılandırmaları ayarlama gerektirebilir
Depolama sürücüsü uyumsuzluklarına dikkat: Kalıcı volumelerinizin containerd’ın snapshotter’ı ile uyumlu olduğundan emin olun

CLI farklarında yol almak

Altyapınız taşındıktan sonra, geliştiricilerin günlük iş akışlarını yeni çalışma zamanıyla uyumlu hale getirmesi gerekir.

Docker komutlarına alışkın geliştiriciler için nerdctl neredeyse birebir aynı bir deneyim sunar. nerdctl run, nerdctl build ve nerdctl compose up gibi komutlar, Docker’daki muadilleriyle birebir çalışır ve geçişi sorunsuz hale getirir.

Hata ayıklama için, Docker’daki hata ayıklama iş akışlarını containerd’a eşlemeyi anlamak önemlidir. Bir kapsayıcıyı incelemek için docker inspect kullanabileceğiniz yerlerde, ctr containers info benzer bilgileri farklı bir formatta sunar. Benzer şekilde, ctr tasks list çalışan kapsayıcıları gösterir.

Çoğu geliştirici, günlük görevler için ctr’ın sözdizimini öğrenmeye gerek bırakmadığı için nerdctl’i yeterli bulur. Düşük seviyeli ctr, çalışma zamanına özgü sorunları giderirken veya containerd’ın API’leriyle doğrudan çalışırken faydalı olmaya devam eder.

Sonuç

Docker ile containerd arasındaki ilişki, yazılım altyapısında başarılı modüler tasarımın mükemmel bir örneğidir. Docker, entegre deneyimi, kapsamlı ekosistemi ve geliştirici dostu arayüzleriyle kod yazan insanlar için en uygun araç olmayı sürdürüyor; bu da kapsayıcılaştırılmış uygulamalar geliştirmeyi verimli (ve keyifli) kılıyor.

Öte yandan containerd, makinaların kodu yürütmesi için çalışma zamanı olarak üretim orkestrasyon platformlarının gerektirdiği kararlılık, performans ve minimalizmi sunarak mükemmelleşir. Docker Engine’in kaputun altında containerd’ı kullanması, bu iki aracın birbirini tamamladığını, rekabet etmediğini gösterir.

Çoğu kuruluş için pragmatik bir yaklaşım öneriyorum: Geliştirme iş akışlarını hızlandıran araç setinden yararlanmak için geliştirici dizüstülerinde Docker’ı kullanmaya devam edin; ancak üretim Kubernetes kümelerini, azaltılmış ek yük ve sadeleştirilmiş çalışma zamanı yığınının operasyonel faydaları için doğrudan containerd’a taşımayı düşünün.

Docker’ın kapsamlı platformunu ya da containerd’ın odaklı çalışma zamanını seçin; her ikisi de modern kapsayıcı ekosisteminin vazgeçilmez bileşenleri olmaya devam ediyor ve uygulama yaşam döngüsünün farklı aşamaları için optimize ediliyor.

Öğrenmeye devam etmek için, Containerization and Virtualization with Docker and Kubernetes yetkinlik yolumuza mutlaka kayıt olun.

Containerd ve Docker SSS

Docker imajlarını containerd ile kullanabilir miyim?

Evet, kesinlikle. Containerd, Docker ile oluşturulanlar da dahil olmak üzere OCI uyumlu herhangi bir kapsayıcı imajını destekler. Docker, OCI standartlarında imajlar oluşturduğundan, bu imajlar containerd ve diğer tüm OCI uyumlu çalışma zamanlarıyla sorunsuz çalışır. Yerelde docker build kullanabilir ve bu imajları üretimde containerd ile herhangi bir uyumluluk sorunu olmadan çalıştırabilirsiniz.

Docker kaputun altında containerd’ı kullanıyor mu?

Evet, Docker Engine çekirdek kapsayıcı çalışma zamanı olarak containerd’ı kullanır. Docker 1.11’den itibaren Docker, oluşturma, yürütme ve yönetim gibi kapsayıcı yaşam döngüsü işlemlerini ele almak için containerd’ı entegre etti. docker run çalıştırdığınızda, Docker daemon’ı (dockerd) kapsayıcıyı fiilen yürütme işini containerd’a devreder; containerd da Linux çekirdeğiyle etkileşim için runc’u kullanır.

Kubernetes neden Docker desteğini kaldırdı?

2022’de Kubernetes, gereksiz bir çeviri katmanını ortadan kaldırmak için dockershim’i (Docker uyumluluk katmanı) kaldırdı. Docker, Container Runtime Interface’ten (CRI) daha önce geldiğinden, Kubernetes API’leri ile Docker arasında çeviri yapmak için dockershim’e ihtiyaç vardı. Kubernetes, CRI aracılığıyla containerd ile doğrudan iletişim kurarak daha iyi performans, kararlılık ve daha basit bir çalışma zamanı yığını elde eder. Docker imajları Kubernetes’te hâlâ sorunsuz çalışır.

Yerel geliştirme için Docker’dan containerd’a geçmeli miyim?

Hayır, yerel geliştirme için Docker daha iyi bir seçim olmaya devam ediyor. Docker, Docker Compose, Docker Desktop’ın GUI’si ve geliştirme iş akışlarını hızlandıran geniş ekosistem desteğiyle entegre bir araç zinciri sunar. Containerd’ı, daha düşük ek yük ve doğrudan CRI entegrasyonunun net faydalar sağladığı üretim Kubernetes kümeleri için kullanın; ancak geliştirici deneyimi açısından üstün olduğu için geliştirici dizüstülerinde Docker’ı tutun.

Nerdctl nedir ve buna ihtiyacım var mı?

Nerdctl, containerd için Docker uyumlu bir CLI’dır ve Docker ile aynı kullanıcı deneyimini (en yaygın komut ve bayrakların desteği) sunar ancak çalışma zamanı olarak containerd’ı kullanır. Containerd ile tanıdık Docker komutlarını kullanarak doğrudan etkileşim kurmak istiyorsanız buna ihtiyaç duyarsınız. Özellikle containerd kullanan geliştirme ortamlarında ya da ekipleri Docker’dan containerd tabanlı iş akışlarına geçirirken faydalıdır.

Yazar

Benito Martin

Martin Data Solutions’ın Kurucusu ve Serbest Çalışan Veri Bilimci, ML ve AI Mühendisi olarak Regresyon, Sınıflandırma, NLP, LLM, RAG, Sinir Ağları, Topluluk Yöntemleri ve Bilgisayarlı Görü alanlarında geniş bir portföy sunuyorum.

Veri temizleme, analitik, modelleme ve AWS ile GCP’de dağıtımı kapsayan uçtan uca birçok ML projesini başarıyla geliştirerek etkili ve ölçeklenebilir çözümler sundum.
Çeşitli sektör kullanım senaryoları için Streamlit ve Gradio ile etkileşimli ve ölçeklenebilir web uygulamaları geliştirdim.
Veri bilimi ve analitik alanlarında öğrencilere eğitim verdim ve mentorluk yaparak kişiselleştirilmiş öğrenme yaklaşımlarıyla mesleki gelişimlerini destekledim.
Kurumsal gereksinimlere uyarlanmış geri getirme destekli üretim (RAG) uygulamaları için kurs içerikleri tasarladım.
MLOps, vektör veritabanları ve LLM’ler gibi konuları ele alan, yüksek etki yaratan yapay zeka ve ML teknik blogları yazdım ve önemli etkileşim sağladım.

Üstlendiğim her projede CI/CD, kod linting’i, biçimlendirme, model izleme, deney takibi ve sağlam hata yönetimi gibi yazılım mühendisliği ve DevOps’taki güncel uygulamaları hayata geçiririm. Tam kapsamlı çözümler sunmaya; veri içgörülerini, işletmelerin büyümesine yardımcı olan ve veri bilimi, makine öğrenimi ile yapay zekâdan en iyi şekilde yararlanan pratik stratejilere dönüştürmeye kararlıyım.

Konular

Docker Veri Mühendisliği Cloud