Bu gece Kubernetes'in bir sonraki sürümü - . Blogumuz için gelişen geleneğe uygun olarak, bu harika Açık Kaynak ürününün yeni sürümündeki önemli değişikliklerden bahsediyoruz.
Bu materyali hazırlamak için kullanılan bilgiler şuradan alınmıştır: , ve ilgili sorunlar, çekme istekleri, Kubernetes Geliştirme Teklifleri (KEP).
SIG kümesi yaşam döngüsünden önemli bir girişle başlayalım: dinamik yük devretme kümeleri Kubernetes (veya daha doğrusu, kendi kendine barındırılan HA dağıtımları) artık tanıdık komutların kullanılması (tek düğümlü kümeler bağlamında) kubeadm (init и join). Kısaca bunun için:
- küme tarafından kullanılan sertifikalar gizli dizilere aktarılır;
- Etcd kümesini K8s kümesi içinde kullanma olasılığı için (yani önceden var olan dış bağımlılıktan kurtulmak için) ;
- Hataya dayanıklı bir yapılandırma sağlayan harici yük dengeleyici için önerilen ayarları belgeler (gelecekte bu bağımlılığın ortadan kaldırılması planlanmaktadır, ancak bu aşamada değil).
Kubeadm ile oluşturulan Kubernetes HA kümesinin mimarisi
Uygulamanın detaylarına şuradan ulaşabilirsiniz. . Bu özellik gerçekten uzun zamandır beklenen bir özellikti: K8s 1.9'da alfa sürümü bekleniyordu ancak şimdi ortaya çıktı.
API
Ekip apply ve herkes bildirimsel nesne yönetimi arasında kubectl apserver'da. Geliştiricilerin kendileri kararlarını kısaca şöyle açıklıyorlar: kubectl apply - Kubernetes'teki yapılandırmalarla çalışmanın temel bir parçasıdır, ancak "hatalarla doludur ve düzeltilmesi zordur" ve bu nedenle bu işlevselliğin normale döndürülmesi ve kontrol düzlemine aktarılması gerekir. Bugün var olan sorunların basit ve net örnekleri:
Uygulamaya ilişkin ayrıntılar haberimizde . Şu anki hazırlık durumu alfa aşamasındadır (bir sonraki Kubernetes sürümü için beta sürümüne yükseltme planlanmaktadır).
Alfa sürümünde kullanıma sunuldu OpenAPI v3 şemasını kullanarak CustomResources için OpenAPI belgeleri oluşturma ve yayınlama (CR) K8'in kullanıcı tanımlı kaynaklarını (CustomResourceDefinition, CRD) doğrulamak için kullanılır (sunucu tarafı). CRD için OpenAPI'yi yayınlamak istemcilere (ör. kubectl) doğrulamayı kendi tarafınızda gerçekleştirin (içinde kubectl create и kubectl apply) ve şemaya göre belgeleri yayınlayın (kubectl explain). Ayrıntılar - içinde .
Önceden var olan günlükler bayraklı O_APPEND (yerine O_TRUNC) bazı durumlarda günlük kaybını önlemek ve günlükleri döndürme için harici yardımcı programlarla kesmenin rahatlığı için.
Ayrıca Kubernetes API bağlamında şunu söyleyebiliriz: PodSandbox и PodSandboxStatus alan runtime_handler hakkındaki bilgileri kaydetmek için RuntimeClass bölmede (bunun hakkında daha fazla bilgiyi metinde okuyun) , bu sınıfın alfa sürümü olarak göründüğü yer) ve Giriş Web Kancalarında hangi versiyonların olduğunu belirleme yeteneği AdmissionReview destekliyorlar. Son olarak, Giriş Web Kancaları kuralları artık ad alanları ve küme çerçeveleri tarafından kullanımlarının kapsamı.
Kasalar
, piyasaya sürülmesinden bu yana beta statüsünde olan , kararlı (GA): bu özellik kapısı artık devre dışı değildir ve Kubernetes 1.17'de kaldırılacaktır.
adı verilen ortam değişkenlerini kullanarak (örneğin, bölme adı) olarak monte edilen dizinlerin adları için , yeni bir alan biçiminde geliştirildi subPathExpr, artık istenen dizin adını belirlemek için kullanılıyor. Bu özellik ilk olarak Kubernetes 1.11'de göründü ancak 1.14 için alfa sürüm durumunda kaldı.
Önceki Kubernetes sürümünde olduğu gibi, aktif olarak gelişen CSI (Konteyner Depolama Arayüzü) için birçok önemli değişiklik getirildi:
CSI
Kullanılabilir hale geldi (alfa sürümünün bir parçası olarak) CSI ciltleri için yeniden boyutlandırma. Bunu kullanmak için adı verilen özellik kapısını etkinleştirmeniz gerekir. ExpandCSIVolumesve ayrıca belirli bir CSI sürücüsünde bu işlem için desteğin mevcut olması.
Alfa sürümündeki CSI için başka bir özellik - Pod spesifikasyonu içindeki CSI birimlerine doğrudan (yani PV/PVC kullanmadan) başvurun. Bu CSI'nin yalnızca uzaktan veri depolama olarak kullanılmasına ilişkin kısıtlamayı kaldırıronlara dünyanın kapılarını açıyor . Kullanmak için () etkinleştirilmelidir CSIInlineVolume özellik kapısı.
Kubernetes'in CSI ile ilgili "dahili kısımlarında" da, son kullanıcılar (sistem yöneticileri) tarafından pek görülemeyen ilerlemeler kaydedildi ... Şu anda geliştiriciler, her depolama eklentisinin iki sürümünü desteklemek zorunda kalıyor: biri - "içinde" eski yol”, K8s kod tabanının içinde (-ağaçta) ve ikincisi - yeni CSI'nin bir parçası olarak (bununla ilgili daha fazlasını okuyun, örneğin, ). Bu, CSI'nin kendisi istikrara kavuştukça ele alınması gereken anlaşılır rahatsızlıklara neden olur. Dahili (ağaç içi) eklentilerin API'sini basitçe kullanımdan kaldırmak mümkün değildir. .
Bütün bunlar alfa versiyonunun ulaşması gerçeğine yol açtı dahili eklenti koduCSI eklentilerinde ağaç içi olarak uygulanan, geliştiricilerin endişelerinin eklentilerinin bir sürümünü desteklemeye indirgenmesi sayesinde eski API'lerle uyumluluk kalacak ve olağan senaryoda eski olarak ilan edilebilecekler. Kubernetes'in (1.15) bir sonraki sürümüyle birlikte tüm bulut sağlayıcı eklentilerinin taşınması, uygulamanın beta statüsü alması ve K8 kurulumlarında varsayılan olarak etkinleştirilmesi bekleniyor. Ayrıntılar için bkz. . Bu göç aynı zamanda belirli bulut sağlayıcıları (AWS, Azure, GCE, Cinder) tarafından tanımlanan hacim sınırlarından.
Ek olarak, CSI (CSIBlockVolume) beta sürümüne.
Düğümler/Kubelet
Alfa sürümü sunuldu için tasarlanan Kubelet'te Temel kaynaklara ilişkin metrikleri döndürün. Genel olarak konuşursak, Kubelet daha önce cAdvisor'dan konteyner kullanımına ilişkin istatistikler alıyordu, artık bu veriler CRI (Konteyner Çalışma Zamanı Arayüzü) aracılığıyla konteyner çalışma zamanı ortamından geliyor, ancak Docker'ın eski sürümleriyle çalışmaya yönelik uyumluluk da korunuyor. Daha önce Kubelet'te toplanan istatistikler REST API aracılığıyla gönderiliyordu ancak artık Kubelet'te bulunan bir uç nokta /metrics/resource/v1alpha1. Geliştiricilerin uzun vadeli stratejisi Kubelet tarafından sağlanan ölçüm kümesini en aza indirmektir. Bu arada, bu ölçümlerin kendileri “temel metrikler” değil, “kaynak metrikleri”dir ve “işlemci ve bellek gibi birinci sınıf kaynaklar” olarak tanımlanır.
Çok ilginç bir nüans: Prometheus formatını kullanmanın çeşitli durumlarıyla karşılaştırıldığında gRPC uç noktasının açık performans avantajına rağmen (aşağıdaki kıyaslamalardan birinin sonucuna bakın), yazarlar bu izleme sisteminin topluluktaki açık liderliği nedeniyle Prometheus'un metin formatını tercih ettiler.
“gRPC büyük izleme ardışık düzenleriyle uyumlu değil. Uç nokta yalnızca metrikleri Metrics Server'a iletmek veya onunla doğrudan entegre olan bileşenleri izlemek için yararlı olacaktır. Metrics Server'da önbelleğe alma kullanılırken Prometheus metin formatı performansı yeterince iyi Prometheus'un toplumda yaygın olarak benimsenmesi göz önüne alındığında, Prometheus'u gRPC'ye tercih etmemiz. OpenMetrics formatı daha kararlı hale geldiğinde, gRPC performansına protokol tabanlı bir formatla yaklaşabileceğiz."
Ölçümler için yeni Kubelet uç noktasında gRPC ve Prometheus formatlarının kullanımına ilişkin karşılaştırmalı performans testlerinden biri. Daha fazla grafik ve diğer ayrıntıları şu adreste bulabilirsiniz: .
Diğer değişikliklerin yanı sıra:
- Kubelet şimdi (bir kez) İşlemleri yeniden başlatmadan ve silmeden önce kapsayıcılar bilinmeyen bir durumda.
- Kullanırken şimdi başlatma kabına normal bir konteynerle aynı bilgiler.
- kubelet
usageNanoCoresCRI istatistik sağlayıcısından ve Windows'taki düğümler ve kapsayıcılar için ağ istatistikleri. - İşletim sistemi ve mimari bilgileri artık etiketlere kaydediliyor
kubernetes.io/osиkubernetes.io/archDüğüm nesneleri (betadan GA'ya aktarılır). - Bir bölmedeki kapsayıcılar için belirli bir sistem kullanıcı grubu belirtme yeteneği (
RunAsGroup, ortaya çıkan ) betadan önce (varsayılan olarak etkindir). - cAdvisor'da kullanılan du ve find, Go uygulamasında.
CLI
Cli-runtime ve kubectl'de -k ile entegrasyon için bayrak (bu arada, geliştirilmesi artık ayrı bir depoda gerçekleştiriliyor), yani. özel özelleştirme dizinlerinden ek YAML dosyalarını işlemek için (bunların kullanımına ilişkin ayrıntılar için bkz. ):
Basit dosya kullanımına örnek (özelleştirmenin daha karmaşık bir uygulaması mümkündür )
Buna ek olarak:
- yeni takım
kubectl create cronjob, adı kendisi için konuşan. - В
kubectl logsşimdi yapabilir флаги-f(--followgünlük akışı için) ve-l(--selectoretiket sorgusu için). - Kubectl joker karakterle seçilen dosyaları kopyalayın.
- Takıma
kubectl waitbayrak--allBelirtilen kaynak türünün ad alanındaki tüm kaynakları seçmek için.
Diğerleri
Aşağıdaki yetenekler kararlı (GA) durumu almıştır:
- , bölmenin hazır olmasında dikkate alınan ek koşulları tanımlamak için bölme spesifikasyonunda kullanılır;
- Büyük sayfalar için destek (özellik kapısı adı verilir) );
- ;
- PriorityClass API'si .
Kubernetes 1.14'te sunulan diğer değişiklikler:
- Varsayılan RBAC politikası artık API erişimine izin vermiyor
discoveryиaccess-reviewkimlik doğrulaması olmayan kullanıcılar (kimliği doğrulanmamış). - Resmi CoreDNS desteği Yalnızca Linux, dolayısıyla bir kümede dağıtmak için kubeadm (CoreDNS) kullanıldığında, düğümlerin yalnızca Linux üzerinde çalışması gerekir (bu sınırlama için nodeSelectors kullanılır).
- Varsayılan CoreDNS yapılandırması artık vekil yerine. Ayrıca CoreDNS'de Uygun (servis için hazır olmayan) bölmelerde yük dengelemeyi önleyen hazırlık Probu.
- Kubeadm'de, aşamalarda
initveyaupload-certs, yeni kontrol düzlemini kubeadm-certs sırrına bağlamak için gereken sertifikaları yükleyin (bayrağı kullanın)--experimental-upload-certs). - Windows kurulumları için bir alfa sürümü ortaya çıktı gMSA (Grup Yönetilen Hizmet Hesabı) - Active Directory'de kapsayıcılar tarafından da kullanılabilen özel hesaplar.
- G.C.E. için Etcd ve kube-apserver arasında mTLS şifrelemesi.
- Kullanılan/bağımlı yazılımdaki güncellemeler: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, kubeadm'de Docker 18.09 desteği ve desteklenen minimum Docker API sürümü artık 1.26'dır.
PS
Blogumuzda da okuyun:
- «";
- «";
- «";
- «'.
Kaynak: habr.com