Docker és Kubernetes: riválisok vagy partnerek?

“Docker vagy Kubernetes?” — ez az egyik leggyakoribb kérdés, amit feltesznek a konténerek világába belépők, és egyben az egyik leggyakoribb félreértés is. A két technológia ugyanis nem egymás versenytársa, hanem két különböző rétegben dolgozik. Olyan ez, mintha azt kérdeznéd: “autó vagy autópálya?”. Ebben a cikkben tisztázzuk, ki mit csinál, hogyan kapcsolódnak, és mikor van valóban szükséged Kubernetes-re.

A félreértés gyökere

A zavart az okozza, hogy mindkét szó a konténerek köré épül, és gyakran egy mondatban hangzanak el. Pedig:

• A Docker egy eszközkészlet, amellyel konténer-image-eket építesz és konténereket futtatsz — jellemzően egyetlen gépen.
• A Kubernetes (gyakran k8s) egy orchesztrátor, amely sok konténert kezel sok gépen keresztül: ütemez, skáláz, gyógyít és összeköt.

A Docker tehát az építő- és futtatóeszköz, a Kubernetes pedig a karmester, aki egy egész zenekart vezényel. Ha még az alapokkal ismerkedsz, kezdd a Mi az a Docker? cikkel és a Hogyan működik oldallal.

Mit csinál a Docker?

A Docker egyetlen host szintjén oldja meg a feladatait:

• Image-ek építése Dockerfile alapján (docker build).
• Konténerek futtatása ezekből az image-ekből (docker run).
• Hálózatok és volume-ok kezelése egy gépen belül.
• Docker Compose-szal több, együttműködő konténer leírása és indítása egyetlen compose.yaml fájlból.

Egy tipikus fejlesztői munkamenet így néz ki:

docker build -t webapp:1.0 .
docker run -d -p 8080:80 webapp:1.0
docker compose up -d

Ez tökéletes egyetlen szerverre vagy a fejlesztői gépedre. De mi van, ha tíz szervered van, és a forgalom napszakonként ingadozik?

Mit csinál a Kubernetes?

Itt lép színre a Kubernetes. A feladata, hogy egy gépcsoporton (cluster) keresztül felügyelje a konténereidet. A főbb képességei:

• Ütemezés (scheduling) – eldönti, melyik node-on fusson egy konténer az erőforrások alapján.
• Skálázás – automatikusan több vagy kevesebb példányt indít a terhelés szerint.
• Önjavítás (self-healing) – ha egy konténer összeomlik vagy egy node kiesik, újraindítja máshol.
• Szolgáltatásfelderítés (service discovery) és terheléselosztás – a konténerek stabil néven elérik egymást.
• Deklaratív működés – te leírod a kívánt állapotot, a Kubernetes pedig gondoskodik róla, hogy a valóság ezt kövesse.

💡 Tipp: A Kubernetes deklaratív. Nem azt mondod meg neki hogyan indítson el valamit, hanem mit szeretnél: “legyen mindig 3 példány ebből a webappból”. Ha kettő marad, ő pótolja a harmadikat — anélkül, hogy te közbelépnél.

Hogyan kapcsolódik a kettő?

És itt jön a lényeg, amitől a “rivális” szó értelmét veszti: a Kubernetes konténereket futtat — méghozzá ugyanazokat az image-eket, amiket Dockerrel építesz.

A kulcs az OCI (Open Container Initiative) szabvány. Ez egy nyílt specifikáció, amely rögzíti, milyen formátumú egy konténer-image és hogyan kell futtatni. A Dockerrel épített image OCI-kompatibilis, így bármilyen OCI-konform futtatókörnyezet elindítja.

⚠️ Figyelem: A Kubernetes 1.24 óta nem használja közvetlenül a Docker Engine-t a konténerek futtatásához (a dockershim-et eltávolították). Ettől még a Dockerrel épített image-eid tökéletesen futnak benne — mert OCI-szabványosak.

A háttérben a Kubernetes egy container runtime-ot használ, jellemzően a containerd-t, amely egyébként a Docker Engine motorja is. Vagyis a Docker és a Kubernetes ugyanarra a low-level technológiára épül, csak más szinten.

Felelősségi körök egymás mellett

Felelősség	Docker	Kubernetes
Image építése	✅ docker build	❌ (a buildet rád/CI-re bízza)
Konténer futtatása egy gépen	✅	✅ (containerd-n keresztül)
Több gép (cluster) kezelése	❌	✅
Automatikus skálázás	❌	✅
Önjavítás node-kiesésnél	❌	✅
Szolgáltatásfelderítés clusteren át	❌	✅
Egyszerű, helyi multi-konténer	✅ (Compose)	túlzás lenne

Látható: a két oszlop nem ütközik, hanem kiegészíti egymást. A Dockerrel készíted az alapanyagot, a Kubernetes pedig nagy léptékben üzemelteti.

Mikor elég a Docker / Compose, és mikor kell Kubernetes?

Nem minden projektnek van szüksége Kubernetes-re — sőt, a legtöbbnek nincs. A választáshoz pár jó szempont:

Maradj Dockernél és Compose-nál, ha:

• egyetlen szerveren vagy néhány konténerrel futsz,
• a fejlesztői környezetedet építed fel,
• a forgalmad kiszámítható, nem kell automatikus skálázás,
• kis csapatban dolgozol, és az egyszerűség a fő szempont.

Gondolkodj Kubernetes-ben, ha:

• több szerveren, magas rendelkezésre állással kell futnod,
• a terhelés erősen ingadozik, és automatikus skálázásra van szükség,
• sok mikroszolgáltatást üzemeltetsz, amelyeknek egymásra kell találniuk,
• a nullaidős (rolling) frissítések és az önjavítás kritikusak.

A Kubernetes ereje a komplexitásból fakad — de ennek ára is van: maga is komplex rendszer. Egy kis appot Kubernetes-re tenni gyakran több baj, mint haszon. Sokszor egy Docker Compose bevezető szintjén megírt compose.yaml tökéletesen elég.

services:
  web:
    image: ghcr.io/pelda/webapp:1.0
    ports:
      - "8080:80"
    restart: unless-stopped
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: titok
    volumes:
      - db-data:/var/lib/postgresql/data

volumes:
  db-data:

Ez a néhány sor egy teljes két-konténeres alkalmazást indít — Kubernetes nélkül.

Összefoglalás

A Docker és a Kubernetes nem riválisok, hanem partnerek, akik a konténeres verem két különböző rétegében dolgoznak. A Docker konténer-image-eket épít és konténereket futtat egyetlen gépen; a Kubernetes ezeket az OCI-szabványos image-eket orchesztrálja sok gépen át — ütemez, skáláz, gyógyít és összeköt. Mindketten a containerd-re támaszkodnak, így a Dockerrel készített image-ed Kubernetes-ben is gond nélkül fut. A gyakorlatban szinte mindig Dockerrel buildelsz, és csak akkor lépsz Kubernetes-re, ha a lépték és a rendelkezésre állás megköveteli.

Ha most ismerkedsz a konténerekkel, kezdd a Kezdő lépések útmutatóval és a Telepítés oldallal. Próbáld ki előbb Docker Compose-zal a saját appodat — és csak akkor lépj tovább a Kubernetes felé, amikor tényleg kinövöd!