Kubernetes API és hozzáférés – a láthatatlan működés mélyén
Amikor legutóbb a Kubernetes API-ról mint „a kommunikáció idegrendszeréről” írtam, sok visszajelzést kaptam arról, mennyire segített érthetővé tenni a fürt működését. Most innen folytatjuk a történetet. Az előző cikkben is sok mindent megmutattam, hogy érthetőbbé tegyem a cluster belső működését, és most megvizsgáljuk, hogyan zajlik valójában az információáramlás a Kubernetes belső világában.
Ennek a cikknek a célja, hogy az API működésének gyakorlati oldalát mutassa be: hogyan jelenik meg mindez a legegyszerűbb kapszula létrehozásánál, mit csinál a kubectl valójában a háttérben, hogyan lehet a klaszteren kívülről hozzáférni az API-szerverhez, és mire szolgál a mindenki által használt ~/.kube/config fájl.
A Kubernetesben minden objektum, minden módosítás, minden lekérdezés API-hívások sorozata. Ha értjük ezt a réteget, a rendszer teljes működése világossá válik.
1. A kapszula mint API-objektum: a legkisebb egység
Az előző cikkben már beszéltünk arról, hogy a kapszula a Kubernetes legkisebb futtatási egysége. Az alábbi példa egy minimális, mégis rendkívül tanulságos kapszula-definíciót mutat be:
apiVersion: v1
kind: Pod
metadata:
name: elsopod
spec:
containers:
- image: nginx
name: robi
Ez a néhány sor már minden lényeges elemet tartalmaz:
- apiVersion – melyik API-csoportot használja az objektum;
- kind – az erőforrás típusa (
Pod); - metadata – az objektum azonosító adatai;
- spec – a kapszulában futó konténerek és paramétereik.
A létrehozás és lekérdezés mind API-hívások sorozatán keresztül történik:
kubectl create -f elsopod.yaml
kubectl get pods
kubectl get pod elsopod -o yaml
kubectl get pod elsopod -o jsonA külvilág számára ezek egyszerű parancsoknak tűnnek, de valójában a kubectl az API-szerverhez küld lekérdezéseket és módosítási kéréseket.
2. Hogyan kommunikál valójában a kubectl?
A Kubernetes minden erőforrást RESTful API-n keresztül kezel. Ez azt jelenti, hogy a kubectl működése valójában nem más, mint HTTP-hívások generálása az API-szerver felé – tipikusan JSON formátumú kommunikációval.
Ha szeretnénk még többet megtudni arról, mit csinál a kubectl a háttérben, akkor kapcsoljuk be a részletes – verbose – naplózást:
kubectl --v=10 get pods elsopod
A logokban ilyen sorok is megjelennek:
curl -k -v -XGET -H "Accept: application/json" \
https://10.128.0.3:6443/api/v1/namespaces/default/pods/elsopod
Ez a sor egyértelművé teszi:
- a
kubectlegy kliens, - a Kubernetes API-szervere a célpont,
- a két fél között TLS-sel védett HTTP-forgalom zajlik.
Ez a tudás fontos, mert így értjük meg igazán, mi történik akkor, amikor mi „csak” egy új kapszulát hozunk létre vagy lekérjük a futó erőforrásokat.
3. Hozzáférés a Kuberneteshez a klaszteren kívülről
A legtöbb adminisztrációs feladat a kubectl használatával történik, de akár közvetlenül curl-lel is kommunikálhatnánk a Kubernetes API-szerverével.
A gond csak az, hogy ehhez hitelesített, TLS-sel védett kapcsolat kell. És mit kell tudni a klaszterhez tartozó API-król?
- A klaszter API végpontjának adatai a
kubectl config viewkimenetében találhatók. - A kliens a hitelesítési adatokat a
~/.kube/configfájlból olvassa ki. - E nélkül a fájl nélkül a hozzáférés legfeljebb korlátozott, „insecure” módon lehetséges, amellyel a legtöbb művelet nem érhető el.
Ezért mondjuk, hogy a kubeconfig a hozzáférés kulcsa: nélküle a klaszter elérhetetlen lenne.
4. A kubeconfig felépítése és jelentése
A ~/.kube/config fájl a Kuberneteshez való hozzáférés központi eleme. A benne található adatok határozzák meg:
- melyik klaszterhez csatlakozunk,
- milyen felhasználó nevében tesszük ezt,
- milyen hitelesítési adatokat használunk,
- és milyen kontextusban fut a
kubectl.
A kubeconfig több fő részből áll, amelyek együtt írják le a kapcsolat minden aspektusát. Egy alap struktúra így néz ki:
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: <base64-adat>
server: https://10.128.0.3:6443
name: kubernetes
contexts:
- context:
cluster: kubernetes
user: kubernetes-admin
name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
user:
client-certificate-data: <base64-cert>
client-key-data: <base64-key>
Most nézzük végig, mit jelentenek ezek a mezők:
apiVersion
Ahogy minden Kubernetes-objektumnál, itt is meg kell határozni, hogy a fájl melyik API-verzió szerint értelmezendő. A kubeconfig esetében ez tipikusan v1.
clusters
A klaszter(ek) eléréséhez szükséges adatok:
- server – az API-szerver címe, amelyhez a
kubectlcsatlakozik; - certificate-authority-data – a CA tanúsítvány, amely biztosítja, hogy a kliens a megfelelő API-szerverhez kapcsolódjon, és a kapcsolat hiteles legyen.
Ezek alapján a kubectl tudja, hová küldje a kéréseit.
users
Itt találhatók a kliens hitelesítési adatai.
Tipikusan:
- kliensoldali tanúsítvány,
- privát kulcs,
- vagy token.
A Kubernetes ebben a részben tárolja, hogy a felhasználó milyen módon igazolja magát a klaszter felé.
contexts
A context egy hármas kapcsolat:
- melyik klasztert használjuk,
- melyik felhasználó nevében,
- és milyen alapbeállításokkal (pl. namespace).
Ez teszi lehetővé, hogy ugyanarról a gépről több klaszterrel is dolgozhassunk, akár eltérő jogosultságokkal.
current-context
Ez mondja meg, hogy a kubectl éppen melyik contextet használja alapértelmezésként.
Ha nem adunk meg külön kapcsolót minden parancsnál, akkor ez a context érvényesül.
preferences
Ritkán használt beállítások, például megjelenítési opciók. A legtöbb esetben üres marad.
5. Miért fontos mindezt érteni?
A kubeconfig nem csupán technikai részlet: a Kubernetes működésének egyik kulcsdarabja.
Ez határozza meg, hogy:
- melyik klaszterrel kommunikálsz,
- milyen jogosultsággal,
- milyen biztonsági réteg alatt.
Ha a kubeconfigot érted, akkor magabiztosan tudsz klaszterek között váltani, hibákat diagnosztizálni, saját API-hívásokat küldeni, vagy akár több környezetet is kezelni ugyanazon a gépen.
A történet pedig itt még nem ér véget – a Kubernetes mélyebb rétegei csak most kezdenek igazán érdekessé válni.
