Her Kubernetes kaynağı için iki tür gereksinimi yapılandırabilirsiniz: İstekler ve Sınırlar. Birincisi, bir konteyneri veya kapsülü çalıştırmak için gerekli olan serbest düğüm kaynaklarının mevcudiyetine ilişkin minimum gereksinimleri tanımlar, ikincisi ise konteynerin kullanabileceği kaynakları kesin olarak sınırlar.
Kubernetes pod'ları planladığında konteynerlerin düzgün çalışması için yeterli kaynağa sahip olması çok önemlidir. Kaynakları kısıtlı bir düğümde büyük bir uygulamayı dağıtmayı planlıyorsanız, düğümün belleğinin azalması veya CPU gücünün tükenmesi nedeniyle çalışmaması mümkündür. Bu makalede, kaynak isteklerini ve limitlerini kullanarak bilgi işlem gücü kesintilerini nasıl çözebileceğinize bakacağız.
İstekler ve Sınırlar, Kubernetes'in CPU ve bellek gibi kaynakları yönetmek için kullandığı mekanizmalardır. İstekler, konteynerin istenen kaynağı almasını sağlayan şeylerdir. Bir kapsayıcı kaynak talep ederse Kubernetes bunu yalnızca bunu sağlayabilecek bir düğümde planlar. Limitler, konteynerin talep ettiği kaynakların hiçbir zaman belirli bir değeri aşmayacağını kontrol eder.
Bir kapsayıcı, bilgi işlem gücünü yalnızca belirli bir sınıra kadar artırabilir, bu sınırdan sonra sınırlı olacaktır. Nasıl çalıştığını görelim. Yani iki tür kaynak vardır: işlemci ve bellek. Kubernetes zamanlayıcı, bölmelerinizi nerede çalıştıracağınızı bulmak için bu kaynaklarla ilgili verileri kullanır. Bir kapsül için tipik bir kaynak spesifikasyonu şuna benzer.
Bir bölmedeki her kapsayıcı, kendi sorgularını ve sınırlarını ayarlayabilir; bunların tümü eklemelidir. İşlemci kaynakları mili çekirdek cinsinden tanımlanır. Konteynerinizin çalışması için iki tam çekirdeğe ihtiyacı varsa değeri 2000m olarak ayarlarsınız. Konteyner çekirdeğin yalnızca 1/4'ünün gücüne ihtiyaç duyuyorsa değer 250m olacaktır. En büyük düğümün çekirdek sayısından daha büyük bir CPU kaynak değeri atarsanız kapsülünüzün hiç başlayacak şekilde programlanmayacağını unutmayın. Dört çekirdeğe ihtiyaç duyan bir Pod'unuz varsa ve Kubernetes kümesi yalnızca iki ana sanal makineden oluşuyorsa benzer bir durum ortaya çıkar.
Uygulamanız özellikle birden fazla çekirdeğin avantajlarından yararlanacak şekilde tasarlanmadığı sürece (karmaşık bilimsel bilgi işlem ve veritabanı işlemleri gibi programlar akla gelir), o zaman en iyi uygulama CPU İsteklerini 1 veya daha düşük bir değere ayarlamak ve ardından ölçeklenebilirlik için daha fazla kopya çalıştırmaktır. Bu çözüm sisteme daha fazla esneklik ve güvenilirlik sağlayacaktır.
CPU sınırlamaları söz konusu olduğunda, sıkıştırılabilir bir kaynak olarak kabul edildiğinden işler daha da ilginçleşiyor. Uygulamanız işlemci güç sınırına yaklaşmaya başlarsa Kubernetes, CPU Azaltma özelliğini kullanarak konteynerinizi yavaşlatmaya başlayarak işlemci frekansını azaltır. Bu, CPU'nun yapay olarak kısıtlanacağı ve uygulamanın potansiyel olarak daha kötü performansa neden olacağı, ancak sürecin sonlandırılmayacağı veya kaldırılmayacağı anlamına gelir.
Bellek kaynakları bayt cinsinden tanımlanır. Genellikle ayarlardaki değer mebibayt Mib cinsinden ölçülür, ancak baytlardan petabaytlara kadar herhangi bir değeri ayarlayabilirsiniz. CPU için de aynı durum geçerlidir; düğümlerinizdeki bellek miktarından daha büyük bir bellek miktarı için istekte bulunursanız, bu bölmenin yürütülmesi planlanmayacaktır. Ancak CPU kaynaklarının aksine bellek sıkıştırılmaz çünkü kullanımını sınırlamanın bir yolu yoktur. Bu nedenle, konteynerin yürütülmesi, kendisine ayrılan hafızanın ötesine geçtiği anda durdurulacaktır.
Düğümlerinizin sağlayabileceği kaynakları aşan istekleri yapılandıramayacağınızı unutmamanız önemlidir. GKE sanal makineleri için paylaşılan kaynak özelliklerini bu videonun altındaki bağlantılarda bulabilirsiniz.
İdeal bir dünyada, konteynerin varsayılan ayarları iş akışlarının sorunsuz çalışmasını sağlamak için yeterli olacaktır. Ancak gerçek dünya böyle değil, insanlar kaynakların kullanımını yapılandırmayı kolaylıkla unutabiliyor ya da bilgisayar korsanları altyapının gerçek yeteneklerini aşan istekler ve kısıtlamalar koyabiliyor. Bu tür senaryoların oluşmasını önlemek için ResourceQuota ve LimitRange kaynak kotalarını yapılandırabilirsiniz.
Bir ad alanı oluşturulduktan sonra kotalar kullanılarak engellenebilir. Örneğin, prod ve dev ad alanlarına sahipseniz, üretim kotalarının hiç olmaması ve geliştirme kotalarının çok katı olması şeklinde bir model vardır. Bu, trafikte keskin bir artış olması durumunda prod'un mevcut kaynağın tamamını ele geçirmesine ve geliştirmeyi tamamen engellemesine olanak tanır.
Kaynak kotası şu şekilde görünebilir. Bu örnekte 4 bölüm vardır; bunlar kodun 4 alt satırıdır.
Her birine bakalım. İstekler.cpu, ad alanındaki tüm kapsayıcılardan gelebilecek birleştirilmiş CPU isteklerinin maksimum sayısıdır. Bu örnekte, 50 milyon istek içeren 10 kapsayıcınız, 100 milyon istek içeren beş kapsayıcınız veya 500 milyon istek içeren yalnızca bir kapsayıcınız olabilir. Belirli bir ad alanının toplam request.cpu sayısı 500 m'den az olduğu sürece her şey yolunda olacaktır.
Bellek talep edilen request.memory, ad alanındaki tüm kapsayıcıların sahip olabileceği maksimum birleşik bellek isteği miktarıdır. Önceki durumda olduğu gibi, ad alanında talep edilen toplam bellek miktarı 50 mebibayttan az olduğu sürece 2 adet 20 mib'lik konteynere, beş adet 100 mib'lik konteynere veya tek bir 100 mib'lik konteynere sahip olabilirsiniz.
Limits.cpu, ad alanındaki tüm kapsayıcıların kullanabileceği maksimum birleşik CPU gücü miktarıdır. Bunu işlemci güç isteklerinin sınırı olarak düşünebiliriz.
Son olarak, limits.memory, ad alanındaki tüm kapsayıcıların kullanabileceği maksimum paylaşılan bellek miktarıdır. Bu, toplam bellek isteklerinin sınırıdır.
Yani bir Kubernetes kümesindeki kapsayıcılar varsayılan olarak sınırsız işlem kaynaklarıyla çalışır. Kaynak kotaları ile küme yöneticileri, ad alanına dayalı olarak kaynak tüketimini ve kaynak oluşturulmasını sınırlayabilir. Bir ad alanında, bir bölme veya kapsayıcı, ad alanı kaynak kotası tarafından belirlenen miktarda CPU gücü ve bellek tüketebilir. Bununla birlikte, bir bölmenin veya konteynerin mevcut tüm kaynakları tekeline alabileceği endişesi vardır. Bu durumu önlemek için, ad alanındaki kaynakların (pod'lar veya kapsayıcılar için) tahsisini sınırlamaya yönelik bir politika olan bir sınır aralığı kullanılır.
Limit aralığı aşağıdakileri gerçekleştirebilecek kısıtlamalar sağlar:
- Ad alanındaki her modül veya kapsayıcı için bilgi işlem kaynaklarının minimum ve maksimum kullanımını sağlayın;
- ad alanındaki her PersistentVolumeClaim için minimum ve maksimum Starage İsteği depolama isteklerini zorunlu kılın;
- ad alanındaki bir kaynak için İstek ile Sınır arasında bir ilişki uygulamak;
- Ad alanındaki işlem kaynakları için varsayılan İstekleri/Sınırları ayarlayın ve bunları çalışma zamanında kapsayıcılara otomatik olarak ekleyin.
Bu şekilde ad alanınızda bir sınır aralığı oluşturabilirsiniz. Ad alanının tamamı için geçerli olan kotanın aksine, Sınır Aralığı bireysel kapsayıcılar için kullanılır. Bu, kullanıcıların ad alanı içinde çok küçük veya tam tersine devasa kapsayıcılar oluşturmasını engelleyebilir. Limit Aralığı şu şekilde görünebilir.
Önceki durumda olduğu gibi burada 4 bölüm ayırt edilebilir. Her birine bakalım.
Varsayılan bölüm, bölmedeki kapsayıcının varsayılan sınırlarını ayarlar. Bu değerleri aşırı aralığa ayarlarsanız bu değerlerin açıkça ayarlanmadığı tüm kapsayıcılar varsayılan değerleri izleyecektir.
Varsayılan istek bölümü defaultRequest, bölmedeki kapsayıcı için varsayılan istekleri yapılandırır. Yine, bu değerleri aşırı aralığa ayarlarsanız, bu seçenekleri açıkça ayarlamayan tüm kapsayıcılar varsayılan olarak bu değerleri kullanacaktır.
Maksimum bölümü, bölmedeki bir kapsayıcı için ayarlanabilecek maksimum sınırları belirtir. Varsayılan kısımdaki değerler ve konteyner limitleri bu limitin üzerine ayarlanamaz. Değer maksimum olarak ayarlandıysa ve varsayılan bölüm yoksa maksimum değerin varsayılan değer haline geleceğini unutmamak önemlidir.
Minimum bölüm, bir bölmedeki kapsayıcı için ayarlanabilecek minimum istekleri belirtir. Ancak varsayılan kısımdaki değerler ve konteyner için yapılan sorgular bu sınırın altına ayarlanamaz.
Bir kez daha, eğer bu değer ayarlanırsa, varsayılan ayar değilse minimum değerin varsayılan bilgi istemi haline geleceğini unutmamak önemlidir.
Bu kaynak istekleri sonuçta Kubernetes planlayıcısı tarafından iş yüklerinizi yürütmek için kullanılır. Kapsayıcılarınızı doğru şekilde yapılandırmanız için nasıl çalıştığını anlamanız çok önemlidir. Kümenizde birden fazla kapsül çalıştırmak istediğinizi varsayalım. Pod spesifikasyonlarının geçerli olduğu varsayıldığında Kubernetes programı, iş yükünü çalıştıracak bir düğüm seçmek için sıralı deneme dengelemeyi kullanacaktır.
Kubernetes, Düğüm 1'in pod kapsayıcılarından gelen istekleri yerine getirmek için yeterli kaynağa sahip olup olmadığını kontrol edecek ve yoksa bir sonraki düğüme geçecektir. Sistemdeki düğümlerden hiçbiri istekleri karşılayamıyorsa bölmeler Beklemede durumuna geçecektir. GKE, otomatik düğüm ölçeklendirme gibi Google Kubernetes motor özelliklerini kullanarak bekleme durumunu otomatik olarak algılayabilir ve birkaç ek düğüm daha oluşturabilir.
Daha sonra düğüm kapasiteniz biterse, otomatik ölçeklendirme, paradan tasarruf etmenizi sağlamak için düğüm sayısını azaltacaktır. Kubernetes'in pod'ları isteklere göre planlamasının nedeni budur. Ancak sınır isteklerden daha yüksek olabilir ve bazı durumlarda düğümün kaynakları tükenebilir. Bu duruma aşırı bağlılık durumu diyoruz.
Dediğim gibi iş CPU'ya gelince Kubernetes pod'ları sınırlamaya başlayacak. Her kapsül istediği kadar alacak, ancak sınıra ulaşmazsa kısıtlama uygulanmaya başlayacak.
Bellek kaynakları söz konusu olduğunda Kubernetes, siz sistem kaynaklarını serbest bırakana kadar hangi bölmelerin silineceği ve hangilerinin tutulacağı konusunda kararlar vermek zorunda kalır, aksi takdirde tüm sistem çöker.
Makinenizin belleğinin tükendiği bir senaryo hayal edelim; Kubernetes bunu nasıl halleder?
Kubernetes, talep ettiklerinden daha fazla kaynak kullanan pod'ları arayacaktır. Dolayısıyla, konteynerlerinizde hiç İstek yoksa, bu onların varsayılan olarak istediklerinden daha fazlasını kullanmaya başladıkları anlamına gelir, çünkü hiçbir şey istemediler! Bu tür konteynerler kapatılmanın başlıca adayları haline geliyor. Bir sonraki adaylar, tüm isteklerini karşılayan ancak hala maksimum limitin altında olan konteynerlerdir.
Dolayısıyla Kubernetes, istek parametrelerini aşan birkaç bölme bulursa bunları önceliğe göre sıralayacak ve ardından en düşük öncelikli bölmeleri kaldıracaktır. Tüm pod'lar aynı önceliğe sahipse Kubernetes, isteklerini aşan pod'ları diğer pod'lardan daha fazla sonlandıracaktır.
Çok nadir durumlarda Kubernetes, hâlâ istekleri kapsamında olan pod'ları iptal edebilir. Kubelet aracısı veya Docker gibi kritik sistem bileşenleri, kendilerine ayrılandan daha fazla kaynak tüketmeye başladığında bu durum meydana gelebilir.
Dolayısıyla, küçük şirketlerin ilk aşamalarında bir Kubernetes kümesi, kaynak talepleri ve kısıtlamaları belirlemeden iyi çalışabilir, ancak ekipleriniz ve projeleriniz boyut olarak büyümeye başladıkça bu alanda sorunlarla karşılaşma riskiyle karşı karşıya kalırsınız. Modüllerinize ve ad alanlarınıza sorgular ve kısıtlamalar eklemek çok az ekstra çaba gerektirir ve birçok zahmetten kurtarabilir.
Bazı reklamlar 🙂
Bizimle kaldığın için teşekkürler. Yazılarımızı beğeniyor musunuz? Daha ilginç içerik görmek ister misiniz? Sipariş vererek veya arkadaşlarınıza tavsiye ederek bize destek olun, , sizin için bizim tarafımızdan icat edilen benzersiz bir giriş seviyesi sunucu analoğu: (RAID1 ve RAID10, 24 adede kadar çekirdek ve 40 GB'a kadar DDR4 ile mevcuttur).
Amsterdam'daki Equinix Tier IV veri merkezinde Dell R730xd 2 kat daha mı ucuz? Sadece burada Hollanda'da! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99$'dan! Hakkında oku
Kaynak: habr.com