„Docker Compose“ ir „Kubernetes“: kada naudoti kiekvieną, skirtumai ir migracija

Informatec Digital » Ištekliai » „Docker Compose“ ir „Kubernetes“: kada naudoti kiekvieną, skirtumai ir migracija

Jei dirbate su konteineriais, anksčiau ar vėliau iškyla svarbus klausimas: „Docker Compose“ ar „Kubernetes“? Abu įrankiai naudojami konteinerizuotame programų gyvavimo cikle , tačiau jie nėra skirti spręsti tas pačias problemas ar tame pačiame kontekste. Šiame straipsnyje mes juos išsamiai palyginame, pateikdami praktinių pavyzdžių, realaus pasaulio scenarijus ir patarimus, kaip sklandžiai pereiti iš vieno į kitą.

Be technologinio išdėstymo, šis sprendimas turi įtakos kasdienėms operacijoms: diegimo laikui, mastelio keitimui , atsparumui, saugumui ir sąnaudoms . Jis taip pat turi įtakos tipiniams duomenų inžinerijos naudojimo atvejams – srautams, duomenų bazėms, srautiniam perdavimui, paketiniam apdorojimui, duomenų formatams ir valdymui, – kur orkestravimas daro didelę įtaką produktyvumui.

Kas yra „Docker“ ir „Docker Compose“ (ir kam jie iš tikrųjų skirti)?

Kalbėdami apie „Docker“, iš tikrųjų turime omenyje ekosistemą: „Docker Engine“, „Docker Hub“, „Dockerfile“, „Docker Compose “... Variklis kuria ir paleidžia konteinerius iš vaizdų; „Hub“ leidžia lengvai jais dalytis; o „Compose“ leidžia apibrėžti kelias steko dalis YAML faile, kad jas būtų galima paleisti viena komanda.

„Compose“ buvo sukurtas tam, kad apsaugotų mus nuo begalinio skriptų skaičiaus ir izoliuotų komandų. Vienu „docker-compose.yml“ failu aprašote paslaugas, tinklus ir tomus , o viską paleidžiate vienu „docker compose up“ (arba „docker-compose up“ V1 versijoje). Idealiai tinka vietiniam kūrimui, integruotam testavimui, demonstracinėms versijoms arba integracinio bendradarbiavimo (CI) aplinkoms.

Kanoninis „Compose“ pavyzdys galėtų būti toks, su API ir „Postgres“ duomenų baze. Atkreipkite dėmesį, kaip priklausomybės, kintamieji ir prievadai deklaruojami skaitomame bloke:

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

Norėdami rankiniu būdu keisti mastelį „Compose“ programoje, galite naudoti paslaugos mastelio keitimo parinktį. „Compose V2“ versijoje tai įprasta daryti naudojant „up --scale“ (1 versijoje buvo „docker-compose scale“):

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

Saugokitės apribojimų: „Compose“ programa skirta vienam pagrindiniam kompiuteriui , ji nebalansuoja apkrovos tarp mazgų ir neautomatiškai nekeičia mastelio, o atnaujinimai paprastai yra rankinis konteinerių atkūrimas naudojant „build“ ir „up -d“.

Kas yra „Kubernetes“ ir ką jis siūlo, palyginti su „Compose“?

„Kubernetes“ (K8s) yra paskirstyta konteinerių orkestravimo platforma. Ji valdo diegimus dideliu mastu daugiamazgiuose klasteriuose , naudodama tokias koncepcijas kaip „Pods“, „Deployments“ ir „Services“, skirtas gamybinėms darbo krūviams valdyti.

„Kubernetes“ sistemoje netvarkote atskirų konteinerių; tvarkote „Pod“ (kuriuose gali būti vienas ar keli konteineriai). Valdymo plokštuma planuoja, kur veikia kiekvienas „Pod“ , teikia paslaugas, paskirsto srautą, keičia horizontalią skalę ir stebi darbo krūvių būklę.

Paprastas diegimas gali atrodyti taip, su 3 žiniatinklio paslaugos kopijomis. Apibrėžkite šablonus, žymas ir atvirus prievadus :

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

Norint jį valdyti apkrovos balansavimo funkciją, debesyje įprasta naudoti „LoadBalancer“ paslaugą. Parinkiklis suderina „Pod“ etiketes su srauto maršrutizavimu.

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

