Kubernetes 1.16: үндсэн инновацийн тойм

Kubernetes 1.16: үндсэн инновацийн тойм

Өнөөдөр, Лхагва гараг, болох болно Kubernetes-ийн дараагийн хувилбар - 1.16. Манай блогт бий болсон уламжлалын дагуу бид арван жилийн ойн үеэр шинэ хувилбарт хамгийн чухал өөрчлөлтүүдийн талаар ярьж байна.

Энэ материалыг бэлтгэхэд ашигласан мэдээллийг эндээс авсан болно Kubernetes сайжруулалтыг хянах хүснэгтүүд, ӨӨРЧЛӨЛТ-1.16 болон холбогдох асуудлууд, татах хүсэлт, Kubernetes Enhancement Proposals (KEP). За, явцгаая! ..

Зангилаа

K8s кластерийн зангилааны (Kubelet) талд үнэхээр олон тооны онцлох шинэлэг зүйлүүдийг (альфа хувилбарын төлөвт) толилуулж байна.

Нэгдүгээрт, гэж нэрлэгддэг «түр зуурын савнууд» (Түр зуурын савнууд), pods дахь дибаг хийх процессыг хялбарчлахад зориулагдсан. Шинэ механизм нь одоо байгаа хонхорцогуудын нэрсийн орон зайд эхэлж, богино хугацаанд амьдрах тусгай савыг эхлүүлэх боломжийг танд олгоно. Тэдний зорилго нь аливаа асуудлыг шийдэж, дибаг хийх зорилгоор бусад сав, савтай харилцах явдал юм. Энэ функцэд зориулж шинэ тушаалыг хэрэгжүүлсэн kubectl debug, мөн чанараараа төстэй kubectl exec: зөвхөн процессыг саванд ажиллуулахын оронд (д exec) энэ нь савны савыг ажиллуулдаг. Жишээлбэл, энэ тушаал нь шинэ савыг подволд холбох болно:

kubectl debug -c debug-shell --image=debian target-pod -- bash

Түр зуурын савны талаарх дэлгэрэнгүй мэдээллийг (мөн тэдгээрийн хэрэглээний жишээг) эндээс олж болно харгалзах KEP. Одоогийн хэрэгжүүлэлт (K8s 1.16) нь альфа хувилбар бөгөөд түүнийг бета хувилбар руу шилжүүлэх шалгууруудын нэг нь "[Kubernetes]-ийн 2-оос доошгүй хувилбарт түр зуурын агуулах API-г турших явдал юм."

NB: Мөн чанар, тэр ч байтугай нэрээрээ энэ функц нь аль хэдийн байгаа залгаастай төстэй юм kubectl-дибагүүний талаар бид аль хэдийн бичсэн. Түр зуурын савнууд гарч ирснээр тусдаа гадаад залгаасын хөгжүүлэлт зогсох төлөвтэй байна.

Өөр нэг шинэлэг зүйл - PodOverhead - хангах зорилготой хонхорцогт зориулсан нэмэлт зардлыг тооцох механизм, ашигласан ажиллах хугацаанаас хамааран ихээхэн ялгаатай байж болно. Жишээлбэл, зохиогчид энэ KEP үр дүнд нь зочны цөм, ката агент, init систем гэх мэтийг ажиллуулах шаардлагатай Ката Контейнерууд үүсдэг. Нэмэлт зардал маш их болсон үед үүнийг үл тоомсорлож болохгүй, энэ нь цаашдын квот, төлөвлөлт гэх мэт үүнийг харгалзан үзэх арга зам байх ёстой гэсэн үг юм. Үүнийг хэрэгжүүлэхийн тулд PodSpec талбар нэмсэн Overhead *ResourceList (-д байгаа өгөгдөлтэй харьцуулна RuntimeClass, хэрэв нэгийг нь ашигласан бол).

