Docker Compose vs Kubernetes: millal neid kasutada, erinevused ja migratsioon

Informatec Digital » Ressursid » Docker Compose vs Kubernetes: millal neid kasutada, erinevused ja migratsioon

Kui töötate konteineritega, tekib varem või hiljem suur küsimus: Docker Compose või Kubernetes? Mõlemat tööriista kasutatakse konteinerdatud rakenduste elutsüklis , kuid need ei ole loodud täpselt samade probleemide lahendamiseks ega samas kontekstis. Selles artiklis võrdleme neid põhjalikult, tuues praktilisi näiteid, reaalseid stsenaariume ja näpunäiteid sujuvaks ühelt teisele migreerumiseks.

Lisaks tehnoloogilisele paigutusele mõjutab see otsus igapäevaseid toiminguid: juurutamise aegu, skaleeritavust , vastupidavust, turvalisust ja kulusid . See mõjutab ka tüüpilisi andmetehnika kasutusjuhtumeid – torujuhtmeid, andmebaase, voogedastust, partiitöötlust, andmevorminguid ja haldamist –, kus orkestreerimine mängib tootlikkuse seisukohalt olulist rolli.

Mis on Docker ja Docker Compose (ja milleks need tegelikult mõeldud on)?

Kui me räägime Dockerist, siis me räägime tegelikult ökosüsteemist: Docker Engine, Docker Hub, Dockerfile, Docker Compose ... Mootor loob ja käitab konteinereid piltide põhjal; Hub teeb nende jagamise lihtsaks; ja Compose võimaldab teil määratleda mitu pinu osa YAML-failis, et need ühe käsuga käivitada.

Compose loodi selleks, et päästa meid lõpututest skriptidest ja isoleeritud käskudest. Ühe docker-compose.yml failiga kirjeldad teenuseid, võrke ja mahtusid ning saad kõik tööle ühe "docker compose up" käsuga (või "docker-compose up" versioonis V1). Ideaalne kohalikuks arenduseks, integreeritud testimiseks, demodeks või CI-keskkondadeks.

Kanooniline näide Compose'ist võib olla see, API ja Postgresi andmebaasiga. Pane tähele, kuidas sõltuvused, muutujad ja pordid deklareeritakse loetavas plokis:

version: '3.8'
services:
  db:
    image: postgres:latest
    restart: always
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_DB=postgres
    ports:
      - '5432:5432'
    volumes:
      - db:/var/lib/postgresql/data
    networks:
      - mynet

  my-api:
    container_name: my-api
    build:
      context: ./
    image: my-api
    depends_on:
      - db
    ports:
      - '8080:8080'
    environment:
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: postgres
      DB_PASSWORD: postgres
      DB_NAME: postgres
    networks:
      - mynet

networks:
  mynet:
    driver: bridge

volumes:
  db:
    driver: local

Compose'is käsitsi skaleerimiseks saate kasutada teenuse skaleerimisvalikut. Compose V2-s on tavaline seda teha valikuga `up --scale` (V1-s oli `docker-compose scale`):

docker compose up -d --scale my-api=3

Arvesta piirangutega: Compose on loodud ühe hosti jaoks , see ei tasakaalusta koormust sõlmede vahel ega teosta automaatset skaleerimist ning uuendused on tavaliselt konteinerite käsitsi taasloomised käskudega "build" ja "up -d".

Mis on Kubernetes ja mida see pakub võrreldes Compose'iga?

Kubernetes (K8s) on hajutatud konteinerite orkestreerimisplatvorm. See haldab ulatuslikke juurutusi mitmesõlmelistes klastrites , kasutades selliseid kontseptsioone nagu Podid, juurutused ja teenused tootmiskoormuste haldamiseks.

Kuberneteses ei hallata üksikuid konteinereid, vaid Pode (mis võivad sisaldada ühte või mitut konteinerit). Juhtimistasand ajastab iga Podi töötamise , avalikustab teenused, jaotab liiklust, skaleerib horisontaalselt ja jälgib töökoormuste seisundit.

