Ĉi-nokte sekva eldono de Kubernetes - . Laŭ la tradicio, kiu disvolviĝis por nia blogo, ni parolas pri la ŝlosilaj ŝanĝoj en la nova versio de ĉi tiu mirinda Malfermkoda produkto.
Informoj uzataj por prepari ĉi tiun materialon estas prenita de , kaj rilataj aferoj, tirpetoj, Kubernetes Enhancement Proposals (KEP).
Ni komencu per grava enkonduko de SIG-grupo-vivciklo: dinamikaj malsukcesaj aretoj Kubernetes (aŭ por esti pli preciza, mem-gastigitaj HA-deplojoj) nun estas uzante konatajn (en la kunteksto de unu-nodaj aretoj) komandojn kubeadm (init и join). Resume, por ĉi tio:
- atestiloj uzataj de la areto estas transdonitaj al sekretoj;
- por la ebleco uzi la etcd-areton ene de la K8s-areto (t.e. forigi la antaŭe ekzistantan eksteran dependecon) ;
- Dokumentas la rekomenditajn agordojn por ekstera ŝarĝbalancilo, kiu provizas misfunkcian agordon (en la estonteco oni planas forigi ĉi tiun dependecon, sed ne en ĉi tiu etapo).
Arkitekturo de Kubernetes HA-areto kreita kun kubeadm
Detaloj pri la efektivigo troveblas en . Ĉi tiu funkcio estis vere longe atendita: la alfa versio estis atendita reen en K8s 1.9, sed nur aperis nun.
API
teamo apply kaj ĝenerale parolante deklara objekta administrado el kubectl en apiserver. La programistoj mem mallonge klarigas sian decidon dirante tion kubectl apply - fundamenta parto de laboro kun agordoj en Kubernetes, tamen, "ĝi estas plena de eraroj kaj malfacile riparebla," kaj tial ĉi tiu funkcio devas esti normaligita kaj transdonita al la kontrolaviadilo. Simplaj kaj klaraj ekzemploj de problemoj kiuj ekzistas hodiaŭ:
Detaloj pri la efektivigo estas en . Nuna preteco estas alfa (promocio al betao estas planita por la venonta eldono de Kubernetes).
Disponebla en alfa versio uzante la OpenAPI v3-skemon por kreante kaj publikigante OpenAPI-dokumentadon por CustomResources (CR) uzata por validigi (servilo-flanko) K8s uzant-difinitajn rimedojn (CustomResourceDefinition, CRD). Eldonado de OpenAPI por CRD permesas klientojn (ekz. kubectl) plenumi validumon sur via flanko (ene de kubectl create и kubectl apply) kaj eldonu dokumentadon laŭ la skemo (kubectl explain). Detaloj - en .
Antaŭekzistantaj ŝtipoj kun flago O_APPEND (sed ne O_TRUNC) por eviti perdon de ŝtipoj en iuj situacioj kaj por la komforto de detranĉi ŝtipojn kun eksteraj utilecoj por rotacio.
Ankaŭ en la kunteksto de la Kubernetes API, oni povas rimarki, ke en PodSandbox и PodSandboxStatus kampo runtime_handler registri informojn pri RuntimeClass en la pod (legu pli pri ĝi en la teksto pri , kie ĉi tiu klaso aperis kiel alfa versio), kaj en Admission Webhooks kapablo determini kiuj versioj AdmissionReview ili subtenas. Finfine, la reguloj de Admission Webhooks nun estas la amplekso de ilia uzo de nomspacoj kaj aretkadroj.
Volboj
, kiu havis beta-statuson ekde liberigo , stabila (GA): ĉi tiu funkcio pordego ne plu estas malŝaltita kaj estos forigita en Kubernetes 1.17.
uzante mediovariablojn nomitajn (ekzemple, la podnomo) por la nomoj de dosierujoj muntitaj kiel , estis evoluigita - en la formo de nova kampo subPathExpr, kiu nun estas uzata por determini la deziratan dosierujon. La funkcio komence aperis en Kubernetes 1.11, sed por 1.14 ĝi restis en alfa versio statuso.
Kiel ĉe la antaŭa eldono de Kubernetes, multaj signifaj ŝanĝoj estas enkondukitaj por la aktive evoluanta CSI (Uja Stokado-Interfaco):
CSI
Fariĝis havebla (kiel parto de la alfa-versio) regrandigi por CSI-volumoj. Por uzi ĝin, vi devos ebligi la ĉefpordegon nomitan ExpandCSIVolumes, same kiel la havebleco de subteno por ĉi tiu operacio en specifa CSI-ŝoforo.
Alia funkcio por CSI en la alfa versio - rilati rekte (t.e. sen uzado de PV/PVC) al CSI-volumoj ene de la podspecifo. Ĉi tio forigas la restrikton pri la uzo de CSI kiel ekskluzive fora datumstokado, malfermante pordojn al la mondo por ili . Por uzo () devas esti ebligita CSIInlineVolume trajtopordego.
Ankaŭ estis progreso en la "internoj" de Kubernetes rilataj al CSI, kiuj ne estas tiel videblaj por finaj uzantoj (sistemaj administrantoj) ... Nuntempe, programistoj estas devigitaj subteni du versiojn de ĉiu stokada kromaĵo: unu - "en la malnova maniero", ene de la K8s-kodbazo (en -arbo), kaj la dua - kiel parto de la nova CSI (legu pli pri ĝi, ekzemple, en ). Ĉi tio kaŭzas kompreneblajn ĝenojn, kiujn oni devas trakti dum CSI mem stabiligas. Ne eblas simple malrekomendi la API de internaj (en-arbaj) kromaĵojn pro .
Ĉio ĉi kondukis al la fakto, ke la alfa versio atingis interna kromaĵokodo, efektivigita kiel en-arbo, en CSI-kromaĵoj, dank'al kiuj la zorgoj de programistoj estos reduktitaj al subteno de unu versio de siaj kromaĵoj, kaj kongruo kun malnovaj API-oj restos kaj ili povas esti deklaritaj malnoviĝintaj en la kutima scenaro. Estas atendite, ke antaŭ la venonta eldono de Kubernetes (1.15) ĉiuj nubaj provizantaj kromprogramoj estos migritaj, la efektivigo ricevos beta-statuson kaj estos aktivigita en K8s-instalaĵoj defaŭlte. Por detaloj, vidu . Ĉi tiu migrado ankaŭ rezultigis de volumenaj limoj difinitaj de specifaj nubaj provizantoj (AWS, Azure, GCE, Cinder).
Aldone, subteno por blokaj aparatoj kun CSI (CSIBlockVolume) al beta versio.
Nodoj/Kubelet
Alpha versio prezentita en Kubelet, desegnita por resendi metrikojn pri ŝlosilaj rimedoj. Ĝenerale, se antaŭe Kubelet ricevis statistikojn pri uzado de uzado de cAdvisor, nun ĉi tiuj datumoj venas de la uja rultempa medio per CRI (Container Runtime Interface), sed kongruo por labori kun pli malnovaj versioj de Docker ankaŭ estas konservita. Antaŭe, statistikoj kolektitaj en Kubelet estis senditaj per la REST API, sed nun finpunkto situanta ĉe /metrics/resource/v1alpha1. Longtempa strategio de programistoj estas minimumigi la aron de metrikoj provizitaj de Kubelet. Parenteze, ĉi tiuj metrikoj mem ne "kernmetriko", sed "rimedometriko", kaj estas priskribitaj kiel "unuaklasaj rimedoj, kiel ekzemple cpu, kaj memoro".
Tre interesa nuanco: malgraŭ la klara rendimenta avantaĝo de la gRPC-finpunkto kompare kun diversaj kazoj de uzado de la formato Prometheus (vidu la rezulton de unu el la komparnormoj malsupre), la aŭtoroj preferis la tekstan formaton de Prometeo pro la klara gvidado de ĉi tiu monitora sistemo en la komunumo.
"gRPC ne kongruas kun ĉefaj monitoraj duktoj. Finpunkto nur estos utila por liveri metrikojn al Metrics Server aŭ monitori komponantojn, kiuj integriĝas rekte kun ĝi. Prometheus-teksta formato-rendimento kiam vi uzas kaŝmemoron en Metrics Server sufiĉe bona por ke ni preferu Prometheus super gRPC pro la ĝeneraligita adopto de Prometheus en la komunumo. Post kiam la OpenMetrics-formato fariĝos pli stabila, ni povos alproksimiĝi al gRPC-agado kun prabazita formato."
Unu el la komparaj agadotestoj de uzado de gRPC kaj Prometheus-formatoj en la nova Kubelet-finpunkto por metrikoj. Pli da grafikaĵoj kaj aliaj detaloj troveblas en .
Inter aliaj ŝanĝoj:
- Kubelet nun (unufoje) ujoj en nekonata stato antaŭ rekomenci kaj forigi operaciojn.
- Kiam vi uzas nun al la init-ujo la samaj informoj kiel por regula ujo.
- kubelet
usageNanoCoresde la provizanto de statistikoj de CRI, kaj por nodoj kaj ujoj en Vindozo retaj statistikoj. - Informoj pri operaciumo kaj arkitekturo nun estas registritaj en etikedoj
kubernetes.io/osиkubernetes.io/archNodaj objektoj (transdonitaj de beta al GA). - Kapablo specifi specifan sisteman uzantgrupon por ujoj en pod (
RunAsGroup, aperis en ) antaŭ beta (aktivigita defaŭlte). - du kaj trovi uzata en cAdvisor, on Go efektivigo.
CLI
En cli-runtime kaj kubectl -k flago por integriĝo kun (cetere, ĝia evoluo nun efektiviĝas en aparta deponejo), t.e. por prilabori pliajn YAML-dosierojn de specialaj kustomigdosierujoj (por detaloj pri uzado de ili, vidu ):
Ekzemplo de simpla dosieruzado (pli kompleksa apliko de kustomize estas ebla ene )
Krome:
- nova teamo
kubectl create cronjob, kies nomo parolas por si mem. - В
kubectl logsnun vi povas flagoj-f(--followpor streaming protokoloj) kaj-l(--selectorpor etikeddemando). - kubectl kopiu dosierojn elektitajn per ĵokero.
- Al la teamo
kubectl waitflago--allelekti ĉiujn rimedojn en la nomspaco de la specifita rimeda tipo.
Aliaj
La sekvaj kapabloj ricevis stabilan (GA) statuson:
- , uzita en la podspecifo por difini kromajn kondiĉojn enkalkulitajn en la preteco de la balgo;
- Subteno por grandaj paĝoj (trajtopordego nomata );
- ;
- PriorityClass API .
Aliaj ŝanĝoj enkondukitaj en Kubernetes 1.14:
- Defaŭlta RBAC-politiko ne plu permesas API-aliron
discoveryиaccess-reviewuzantoj sen aŭtentigo (neaŭtentikigita). - Oficiala CoreDNS-subteno Linukso nur, do kiam oni uzas kubeadm por deploji ĝin (CoreDNS) en areto, nodoj devas nur funkcii per Linukso (nodeSelectors estas uzataj por ĉi tiu limigo).
- Defaŭlta CoreDNS-agordo nun estas anstataŭ prokurilo. Ankaŭ, en CoreDNS ReadinessProbe, kiu malhelpas ŝarĝan ekvilibron sur taŭgaj (ne pretaj por servo) podoj.
- En kubeadm, sur fazoj
initaŭupload-certs, ŝarĝu la atestojn necesajn por konekti la novan kontrolaviadilon al la sekreto kubeadm-certs (uzu la flagon--experimental-upload-certs). - Alfa versio aperis por Vindozaj instalaĵoj gMSA (Group Managed Service Account) - specialaj kontoj en Active Directory, kiuj ankaŭ povas esti uzataj per ujoj.
- Por G.C.E. mTLS-ĉifrado inter etcd kaj kube-apiserver.
- Ĝisdatigoj en uzata/dependa programaro: Iru 1.12.1, CSI 1.1, CoreDNS 1.3.1, Docker 18.09-subteno en kubeadm, kaj la minimuma subtenata Docker API-versio nun estas 1.26.
PS
Legu ankaŭ en nia blogo:
- «»;
- «»;
- «»;
- «".
fonto: www.habr.com