Interkontinentális Docker Swarm

 ( janoszen | 2017. október 23., hétfő - 11:44 )

Miután végre kilátok a hullámok fölött, sikerült hétvégén egy kicsit játszanom. Ezúttal egy olyan Docker Swarm setupot építettem, ami két kontinensen 3 DC-ben futtat Wordpresst. Miért? Mert megtehetem. Ihun-e a leírás.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

király

király

subs

Állítólag a CRI-O és a Kubernetes úgyis hamarosan megöli az egész Dockert. Állítólag.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Ezt mar mondtak az rkt-ra is :). Ebben ugy is az lesz a donto ,hogy a kubernetes maga mit fog tamogatni. De jelenleg meg kuzdenek ,hogy 1.12.6-rol fel lehessen vegre frissiteni az ujabb verziokra ami 1.8-as verzioval remelhetoleg megtortenik...
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

Úgy tudom, hogy a Kubernetes csak a CRI-O-t támogatja natívan, illetve a Docker csapat ad Docker támogatást hozzá.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Most jelentetek be Docker confon ,hogy lesz native docker support. https://techcrunch.com/2017/10/17/docker-gives-into-invevitable-and-offers-native-kubernetes-support/

Hat a CRI-O asszem csak RedHat supportalja es meg talan google cloudba se erheto el. De az Azure is csak docker verziot tamogat az AWS is docker supportal jon.

Dockerbe is belelapaltotak minden szart aztan most a mobyval probaljak levalasztalni modulokra mert tarthatatlan lett a kod es van x ezer bug amit kepetlenseg karbantartni ez meg is latszik az 1.1x.x stabbilatasan.

--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

Az OpenShift is CRI-O alapon fog menni.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Elnezegetve hogy Kubernetest telepiteni mennyire irdatlanul bonyolult egy Swarmhoz kepest es mennyire hianyzik hozza a legalapvetobb tooling is, egyelore azert erre nem vennek be merget. Hihetetlenul sok es kiraly feature van benne, de ha ma egy mezei rendszergazdanak azt mondom hogy akkor tegyen fel egy tobb gepes kubernetest, akkor lehet hogy 3 nap utan suru anyazasok kozepette hozzam vag valamit. A sajat doksijuk is halal outdated volt amikor legutobb neztem, es hallottam mar Google rendszergazdat anyazni ra.

Oszinten nagyon szeretnem ha a Kubernetes egy konnyen hasznalhato kezes joszag lenne, mert sok problemamat megoldana, de egyelore nem az.

--
Pásztor János
Sole Proprietor @ Opsbears | Refactor Zone

Ha ez kell akkor arra ott a https://coreos.com/tectonic/ 10 gepig free. Next -> Next finish. Viszont nem fogod tudni hogyan mukodik mar pedig ha debugolni akarod akkor muszaj lesz.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

Na latod, pont ez az. Attol, hogy valahogy felmaszik, meg nincs monitorozva, nincs debugolashoz knowhow, stb. Jatszani jo, de uzemeltetni, tenyleges, penzt termelo rendszereket... (Ugyanez igaz arra is ha valaki random third party Docker containereket futtat.) Ez meg nem production ready, hacsak nem akarsz egy raklap munkaorat betolni es van egy rendszergazda csapatod akinek nincs mas dolga mint hogy ezzel foglalkozzon.

--
Pásztor János
Sole Proprietor @ Opsbears | Refactor Zone

Nem allitom ,hogy nem igaz amit igy leirsz de azert kicsit tulzasnak tartom. Ha valaki nem akarja maganak felepiteni es uzemeltetni ott a google cloud. Az a cucc amit kuldtem ott monitorozva van az infra ez az egyik fizeteso ficsore. Az ,hogy nem production ready meg ez a Te velemenyed de mondjuk ott a GitHub aki at alt Kubernetes meg van 1-2 kisebb ceg. Nem allitotam ,hogy nekunk nagy rendszerunk van de van 40+ node meg 3-4 ezer kontener es nincs uzemeltetoi csapat es nem is kell naponta tutujgatni a rendszert ,hogy mukodjon.

--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

Jogos, kicsit felreerthetoen fogalmaztam. Szoval, szerintem a Kubernetes onmagaban, kulso tamogatas nelkul nem feltetlenul az az eszkoz amit egy kis projekthez, kis csapathoz szeretne hasznalni valaki. Egyszeruen azert, mert sok a mozgo alkatresz, sok a szukseges know-how es sok az energia amit bele kell tenni hogy legyen egy mukodo rendszer. A hivatalos deployment script hivatalosan beta allapotu, es legutobbi probalkozasaimkor nem is mukodott megfeleloen. Rancherrel elindul szepen a Kubernetes, de az plusz mozgo alkatresz, raadasul nagy verziovaltas elott nem akarok elkezdeni foglalkozni vele.

A legnagyobb rendszer amit jelenleg uzemeltetek az egy par tucat gepen egy par szaz container es igy is tulzasnak erzem az energiat amit bele kell tenni, ha osszehasonlitom azzal hogy a Swarm egy init + join parancs kiadasabol megvan, es a jelenlegi tesztek szerint egesz stabilan mukodik. Nincs autoscaling, nincs alatta hardver provizionalas, de nem is kell erre a felhasznalasra.