Gamybos aplinkoje „Kubernetes“ pasižymi tokiomis galimybėmis kaip didelio našumo automatizavimas (HPA), nuolatiniai atnaujinimai ir savaiminis atkūrimas. HPA koreguoja kopijas pagal rodiklius (pvz., procesoriaus naudojimą) :

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

Konteinerio būklė stebima zondais; jei jie sugenda, K8s paleidžia konteinerį iš naujo. Tai yra „savaiminio gijimo“ pagrindas :

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

Pagrindiniai panašumai ir skirtumai (esminiai dalykai neperkalbant)

Kas juos vienija: jie dirba su konteineriais ir apibrėžia diegimus per YAML. Abu sprendimai yra naudingi kūrėjams ir operatoriams ir puikiai papildo vienas kitą kūrimo ir gamybos darbo eigoje.

Esminis skirtumas slypi taikymo srityje: „Compose“ yra orientuota į „Docker“ ir skirta vienam mazgui ; „Kubernetes“ palaiko kelias vykdymo aplinkas ir daugiamazgius klasterius, tiesiogiai integruojant juos į debesis ir valdomas paslaugas.

Svarbesni skirtumai: „Kubernetes“ siūlo automatinį mastelio keitimą, nuolatinius atnaujinimus ir savęs taisymą ; „Compose“ to nedaro. „Kubernetes“ abstrahuoja naudodama „Pod“; „Compose“ tiesiogiai sąveikauja su „Docker“ konteineriais.

Be to, „Kubernetes“ apima „Jobs“ ir „CronJobs“ vienkartinėms arba suplanuotoms užduotims. Taip išvengiama sistemos „cron“ užduočių ir papildomų konteinerinių procesų , todėl platforma išlieka natūralia vieta automatizavimui apibrėžti.

Vietinėse sistemose „Compose“ laimi greičio ir paprastumo požiūriu. Jei reikia mastelio keitimo į šimtus mazgų arba kelių debesų aplinkų, „Kubernetes“ yra logiškas pasirinkimas . „Compose“ gali panaudoti „Docker Swarm“ diegimui keliuose mazguose, tačiau jos diegimo tempas ir galimybės neatitinka „Kubernetes“ ekosistemos ir brandos.

Kodėl jums reikia orkestravimo (ir kada kiekvienas iš jų geriausiai tinka)

Geras orkestravimo įrankis suteikia: vieningą aprūpinimą ir diegimą, suplanuotus paleidimus, ryšį tarp paslaugų , apkrovos balansavimą ir papildomą saugumą, užtikrinant papildomą kiekvienos paslaugos valdymą.

„Compose“ apžvelgia pagrindinius dalykus supaprastintai ir lengvai skaitomai, todėl tai puikus įrankis kūrimui, testavimui ir demonstracinėms versijoms. Tačiau jo apribojimai išryškėja, kai reikia kelių mazgų, vietinio apkrovos balansavimo ir automatinio mastelio keitimo arba laipsniško diegimo be prastovų.

Kita vertus, „Kubernetes“ yra „platforma“, kai apkrova auga: daugiamazgė, automatinis mastelio keitimas, didelis prieinamumas ir gigantiška ekosistema , turinti vietinį palaikymą AWS, Azure, GCP ir valdomose parinktyse.

Realaus pasaulio naudojimo atvejai (kūrimo, duomenų ir kt.)

„Compose“ pasižymi šiomis savybėmis: atkuriamos vietinės aplinkos, E2E testavimas, CI/CD ir mokymai . Viso steko apibrėžimas YAML ir paleidimas viena komanda pašalina daug triukšmo.

„Kubernetes“ idealiai tinka: gamybos programoms, daiktų internetui ir periferiniams skaičiavimams, dideliems duomenims ir mašininiam mokymuisi , bei daugialypėms / hibridinėms debesijos aplinkoms. Ji valdo paskirstytas darbo krūvius, kur svarbu delsa, atsparumas ir stebimumas.

Duomenų inžinerijoje „K8s“ puikiai tinka srautinio ir paketinio apdorojimo vamzdynams, duomenų bazėms, eilėms ir analitiniams varikliams , valdant išteklius kiekvienam moduliui ir automatiškai keičiant mastelį esant piko metu.

