Windows Server 2022 özelinde containers ile ilgili bilgilere aşağıdaki yazımdan ulaşabilirsiniz.

Windows Server 2022’den itibaren Windows platformunda iki tür container mevcuttur: Windows Server containers ve Hyper-V Containers. Her container türü, Windows Server 2022’nin Server core veya Nano Server SKU’sunu destekler.

Windows Server Container and Hyper-V Containers

Windows Server container ve Hyper-V containerları, aynı taşınabilirlik ve tutarlılık avantajlarının çoğunu sunar, ancak isolation anlamında ve performans özellikleri açısından farklılık gösterir.

Windows Server Containers;  process ve namespace teknolojisi aracılığıyla uygulama yalıtımı sağlar. Bir Windows Server containerı, kerneli, container host ile ve ana bilgisayar üzerinde çalışan tüm diğer containerlarla paylaşır. Yani kernel isolation mevcut değildir.

Hyper-V Containers, her bir container yüksek düzeyde optimize edilmiş bir sanal makinede çalıştırarak Windows Server containers tarafından sağlanan yalıtımı genişletir. Bu yapılandırmada, ana hostun kerneli, Hyper-V Kapsayıcıları ile paylaşılmaz. Yani tüm containerlar için kernel bazında bir isolation mevcuttur.

Hyper-V containerlar tarafından sağlanan ekstra izolasyon, büyük ölçüde containerlar ile container ana bilgisayarı arasındaki hypervisor isolation layer ile sağlanır. Bu durum, Windows Server containerlarının aksine, container yoğunluğunu etkiler, sistem dosyalarının ve ikili dosyaların daha az paylaşımı gerçekleşebilir ve bu da genel olarak daha büyük bir depolama ve bellek ayak izi ile sonuçlanır. Ayrıca, bazı ağ, depolama I/O ve CPU yollarında beklenen ek yük vardır.

Yani performans anlamında aynı kerneli paylaştığı için Windows Server containerlar daha avantajlı durumdadır. Ama aynı kernel’i paylaştıkları için de bu durum bazı caselerde tercih edilmeyebilir.

Ayrıca aşağıdaki makalem ilginizi çekebilir.

Windows Server 2022 üzerine Container Kurulumu

Nano Server and Server Core

Windows Server containerlar ve Hyper-V containerlar, Sunucu kerneli ve Windows Server 2022’de bulunan yeni bir yükleme seçeneği için destek sunar: Nano Server.

Nano Server, özel bulutlar ve veri merkezleri için optimize edilmiş, uzaktan yönetilen bir sunucu işletim sistemidir. Sunucu kerneli modunda Windows Server’a benzer, ancak önemli ölçüde daha küçüktür, yerel oturum açma özelliği yoktur ve yalnızca 64 bit uygulamaları, araçları ve aracıları destekler. Windows Server’dan çok daha az disk alanı kaplar, önemli ölçüde daha hızlı kurulur ve çok daha az güncelleme ve yeniden başlatma gerektirir. Yeniden başlatıldığında, çok daha hızlı yeniden başlar.

Container Start-Up Time

Container başlatma süresi, containerların bir çok senaryoda en önemli ölçüdür. Bu nedenle, container başlatma süresi için en iyi şekilde nasıl optimize edileceğini anlamak çok önemlidir. Aşağıda, daha iyi başlatma süresi elde etmek için anlaşılması gereken bazı konfigürasyon önerleri bulunmaktadır.

First Logon

Microsoft, hem Nano Server hem de server kerneli için bir temel image gönderir. Sunucu kerneli için gönderilen temel image, ilk oturum açma (OOBE) ile ilişkili başlatma süresi ek yükü kaldırılarak optimize edilmiştir. Nano Sunucu temel imajında durum böyle değildir. Ancak bu maliyet, container imajına en az bir katman taahhüt edilerek Nano Sunucu tabanlı imajlardan çıkarılabilir. imajdan sonraki kapsayıcı başlangıçları, ilk oturum açma maliyetine neden olmaz.

Scratch Space Location

Containerlar, varsayılan olarak, çalışan containerın ömrü boyunca depolama için kapsayıcı ana bilgisayarının sistem sürücüsü ortamında geçici bir boş alan kullanır. Bu, containerın sistem sürücüsü olarak hizmet eder ve container işleminde yapılan yazma ve okumaların çoğu bu yolu takip eder.

Sistem sürücüsünün dönen disk manyetik ortamında (HDD’ler) bulunduğu ancak daha hızlı depolama ortamının mevcut olduğu (daha hızlı HDD’ler veya SSD’ler) ana sistemler için, kap çalışma alanını farklı bir sürücüye taşımak mümkündür. Bu, dockerd –g komutu kullanılarak elde edilir. Bu komut geneldir ve sistemde çalışan tüm kapsayıcıları etkiler.

