🥇Kubernetes 1.17: pangkalahatang-ideya ng mga pangunahing inobasyon

Kahapon, Disyembre 9, naganap susunod na paglabas ng Kubernetes - 1.17. Ayon sa tradisyon na binuo para sa aming blog, pinag-uusapan namin ang tungkol sa mga pinaka makabuluhang pagbabago sa bagong bersyon.

Ang impormasyong ginamit sa paghahanda ng materyal na ito ay kinuha mula sa opisyal na anunsyo, Mga talahanayan ng pagsubaybay sa mga pagpapahusay ng Kubernetes, CHANGELOG-1.17 at mga kaugnay na isyu, pull request, at Kubernetes Enhancement Proposals (KEP). Ano'ng Bago?..

Topology-aware na pagruruta

Matagal nang hinihintay ng komunidad ng Kubernetes ang tampok na ito - Topology-aware service routing. Kung KEP ito ay nagmula sa Oktubre 2018, at ang opisyal Pagpapahusay — 2 taon na ang nakalipas, ang mga karaniwang isyu (gaya ng ito) - at mas matanda pa ng ilang taon...

Ang pangkalahatang ideya ay magbigay ng kakayahang magpatupad ng "lokal" na pagruruta para sa mga serbisyong naninirahan sa Kubernetes. "Lokalidad" sa kasong ito ay nangangahulugang "parehong topological na antas" (antas ng topology), na maaaring:

magkapareho ang node para sa mga serbisyo,
ang parehong rack ng server,
ang parehong rehiyon
ang parehong cloud provider,
...

Mga halimbawa ng paggamit ng feature na ito:

pagtitipid sa trapiko sa mga pag-install ng cloud na may maraming availability zone (multi-AZ) - tingnan. bagong ilustrasyon gamit ang halimbawa ng trapiko mula sa parehong rehiyon, ngunit magkaibang mga AZ sa AWS;
mas mababang performance latency/mas mahusay na throughput;
isang sharded na serbisyo na mayroong lokal na impormasyon tungkol sa node sa bawat shard;
paglalagay ng fluentd (o mga analogue) sa parehong node kasama ang mga application na ang mga log ay kinokolekta;
...

Ang ganitong pagruruta, na "alam" tungkol sa topology, ay tinatawag ding network affinity - sa pamamagitan ng pagkakatulad sa pagkakaugnay ng node, pod affinity/anti-affinity o nagpakita hindi pa katagal Pag-iiskedyul ng Dami ng Topology-Aware (at Pagbibigay ng Dami). Kasalukuyang antas ng pagpapatupad ServiceTopology sa Kubernetes - alpha na bersyon.

Para sa mga detalye kung paano gumagana ang feature at kung paano mo ito magagamit, basahin artikulong ito mula sa isa sa mga may-akda.

IPv4/IPv6 dual stack na suporta

Makabuluhang pag-unlad nakapirming sa isa pang feature ng network: sabay-sabay na suporta para sa dalawang IP stack, na unang ipinakilala sa K8s 1.16. Sa partikular, ang bagong release ay nagdala ng mga sumusunod na pagbabago:

sa kube-proxy ipinatupad posibilidad ng sabay-sabay na operasyon sa parehong mga mode (IPv4 at IPv6);
в Pod.Status.PodIPs lumitaw suporta para sa pababang API (kasabay ng sa /etc/hosts ngayon kailangan nila ang host na magdagdag ng IPv6 address);
dual stack na suporta KIND (Kubernetes IN Docker) at kubeadm;
na-update na mga pagsubok sa e2e.

Guhit gamit ang dual stack IPV4/IPv6 sa KIND

Pag-unlad sa CSI

Idineklara na stable suporta sa topology para sa CSI-based na storage, unang ipinakilala noong K8s 1.12.

Inisyatiba para sa paglipat ng mga volume plugin sa CSI - CSI Migration - naabot ang beta na bersyon. Ang tampok na ito ay kritikal upang maisalin ang mga umiiral nang plugin ng storage (sa-puno) sa isang modernong interface (CSI, wala sa puno) hindi nakikita ng mga end user ng Kubernetes. Kakailanganin lamang ng mga administrator ng cluster na i-enable ang CSI Migration, pagkatapos nito ay magpapatuloy na "gumagana lang" ang mga umiiral nang stateful na mapagkukunan at workload... ngunit gumagamit ng mga pinakabagong driver ng CSI sa halip na ang mga luma na kasama sa core ng Kubernetes.

