Gelişmiş planlama tekniklerini uygulamak için Kubernetes kullanın
Kubernetes gibi gelişmiş kapsayıcı düzenleme araçlarını kullanmanın avantajlarından biri, zamanlayıcısının çok esnek olmasıdır. Bu, kullanıcılara, yalnızca düğümlerin mevcut kaynaklarına göre değil, koşulları karşılayan belirli iş istasyonu düğümlerine Bölmelerin tahsis edildiği ortamı belirtmek için kullanılabilen çok çeşitli seçenekler sağlar. Kubernetes'in bölmeleri doğru ana bilgisayara nasıl yerleştirmeye karar verdiğini açıklamak için Kubernetes ana makinesinin ve bazı bileşenlerin basitleştirilmiş bir şemasına bakabiliriz:
Ana API (kube-apiserver), küme gereksinimlerinin ve mevcut durumun okunmasını / yazılmasını sağlayan bir araçtır. Planlayıcı gibi bileşenler, mevcut durum bilgilerini almak, bazı mantık ve hesaplamaları uygulamak ve API'yi istenen durum hakkında yeni bilgilerle güncellemek için ana API'yi kullanabilir (örneğin, yeni bir bölmeye hangi düğümün programlanacağını veya hangi bölmenin gerektiğini belirtmesi Başka bir düğüme geçin). Ek olarak, küme kullanıcıları ve yöneticileri, API'leri harici olarak sağlayan Kubernetes panosu aracılığıyla küme durumunu güncelleyebilir veya görüntüleyebilir. CI / CD ardışık düzeni, API'yi yeni kaynaklar oluşturmak veya mevcut kaynakları değiştirmek için de kullanabilir.
API'yi çağıran diğer ana rol, işçi düğümünde kabın (genellikle Docker) çalışma durumunu yöneten "kubelets" adlı aracı düğümdür. Kubelet, raporlanacak ana bilgisayarın beklenen durumu ile gerçek durumu arasında bir fark olduğunu belirlediğinde, ana API tarafından açıklanan hedef duruma ulaşmak için gerekli kapsayıcıyı başlatır veya sonlandırır. Kubelet'ler genellikle API'leri sorgular veya değişikliklerini gözlemler; bu nedenle Kubernetes, güncellemelere ve değişikliklere neredeyse anında yanıt verir. (Birkaç saniye).
Gördüğümüz gibi Kubernetes, küme durumunu korumak ve güncellemek için denetleyici modunu kullanır ve planlayıcı denetleyici yalnızca bölme planlama kararlarından sorumludur. Planlayıcı, planlanmamış bölmeleri keşfetmek için sürekli olarak Kubernetes API'sini izler ve bu tür bölmeler bulunduğunda, bölmenin hangi düğümün planlanması / yerleştirilmesi gerektiğine karar verir.
Yeni bir kapsül başlatmak için üç aşama vardır:
-
Düğüm filtreleme
-
Düğüm önceliği hesaplaması
-
Gerçek planlama işlemi
İlk aşamada, programlayıcı bu iş yüküyle hangi düğümlerin uyumlu olduğunu kontrol edecektir. Bu uyumsuz düğümleri kaldırmak için bir dizi filtre kullanır. Aşağıdaki filtreleri kullanacaktır:
Hacim filtresi
Bu kontroller sayesinde programlayıcı, hangi düğümlerin bölmeleri çalıştıramayacağını önceden bilir, bu nedenle bu düğümleri hedef listeden kaldırır. Örneğin, düğümle aynı kullanılabilirlik bölgesindeki bölmenin gerektirdiği veri hacmi mi? Bağlanabilir mi ve temeldeki bulut hizmeti sağlayıcısının kurallarıyla çelişmez mi? (Örneğin, AWS'de bir erişilebilirlik bölgesinden başka bir bölgedeki düğümlere EBS birimleri eklemek imkansızdır). Ek olarak, hacim tarafından tanımlanan topoloji kısıtlamalarını karşılamanız gerekir (bölmenin talep ettiği hacim, yalnızca belirli bir düğüm kümesine eklenmesine izin veren veya diğer düğümlere eklenmesini özellikle yasaklayan bir "düğüm yakınlığı" kısıtlamasına sahip olabilir).
İşte kaynak filtresi:
Bu filtreler çok basit. Programlayıcı, bölmenin talep ettiği kaynağın kullanılabilir olup olmadığını kontrol edecek, düğüm üzerinde yetersiz bellek veya yetersiz disk alanı gibi herhangi bir baskı olmadığından emin olacak ve istenen bağlantı noktasının düğümde açılıp açılamayacağını onaylayacaktır. Örneğin, bir bölme 8080 numaralı bağlantı noktasına bağlanması gerektiğini belirtirse, ancak benzer gereksinimleri olan başka bir bölme bağlantı noktasını işgal etmişse, düğüm hedeften kaldırılacaktır.
Son filtre grubu, ilişkili seçicilerdir:
Bu örnekte, programlayıcının, bölmenin belirli bir düğümde çalışması gerektiğini açıkça belirtip belirtmediğini veya kapsül yakınlığını belirtip belirtmediğini doğruladığını görebilirsiniz (yalnızca başka bölmeler mevcut olduğunda çalışması veya belirli bir düğümle aynı düğümde olmaktan kaçınması gerekiyorsa) Ek olarak, bu filtre, bölmenin, özel_gpu / bakım / aşamalandırma_only (veya kullanıcı tanımlı koşullar) veya bellek basıncı / ulaşılamaz / disk basıncı (sistem örneği uygulama pigmenti) gibi düğümün bazı kötü koşullarını tolere edip edemeyeceğini de kontrol edecektir. ). Tolerans, tolerans tanımında belirtilir ve kabın bu koşullara sahip düğümler üzerinde programlanmasına izin verir. Başka bir deyişle, çalıştırılmasına açıkça izin verilen bölmeler dışında, diğer tüm bölmelerin düğümde zamanlaması veya yürütülmesi reddedilecektir. Bunlar, Kubernetes'in zamanlama davranışını ayarlamak için önemli mekanizmalardır.
Bu filtreleme adımlarını tamamladıktan sonra, bu Kapsül için kullanılabilir düğüm olmayabilir. Bu durumda, bölme düzensiz kalır ve bölmeyi çalıştırmadaki başarısızlığın nedeni de dahil olmak üzere kontrol paneline yansıtılır (örneğin, "bu bölme kısıtlamalarını karşılayabilecek bir düğüm bulunamıyor" veya "bölmeyi programlamak için yeterli bellek yok" ). Filtreyi geçerse ve birkaç düğüm seçmenize izin verirse, programlayıcı aşağıdaki parametrelere göre öncelik kontrollerini çalıştırır:
Bu kontrol tamamlandıktan sonra, programlayıcı her bir düğümün puanını hesaplayacak ve en yüksek puanlı düğüm kabı çalıştıracaktır.
Aşağıda, temel kaynak gereksinimlerinden özel zamanlayıcı denetleyicileri kullanmaya kadar gelişmiş yöntemlerin karmaşıklığına göre sıralanmış, bölme tanımlaması sırasında kapsül yerleşimini denetlemeye yönelik yöntemlerin bir listesi verilmiştir:
Planlayıcının doğru kararlar vermesine yardımcı olmanın ilk temel yolu, bellek / CPU isteklerini ve limitlerini belirlemektir. İstekler, planlama aşamasında kullanılır ve zaten çalışmakta olan bölmelerde kısıtlamalar kullanılır.
Aşağıdaki temel kurallara göre birim uyumluluğu sorunlarını önleyebiliriz:
-
İstenen birimin gerekli düğüm ile aynı kullanılabilirlik bölgesinde olduğundan emin olun. Örneğin, bölmenin "A" alanında bir grup düğüm çalıştırmak istediğinizde ve bölmenin "B" alanında bir birim kullanmanız gerektiğinde, lütfen bu birimleri doğru alana veya özel bir birimde klonladığınızdan emin olun. Bölgedeki birkaç yeni düğümü, bu düğümlere bağlanabilmesi için döndürün.
-
Düğümün kapasite sınırına ulaşmadığından emin olun (örneğin, Azure bulutunda, kaç birimin bağlanabileceği konusunda bir sınır vardır).
-
Zaten ayrı bir düğüme bağlı olan bir birimi belirtmeyin. Bir konteyner birkaç birim gerektiriyorsa, ancak bu kapasiteler başka bir ana bilgisayara bağlanmak üzere ayarlanmışsa, bu koşul karşılanamayacağı için konteyner çalışamayacaktır.
-
Birimin bağlanabileceği veya bağlanamayacağı düğümlerin bir listesini belirterek hacim topolojisi kısıtlamalarını kullanın.
Ek olarak, pod tanımında belirtilmesi gereken birkaç kısıtlama seçeneğimiz var:
-
Bu bölmenin doğrudan çalışması gereken nodeName öğesini ayarlayın.
-
Düğümün bölmeyi çalıştırabilmesi için sahip olması gereken etiketi belirtmek için nodeSelector'ı kullanın.
-
Bozukluklar (düğümde) ve tolerans (Bölmede) - Yukarıda belirtildiği gibi, Bozukluklar düğümün durumunun bir göstergesidir; bu tür bir leke için "tolerans" belirtmedikleri sürece, lekeli düğümde hiçbir bölme düzenlenmeyecektir. . Bir düğüm birden fazla bozukluğa sahip olabilir ve bir kap birden çok toleransa sahip olabilir.
Aşağıdaki görüntü, kusur türünü ve örnek tolerans tanımını gösterir:
Bir sonraki kısıtlama mekanizması, kapsül tanımında ayarlanabilen ilişkili tercihtir. Affinity'nin şu anda iki kapsamı var ve hâlâ geliştirme aşamasındadır. Şimdi, aşağıdaki şekilde gösterildiği gibi yalnızca programlama aşaması ilişkilendirmesi kullanılabilir:
"Planlama sırasında tercih edilir" seçeneğini kullandığınızda, Kubernetes kapsülleri bu ayara göre planlamak için elinden geleni yapacaktır. "Programlama sırasında gerekli" seçeneğini kullanırsanız, koşulu zorlar ve koşul karşılanmazsa, bölme düğümde çalışmaz.
Çalıştırmak istediğiniz düğümde bölme tercihlerini belirlemenin birkaç farklı yolu vardır. Pek çok kişinin aşina olduğu basit bir tercih, kabın yalnızca kesin etiket değerlerine sahip düğümlerde programlanmasına neden olan "düğüm seçici" dir (belirli bir etiketi doğrudan belirtin). Düğüm tercihlerini belirlemenin başka bir yolu, aşağıdaki şekilde gösterildiği gibi operatörlerin kullanımına izin veren düğüm ilişkilerini ve "düğüm seçici terimlerini" kullanmaktır. Bu, kullanıcının zamanlamayı planlayacağı veya önleyeceği esnek bir kurallar dizisi belirlemesine olanak tanır.
Düğüm seçicinin katı etiket eşleşmesinden farklı olarak, benzerlik kuralının düğüm seçici teriminde daha esnek bir eşleştirme ifadesi kullanılabilir. Etiket değerini olası değişiklikler listesiyle ("Giriş" operatörü) karşılaştırmak için eşleşme ifadesi operatörünü kullanabilir veya etiket değerinin belirtilen listedeki değerlerden biri ("NotIn") olup olmadığını kontrol edebilirsiniz. Ayrıca, değerine bakılmaksızın etiketin düğümde var olup olmadığını da belirleyebilirler. Son olarak, etiketin değerini "Gt" (büyüktür) ve "Lt" (küçüktür) operatörleriyle karşılaştırabilirler. Aşağıda, düğüm benzeşimi kurallarının başka bir örneği verilmiştir:
Gördüğünüz gibi, bu kurallar kümesi, düğümlerin "kubernetes.io/e2e-az-name" etiketinin değerini "e2e-az1" veya "e2e-az2" olarak belirtmek için kullanılmasını gerektirir. Kural ayrıca, "başka-düğüm-etiket-değeri" değerine sahip "başka-düğüm-etiket-anahtarı" özel etiketli düğümlerin tercihli seçimini de içerir; bu, iki kısıtlamayı karşılayan bir düğüm varsa çalışacağı anlamına gelir Bölme.
Düğüm ilişkilendirme ayarlarına ek olarak, aşağıdaki gibi tanımlanan bölmeler arası ilişkilendirme ve ilişkilendirme önleme ayarları da vardır:
Bu kuralları kullanarak, bölmelerin yan yana konumlarını kontrol edebilirsiniz. Bazı bölmelerin diğer bölme türleriyle birlikte yerleştirilmesi kabul edilebilirken, diğer bölmelerin belirli bölme türleriyle aynı makineye yerleştirilmesinden kaçınması gerekebilir (örneğin, Kubernetes'in aynı düğümde çalışmayı planlamasına neden olacak CPU yoğun bölmeler) Yük çok yüksektir, bu da performansın düşmesine neden olur).
Aşağıda, kapsül ilişkilendirme kurallarına bir örnek verilmiştir:
-
Kapsül "A" yı burada programlamak için, "B" bölmesinin düğümde çalışıyor olması gerekir.
-
"B" bölmesini çalıştıran düğüm tercih edilir, aksi takdirde herhangi bir düğüm üzerinde olabilir.
Ve bu örnek, kapsül ilişkilendirme önleme kuralını gösterir:
-
"B" bölmesi bu düğümde çalışıyorsa, lütfen düzenleme yapmayın
-
Kapsül "B" nin çalışmadığı düğüm tercih edilir, aksi takdirde herhangi bir düğüm üzerinde çalışabilir.
Aşağıda, bir etiket seçici olan ve label anahtar sözcüğünü "birlikte konum göstergesi" olarak tanımlayan topologyKey'in tanıtılmasına bir örnek verilmiştir. Bölmeleri tüm kümede eşit olarak dağıtmak için, zamanlayıcı, bu düğümler üzerinde farklı topologyKey etiket değerlerine sahip düğümleri seçmeye çalışacaktır. "Bölmeleri birbirine olabildiğince yakın istiflemek" için (bu programlama tercihi de mevcuttur ve bir sonraki adımda açıklanmaktadır), bu kez tercihen aynı etiket değerine sahip düğümleri seçerek topologyKey etiketine dayalı bir yargıya varabilir.
Açıklanan yöntemlere ek olarak, farklı zamanlama algoritmalarını ayarlamak için "kube-scheduler" bileşenine (Kubernetes çalıştıran ana bileşenlerden biridir) iletilen bayrakların kullanılması gibi, Kubernetes planlayıcısının davranışını değiştirmenin başka yolları da vardır. "-Algorithm-provider" bayrağı için mevcut iki seçenek şunlardır: "DefaultProvider" ve "ClusterAutoscalerProvider". "DefaultProvider", tüm düğümlerin yükünü dengelemek için kümedeki kapsayıcıları ayırmaya çalışır. Ve "ClusterAutoscalerProvider", daha iyi kaynak kullanımı elde etmek için her bir düğümdeki çoğu bölmeyi önlemeye çalışacaktır (genellikle temel çalışan düğümler CPU ve bellek gibi tüketim kaynaklarına göre otomatik olarak ölçeklendiğinde kullanılır).
Algoritmada değişiklikler sağlamaya ek olarak, kendi planlama "mantığınızı" sağlamak için ConfigMap veya dosyada tanımlanan stratejiyi de kullanabilirsiniz:
Bu, özel politikaları planlayıcıya aktarmanıza olanak tanır ve yalnızca GitHub'da (resmi Kubernetes belgelerinde bile değil) belgelenen çok gelişmiş bir özelliktir. Bununla birlikte, bir Kubernetes "hacker" olmak istiyorsanız, GitHub'daki bağlantılı sayfada daha fazla bilgi bulabilir ve burada örnek bir politika dosyası okuyabilirsiniz. Stratejinin her kullanılabilir parametresi, algoritmanın akışını ve Kapsüllerin nereye yerleştirileceğine ilişkin kuralları belirler. Bu belgede açıklanmıştır. Politikanızı dosyaya koymak için "-use-legacy-policy-config = true" + "-policy-config-file" seçeneğini belirtin. Aksi takdirde, hedef yapılandırma eşlemesini strateji olarak belirtmek için yapılandırma eşlemesini ve yapılandırma eşleme ad alanı bayraklarını kullanın.
Zamanlamayı özelleştirmenin başka bir yolu, belirli bir bölme veya küme için kendi zamanlayıcınızı kullanmaktır.Herhangi bir dilde bir zamanlayıcı yazabilirsiniz. Tek yapmanız gereken, API'yi aşağıdaki gibi kullanmaktır:
Yukarıdaki örnekte, özel planlayıcının, belirtilen API aracılığıyla düğümü ve kapsülü elde etmesi ve ardından "aşama = Beklemede" ve "schedulerName = your-scheduler-name" ile bölmeyi seçmesi gerekir. Her bir bölmenin nereye yerleştirilmesi gerektiğini hesapladıktan sonra, zamanlayıcı bir Binding nesnesi oluşturacaktır (en uygun hedef düğümü hesaplamak için kullanılır; yorumlar, etiketler, Docker görüntüleri gibi bölme tanımında ve düğüm tanımında bulunan tüm bilgileri kullanabilirsiniz. Ad, hacim veya gereksinimlerinize göre bölmenin doğru konumunu belirlemeye yardımcı olan herhangi bir bilgi).
Özel bir zamanlayıcıyı daha iyi uygulamak için düğümleri gözlemlemeli ve hesaplamayı hızlandırmak için bilgileri önbelleğe almalısınız. Özel ek mantık ve işlevler için iyi bir başlangıç noktası sağladığından, mevcut zamanlayıcıyı çatallamak iyi bir başlangıç noktasıdır.