Põhiline juurutus võib välja näha selline, koos veebiteenuse kolme koopiaga. Määrake mallid, sildid ja avatud pordid :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: my-web-image
          ports:
            - containerPort: 8000

Koormuse tasakaalustamiseks on pilves tavaline kasutada LoadBalancer teenust. Valija sobitab Podi sildid liikluse suunamiseks.

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8000
  type: LoadBalancer

Tootmises särab Kubernetes selliste võimalustega nagu suure jõudlusega automatiseerimine (HPA), jooksvad värskendused ja isetaastamine. HPA kohandab koopiaid mõõdikute (nt protsessori kasutuse) põhjal :

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  minReplicas: 1
  maxReplicas: 10
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-deployment
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50

Konteineri tervist jälgitakse sondidega; kui need rikki lähevad, taaskäivitab K8s konteineri. See on "enesetervendamise" alus :

apiVersion: v1
kind: Pod
metadata:
  name: web-pod
spec:
  containers:
    - name: web
      image: my-web-image
      ports:
        - containerPort: 8000
      livenessProbe:
        httpGet:
          path: /healthcheck
          port: 8000
        initialDelaySeconds: 15
        periodSeconds: 15

Peamised sarnasused ja erinevused (olulised asjad ilma ümber põõsa keerutamata)

Mis neil ühist on: nad töötavad konteineritega ja defineerivad juurutusi YAML-i kaudu. Mõlemad lahendused on kasulikud nii arendajatele kui ka operaatoritele ning täiendavad teineteist väga hästi arendus- ja tootmisprotsesside töövoogudes.

Oluline erinevus seisneb ulatuses: Compose on Docker-keskne ja ühe hosti põhine ; Kubernetes toetab mitut käituskeskkonda ja mitmesõlmelisi klastreid, millel on otsene integratsioon pilvedesse ja hallatud teenustesse.

Olulisemad erinevused: Kubernetes pakub automaatset skaleerimist, jooksvaid värskendusi ja isetervendamist ; Compose seda ei tee. Kubernetes abstraheerib Pode; Compose suhtleb otse Dockeri konteineritega.

Lisaks sisaldab Kubernetes ühekordsete või ajastatud ülesannete jaoks tööülesandeid (Jobs) ja CronJobse (CronJobs). See väldib süsteemi cron-töid ja täiendavaid konteinerdatud protsesse , hoides platvormi loomuliku kohana automatiseeringute määratlemiseks.

Kohapeal võidab Compose kiiruse ja lihtsuse poolest. Sadade sõlmede või mitme pilve keskkondade skaleerimiseks on Kubernetes loogiline valik . Compose saab Docker Swarmi mitme hostiga juurutuste jaoks ära kasutada, kuid selle kasutuselevõtu määr ja võimalused ei vasta Kubernetes'i ökosüsteemile ja küpsusele.

Miks on vaja orkestreerimist (ja millal igaüks neist sobib kõige paremini)

Hea orkestreerija pakub teile ühtset pakkumist ja juurutamist, ajastatud käivitamisi, teenustevahelist suhtlust , koormuse tasakaalustamist ja täiendavat turvalisust iga teenuse täiendava haldamise kaudu.

Compose hõlmab põhitõdesid sujuval ja loetaval viisil, muutes selle suurepäraseks tööriistaks arendamiseks, testimiseks ja demode jaoks. Selle piirangud ilmnevad aga siis, kui vajate mitut sõlme, natiivset koormuse tasakaalustamist ja automaatset skaleerimist või astmelisi juurutusi ilma seisakuteta.

Kubernetes seevastu on koormuse kasvu korral „platvorm“: mitmesõlmeline, automaatne skaleerimine, kõrge käideldavus ja hiiglaslik ökosüsteem , millel on natiivne tugi AWS-il, Azure'il, GCP-l ja hallatud valikutel.

Reaalse maailma kasutusjuhud (arendus, andmed ja muu)

Compose särab järgmistes valdkondades: reprodutseeritavad lokaalsed keskkonnad, E2E-testimine, CI/CD ja koolitus . Kogu pinu defineerimine YAML-is ja selle käivitamine ühe käsuga kõrvaldab palju müra.

