Şöyle bir durum var Kubernetes’le ilgili: devasa bir yapı. Ve bu devi yönetmek, özellikle de ML eğitim çiftlikleri, ultra düşük gecikmeli ticaret sistemleri veya neredeyse nefes alan veritabanları gibi performans-kritik iş yüklerinden bahsettiğimizde — her zaman hassas bir dans olmuştur. Tahmin edilebilir performans istersiniz, bu da genellikle ana etkinlik için özel, NUMA uyumlu kaynakları ayırmayı gerektirir. Ama pod’lar artık yalnız tek kapsayıcılar değil. Onlar birer ekosistem. Loglama, izleme, servis ağları, veri girişi için yan destekçileri var — her şey dahil.
Tarihsel olarak, ana uygulamanız için o el değmemiş, özel kaynakları elde etmek demek, her şeye baştan girmeniz demekti. Pod’daki her bir kapsayıcı, özel, tam sayı bir CPU dilimi alırdı. İsraf mı? Kesinlikle. Özellikle zar zor CPU tüketen minicik bir metrik dışa aktarıcısı için. Eğer bu sıkı tahsisten kaçınırsanız, pod’un değerli Garantili Hizmet Kalitesi (QoS) sınıfını kaybederdiniz ve onunla birlikte tutarlı, üst düzey performans umudunuzu da. Zorlu uygulamaları çalıştıran herkes için gerçek bir Sophie’nin Seçimi.
Yeni Bir Umut: Pod Seviyesi Yöneticileri Ortaya Çıkıyor
Kubernetes v1.36 ise, Pod Seviyesi Kaynak Yöneticileri‘nin alfa tanıtımıyla iğneyi biraz daha ileri itiyor. Bu sadece bir ayar değil; bu, kubelet’in Topoloji, CPU ve Bellek Yöneticilerinin yeteneklerini genişleten temel bir mimari değişim. En büyük haber ne mi? Artık .spec.resources içinde pod seviyesi kaynak tanımlarını destekliyorlar. Katı kapsayıcı başına tahsis modelinden kesinlikle pod merkezli bir modele geçiyoruz.
Bu yeni özellik kapılarını (PodLevelResourceManagers ve PodLevelResources) etkinleştirmek, kubelet’in hibrit kaynak tahsis modellerini düzenlemesini sağlıyor. Bu demek oluyor ki, yıldız performans gösterenler için o NUMA uyumunu ve özel kaynak tahsisini, daha az talepkar yoldaşlarına CPU çekirdekleri israf etmeden alabilirsiniz. Esneklik verimlilikle buluşuyor, sonunda.
Gerçek Dünya Senaryoları: Lastiğin NUMA ile Buluştuğu Yer
Bu yeni yaklaşımın güzelliği, pratik kullanım durumlarında parlıyor ve büyük ölçüde Topoloji Yöneticisi’nin kapsamına bağlı. Ana kapsayıcı, yerel metrik dışa aktarıcısı ve bir yedekleme ajanı yan destekçisi ile birlikte gelen, gecikmeye duyarlı bir veritabanı pod’u düşünün.
Eğer Topoloji Yöneticisi’ni pod kapsamıyla yapılandırırsanız, kubelet tüm pod’un kaynak bütçesine dayalı tekil bir NUMA hizalaması gerçekleştirir. Kritik veritabanı kapsayıcısı, o belirli NUMA düğümünden özel CPU ve bellek dilimlerini kapar. Geriye ne kaldı? Bir pod paylaşımlı havuzu oluşturur. Metrik dışa aktarıcınız ve yedekleme ajanınız burada ikamet eder. Kaynakları kendi aralarında paylaşırlar, evet, ancak kritik olarak, veritabanının özel dilimlerinden ve düğümün geri kalanından izole edilmişlerdir. Bu çok önemli: özel çekirdekleri israf etmeden yardımcı kapsayıcıları aynı NUMA düğümüne yerleştirebilirsiniz.
podTopoloji Yöneticisi kapsamıyla yapılandırıldığında, kubelet tüm pod’un bütçesine dayalı tek bir NUMA hizalaması gerçekleştirir. Veritabanı kapsayıcısı, o NUMA düğümünden özel CPU ve bellek dilimlerini alır. Pod’un bütçesinden kalan kaynaklar yeni bir pod paylaşımlı havuzu oluşturur.
Bu YAML’de şöyle görünebilir:
apiVersion: v1
kind: Pod
metadata:
name: tightly-coupled-database
spec:
# Pod seviyesi kaynaklar genel bütçeyi ve NUMA hizalama boyutunu belirler.
resources:
requests:
cpu: "8"
memory: "16Gi"
limits:
cpu: "8"
memory: "16Gi"
initContainers:
- name: metrics-exporter
image: metrics-exporter:v1
restartPolicy: Always
- name: backup-agent
image: backup-agent:v1
restartPolicy: Always
containers:
- name: database
image: database:v1
# Bu Garantili kapsayıcı, pod'un bütçesinden özel bir 6 CPU dilimi alır.
# Kalan 2 CPU ve 4Gi bellek, yan destekçiler için pod paylaşımlı havuzunu oluşturur.
resources:
requests:
cpu: "6"
memory: "12Gi"
limits:
cpu: "6"
memory: "12Gi"
Alternatif olarak, altyapı yan destekçileriyle bir ML iş yükü düşünün. Burada muhtemelen container Topoloji Yöneticisi kapsamına yönelirsiniz. Kubelet her kapsayıcıyı ayrı ayrı değerlendirir. Maksimum performans arayışındaki ML eğitim kapsayıcısı, özel, NUMA uyumlu CPU’larını ve belleğini alır. Servis ağı yan destekçisi mi? O özel muameleye ihtiyacı yok; düğüm genelindeki paylaşımlı havuzda mutlu mesut çalışır. Toplam kaynak tüketimi hala genel pod sınırlarıyla sınırlıdır, ancak o özel, NUMA uyumlu kaynakları yalnızca gerçekten ihtiyaç duyulan yerlere ihtiyatlı bir şekilde uyguluyorsunuz.
apiVersion: v1
kind: Pod
metadata:
name: ml-workload
spec:
# Pod seviyesi kaynaklar genel bütçe kısıtlamasını belirler.
resources:
requests:
cpu: "4"
memory: "8Gi"
limits:
cpu: "4"
memory: "8Gi"
initContainers:
- name: service-mesh-sidecar
image: service-mesh:v1
restartPolicy: Always
containers:
- name: ml-training
image: ml-training:v1
# 'container' kapsamı altında, bu Garantili kapsayıcı özel,
# NUMA uyumlu kaynakları alırken, yan destekçi düğümün paylaşımlı havuzunda çalışır.
resources:
requests:
cpu: "3"
memory: "6Gi"
limits:
cpu: "3"
memory: "6Gi"
CPU Kotaları ve İzolasyon Sanatı
İzolasyon anahtardır ve bu karma iş yükleri için farklı şekilde ele alınır. Özel CPU dilimleri alan kapsayıcılar için, CPU CFS kota zorlaması kapsayıcı seviyesinde devre dışı bırakılır. Bu, genellikle çekirdeğin Tam Adil Zamanlayıcısı (CFS) tarafından uygulanan kısıtlamalar olmadan çalıştıkları anlamına gelir, bu da onların engellenmeden patlamalarını ve performans göstermelerini sağlar.
Özel CPU dilimleri almayan kapsayıcılar için, bir paylaşımlı havuzun parçası haline gelirler – ister pod seviyesi paylaşımlı havuz, ister düğüm genelindeki paylaşımlı havuz olsun. Bu kapsayıcılar CFS kota zorlamasına sahiptir. CFS zamanlama politikasına göre kaynakları paylaşırlar. Temel süreçleri aç bırakmalarını önlemek için tasarlanmış nüanslı bir sistemdir, aynı zamanda yüksek bahisli uygulamalar için özel hatlar sağlarken.
Temel Değişim: Kapsayıcılardan Podlara
Bu pod seviyesi kaynak yönetimine geçiş, bir optimizasyondan daha fazlasıdır; Kubernetes içinde felsefi bir değişimdir. Yıllardır, temel planlama ve kaynak tahsis birimi kapsayıcı olmuştur. Bu yeni özellik, modern uygulamaların genellikle bir pod içinde dağıtıldığını ve bu dağıtılmış bileşenleri birleşik bir birim olarak yönetmenin performans ve verimlilik için kritik olduğunu kabul ediyor. Pod’u bağımsız süreçlerin bir koleksiyonundan çok, tek bir, karmaşık da olsa, uygulama örneği olarak ele almakla ilgili.
Bu, yüksek performanslı uygulamaları nasıl tasarlayıp dağıttığımız konusunda büyüleyici olasılıklar açıyor. Bireysel kapsayıcı kaynak ihtiyaçlarını titizlikle hesaplamak ve QoS etkileriyle mücadele etmek yerine, artık bir pod’un genel kaynak ayak izini tanımlayabilir ve ardından bu bütçe dahilinde akıllıca yetki devri yapabiliriz. Operasyonları kolaylaştırır ve daha da önemlisi, performans cezaları olmadan daha sıkı kaynak kullanımı sağlar. Bu, FinOps ekipleri ve o ulaşılmaz performans metriklerinin peşinde koşan mühendisler için bir kazanç.
Geliştiriciler ve Operatörler İçin Anlamı
Geliştiriciler için bu, karmaşık pod’lar için kaynak gereksinimlerini belirtmenin daha sezgisel bir yolunu sunar. Performans-kritik bileşenlerinizi ve destekleyici kadrolarını net bir şekilde ayırabilirsiniz. Operatörler için, bu daha verimli düğüm kullanımı ve potansiyel olarak daha iyi maliyet tasarrufu anlamına gelir, çünkü ana uygulama için QoS’yi sürdürmek için yan destekçiler için kaynakları aşırı tahsis etmiyorsunuz. Bu, Kubernetes’i en zorlu iş yükleri için daha uygulanabilir bir platform haline getirme yolunda önemli bir adımdır.
Elbette, bu alfa. Pürüzlü kenarlar, değişiklikler ve tabii ki olgunlaştıkça daha fazla sorgulama bekleyin. Ama yön açık: Kubernetes, temel donanımın sınırlı kaynaklarını nasıl tahsis ettiği konusunda akıllanıyor ve bu izlemeye değer bir gelişme.
