Šonakt nākamais Kubernetes izlaidums - . Saskaņā ar tradīciju, kas ir izveidojusies mūsu emuāram, mēs runājam par galvenajām izmaiņām šī brīnišķīgā atvērtā pirmkoda produkta jaunajā versijā.
Šī materiāla sagatavošanai izmantotā informācija ir ņemta no , un saistītie jautājumi, izvilkšanas pieprasījumi, Kubernetes uzlabošanas priekšlikumi (KEP).
Sāksim ar svarīgu ievadu no SIG klastera dzīves cikla: dinamiskās kļūmjpārlēces kopas Kubernetes (vai, precīzāk sakot, pašviesinātas HA izvietošanas) tagad ir izmantojot pazīstamas (viena mezgla klasteru kontekstā) komandas kubeadm (init и join). Īsāk sakot, šim:
- klastera izmantotie sertifikāti tiek nodoti noslēpumiem;
- par iespēju izmantot etcd klasteru K8s klasterī (t.i., atbrīvoties no iepriekš esošās ārējās atkarības) ;
- Dokumentē ieteicamos iestatījumus ārējam slodzes balansētājam, kas nodrošina kļūdu izturīgu konfigurāciju (nākotnē ir plānots novērst šo atkarību, bet ne šajā posmā).
Ar kubeadm izveidotā Kubernetes HA klastera arhitektūra
Sīkāku informāciju par ieviešanu var atrast . Šī funkcija bija patiešām ilgi gaidīta: alfa versija tika gaidīta jau K8s 1.9 versijā, taču tā parādījās tikai tagad.
API
Komanda apply un vispārīgi runājot deklaratīvā objektu vadība no kubectl apiserverā. Paši izstrādātāji īsi skaidro savu lēmumu ar to kubectl apply - būtiska daļa darbā ar konfigurācijām programmā Kubernetes, taču “tas ir pilns ar kļūdām un grūti labojams”, un tāpēc šī funkcionalitāte ir jāatgriež normālā stāvoklī un jāpārnes uz vadības plakni. Vienkārši un skaidri piemēri mūsdienu problēmām:
Sīkāka informācija par ieviešanu ir atrodama . Pašreizējā gatavība ir alfa (paaugstināšana uz beta ir plānota nākamajā Kubernetes laidienā).
Pieejams alfa versijā izmantojot OpenAPI v3 shēmu izveidot un publicēt OpenAPI dokumentāciju par CustomResources (CR), ko izmanto, lai validētu (servera puses) K8s lietotāja definētus resursus (CustomResourceDefinition, CRD). Publicējot OpenAPI for CRD, klienti (piem., kubectl) veiciet validāciju savā pusē (iekšā kubectl create и kubectl apply) un izsniedz dokumentāciju saskaņā ar shēmu (kubectl explain). Sīkāka informācija - iekšā .
Iepriekš esošie žurnāli ar karogu O_APPEND (bet ne O_TRUNC), lai dažās situācijās izvairītos no baļķu zudumiem un ērtākai baļķu apgriešanai ar ārējām utilītprogrammām rotācijai.
Arī Kubernetes API kontekstā var atzīmēt, ka in PodSandbox и PodSandboxStatus laukā runtime_handler lai ierakstītu informāciju par RuntimeClass podā (vairāk par to lasiet tekstā par , kur šī klase parādījās kā alfa versija) un programmā Uzņemšanas Webhooks spēja noteikt, kuras versijas AdmissionReview viņi atbalsta. Visbeidzot, tagad ir spēkā Uzņemšanas Webhooks noteikumi to izmantošanas apjoms nosaukumvietās un klasteru ietvaros.
Uzglabāšana
, kurai kopš izlaišanas bija beta statuss , stabils (GA): šīs funkcijas vārti vairs nav atspējoti un tiks noņemti Kubernetes 1.17.
izmantojot vides mainīgos, ko sauc (piemēram, aplikuma nosaukums) to direktoriju nosaukumiem, kas uzstādīti kā , tika izstrādāts - jauna lauka veidā subPathExpr, ko tagad izmanto, lai noteiktu vēlamā direktorija nosaukumu. Sākotnēji šī funkcija parādījās Kubernetes versijā 1.11, bet versijai 1.14 tā palika alfa versijas statusā.
Tāpat kā iepriekšējā Kubernetes laidienā, aktīvi attīstās CSI (konteineru glabāšanas interfeiss) ir ieviestas daudzas būtiskas izmaiņas:
CSI
Kļuvis pieejams (kā daļa no alfa versijas) izmēru maiņa CSI sējumiem. Lai to izmantotu, jums būs jāiespējo funkciju vārti, ko sauc ExpandCSIVolumes, kā arī šīs darbības atbalsta klātbūtne konkrētā CSI draiverī.
Vēl viena CSI funkcija alfa versijā - atsaukties tieši (t.i., neizmantojot PV/PVC) uz CSI apjomiem pod specifikācijā. Šis atceļ ierobežojumus CSI izmantošanai tikai kā attālinātai datu glabāšanai, atverot viņiem durvis uz pasauli . Lietošanai () ir jāiespējo CSIInlineVolume funkciju vārti.
Progress ir vērojams arī ar CSI saistītajās Kubernetes “iekšējās ierīcēs”, kuras nav tik redzamas gala lietotājiem (sistēmas administratoriem) ... Pašlaik izstrādātāji ir spiesti atbalstīt divas katra krātuves spraudņa versijas: vienu - “ vecais veids”, K8s kodu bāzē (-kokā), bet otrais - kā daļa no jaunā CSI (vairāk par to lasiet, piemēram, in ). Tas rada saprotamas neērtības, kas ir jānovērš, stabilizējoties pašam CSI. Nav iespējams vienkārši pārtraukt iekšējo (kokā ietverto) spraudņu API darbību, jo .
Tas viss noveda pie tā, ka alfa versija sasniedza iekšējais spraudņa kods, kas ieviests kā in-tree, CSI spraudņos, pateicoties kuriem izstrādātāju rūpes tiks samazinātas līdz vienas viņu spraudņu versijas atbalstīšanai, un saderība ar vecajiem API saglabāsies un tie var tikt pasludināti par novecojušiem parastajā scenārijā. Paredzams, ka līdz nākamajai Kubernetes (1.15) laidienai visi mākoņpakalpojumu sniedzēja spraudņi tiks migrēti, ieviešana saņems beta statusu un pēc noklusējuma tiks aktivizēta K8s instalācijās. Sīkāku informāciju sk . Šīs migrācijas rezultātā arī no skaļuma ierobežojumiem, ko nosaka konkrēti mākoņpakalpojumu sniedzēji (AWS, Azure, GCE, Cinder).
Turklāt atbalsts bloku ierīcēm ar CSI (CSIBlockVolume) uz beta versiju.
Mezgli / Kubelet
Prezentēta alfa versija in Kubelet, kas paredzēts atdeves metriku par galvenajiem resursiem. Vispārīgi runājot, ja iepriekš Kubelet saņēma statistiku par konteinera lietojumu no cAdvisor, tagad šie dati nāk no konteinera izpildlaika vides, izmantojot CRI (Container Runtime Interface), taču tiek saglabāta arī saderība darbam ar vecākām Docker versijām. Iepriekš Kubelet apkopotā statistika tika nosūtīta, izmantojot REST API, bet tagad galapunkts atrodas plkst /metrics/resource/v1alpha1. Izstrādātāju ilgtermiņa stratēģija ir samazināt Kubelet nodrošināto metrikas kopu. Starp citu, paši šie rādītāji nevis “pamatmetrika”, bet “resursu metrika”, un tie tiek raksturoti kā “pirmās klases resursi, piemēram, centrālais procesors un atmiņa”.
Ļoti interesanta nianse: neskatoties uz nepārprotamo gRPC galapunkta veiktspējas priekšrocību salīdzinājumā ar dažādiem Prometheus formāta izmantošanas gadījumiem (skatiet zemāk viena no etaloniem rezultātu), autori deva priekšroku Prometheus teksta formātam, jo šī pārraudzības sistēma sabiedrībā skaidri vadās.
“gRPC nav savietojams ar galvenajiem monitoringa cauruļvadiem. Galapunkts būs noderīgs tikai metrikas piegādei uz Metrics Server vai pārraudzības komponentiem, kas ir tieši integrēti ar to. Prometheus teksta formāta veiktspēja, izmantojot Metrics Server kešatmiņu pietiekami labs lai mēs dotu priekšroku Prometheus, nevis gRPC, ņemot vērā Prometheus plaši izplatīto ieviešanu sabiedrībā. Tiklīdz OpenMetrics formāts kļūs stabilāks, mēs varēsim tuvoties gRPC veiktspējai, izmantojot prototipa formātu.
Viens no salīdzinošajiem veiktspējas testiem, izmantojot gRPC un Prometheus formātus jaunajā Kubelet metriku galapunktā. Vairāk grafiku un citu informāciju var atrast .
Starp citām izmaiņām:
- Kubelet tagad (vienu reizi) konteineri nezināmā stāvoklī pirms restartēšanas un dzēšanas darbības.
- Lietojot tagad uz init konteineru tāda pati informācija kā parastam konteineram.
- kubelet
usageNanoCoresno CRI statistikas sniedzēja, kā arī mezgliem un konteineriem Windows tīkla statistika. - Operētājsistēmas un arhitektūras informācija tagad tiek ierakstīta etiķetēs
kubernetes.io/osиkubernetes.io/archMezglu objekti (pārsūtīti no beta uz GA). - Iespēja norādīt konkrētu sistēmas lietotāju grupu konteineriem podā (
RunAsGroup, parādījās ) pirms beta versijas (iespējota pēc noklusējuma). - du un atrast, ko izmanto cAdvisor, on Go ieviešana.
CLI
Cli-runtime un kubectl -k karodziņš integrācijai ar (starp citu, tā izstrāde tagad tiek veikta atsevišķā repozitorijā), t.i. lai apstrādātu papildu YAML failus no īpašiem kustomizācijas direktorijiem (sīkāku informāciju par to izmantošanu skatiet ):
Vienkārša failu izmantošanas piemērs (iekšpusē ir iespējama sarežģītāka kustomize pielietošana )
Turklāt:
- jauna komanda
kubectl create cronjob, kura nosaukums runā pats par sevi. - В
kubectl logstagad Tu vari karogi-f(--followžurnālu straumēšanai) un-l(--selectoretiķetes vaicājumam). - kubectl kopēt failus, kas atlasīti ar aizstājējzīmi.
- Uz komandu
kubectl waitkarogs--alllai atlasītu visus resursus norādītā resursa tipa nosaukumvietā.
Pārējie
Tālāk norādītajām iespējām ir piešķirts stabils (GA) statuss:
- , ko izmanto pāksts specifikācijā, lai definētu papildu nosacījumus, kas jāņem vērā pāksts gatavībā;
- Atbalsts lielām lapām (funkciju vārti tiek saukti );
- ;
- PriorityClass API .
Citas Kubernetes 1.14 ieviestās izmaiņas:
- Noklusējuma RBAC politika vairs neļauj piekļūt API
discoveryиaccess-reviewlietotāji bez autentifikācijas (neautentificēts). - Oficiālais CoreDNS atbalsts tikai priekš Linux, tāpēc, izmantojot kubeadm tā izvietošanai (CoreDNS) klasterī, mezgliem vajadzētu darboties tikai Linux (šim ierobežojumam tiek izmantoti nodeSelectors).
- Tagad ir noklusējuma CoreDNS konfigurācija starpniekservera vietā. Arī CoreDNS ReadinessProbe, kas novērš slodzes līdzsvarošanu uz atbilstošiem (servisam nav gataviem) podiem.
- In kubeadm, uz fāzēm
initvaiupload-certs, ielādējiet sertifikātus, kas nepieciešami, lai jauno vadības plakni savienotu ar kubeadm-certs noslēpumu (izmantojiet karogu--experimental-upload-certs). - Par Windows-Ir parādījusies instalāciju alfa versija. gMSA (Group Managed Service Account) — īpaši konti Active Directory, ko var izmantot arī konteineri.
- Par G.C.E. mTLS šifrēšana starp etcd un kube-apiserver.
- Lietotās/atkarīgās programmatūras atjauninājumi: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, Docker 18.09 atbalsts programmā kubeadm, un minimālā atbalstītā Docker API versija tagad ir 1.26.
PS
Lasi arī mūsu emuārā:
- «";
- «";
- «";
- «'.
Avots: www.habr.com