Kubernetes sobib ideaalselt: tootmisrakenduste, asjade interneti ja servandmetöötluse, suurandmete ja masinõppe ning multi-/hübriidpilvekeskkondade jaoks. See haldab hajutatud töökoormusi, kus latentsus, vastupidavus ja jälgitavus on olulised.

Andmetehnikas sobib K8s ideaalselt voogedastus- ja partiitöötlustorustike, andmebaaside, järjekordade ja analüütiliste mootorite jaoks , pakkudes ressursside kontrolli pod-põhiselt ja automaatset skaleerimist tippkoormuste korral.

Kui teie projekt on väike ja mahub ühele hostile, ajab Compose selle asja ilma probleemideta ära. Aga kui teie kasutajaskond kasvab ja vajate tõsist rikketaluvust ja koormuse tasakaalustamist , on aeg kaaluda Kubernetesit.

Võrgustamine, skaleerimine ja uuendamine: praktiline võrdlus

Compose loob võrgu iga projekti kohta ja lahendab nimed teenuse kohta. Konteineritega suhtlemine on projekti sees lihtne ja turvaline , kuid väline koormuse tasakaalustamine ja mitme hostimine pole selle sisseehitatud funktsioonid.

Kuberneteses pakuvad teenused DNS-i avastamist ja koormuse tasakaalustamist klastri sees; väljapoole saate HTTP/S-liikluse suunamiseks kasutada LoadBalancerit, NodePorti või Ingressi.

Skaleerimine: Komponeeri skaleerimisi käsitsi ja ainult ühel hostil. Kubernetes skaleerub horisontaalselt HPA abil ja programmiliselt mõõdikute ja/või sündmuste abil. See saab kasvada ka rohkemate sõlmedeni, kui klaster seda lubab.

Värskendused: Compose'is on need tavaliselt käsitsi taasloomised. K8s teeb jooksvaid värskendusi edenemise kontrolliga (kubectl rollout) ja võimalusega taastada, kui midagi valesti läheb, minimeerides selle mõju.

Isetervendamine: Compose saab konteinereid taaskäivitada, kuid see ei lahenda hosti või käitusaja krahhe. Kubernetes paigutab Podid kasutajate jaoks läbipaistvalt ümber tervetesse sõlmedesse .

Arendaja tootlikkus ja operatiivkogemus

Compose on õhuke kiht Dockeri peal. See on kiirelt õpitav ja selle tagasisideahel on kohene , ideaalne iteratsiooniks.

Kubernetes lisab uusi kontseptsioone (Podid, juurutused, teenused, ingress, konfiguratsioonikaardid, PVC-d jne). Õppimiskõver on küll aeg, aga vastutasuks saate täpse kontrolli juurutuste, turvalisuse, jälgitavuse ja skaleeritavuse üle.

Ühilduvuse osas on Compose „Docker-keskne“. Kubernetes toetab erinevaid käituskeskkondi ja integreerub pilveteenuse pakkujatega , mis on oluline ettevõtetele, kellel on mitme pilve või hübriidstrateegiad.

Docker Compose'ilt Kubernetesile migreerimine ilma hulluks minemata

Millal migreerida? Kui teie rakendus pole enam "väike", vajate mitmesõlmelist tuge, jälgitavust, skaleeritavust ja kõrget käideldavust või teilt küsitakse nn. "canary" ja "sinirohelisi" juurutusi.

Tüüpilised väljakutsed: teenindusvõrgu kaardistamine, PV/PVC-ga salvestusruumi kujundamine , konfiguratsiooni eraldamine konfiguratsioonikaartideks/salajateks ning iga konteineri tervise- ja valmisolekumustrite ülevaatamine.

Samuti tuleb ümber mõelda arhitektuur: Pod kui juurutusüksus , teenused lõpp-punktide paljastamiseks ja ressursid konteineri kohta (CPU/Mem), et ajastaja saaks oma tööd teha.

Komponeerimine: komponeerimisest K8s-ini vaid mõne sammuga