Өөр нэг онцлох шинэлэг зүйл бол зангилааны топологийн менежер (Зангилааны топологийн менежер), Kubernetes дахь янз бүрийн бүрэлдэхүүн хэсгүүдийн техник хангамжийн нөөцийн хуваарилалтыг нарийн тааруулах хандлагыг нэгтгэх зорилготой. Энэхүү санаачилга нь орчин үеийн төрөл бүрийн системүүдийн (харилцаа холбоо, машин сургалтын салбар, санхүүгийн үйлчилгээ гэх мэт) өндөр хүчин чадалтай зэрэгцээ тооцоолол хийх, үйл ажиллагааны гүйцэтгэлийн саатлыг багасгах хэрэгцээ нэмэгдэж байгаатай холбоотой бөгөөд үүний тулд дэвшилтэт CPU болон техник хангамжийн хурдатгалын чадвар. Kubernetes дахь ийм оновчлолууд нь ялгаатай бүрэлдэхүүн хэсгүүдийн (CPU менежер, Төхөөрөмжийн менежер, CNI) ачаар өнөөг хүртэл хүрч ирсэн бөгөөд одоо тэдгээрт хандлагыг нэгтгэж, шинэ ижил төстэй топологи гэж нэрлэгддэг холболтыг хялбаршуулдаг нэг дотоод интерфэйс нэмэгдэх болно. aware - Kubelet талын бүрэлдэхүүн хэсгүүд. Дэлгэрэнгүй - дотор харгалзах KEP.

Kubernetes 1.16: үндсэн инновацийн тойм
Топологийн менежерийн бүрэлдэхүүн хэсгийн диаграмм

Дараагийн онцлог - савыг ажиллаж байх үед нь шалгах (эхлүүлэх датчик). Ашиглахад удаан хугацаа шаардагддаг чингэлэгүүдийн хувьд шинэчлэгдсэн статусыг олж авахад хэцүү байдаг: тэдгээр нь ажиллаж эхлэхээсээ өмнө "алагддаг" эсвэл удаан хугацаагаар мухардалд ордог. Шинэ шалгалт (дуудагдсан функцийн хаалгаар идэвхжсэн StartupProbeEnabled) pod ажиллаж дуусах хүртэл бусад шалгалтын үр нөлөөг цуцална, эс тэгвээс хойшлуулна. Энэ шалтгааны улмаас уг функцийг анх нэрлэжээ pod-startup liveness-probe holdoff. Эхлэхэд удаан хугацаа шаардагддаг хонхорцогуудын хувьд та мужийг харьцангуй богино хугацааны интервалаар санал асуулга явуулж болно.

Нэмж дурдахад, RuntimeClass-ийн сайжруулалтыг бета төлөвт нэн даруй ашиглах боломжтой болж, "нэгдмэл бус кластер"-д дэмжлэг үзүүлэх боломжтой. C RuntimeClass хуваарь Одоо зангилаа бүрд RuntimeClass тус бүрийг дэмжих шаардлагагүй: pods-ийн хувьд та кластерын топологийн талаар бодохгүйгээр RuntimeClass-ийг сонгож болно. Өмнө нь үүнд хүрэхийн тулд хонхорцог нь шаардлагатай бүх зүйлээ дэмждэг зангилаанууд дээр зогсохын тулд NodeSelector болон хүлцэлд тохирох дүрмийг зааж өгөх шаардлагатай байв. IN КЕП Энэ нь хэрэглээний жишээ, мэдээж хэрэг хэрэгжилтийн нарийн ширийн зүйлийн талаар ярьдаг.

Сүлжээ

Kubernetes 1.16 дээр анх удаа (альфа хувилбарт) гарч ирсэн хоёр чухал сүлжээний онцлог нь:

  • тусламж хос сүлжээний стек - IPv4/IPv6 - ба түүний тохирох "ойлголт" нь хонхорцог, зангилаа, үйлчилгээний түвшинд. Үүнд pods хооронд IPv4-ээс IPv4 болон IPv6-аас IPv6 хүртэл харилцан ажиллах чадвар, pods-аас гадаад үйлчилгээ, лавлагааны хэрэгжүүлэлтүүд (Bridge CNI, PTP CNI болон Host-Local IPAM залгаасууд дотор), түүнчлэн ажиллаж байгаа Kubernetes кластертай урвуу нийцтэй байдал орно. Зөвхөн IPv4 эсвэл IPv6. Хэрэгжилтийн талаарх дэлгэрэнгүй мэдээлэл байна КЕП.

    Хоёр төрлийн (IPv4 ба IPv6) IP хаягуудыг подкуудын жагсаалтад харуулах жишээ:

    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#

  • Endpoint-д зориулсан шинэ API - EndpointSlice API. Энэ нь хяналтын хавтгай дахь янз бүрийн бүрэлдэхүүн хэсгүүдэд (apiserver, etcd, endpoints-controller, kube-proxy) нөлөөлдөг одоо байгаа Endpoint API-ийн гүйцэтгэл / өргөтгөх чадварын асуудлыг шийддэг. Шинэ API нь Discovery API бүлэгт нэмэгдэх бөгөөд мянга мянган зангилаанаас бүрдэх кластерт үйлчилгээ тус бүр дээр хэдэн арван мянган арын төгсгөлийн цэгүүдэд үйлчлэх боломжтой болно. Үүнийг хийхийн тулд Үйлчилгээ бүрийг N объекттой харуулдаг EndpointSlice, тус бүр нь анхдагчаар 100-аас илүүгүй төгсгөлтэй байна (утгыг тохируулах боломжтой). EndpointSlice API нь цаашдын хөгжилд нь боломж олгох болно: pod тус бүрийн олон IP хаяг, төгсгөлийн шинэ төлөв (зөвхөн биш) Ready и NotReady), төгсгөлийн цэгүүдийн динамик дэд тохиргоо.

