Kubernetes 1.14: Yangiliklarning diqqatga sazovor joylari

Bu kecha amalga oshiriladi Kubernetesning keyingi nashri - 1.14. Bizning blogimiz uchun ishlab chiqilgan an'anaga ko'ra, biz ushbu ajoyib Open Source mahsulotining yangi versiyasidagi asosiy o'zgarishlar haqida gapiramiz.

Ushbu materialni tayyorlash uchun foydalanilgan ma'lumotlardan olingan Kubernetes yaxshilanishlarini kuzatish jadvallari, CHANGELOG-1.14 va tegishli masalalar, tortish so'rovlari, Kubernetes Enhancement Proposals (KEP).

Keling, SIG klaster-hayot tsiklidan muhim kirish bilan boshlaylik: dinamik nosozlik klasterlari Kubernetes (yoki aniqrog'i, o'z-o'zidan HA o'rnatish) hozir yaratilishi mumkin tanish (bitta tugunli klasterlar kontekstida) buyruqlar yordamida kubeadm (init и join). Qisqasi, buning uchun:

• klaster tomonidan foydalaniladigan sertifikatlar sirlarga o'tkaziladi;
• K8s klasterida etcd klasteridan foydalanish imkoniyati uchun (ya'ni, ilgari mavjud bo'lgan tashqi qaramlikdan xalos bo'lish) etcd-operator;
• Nosozliklarga chidamli konfiguratsiyani ta'minlaydigan tashqi yuk balansi uchun tavsiya etilgan sozlamalarni hujjatlashtiradi (kelajakda bu qaramlikni bartaraf etish rejalashtirilgan, ammo bu bosqichda emas).

kubeadm bilan yaratilgan Kubernetes HA klasterining arxitekturasi

Amalga oshirish tafsilotlari bilan tanishish mumkin dizayn taklifi. Bu xususiyat haqiqatan ham uzoq kutilgan edi: alfa versiyasi K8s 1.9 da kutilgan edi, ammo hozir paydo bo'ldi.

API

komanda apply va umuman deklarativ ob'ektni boshqarish o'tdi dan kubectl apiserverda. Ishlab chiquvchilarning o'zlari shunday deb o'z qarorlarini qisqacha tushuntiradilar kubectl apply - Kubernetes-dagi konfiguratsiyalar bilan ishlashning asosiy qismi, ammo "u xatolarga to'la va uni tuzatish qiyin" va shuning uchun bu funktsiyani normal holatga keltirish va boshqaruv tekisligiga o'tkazish kerak. Bugungi kunda mavjud muammolarning oddiy va aniq misollari:

Amalga oshirish haqida batafsil ma'lumotlar mavjud KO'RING. Hozirgi tayyorgarlik alfa (Kubernetesning keyingi versiyasi uchun beta versiyasiga ko'tarilish rejalashtirilgan).

Alfa versiyada mavjud imkoniyat uchun OpenAPI v3 sxemasidan foydalanish CustomResources uchun OpenAPI hujjatlarini yaratish va nashr etish (CR) (server tomonida) K8s foydalanuvchi tomonidan belgilangan resurslarni (CustomResourceDefinition, CRD) tekshirish uchun ishlatiladi. CRD uchun OpenAPI-ni nashr qilish mijozlarga (masalan, kubectl) tekshirishni o'zingiz tomondan amalga oshiring (ichida kubectl create и kubectl apply) va sxema bo'yicha hujjatlarni berish (kubectl explain). Tafsilotlar - ichida KO'RING.

Oldindan mavjud jurnallar hozir ochilmoqda bayroq bilan O_APPEND (lekin emas O_TRUNC) ba'zi holatlarda jurnallarni yo'qotmaslik va aylanish uchun tashqi yordam dasturlari bilan jurnallarni kesish qulayligi uchun.

Shuningdek, Kubernetes API kontekstida shuni ta'kidlash mumkinki PodSandbox и PodSandboxStatus qo'shildi maydonda runtime_handler haqida ma'lumot yozib olish RuntimeClass podda (bu haqda ko'proq haqida matnda o'qing Kubernetes 1.12 versiyasi, bu sinf alfa versiyasi sifatida paydo bo'lgan) va Qabul vebhuklarida amalga oshirildi qaysi versiyalarni aniqlash qobiliyati AdmissionReview qo‘llab-quvvatlaydilar. Nihoyat, Qabul Webhooks qoidalari endi chegaralanishi mumkin nom maydonlari va klaster ramkalari tomonidan ulardan foydalanish darajasi.

Saqlash

PersistentLocalVolumes, chiqarilgandan beri beta holatiga ega edi K8s 1.10, e'lon qildi barqaror (GA): bu xususiyat eshigi endi o'chirilgan va Kubernetes 1.17 da o'chiriladi.

imkoniyat deb nomlangan muhit o'zgaruvchilari yordamida Pastga API (masalan, pod nomi) sifatida o'rnatilgan kataloglar nomlari uchun subPath, ishlab chiqilgan - yangi soha shaklida subPathExpr, bu endi kerakli katalog nomini aniqlash uchun ishlatiladi. Bu xususiyat dastlab Kubernetes 1.11 da paydo bo'ldi, ammo 1.14 uchun u alfa versiyasi holatida qoldi.

Kubernetesning oldingi versiyasida bo'lgani kabi, faol rivojlanayotgan CSI (Container Storage Interface) uchun ko'plab muhim o'zgarishlar kiritilgan:

CSI

Mavjud bo'ldi (alfa versiyasining bir qismi sifatida) qo'llab-quvvatlash CSI hajmlari uchun o'lchamini o'zgartirish. Uni ishlatish uchun siz chaqirilgan xususiyat eshigini yoqishingiz kerak bo'ladi ExpandCSIVolumes, shuningdek, ma'lum bir CSI drayverida ushbu operatsiyani qo'llab-quvvatlash mavjudligi.

Alfa versiyasida CSI uchun yana bir xususiyat - imkoniyat to'g'ridan-to'g'ri (ya'ni, PV/PVX ishlatmasdan) pod spetsifikatsiyasidagi CSI hajmlariga murojaat qiling. Bu CSI-dan faqat masofaviy ma'lumotlarni saqlash sifatida foydalanishga bo'lgan cheklovni olib tashlaydi, ular uchun dunyo eshiklarini ochadi mahalliy efemer hajmlar. Foydalanish uchun (hujjatlardan misol) yoqilgan bo'lishi kerak CSIInlineVolume xususiyatli eshik.

Kubernetes-ning CSI bilan bog'liq "ichki qismlarida" ham taraqqiyot kuzatildi, ular oxirgi foydalanuvchilar (tizim ma'murlari) uchun unchalik ko'rinmaydi ... Hozirda ishlab chiquvchilar har bir saqlash plaginining ikkita versiyasini qo'llab-quvvatlashga majbur: biri - "ichida" eski usul”, K8s kod bazasi ichida (daraxtda), ikkinchisi - yangi CSIning bir qismi sifatida (masalan, bu haqda ko'proq o'qing shu yerda). Bu tushunarli noqulayliklarni keltirib chiqaradi, chunki CSIning o'zi barqarorlashadi. Ichki (daraxt ichidagi) plaginlarning API-ni shunchaki bekor qilish mumkin emas tegishli Kubernetes siyosati.

Bularning barchasi alfa versiyasiga erishganiga olib keldi migratsiya jarayoni ichki plagin kodi, CSI plaginlarida daraxt ichida amalga oshiriladi, buning natijasida ishlab chiquvchilarning tashvishlari plaginlarining bitta versiyasini qo'llab-quvvatlashga kamayadi va eski API bilan moslik saqlanib qoladi va ular odatdagi stsenariyda eskirgan deb e'lon qilinishi mumkin. Kubernetes (1.15) ning keyingi versiyasiga qadar barcha bulutli provayder plaginlari ko'chiriladi, dastur beta holatini oladi va sukut bo'yicha K8s o'rnatishlarida faollashtiriladi. Tafsilotlar uchun qarang dizayn taklifi. Bu migratsiya ham natija berdi rad etish muayyan bulut provayderlari (AWS, Azure, GCE, Cinder) tomonidan belgilangan hajm chegaralaridan.

Bundan tashqari, CSI bilan bloklangan qurilmalarni qo'llab-quvvatlash (CSIBlockVolume) uzatildi beta versiyasiga.

Tugunlar/Kubelet

Alfa versiyasi taqdim etildi yangi yakuniy nuqta Kubeletda, uchun mo'ljallangan asosiy resurslar bo'yicha ko'rsatkichlarni qaytarish. Umuman olganda, agar ilgari Kubelet konteynerdan foydalanish statistikasini cAdvisor’dan olgan bo‘lsa, endi bu ma’lumotlar konteyner ish vaqti muhitidan CRI (Container Runtime Interface) orqali keladi, lekin Docker’ning eski versiyalari bilan ishlash uchun moslik ham saqlanib qolgan. Ilgari Kubelet-da to'plangan statistik ma'lumotlar REST API orqali yuborilgan bo'lsa, endi oxirgi nuqta quyidagi manzilda joylashgan. /metrics/resource/v1alpha1. Ishlab chiquvchilarning uzoq muddatli strategiyasi hisoblanadi Kubelet tomonidan taqdim etilgan ko'rsatkichlar to'plamini minimallashtirishdir. Aytgancha, bu ko'rsatkichlarning o'zi endi qo'ng'iroq qilishadi "asosiy ko'rsatkichlar" emas, balki "resurs ko'rsatkichlari" va "protsessor va xotira kabi birinchi darajali resurslar" sifatida tavsiflanadi.

Juda qiziq nuance: Prometey formatidan foydalanishning turli holatlari bilan solishtirganda gRPC so'nggi nuqtasining aniq ishlash ustunligiga qaramay (quyidagi benchmarklardan birining natijasiga qarang), mualliflar ushbu monitoring tizimining jamiyatda aniq rahbarligi tufayli Prometeyning matn formatini afzal ko'rdilar.

“gRPC asosiy monitoring quvurlari bilan mos kelmaydi. Endpoint faqat Metrics Serverga o'lchovlarni etkazib berish yoki u bilan to'g'ridan-to'g'ri integratsiyalangan komponentlarni kuzatish uchun foydali bo'ladi. Metrics Serverda keshlashdan foydalanganda Prometey matn formatining ishlashi etarlicha yaxshi biz uchun Prometeyni gRPC dan afzal ko'rishimiz uchun Prometeyning jamiyatda keng qo'llanilishini hisobga olgan holda. OpenMetrics formati barqarorroq bo'lganda, biz gRPC ishlashiga proto-asoslangan format bilan yaqinlasha olamiz.

Ko'rsatkichlar uchun yangi Kubelet so'nggi nuqtasida gRPC va Prometey formatlaridan foydalanishning qiyosiy ishlash testlaridan biri. Batafsil grafiklar va boshqa tafsilotlarni topishingiz mumkin KO'RING.

Boshqa o'zgarishlar qatorida:

• Kubelet hozir (bir marta) to'xtatishga harakat qilish qayta ishga tushirish va operatsiyalarni o'chirishdan oldin konteynerlarni noma'lum holatda.
• Foydalanishda PodPresets Endi boshlang'ich konteyneriga qo'shiladi oddiy konteyner bilan bir xil ma'lumot.
• kubelet foydalanishni boshladi usageNanoCores CRI statistikasi provayderidan va Windows tizimidagi tugunlar va konteynerlar uchun qo'shildi tarmoq statistikasi.
• Operatsion tizim va arxitektura ma'lumotlari endi teglarda qayd etilgan kubernetes.io/os и kubernetes.io/arch Tugun ob'ektlari (beta-dan GA-ga o'tkaziladi).
• Podda konteynerlar uchun ma'lum bir tizim foydalanuvchi guruhini belgilash qobiliyati (RunAsGroup, ichida paydo bo'ldi K8s 1.11) rivojlangan beta versiyasidan oldin (sukut bo'yicha yoqilgan).
• du va cAdvisor-da qo'llaniladigan topish, almashtirildi on Go amalga oshirish.

CLI

Cli-runtime va kubectl-da qo'shildi bilan integratsiya uchun -k bayrog'i moslashtirish (Aytgancha, uning rivojlanishi endi alohida omborda amalga oshiriladi), ya'ni. maxsus kustomizatsiya kataloglaridan qo'shimcha YAML fayllarini qayta ishlash uchun (ulardan foydalanish bo'yicha batafsil ma'lumot uchun qarang KO'RING):

Oddiy fayldan foydalanishga misol moslashtirish (Ichkarida kustomizatsiyani yanada murakkab qo'llash mumkin qoplamalari)

Bundan tashqari:

• Qo'shilgan yangi jamoa kubectl create cronjob, kimning ismi o'zi uchun gapiradi.
• В kubectl logs endi mumkin birlashtirish uchun bayroqlar -f (--follow jurnallarni oqimlash uchun) va -l (--selector yorliq so'rovi uchun).
• kubectl o'rgatgan wild card bilan tanlangan fayllarni nusxalash.
• Jamoaga kubectl wait qo'shilgan bayroq --all belgilangan resurs turidagi nomlar maydonidagi barcha resurslarni tanlash.

boshqa

Quyidagi imkoniyatlar barqaror (GA) maqomini oldi:

• ReadinessGate, podning tayyorligida hisobga olingan qo'shimcha shartlarni belgilash uchun pod spetsifikatsiyasida ishlatiladi;
• Katta sahifalarni qo'llab-quvvatlash (xususiyatlar eshigi chaqiriladi HugePages);
• CustomPodDNS;
• PriorityClass API Pod ustuvorligi va ustunligi.

Kubernetes 1.14 da kiritilgan boshqa o'zgarishlar:

• Standart RBAC siyosati endi API kirishiga ruxsat bermaydi discovery и access-review autentifikatsiyasiz foydalanuvchilar (tasdiqlanmagan).
• Rasmiy CoreDNS yordami ta'minlangan Faqat Linux, shuning uchun kubeadm dan (CoreDNS) klasterda joylashtirish uchun foydalanilganda, tugunlar faqat Linuxda ishlashi kerak (bu cheklov uchun nodeSelectors ishlatiladi).
• Standart CoreDNS konfiguratsiyasi hozir ispolzet oldinga plagin proksi o'rniga. Shuningdek, CoreDNS da qo'shildi Tegishli (xizmat ko'rsatishga tayyor bo'lmagan) podlarda yukni muvozanatlashni oldini olishga tayyorlikProbe.
• Kubeadm-da, bosqichlarda init yoki upload-certs, mumkin bo‘ldi yangi boshqaruv tekisligini kubeadm-certs siriga ulash uchun zarur bo'lgan sertifikatlarni yuklang (bayroqdan foydalaning --experimental-upload-certs).
• Windows o'rnatish uchun alfa versiyasi paydo bo'ldi qo'llab-quvvatlash gMSA (Group Managed Service Account) - Active Directory-dagi maxsus hisoblar, ulardan konteynerlar ham foydalanishi mumkin.
• G.C.E uchun. faollashtirilgan etcd va kube-apiserver o'rtasida mTLS shifrlash.
• Ishlatilgan/qaram dasturiy ta'minotdagi yangilanishlar: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, kubeadm'da Docker 18.09 qo'llab-quvvatlanadi va minimal qo'llab-quvvatlanadigan Docker API versiyasi endi 1.26.

PS

Shuningdek, bizning blogimizda o'qing:

• «Kubernetes 1.13: Yangiliklarning diqqatga sazovor joylari";
• «Kubernetes 1.12: Yangiliklarning diqqatga sazovor joylari";
• «Kubernetes 1.11: Yangiliklarning diqqatga sazovor joylari";
• «Kubernetes 1.10: Yangiliklarning diqqatga sazovor joylari".

Manba: www.habr.com