Jei jūsų projektas mažas ir telpa viename mazge, „Compose“ tai atliks be jokių rūpesčių. Tačiau kai jūsų vartotojų bazė auga ir jums reikia rimto gedimų toleravimo ir apkrovos balansavimo , laikas apsvarstyti „Kubernetes“.

Tinklo kūrimas, mastelio keitimas ir atnaujinimai: praktinis palyginimas

„Compose“ sukuria tinklą kiekvienam projektui ir sprendžia pavadinimus pagal paslaugas. Bendravimas su konteineriais projekto viduje yra paprastas ir saugus , tačiau išorinis apkrovos balansavimas ir kelių serverių talpinimas nėra įgimtos funkcijos.

„Kubernetes“ sistemoje paslaugos siūlo DNS aptikimą ir apkrovos balansavimą klasteryje; išoriniam srautui nukreipti galite naudoti „LoadBalancer“, „NodePort“ arba „Ingress“.

Mastelio keitimas: komponuokite mastelius rankiniu būdu ir tik viename pagrindiniame kompiuteryje. „Kubernetes“ keičia mastelį horizontaliai su HPA ir programiškai su metrikomis ir (arba) įvykiais. Jis taip pat gali augti iki daugiau mazgų, jei tai leidžia klasteris.

Atnaujinimai: „Compose“ programoje tai dažniausiai rankinis atkūrimas. „K8s“ atlieka nuolatinius atnaujinimus su eigos kontrole („kubectl rollout“) ir galimybe atšaukti, jei kas nors nepavyksta, taip sumažinant poveikį.

Savęs atstatymas: „Compose“ gali paleisti konteinerius iš naujo, bet neišsprendžia pagrindinio kompiuterio ar vykdymo aplinkos gedimų. „Kubernetes“ perkelia „Pod“ į sveikus mazgus , skaidriai vartotojams.

Kūrėjo produktyvumas ir praktinė patirtis

„Compose“ yra plonas „Docker“ sluoksnis. Jis greitai išmokstamas, o grįžtamojo ryšio ciklas yra tiesioginis , puikiai tinkantis iteracijai.

„Kubernetes“ prideda naujų koncepcijų (ankštys, diegimai, paslaugos, įėjimas, konfigūracijos žemėlapiai, PVC ir kt.). Yra mokymosi kreivė, tačiau mainais jūs gaunate išsamią diegimo, saugumo, stebimumo ir mastelio keitimo kontrolę.

Kalbant apie suderinamumą, „Compose“ pirmiausia orientuota į „Docker“. „Kubernetes“ palaiko įvairias vykdymo aplinkas ir integruojasi su debesijos paslaugų teikėjais , o tai yra labai svarbu įmonėms, taikančioms kelių debesų arba hibridines strategijas.

Migracija iš „Docker Compose“ į „Kubernetes“ be jokių išdaigų

Kada migruoti? Kai jūsų programa nebėra „maža“, jums reikės kelių mazgų, stebimumo, mastelio keitimo ir didelio prieinamumo arba jūsų bus prašoma atlikti „canary“ ir „blue/green“ diegimus.

Tipiniai iššūkiai: paslaugų tinklo žemėlapio sudarymas, saugyklos su PV/PVC projektavimas , konfigūracijos atskyrimas į „ConfigMap“/„Secrets“ ir kiekvieno konteinerio sveikatos bei parengties modelių peržiūra.

Taip pat reikia persvarstyti architektūrą: „Pod“ kaip diegimo vienetą , paslaugas galinių taškų atskleidimui ir išteklius kiekvienam konteineriui (CPU/Mem), kad planuoklė galėtų atlikti savo darbą.

„Compose“: nuo „Compose“ iki „K8s“ vos keliais žingsniais

„Kompose“ konvertuoja „docker-compose.yml“ failus į „Kubernetes“ arba „OpenShift“ manifestus. Tai tiesiausias būdas pradėti migraciją neperrašant viso YAML rankiniu būdu.

Prieš pradėdami, jums reikia „Kubectl“ klasterio ir sukonfigūruoto „kubectl“. Jei testuojate ką nors su būsena, rekomenduojama turėti bent du darbinius mazgus (ne valdymo plokštumas). Patikrinkite savo versiją naudodami „kubectl version“.

