Контейнерная оркестровка, позволяющая оркестровать существующие контейнеры docker
Я работаю с Docker уже довольно давно и уже имею производственную среду, которая начиналась с малого, но теперь выросла до более чем 50 узлов Linux, на каждом из которых работает один контейнер Docker.
Я оркестровал все с помощью пользовательских скриптов на python, и до сих пор все работало отлично, но поскольку мы, вероятно, будем продолжать расширяться, я подумал, что в какой-то момент мне понадобится надежный, гибкий инструмент оркестровки, поэтому можно начать планировать все уже сейчас.
Я начал читать о вариантах оркестровки docker, и на данный момент я сузил круг до двух вариантов: Kubernetes или docker-swarm.
Глядя на Kubernetes, кажется, что это правильный выбор (как надежная, гибкая система оркестровки), но я не уверен, подходит ли она для моей среды. Из того, что я читал, она не может работать с уже существующими контейнерами docker, ее можно использовать только для создания нового кластера с нуля. В нашем случае мы используем выделенные серверы с особыми требованиями к оборудованию, поэтому у нас нет возможности создать еще один параллельный, альтернативный кластер, где мы могли бы начать работу с Kubernetes с чистого листа.
С другой стороны, docker-swarm выглядит более подходящим для оркестровки существующих контейнеров docker, но, похоже, имеет проблемы с надежностью и масштабированием.
Может ли кто-нибудь с большим опытом работы с Kubernetes/docker-swarm дать мне несколько советов о том, как мне следует подходить к миграции на оркестрованный кластер docker, без необходимости создавать его с нуля (поскольку в моем случае это невозможно)?
Спасибо!
Nu știu prea multe despre Docker Swarm, dar îmi pot împărtăși gândurile despre partea Kubernetes.
Oricum veți avea nevoie de câteva mașini suplimentare dacă doriți să faceți modificări în mediu - mașinile dvs. utilizează 90%, așa că nu văd cum ați putea migra sau începe să utilizați Kubernetes acolo în scenariul actual. În afară de oprirea nodurilor dvs. unul câte unul și migrarea treptată la Kubernetes. Puteți încerca să schimbați două dintre nodurile curente în 1 master kubernetes și 1 nod (folosind de exemplu kubespray) și apoi să vă alăturați containerele la cluster ca implementări.
Ați menționat deja că nu puteți începe să orchestrați containerele care rulează, deoarece va trebui să le rotiți de la zero pentru a începe să utilizați Kubernetes - dar un lucru este important aici. Dacă o faci bine cu K8s, nu vei mai avea niciodată această problemă.Modul declarativ al lui Kubernetes și faptul că totul este un fișier yaml ușurează viitorul. Va trebui doar să vă păstrați serviciile, implementările, configmap-urile, backup, iar această problemă va dispărea în viitor. De asemenea, orchestrarea, autovindecarea, îmbunătățirile și scalarea nu vor mai fi atât de complicate.
Deci, pentru a rezuma povestea lungă. Nu susțin că ceea ce voi scrie este singurul mod corect în care voi împărtăși ceea ce aș face în situația ta.
Ați menționat deja că închiriați hardware-ul - de ce să nu vă mutați pe un Cloud atunci? Nu este nevoie să mutați totul imediat. Ceea ce vreau să spun este - recreați-vă infra-ul în Cloud - poate într-unul dintre serviciile Kubernetes gestionate (GKE, EKS, AKS sau multe altele), deoarece acestea sunt cele mai ușor de gestionat și veți fi susținut de ingineri de la Google / AWS / Azure etc. pentru a vă ajuta dacă veți avea probleme cu clusterul dvs. După ce ați terminat cu mediul din Cloud și funcționează așa cum era de așteptat, atunci puteți decide ce urmează.
Merită să rămâi cu toată infrastructura ta sau poate este mai bine să te întorci la premisă? În acest caz, veți avea deja experiență cu Kubernetes, fișiere YAML pregătite, copii de siguranță etc. și mutarea acestui lucru din Cloud Kubernetes în Kubernetes la fața locului va fi mult mai simplă - tot ce va trebui să faceți este aproape 1: 1 migrare + unele jocuri cu rețele.
Există probe gratuite disponibile, astfel încât să puteți testa dacă acest lucru funcționează în acest fel - în GCP primiți o probă gratuită de 300 USD și, de asemenea, acestea oferă reduceri de utilizare continuă. Așadar, ați putea testa aplicația la scară mai mică. În AWS există un nivel gratuit care ar trebui să fie suficient pentru a testa unele caracteristici de bază. Nu sunt sigur despre alți furnizori de cloud, dar cu siguranță au oferte corespunzătoare.
Deci, fie că încercați să migrați parțial către Cloud și să vă jucați cu împărțirea traficului între on-prem și Cloud, fie să copiați întregul infra în Cloud și apoi să îl reproduceți on-prem dacă doriți.
O altă modalitate este să opriți două noduri, să creați un master Kubernetes și un nod pe ele și apoi să vă uniți încet nodurile la cluster unul câte unul. Asta depinde și de ce tip de aplicație rulați, vă puteți permite timpii morți etc., dar totul poate fi rezolvat cu, de exemplu, implementarea canarului.