Nested Hyper-V Containers

Windows Server 2022 için Hyper-V, nested hyper-v desteği sunar. Yani, sanal bir makineyi sanal bir makineden çalıştırma yeteneği. Bu, birçok senaryoda olumludur, özellikle test senaryolarında ancak aynı zamanda, fiziksel ana bilgisayarın üzerinde çalışan iki hiper yönetici düzeyi olduğundan, hiper yöneticinin maruz kaldığı bazı performans etkilerini abartır.

Containerlar için bu, bir sanal makine içinde bir Hyper-V kapsayıcısını çalıştırırken bir etkiye sahiptir. Bir Hyper-V Konteyner, kendisi ve konteyner ana bilgisayarı arasında bir hiper yönetici katmanı aracılığıyla yalıtım sunduğundan, kapsayıcı ana bilgisayar Hyper-V tabanlı bir sanal makine olduğunda, kapsayıcı başlatma süresi, depolama I/O, network açısından ilişkili performans ek yük meydana getirir.

Storage

Mounted Data Volumes

Containerlar, container çalışma alanı için container ana bilgisayar sistem sürücüsünü kullanma yeteneği sunar. Bununla birlikte, konteyner çizik alanı, konteynerin ömrüne eşit bir ömre sahiptir. Yani, container durdurulduğunda, karalama alanı ve ilgili tüm veriler kaybolur.

Ancak, verilerin container ömründen bağımsız olarak devam etmesinin istendiği birçok senaryo vardır. Bu durumlarda, container ana bilgisayardan containerdan veri hacimlerinin mount edilmesini Windows destekler.

Scratch Space

Hem Windows Server containerları hem de Hyper-V containerları, varsayılan olarak container çalışma alanı için 20 GB dynamic VHD sağlar. Her iki container türü için, container işletim sistemi bu alanın bir kısmını kaplar ve bu, başlatılan her container için geçerlidir. Bu nedenle, başlatılan her kapsayıcının bir miktar depolama etkisi olduğunu ve iş yüküne bağlı olarak 20 GB’a kadar yedek depolama ortamı yazabileceğini hatırlamak önemlidir. Sunucu depolama yapılandırmaları bu akılda tutularak tasarlanmalıdır.

Networking

Windows Server containerları ve Hyper-V containerları, farklı ağ yapılandırmalarının ihtiyaçlarını en iyi şekilde karşılayacak çeşitli ağ oluşturma modları sunar. Bu seçeneklerin her biri kendi performans özelliklerini sunar.

Windows Network Address Translation (WinNAT)

Her container, dahili, özel bir IP prefixden bir IP adresi alacaktır (örneğin, 172.16.0.0/12). Kapsayıcı ana bilgisayardan kapsayıcı uç noktalarına bağlantı noktası iletme/eşleme desteklenir. Docker, dockerd ilk çalıştığında varsayılan olarak bir NAT ağı oluşturur.

Winnat, biraz sonra değineceğimiz üç moddan NAT yapılandırması en pahalı ağ IO yoludur, ancak gereken en az yapılandırma miktarına sahiptir.

Windows Server containerları, sanal anahtara eklemek için bir Ana Bilgisayar vNIC’sini kullanır. Hyper-V Kapsayıcıları, sanal anahtara eklemek için bir sanal VM Nic  kullanır. Containerlar harici ağ ile iletişim kurarken, paketler, bir miktar ek yüke neden olan nat uygulanarak WinNAT üzerinden yönlendirilir.

Transparent

Her container endpoint doğrudan fiziksel ağa bağlıdır. Fiziksel ağdan IP adresleri, harici bir DHCP sunucusu kullanılarak statik veya dinamik olarak atanabilir.

Transparent mod, ağ I/O yolu açısından en ucuz olanıdır ve harici paketler, harici ağa doğrudan erişim sağlayan sanal kapsayıcı NIC’ye doğrudan geçirilir.

L2 Bridge

Her container endpoint, container ana bilgisayarıyla aynı IP alt ağında olacaktır. IP adresleri, kapsayıcı ana bilgisayarıyla aynı prefixten statik olarak atanmalıdır. Ana bilgisayardaki tüm kapsayıcı end pointler, Layer2 adres çevirisi nedeniyle aynı MAC adresine sahip olacaktır.

L2 bridge Modu, harici ağa doğrudan erişim sağladığı için WinNAT modundan daha performanslıdır, ancak MAC adresi çevirisini de sunduğu için Şeffaf moddan daha az performans gösterir.