Kubernetes arkkitehtuuri

Kubernetes arkkitehtuuri

Tässä osiossa opit, miten Kubernetes toimii konepellin alla: miksi orkestrointia tarvitaan, mitä tarkoittaa deklaratiivinen malli ja mistä osista klusteri koostuu. Lopussa on lyhyt käytännön harjoitus, jossa tutkit oman klusterisi komponentteja.

1. Miksi orkestrointia tarvitaan?

Kun sovellus paketoidaan konttiin (esim. Docker), yksittäisen kontin ajaminen on helppoa. Ongelmat alkavat, kun kontteja on kymmeniä tai satoja ja niiden pitää toimia luotettavasti:

• Skaalaus – Miten lisään tai vähennän kopioita kuorman mukaan?
• Vikasietoisuus – Mitä tapahtuu, kun kontti tai kokonainen palvelin kaatuu?
• Verkko – Miten kontit löytävät toisensa ja miten liikenne jaetaan?
• Julkaisut – Miten päivitän uuden version ilman käyttökatkoa?

Orkestrointi tarkoittaa näiden asioiden automatisointia. Kubernetes on käytännön standardi konttien orkestrointiin: se päättää, missä kontit ajetaan, käynnistää kaatuneet uudelleen ja pitää huolen, että haluttu tila toteutuu.

💡 Ydinajatus: Sinä kerrot Kubernetesille mitä haluat, et miten se tehdään.

2. Deklaratiivinen malli ja sovittelusilmukka

Kubernetes toimii deklaratiivisesti. Kuvaat haluamasi lopputilan (desired state) – esimerkiksi “aja 3 kopiota tästä sovelluksesta” – ja Kubernetes pyrkii jatkuvasti saavuttamaan ja ylläpitämään sen.

Tätä toteuttaa sovittelusilmukka (reconciliation loop):

flowchart LR
	A[Haluttu tila<br/>desired state] --> B{Vertaa}
	C[Nykyinen tila<br/>current state] --> B
	B -->|eroaa| D[Tee korjaavat toimet]
	D --> C
	B -->|sama| E[Ei toimenpiteitä]

Esimerkki: jos määrittelet 3 kopiota, mutta yksi kaatuu, nykyinen tila (2) eroaa halutusta tilasta (3). Kubernetes huomaa eron ja käynnistää uuden kopion automaattisesti.

Imperatiivinen vs. deklaratiivinen

3. Klusterin komponentit

Kubernetes-klusteri koostuu ohjaustasosta (control plane) ja työsolmuista (worker nodes).

flowchart TB
	subgraph CP[Ohjaustaso · Control Plane]
		API[kube-apiserver]
		ETCD[(etcd)]
		SCH[kube-scheduler]
		CM[controller-manager]
		API --- ETCD
		API --- SCH
		API --- CM
	end
	subgraph N1[Työsolmu · Worker Node]
		K1[kubelet]
		P1[kube-proxy]
		R1[Konttiajuri]
		POD1[Pod]
		K1 --- R1
		R1 --- POD1
	end
	API --- K1
	kubectl[kubectl / käyttäjä] --> API

Ohjaustaso (Control Plane)

Ohjaustaso on klusterin “aivot” – se tekee päätökset ja säilyttää tilan.

• kube-apiserver – Klusterin keskitetty rajapinta. Kaikki kommunikointi (myös kubectl) kulkee sen kautta. Ainoa komponentti, joka kirjoittaa etcd:hen.
• etcd – Hajautettu avain–arvo-tietokanta, joka säilyttää klusterin koko tilan. Tämä on klusterin “totuuden lähde”.
• kube-scheduler – Päättää, mille työsolmulle uusi Pod sijoitetaan (resurssien, rajoitteiden ja sääntöjen perusteella).
• controller-manager – Ajaa sovittelusilmukoita (esim. varmistaa, että kopioiden määrä pysyy oikeana).

Työsolmut (Worker Nodes)

Työsolmut ajavat varsinaiset sovelluskontit.

• kubelet – Solmun agentti, joka varmistaa, että sille määrätyt Podit ovat ajossa ja terveitä. Raportoi tilan apiserverille.
• kube-proxy – Hoitaa solmun verkkosäännöt ja liikenteen ohjauksen palveluihin.
• Konttiajuri (container runtime, esim. containerd) – Käynnistää ja ajaa kontit.

Pod – pienin yksikkö

Pod on Kuberneteksen pienin sijoitettava yksikkö. Se sisältää yhden tai useamman tiiviisti yhteen kuuluvan kontin, jotka jakavat saman verkon ja tallennustilan. Käytännössä yksi Pod = usein yksi sovelluskontti.

