Ano ang mga pangunahing bahagi ng arkitektura ng Kubernetes at ano ang responsibilidad ng bawat isa?

Ang isang Kubernetes cluster ay binubuo ng isang control plane at isang set ng worker machine, na tinatawag na nodes, na nagpapatakbo ng mga containerized na application sa Pods. Ang bawat cluster ay nangangailangan ng kahit man lang isang worker node para magpatakbo ng Pods.

Sa konsepto, ang Kubernetes ay declarative: nagsusumite ka ng gustong estado sa API server (naka-imbak sa etcd), at ang mga controller ay nagpapatakbo ng tuluy-tuloy na mga loop ng pagkakasundo na nagbabantay sa mga pagkakaiba at kumikilos upang humimok ng aktwal na estado patungo sa nais na estado.

Kontrolin ang mga bahagi ng eroplano

Ang control plane ay gumagawa ng mga pandaigdigang desisyon tungkol sa cluster (gaya ng pag-iskedyul) at tumutugon sa mga kaganapan ng cluster. Sa produksyon, karaniwan itong tumatakbo sa maraming makina para sa mataas na kakayahang magamit.

• kube-apiserver — ang pangunahing bahagi na naglalantad sa Kubernetes HTTP API. Ito ang front end ng control plane at ang nag-iisang punto ng contact: lahat ng authentication, authorization, validation ng kahilingan, at pagbabasa/pagsusulat ng cluster state na dumadaloy dito. Naka-scale ito nang pahalang. Sa mga normal na deployment, ito lang ang Kubernetes component na direktang nagbabasa at nagsusulat ng cluster state sa etcd; lahat ng iba pang bahagi ay nakikipag-ugnayan sa estado sa pamamagitan ng API server.
• etcd — isang pare-pareho at very-available na key-value store na ginagamit bilang backing store ng Kubernetes para sa lahat ng cluster data: configuration, state, at metadata. etcd ay sapilitan at ang nag-iisang pinagmulan ng katotohanan — ang pagkawala nito ay nangangahulugan ng pagkawala ng lahat ng estado ng cluster, kaya dapat itong tumakbo nang may korum (isang kakaibang bilang ng mga miyembro) at regular na naka-back up.
• kube-scheduler — binabantayan ang Mga Pod na hindi pa nakatali sa isang node at itinatalaga ang bawat Pod sa isang angkop na node, na isinasaalang-alang ang mga mapagkukunan, mga hadlang, at mga patakaran.
• kube-controller-manager — nagpapatakbo ng mga controller na nagpapatupad ng Kubernetes API na gawi (hal., Node controller, Job controller, EndpointSlice controller). Ang bawat controller ay pinapanood ang nais na estado at pinagkasundo ang aktwal na estado patungo dito.
• cloud-controller-manager (opsyonal) — sumasama sa pinagbabatayan na cloud provider, na naghihiwalay sa cloud-specific na logic mula sa mga pangunahing bahagi ng Kubernetes.

Mga bahagi ng node

Ang mga ito ay tumatakbo sa bawat node, pinapanatili ang Pods na tumatakbo at nagbibigay ng runtime environment.

• kubelet — ang ahente na nagsisigurong gumagana ang Pods, kasama ang kanilang mga container. Pinapanood nito ang API server para sa mga pagtatalaga ng Pod, nagsisimula ng mga container sa pamamagitan ng runtime, nag-mount ng mga volume, nagpapatakbo ng liveness/readiness probe, at nag-uulat ng node status.
• kube-proxy — nagpapatupad ng Networking ng Serbisyo sa pamamagitan ng pagprograma ng mga iptable o mga panuntunan sa IPVS sa mga node upang maipasa ang trapiko sa isang Serbisyo sa mga tamang Pod IP. Ito ay minarkahan na opsyonal dahil ang ilang CNI plugin (hal., Cilium sa eBPF mode) ang pumalit sa trabaho nito, ngunit sa isang karaniwang cluster ito ay kinakailangan.
• Container runtime — ang software na responsable para sa pagpapatakbo ng mga container (containerd, CRI-O, atbp., sa pamamagitan ng CRI interface).

Mga Addon

Pinapalawak ng mga addon ang cluster functionality: cluster DNS (CoreDNS bilang default), ang Dashboard web UI, pagsubaybay sa mapagkukunan ng lalagyan, at pag-log sa antas ng cluster.

Karaniwang follow-up: lahat ng komunikasyon ay dumadaloy sa API server — pinapanood lang ito ng scheduler, controllers, at kubelets — na ginagawang kritikal na hub ng cluster ang API server.