Nem tudom ertelmesen elmagyarazni hogy mit akarok, nem mukodik ma a fogalmazokam. Bocsi. Lesz most 2 hetem amikor az idom nagy reszet ezekkel fogom tolteni es akkor majd meglatjuk hogy mi a verdikt.

--
Pásztor János
Sole Proprietor @ Opsbears | Refactor Zone

Okes igy mar ertem amit mondasz. Ha kell help keres meg privatban es szivesen segitek. Nemtudom melyik deployment scriptet nezted ha kube-aws-t az production ready de ha kell a sajat cuccunkat megosztom majd.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

Irtam privatot par kerdessel. Koszonom a lehetoseget.

--
Pásztor János
Sole Proprietor @ Opsbears | Refactor Zone

Mi a use case a multi-region setuphoz? Csak játék, vagy valamit így akarsz megoldani..
De ha már csinálod, érdekelne mit csinál a cucc különböző network outage esetekben.

V-dayen tartok előadást arról, hogy hogyan építettem saját CDN-t (és nem lövöm le a poént előre). Ehhez kisérleteztem pár plusz dologgal, amit én ugyan nem használok, de adott esetben érdekes lehet mint téma.

A jelenlegi setup Wordpresst futtat Galera backenddel, szóval network outage esetén, mivel leáll az overlay hálózat, kiesik a quorumból, aminek hatására a Route53 health check kidobja a DNS rotálásból, vagyis nem kap forgalmat. Maga a Swarm hálózati kiesés után elég szépen visszajön, ha össze tud állni az eredeti konfiguráció szerinti többség. Ezt meg is tapasztaltam amikor a t2.small instance-ek alól elfogyott a CPU credit és elkezdtek nem csinálni semmit. Mivel mindhárom node-on megtörtént, így azt mondta mindegyik, hogy "Swarm has no leader", a containerek viszont tovább mentek (amennyire bírtak működő overlay hálózat és CPU nélkül). Miután a CPU zabálást megszűntettem, szépen visszajött minden.

Ha van tipped hogy mit nézzek még stabilitási teszt gyanánt, szólj, V-dayig fut még a cluster.

--
Pásztor János
Sole Proprietor @ Opsbears | Refactor Zone

Hát én annyiféle hálózati anomáliát láttam már, hogy nem gondolkoznék régiók közti Kubernetesben (tehát itt nem a docker swarmról beszélek). (itt az orchestrator-re gondolok, a szolgáltatás pl Galera failure mode-ja megint külön történet) Azt hiszem, felrakom én is ezt a cuccot és meghajtom egy picit. :) Egyszer nagyon régen néztem, de akkor még nagyon kezdetleges volt.

Kubernetes szepen elvan amugy mert kulon szeparalja a datacentereket de megis tudod vezerelni egybol: https://kubernetes.io/docs/concepts/cluster-administration/federation/

En ezt anno ki probaltam nem zavarja az egyik a masikat. De mondjuk pl. DB-t nem rakunk kubernetesbe.

--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

Idézet:
De mondjuk pl. DB-t nem rakunk kubernetesbe.

Miert nem?

--
Pásztor János
Sole Proprietor @ Opsbears | Refactor Zone

Egyreszt nem nagyon uzemeltetunk DB-t. Ennek az egyik oka ,hogy eppen van eleg dolgunk es feleslegesen nem vennenk a nyakunkba. A masodik az ,hogy en nagyon otszkodom meg DB-t dockerben futtatni jelenleg. Nem azt mondom ,hogy kesobb nem fog ez valtozni de pl. mi MongoDB meg ES-t hasznalunk.

1. MongoDB-t baromi nagy macera futtatni kubernetesbe jelenleg remelem fog ez valtozni de jelenleg nem vallalnam be
2. ES ezt mi uzemeltetuk voltak neha szivasok de alapvetoen jol mukodott viszont ezt is kiszerveztuk mert ez is plusz egy macera volt.

--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

Értem, akkor ez egy szubjektív vélemény, ha jól értelmezem.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Ez igy van. De mivel sok mindent futtatsz 1 gepen igy baromira oda kell figyelni az eroforras kiosztasokra mind diszk mind memoria es cpu-ban. Mert az SQL szervered konnyen felzabalja az eroforrast az alkalmazas elol vagy pont forditva es elkezdenek kidolni a nodeok a rendszerbol.

Nalunk mindenen van resource korlat mivel egyreszt kell a skalazashoz masreszt nem szeretnenk tul telitetni a szervereket es mondjuk egy DB szervernel viszonylag komplikaltabb ezt ki szamolni.

--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

Nem csoportositod a szervereket? Marmint hogy X szerver csoport csak DB-kre van, es minden gepre csak egy DB kerul? Mert nalam igy van megoldva, a Docker csak azert van hogy konnyebb legyen frissiteni / tesztelni.

--
Pásztor János
Sole Proprietor @ Opsbears | Refactor Zone

A federation egész más, mint egy multi-region cluster! De igen.