docker

Senki sem szereti a rendetlenséget. Akkor sem, ha nem vagyunk rendmániások. Valahol mindannyiunknak szüksége van arra a fajta belső nyugalomra, amit az ad, hogy a dolgok a helyükön vannak. Egy rendezett tér nem csak esztétikai kérdés: segít tisztábban gondolkodni, könnyebben eligazodni, és biztonságérzetet ad a mindennapokban.

Nincs ez másképp a Kubernetes cluster esetében sem. Amikor egyre több alkalmazást, podot, service-t és konfigurációt indítunk el, hamar rájövünk, hogy a rendszer saját “lakói” is igénylik a strukturáltságot. A Kubernetes pedig erre egy elegáns, mégis egyszerű megoldást kínál: a namespace-eket, amelyek láthatatlanul, de nagyon is hatékonyan teremtik meg azt a rendezettséget, amelyre egy növekvő clusternek szüksége van.

Mi az a namespace?

A Kubernetesben a namespace egy logikai szeparációs mechanizmus, amely csoportokra bontja a cluster erőforrásait.
A fogalom eredetileg a Linux kernel világából származik: ott is az izoláció a cél, vagyis hogy különböző folyamatok saját, elkülönített erőforrás-nézetet kapjanak.

A Kubernetes ezt továbbgondolja: a namespace nem csupán technikai elszeparálás, hanem egy szervezési, erőforrás-kontroll és biztonsági keret is.

Lényeg:

• Minden API-hívás egy namespace-en belül történik, hacsak nem adunk meg külön mást. Például: https://<api-server>/api/v1/namespaces/default/pods
• A namespace lehetővé teszi a kvóták és limitációk alkalmazását egy adott csoport erőforrásaira.
• Később az access control – például RBAC – is működhet namespace-szinten.
• Ha csak néhány erőforrás van a clusterben, akkor a szükségessége nem mindig látszik. De nagyobb vállalati környezetben a namespace az egyik legfontosabb szervezési eszköz.

A Kubernetes alapértelmezett namespace-ei

Amikor egy új clustert létrehozunk, Kubernetes négy namespace-t hoz létre automatikusan. Ezek előre definiált szerepet töltenek be, és fontos, hogy ismerjük őket.

default

Az alapértelmezett namespace.
Ha nem adunk meg explicit namespace-t egy API-hívásban vagy egy YAML-ben, minden ide kerül.

kube-system

Itt futnak a rendszer- és infrastruktúra szintű komponensek.
Maga a Kubernetes működéséhez szükséges podok találhatók itt, például a DNS, a kontrollerek, scheduler stb.

kube-public

Ez egy mindenki számára olvasható namespace (még hitelesítetlen felhasználók számára is).
Tipikusan olyan információkat tartalmaz, amelyeknek publikusnak kell lenniük.

kube-node-lease

Ez tárolja a node-ok „lease” objektumait.
A control plane ezzel követi a node egészségi állapotát, gyorsabban és hatékonyabban, mint korábban.

Hogyan dolgozunk namespace-ekkel?

A namespace-ek egy része kimondottan szervezési célokat szolgál: a fejlesztői, tesztelési és éles környezet könnyen elkülöníthető, de akár csapatonként, projektenként vagy üzleti funkcióként is létrehozhatunk új namespace-eket.

A legfontosabb alapműveletek:

Meglévő namespace-ek listázása

kubectl get ns

Új namespace létrehozása

kubectl create ns sajat-projekt

Namespace részletes leírása

Megmutatja többek között a címkéket, annotációkat, kvótákat, limiteket.

kubectl describe ns sajat-projekt

Namespace tartalmának YAML formátumú lekérése

kubectl get ns/sajat-projekt -o yaml

Namespace törlése

kubectl delete ns sajat-projekt

Namespace használata YAML fájlokban

Ha egy erőforrást szeretnénk egy konkrét namespace-ben létrehozni, azt a metadata blokkban kell megadni:

apiVersion: v1
kind: Pod
metadata:
  name: redis
  namespace: sajat-projekt

Ez a mindennapi Kubernetes fejlesztés egyik alapja: a pod encapsulation, a resource isolation és a cluster szervezése így lesz konzisztens, rendezett és biztonságos.

pod encapsulation: A „pod-beágyazás” azt jelenti, hogy a Kubernetes egyetlen kezelhető egységbe, az úgynevezett Podba foglal egy vagy több szorosan együttműködő konténert, a közösen használt tárolót és hálózati erőforrásokat. Ez lehetővé teszi, hogy konténerek egységes egészként működjenek: közösen használják az olyan erőforrásokat, mint a tároló vagy a hálózat, miközben a rendszer egy csomóponton (node) együtt ütemezi és kezeli őket. Ez a megközelítés jelentősen leegyszerűsíti az alkalmazások telepítését és skálázását.

Mikor érdemes namespace-t használni?

A namespace akkor segít igazán, ha:

• több csapat dolgozik ugyanabban a clusterben,
• több környezetet szeretnénk egymástól elszeparálni (dev, test, staging, prod),
• erőforráskvótákat kell alkalmazni (CPU, memória, storage),
• korlátozni akarjuk az erőforrások láthatóságát vagy módosíthatóságát,
• strukturált, átlátható cluster felépítést szeretnénk.

Kisebb clusterben nem mindig tűnik létkérdésnek, de hosszú távon a namespace az egyik legfontosabb szervezési eszköz, ami segít megelőzni a káoszt.

Összegzés

A namespace látszólag egy apró részlet a Kubernetesben, mégis az egész ökoszisztéma egyik legfontosabb alapköve.
Rendet teremt, felelősségi köröket választ szét, erőforrásokat szabályoz, és előkészíti a terepet a biztonságos, skálázható működéshez.

Ahogy tovább haladunk a Kubernetes mélyebb rétegei felé, újabb olyan elemeket fogunk megismerni, amelyek pontosan ilyen csendben, mégis hatalmas erővel segítik a fejlesztőket, üzemeltetőket és szervezeteket abban, hogy a microservice-ek világában stabil rendszereket építsenek.

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 json

A 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 kubectl egy 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 view kimenetében találhatók.
• A kliens a hitelesítési adatokat a ~/.kube/config fá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 kubectl csatlakozik;
• 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.