4. Sovelluksen elinkaari

Näin määrittelemäsi sovellus päätyy ajoon:

1. Lähetys – Lähetät halutun tilan (esim. YAML) kubectl-työkalulla apiserverille.
2. Tallennus – apiserver tallentaa määrittelyn etcd:hen.
3. Ajoitus – scheduler valitsee sopivan työsolmun Podille.
4. Käynnistys – valitun solmun kubelet käynnistää kontin konttiajurin avulla.
5. Valvonta – controllerit ja kubelet valvovat jatkuvasti, että tila vastaa haluttua. Poikkeamat korjataan automaattisesti.

sequenceDiagram
	participant U as kubectl
	participant A as apiserver
	participant E as etcd
	participant S as scheduler
	participant K as kubelet
	U->>A: Haluttu tila (YAML)
	A->>E: Tallenna tila
	S->>A: Valitse solmu Podille
	A->>K: Käynnistä Pod solmulla
	K->>A: Raportoi tila (Running)

5. Käytännön harjoitus (5 min)

Tässä harjoituksessa käytät kouluttajan ylläpitämää jaettua Kubernetes-klusteria. Lataa ensin klusterin kubeconfig alta (tarvitset kouluttajalta saamasi salasanan) ja ota se käyttöön, jotta seuraavat kubectl-komennot toimivat.

Ota ladattu tiedosto käyttöön joko asettamalla KUBECONFIG-ympäristömuuttuja tai kopioimalla tiedosto oletussijaintiin:

# Vaihtoehto A: osoita kubectl ladattuun tiedostoon nykyisessä istunnossa
export KUBECONFIG=$HOME/Downloads/config

# Vaihtoehto B: kopioi oletussijaintiin
mkdir -p $HOME/.kube && cp $HOME/Downloads/config $HOME/.kube/config

Luo lopuksi oma nimiavaruus (namespace), jossa työskentelet, jotta harjoituksesi eivät sekoitu muiden osallistujien resursseihin jaetussa klusterissa:

# Korvaa <oma-nimi> omalla nimelläsi
kubectl create namespace <oma-nimi> --dry-run=client -o yaml | kubectl apply -f -
kubectl config set-context --current --namespace=<oma-nimi>

Tämän jälkeen kubectl-komennot kohdistuvat automaattisesti omaan nimiavaruuteesi (järjestelmäkomponentteja tarkastellaan silti erikseen -n kube-system -valitsimella).

1. Katso klusterin solmut ja niiden tila:

kubectl get nodes -o wide

Näet klusterin työsolmut, niiden tilan (Ready) ja Kubernetes-version.

2. Tarkastele ohjaustason ja järjestelmän komponentteja:

kubectl get pods -n kube-system

kube-system-nimiavaruudessa ajetaan järjestelmäkomponentteja, kuten kube-proxy ja verkko-osat. Näet, että Kubernetes hallitsee myös omia osiaan Podeina.

3. Katso, mitä komponentteja klusteri raportoi terveiksi:

kubectl get componentstatuses

4. Kokeile deklaratiivista mallia käytännössä. Luo Deployment, poista sen Pod ja seuraa, mitä tapahtuu:

# Luo Deployment, joka pitää yllä 1 kopiota nginxistä
kubectl create deployment web --image=nginx

# Katso syntyneet Podit
kubectl get pods

# Poista Pod käsin (korvaa <nimi> listasta saamallasi nimellä)
kubectl delete pod <nimi>

# Katso uudelleen – Kubernetes on jo käynnistänyt korvaavan Podin
kubectl get pods

🔎 Huomaa: Vaikka poistit Podin, sovittelusilmukka huomasi eron haluttuun tilaan (1 kopio) ja loi uuden Podin automaattisesti. Tämä on deklaratiivinen malli toiminnassa.

Siivoa harjoitus lopuksi poistamalla oma nimiavaruus, mikä poistaa myös kaikki sen sisältämät resurssit:

kubectl delete namespace <oma-nimi>

Yhteenveto

• Kubernetes orkestroi kontteja: skaalaus, vikasietoisuus, verkko ja julkaisut hoituvat automaattisesti.
• Malli on deklaratiivinen: kuvaat halutun tilan, ja sovittelusilmukka ylläpitää sitä.
• Ohjaustaso (apiserver, etcd, scheduler, controller-manager) tekee päätökset; työsolmut (kubelet, kube-proxy, konttiajuri) ajavat sovellukset.
• Pod on pienin sijoitettava yksikkö.
• Kun poistat Podin, Kubernetes luo sen uudelleen – juuri niin kuin deklaratiivisen mallin kuuluukin toimia.