Diegimas: Rekomenduojamas būdas yra atsisiųsti dvejetainį failą iš naujausios „GitHub“ versijos. Taip pat galite naudoti tarball, „Homebrew“ sistemoje „macOS“ arba „go get“ (pastaroji parinktis naudoja pagrindinį failą su kūrimo metu atliktais pakeitimais).

Pagrindinis konvertavimas: eikite į katalogą docker-compose.yml ir paleiskite :

kompose convert
kubectl apply -f <archivos-generados>

„Kompose“ pagal numatytuosius nustatymus generuoja diegimus ir paslaugas. Žurnale paprastai pateikiamas kiekvienas sukurtas failas , o pritaikius diegimus ir paslaugas klasteryje matysite kaip „sukurtus“.

Prieiga: jei naudojate „Minikube“, galite lengvai atskleisti arba pateikti užklausas dėl paslaugų. Debesyje pažymėkite „LoadBalancer Ingress“, kad gautumėte viešąjį „LoadBalancer“ paslaugos IP adresą; naudodami „NodePort“, mazguose turėsite atvirą prievadą.

Valymas: Baigę testą, pašalinkite panaudotus išteklius. Palaikykite klasterį švarų, kad išvengtumėte konfliktų tarp iteracijų.

Išplėstinės „Kompose“ parinktys (teikėjai, objektai ir žymės)

„Kompose“ palaiko „Kubernetes“ ir „OpenShift“. Jei nenurodysite „--provider“, pagal numatytuosius nustatymus ji naudos „Kubernetes“ . Naudodama „OpenShift“, ji gali generuoti „DeploymentConfigs“ ir „ImageStreams“ ir net „BuildConfigs“, jei naudojate kūrimo direktyvas.

Taip pat palaikomos įvairios išvestys: JSON su „-j“, „ReplicationControllers“, „DaemonSets“ arba „Helm Charts“ . Funkcija „--replicas“ leidžia keisti replikų skaičių RC; „Helm“ atveju ji generuoja pagrindinę diagramos struktūrą.

Konversiją veikia sukurto failo žymės. Pavyzdžiui, galite apibrėžti paslaugos tipą arba tai, ar atskleisti galinį tašką per įėjimo / maršruto parinktį.

Žyma	Vertybės
kompose.service.type	nodeport/clusterip/loadbalancer
kompose.service.expose	true / pagrindinio kompiuterio pavadinimas

Svarbu nepamiršti: pavadinimai su „_“ konvertuojami į „-“ (K8s neleidžia pabraukimų), o jei paslauga naudoja tomus, diegimo strategija pasikeičia į „Sukurti iš naujo“, kad būtų išvengta konfliktų su keliais rašytojais.

„Kompose“ palaiko kelias versijas ir failus

„Kompose“ palaiko „Compose V1“, „V2“ ir „V3“ versijas (su ribotu 2.1 ir 3.2 versijų palaikymu dėl jų eksperimentinio pobūdžio). Jei vienu metu perduodate kelis „docker-compose“ failus, jie sujungiami , o bendri elementai perrašomi naujausiu failu, kaip ir atliekant perrašymą.

„Kubernetes“ konvertavimo metu matysite tokius pranešimus kaip „WARN Unsupported key build – ignoring“ (ĮSPĖJIMAS: Nepalaikomas rakto kūrimas – ignoravimas), jei yra nesuderinamų raktų. Nesijaudinkite, įrankis toliau veiks su tuo, ką supranta , o likusius paliks vėlesniam rankiniam koregavimui.

Be „Kompose“: „Move2Kube“ ir rankinis perkėlimas

Jei reikia daugiau kontrolės, yra tokių įrankių kaip „Move2Kube“, kurie analizuoja jūsų kūrimo procesą ir generuoja tikslesnius „Kubernetes“ artefaktus. Jie naudingi, kai norite pritaikyti verslo modelius ar šablonus iš savo platformos.