Sa ngayon, handa na ang paglipat para sa mga driver ng AWS EBS sa beta na bersyon (kubernetes.io/aws-ebs) at GCE PD (kubernetes.io/gce-pd). Ang mga pagtataya para sa iba pang pasilidad ng imbakan ay ang mga sumusunod:

Pinag-usapan namin kung paano napunta sa CSI ang "tradisyonal" na suporta sa storage sa K8s artikulong ito. At ang paglipat ng CSI migration sa beta status ay nakatuon sa hiwalay na publikasyon sa blog ng proyekto.

Bilang karagdagan, ang isa pang makabuluhang functionality sa konteksto ng CSI, na nagmula (implementasyon ng alpha) sa K1.17s 8, ay umabot sa beta status (ibig sabihin, naka-enable bilang default) sa Kubernetes 1.12 release - paggawa ng mga snapshot at pagbawi mula sa kanila. Kabilang sa mga pagbabagong ginawa sa Kubernetes Volume Snapshot sa daan patungo sa beta release:

hinahati ang CSI external-snapshotter sidecar sa dalawang controllers,
nagdagdag ng lihim para sa pagtanggal (lihim sa pagtanggal) bilang isang anotasyon sa mga nilalaman ng isang snapshot ng volume,
bagong finalizer (finalizer) upang maiwasang matanggal ang snapshot API object kung may mga natitirang koneksyon.

Sa panahon ng paglabas 1.17, ang feature ay sinusuportahan ng tatlong CSI driver: GCE Persistent Disk CSI Driver, Portworx CSI Driver at NetApp Trident CSI Driver. Higit pang mga detalye tungkol sa pagpapatupad at paggamit nito ay matatagpuan sa ang publikasyong ito sa blog.

Mga Label ng Cloud Provider

Mga label na awtomatikong itinalaga sa mga nilikhang node at volume depende sa cloud provider na ginamit, ay magagamit sa Kubernetes bilang isang beta na bersyon sa napakatagal na panahon - mula nang ilabas ang K8s 1.2 (Abril 2016!). Dahil sa kanilang malawakang paggamit sa napakatagal na panahon, ang mga developer nagpasya, na oras na para ideklara ang feature na stable (GA).

Samakatuwid, lahat sila ay pinalitan ng pangalan nang naaayon (sa pamamagitan ng topology):

beta.kubernetes.io/instance-type → node.kubernetes.io/instance-type
failure-domain.beta.kubernetes.io/zone → topology.kubernetes.io/zone
failure-domain.beta.kubernetes.io/region → topology.kubernetes.io/region

... ngunit magagamit pa rin sa ilalim ng kanilang mga lumang pangalan (para sa pabalik na pagkakatugma). Gayunpaman, inirerekomenda ang lahat ng mga administrator na lumipat sa mga kasalukuyang label. Kaugnay na Dokumentasyon Na-update na ang K8s.

Nakabalangkas na output ng kubeadm

Itinanghal sa alpha na bersyon sa unang pagkakataon nakabalangkas na output para sa kubeadm utility. Mga sinusuportahang format: JSON, YAML, Go template.

Pagganyak para sa pagpapatupad ng tampok na ito (ayon sa KEP) ay:

Bagama't maaaring manu-manong i-deploy ang Kubernetes, ang de facto (kung hindi de jure) na pamantayan para sa operasyong ito ay ang paggamit ng kubeadm. Ang mga sikat na tool sa pamamahala ng system tulad ng Terraform ay umaasa sa kubeadm para sa pag-deploy ng Kubernetes. Kasama sa mga nakaplanong pagpapahusay sa Cluster API ang isang composable package para sa Kubernetes bootstrapping na may kubeadm at cloud-init.

Kung walang structured na output, kahit na ang pinaka-hindi nakakapinsalang mga pagbabago sa unang tingin ay maaaring masira ang Terraform, Cluster API at iba pang software na gumagamit ng mga resulta ng kubeadm.

Kasama sa aming mga agarang plano ang suporta (sa anyo ng structured na output) para sa mga sumusunod na kubeadm command:

alpha certs
config images list
init
token create
token list
upgrade plan
version

Ilustrasyon ng isang tugon ng JSON sa isang utos kubeadm init -o json:

{
  "node0": "192.168.20.51:443",
  "caCrt": "sha256:1f40ff4bd1b854fb4a5cf5d2f38267a5ce5f89e34d34b0f62bf335d74eef91a3",
  "token": {
    "id":          "5ndzuu.ngie1sxkgielfpb1",
    "ttl":         "23h",
    "expires":     "2019-05-08T18:58:07Z",
    "usages":      [
      "authentication",
      "signing"
    ],
    "description": "The default bootstrap token generated by 'kubeadm init'.",
    "extraGroups": [
      "system:bootstrappers:kubeadm:default-node-token"
    ]
  },
  "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c="
}

Pagpapatatag ng iba pang mga pagbabago

Sa pangkalahatan, ang paglabas ng Kubernetes 1.17 ay naganap sa ilalim ng motto na "Katatagan" Ito ay pinadali ng katotohanan na maraming mga tampok sa loob nito (ang kanilang kabuuang bilang ay 14) nakatanggap ng status ng GA. Sa kanila:

"pagmamarka" ng mga node ayon sa ilang mga kundisyon (TaintNodesByCondition), lumabas sa K8s 1.8;
Manood ng Mga Bookmark - isang bagong uri ng mga kaganapan na may label na ang lahat ng mga bagay ay hanggang sa isang tiyak na bersyon (resourceVersion) ay naproseso na ng relo;
mga default na halaga (defaulting) para sa Custom Resources;
ibinahagi sa pagitan ng mga lalagyan sa pod process namespaces;
ScheduleDaemonSetPods - pag-iskedyul ng mga pod sa DaemonSet gamit ang kube-scheduler (sa halip na ang DaemonSet controller);
mga dynamic na limitasyon sa bilang ng mga volume depende sa uri ng node;
suporta sa variable ng kapaligiran para sa mga pangalan ng direktoryo na naka-mount bilang subPath;
Kubelet heartbeats transfer sa isang espesyal na Lease API;
"proteksyon ng finalizer" (Proteksyon ng Finalizer) para sa mga load balancer (pagsusuri sa kaukulang mga mapagkukunan ng Serbisyo bago tanggalin ang mga mapagkukunan ng LoadBalancer);
pag-optimize ng kube-apiserver sa pagganap kapag nagtatrabaho sa maraming mga relo na sinusubaybayan ang magkatulad na hanay ng mga bagay - nakakamit sa pamamagitan ng pag-iwas sa paulit-ulit na serialization ng parehong mga bagay para sa bawat watcher.

Iba pang mga pagbabago

Ang buong listahan ng mga inobasyon sa Kubernetes 1.17, siyempre, ay hindi limitado sa mga nakalista sa itaas. Narito ang ilang iba pa (at para sa mas kumpletong listahan, tingnan CHANGELOG):

Ang feature na ipinakita sa huling release ay umabot na sa beta na bersyon RunAsUserName para sa windows;
katulad na pagbabago nangyari EndpointSlice API (mula rin sa K8s 1.16), gayunpaman, sa ngayon, hindi pinagana bilang default ang solusyong ito para mapahusay ang performance/scalability ng Endpoint API;
Ang mga pod ay kritikal na ngayon para sa operasyon ng cluster maaaring malikha hindi lamang sa mga namespace kube-system (para sa mga detalye, tingnan ang dokumentasyon para sa Limitahan ang paggamit ng Priority Class);
bagong opsyon para sa kubelet - --reserved-cpus — nagpapahintulot sa iyo na tahasang tukuyin ang listahan ng mga CPU na nakalaan para sa system;
para sa kubectl logs ipinakita bagong bandila --prefix, pagdaragdag ng pangalan ng pod at source container sa bawat linya ng log;
в label.Selector idinagdag RequiresExactMatch;
lahat ng lalagyan sa kube-dns ay tumatakbo na ngayon na may mas kaunting mga pribilehiyo;
hyperkube nahiwalay sa isang hiwalay na GitHub repository at hindi na isasama sa mga release ng Kubernetes;
marami pinahusay na pagganap kube-proxy para sa mga hindi UDP port.

Mga pagbabago sa dependency:

Ang bersyon ng CoreDNS na kasama sa kubeadm ay 1.6.5;
crictl bersyon na-update sa v1.16.1;
CSI 1.2.0;
etcd 3.4.3;
Pinakabagong nasubok na bersyon ng Docker na na-upgrade sa 19.03;
Ang minimum na bersyon ng Go na kinakailangan upang bumuo ng Kubernetes 1.17 ay 1.13.4.

PS

Basahin din sa aming blog:

Pinagmulan: www.habr.com

Kubernetes 1.17: pangkalahatang-ideya ng mga pangunahing inobasyon