Сүүлийн хувилбарт танилцуулсан нь бета хувилбарт хүрсэн эцсийн боловсруулагч, нэртэй service.kubernetes.io/load-balancer-cleanup үйлчилгээ тус бүрд төрлөөр нь хавсаргасан LoadBalancer. Ийм үйлчилгээг устгах үед энэ нь тэнцвэржүүлэгчийн холбогдох бүх нөөцийг "цэвэрлэх" хүртэл нөөцийг бодитоор устгахаас сэргийлдэг.

API машин

Жинхэнэ "тогтворжуулалтын үе шат" нь Kubernetes API сервер болон түүнтэй харилцах талбарт байдаг. Энэ нь ихээхэн ачаар болсон тусгай танилцуулга хийх шаардлагагүй хүмүүсийг тогтвортой байдалд шилжүүлэх Custom Resource Definitions (CRD), Kubernetes 1.7-ийн алс холын өдрүүдээс хойш бета статустай байсан (мөн энэ бол 2017 оны XNUMX-р сар!). Үүнтэй ижил тогтворжилт нь холбогдох шинж чанаруудад ирсэн:

  • "дэд эх сурвалж" нь /status и /scale CustomResources-ийн хувьд;
  • хувиргах гадаад вэб дэгээ дээр суурилсан CRD-д зориулсан хувилбарууд;
  • саяхан танилцуулсан (K8s 1.15-д) өгөгдмөл утгууд (өгөгдмөл) болон автомат талбайг устгах (тайрах) CustomResources-ийн хувьд;
  • боломж OpenAPI v3 схемийг ашиглан сервер талд CRD нөөцийг баталгаажуулахад ашигладаг OpenAPI баримт бичгийг үүсгэж нийтлэх.

Kubernetes-ийн администраторуудад эртнээс танил болсон өөр нэг механизм: элсэлтийн вэб дэгээ - мөн бета төлөвт удаан хугацаагаар үлдсэн (K8s 1.9-с хойш) бөгөөд одоо тогтвортой гэж зарлагдлаа.

Өөр хоёр онцлог нь бета хувилбарт хүрсэн: сервер талд хэрэглэнэ и хавчуурга үзэх.

Альфа хувилбарын цорын ганц чухал шинэлэг зүйл нь байв алдаа нь SelfLink - заасан объектыг төлөөлж, нэг хэсэг болох тусгай URI ObjectMeta и ListMeta (өөрөөр хэлбэл Кубернетес дэх аливаа объектын хэсэг). Тэд яагаад үүнийг орхиод байгаа юм бэ? Энгийн аргаар сэдэл өгөх сонсогдож байна Энэ талбар оршин тогтнох бодит (илэн далангүй) шалтгаан байхгүй. Илүү албан ёсны шалтгаанууд нь гүйцэтгэлийг оновчтой болгох (шаардлагагүй талбарыг арилгах замаар), ерөнхий аписерверийн ажлыг хялбарчлах, ийм талбарыг тусгай аргаар зохицуулах (энэ нь объектын өмнө тавигдсан цорын ганц талбар юм) юм. цуваа болсон). Жинхэнэ хуучирсан (бета дотор) SelfLink Kubernetes хувилбар 1.20, эцсийн хувилбар нь 1.21.

Өгөгдөл хадгалах