Rankinis perkėlimas yra visiškai tinkamas ir beveik visada rekomenduojamas po pradinio perkėlimo. Įprasti veiksmai apima: paslaugų konvertavimą į „Deployments/StatefulSets“ , tinklų konvertavimą į „Services/Ingress“ ir tomų konvertavimą į PV/PVC su saugojimo klasėmis.

Minimalus „Compose“ paslaugos konvertavimo į „Deployment“ pavyzdys gali atrodyti taip: perkelkite prievadus, atvaizdą ir žymas į „Pod“ šabloną:

# 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

Būsenai (duomenų bazėms, eilėms) apsvarstykite „StatefulSets“ ir „PersistentVolumes“. Ne viskas, kas „Compose“ sistemoje buvo „kartu“, turėtų būti tame pačiame „Pod“ ; atskirkite atsakomybes ir naudokite paslaugas komunikacijai tarp komponentų.

Duomenų scenarijai: srautinis perdavimas, paketinis perdavimas ir valdymas

Sudėtinguose duomenų srautuose K8s puikiai tinka: užduotims (Jobs) paketiniams procesams, „CronJobs“ laiko langams , API diegimams ir operatoriams tokiose sistemose kaip „Kafka“, „Spark“ ar „Flink“.

Srautinėms operacijoms ir duomenų bazėms paleidimą palengvina bendruomenės operatoriai ir diagramos. „Service Mesh“ tinklas ir išteklių valdymas užtikrina labiau nuspėjamas delsas ir SLO, palyginti su vieno serverio sprendimu.

Duomenų valdymo ir saugumo srityje „Kubernetes“ siūlo vardų erdves, politikas ir RBAC valdymą aplinkų auditavimui ir atskyrimui. Tai yra praktinis pranašumas, palyginti su „Compose“ vietiniu metodu.

Geriausia praktika ir nedideli operaciniai gudrybės

„Compose“ programoje: palaikykite savo YAML mažą ir modulinį ; naudokite aplinkos kintamuosius ir .env failus; dokumentuokite prievadus ir priklausomybes; ir CI atspindėkite tai, ką vykdote lokaliai.

„Kubernetes“ sistemoje: apibrėžkite procesoriaus ir atminties užklausas / apribojimus , naudokite parengties / gyvumo zondus, atskirkite konfigūraciją į „ConfigMaps“ / slaptus raktus ir kiekvienai paslaugai pritaikykite tinkamas diegimo strategijas.

„Kubeck“ atnaujinimams: naudokite „kubectl set image“ ir „kubectl rollout status“ , kad stebėtumėte eigą ir atšauktumėte atliktus pakeitimus, jei kas nors nepavyksta. Tai padės išvengti prastovų gamyboje.

Jei „Compose“ programoje reikia konkrečių užduočių, galite jas imituoti, tačiau „Kubernetes“ sistemoje viskas tvarkingiau naudojant „CronJobs“ / „Jobs“ ; konteineriai neužgriozdinami papildomais procesais ar „cron“ serveriais.

Greiti DUK, kad išvengtumėte painiavos

Ar „Compose“ pakeičia „Kubernetes“? Ne. „Compose“ supaprastina kelių konteinerių stekus viename pagrindiniame kompiuteryje; „Kubernetes“ veikia klasterio mastu ir užtikrina aukštą prieinamumą.

Ar „Compose“ vis dar naudojama? Taip, labai dažnai. Tai idealus kūrimo ir testavimo įrankis , skirtas sukurti pilnas aplinkas vos keliomis komandomis.

Ar „Kubernetes“ yra „geresnis“ nei „Docker“? Tai skirtingi dalykai: „Docker“ yra konteinerių platforma ; „Kubernetes“ juos sujungia į klasterį ir prideda pažangias operacijas.

Ar galiu perkelti savo „Compose“ į „Kubernetes“ jo neperrašydamas rankiniu būdu? Taip, su „Kompose“ arba „Docker Desktop“ integracija. Tai suteikia jums greitą pirmąjį žingsnį , kurį galite vėliau patobulinti.

Smulkios detalės: programavimas, „OpenShift“ ir alternatyvios konversijos

K8s nėra tik nuolatinis diegimas: „Jobs“ ir „CronJobs“ apima vienkartines arba suplanuotas užduotis, jums nereikės valdyti sistemos „cron“.

