Sellel ööl järgmine Kubernetes'i väljaanne — . Nagu meie blogi tavaks on, räägime uusversiooni peamistest muudatustest selles suurepärases avatud lähtekoodiga tootes.
Selle materjali koostamiseks kasutatud teave on saadud , ja vastavatest probleemidest, tõmbenumbrist, Kubernetes'i täiustuste ettepanekutest (KEP).
Alustame olulise sissejuhatusega SIG cluster-lifecycle'ilt: dünaamilised tõrkeotsimise klastrid Kuberneteses (või õigemini, self-hosted HA paigutustes) saab nüüd tavapäraste (ühe sõlme klastrite kontekstis) käskudega kubeadm (— algne ettevalmistus enne juurutamist, siin võib olla kõike: sõltuvuste allalaadimist, saladuste lahtipakkimist ja muud. ja join). Ühesõnaga, selleks:
- kasutatud klastri sertifikaadid kantakse üle saladustesse;
- klastri etcd kasutamiseks K8s-klastris (st välisest sõltuvusest vabanemiseks) on kaasatud ;
- dokumenteeritakse soovitatud seadistused väliseks koormuse tasakaalustajaks, mis tagab tõrkekindla konfiguratsiooni (edasi on plaanis vabaneda ka neist sõltuvustest, kuid mitte praegu).
Kubeadm'iga loodud HA-klastri arhitektuur
Rakenduse üksikasjadega saab tutvuda . See funktsioon oli tõeliselt oodatud: alfa-versiooni oodati juba K8s 1.9, kuid see ilmus alles nüüd.
API
Meeskond apply ja üldiselt deklaratiivne haldamine objektide API-s kubectl apiserverisse. Arendajad seletavad oma otsust lühidalt, et kubectl apply — põhiosa Kubernetes'i konfiguratsioonidega töötamisest, kuid siiski «täis vigu ja keeruline parandamiseks», mistõttu tuleb see funktsionaalsus viia normi ja üle kanda juhtimiskihti. Lihtsad ja ilmne probleemide näited:
Täpsemad rakenduse üksikasjad — . Aktuaalne olek — alfa-versioon (edasi liikumine beeta on planeeritud järgmise Kubernetes'i väljaande jaoks).
Alfa-versioonis sai kätte kasutada OpenAPI v3 skeemi CustomResources'i OpenAPI-dokumentatsiooni loomisel ja avaldamisel (CR), mida kasutatakse K8s'i kasutaja määratud ressursside valideerimiseks (CustomResourceDefinition, CRD). CRD OpenAPI avaldamine võimaldab klientidel (näiteks kubectl) teha valideerimist oma poolse (kubectl create'i lõpetamisel ) ja välja anda skeemi dokumentatsiooni ( ja kubectl applykubectl selgitada)). Üksikasjad — .
Varasemad logid lipuga O_APPEND (mitte O_TRUNC) logide kaotsimine vältimise ja väliste logide rotatsiooni utiliitide mugavuse huvides.
Samuti Kubernetes API kontekstis võib märkida, et PodSandbox ja PodSandboxStatus välja runtime_handler info arvestamiseks RuntimeClass podis (lisainfot leiate Kubernetes 1.12 võimaluse määrata, millised versioonid AdmissionReview nad toetavad. Lõpuks, Admissions Webhookide reeglites on nüüd võimalik piirata Salvestamisruumid
, mis olid beetaversioonis alates
K8s 1.10 , keskkonnamuutujate kasutamisega, mida tuntakse kui
Downward API subPath subPathExpr , mille abil määratakse nüüd sobiv kausta nimi. See funktsioon ilmus algselt Kubernetes 1.11, kuid jäi ka 1.14 alfa-versiooniks.Nagu ka eelmises Kubernetes väljaandes, on aktiivselt arenevale CSI (Container Storage Interface) esitatud palju olulisi muudatusi:
CSI
on nüüd saadaval (alfa-versioonis)
CSI-mahuttonide suuruse muutmine . Selle kasutamiseks peab olema lubatud funktsioonigaExpandCSIVolumes , samuti peab vastav CSI-juht tooma selle toimingu toe.Veel üks alfa-versiooni funktsioon CSI jaoks —
viidata otse (st ilma PV/PVC kasutamata) CSI-mahuttonidele podide spetsifikatsioonis. See eemaldab piirangu kasutada CSI-d ainult kaugel asuvate andmesalvestusseadmetena, avades neile ukse kohalikesse ajutistesse mahtudesse.Kasutamiseks ( ) peab olema lubatudfunktsioon. Kubernetes „sisemustes“, mis on seotud CSI-ga, on edusamme, mis tasapisi ei paista lõppkasutajatele (süsteemiadministraatoritele)... Praegu peavad arendajad toetama iga salvestusploki kahte versiooni: üks — „vana stiiliga“ K8si koodibaasis (in-tree), ja teine — uue CSI raames. (lisainfot leiate näiteks)
Kubernetes'i CSI ga seotud "siseküljed" on teinud edusamme, mis ei pruugi lõppkasutajatele (süsteemiadministraatoritele) kohe silma paista... Praeguseks peavad arendajad toetama iga salvestusplugina kahte versiooni: ühe — "vana," K8s'i koodibaasis (in-tree) ja teise — uue CSI raames. (rohkem selle kohta loe näiteks siin, ). See, et tekitab arusaadavaid ebamugavusi, mida tuleb kõrvaldatud, kui CSI stabiliseerub. Sisemiste pluginade deklareerimine vananenuks ei ole lihtsalt võimalik. .
Kõik see viis selleni, et alfa-versioonid on saavutanud sisemiste pluginade koodi, mis on rakendatud kui in-tree, CSI pluginad, mille tõttu arendajate mured vähenevad ühe versiooni oma pluginade toetamisega, samas kui ühilduvus vanade API-dega säilib ja need saab deklareerida vananenuks tavapärase stsenaariumi kohaselt. Oodatakse, et järgmise Kubernetes'i versiooni (1.15) puhul toimub kõikide pilveteenuse pakkujate pluginade migratsioon, rakendamine saab beetaversiooni staatuse ja see aktiveeritakse K8si installides vaikimisi. Lisainfot leiate . Selle migratsiooni tulemuseks on ka piirangutest, mis on määratletud konkreetsete pilveteenuse pakkujate (AWS, Azure, GCE, Cinder) poolt.
Lisaks sellele on toetatud blokiseadmeid CSI-ga (CSIBlockVolume) beetaversiooniks.
Sõlmed / Kubelet
Alfa-versioon uue endpoint'i kohta peamiste ressursside statistikate edastamiseks. . Üldiselt, kui varem Kubelet sai konteinerite kasutusstatistikat cAdvisor'ist, siis nüüd tulevad andmed konteineri täitmiselt CRI (Container Runtime Interface) kaudu, kuid säilib ka ühilduvus vanade Docker'i versioonidega. Varem Kubeleti kogutud statistika anti välja läbi REST API, nüüd kasutatakse selleks endpointi, mis asub aadressil. Pikemaajaline strateegia arendajate jaoks /metrics/resource/v1alpha1on vähendada Kubelet'i pakutavate statistikate hulka. selle eesmärk. Muide, neid statistikaid mitte "core metrics", vaid "resource metrics", ja need kirjeldavad kui "first-class resources, such as cpu and memory".
Väga huvitav nüanss: hoolimata gRPC endpoint'i selgest jõudlusest võrreldes erinevate Prometheuse vormingu kasutusjuhtumitega, (üks benchmark tulemusi vaata allpool), eelistasid autorid tekstivormingut Prometheus, kuna see süsteem on jälgimise kogukonnas selgelt juhtpositsioonil.
gRPC ei ühildu peamiste jälgimisprotsessidega. Endpoint on kasulik ainult meetrite edastamiseks Metrics Serverisse või jälgimiskomponentidesse, mis integreeruvad otse selle sisse. Caching'i kasutamisel Metrics Serveris on Prometheuse tekstivormingu jõudlus piisavalt hea meie jaoks, et eelistada Prometheust gRPC-le, arvestades Prometheuse laialdast kasutust kogukonnas. Kui OpenMetricsi formaat muutub stabiilsemaks, saame saavutada gRPC jõudluse proto-põhise formaadiga.
Üks võrdluskatsetest gRPC ja Prometheuse formaatide jõudluse kasutamisest uues Kubeleti endpoint'is meetrite jaoks. Rohkem graafikuid ja muid üksikasju leiate .
Muude muudatuste seas:
- Kubelet proovib nüüd (ühe korra) tunmatutes (unknown) olekutes konteinerid enne taaskäivitamise ja kustutamise operatsioone.
- Kasutades lisatakse nüüd init-konteinerile Kubelet
- on hakanud kasutama
CRI statistikapakkujast, ja Windowsis node'ide ning konteinerite jaoksvõrgustatistika. Operatsioonisüsteemi ja arhitektuuri teave salvestatakse nüüd siltidesse - kubernetes.io/os
kubernetes.io/archjaNode'i objektidesse (ümber tõlgitud beetast GA-ks).Võimalus määrata konkreetne kasutajagrupp konteineritele pod'is ( - RunAsGroup
, on saanud kättesaadavaksK8s 1.11 ) du ja find, mida kasutatakse cAdvisoris, - asendatakse CLI
cli-runtime'is ja kubectl'is
lipp -k integreerimiseks (muide, selle arendamine käib nüüd eraldi repos), st spetsiaalsetest kustomizatsiooni kataloogidest lisainfos YAML-failide töötlemiseks (kasutamise üksikasjad leiate Näide lihtsast kustomization faili kasutamisest ):
(võimalik, et ka keerukam kustomize rakendamine overlays raames. uus käsk )
, mille nimi räägib enda eest.
- kubectl logs
on nüüd võimalikühendada - Uues
lipud--follow -l-f(--selectorlabel query jaoks).õpivad(kopeerima faile, mis valitakse wild card'i abil.Käsk - kubectl lipp
- --all
kõigi määratud ressursitüübiga ressursside valimiseks nimedesse.TeisedStabiilne (GA) staatus saadud järgmised võimalused:ReadinessGate
Teised
Stabiilne (GA) staatus on saanud järgmised võimalused:
- , mida kasutatakse pod'i spetsifikatsioonis, et määratleda täiendavad tingimused, mida arvesse võtta pod'i valmiduses;
- Suurte lehtede tugi (funktsioonigate nimega );
- ;
- PriorityClass API, .
Teised muudatused, mis on esitatud Kubernetes 1.14-s:
- Vaikimisi RBAC poliitika ei paku enam juurdepääsu API-le
discoveryjaaccess-reviewkasutajatele, kellel ei ole autentimist (unauthenticated). - CoreDNS ametlik tugi ainult Linuxile, seega peab kubeadm-i kasutamisel selle (CoreDNS) juurutamiseks klastris töötama ainult Linux (selle piirangu jaoks kasutatakse nodeSelectors).
- CoreDNS vaikimisi konfiguratsioon on nüüd asetamine proxy. Lisaks, CoreDNS-i readinessProbe, mis takistab koormuse tasakaalustamist vastavatesse (teenindamiseks mittevalmid) pod'idesse.
- Kubeadm-is, etappidel
— algne ettevalmistus enne juurutamist, siin võib olla kõike: sõltuvuste allalaadimist, saladuste lahtipakkimist ja muud.võiupload-certs, laadida sertifikaadid, mida on vaja uue control-plane'i ühendamiseks kubeadm-certs saladusega (kasutatakse lippu--experimental-upload-certs). - Windowsi installatsioonide jaoks on saadaval alfa-versioon gMSA (Group Managed Service Account) — spetsiaalsed kontod Active Directory-s, mida saavad kasutada ka konteinerid.
- GCE jaoks mTLS-krüpteerimine etcd ja kube-apiserveri vahel.
- Uuendused kasutatavates/sõltuvates tarkvarades: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, Docker 18.09 tugi kubeadm-is, ning minimaalne toetatud Docker API versioon on nüüd 1.26.
P.S.
Lugege ka meie blogist:
- «»;
- «»;
- «»;
- «».
Allikas: habr.com
