Docker Compose proti Kubernetes: kdaj uporabiti katerega od njih, razlike in migracija

Informatec Digital » Viri » Docker Compose proti Kubernetes: kdaj uporabiti katerega od njih, razlike in migracija

Če delate s kontejnerji, se prej ali slej pojavi veliko vprašanje: Docker Compose ali Kubernetes? Obe orodji se uporabljata v življenjskem ciklu kontejneriziranih aplikacij , vendar nista zasnovani za reševanje popolnoma enakih problemov ali v istem kontekstu. V tem članku ju bomo podrobno primerjali s praktičnimi primeri, scenariji iz resničnega sveta in nasveti za nemoten prehod z enega na drugega.

Poleg tehnološke zasnove odločitev vpliva tudi na vsakodnevno poslovanje: čas uvajanja, skalabilnost , odpornost, varnost in stroške . Vpliva tudi na tipične primere uporabe podatkovnega inženiringa – cevovode, baze podatkov, pretakanje, paketno obdelavo, formate podatkov in upravljanje – kjer orkestracija bistveno vpliva na produktivnost.

Kaj sta Docker in Docker Compose (in čemu sta pravzaprav namenjena)?

Ko govorimo o Dockerju, v resnici govorimo o ekosistemu: Docker Engine, Docker Hub, Dockerfile, Docker Compose … Mehanizem ustvarja in izvaja vsebnike iz slik; Hub omogoča enostavno skupno rabo; Compose pa vam omogoča, da v datoteki YAML definirate več delov sklada, da jih zaženete z enim samim ukazom.

Compose je bil ustvarjen, da nas reši neskončnih skriptov in izoliranih ukazov. Z eno samo datoteko docker-compose.yml opišete storitve, omrežja in nosilce podatkov , vse pa zaženete z enim samim ukazom »docker compose up« (ali »docker-compose up« v V1). Idealno za lokalni razvoj, integrirano testiranje, predstavitve ali okolja CI.

Kanoničen primer uporabe programa Compose je lahko tale, z API-jem in podatkovno bazo Postgres. Bodite pozorni na to, kako so odvisnosti, spremenljivke in vrata deklarirane v berljivem bloku:

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

Za ročno skaliranje v Composeu lahko uporabite možnost skaliranja v storitvi. V Composeu V2 je to običajno mogoče storiti z `up --scale` (v V1 je bilo `docker-compose scale`):

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

Pazite na omejitve: Compose je zasnovan za en sam gostitelj , ne uravnava obremenitve med vozlišči ali samodejno skalira, posodobitve pa so običajno ročne reprodukcije vsebnikov z "build" in "up -d".

Kaj je Kubernetes in kaj ponuja v primerjavi s Composeom?

Kubernetes (K8s) je platforma za orkestracijo porazdeljenih kontejnerjev. Upravlja uvedbe v velikem obsegu v večvozličnih gručah s koncepti, kot so Podi, Uvedbe in Storitve za upravljanje produkcijskih delovnih obremenitev.

V Kubernetesu ne upravljate posameznih vsebnikov, temveč upravljate pode (ki lahko vsebujejo enega ali več vsebnikov). Nadzorna ravnina načrtuje, kje se vsak pod izvaja , izpostavlja storitve, distribuira promet, horizontalno skalira in spremlja stanje delovnih obremenitev.

Osnovna namestitev bi lahko izgledala takole, s 3 replikami spletne storitve. Določite predloge, oznake in izpostavljena vrata :

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

Za izpostavljanje z uravnoteženjem obremenitve je v oblaku tipična storitev LoadBalancer. Selektor ujema oznake Poda z usmerjanjem prometa.

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

V produkciji Kubernetes blesti z zmogljivostmi, kot so visokozmogljiva avtomatizacija (HPA), posodobitve in samoobnovitev. HPA prilagaja replike na podlagi metrik (npr. porabe procesorja) :

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

Zdravje kontejnerja se spremlja s sondami; če te odpovejo, K8s znova zažene kontejner. To je osnova "samozdravljenja" :

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

Ključne podobnosti in razlike (bistvene stvari brez ovinkarjenja)

Skupno jim je: delo z vsebniki in definiranje uvajanj prek YAML. Obe rešitvi sta uporabni za razvijalce in operaterje ter se zelo dobro dopolnjujeta v delovnem toku dev→prod.

Ključna razlika je v obsegu: Compose je osredotočen na Docker in ima enega gostitelja ; Kubernetes podpira več izvajalnih okolij in gruče z več vozlišči, z neposredno integracijo v oblake in upravljane storitve.

Pomembnejše razlike: Kubernetes ponuja samodejno skaliranje, posodobitve in samozdravljenje ; Compose tega ne omogoča. Kubernetes se abstrahira s Pod-i; Compose neposredno komunicira z Dockerjevimi vsebniki.

Poleg tega Kubernetes vključuje opravila (Jobs) in cronJob-e za enkratna ali načrtovana opravila. S tem se izognemo sistemskim cron opravilom in dodatnim vsebnikom vgrajenim procesom , platforma pa ostaja naravno mesto za definiranje avtomatizacij.

Na lokaciji podjetja Compose zmaga v smislu hitrosti in preprostosti. Za skaliranje na stotine vozlišč ali večoblačna okolja je Kubernetes logična izbira . Compose lahko izkoristi Docker Swarm za uvajanje na več gostiteljev, vendar njegova stopnja sprejemanja in zmogljivosti ne ustrezajo ekosistemu in zrelosti Kubernetes.

Zakaj potrebujete orkestracijo (in kdaj je vsaka najbolj primerna)

Dober orkestrator vam nudi: enotno zagotavljanje in uvajanje, načrtovane zagone, komunikacijo med storitvami , uravnoteženje obremenitve in dodatno varnost z dodatnim upravljanjem posameznih storitev.

Compose pokriva osnove na poenostavljen in berljiv način, zaradi česar je odlično orodje za razvoj, testiranje in predstavitve. Vendar pa njegove omejitve postanejo očitne, ko potrebujete več vozlišč, izvorno uravnoteženje obremenitve in samodejno skaliranje ali inkrementalne uvedbe brez izpadov.

Kubernetes pa je "platforma", ko obremenitev narašča: večvozlišče, samodejno skaliranje, visoka razpoložljivost in ogromen ekosistem z izvorno podporo za AWS, Azure, GCP in upravljane možnosti.

Primeri uporabe iz resničnega sveta (razvoj, podatki in drugo)

Compose blesti na področjih: ponovljivih lokalnih okolij, testiranja E2E, CI/CD in usposabljanja . Definiranje celotnega sklada v YAML in njegov zagon z enim samim ukazom odpravi veliko šuma.

Kubernetes je idealen za: produkcijske aplikacije, internet stvari in robno računalništvo, velike podatke in strojno učenje ter več/hibridna oblačna okolja. Upravlja porazdeljene delovne obremenitve, kjer so pomembne latenca, odpornost in opazovalnost.

V podatkovnem inženirstvu je K8s odličen za pretakanje in paketno obdelavo podatkov, baze podatkov, čakalne vrste in analitične mehanizme , z nadzorom virov na posamezen pod in samodejnim skaliranjem ob konicah.

Če je vaš projekt majhen in se prilega enemu gostitelju, bo Compose brez težav opravil delo. Ko pa vaša uporabniška baza raste in potrebujete resno toleranco napak in uravnoteženje obremenitve , je čas, da razmislite o Kubernetes.

Mreženje, skaliranje in nadgradnje: praktična primerjava

Compose ustvari omrežje za vsak projekt posebej in razreši imena za vsako storitev posebej. Komunikacija z vsebniki je znotraj projekta preprosta in varna , vendar zunanje uravnoteženje obremenitve in večgostovanje nista izvorni funkciji.

V Kubernetes storitve ponujajo odkrivanje DNS in uravnoteženje obremenitve znotraj gruče; navzven lahko za usmerjanje prometa HTTP/S uporabite LoadBalancer, NodePort ali Ingress.

Skaliranje: Compose se skalira ročno in samo na enem gostitelju. Kubernetes se skalira vodoravno s HPA in programsko z metrikami in/ali dogodki. Lahko se razširi tudi na več vozlišč, če gruča to dopušča.

Posodobitve: V Composeu so to običajno ročne rekonstrukcije. K8s izvaja tekoče posodobitve z nadzorom napredka (uvajanje kubectl) in možnostjo razveljavitve, če gre kaj narobe, kar zmanjšuje vpliv.

Samopopravljanje: Compose lahko znova zažene vsebnike, vendar ne odpravi zrušitev gostitelja ali izvajalnega okolja. Kubernetes premakne pode na zdrava vozlišča , pregledno za uporabnike.

Produktivnost razvijalcev in operativne izkušnje

Compose je tanka plast na vrhu Dockerja. Hitro se ga je naučiti, njegova povratna zanka pa je takojšnja , kar je idealno za iteracije.

Kubernetes dodaja nove koncepte (Pods, Deployments, Services, Ingress, ConfigMaps, PVCs itd.). Obstaja krivulja učenja, vendar v zameno pridobite podroben nadzor nad deploymenti, varnostjo, opazovalnostjo in skalabilnostjo.

Kar zadeva združljivost, je Compose »Docker-first«. Kubernetes podpira različna izvajalna okolja in se integrira s ponudniki oblaka , kar je ključnega pomena za podjetja z večoblačnimi ali hibridnimi strategijami.

Selitev iz Docker Compose v Kubernetes brez pretiravanja

Kdaj seliti? Ko vaša aplikacija ni več "majhna", potrebujete večvozlišče, opazovalnost, skalabilnost in visoko razpoložljivost ali pa se od vas zahtevajo kanarčkovske in modro/zelene uvedbe.

Tipični izzivi: kartiranje servisnega omrežja, načrtovanje shranjevanja s PV/PVC , ločevanje konfiguracije na ConfigMaps/Secrets in pregled vzorcev zdravja in pripravljenosti vsakega vsebnika.

Prav tako je treba ponovno pretehtati arhitekturo: Pod kot enoto za uvajanje , storitve za izpostavljanje končnih točk in vire na vsebnik (CPU/Mem), da lahko razporejevalnik opravlja svoje delo.

Kompose: od Compose do K8s v nekaj korakih

Kompose pretvori datoteke docker-compose.yml v manifeste Kubernetes ali OpenShift. To je najbolj neposreden način za začetek migracije brez ročnega prepisovanja celotne datoteke YAML.

Preden začnete, potrebujete gručo Kubectl in konfiguriran kubectl. Če testirate karkoli, kar ohranja stanje, sta priporočljivi vsaj dve delovni vozlišči (ne kontrolni ravnini). Preverite svojo različico z `kubectl version`.

Namestitev: Priporočena metoda je prenos binarne datoteke iz najnovejše izdaje GitHub-a. Uporabite lahko tudi tarball, Homebrew v sistemu macOS ali »go get« (zadnja možnost uporablja glavno datoteko s spremembami v razvoju).

Osnovna pretvorba: pojdite v imenik docker-compose.yml in zaženite :

kompose convert
kubectl apply -f <archivos-generados>

Kompose privzeto ustvari uvedbe in storitve. Dnevnik običajno navaja vse ustvarjene datoteke , po uporabi pa boste v gruči videli, da so uvedbe in storitve »ustvarjene«.

Dostop: Če uporabljate Minikube, lahko preprosto izpostavite ali poizvedujete storitve. V oblaku preverite »LoadBalancer Ingress« , da dobite javni IP-naslov storitve LoadBalancer; z NodePort boste imeli odprta vrata na vozliščih.

Čiščenje: Ko končate s testom, odstranite uporabljene vire. Ohranite čisto gručo, da se izognete konfliktom med iteracijami.

Napredne možnosti Kompose (ponudniki, objekti in oznake)

Kompose podpira Kubernetes in OpenShift. Če ne določite »--provider«, bo privzeto uporabil Kubernetes . Z OpenShift lahko ustvari konfiguracije za deploymentconfigs in slikovne tokove (ImageStreams) ter celo konfiguracije za build, če uporabljate direktive za build.

Podpira tudi različne izhode: JSON z "-j", ReplicationControllers, DaemonSets ali Helm Charts . Zastavica "--replicas" vam omogoča spreminjanje števila replik v RC-jih; za Helm generira osnovno strukturo grafikona.

Oznake, specifične za Kompose, znotraj procesa sestavljanja vplivajo na pretvorbo. Na primer, lahko določite vrsto storitve ali ali želite končno točko izpostaviti prek vhoda/poti.

Oznaka	Vrednosti
vrsta.storitve.kompose	nodeport/clusterip/loadbalancer
kompose.storitev.razkritje	true / ime gostitelja

Podrobnosti, ki jih je treba upoštevati: imena z »_« se pretvorijo v »-« (K8s ne dovoljuje podčrtajev) in če storitev uporablja nosilce podatkov, se strategija uvajanja spremeni v »Ponovno ustvari«, da se izognemo konfliktom z več pisci.

Kompose podpira več različic in datotek

Kompose podpira Compose V1, V2 in V3 (z omejeno podporo za različici 2.1 in 3.2 zaradi njune eksperimentalne narave). Če hkrati posredujete več datotek docker-compose, se združijo in skupni elementi se prepišejo z najnovejšo, tako kot bi to storili pri prepisu.

Med pretvorbo Kubernetes boste videli sporočila, kot je »OPOZORILO: Nepodprta gradnja ključev – ignoriranje«, če obstajajo nezdružljivi ključi. Brez skrbi, orodje bo nadaljevalo s tem, kar razume , ostalo pa bo pustilo za kasnejšo ročno prilagoditev.

Onkraj Komposeja: Move2Kube in ročna migracija

Če potrebujete več nadzora, so na voljo orodja, kot je Move2Kube, ki analizirajo vaše sporočilo Compose in ustvarijo natančneje prilagojene artefakte Kubernetes. Uporabna so, kadar želite prilagoditi poslovne vzorce ali predloge s svoje platforme.

Ročna migracija je povsem veljavna in skoraj vedno priporočljiva po začetni migraciji. Tipični koraki vključujejo: pretvorbo storitev v Deployments/StatefulSets , omrežij v Services/Ingress in nosilcev v PV/PVC s razredi shranjevanja.

Minimalni primer pretvorbe storitve Compose v storitev Deployment bi lahko izgledal takole: prenos vrat, slike in oznak v predlogo Pod:

# 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

Za stanje (baze podatkov, čakalne vrste) razmislite o StatefulSets in PersistentVolumes. Vse, kar je šlo "skupaj" v Compose, ne sme iti v isti Pod ; ločite odgovornosti in uporabite Services za komunikacijo med komponentami.

Scenariji podatkov: pretakanje, paketno obdelavo in upravljanje

V kompleksnih podatkovnih cevovodih se K8s prilega kot ulitica: opravila za paketne procese, CronJob-i za časovna okna , uvajanja za API-je in operatorji za sisteme, kot so Kafka, Spark ali Flink.

Za pretakanje in baze podatkov operaterji skupnosti in grafikoni olajšajo zagon. Omrežje Service Mesh in nadzor virov zagotavljata bolj predvidljive zakasnitve in SLO v primerjavi z rešitvijo z enim gostiteljem.

Na področju upravljanja in varnosti podatkov Kubernetes ponuja imenske prostore, pravilnike in nadzor RBAC za revidiranje in ločevanje okolij. To je praktična prednost pred lokalnim pristopom Compose.

Najboljše prakse in majhni operativni triki

V Composeu: naj bo vaš YAML majhen in modularen ; uporabljajte okoljske spremenljivke in datoteke .env; dokumentirajte vrata in odvisnosti; in v CI odražajte, kaj izvajate lokalno.

V Kubernetes: definirajte zahteve/omejitve CPU in pomnilnika , uporabite sonde pripravljenosti/življenje, ločite konfiguracijo v ConfigMaps/Secrets in uporabite ustrezne strategije uvajanja za vsako storitev.

Za posodobitve Kubecka: uporabite `kubectl set image` in `kubectl rollout status` za spremljanje napredka in povrnitev napake, če gre kaj narobe. To bo preprečilo izpade v produkciji.

Če v Composeu potrebujete določena opravila, jih lahko simulirate, v Kubernetesu pa je s CronJobs/Jobs čistejše ; ne zatrpavate vsebnikov z dodatnimi procesi ali gostiteljskimi croni.

Kratka vprašanja in odgovori, da se izognete zmedi

Ali Compose nadomešča Kubernetes? Ne. Compose poenostavlja večkontejnerne sklade na enem gostitelju; Kubernetes orkestrira na ravni gruče z visoko razpoložljivostjo.

Se Compose še vedno uporablja? Da, zelo pogosto. Je idealno orodje za razvoj in testiranje za nastavitev celotnih okolij z le nekaj ukazi.

Je Kubernetes "boljši" od Dockerja? Gre za dve različni stvari: Docker je platforma za kontejnerje ; Kubernetes jih orkestrira v gručo in dodaja napredne operacije.

Ali lahko prenesem svoj Compose v Kubernetes, ne da bi ga ročno prepisal? Da, z integracijo Kompose ali Docker Desktop. To vam omogoča hiter prvi korak , ki ga lahko nato izboljšate.

Podrobnosti: programiranje, OpenShift in alternativne pretvorbe

K8s ni le neprekinjeno uvajanje: opravila in CronJobs pokrivajo enkratne ali načrtovane naloge, ne da bi vam bilo treba upravljati sistemske crone.

V OpenShiftu lahko Kompose ustvari konfiguracije za razporeditev (DeploymentConfigs) in slikovne tokove (ImageStreams), pa tudi konfiguracije za gradnjo (BuildConfigs), če je Compose imel gradnjo, povezano z repozitorijem Git. Zastavici »--build-repo« in »--build-branch« se uporabljata za prilagajanje izvorne kode.

Če želite drugačen izhod, Kompose namesto privzetih uvedb in storitev omogoča uporabo DaemonSets, ReplicationControllers ali Helm Charts . Lahko ustvari tudi JSON, ne le YAML.

Združljivost, opozorila in manjše težave

Kompose podpira Compose V1/V2/V3 (z omejitvami v različicah 2.1 in 3.2). Nepodprte tipke so prezrte z opozorilom WARN , kar pušča prostor za ročne nastavitve.

Če ima vaša storitev nosilce podatkov, Kompose spremeni strategijo na »Ponovno ustvari«, da se izogne ​​sočasnosti na istem nosilcu podatkov . To je običajno za storitve, ki ohranjajo stanje.

Podčrtaji v imenih se pretvorijo v vezaje. To je omejitev Kubernetesa za imena objektov , zato se prepričajte, da jih v Composeu pravilno poimenujete, da se izognete presenečenjem med pretvorbo.

Za dostop od zunaj preverite vrsto storitve: ClusterIP (interni), NodePort (vrata na vozliščih) ali LoadBalancer (javni IP v oblaku). Z Ingressom boste imeli čiste poti HTTP/S in centraliziran TLS.

Če testirate v Minikubeu, bodo ukazi, kot je »minikube service <svc> –url«, vrnili hiter URL . V oblaku pri opisovanju storitve bodite pozorni na polje »LoadBalancer Ingress«.

Zanimiva točka: znotraj skupnosti boste našli reference na plače za profile Kubernetes in stopnje uporabe blizu 88 % v produkcijskih okoljih. Nič nenavadnega: to je dejanski standard.

Za popolno sliko, Kubernetes ponuja več kot le HTTP: Service Mesh, operatorji in CRD- ji razširjajo doseg Kubernetesa. Če prihajate s Composea, je normalno, da se sprva počutite preobremenjeni, vendar se ta dodatna moč prevede v robustnejše delovanje.

Ponastavitev pravilnikov: uporabne ekvivalente

Compose omogoča »ponovni zagon: vedno/ob-napaki/ne«. V Kubernetes boste imeli, odvisno od primera, posamezne pode ali krmilnike (Deployments ali RC) z ustreznimi pravilniki za ponovni zagon.

ponovni zagon docker-compose	Predmet v K8s	pravilnik o ponovnem zagonu
«» / vedno	Krmilnik (uvajanje/RC)	Vedno
ob okvari	Pod	ObNeuspehu
št	Pod	Nikoli ne

Če ste v Composeu imeli vsebnike za "izračun" ali kratkotrajne naloge (kot je hiter "pi"), jih preprosto implementirajte v K8s kot opravilo ali CronJob z ustrezno politiko in vse je pripravljeno.

Za hitre lokalne uvedbe izberite Compose, za uvedbe Kubernetes pa, ko vaše okolje zahteva več moči: podporo za več vozlišč, samodejno skaliranje, brezhibne uvedbe in resnično odpornost . S Compose, Move2Kube in malo previdnosti je prehod gladek.

Končna izbira je odvisna od obsega in kompleksnosti: Compose je odličen za razvoj, testiranje in enogostiteljske sklade ; Kubernetes je prava izbira za podjetja, uvedbe v več oblakih in ekipe, ki potrebujejo napredno avtomatizacijo, visoko razpoložljivost in ekosistem s tisoči integracij.