Kubernetes'i kullanmaya başladığınızda konteyner kaynaklarını ayarlamayı unutmak yaygın bir durumdur. Bu noktada Docker imajının çalışmasını ve Kubernetes kümesine dağıtılabilmesini sağlamak yeterlidir.
Ancak daha sonra uygulamanın diğer uygulamalarla birlikte bir üretim kümesinde konuşlandırılması gerekir. Bunu yapmak için, konteyner için kaynak ayırmanız ve uygulamayı çalışır duruma getirmek için yeterli sayıda kaynak olduğundan ve çalışan diğer uygulamalarda sorun yaşamayacağından emin olmanız gerekir.
Ekip Konteyner kaynakları (CPU ve MEM), istekler ve kaynak sınırlamaları hakkında bir makalenin çevirisini yaptı. Bu ayarların avantajlarını ve bunları ayarlamazsanız ne olacağını öğreneceksiniz.
bilgi işlem kaynakları
Aşağıdaki birimlere sahip iki tür kaynağımız var:
- Merkezi işlem birimi (CPU) - çekirdekler;
- Bellek (MEM) - bayt.
Kaynaklar her kapsayıcı için belirtilir. Aşağıdaki Pod YAML dosyasında istenen ve sınırlanan kaynakları içeren bir kaynak bölümü göreceksiniz:
- İstenen Kapsül Kaynakları = tüm kapsayıcılar için istenen kaynakların toplamı;
- Kapsül Kaynak Sınırı = Tüm Kapsül Kaynak Sınırlarının toplamı.
apiVersion: v1
kind: Pod
metadata:
name: backend-pod-name
labels:
application: backend
spec:
containers:
— name: main-container
image: my-backend
tag: v1
ports:
— containerPort: 8080
resources:
requests:
cpu: 0.2 # REQUESTED CPU: 200m cores
memory: "1Gi" # REQUESTED MEM: 1Gi
limits:
cpu: 1 # MAX CPU USAGE: 1 core
memory: "1Gi" # MAX MEM USAGE: 1Gi
— name: other-container
image: other-app
tag: v1
ports:
— containerPort: 8000
resources:
requests:
cpu: "200m" # REQUESTED CPU: 200m cores
memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
limits:
cpu: 1 # MAX CPU USAGE: 1 core
memory: "1Gi" # MAX MEM USAGE: 1GiTalep Edilen ve Sınırlı Kaynaklara Örnek
Tarla resources.requested spesifikasyondan Pod, istenen düğümü bulmak için kullanılan öğelerden biridir. Bunun için zaten Pod dağıtımını planlayabilirsiniz. Uygun bir düğümü nasıl bulursunuz?
Kubernetes, bir ana düğüm veya ana düğüm (Kubernetes Kontrol Düzlemi) dahil olmak üzere çeşitli bileşenlerden oluşur. Ana düğümün çeşitli süreçleri vardır: kube-apserver, kube-denetleyici-yönetici ve kube-zamanlayıcı.
Kube zamanlayıcı süreci, yeni oluşturulan bölmeleri gözden geçirmekten ve talep edilen kaynak sayısı da dahil olmak üzere tüm bölme istekleriyle eşleşen olası çalışan düğümleri bulmaktan sorumludur. Kube-scheduler tarafından bulunan düğümlerin listesi sıralanır. Kapsül en yüksek puana sahip düğümde planlanır.
Mor Kapsül nereye yerleştirilecek?
Resimde kube-scheduler'ın yeni bir mor Pod planlaması gerektiğini görebilirsiniz. Kubernetes kümesi iki düğüm içerir: A ve B. Gördüğünüz gibi kube-scheduler, A düğümünde bir Pod planlayamaz; mevcut (istenmeyen) kaynaklar, mor Pod'un istekleriyle eşleşmiyor. Dolayısıyla, mor Pod'un talep ettiği 1 GB'lık bellek, kullanılabilir bellek 0,5 GB olduğundan A düğümüne sığmayacaktır. Ancak B düğümünün yeterli kaynağı var. Sonuç olarak kube-scheduler, mor Pod'un hedefinin B düğümü olduğuna karar verir.
Artık talep edilen kaynakların Pod'u çalıştıracak düğüm seçimini nasıl etkilediğini biliyoruz. Peki marjinal kaynakların etkisi nedir?
Kaynak sınırı, CPU/MEM'in geçemeyeceği bir sınırdır. Ancak CPU kaynağı esnek olduğundan CPU sınırlarına ulaşan konteynerler Pod'un çıkmasına neden olmaz. Bunun yerine CPU kısıtlaması başlayacak. MEM kullanım sınırına ulaşıldığında konteyner OOM-Killer nedeniyle durdurulacak ve RestartPolicy ayarı izin veriyorsa yeniden başlatılacaktır.
İstenilen ve maksimum kaynaklar ayrıntılı olarak
Docker ve Kubernetes arasındaki kaynak iletişimi
Kaynak isteklerinin ve kaynak sınırlarının nasıl çalıştığını açıklamanın en iyi yolu Kubernetes ile Docker arasındaki ilişkiyi tanıtmaktır. Yukarıdaki görselde Kubernetes alanları ile Docker başlangıç bayraklarının nasıl ilişkili olduğunu görebilirsiniz.
Bellek: istek ve sınırlama
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Yukarıda belirtildiği gibi bellek bayt cinsinden ölçülür. Dayalı hafızayı sayı olarak belirtebiliriz. Genellikle bir tam sayıdır, örneğin 2678 - yani 2678 bayttır. Sonekleri de kullanabilirsiniz G и Giasıl önemli olan bunların eşdeğer olmadığını hatırlamaktır. Birincisi ondalık, ikincisi ikili. k8s belgelerinde belirtilen örnek gibi: 128974848, 129e6, 129M, 123Mi - pratik olarak eşdeğerdirler.
Kubernetes seçeneği limits.memory bayrakla eşleşiyor --memory Docker'dan. durumunda request.memory Docker bu alanı kullanmadığından Docker için ok işareti bulunmamaktadır. Bu gerekli mi diye sorabilirsiniz. Evet lazım. Daha önce de söylediğim gibi Kubernetes için saha önemli. Kube-scheduler, buradan gelen bilgilere dayanarak Pod'u hangi düğümün programlayacağına karar verir.
Bir istek için yetersiz bellek ayarlarsanız ne olur?
Kapsayıcı istenen belleğin sınırlarına ulaştıysa Pod, düğümde yeterli bellek olmadığında duran bir Pod grubuna yerleştirilir.
Bellek sınırını çok düşük ayarlarsanız ne olur?
Kapsayıcı bellek sınırını aşarsa OOM-Killed nedeniyle sonlandırılacaktır. Ve mümkünse, varsayılan değerin olduğu RestartPolicy'ye göre yeniden başlatılacaktır. Always.
İstenen belleği belirtmezseniz ne olur?
Kubernetes limit değerini alıp varsayılan değer olarak ayarlayacaktır.
Bellek sınırı belirtmezseniz ne olabilir?
Container'ın herhangi bir kısıtlaması yoktur; istediği kadar bellek kullanabilir. Düğümün tüm mevcut belleğini kullanmaya başlarsa OOM onu öldürecektir. Konteyner daha sonra mümkünse RestartPolicy'ye göre yeniden başlatılacaktır.
Bellek sınırlarını belirtmezseniz ne olur?
Bu en kötü durum senaryosudur: Zamanlayıcı konteynerin ne kadar kaynağa ihtiyaç duyduğunu bilmez ve bu durum düğümde ciddi sorunlara neden olabilir. Bu durumda, ad alanında varsayılan sınırlamaların (LimitRange tarafından belirlenen) olması güzel olurdu. Varsayılan sınır yoktur; Pod'un sınırı yoktur, istediği kadar bellek kullanabilir.
İstenen bellek düğümün sunabileceğinden fazlaysa Kapsül planlanmayacaktır. Bunu hatırlamak önemlidir Requests.memory - minimum değer değil. Bu, konteynerin sürekli çalışmasını sağlamak için yeterli bellek miktarının açıklamasıdır.
Genellikle aynı değerin ayarlanması önerilir. request.memory и limit.memory. Bu, Kubernetes'in, Pod'u çalıştırmak için yeterli belleğe sahip ancak onu çalıştırmak için yeterli olmayan bir düğümde bir Pod planlamamasını sağlar. Unutmayın: Kubernetes Pod planlaması yalnızca dikkate alınır requests.memoryVe limits.memory dikkate almaz.
CPU: istek ve sınırlama
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
CPU ile her şey biraz daha karmaşıktır. Kubernetes ile Docker arasındaki ilişkinin resmine dönersek şunu görebilirsiniz: request.cpu maçlar --cpu-sharesoysa limit.cpu bayrakla eşleşiyor cpus Docker'da.
Kubernetes'in talep ettiği CPU, CPU döngülerinin oranı olan 1024 ile çarpılır. 1 adet full core talep etmek istiyorsanız şunu eklemelisiniz cpu: 1Yukarıda gösterildiği gibi.
Tam çekirdek talep etmeniz (oran = 1024), konteynerinizin onu alacağı anlamına gelmez. Ana makinenizde yalnızca bir çekirdek varsa ve birden fazla konteyner çalıştırıyorsanız tüm konteynerlerin mevcut CPU'yu aralarında paylaşması gerekir. Bu nasıl oluyor? Şimdi resme bakalım.
CPU İsteği - Tek Çekirdekli Sistem
Container'ları çalıştıran tek çekirdekli bir ana bilgisayar sisteminiz olduğunu hayal edelim. Anne (Kubernetes) bir pasta (CPU) pişirdi ve bunu çocuklar (kaplar) arasında bölmek istiyor. Üç çocuk pastanın tamamını (oran = 1024), diğer çocuk ise pastanın yarısını (512) istiyor. Annem adil olmak istiyor ve basit bir hesaplama yapıyor.
# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%Hesaplamaya göre üç çocuk çekirdeğin tamamını değil %28'ini alacak. Dördüncü çocuk tam çekirdeğin yarısını değil %14'ünü alacak. Ancak çok çekirdekli bir sisteminiz varsa işler farklı olacaktır.
CPU İsteği - Çok Çekirdekli (4) Sistem
Yukarıdaki resimde üç çocuğun pastanın tamamını, birinin de yarısını istediğini görebilirsiniz. Annem dört turta pişirdiğine göre her çocuğuna istediği kadar pasta verilecek. Çok çekirdekli bir sistemde işlemci kaynakları mevcut tüm işlemci çekirdeklerine dağıtılır. Bir kapsayıcı birden az tam CPU çekirdeğiyle sınırlıysa yine de onu %100 oranında kullanabilir.
Yukarıdaki hesaplamalar CPU'nun konteynerler arasında nasıl dağıtıldığını anlamak için basitleştirilmiştir. Elbette konteynerlerin yanı sıra CPU kaynaklarını kullanan başka işlemler de var. Bir kapsayıcıdaki işlemler boşta olduğunda diğerleri onun kaynağını kullanabilir. CPU: "200m" maçlar CPU: 0,2bu da bir çekirdeğin yaklaşık %20'si anlamına gelir.
Şimdi hakkında konuşalım limit.cpu. Kubernetes'in sınırladığı CPU 100 ile çarpılır. Sonuç, konteynerin her 100 µs'de kullanabileceği süre miktarıdır (cpu-period).
limit.cpu Docker bayrağıyla eşleşir --cpus. Bu eskinin yeni bir birleşimi --cpu-period и --cpu-quota. Bunu ayarlayarak, kısıtlama başlamadan önce konteynerin maksimum olarak ne kadar kullanılabilir CPU kaynağı kullanabileceğini belirtiriz:
- cpus - kombinasyon
cpu-periodиcpu-quota. cpus = 1.5ayarlamaya eşdeğercpu-period = 100000иcpu-quota = 150000; - CPU dönemi - dönem , varsayılan 100 mikrosaniye;
- işlemci kotası - içindeki mikrosaniye sayısı
cpu-period, konteyner tarafından sınırlandırılmıştır.
Yetersiz miktarda istenen CPU takarsanız ne olur?
Konteynerin yüklü olduğundan daha fazlasına ihtiyacı varsa, diğer işlemlerden CPU çalacaktır.
CPU limitini çok düşük ayarlarsanız ne olur?
CPU kaynağı ayarlanabilir olduğundan azaltma açılacaktır.
Bir CPU isteği belirtmezseniz ne olur?
Bellekte olduğu gibi istek değeri de sınıra eşittir.
CPU limiti belirtmezseniz ne olur?
Konteyner ihtiyaç duyduğu kadar CPU kullanacaktır. Ad alanında varsayılan bir CPU ilkesi (LimitRange) tanımlanmışsa bu sınır kapsayıcı için de kullanılır.
Bir istek veya CPU sınırı belirtmezseniz ne olur?
Bellekte olduğu gibi bu da en kötü senaryodur. Zamanlayıcı, konteynerinizin ne kadar kaynağa ihtiyaç duyduğunu bilmez ve bu, düğümde ciddi sorunlara neden olabilir. Bunu önlemek için ad alanlarına yönelik varsayılan sınırları (LimitRange) ayarlamanız gerekir.
Unutmayın: Düğümlerin sağlayabileceğinden daha fazla CPU talep ederseniz Pod programlanmayacaktır. Requests.cpu - minimum değer değil, Pod'u başlatmak ve hatasız çalışmak için yeterli bir değer. Uygulama karmaşık hesaplamalar gerçekleştirmiyorsa en iyi seçenek request.cpu <= 1 ve gerektiği kadar kopya başlatın.
İdeal miktarda istenen kaynak veya kaynak limiti
Bilgi işlem kaynaklarının sınırlamasını öğrendik. Şimdi şu soruyu cevaplamanın zamanı geldi: “Uygulamayı sorunsuz bir şekilde çalıştırmak için Pod'umun kaç kaynağa ihtiyacı var? İdeal miktar nedir?
Ne yazık ki bu soruların net bir cevabı yok. Uygulamanızın nasıl çalıştığını veya ne kadar CPU veya belleğe ihtiyaç duyduğunu bilmiyorsanız en iyi seçenek, uygulamaya çok fazla bellek ve CPU vermek ve ardından performans testleri çalıştırmaktır.
Performans testlerine ek olarak bir hafta boyunca uygulamanın izlemedeki davranışını izleyin. Grafikler uygulamanızın talep ettiğinizden daha az kaynak tükettiğini gösteriyorsa talep edilen CPU veya bellek miktarını azaltabilirsiniz.
Örnek olarak buna bakın . İstenen kaynaklar veya kaynak sınırı ile mevcut kaynak kullanımı arasındaki farkı görüntüler.
Sonuç
Kaynak istemek ve sınırlamak Kubernetes kümenizin sağlıklı kalmasına yardımcı olur. Doğru limit konfigürasyonu maliyetleri en aza indirir ve uygulamaların her zaman çalışır durumda kalmasını sağlar.
Kısacası akılda tutulması gereken birkaç şey var:
- İstenen kaynaklar, başlatma sırasında (Kubernetes uygulamayı barındırmayı planladığında) dikkate alınan bir yapılandırmadır. Bunun tersine, kaynakların sınırlandırılması çalışma zamanında (uygulama zaten düğümde çalışırken) önemlidir.
- Bellekle karşılaştırıldığında CPU düzenlenmiş bir kaynaktır. Yeterli CPU yoksa Pod'unuz kapanmaz ve kısma mekanizması açılır.
- Talep edilen kaynaklar ve kaynak limiti minimum ve maksimum değerler değildir! Talep edilen kaynakları tanımlayarak uygulamanın sorunsuz çalışmasını sağlarsınız.
- Bellek isteğini bellek sınırına eşitlemek iyi bir uygulamadır.
- Tamam yükleme istendi
CPU <=1Uygulama karmaşık hesaplamalar gerçekleştirmiyorsa. - Bir düğümde mevcut olandan daha fazla kaynak talep ederseniz Kapsül hiçbir zaman o düğüme planlanmayacaktır.
- İstenen kaynakların/kaynak sınırlarının doğru miktarını belirlemek için yük testini ve izlemeyi kullanın.
Umarım bu makale kaynak sınırlamasının temel kavramını anlamanıza yardımcı olur. Ve bu bilgiyi işinizde uygulayabileceksiniz.
İyi şanslar!
Okumak için başka ne var:
- .
- .
- .
Kaynak: habr.com