Өмнөх хувилбаруудын нэгэн адил хадгалалтын талбайн гол ажил энэ газарт ажиглагдаж байна CSI дэмжлэг. Энд гол өөрчлөлтүүд нь:

  • анх удаа (альфа хувилбарт) гарч ирэв Windows ажилчны зангилааны CSI залгаасын дэмжлэг: хадгалалттай ажиллах одоогийн арга нь мөн Powershell дээр суурилсан Microsoft-ын Kubernetes үндсэн болон FlexVolume залгаасууд дахь мод доторх залгаасуудыг орлуулах болно;

    Kubernetes 1.16: үндсэн инновацийн тойм
    Windows-д зориулсан Kubernetes дээр CSI залгаасуудыг хэрэгжүүлэх схем

  • боломж CSI эзлэхүүний хэмжээг өөрчлөх, K8s 1.12-д буцаж танилцуулагдсан бөгөөд бета хувилбар болж өссөн;
  • Орон нутгийн түр зуурын эзлэхүүнийг үүсгэхийн тулд CSI-г ашиглах чадвараар ижил төстэй "сурталчилгаа" (альфагаас бета хүртэл) хийгдсэн.CSI Inline дууны дэмжлэг).

Kubernetes-ийн өмнөх хувилбарт танилцуулсан эзэлхүүнийг клонжуулах функц (одоо байгаа PVC-ийг ашиглан DataSource шинэ PVC үүсгэх) мөн одоо бета статусыг хүлээн авлаа.

Хуваарьлагч

Хуваарьт хоёр мэдэгдэхүйц өөрчлөлт (альфа аль аль нь):

  • EvenPodsSpreading - боломж ачааллыг "шударга хуваарилах" зорилгоор логик хэрэглээний нэгжийн оронд pods ашиглах (Deployment and ReplicaSet гэх мэт) болон энэ хуваарилалтыг тохируулах (хатуу шаардлага эсвэл зөөлөн нөхцөл, өөрөөр хэлбэл тэргүүлэх ач холбогдол). Энэ онцлог нь одоогоор сонголтоор хязгаарлагдаж байгаа төлөвлөсөн подкуудын одоо байгаа түгээлтийн чадамжийг өргөжүүлэх болно PodAffinity и PodAntiAffinity, администраторуудад энэ асуудалд илүү нарийн хяналт өгөх нь илүү өндөр хүртээмжтэй, оновчтой нөөцийн зарцуулалт гэсэн үг юм. Дэлгэрэнгүй - дотор КЕП.
  • Ашиглах BestFit бодлого в RequestedToCapacityRatio Тэргүүлэх функц боломж олгох pod төлөвлөлтийн үед ашиглах хогийн сав баглаа боодол ("Саванд савлах") үндсэн нөөц (процессор, санах ой) болон өргөтгөсөн нөөцөд (GPU гэх мэт). Дэлгэрэнгүй мэдээллийг үзнэ үү КЕП.

    Kubernetes 1.16: үндсэн инновацийн тойм
    Хуваарийн хуваарь: хамгийн сайн тохирох бодлогыг ашиглахаас өмнө (өгөгдмөл хуваарьлагчаар шууд) болон түүнийг ашиглах үед (хуваарьлагч өргөтгөгчөөр)

Цаашилбал, танилцуулсан Kubernetes хөгжлийн үндсэн модны гадна (модноос гадуур) өөрийн хуваарийн залгаасуудыг үүсгэх чадвар.

Бусад өөрчлөлтүүд

Мөн Kubernetes 1.16 хувилбар дээр та тэмдэглэж болно зориулсан санаачилга авчрах боломжтой хэмжүүрүүдийг бүрэн дарааллаар нь, эсвэл илүү тодорхой, дагуу албан ёсны журам K8s багаж хэрэгсэл рүү. Тэд ихэвчлэн харгалзах зүйл дээр тулгуурладаг Прометейгийн баримт бичиг. Тохиромжгүй байдал нь янз бүрийн шалтгааны улмаас үүссэн (жишээлбэл, зарим хэмжигдэхүүнийг одоогийн заавар гарч ирэхээс өмнө зүгээр л үүсгэсэн) бөгөөд хөгжүүлэгчид "Прометейгийн бусад экосистемтэй нийцүүлэн" бүх зүйлийг нэг стандартад хүргэх цаг болсон гэж шийджээ. Энэхүү санаачилгын одоогийн хэрэгжилт нь альфа статустай байгаа бөгөөд Kubernetes-ийн дараагийн хувилбаруудад бета (1.17) болон тогтвортой (1.18) хувилбарууд руу аажмаар дэвших болно.