Kompose teisendab docker-compose.yml failid Kubernetes'i või OpenShift'i manifestideks. See on kõige otsesem viis migratsiooni alustamiseks ilma kogu YAML-i käsitsi ümber kirjutamata.

Enne alustamist on vaja Kubectl-klastrit ja konfigureeritud kubectl-i. Kui testid midagi olekuga, on soovitatav vähemalt kaks töösõlme (mitte juhtimistasandit). Kontrolli oma versiooni käsuga `kubectl version`.

Paigaldamine: Soovitatav meetod on binaarfaili allalaadimine GitHubi uusimast versioonist. Võite kasutada ka tarballi, macOS-is Homebrew'd või "go get" (viimane variant kasutab arenduses tehtud muudatustega master-faili).

Põhiline teisendamine: navigeeri kataloogi docker-compose.yml ja käivita :

kompose convert
kubectl apply -f <archivos-generados>

Kompose genereerib juurutused ja teenused vaikimisi. Logi loetleb tavaliselt kõik loodud failid ja pärast rakendamist näete klastris juurutuste ja teenuste olekut "loodud".

Ligipääs: Kui kasutate Minikube'i, saate teenuseid hõlpsalt avaldada või päringuid esitada. Pilves kontrollige LoadBalanceri teenuse avaliku IP-aadressi saamiseks valikut „LoadBalancer Ingress”; NodePorti abil on teil sõlmedel avatud port.

Puhastamine: Kui olete testi lõpetanud, eemaldage rakendatud ressursid. Hoidke oma klaster puhtana, et vältida konflikte iteratsioonide vahel.

Kompose'i täpsemad valikud (pakkujad, objektid ja sildid)

Kompose toetab Kubernetes'i ja OpenShift'i. Kui te ei täpsusta "--provider", kasutab see vaikimisi Kubernetes'i . OpenShiftiga saab see genereerida DeploymentConfigs'e ja ImageStreame'e ning isegi BuildConfigs'e, kui kasutate ehitusdirektiive.

See toetab ka mitmesuguseid väljundeid: JSON koos valikuga "-j", ReplicationControllers, DaemonSets või Helm Charts . Lipp "--replicas" võimaldab muuta RC-des replikaatide arvu; Helmi puhul genereerib see põhilise diagrammistruktuuri.

Komposeerimisprotsessis olevad komposiidispetsiifilised sildid mõjutavad teisendamist. Näiteks saate määrata teenuse tüübi või selle, kas avaldada lõpp-punkt sisenemis-/marsruudi kaudu.

Silt	Väärtused
kompose.service.type	nodeport/clusterip/loadbalancer
kompose.service.expose	tõene / hostinimi

Tasub meeles pidada: „_”-ga tähistatud nimed teisendatakse „-”-ks (K8s ei luba alakriipse) ja kui teenus kasutab köiteid, muutub juurutamisstrateegia väärtuseks „Uuesti loomine”, et vältida konflikte mitme kirjutajaga.

Kompose toetab mitut versiooni ja faili

Kompose toetab Compose'i versioone 1, 2 ja 3 (piiratud toega versioonidele 2.1 ja 3.2 nende eksperimentaalse olemuse tõttu). Kui edastate korraga mitu Docker-Compose'i faili, siis need ühendatakse ja ühised elemendid kirjutatakse uusima failiga üle, täpselt nagu ülekirjutuse korral.

Kubernetes'i teisendamise ajal näete ühildumatute võtmete olemasolu korral teateid, näiteks „WARN Unsupported key build – ignoring” (HOIATUS: Toetamata võtme loomine – ignoring). Ärge muretsege, tööriist jätkab sellega, millest aru saab, ja jätab ülejäänu hilisemaks käsitsi kohandamiseks.

Kompose'ist kaugemale: Move2Kube ja käsitsi migreerimine

Kui vajate suuremat kontrolli, on olemas tööriistad nagu Move2Kube, mis analüüsivad teie koostamisfaili ja genereerivad täpsemaid Kubernetesi artefakte. Need on kasulikud, kui soovite oma platvormilt ärimustreid või malle kohandada.

Manuaalne migreerimine on täiesti sobiv ja peaaegu alati soovitatav pärast esialgset migreerimist. Tüüpilised sammud hõlmavad järgmist: teenuste teisendamine Deployments/StatefulSets-iks , võrkude teisendamine Services/Ingress-iks ja köidete teisendamine PV/PVC-ks koos salvestusklassidega.

Minimaalne näide Compose'i teenuse teisendamisest juurutamiseks võib välja näha selline: portide, pildi ja siltide ülekandmine Pod-mallile:

# docker-compose.yml
version: '3'
services:
  web:
    build: .
    ports:
      - '8000:8000'
    depends_on:
      - db

# Kubernetes
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: my-web-image
          ports:
            - containerPort: 8000

Oleku (andmebaasid, järjekorrad) puhul kaaluge StatefulSets ja PersistentVolumes funktsioone. Kõik, mis Compose'is "koos" käis, ei peaks minema samasse Pod'i ; eraldage vastutusalad ja kasutage komponentide vaheliseks suhtlemiseks teenuseid.

Andmestsenaariumid: voogedastus, partiitöötlus ja haldamine

Keerulistes andmekanalites sobib K8s ideaalselt: Jobid pakktöötluste jaoks, CronJobid ajaakende jaoks , API-de juurutused ja operaatorid sellistele süsteemidele nagu Kafka, Spark või Flink.

Striimimise ja andmebaaside puhul hõlbustavad käivitamist kogukonna operaatorid ja diagrammid. Service Mesh võrk ja ressursside kontroll tagavad ühe hostiga lahendusega võrreldes prognoositavamad latentsusajad ja SLO-d.

Andmehalduse ja -turbe valdkonnas pakub Kubernetes nimeruume, poliitikaid ja RBAC-juhtimist keskkondade auditeerimiseks ja eraldamiseks. See on praktiline eelis Compose'i lokaalse lähenemisviisi ees.

Parimad tavad ja väikesed operatiivsed nipid

Koostamisel: hoia oma YAML väikese ja modulaarsena ; kasuta keskkonnamuutujaid ja .env-faile; dokumenteeri pordid ja sõltuvused; ning kajasta CI-s seda, mida sa lokaalselt käitad.

Kuberneteses: määratle protsessori ja mälu taotlused/piirangud , kasuta valmisoleku/elujõu sonde, eralda konfiguratsioon ConfigMapsideks/salajateks ja rakenda igale teenusele sobivaid juurutamisstrateegiaid.

Kubecki värskenduste puhul: kasutage edusammude jälgimiseks ja probleemide korral tagasipööramiseks käske `kubectl set image` ja `kubectl rollout status` . See hoiab ära seisakuid tootmises.

Kui vajate Compose'is konkreetseid töid, saate neid simuleerida, aga Kuberneteses on see CronJobs/Jobsiga puhtam ; te ei risusta konteinereid lisaprotsesside ega host-cronidega.

Kiire KKK segaduse vältimiseks

Kas Compose asendab Kubernetes'i? Ei. Compose lihtsustab mitme konteineriga pinu haldamist ühel hostil; Kubernetes orkestreerib klastri skaalal kõrge käideldavusega.

Kas Compose'i kasutatakse ikka veel? Jah, väga palju. See on ideaalne arendus- ja testimistööriist terviklike keskkondade loomiseks vaid paari käsuga.

Kas Kubernetes on Dockerist "parem"? Need on erinevad asjad: Docker on konteinerplatvorm ; Kubernetes koordineerib neid klastris ja lisab täiustatud toiminguid.

Kas ma saan oma Compose'i Kubernetesesse tuua ilma seda käsitsi ümber kirjutamata? Jah, Kompose'i või Docker Desktopi integratsiooniga. See annab sulle kiire esimese sammu , mida saad seejärel täpsustada.

Peened detailid: programmeerimine, OpenShift ja alternatiivsed konversioonid

