ProHoster > Blog > administrasie > Kubernetes 1.14: Hoogtepunte van wat nuut is

Kubernetes 1.14: Hoogtepunte van wat nuut is

Kubernetes 1.14: Hoogtepunte van wat nuut is

Hierdie nag sal plaasvind volgende weergawe van Kubernetes - 1.14. Volgens die tradisie wat vir ons blog ontwikkel het, praat ons oor die sleutelveranderinge in die nuwe weergawe van hierdie wonderlike Oopbronproduk.

Inligting wat gebruik word om hierdie materiaal voor te berei, is geneem uit Kubernetes-verbeteringsopsporingstabelle, VERANDERINGSLOG-1.14 en verwante kwessies, trekversoeke, Kubernetes Enhancement Proposals (KEP).

Kom ons begin met 'n belangrike inleiding van SIG-kluster-lewensiklus: dinamiese failover-klusters Kubernetes (of om meer presies te wees, HA-ontplooiings wat self aangebied word) is nou geskep kan word met behulp van bekende (in die konteks van enkelnodus-klusters) opdragte kubeadm (init и join). Kortom, hiervoor:

  • sertifikate wat deur die groepering gebruik word, word na geheime oorgedra;
  • vir die moontlikheid om die etcd-groepering binne die K8s-groepering te gebruik (d.w.s. ontslae te raak van die voorheen bestaande eksterne afhanklikheid) ens-operateur;
  • Dokumenteer die aanbevole instellings vir 'n eksterne lasbalanseerder wat 'n foutverdraagsame konfigurasie bied (in die toekoms word beplan om hierdie afhanklikheid uit te skakel, maar nie op hierdie stadium nie).

Kubernetes 1.14: Hoogtepunte van wat nuut is
Argitektuur van 'n Kubernetes HA-kluster geskep met kubeadm

Besonderhede van die implementering kan gevind word in ontwerpvoorstel. Hierdie kenmerk was werklik lank verwag: die alfa-weergawe is terug in K8s 1.9 verwag, maar het eers nou verskyn.

API

Span apply en oor die algemeen verklarende objekbestuur geslaag van kubectl in apiserver. Die ontwikkelaars verduidelik self kortliks hul besluit deur dit te sê kubectl apply - 'n fundamentele deel van die werk met konfigurasies in Kubernetes, egter, "dit is vol foute en moeilik om reg te maak," en daarom moet hierdie funksionaliteit teruggebring word na normaal en oorgedra word na die beheervlak. Eenvoudige en duidelike voorbeelde van probleme wat vandag bestaan:

Kubernetes 1.14: Hoogtepunte van wat nuut is

Besonderhede oor die implementering is in Kep. Huidige gereedheid is alfa (bevordering na beta word vir die volgende Kubernetes-vrystelling beplan).

Beskikbaar gemaak in alfa weergawe geleentheid met behulp van die OpenAPI v3-skema vir skep en publiseer OpenAPI-dokumentasie vir CustomResources (CR) gebruik om (bediener-kant) K8s gebruiker-gedefinieerde hulpbronne te valideer (CustomResourceDefinition, CRD). Publisering van OpenAPI vir CRD laat kliënte toe (bv. kubectl) voer validering aan jou kant uit (binne kubectl create и kubectl apply) en reik dokumentasie uit volgens die skema (kubectl explain). Besonderhede - in Kep.

Vooraf bestaande logs gaan nou oop met vlag O_APPEND (maar nie O_TRUNC) om die verlies van stompe in sommige situasies te vermy en vir die gerief om stompe met eksterne nutsprogramme af te kap vir rotasie.