Үүнээс гадна дараахь өөрчлөлтүүдийг тэмдэглэж болно.

  • Windows хөгжүүлэлтийг дэмждэг с гадаад төрх Энэ үйлдлийн системд зориулсан Kubeadm хэрэгслүүд (альфа хувилбар), боломж RunAsUserName Windows савны хувьд (альфа хувилбар), сайжруулалт Бүлгийн удирдлагатай үйлчилгээний данс (gMSA) бета хувилбар хүртэл дэмждэг, дэмжлэг үзүүлэх vSphere эзлэхүүний хувьд холбох/хавсруулах.
  • Дахин боловсруулсан API хариулт дахь өгөгдлийг шахах механизм. Өмнө нь HTTP шүүлтүүрийг эдгээр зорилгоор ашигладаг байсан бөгөөд энэ нь түүнийг анхдагчаар идэвхжүүлэхээс сэргийлсэн хэд хэдэн хязгаарлалт тавьсан. "Ил тод хүсэлт шахалт" одоо ажиллаж байна: үйлчлүүлэгч илгээж байна Accept-Encoding: gzip Толгой хэсэгт хэмжээ нь 128 КБ-аас хэтэрсэн тохиолдолд GZIP-ээр шахсан хариултыг хүлээн авна. Go үйлчлүүлэгч автоматаар шахалтыг дэмждэг (шаардлагатай толгойг илгээдэг), ингэснээр тэд замын хөдөлгөөний бууралтыг шууд анзаарах болно. (Бусад хэлний хувьд бага зэрэг өөрчлөлт оруулах шаардлагатай байж магадгүй.)
  • Боломжтой болсон гадаад хэмжигдэхүүн дээр тулгуурлан HPA-г тэгээс/тэг хүртэл масштаблах. Хэрэв та объект/гадаад хэмжигдэхүүн дээр тулгуурлан масштаблах юм бол ажлын ачаалал идэвхгүй байх үед нөөцийг хэмнэхийн тулд автоматаар 0 хуулбар хүртэл масштаблах боломжтой. Энэ функц нь ялангуяа ажилчид GPU-ийн нөөцийг хүссэн тохиолдолд ашиг тустай байх ёстой бөгөөд өөр өөр төрлийн сул зогсолттой ажилчдын тоо нь байгаа GPU-ийн тооноос давсан байдаг.
  • Шинэ үйлчлүүлэгч - k8s.io/client-go/metadata.Client - объектуудад "ерөнхий" хандалт хийх. Энэ нь мета өгөгдлийг хялбархан олж авахад зориулагдсан (жишээ нь: дэд хэсэг metadata) кластерийн нөөцөөс хог хаягдал цуглуулах, квотын үйл ажиллагаа явуулах.
  • Kubernetes бүтээх одоо та чадна хуучин (модон доторх) үүл үйлчилгээ үзүүлэгчгүй (альфа хувилбар).
  • kubeadm хэрэгсэл рүү нэмсэн туршилтын (альфа хувилбар) үйл ажиллагааны явцад өөрчлөх засваруудыг хэрэглэх чадвар init, join и upgrade. Далбааг хэрхэн ашиглах талаар илүү ихийг мэдэж аваарай --experimental-kustomize, дотор үзнэ үү КЕП.
  • Аписерверийн шинэ төгсгөлийн цэг - readyz, - бэлэн байдлын талаархи мэдээллийг экспортлох боломжийг танд олгоно. API сервер нь одоо тугтай болсон --maximum-startup-sequence-duration, дахин эхлүүлэхийг зохицуулах боломжийг танд олгоно.
  • Хоёр Azure-д зориулсан онцлог тогтвортой гэж зарласан: дэмжлэг хүртээмжтэй бүсүүд (Хүртээмжтэй бүсүүд) ба хөндлөн нөөцийн бүлэг (RG). Үүнээс гадна Azure нэмсэн:
  • AWS одоо байна дэмжлэг Windows дээрх EBS болон оновчтой болгосон EC2 API дуудлага DescribeInstances.
  • Kubeadm одоо бие даасан нүүдэллэдэг CoreDNS хувилбарыг шинэчлэх үед CoreDNS тохиргоо.
  • Хоёртын файлууд гэх мэт харгалзах Docker зураг дээр хийж байсан world-executable бөгөөд энэ нь танд үндсэн эрх шаардлагагүйгээр энэ зургийг ажиллуулах боломжийг олгодог. Мөн, гэх мэт шилжих зураг зогссон etcd2 хувилбарын дэмжлэг.
  • В Cluster Autoscaler 1.16.0 үндсэн зураг болгон distroless ашиглах руу шилжиж, гүйцэтгэл сайжирч, шинэ үүл үйлчилгээ үзүүлэгч (DigitalOcean, Magnum, Packet) нэмэгдсэн.
  • Ашигласан/хамааралтай програм хангамжийн шинэчлэлтүүд: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Мөн манай блог дээрээс уншина уу:

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх