Docker Compose vs Kubernetes: Kad katru lietot, atšķirības un migrācija

Informatec Digital » Resursi » Docker Compose vs Kubernetes: Kad katru lietot, atšķirības un migrācija

Ja strādājat ar konteineriem, agrāk vai vēlāk rodas lielais jautājums: Docker Compose vai Kubernetes? Abi rīki tiek izmantoti konteinerizētu lietojumprogrammu dzīves ciklā , taču tie nav paredzēti tieši tādu pašu problēmu risināšanai vai vienā un tajā pašā kontekstā. Šajā rakstā mēs tos padziļināti salīdzinām, sniedzot praktiskus piemērus, reālās pasaules scenārijus un padomus, kā vienmērīgi migrēt no viena uz otru.

Papildus tehnoloģiskajai izvietošanai šis lēmums ietekmē ikdienas darbības: izvietošanas laikus, mērogojamību , noturību, drošību un izmaksas . Tas ietekmē arī tipiskus datu inženierijas lietošanas gadījumus — cauruļvadus, datubāzes, straumēšanu, pakešapstrādi, datu formātus un pārvaldību —, kur orķestrēšana rada būtisku atšķirību produktivitātes ziņā.

Kas ir Docker un Docker Compose (un kam tie īsti paredzēti)?

Kad mēs runājam par Docker, mēs patiesībā runājam par ekosistēmu: Docker Engine, Docker Hub, Dockerfile, Docker Compose … Dzinējs izveido un palaiž konteinerus no attēliem; Hub atvieglo to koplietošanu; un Compose ļauj definēt vairākas steka daļas YAML failā, lai tās palaistu ar vienu komandu.

Compose tika izveidots, lai mūs pasargātu no nebeidzamiem skriptiem un izolētām komandām. Ar vienu docker-compose.yml failu jūs aprakstāt pakalpojumus, tīklus un sējumus , un visu varat darbināt ar vienu "docker compose up" (vai "docker-compose up" V1 versijā). Ideāli piemērots lokālai izstrādei, integrētai testēšanai, demonstrācijām vai CI vidēm.

Kanonisks Compose piemērs varētu būt šis, ar API un Postgres datubāzi. Ievērojiet, kā atkarības, mainīgie un porti tiek deklarēti lasāmā blokā:

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

Lai manuāli mērogotu pakalpojumā Compose, varat izmantot pakalpojuma mērogošanas opciju. Compose 2. versijā to parasti dara ar `up --scale` (1. versijā bija `docker-compose scale`):

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

Ņemiet vērā ierobežojumus: Compose ir paredzēts vienam resursdatoram , tas nenodrošina slodzes balansēšanu starp mezgliem vai automātisku mērogošanu, un atjauninājumi parasti ir manuāla konteineru atjaunošana ar "build" un "up -d".

Kas ir Kubernetes un ko tas piedāvā salīdzinājumā ar Compose?

Kubernetes (K8s) ir izkliedēta konteineru orķestrēšanas platforma. Tā pārvalda izvietošanu plašā mērogā vairāku mezglu klasteros , izmantojot tādus konceptus kā Pods, Deployments un Services, lai pārvaldītu ražošanas darba slodzes.

Kubernetes vidē jūs nepārvaldāt atsevišķus konteinerus; jūs pārvaldāt Podus (kuri var saturēt vienu vai vairākus konteinerus). Vadības plakne ieplāno katra Poda darbību , nodrošina pakalpojumu pieejamību, sadala trafiku, horizontāli mērogo un uzrauga darba slodžu stāvokli.

Pamata izvietošana varētu izskatīties šādi ar 3 tīmekļa pakalpojuma kopijām. Definējiet veidnes, etiķetes un atklātās pieslēgvietas :

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

Lai to varētu izmantot ar slodzes līdzsvarošanu, mākonī parasti tiek izmantots LoadBalancer pakalpojums. Selektors saskaņo Pod etiķetes ar datplūsmas maršrutēšanu.

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

Ražošanas vidē Kubernetes izceļas ar tādām iespējām kā augstas veiktspējas automatizācija (HPA), mainīgie atjauninājumi un pašatjaunošanās. HPA pielāgo kopijas, pamatojoties uz rādītājiem (piemēram, centrālā procesora noslodzi) :

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

Konteinera stāvoklis tiek uzraudzīts ar zondēm; ja tās neizdodas, K8s restartē konteineru. Tas ir "pašdziedināšanās" pamats :

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

Galvenās līdzības un atšķirības (būtiskākais, nepārprotami)

Kas tiem ir kopīgs: tie strādā ar konteineriem un definē izvietojumus, izmantojot YAML. Abi risinājumi ir noderīgi gan izstrādātājiem, gan operatoriem , un tie viens otru ļoti labi papildina izstrādes un ražošanas darbplūsmā.

Būtiskākā atšķirība slēpjas darbības jomā: Compose ir Docker centrēts un paredzēts vienam resursdatoram ; Kubernetes atbalsta vairākas izpildlaika vides un vairāku mezglu klasterus, ar tiešu integrāciju mākoņos un pārvaldītajos pakalpojumos.

Svarīgākas atšķirības: Kubernetes piedāvā automātisko mērogošanu, mainīgos atjauninājumus un pašdziedināšanu ; Compose to nedara. Kubernetes abstrahējas ar Pods; Compose tieši mijiedarbojas ar Docker konteineriem.

Turklāt Kubernetes ietver Jobs un CronJobs vienreizējiem vai ieplānotiem uzdevumiem. Tas ļauj izvairīties no sistēmas cron uzdevumiem un papildu konteinerizētiem procesiem , saglabājot platformu kā dabisku vietu automatizācijas definēšanai.

Lokāli Compose uzvar ātruma un vienkāršības ziņā. Mērogošanai līdz simtiem mezglu vai vairāku mākoņu vidēm Kubernetes ir loģiska izvēle . Compose var izmantot Docker Swarm vairāku saimniekdatoru izvietošanai, taču tā ieviešanas līmenis un iespējas neatbilst Kubernetes ekosistēmai un brieduma pakāpei.

Kāpēc nepieciešama orķestrēšana (un kad katra no tām vislabāk atbilst)

Labs orķestrētājs nodrošina: vienotu nodrošināšanu un izvietošanu, plānotas palaišanas, saziņu starp pakalpojumiem , slodzes līdzsvarošanu un papildu drošību, izmantojot papildu pārvaldību katram pakalpojumam.

Compose aptver pamatus vienkāršotā un lasāmā veidā, padarot to par lielisku rīku izstrādei, testēšanai un demonstrācijām. Tomēr tā ierobežojumi kļūst acīmredzami, kad ir nepieciešami vairāki mezgli, vietējā slodzes līdzsvarošana un automātiskā mērogošana vai pakāpeniska izvietošana bez dīkstāves.

Savukārt Kubernetes ir “platforma”, kad slodze pieaug: vairāku mezglu atbalsts, automātiska mērogošana, augsta pieejamība un gigantiska ekosistēma ar vietējo atbalstu AWS, Azure, GCP un pārvaldītajām iespējām.

Reālās pasaules lietošanas gadījumi (izstrāde, dati un citi)

Compose izceļas ar šādām priekšrocībām: reproducējamas lokālās vides, E2E testēšana, CI/CD un apmācība . Visa steka definēšana YAML valodā un tā palaišana ar vienu komandu novērš daudz trokšņa.

Kubernetes ir ideāli piemērots: ražošanas lietojumprogrammām, lietu internetam (IoT) un perifērijas skaitļošanai, lielajiem datiem un mašīnmācībai , kā arī vairāku/hibrīdu mākoņvidēm. Tas pārvalda izkliedētas darba slodzes, kurās svarīga ir latentums, noturība un novērojamība.

Datu inženierijā K8s ir ideāli piemērots straumēšanas un pakešu cauruļvadiem, datubāzēm, rindām un analītiskajām dzinējiem , ar resursu kontroli katram podam un automātisku mērogošanu maksimālās slodzes laikā.

Ja jūsu projekts ir mazs un ietilpst vienā resursdatorā, Compose paveiks šo uzdevumu bez jebkādām problēmām. Taču, kad jūsu lietotāju bāze pieaug un jums ir nepieciešama nopietna kļūdu tolerance un slodzes līdzsvarošana , ir pienācis laiks apsvērt Kubernetes.

Tīklošana, mērogošana un jauninājumi: praktisks salīdzinājums

Compose izveido tīklu katram projektam un identificē nosaukumus katram pakalpojumam. Saziņa ar konteineriem projekta ietvaros ir vienkārša un droša , taču ārējā slodzes līdzsvarošana un vairāku mitināšanu iespējas nav iebūvētas funkcijas.

Kubernetes vidē pakalpojumi piedāvā DNS noteikšanu un slodzes līdzsvarošanu klastera ietvaros; uz āru HTTP/S datplūsmas maršrutēšanai var izmantot LoadBalancer, NodePort vai Ingress.

Mērogošana: komponējiet mērogus manuāli un tikai vienā resursdatorā. Kubernetes mērogojas horizontāli ar HPA un programmiski ar metrikām un/vai notikumiem. To var arī paplašināt līdz vairākiem mezgliem, ja klasteris to atļauj.

Atjauninājumi: Programmā Compose tie parasti ir manuāli atjaunoti. K8s veic slīdošus atjauninājumus ar progresa kontroli (kubectl rollout) un iespēju tos atgriezt, ja kaut kas noiet greizi, tādējādi samazinot ietekmi.

Pašdziedināšana: Compose var restartēt konteinerus, taču tas neatrisina resursdatora vai izpildlaika avārijas. Kubernetes pārvieto Podus uz veseliem mezgliem , lietotājiem caurspīdīgi.

Izstrādātāja produktivitāte un operacionālā pieredze

Compose ir plāns slānis virs Docker. To ir ātri apgūt, un tā atgriezeniskās saites cilpa ir tūlītēja , ideāli piemērota iterācijai.

Kubernetes pievieno jaunus konceptus (Pods, Deployments, Services, Ingress, ConfigMaps, PVCs utt.). Pastāv mācīšanās līkne, bet pretī jūs iegūstat detalizētu kontroli pār izvietošanu, drošību, novērojamību un mērogojamību.

Saderības ziņā Compose ir “Docker-prioritāte”. Kubernetes atbalsta dažādas izpildlaika vides un integrējas ar mākoņpakalpojumu sniedzējiem , kas ir ļoti svarīgi uzņēmumiem ar daudzmākoņa vai hibrīdstratēģijām.

Migrācija no Docker Compose uz Kubernetes bez liekas piepūles

Kad migrēt? Kad jūsu lietojumprogramma vairs nav "maza", ir nepieciešama vairāku mezglu funkcionalitāte, novērojamība, mērogojamība un augsta pieejamība , vai arī jums tiek lūgta "canary" un "zilā/zaļā" izvietošana.

Tipiski izaicinājumi: pakalpojumu tīkla kartēšana, krātuves projektēšana ar PV/PVC , konfigurācijas atdalīšana konfigurācijas kartēs/noslēpumos un katra konteinera veselības un gatavības modeļu pārskatīšana.

Ir jāpārskata arī arhitektūra: Pod kā izvietošanas vienība , pakalpojumi galapunktu pieejamībai un resursi katram konteineram (CPU/Mem), lai plānotājs varētu veikt savu darbu.

Komponēšana: no Kompozīcijas līdz K8s dažos soļos

Kompose konvertē docker-compose.yml failus Kubernetes vai OpenShift manifestos. Tas ir tiešākais veids, kā sākt migrāciju, manuāli nepārrakstot visu YAML.

Pirms sākat darbu, ir nepieciešams Kubectl klasteris un konfigurēts kubectl. Ja testējat kaut ko statusa ziņā reģistrētu, ieteicams izmantot vismaz divus darba mezglus (nevis vadības plaknes). Pārbaudiet savu versiju, izmantojot `kubectl version`.

Instalēšana: Ieteicamā metode ir lejupielādēt bināro failu no jaunākās GitHub versijas. Varat izmantot arī tarball, Homebrew operētājsistēmā macOS vai "go get" (šī pēdējā opcija izmanto galveno failu ar izmaiņām izstrādē).

Pamata konvertēšana: dodieties uz direktoriju docker-compose.yml un palaidiet :

kompose convert
kubectl apply -f <archivos-generados>

Kompose pēc noklusējuma ģenerē izvietojumus un pakalpojumus. Žurnālā parasti ir norādīts katrs izveidotais fails , un pēc lietošanas klasterī izvietojumi un pakalpojumi tiks parādīti kā “izveidoti”.

Piekļuve: Ja izmantojat Minikube, varat viegli piekļūt vai vaicāt pakalpojumus. Mākonī atzīmējiet "LoadBalancer Ingress" , lai iegūtu LoadBalancer pakalpojuma publisko IP adresi; izmantojot NodePort, mezglos būs atvērts ports.

Tīrīšana: Kad esat pabeidzis testu, noņemiet lietotos resursus. Uzturiet klasteri tīru, lai izvairītos no konfliktiem starp iterācijām.

Komposēšanas papildu opcijas (nodrošinātāji, objekti un tagi)

Kompose atbalsta Kubernetes un OpenShift. Ja nenorādāt "--provider", tas pēc noklusējuma izmanto Kubernetes . Izmantojot OpenShift, tas var ģenerēt DeploymentConfigs un ImageStreams, un pat BuildConfigs, ja izmantojat būvēšanas direktīvas.

Tas atbalsta arī dažādas izvades: JSON ar "-j", ReplicationControllers, DaemonSets vai Helm Charts . Karodziņš "--replicas" ļauj mainīt repliku skaitu RC; Helm gadījumā tas ģenerē pamata diagrammas struktūru.

Konversiju ietekmē komposēšanas procesā esošie komposēšanas specifiskie tagi. Piemēram, varat definēt pakalpojuma veidu vai to, vai galapunkts ir jāatklāj, izmantojot ieeju/maršrutu.

Tag	Vērtības
kompozīt.pakalpojums.tips	nodeport/clusterip/loadbalancer
komposēt.pakalpojums.atklāt	patiess / resursdatora nosaukums

Detaļas, kas jāpatur prātā: nosaukumi ar “_” tiek konvertēti uz “-” (K8s nepieļauj pasvītras), un, ja pakalpojums izmanto sējumus, izvietošanas stratēģija mainās uz “Pārveidot”, lai izvairītos no konfliktiem ar vairākiem rakstītājiem.

Kompose atbalsta vairākas versijas un failus

Kompose atbalsta Compose V1, V2 un V3 (ar ierobežotu atbalstu 2.1 un 3.2 versijām to eksperimentālā rakstura dēļ). Ja vienlaikus nododat vairākus Docker-Compose failus, tie tiek apvienoti , un kopīgie elementi tiek pārrakstīti ar jaunāko failu, tāpat kā pārrakstīšanas gadījumā.

Kubernetes konvertēšanas laikā jūs redzēsiet tādus ziņojumus kā "WARN Unsupported key build – ignoring" (Brīdinājums: neatbalstīta atslēgas veidošana — ignorēšana), ja ir nesaderīgas atslēgas. Neuztraucieties, rīks turpinās darbu ar to, ko saprot , un pārējo atstās vēlākai manuālai pielāgošanai.

Vairāk nekā Kompose: Move2Kube un manuāla migrācija

Ja nepieciešama lielāka kontrole, ir pieejami tādi rīki kā Move2Kube, kas analizē jūsu sacerējuma failu un ģenerē precīzākus Kubernetes artefaktus. Tie ir noderīgi, ja vēlaties pielāgot biznesa modeļus vai veidnes no savas platformas.

Manuāla migrācija ir pilnīgi derīga un gandrīz vienmēr ieteicama pēc sākotnējās migrācijas. Tipiskas darbības ietver: pakalpojumu konvertēšanu uz Deployments/StatefulSets , tīklu konvertēšanu uz Services/Ingress un sējumu konvertēšanu uz PV/PVC ar krātuves klasēm.

Minimāls Compose pakalpojuma konvertēšanas uz Deployment piemērs varētu izskatīties šādi: pārsūtiet portus, attēlu un etiķetes uz Pod veidni:

# 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

Stāvokļa (datubāzēm, rindām) gadījumā apsveriet StatefulSets un PersistentVolumes. Ne visam, kas Compose iet "kopā", vajadzētu iet vienā Pod ; atdaliet atbildības un izmantojiet Services, lai sazinātos starp komponentiem.

Datu scenāriji: straumēšana, pakešu apstrāde un pārvaldība

Sarežģītos datu cauruļvados K8s iederas kā cimds: darbi (Jobs) partiju procesiem, CronJobs laika logiem , izvietojumi API un operatori tādām sistēmām kā Kafka, Spark vai Flink.

Straumēšanas un datubāzu gadījumā kopienas operatori un diagrammas atvieglo palaišanu. Pakalpojumu tīkla tīkls un resursu kontrole nodrošina paredzamākus latentumus un SLO salīdzinājumā ar viena resursdatora risinājumu.

Datu pārvaldības un drošības jomā Kubernetes piedāvā vārdtelpas, politikas un RBAC kontroli vides auditēšanai un atdalīšanai. Tā ir praktiska priekšrocība salīdzinājumā ar Compose lokālo pieeju.

Labākā prakse un nelieli darbības triki

Sarakstā: saglabājiet savu YAML mazu un modulāru ; izmantojiet vides mainīgos un .env failus; dokumentējiet portus un atkarības; un atspoguļojiet CI to, ko darbināt lokāli.

Kubernetes vidē: definējiet centrālā procesora un atmiņas pieprasījumus/ierobežojumus , izmantojiet gatavības/dzīvības pārbaudes, atdaliet konfigurāciju ConfigMaps/Secrets mapēs un katram pakalpojumam piemērojiet atbilstošas ​​izvietošanas stratēģijas.

Kubeck atjauninājumiem: izmantojiet `kubectl set image` un `kubectl rollout status` , lai uzraudzītu progresu un atsauktu iepriekšējos iestatījumus, ja kaut kas noiet greizi. Tas novērsīs dīkstāvi ražošanas vidē.

Ja Compose ir nepieciešami konkrēti uzdevumi, tos var simulēt, bet Kubernetes tas ir tīrāk ar CronJobs/Jobs ; jūs nepārblīvējat konteinerus ar papildu procesiem vai cronu mitināšanu.

Ātri bieži uzdotie jautājumi, lai izvairītos no neskaidrībām

Vai Compose aizstāj Kubernetes? Nē. Compose vienkāršo vairāku konteineru stekus vienā resursdatorā; Kubernetes darbojas klastera mērogā ar augstu pieejamību.

Vai Compose joprojām tiek izmantots? Jā, ļoti bieži. Tas ir ideāls izstrādes un testēšanas rīks pilnīgu vides izveidei, izmantojot tikai pāris komandas.

Vai Kubernetes ir "labāks" par Docker? Tās ir dažādas lietas: Docker ir konteineru platforma ; Kubernetes tos saskaņo klasterī un pievieno uzlabotas darbības.

Vai es varu pārnest savu Compose uz Kubernetes, to manuāli nepārrakstot? Jā, ar Kompose vai Docker Desktop integrāciju. Tas nodrošina ātru pirmo soli , ko pēc tam varat precizēt.

Sīkas detaļas: programmēšana, OpenShift un alternatīvas konvertēšanas

K8s nav tikai nepārtraukta izvietošana: Jobs un CronJobs aptver vienreizējus vai plānotus uzdevumus, bez nepieciešamības pārvaldīt sistēmas cronus.

OpenShift vidē Kompose var ģenerēt DeploymentConfigs un ImageStreams, un pat BuildConfigs, ja Compose ir bijis būvējums, kas saistīts ar Git repozitoriju. Karodziņi “--build-repo” un “--build-branch” tiek izmantoti, lai pielāgotu avotu.

Ja vēlaties citu izvadi, Kompose noklusējuma izvietojumu un pakalpojumu vietā ļauj izmantot DaemonSets, ReplicationControllers vai Helm Charts . Tas var ģenerēt arī JSON, ne tikai YAML.

Saderība, brīdinājumi un nelielas problēmas

Kompose atbalsta Compose V1/V2/V3 (ar ierobežojumiem 2.1 un 3.2 versijās). Neatbalstītās atslēgas tiek ignorētas ar WARN , atstājot vietu manuālām korekcijām.

Ja jūsu pakalpojumam ir sējumi, Kompose maina stratēģiju uz "Izveidot atkārtoti", lai izvairītos no vienlaicīguma vienā un tajā pašā sējumā . Tas ir normāli pakalpojumiem ar stāvokli.

Pasvītras nosaukumos tiek pārvērstas par defisēm. Šis ir Kubernetes ierobežojums objektu nosaukumiem , tāpēc pārliecinieties, vai tie ir pareizi nosaukti programmā Compose, lai izvairītos no pārsteigumiem konvertēšanas laikā.

Lai piekļūtu no ārpuses, pārbaudiet pakalpojuma veidu: ClusterIP (iekšējais), NodePort (ports mezglos) vai LoadBalancer (publiska IP adrese mākonī). Izmantojot Ingress, jums būs tīri HTTP/S maršruti un centralizēts TLS.

Ja testējat Minikube vidē, tādas komandas kā “minikube service <svc> –url” atgriezīs ātru URL . Mākonī, aprakstot pakalpojumu, skatiet lauku “LoadBalancer Ingress”.

Viens interesants aspekts: kopienā var atrast atsauces uz algām Kubernetes profiliem un ieviešanas līmeni, kas ražošanas vidē ir tuvu 88%. Nekas neparasts: tas ir faktiskais standarts.

Lai pilnīgāk saprastu, Kubernetes ir kas vairāk par HTTP: pakalpojumu tīkls, operatori un klientu resursu pārvaldības (CRD) elementi paplašina Kubernetes darbības jomu. Ja izmantojat Compose, sākumā ir normāli justies pārslogotam, taču šī papildu jauda nozīmē stabilāku darbību.

Atiestatīt politikas: noderīgas ekvivalences

Kompozīcija ļauj veikt restartēšanu: vienmēr/kļūmes gadījumā/nē. Kubernetes vidē atkarībā no gadījuma būs atsevišķi Podi vai kontrolieri (izvietojumi vai RC) ar atbilstošām restartēšanas politikām.

docker-compose restartēšana	Objekts K8s	restartPolicy
«» / vienmēr	Kontrolieris (izvietošana/RC)	vienmēr
atteices gadījumā	Pāksts	Kļūmes gadījumā
Nē	Pāksts	Nekad

Ja programmā Compose jums bija "aprēķinu" konteineri vai īslaicīgi uzdevumi (piemēram, ātra "pi"), vienkārši ieviesiet to programmā K8s kā Job vai CronJob ar atbilstošu politiku, un viss ir gatavs.

Izvēlieties Compose ātrai lokālai izvietošanai un Kubernetes, ja jūsu videi nepieciešama lielāka jauda: vairāku mezglu atbalsts, automātiska mērogošana, nemanāma izvietošana un patiesa noturība . Ar Compose, Move2Kube un nelielu rūpību pāreja ir vienmērīga.

Galu galā izvēle ir atkarīga no mēroga un sarežģītības: Compose ir lieliski piemērots izstrādei, testēšanai un viena resursdatora sistēmām ; Kubernetes ir piemērots risinājums uzņēmumiem, vairāku mākoņu izvietošanai un komandām, kurām nepieciešama uzlabota automatizācija, augsta pieejamība un ekosistēma ar tūkstošiem integrāciju.