„OpenShift“ programoje „Kompose“ gali generuoti „DeploymentConfigs“ ir „ImageStreams“ ir net „BuildConfigs“, jei „Compose“ turėjo su „Git“ saugykla susietą kompiliaciją. Šaltiniui koreguoti naudojamos vėliavėlės „--build-repo“ ir „--build-branch“.

Jei norite kitokios išvesties, „Kompose“ leidžia naudoti „DaemonSets“, „ReplicationControllers“ arba „Helm Charts“, o ne numatytuosius „Deployments and Services“. Ji taip pat gali generuoti JSON, o ne tik YAML.

Suderinamumas, įspėjimai ir nedidelės problemos

„Kompose“ palaiko „Compose V1/V2/V3“ (su 2.1 ir 3.2 versijų apribojimais). Nepalaikomi raktai ignoruojami su įspėjimu „WARN“ , paliekant vietos rankiniam koregavimui.

Jei jūsų paslauga turi tomų, „Kompose“ pakeičia strategiją į „Atkurti“, kad būtų išvengta lygiagretumo tame pačiame tome . Tai įprasta būsenomis valdomoms paslaugoms.

Pabraukimai pavadinimuose konvertuojami į brūkšnelius. Tai „Kubernetes“ apribojimas objektų pavadinimams , todėl įsitikinkite, kad teisingai juos pavadinote programoje „Compose“, kad konvertavimo metu išvengtumėte netikėtumų.

Norėdami pasiekti iš išorės, patikrinkite paslaugos tipą: „ClusterIP“ (vidinis), „NodePort“ (prievadas mazguose) arba „LoadBalancer“ (viešas IP adresas debesyje). Naudodami „Ingress“ turėsite švarius HTTP/S maršrutus ir centralizuotą TLS.

Jei testuojate „Minikube“, tokios komandos kaip „minikube service <svc> –url“ grąžins greitą URL adresą . Debesyje, aprašydami paslaugą, atkreipkite dėmesį į lauką „LoadBalancer Ingress“.

Įdomus dalykas: bendruomenėje rasite nuorodų į atlyginimus už „Kubernetes“ profilius ir beveik 88 % pritaikymo rodiklį gamybinėje aplinkoje. Nieko neįprasto: tai faktinis standartas.

Kad būtų aiškiau, „Kubernetes“ siūlo daugiau nei HTTP: „Service Mesh“, operatoriai ir CRD praplečia „Kubernetes“ aprėptį. Jei naudojate „Compose“, iš pradžių normalu jaustis prislėgtam, tačiau ši papildoma galia reiškia patikimesnes operacijas.

Atstatyti taisykles: naudingi atitikmenys

„Compose“ leidžia „paleisti iš naujo: visada / gedimo atveju / ne“. „Kubernetes“, priklausomai nuo atvejo, turėsite atskirus „Pod“ arba valdiklius (diegimus arba RC) su atitinkamomis paleidimo iš naujo politikomis.

docker-compose paleisti iš naujo	Objektas K8s	paleisti iš naujoPolicy
«» / visada	Valdiklis (diegimas / nuotolinis valdymas)	Visada
gedimo atveju	Ankštis	Dėl nesėkmės
ne	Ankštis	niekada

Jei „Compose“ turėjote „skaičiavimo“ konteinerius arba trumpalaikes užduotis (pvz., greitą „pi“), tiesiog įdiekite jas „K8s“ kaip „Job“ arba „CronJob“ su atitinkama politika ir viskas paruošta.

Rinkitės „Compose“, jei norite greito vietinio diegimo, ir „Kubernetes“, kai jūsų aplinkai reikia daugiau galios: kelių mazgų palaikymas, automatinis mastelio keitimas, sklandus diegimas ir tikras atsparumas . Su „Compose“, „Move2Kube“ ir trupučiu dėmesio perėjimas vyksta sklandžiai.

Galiausiai pasirinkimas priklauso nuo masto ir sudėtingumo: „Compose“ puikiai tinka kūrimui, testavimui ir vieno serverio stekų kūrimui ; „Kubernetes“ yra tinkamiausias pasirinkimas įmonėms, kelių debesų diegimams ir komandoms, kurioms reikalinga pažangi automatizacija, didelis prieinamumas ir ekosistema su tūkstančiais integracijų.