Ook in die konteks van die Kubernetes API, kan daarop gelet word dat in PodSandbox и PodSandboxStatus bygevoeg gebied runtime_handler inligting oor aan te teken RuntimeClass in die peul (lees meer daaroor in die teks oor Kubernetes 1.12 vrystelling, waar hierdie klas as 'n alfa-weergawe verskyn het), en in Admission Webhooks geïmplementeer vermoë om te bepaal watter weergawes AdmissionReview hulle ondersteun. Uiteindelik is die Admission Webhooks-reëls nou beperk kan word die omvang van hul gebruik deur naamruimtes en groeperingsraamwerke.

Stoorgeriewe

PersistentLocalVolumes, wat sedert vrystelling beta-status gehad het K8s 1.10, aangekondig stabiel (GA): hierdie kenmerkhek is nie meer gedeaktiveer nie en sal in Kubernetes 1.17 verwyder word.

Geleentheid die gebruik van omgewingsveranderlikes genoem Afwaartse API (byvoorbeeld, die pod naam) vir die name van gidse gemonteer as subPath, is ontwikkel - in die vorm van 'n nuwe veld subPathExpr, wat nou gebruik word om die gewenste gidsnaam te bepaal. Die kenmerk het aanvanklik in Kubernetes 1.11 verskyn, maar vir 1.14 het dit in alfa-weergawestatus gebly.

Soos met die vorige Kubernetes-vrystelling, word baie belangrike veranderinge ingestel vir die aktief ontwikkelende CSI (Container Storage Interface):

CSI

Beskikbaar geword (as deel van die alfa-weergawe) ondersteun grootte verander vir CSI-volumes. Om dit te gebruik, sal jy die kenmerkhek wat genoem word, moet aktiveer ExpandCSIVolumes, sowel as die teenwoordigheid van ondersteuning vir hierdie bewerking in 'n spesifieke CSI-bestuurder.

Nog 'n kenmerk vir CSI in die alfa weergawe - geleentheid verwys direk (d.w.s. sonder om PV/PVC te gebruik) na CSI-volumes binne die peulspesifikasie. Hierdie verwyder die beperking op die gebruik van CSI as uitsluitlik afgeleë databerging, wat vir hulle deure na die wêreld oopmaak plaaslike kortstondige volumes. Vir gebruik (voorbeeld uit dokumentasie) moet geaktiveer word CSIInlineVolume kenmerk hek.

Daar was ook vordering in die "internals" van Kubernetes wat verband hou met CSI, wat nie so sigbaar is vir eindgebruikers (stelseladministrateurs) ... Tans word ontwikkelaars gedwing om twee weergawes van elke berging-inprop te ondersteun: een - "in die ou manier”, binne die K8s-kodebasis (in -boom), en die tweede - as deel van die nuwe CSI (lees meer daaroor, byvoorbeeld in hier). Dit veroorsaak verstaanbare ongerief wat aangespreek moet word namate CSI self stabiliseer. Dit is nie moontlik om bloot die API van interne (in-boom) inproppe af te sien nie as gevolg van relevante Kubernetes-beleid.

Dit alles het gelei tot die feit dat die alfa weergawe bereik migrasie proses interne inpropkode, geïmplementeer as in-boom, in CSI-inproppe, waardeur die bekommernisse van ontwikkelaars verminder sal word tot die ondersteuning van een weergawe van hul inproppe, en versoenbaarheid met ou API's sal bly en hulle kan in die gewone scenario as verouderd verklaar word. Daar word verwag dat alle wolkverskaffer-inproppe teen die volgende vrystelling van Kubernetes (1.15) gemigreer sal word, die implementering sal beta-status ontvang en by verstek in K8s-installasies geaktiveer sal word. Vir besonderhede, sien ontwerpvoorstel. Hierdie migrasie het ook tot gevolg gehad mislukking van volumelimiete gedefinieer deur spesifieke wolkverskaffers (AWS, Azure, GCE, Cinder).

Boonop ondersteuning vir bloktoestelle met CSI (CSIBlockVolume) oorgedra na beta weergawe.

Nodes/Kubelet

Alpha weergawe aangebied nuwe eindpunt in Kubelet, ontwerp vir statistieke op sleutelhulpbronne terug te gee. Oor die algemeen, as Kubelet voorheen statistieke oor houergebruik van cAdvisor ontvang het, kom hierdie data nou vanaf die houerlooptydomgewing via CRI (Container Runtime Interface), maar versoenbaarheid om met ouer weergawes van Docker te werk, word ook behou. Voorheen is statistieke wat in Kubelet ingesamel is, via die REST API gestuur, maar nou is 'n eindpunt geleë by /metrics/resource/v1alpha1. Langtermyn strategie van ontwikkelaars bestaan is om die stel metrieke wat deur Kubelet verskaf word, te minimaliseer. Terloops, hierdie statistieke self nou bel hulle nie "kernmetrieke" nie, maar "hulpbronmetrieke", en word beskryf as "eersteklashulpbronne, soos cpu, en geheue".

'n Baie interessante nuanse: ten spyte van die duidelike prestasievoordeel van die gRPC eindpunt in vergelyking met verskeie gevalle van die gebruik van die Prometheus-formaat (sien die resultaat van een van die maatstawwe hieronder), het die skrywers die teksformaat van Prometheus verkies as gevolg van die duidelike leierskap van hierdie moniteringstelsel in die gemeenskap.

“gRPC is nie versoenbaar met groot moniteringspypleidings nie. Eindpunt sal slegs nuttig wees vir die lewering van metrieke aan Metrics Server of monitering van komponente wat direk daarmee integreer. Prometheus-teksformaatprestasie wanneer kasgeheue in Metrics Server gebruik word goed genoeg vir ons om Prometheus bo gRPC te verkies gegewe die wydverspreide aanvaarding van Prometheus in die gemeenskap. Sodra die OpenMetrics-formaat meer stabiel word, sal ons gRPC-prestasie met 'n proto-gebaseerde formaat kan benader."

Kubernetes 1.14: Hoogtepunte van wat nuut is
Een van die vergelykende prestasietoetse van die gebruik van gRPC- en Prometheus-formate in die nuwe Kubelet-eindpunt vir metrieke. Meer grafieke en ander besonderhede kan gevind word in Kep.

Onder ander veranderinge:

  • Kubelet nou (een keer) probeer stop houers in 'n onbekende toestand voor herbegin en verwyder bedrywighede.
  • As u gebruik PodPresets nou na die inithouer word bygevoeg dieselfde inligting as vir 'n gewone houer.
  • kubelet begin gebruik het usageNanoCores van die CRI-statistiekverskaffer, en vir nodusse en houers op Windows bygevoeg netwerkstatistieke.
  • Bedryfstelsel- en argitektuurinligting word nou in etikette aangeteken kubernetes.io/os и kubernetes.io/arch Node-voorwerpe (oorgedra van beta na GA).
  • Vermoë om 'n spesifieke stelselgebruikergroep vir houers in 'n peul te spesifiseer (RunAsGroup, verskyn in K8s 1.11) gevorderd voor beta (by verstek geaktiveer).
  • du en vind gebruik in cAdvisor, vervang on Go implementering.

CLI

In cli-runtime en kubectl bygevoeg -k vlag vir integrasie met pasmaak (terloops, die ontwikkeling daarvan word nou in 'n aparte bewaarplek uitgevoer), d.w.s. om addisionele YAML-lêers vanaf spesiale kustomiseringsgidse te verwerk (vir besonderhede oor die gebruik daarvan, sien Kep):

Kubernetes 1.14: Hoogtepunte van wat nuut is
Voorbeeld van eenvoudige lêergebruik aanpassing ('n meer komplekse toepassing van kustomize is moontlik binne overlays)

Daarbenewens:

  • Bygevoeg nuwe span kubectl create cronjob, wie se naam vanself spreek.
  • В kubectl logs nou kan jy te kombineer vlae -f (--follow vir stroomlogboeke) en -l (--selector vir etiketnavraag).
  • kubectl geleer kopieer lêers wat met wildkaart gekies is.
  • Aan die span kubectl wait bygevoeg vlag --all om alle hulpbronne in die naamruimte van die gespesifiseerde hulpbrontipe te kies.

Ander

Die volgende vermoëns het stabiele (GA) status ontvang:

Ander veranderinge wat in Kubernetes 1.14 ingestel is:

  • Verstek RBAC-beleid laat nie meer API-toegang toe nie discovery и access-review gebruikers sonder verifikasie (ongewaarmerk).
  • Amptelike CoreDNS-ondersteuning verseker Slegs Linux, dus wanneer kubeadm gebruik word om dit (CoreDNS) in 'n cluster te ontplooi, moet nodusse slegs op Linux loop (nodeSelectors word vir hierdie beperking gebruik).
  • Die standaard CoreDNS-opstelling is nou gebruike vorentoe-inprop in plaas van volmag. Ook in CoreDNS bygevoeg gereedheidProbe, wat lasbalansering op toepaslike (nie gereed vir diens nie) peule voorkom.
  • In kubeadm, op fases init of upload-certs, moontlik geword het laai die sertifikate wat nodig is om die nuwe beheervlak aan die kubeadm-certs geheim te koppel (gebruik die vlag --experimental-upload-certs).
  • 'n Alfa-weergawe het vir Windows-installasies verskyn ondersteuning gMSA (Group Managed Service Account) - spesiale rekeninge in Active Directory wat ook deur houers gebruik kan word.
  • Vir G.C.E. geaktiveer mTLS-enkripsie tussen etcd en kube-apiserver.
  • Opdaterings in gebruikte/afhanklike sagteware: Gaan 1.12.1, CSI 1.1, CoreDNS 1.3.1, Docker 18.09-ondersteuning in kubeadm, en die minimum ondersteunde Docker API-weergawe is nou 1.26.

PS

Lees ook op ons blog:

Bron: will.com

Voeg 'n opmerking