Bugün Çarşamba, Kubernetes'in bir sonraki sürümü - 1.16. Blogumuzda gelişen geleneğe uygun olarak, yeni versiyondaki en önemli değişikliklerden bahsettiğimiz onuncu yıl dönümü zamanıdır.
Bu materyali hazırlamak için kullanılan bilgiler şuradan alınmıştır: , ve ilgili sorunlar, çekme istekleri ve Kubernetes Geliştirme Teklifleri (KEP). O zaman hadi gidelim!..
Düğümler
K8s küme düğümleri (Kubelet) tarafında gerçekten çok sayıda dikkate değer yenilik (alfa sürüm durumunda) sunulmaktadır.
Öncelikle sözde «» (Geçici Konteynerler), bölmelerdeki hata ayıklama işlemlerini basitleştirmek için tasarlanmıştır. Yeni mekanizma, mevcut bölmelerin ad alanında başlayan ve kısa bir süre için geçerli olan özel kapları başlatmanıza olanak tanır. Amaçları, herhangi bir sorunu çözmek ve hata ayıklamak için diğer kapsüller ve konteynerlerle etkileşime girmektir. Bu özellik için yeni bir komut uygulandı kubectl debugözü itibarıyla benzer kubectl exec: yalnızca bir kapta bir işlem çalıştırmak yerine (olduğu gibi) exec) bir bölmedeki bir kabı başlatır. Örneğin, bu komut yeni bir kapsayıcıyı bir bölmeye bağlayacaktır:
kubectl debug -c debug-shell --image=debian target-pod -- bashGeçici kaplarla ilgili ayrıntılar (ve bunların kullanım örnekleri) şurada bulunabilir: . Mevcut uygulama (K8s 1.16'da) bir alfa sürümüdür ve beta sürüme aktarılmasına yönelik kriterler arasında "Geçici Konteynerler API'sinin [Kubernetes]'in en az 2 sürümü için test edilmesi" yer alır.
NB: Bu özellik, özü ve hatta adı itibarıyla halihazırda mevcut bir eklentiye benzemektedir hangimiz hakkında . Geçici kapların ortaya çıkmasıyla ayrı bir harici eklentinin geliştirilmesinin sona ermesi bekleniyor.
Başka bir yenilik - - sağlamak için tasarlandı kapsüller için genel gider maliyetlerini hesaplama mekanizması, kullanılan çalışma zamanına bağlı olarak büyük ölçüde değişebilir. Örnek olarak yazarlar konuk çekirdeğin, kata aracısının, başlatma sisteminin vb. çalıştırılmasını gerektiren Kata Kapları ile sonuçlanır. Genel gider bu kadar büyüdüğünde göz ardı edilemez, bu da daha fazla kota, planlama vb. için bunu hesaba katmanın bir yolu olması gerektiği anlamına gelir. Bunu uygulamak için PodSpec alan eklendi Overhead *ResourceList (verilerle karşılaştırılır) RuntimeClass, eğer biri kullanılıyorsa).
Dikkat çeken bir diğer yenilik ise düğüm topolojisi yöneticisi (Düğüm Topolojisi Yöneticisi)Kubernetes'teki çeşitli bileşenler için donanım kaynaklarının tahsisinde ince ayar yapma yaklaşımını birleştirmek üzere tasarlanmıştır. Bu girişim, yüksek performanslı paralel hesaplama ve gelişmiş CPU ve gelişmiş CPU kullanan operasyonların yürütülmesindeki gecikmelerin en aza indirilmesi için çeşitli modern sistemlere (telekomünikasyon, makine öğrenimi, finansal hizmetler vb. alanından) artan ihtiyaçtan kaynaklanmaktadır. donanım hızlandırma yetenekleri. Kubernetes'teki bu tür optimizasyonlar şimdiye kadar farklı bileşenler (CPU yöneticisi, Cihaz yöneticisi, CNI) sayesinde elde edildi ve şimdi bunlara yaklaşımı birleştiren ve topoloji adı verilen yeni benzerlerin bağlantısını basitleştiren tek bir dahili arayüz eklenecek. farkında - Kubelet tarafındaki bileşenler. Ayrıntılar - içinde .
Topoloji Yöneticisi Bileşen Şeması
Sonraki özellik - Konteynerleri çalışırken kontrol etmek (). Bildiğiniz gibi lansmanı uzun süren konteynerler için güncel durum elde etmek zordur: ya gerçekten çalışmaya başlamadan "öldürülürler" ya da uzun süre çıkmaza girerler. Yeni kontrol (çağrılan özellik kapısı aracılığıyla etkinleştirilir) StartupProbeEnabled) bölmenin çalışması bitene kadar diğer kontrollerin etkisini iptal eder - veya daha doğrusu erteler. Bu nedenle bu özellik orijinal olarak adlandırıldı . Başlaması uzun süren bölmeler için durumu nispeten kısa zaman aralıklarında yoklayabilirsiniz.
Ek olarak, RuntimeClass için "heterojen kümeler" için destek ekleyen bir iyileştirme beta durumunda hemen kullanıma sunuldu. C Artık her düğümün her RuntimeClass için desteğe sahip olması hiç de gerekli değil: bölmeler için küme topolojisini düşünmeden bir RuntimeClass seçebilirsiniz. Daha önce bunu başarmak için (böylece bölmeler, ihtiyaç duydukları her şeyi destekleyen düğümlerde bulunur), NodeSelector'a ve toleranslara uygun kurallar atamak gerekiyordu. İÇİNDE Kullanım örneklerinden ve tabii ki uygulama ayrıntılarından bahsediyor.
ağ
Kubernetes 1.16'da ilk kez (alfa sürümünde) ortaya çıkan iki önemli ağ özelliği şunlardır:
- çift ağ yığını - IPv4/IPv6 - ve bölmeler, düğümler, hizmetler düzeyinde buna karşılık gelen "anlama". Pod'lardan harici hizmetlere kadar pod'lar arasında IPv4'ten IPv4'e ve IPv6'dan IPv6'ya birlikte çalışabilirliği, referans uygulamalarını (Köprü CNI, PTP CNI ve Ana Bilgisayar-Yerel IPAM eklentileri dahilinde) ve ters çalışan Kubernetes kümeleriyle uyumlu Yalnızca IPv4 veya IPv6. Uygulama detayları şurada .
Bölme listesinde iki türdeki (IPv4 ve IPv6) IP adreslerinin görüntülenmesine bir örnek:
kube-master# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE nginx-controller 1/1 Running 0 20m fd00:db8:1::2,192.168.1.3 kube-minion-1 kube-master# - Uç Nokta için Yeni API - . Mevcut Uç Nokta API'sinin kontrol düzlemindeki çeşitli bileşenleri (apserver, vb., uç nokta denetleyicisi, kube-proxy) etkileyen performans/ölçeklenebilirlik sorunlarını çözer. Yeni API, Discovery API grubuna eklenecek ve binlerce düğümden oluşan bir kümede her hizmette on binlerce arka uç noktaya hizmet verebilecek. Bunu yapmak için her Hizmet N nesneyle eşlenir
EndpointSlice, her birinin varsayılan olarak 100'den fazla uç noktası yoktur (değer yapılandırılabilir). EndpointSlice API aynı zamanda gelecekteki gelişimi için de fırsatlar sağlayacaktır: her bir bölme için birden fazla IP adresi desteği, uç noktalar için yeni durumlar (yalnızcaReadyиNotReady), uç noktalar için dinamik alt kümeleme.
Son sürümde sunulan beta sürümüne ulaştı , adlandırılmış service.kubernetes.io/load-balancer-cleanup ve her hizmete türle birlikte eklenir LoadBalancer. Böyle bir hizmetin silinmesi sırasında, ilgili tüm dengeleyici kaynakların "temizlenmesi" tamamlanana kadar kaynağın fiilen silinmesi önlenir.
API Makineleri
Gerçek "stabilizasyon kilometre taşı" Kubernetes API sunucusu ve onunla etkileşim alanındadır. Bu büyük ölçüde sayesinde oldu özel bir tanıtıma ihtiyaç duymayanların istikrarlı statüye aktarılması (CRD)Kubernetes 1.7'nin uzak günlerinden beri beta statüsünde olan (ve bu Haziran 2017!). İlgili özelliklerde de aynı stabilizasyon sağlandı:
- ile
/statusи/scaleÖzel Kaynaklar için; - harici webhook'u temel alan CRD sürümleri;
- (K8s 1.15'te) varsayılan değerler (varsayılan) ve otomatik alan kaldırma (budama) Özel Kaynaklar için;
- sunucu tarafında CRD kaynaklarını doğrulamak için kullanılan OpenAPI belgelerini oluşturmak ve yayınlamak için OpenAPI v3 şemasını kullanma.
Kubernetes yöneticilerinin uzun zamandır aşina olduğu başka bir mekanizma: - ayrıca uzun süre beta durumunda kaldı (K8s 1.9'dan beri) ve artık kararlı olarak ilan edildi.
Diğer iki özellik betaya ulaştı: и .
Ve alfa sürümündeki tek önemli yenilik şuydu: itibaren SelfLink — belirtilen nesneyi temsil eden ve onun parçası olan özel bir URI ObjectMeta и ListMeta (yani Kubernetes'teki herhangi bir nesnenin parçası). Neden bundan vazgeçiyorlar? Basit bir şekilde motivasyon Bu alanın hala var olması için gerçek (ezici) nedenlerin yokluğu. Daha resmi nedenler, performansı optimize etmek (gereksiz bir alanı kaldırarak) ve böyle bir alanı özel bir şekilde işlemek zorunda kalan genel apserver'ın çalışmasını basitleştirmektir (bu, nesneden hemen önce ayarlanan tek alandır) serileştirilmiştir). Gerçek eskime (beta dahilinde) SelfLink Kubernetes sürüm 1.20 ve son sürüm 1.21 ile gerçekleşecek.
Veri depolama
Depolama alanındaki asıl çalışma, daha önceki sürümlerde olduğu gibi bölgede gözlemleniyor . Buradaki ana değişiklikler şunlardı:
- ilk kez (alfa sürümünde) Windows çalışan düğümleri için CSI eklenti desteği: Depolamayla çalışmanın mevcut yöntemi aynı zamanda Kubernetes çekirdeğindeki ağaç içi eklentilerin ve Microsoft'un Powershell tabanlı FlexVolume eklentilerinin yerini alacak;
Windows için Kubernetes'te CSI eklentilerini uygulama şeması - fırsat K8s 1.12'de tanıtılan , beta sürüme dönüştü;
- Benzer bir "promosyon" (alfadan betaya), yerel geçici hacimler oluşturmak için CSI kullanma yeteneği sayesinde elde edildi ().
Kubernetes'in önceki sürümünde kullanıma sunuldu (mevcut PVC'yi kullanarak DataSource yeni PVC oluşturmak için) artık beta statüsünü de aldı.
zamanlayıcı
Planlamada iki önemli değişiklik (her ikisi de alfa):
- - fırsat Yüklerin “adil dağıtımı” için mantıksal uygulama birimleri yerine bölmeleri kullanın (Deployment ve ReplicaSet gibi) ve bu dağıtımın ayarlanması (zor bir gereksinim olarak veya yumuşak bir koşul olarak, yani öncelik olarak). Bu özellik, şu anda seçeneklerle sınırlı olan, planlanan bölmelerin mevcut dağıtım yeteneklerini genişletecek
PodAffinityиPodAntiAffinity, yöneticilere bu konuda daha hassas kontrol sağlar; bu da daha iyi yüksek kullanılabilirlik ve optimize edilmiş kaynak tüketimi anlamına gelir. Ayrıntılar - içinde . - kullanımı BestFit Politikası в Talep Edilen Kapasite Oranı Öncelik İşlevi pod planlama sırasında, bu da izin verecek uygulamak Hem temel kaynaklar (işlemci, bellek) hem de genişletilmiş kaynaklar (GPU gibi) için (“kaplarda paketleme”). Daha fazla ayrıntı için bkz. .
Zamanlama bölmeleri: en uygun politikayı kullanmadan önce (doğrudan varsayılan zamanlayıcı aracılığıyla) ve kullanımıyla birlikte (zamanlayıcı genişletici aracılığıyla)
Buna ek olarak, ana Kubernetes geliştirme ağacının dışında (ağaç dışı) kendi zamanlayıcı eklentilerinizi oluşturma yeteneği.
Diğer değişiklikler
Ayrıca Kubernetes 1.16 sürümünde de belirtilebilir için girişim mevcut metrikler tam sıraylaveya daha doğrusu, buna uygun olarak K8'in enstrümantasyonuna. Büyük ölçüde ilgili olanlara güveniyorlar . Çeşitli nedenlerden dolayı tutarsızlıklar ortaya çıktı (örneğin, bazı ölçümler mevcut talimatlar ortaya çıkmadan önce basitçe oluşturuldu) ve geliştiriciler, her şeyi "Prometheus ekosisteminin geri kalanıyla uyumlu" tek bir standarda getirme zamanının geldiğine karar verdi. Bu girişimin şu anki uygulaması alfa durumundadır ve Kubernetes'in sonraki sürümlerinde aşamalı olarak beta (1.17) ve kararlı (1.18) sürümlere yükseltilecektir.
Ek olarak aşağıdaki değişiklikler de not edilebilir:
- Windows desteği geliştirme с Bu işletim sistemi için Kubeadm yardımcı programları (alfa sürümü),
RunAsUserNameWindows kapsayıcıları için (alfa sürümü), Beta sürüme kadar Grup Yönetilen Hizmet Hesabı (gMSA) desteği, vSphere birimleri için bağlama/ekleme. - API yanıtlarında veri sıkıştırma mekanizması. Daha önce, bu amaçlar için, varsayılan olarak etkinleştirilmesini engelleyen bir dizi kısıtlama getiren bir HTTP filtresi kullanılıyordu. "Şeffaf istek sıkıştırma" artık çalışıyor: istemciler gönderiyor
Accept-Encoding: gzipbaşlıkta, boyutu 128 KB'yi aşarsa GZIP ile sıkıştırılmış bir yanıt alırlar. Go istemcileri sıkıştırmayı otomatik olarak destekler (gerekli başlığı gönderir), böylece trafikte bir azalma olduğunu hemen fark ederler. (Diğer diller için küçük değişiklikler gerekebilir.) - HPA'yı harici ölçümlere dayalı olarak sıfır bölmelerden/sıfır bölmelere ölçeklendirme. Nesnelere/harici ölçümlere göre ölçeklendirirseniz iş yükleri boştayken kaynakları kaydetmek için otomatik olarak 0 kopyaya ölçekleyebilirsiniz. Bu özellik özellikle çalışanların GPU kaynakları talep ettiği ve farklı türdeki boşta çalışanların sayısının mevcut GPU sayısını aştığı durumlarda yararlı olacaktır.
- Yeni müşteri - — nesnelere “genelleştirilmiş” erişim için. Meta verileri (yani alt bölüm) kolayca almak için tasarlanmıştır.
metadata) küme kaynaklarından alabilir ve bunlarla çöp toplama ve kota işlemlerini gerçekleştirebilirsiniz. - Kubernetes'i oluşturun eski (“yerleşik” ağaç içi) bulut sağlayıcıları (alfa sürümü) olmadan.
- kubeadm yardımcı programına deneysel (alfa sürümü) işlemler sırasında özelleştirme yamaları uygulama yeteneği
init,joinиupgrade. Bayrağın nasıl kullanılacağı hakkında daha fazla bilgi edinin--experimental-kustomize, bkz. . - Apserver için yeni uç nokta - , - hazır olup olmadığına ilişkin bilgileri dışa aktarmanıza olanak tanır. API sunucusunun da artık bir bayrağı var
--maximum-startup-sequence-durationyeniden başlatmalarını düzenlemenize olanak tanır. - iki Azure'a yönelik özellikler kararlı olarak bildirildi: destek (Kullanılabilirlik Alanları) ve (RG). Ayrıca Azure şunu ekledi:
- AAD ve ADFS;
-
service.beta.kubernetes.io/azure-pip-nameyük dengeleyicinin genel IP'sini belirtmek için; - ayarları
LoadBalancerNameиLoadBalancerResourceGroup.
- AWS artık Windows'ta EBS için ve EC2 API çağrıları
DescribeInstances. - Kubeadm artık bağımsız CoreDNS sürümünü yükseltirken CoreDNS yapılandırması.
- İkili dosyalar vb. karşılık gelen Docker görüntüsünde Bu görüntüyü kök haklarına ihtiyaç duymadan çalıştırmanıza olanak tanıyan dünya çapında yürütülebilir. Ayrıca, vbd geçiş görüntüsü vbd2 sürüm desteği.
- В temel görüntü olarak dağıtımsız kullanmaya geçildi, performans iyileştirildi, yeni bulut sağlayıcıları eklendi (DigitalOcean, Magnum, Packet).
- Kullanılan/bağımlı yazılımdaki güncellemeler: Go 1.12.9, vb. 3.3.15, CoreDNS 1.6.2.
PS
Blogumuzda da okuyun:
- «";
- «";
- «";
- «'.
Kaynak: habr.com