K8s ei ole lihtsalt pidev juurutamine: Jobs ja CronJobs hõlmavad ühekordseid või planeeritud ülesandeid ilma, et peaksite süsteemi cron'e haldama.

OpenShiftis saab Kompose genereerida DeploymentConfig'e ja ImageStreame ning isegi BuildConfig'e, kui Compose'il oli Giti repositooriumiga seotud ehitus. Allika kohandamiseks kasutatakse lippe „--build-repo” ja „--build-branch”.

Kui soovite teistsugust väljundit, lubab Kompose vaikimisi juurutuste ja teenuste asemel kasutada DaemonSet'e, ReplicationControllereid või Helm Chart'e . See suudab genereerida ka JSON-i, mitte ainult YAML-i.

Ühilduvus, hoiatused ja väiksemad probleemid

Kompose toetab Compose'i versioone V1/V2/V3 (piirangutega versioonides 2.1 ja 3.2). Toetamata võtmeid ignoreeritakse ja neile antakse hoiatus (WARN) , jättes ruumi käsitsi kohandamiseks.

Kui teie teenusel on köiteid, muudab Kompose strateegiaks „Loo uuesti”, et vältida samaaegset kasutamist samal köitel . See on olekuga teenuste puhul tavaline.

Nimedes olevad alakriipsud teisendatakse sidekriipsudeks. See on Kubernetes'i piirang objektinimedele , seega veenduge, et nimetaksite need Compose'is õigesti, et vältida teisendamise ajal üllatusi.

Väljastpoolt juurdepääsuks kontrollige teenuse tüüpi: ClusterIP (sisemine), NodePort (port sõlmedel) või LoadBalancer (avalik IP pilves). Ingressi abil on teil puhtad HTTP/S marsruudid ja tsentraliseeritud TLS.

Minikube'is testides tagastavad sellised käsud nagu „minikube service <svc> –url” kiire URL-i . Cloudis vaata teenuse kirjeldamisel välja „LoadBalancer Ingress”.

Üks huvitav punkt: kogukonnas leiab viiteid Kubernetes'i profiilide palkadele ja ligi 88% kasutuselevõtu määradele tootmiskeskkondades. Midagi ebatavalist pole: see on de facto standard.

Pildi lõpuleviimiseks on Kubernetes enamat kui HTTP: Service Mesh, operaatorid ja CRD-d laiendavad Kubernetes'i ulatust. Kui kasutate Compose'i, on normaalne alguses tunda end ülekoormatuna, kuid see lisavõimsus tähendab töökindlamaid toiminguid.

Lähtestamispoliitikad: kasulikud ekvivalentsused

Koostamine lubab taaskäivitamist: alati/rikke korral/ei. Kuberneteses on teil olenevalt juhtumist individuaalsed Podid või kontrollerid (juurutused või RC) koos sobivate taaskäivituspoliitikatega.

docker-compose taaskäivitamine	Objekt K8s-is	taaskäivituspoliitika
«» / alati	Kontroller (juurutamine/RC)	Alati
rikke korral	Kaun	Ebaõnnestumisel
ei	Kaun	Mitte kunagi

Kui sul oli Compose'is "arvutuskonteinereid" või ajutisi ülesandeid (näiteks kiire "pi"), siis rakenda see lihtsalt K8s-is Job- või CronJob-tüüpi ülesandena vastava poliitikaga ja oledki valmis.

Valige Compose kiireteks kohalikeks juurutusteks ja Kubernetes, kui teie keskkond nõuab rohkem võimsust: mitme sõlme tugi, automaatne skaleerimine, sujuvad juurutused ja tõeline vastupidavus . Compose'i, Move2Kube'i ja väikese hoolikusega on üleminek sujuv.

Lõppkokkuvõttes sõltub valik ulatusest ja keerukusest: Compose sobib suurepäraselt arendamiseks, testimiseks ja ühe hosti süsteemide jaoks ; Kubernetes on parim valik ettevõtetele, mitme pilve juurutustele ja meeskondadele, kes vajavad täiustatud automatiseerimist, kõrget käideldavust ja tuhandete integratsioonidega ökosüsteemi.