api

| Olvasási idő: 4 perc |

Ha elég időt töltünk Kubernetes környezetben, egy ponton elkerülhetetlenül rájövünk, hogy a sok látható elem – kapszulák, szolgáltatások, vezérlők, automatizmusok – mögött van valami közös, csendben működő hatalom. Valami, ami minden változtatást, minden lekérdezést, minden döntést összeköt. Ez az API.

Egy láthatatlan infrastruktúra-háló, amely összefogja a fürt egészét, irányítja az adatáramlást, és biztosítja, hogy a rendszer minden része ugyanazt a nyelvet beszélje. Amikor ezt megértjük, nem csak használjuk a Kubernetest – elkezdjük igazán érteni.

Az API a Kubernetes motorja

A Kubernetes teljes architektúrája API-alapú. A központi komponens, a kube-apiserver, felel azért, hogy a fürtben futó összes komponens — a vezérlősík elemei és a külső kliensek — megbízhatóan kommunikáljanak egymással.
Minden, amit a kubectl paranccsal végzünk, valójában egy REST-alapú API hívás, amely HTTP metódusokat (GET, POST, DELETE stb.) használ.

Aki szeretne mélyebben belelátni a működésbe, kipróbálhatja a curl-alapú lekérdezéseket is. A megfelelő tanúsítványok birtokában például így kérhetjük le az aktuális kapszulák (Pods) listáját:

curl --cert user.pem --key user-key.pem \
 --cacert /path/to/ca.pem \
 https://k8sServer:6443/api/v1/pods

Ezek a hívások teszik lehetővé, hogy akár automatizált rendszerek, akár fejlesztői eszközök biztonságosan kapcsolódjanak a Kubernetes API-hoz.

A RESTful szemlélet ereje

A Kubernetes API RESTful, vagyis állapotmentes és erőforrás-orientált.
Minden objektum – például egy kapszula vagy egy szolgáltatás – egy konkrét API-végpont (endpoint) mögött található.
A /api/v1/pods például a kapszulákhoz tartozó végpont, ahol a GET lekérdezés listát ad, a POST pedig új kapszulát hoz létre.
Ez a megközelítés lehetővé teszi, hogy a Kubernetes könnyen integrálható legyen bármely modern fejlesztési vagy üzemeltetési eszközzel.

Jogosultságok és hozzáférés-ellenőrzés

A Kubernetes egyik legfontosabb biztonsági alapelve, hogy minden felhasználó csak azt tehessen meg, amire jogosultsága van.
Ezt az RBAC (Role-Based Access Control) rendszer szabályozza, de már a gyakorlati munkához is jól jön, ha gyorsan ellenőrizni tudjuk, mire van engedélyünk.

A kubectl auth can-i parancs pontosan erre való:

kubectl auth can-i create deployments
yes
kubectl auth can-i create deployments --as robert
no
kubectl auth can-i create deployments --as robert --namespace developer
yes

A fenti példában látható, hogy a „robert” nevű felhasználó csak a developer névtérben (namespace) hozhat létre új Deployment objektumokat.

A Kubernetes három fő API-t biztosít az engedélyek ellenőrzésére:

API típus	Funkció
SelfSubjectAccessReview	Ellenőrzi, hogy az aktuális felhasználó végrehajthat-e egy adott műveletet.
LocalSubjectAccessReview	Ugyanez, de egy konkrét névtérre korlátozva.
SelfSubjectRulesReview	Megmutatja, milyen műveleteket hajthat végre a felhasználó egy névtérben.

Ez a felépítés biztosítja, hogy a jogosultságok átláthatóak és ellenőrizhetőek legyenek, ami különösen fontos nagyvállalati környezetben.

Optimista konkurencia – amikor több kéz nyúl ugyanahhoz az objektumhoz

A Kubernetes nem zárja le az erőforrásokat szerkesztés közben.
Ehelyett az úgynevezett optimista konkurenciakezelést (Optimistic Concurrency) használja, amely a resourceVersion értékre támaszkodik.

Amikor valaki módosít egy objektumot, a rendszer ellenőrzi, hogy a resourceVersion azóta megváltozott-e.
Ha igen, 409 CONFLICT hibát kapunk, ami jelzi, hogy az objektumot időközben más is frissítette.
Ez a módszer különösen fontos nagy fürtök esetén, ahol több automatizált folyamat és emberi adminisztrátor is dolgozik egyszerre ugyanazokon az erőforrásokon.

A resourceVersion értéket az etcd adatbázis kezeli, és egyedileg azonosítja az adott objektumot a névtér és a típus alapján.
A lekérdezések (GET, WATCH) nem változtatják ezt az értéket, csak a módosítások (UPDATE, PATCH, DELETE).

Annotációk – amikor a metaadat többet mond, mint ezer címke

A Kubernetes-ben a címkék (labels) segítségével szűrhetünk és csoportosíthatunk objektumokat.
Az annotációk (annotations) viszont nem keresésre, hanem metaadatok tárolására szolgálnak.
Ezek lehetnek időbélyegek, kapcsolódó objektumokra mutató hivatkozások, vagy akár az adott erőforrásért felelős fejlesztő e-mail-címe.

Az annotációk kulcs–érték párok formájában tárolódnak, és ember számára is olvashatóak.
Ez különösen hasznos lehet integrációs vagy üzemeltetési eszközök számára, mivel így minden releváns információ közvetlenül az objektumhoz kapcsolható.

Példa annotációk létrehozására és módosítására:

kubectl annotate pods --all description='Production Pods' -n prod
kubectl annotate --overwrite pod webpod description='Old Production Pod' -n prod
kubectl annotate -n prod pod webpod description-

Az annotációk segítségével tehát kontextust adhatunk az erőforrásainkhoz – anélkül, hogy az API működését befolyásolnánk.

Összegzés

A Kubernetes API nem csupán egy technikai interfész, hanem a platform idegrendszere.
A RESTful megközelítés, a precíz hozzáférés-kezelés, az optimista konkurencia és a rugalmas annotációk mind azt a célt szolgálják, hogy a rendszergazdák és fejlesztők hatékonyan, biztonságosan és átláthatóan kezeljék a komplex felhős környezeteket.

Aki megérti az API működését, valójában a Kubernetes egészét érti meg.
És bár a kapszulák futtatása látványosabbnak tűnhet, az igazi varázslat mégis itt, az API hívások szintjén történik.