Kubernetes 1.16 - hoe om op te gradeer sonder om iets te breek

Vandag, 18 September, word die volgende weergawe van Kubernetes vrygestel - 1.16. Soos altyd wag baie verbeterings en nuwe produkte op ons. Maar ek wil graag jou aandag vestig op die Aksie Vereiste-afdelings van die lêer VERANDERINGSLOG-1.16.md. Hierdie afdelings publiseer veranderinge wat jou toepassing, groeponderhoudnutsmiddels kan breek, of veranderinge aan konfigurasielêers kan vereis.

Oor die algemeen vereis hulle handmatige ingryping ...

Kom ons begin dadelik met 'n verandering wat heel waarskynlik almal sal raak wat lank genoeg met kubernetes werk. Die Kubernetes API ondersteun nie meer verouderde hulpbron-API-weergawes nie.

As iemand nie geweet het of vergeet het nie...Die API-weergawe van die hulpbron word in die manifes in die veld aangedui apiVersion: apps/v1

Naamlik

Hulpbron tipe
ou weergawe
Waarmee vervang moet word

Alle hulpbronne
apps/v1beta1
apps/v1beta2
toepassings/v1

ontplooiings
daemonset
replikaset
uitbreiding/v1beta1
toepassings/v1

netwerkbeleide
uitbreidings/v1beta1
networking.k8s.io/v1

podsekuriteitsbeleide
uitbreidings/v1beta1
beleid/v1beta1

Ek wil ook u aandag daarop vestig dat voorwerpe van tipe Ingress ook verander apiVersion op networking.k8s.io/v1beta1. Ou betekenis extensions/v1beta1 word steeds ondersteun, maar daar is 'n goeie rede om hierdie weergawe terselfdertyd in die manifes op te dateer.

Daar is nogal baie veranderinge in verskeie stelseletikette (Node-etikette) wat op nodusse geïnstalleer is.

Kubelet is verbied om arbitrêre etikette op te stel (voorheen kon dit via bekendstellingsleutels gestel word kubelet --node-labels), hulle het net hierdie lys gelaat toegelaat:

kubernetes.io/hostname
kubernetes.io/instance-type
kubernetes.io/os
kubernetes.io/arch

beta.kubernetes.io/instance-type
beta.kubernetes.io/os
beta.kubernetes.io/arch

failure-domain.beta.kubernetes.io/zone
failure-domain.beta.kubernetes.io/region

failure-domain.kubernetes.io/zone
failure-domain.kubernetes.io/region

[*.]kubelet.kubernetes.io/*
[*.]node.kubernetes.io/*

Tags beta.kubernetes.io/metadata-proxy-ready, beta.kubernetes.io/metadata-proxy-ready en beta.kubernetes.io/kube-proxy-ds-ready word nie meer by nuwe nodusse gevoeg nie, en verskeie bykomende komponente het effens verskillende etikette as noduskiesers begin gebruik:

komponent
Ou etiket
Huidige etiket

kube-proxy
beta.kubernetes.io/kube-proxy-ds-ready
node.kubernetes.io/kube-proxy-ds-ready

ip-masker-agent
beta.kubernetes.io/masq-agent-ds-ready
node.kubernetes.io/masq-agent-ds-ready

metadata-instaanbediener
beta.kubernetes.io/metadata-proxy-ready
cloud.google.com/metadata-proxy-ready

kubeadm verwyder nou die aanvanklike kublet-konfigurasielêer daaragter bootstrap-kubelet.conf. As jou gereedskap toegang tot hierdie lêer gehad het, skakel dan oor na gebruik kubelet.conf, wat huidige toeganginstellings stoor.

Cadvisor verskaf nie meer statistieke nie pod_name и container_nameas jy dit in Prometheus gebruik het, gaan na metrieke pod и container onderskeidelik.

Het die sleutels verwyder met die lynopdrag:

komponent
Ingetrekte sleutel

hiperkube
--maak-simbool

kube-proxy
--hulpbronhouer

Die skeduleerder het weergawe v1beta1 van die Event API begin gebruik. As jy derdepartynutsgoed gebruik om met die Event API te kommunikeer, skakel oor na die nuutste weergawe.

’n Oomblik van humor. Tydens die voorbereiding van vrystelling 1.16 is die volgende veranderinge aangebring:

• het die aantekening verwyder scheduler.alpha.kubernetes.io/critical-pod in weergawe v1.16.0-alpha.1
• het die aantekening teruggestuur scheduler.alpha.kubernetes.io/critical-pod in weergawe v1.16.0-alpha.2
• het die aantekening verwyder scheduler.alpha.kubernetes.io/critical-pod in weergawe v1.16.0-beta.1

Gebruik die veld spec.priorityClassName om die belangrikheid van die peul aan te dui.

Bron: will.com