Pavel Selivanov, mîmarê çareseriyên Southbridge û mamosteyê Slurm, li DevOpsConf 2019 pêşkêşiyek kir. Ev axaftin beşek ji yek ji mijarên qursa kûr a li ser Kubernetes "Slurm Mega" ye.
18-20 Mijdarê li Moskovayê pêk tê.
- Moskow, 22-24 Mijdar.
herdem heye.
Li jêr birîn nusxeyek ji raporê heye.
Roj baş hevalno û yên ku bi wan re sempatî dikin. Îro ez ê li ser ewlehiyê biaxivim.
Ez dibînim ku îro li salonê gelek cerdevan hene. Ez pêşiyê lêborîna xwe ji we dixwazim heke ez şertên cîhana ewlehiyê ne tam wekî ku ji we re adetî ye bikar bînim.
Wusa qewimî ku nêzîkê şeş meh berê ez li komeke giştî ya Kubernetes rast hatim. Public tê wê wateyê ku n-emîn cîhên navan hene. Hemî van bikarhêneran ji pargîdaniyên cûda ne. Welê, hate texmîn kirin ku divê ev kom wekî CDN were bikar anîn. Ango, ew komekê didin we, li wir bikarhênerek didin we, hûn diçin wir qada navên xwe, eniyên xwe bicîh dikin.
Pargîdaniya min a berê hewl da ku karûbarek wusa bifroşe. Û ji min hat xwestin ku ez komê bigirim da ku bibînim ka ev çareserî maqûl e an na.
Ez hatim vê komê. Mafên bisînor dan min, cîhê navan bi sînor hat dayîn. Zarokên li wir fêm kirin ku ewlekarî çi ye. Wan li Kubernetes-ê li ser Kontrola gihîştina-based Role (RBAC) xwend - û wan ew zivirî da ku ez nekarim pod ji veqetandinê veqetînim. Pirsgirêka ku min hewl dida ku bi destpêkirina podek bêyî veqetandinê çareser bikim nayê bîra min, lê min bi rastî dixwest ku ez tenê podek bidim destpêkirin. Ji bo bextewariya xwe, min biryar da ku bibînim ka çi mafên min ên di komê de hene, ez dikarim çi bikim, ez nikarim çi bikim, û wan li wir çi xelet kiriye. Di heman demê de, ez ê ji we re bibêjim ka wan çi di RBAC de bi xeletî mîheng kiriye.
Wusa çêbû ku di du hûrdeman de min rêveberek koma wan wergirt, li hemî navên cîran mêze kir, li wir eniyên hilberîna xebitandinê yên pargîdaniyên ku berê karûbar kirîn û bicîh kirin dît. Min bi zorê nikaribû xwe bihêlim ku ez biçim pêşiya yekî û hindek sondxwarinê bixim ser rûpela sereke.
Ez ê bi mînakan ji we re bibêjim ka min çawa ev kir û çawa xwe ji vê yekê biparêze.
Lê pêşî, ez xwe bidim nasîn. Navê min Pavel Selivanov e. Ez mîmarek li Southbridge me. Ez Kubernetes, DevOps û her cûre tiştên xweşik fam dikim. Endezyarên Southbridge û ez van hemûyan ava dikin, û ez şêwirmendiyê dikim.
Li gel xebatên xwe yên sereke, di van demên dawî de me projeyên bi navê Slûrms dan destpêkirin. Em hewl didin ku kapasîteya xwe ya xebata bi Kubernetes re hinekî bigihînin girseyê, ku mirovên din jî fêrî K8-an bikin.
Ez ê îro qala çi bikim? Mijara raporê diyar e - di derbarê ewlehiya koma Kubernetes de. Lê ez dixwazim tavilê bibêjim ku ev mijar pir mezin e - û ji ber vê yekê ez dixwazim tavilê zelal bikim ka ez ê bê guman li ser neaxivim. Ez ê behsa şertên hackneyed ên ku berê sed carî li ser Înternetê hatine bikar anîn nekim. Hemî cûreyên RBAC û sertîfîkayan.
Ez ê li ser tiştê ku ez û hevkarên min di derheqê ewlehiyê de di komek Kubernetes de diêşîne biaxivim. Em van pirsgirêkan hem di nav pêşkêşkerên ku komên Kubernetes peyda dikin û hem jî di nav xerîdarên ku têne cem me de dibînin. Û tewra ji xerîdarên ku ji pargîdaniyên rêveber ên şêwirmendiyê yên din têne cem me. Yanî bi rastî qebareya trajediyê pir mezin e.
Bi rastî sê xal hene ku ez ê îro behsa wan bikim:
- Mafên bikarhêner li hember mafên pod. Mafên bikarhêner û mafên pod ne heman tişt in.
- Komkirina agahiyan li ser komê. Ez ê nîşan bidim ku hûn dikarin hemî agahdariya ku hûn hewce ne ji komek kom bikin bêyî ku di vê komê de mafên taybetî hebin.
- Êrîşa DoS li ser komê. Ger em nikaribin agahiyê berhev bikin, em ê di her rewşê de bikarin komê saz bikin. Ez ê li ser êrîşên DoS-ê yên li ser hêmanên kontrolkirina komê biaxivim.
Tiştek din a gelemperî ku ez ê behs bikim ev e ku min ev hemî li ser ceriband, li ser ku ez bê guman dikarim bibêjim ku ew hemî dixebite.
Em sazkirina komek Kubernetes bi karanîna Kubespray ve wekî bingeh digirin. Ger kes nizane, ev bi rastî ji bo Ansible komek rolan e. Em bi berdewamî di karê xwe de bikar tînin. Tiştê baş ew e ku hûn dikarin wê li her deverê bixin - hûn dikarin wê bixin ser perçeyên hesin an jî li cîhek ewr. Yek rêbazek sazkirinê ji bo her tiştî dixebite.
Di vê komê de ez ê Kubernetes v1.14.5 hebe. Tevahiya koma Cube, ya ku em ê lê bihesibînin, di nav cîhên navan de tê dabeş kirin, her navek ji tîmek cihê ye, û endamên vê tîmê bigihîjin her navekî. Ew nikarin biçin navên cihê, tenê yên xwe. Lê hin hesabek rêveberê heye ku mafên tevahiya komê heye.
Min soz da ku yekem tiştê ku em ê bikin ev e ku mafên rêveberiyê yên komê bistînin. Pêdiviya me bi podek taybetî heye ku dê koma Kubernetes bişkîne. Tiştê ku divê em bikin ev e ku wê li koma Kubernetes bicîh bikin.
kubectl apply -f pod.yamlEv pod dê bigihîje yek ji axayên koma Kubernetes. Û piştî vê komê dê bi kêfxweşî pelek bi navê admin.conf vegerîne me. Di Cube de, ev pel hemî sertîfîkayên rêveberê hilîne, û di heman demê de API-ya komê mîheng dike. Bi vî rengî hêsan e ku meriv bigihîje rêveberê, ez difikirim, 98% ji komên Kubernetes.
Ez dubare dikim, ev pod ji hêla pêşdebirek di koma we de hatî çêkirin ku gihîştina pêşniyarên xwe di nav cîhek navekî piçûk de bicîh dike, ew hemî ji hêla RBAC ve hatî girtin. Mafê wî tunebû. Lê dîsa jî sertîfîka hat vegerandin.
Û niha li ser podek taybetî amadekirî. Em wê li ser her wêneyê dimeşînin. Ka em debian:jessie wekî mînakek bigirin.
Me ev tişt heye:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Tolerans çi ye? Mamosteyên di komek Kubernetes de bi gelemperî bi tiştek ku jê re tê gotin taint têne nîşankirin. Û cewherê vê "enfeksiyonê" ev e ku ew dibêje ku nekarin girêkên serdest werin veqetandin. Lê tu kes xwe aciz nake ku di her çîçekê de destnîşan bike ku ew ji "enfeksiyonê" re tolerans e. Beşa Tolerasyonê tenê dibêje ku heke hin girêk NoSchedule hebe, wê hingê girêka me ji enfeksiyonek wusa re tolerans e - û pirsgirêk tune.
Wekî din, em dibêjin ku binê me ne tenê tolerans e, lê di heman demê de dixwaze bi taybetî axayê jî bike hedef. Ji ber ku axayan tiştê herî xweş ku em hewce ne - hemî sertîfîka hene. Ji ber vê yekê, em dibêjin nodeSelector - û me etîketek standard li ser masteran heye, ku dihêle hûn ji hemî girêkên di komê de tam wan girêkên ku serdest in hilbijêrin.
Bi van her du beşan ew ê teqez bê ser axa. Û dê destûr bê dayîn ku li wir bijî.
Lê tenê hatina cem axayê me têrê nake. Ev ê tiştekî nede me. Ji ber vê yekê em van du tiştan hene:
hostNetwork: true
hostPID: true Em diyar dikin ku pod meya ku em dest pê dikin dê di nav qada navkerê de, di qada navên torê de û di nav qada navên PID de bijî. Gava ku pod li ser masterê were destpêkirin, ew ê karibe hemî navgînên rastîn, zindî yên vê nodê bibîne, li hemî seyrûseferê guhdarî bike û PID-a hemî pêvajoyan bibîne.
Wê demê mesele tiştên piçûk e. etcd bistînin û tiştê ku hûn dixwazin bixwînin.
Tiştê herî balkêş ev taybetmendiya Kubernetes e, ku ji hêla xwerû li wir heye.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host Û cewhera wê ev e ku em dikarin di podê de bibêjin ku em dest pê dikin, tewra bêyî mafên vê komê, ku em dixwazin cildek ji celebê hostPath biafirînin. Ev tê vê wateyê ku rê ji mêvandarê ku em ê pê bidin destpêkirin bigirin - û wê wekî cildê bigirin. Û paşê em jê re dibêjin: hoste. Em tevahiya vê hostPathê di hundurê podê de siwar dikin. Di vê nimûneyê de, li pelrêça / host.
Ez ê dîsa dubare bikim. Me ji podê re got ku were ba master, tora mêvandar û hostPID-ê li wir bigire - û tevahiya koka masterê li hundurê vê podê siwar bike.
Hûn fêm dikin ku li Debian me bash running heye, û ev bash di bin root de derbas dibe. Ango, me tenê root li ser master wergirt, bêyî ku di koma Kubernetes de tu maf hebe.
Dûv re hemî peywir ev e ku hûn biçin pelrêça bin /host /etc/kubernetes/pki, heke ez ne xelet bim, hemî sertîfîkayên masterê yên komê li wir hildibijêrin û, li gorî vê yekê, bibin rêvebirê komê.
Ger hûn bi vî rengî lê mêze bikin, ev hin mafên herî xeternak ên di pods-ê de ne - bêyî ku bikarhêner xwediyê kîjan mafên be:
Ger mafê min hebe ku ez podek li hin cîhê navên komê bimeşînim, wê hingê ev pod ji hêla xwerû ve xwediyê van mafan e. Ez dikarim podên îmtiyazê bimeşînim, û ev bi gelemperî hemî maf in, bi pratîkî li ser nodê root in.
My favorite bikarhêner Root e. Û Kubernetes vê vebijarka Run As Non-Root heye. Ev celebek parastina ji hacker e. Ma hûn dizanin "vîrûsa Moldavia" çi ye? Ger hûn ji nişka ve hacker bin û werin koma min a Kubernetes, wê hingê em, rêvebirên belengaz, dipirsin: "Ji kerema xwe di polên xwe de destnîşan bikin ku hûn ê bi kîjan komê min hack bikin, wekî ne-root bimeşînin. Wekî din, ew ê biqewime ku hûn pêvajoyê di binavê xwe de di bin root de bimeşînin, û ew ê ji we re pir hêsan be ku hûn min hack bikin. Ji kerema xwe xwe ji xwe biparêzin."
Hêjmara riya mêvandar, bi dîtina min, awayê zûtirîn e ku meriv encama xwestinê ji komek Kubernetes bigire.
Lê bi van hemûyan re çi bikin?
Fikra ku divê were serê her rêvebirê normal yê ku bi Kubernetes re rû bi rû bimîne ev e: "Erê, min ji we re got, Kubernetes nexebite. Di wê de qul hene. Û tevahiya Kube pûç e." Bi rastî, tiştek wekî belgeyek heye, û heke hûn li wir binêrin, beşek heye .
Ev hêmanek yaml e - em dikarin wê di koma Kubernetes de biafirînin - ku bi taybetî di danasîna podan de aliyên ewlehiyê kontrol dike. Ango, di rastiyê de, ew mafên karanîna her hostNetwork, hostPID, hin celebên cildê yên ku di destpêkê de di nav potan de ne kontrol dike. Bi alîkariya Polîtîkaya Ewlekariya Pod, ev hemî dikare were vegotin.
Tişta herî balkêş di derbarê Siyaseta Ewlekariya Pod de ev e ku di koma Kubernetes de, hemî sazkerên PSP-ê ne tenê bi ti awayî nayên şirove kirin, ew bi xwerû têne asteng kirin. Polîtîkaya Ewlekariya Pod bi karanîna pêveka pejirandinê ve tête çalak kirin.
Baş e, ka em Siyaseta Ewlekariya Pod-ê di nav komê de bicîh bikin, em bibêjin ku di qada navan de hin pêlên karûbarê me hene, ku tenê rêvebiran bigihîjin wan. Em bêjin, di hemî rewşên din de, pod xwedî mafên sînordar in. Ji ber ku bi îhtîmalek mezin pêşdebiran ne hewce ne ku di koma we de podên îmtiyazê bimeşînin.
Û her tişt bi me re baş xuya dike. Û koma meya Kubernetes di du hûrdeman de nayê hack kirin.
Pirsgirêkek heye. Bi îhtîmalek mezin, heke we komek Kubernetes heye, wê hingê çavdêrî li ser koma we tê saz kirin. Ez ê heta pêşbînî bikim ku ger koma we xwedî çavdêriyê be, wê jê re Prometheus were gotin.
Tiştê ku ez ê ji we re bibêjim dê hem ji bo operatorê Prometheus û hem jî ji bo Prometheus ku di forma xweya paqij de hatî radest kirin derbasdar be. Pirs ev e ku ger ez nikaribim ew qas zû rêveberek bigirim nav komê, wê hingê ev tê vê wateyê ku ez hewce dikim bêtir bigerim. Û ez dikarim bi alîkariya çavdêriya we bigerim.
Dibe ku her kes heman gotaran li ser Habré dixwîne, û çavdêrî di cîhê navên çavdêriyê de cih digire. Nexşeya Helm hema hema ji bo her kesî yek tê gotin. Ez texmîn dikim ku heke hûn helmê stabîl/prometheus saz bikin, hûn ê bi qasî heman navan biqedin. Û bi îhtîmaleke mezin ez ê ne mecbûr im ku navê DNS-ê di koma we de texmîn bikim. Ji ber ku ew standard e.
Dûv re me hin dev ns hene, ku tê de hûn dikarin hin podek bimeşînin. Û paşê ji vê podê pir hêsan e ku meriv tiştek wusa bike:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics yek ji hinardekarên Prometheus e ku metrîkan ji Kubernetes API bixwe berhev dike. Li wir gelek dane hene, çi di koma we de dimeşe, ew çi ye, çi pirsgirêkên we bi wê re hene.
Wek mînakek hêsan:
kube_pod_container_info{namespace=“kube-system”,pod=”kube-apiserver-k8s- 1″,container=”kube-apiserver”,image=
"gcr.io/google-containers/kube-apiserver:v1.14.5"
,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1
Bi çêkirina daxwazek kulmek hêsan a ji podek bêdestûr, hûn dikarin agahdariya jêrîn bistînin. Heke hûn nizanin kîjan guhertoya Kubernetes-ê hûn dimeşînin, ew ê bi hêsanî ji we re vebêje.
Û ya herî balkêş ev e ku ji bilî gihîştina kube-state-metrics, hûn dikarin bi heman rengî rasterast rasterast xwe bigihînin Prometheus. Hûn dikarin metrîkan ji wir berhev bikin. Tewra hûn dikarin ji wir metrîkan ava bikin. Tewra ji hêla teorîkî ve, hûn dikarin pirsek wusa ji komek li Prometheus ava bikin, ku ew ê bi hêsanî wê vebike. Û çavdêriya we dê bi tevahî ji komê bixebite.
Û li vir pirs derdikeve holê ka gelo çavdêriyek derveyî çavdêriya we dişopîne. Min tenê fersend girt ku ez di komek Kubernetes de bêyî ti encamek ji bo xwe kar bikim. Hûn jî nizanin ku ez li wir dixebitim, ji ber ku êdî çavdêrî tune.
Mîna PSP-ê, wusa dixuye ku pirsgirêk ev e ku hemî van teknolojiyên xweşik - Kubernetes, Prometheus - ew tenê naxebitin û tijî qul in. Ne rast.
Tiştek weha heye - .
Ger hûn rêveberek normal in, wê hingê bi îhtîmalek mezin hûn di derbarê Siyaseta Torgilokê de dizanin ku ev tenê yamlek din e, ya ku jixwe gelek ji wan di komê de hene. Û hin Polîtîkayên Torê bê guman ne hewce ne. Û her çend hûn bixwînin Polîtîkaya Torê çi ye, ku ew dîwarek yaml a Kubernetes-ê ye, ew dihêle hûn mafên gihîştinê di navbera cîhên navan, di navbera potan de sînordar bikin, wê hingê we bê guman biryar da ku dîwarê agir di forma yaml-ê de li Kubernetes-ê li ser bingeha abstractionsên din e. ... Na, na. Ev bê guman ne hewce ye.
Tewra ku we ji pisporên ewlehiyê yên xwe re negot ku bi karanîna Kubernetes-a xwe hûn dikarin dîwarek pir hêsan û hêsan, û di heman demê de yekî pir granular ava bikin. Ger ew hîn vê yekê nizanin û we aciz nakin: "Welle, bide min, bide min ..." Wê hingê di her rewşê de, hûn hewce ne ku Siyaseta Torgilokê gihandina hin cihên karûbarê ku dikarin ji koma we werin derxistin asteng bikin. bê destûr.
Mîna ku di mînaka ku min da, hûn dikarin metrîkên dewleta kube ji her cîhê navî yê di koma Kubernetes de derxînin bêyî ku hûn mafên wiya bikin. Polîtîkayên torê gihîştina ji hemî navên din ên cîhê navên çavdêriyê girtine û ew e: bê gihîştin, bê pirsgirêk. Di hemî nexşeyên ku hene de, hem Prometheus standard û hem jî Prometheusê ku di operatorê de ye, bi tenê vebijarkek di nirxên helmê de heye ku bi tenê polîtîkayên torê ji wan re çalak bike. Hûn tenê hewce ne ku wê vekin û ew ê bixebitin.
Bi rastî li vir pirsgirêkek heye. Ji ber ku rêveberek rih normal, we bi îhtîmalek mezin biryar da ku polîtîkayên torê ne hewce ne. Û piştî xwendina her cûre gotarên li ser çavkaniyên mîna Habr, we biryar da ku flannel, nemaze bi moda mêvandar-dergeh, çêtirîn tiştê ku hûn dikarin hilbijêrin.
Ez çi bikim?
Hûn dikarin biceribînin ku çareseriya torê ya ku we di koma Kubernetes-ê de heye ji nû ve bicîh bikin, hewl bidin ku wê bi tiştek fonksiyoneltir veguherînin. Ji bo heman Calico, wek nimûne. Lê ez dixwazim tavilê bibêjim ku peywira guheztina çareseriya torê di komek xebatkar a Kubernetes de pir ne-tewre ye. Min ew du caran çareser kir (her du caran, lêbelê, teorîkî), lê me tewra nîşan da ku meriv wê çawa li Slurms çawa bike. Ji bo xwendekarên xwe, me destnîşan kir ka meriv çawa çareseriya torê di komek Kubernetes de biguhezîne. Di prensîbê de, hûn dikarin biceribînin ku pê ewle bibin ku li ser komê hilberînê demdirêj tune. Lê dibe ku hûn bi ser nekevin.
Û pirsgirêk bi rastî pir bi hêsanî çareser dibe. Di komê de sertîfîka hene, û hûn dizanin ku sertîfîkayên we dê di salekê de biqede. Welê, bi gelemperî çareseriyek normal bi sertîfîkayên di komekê de - çima em ditirsin, em ê komek nû li nêzê xwe rakin, bihêlin ya kevin xera bibe, û her tiştî ji nû ve saz bikin. Rast e, dema ku xera bibe, divê em rojekê rûnin, lê li vir komek nû heye.
Gava ku hûn komikek nû radikin, di heman demê de li şûna flannelê Calico têxin.
Ger sertîfîkayên we ji bo sed salan werin derxistin û hûn nexwazin komê ji nû ve belav bikin hûnê çi bikin? Tiştek wekî Kube-RBAC-Proxy heye. Ev pêşkeftinek pir xweş e, ew dihêle hûn xwe wekî konteynirek kêlekê li her podek di koma Kubernetes de bicîh bikin. Û ew bi rastî bi riya RBAC ya Kubernetes bixwe destûrnameyê li vê podê zêde dike.
Pirsgirêkek heye. Berê, ev çareseriya Kube-RBAC-Proxy di Prometheusê operator de hate çêkirin. Lê paşê ew çû. Naha guhertoyên nûjen xwe dispêrin vê yekê ku we polîtîkayek torê heye û wê bi karanîna wan bigire. Û ji ber vê yekê em ê neçar in ku nexşeyê hinekî ji nû ve binivîsin. Bi rastî, heke hûn biçin , mînakên ku meriv vê yekê wekî kêlek bikar tîne hene, û nexşe neçar in ku hindiktirîn ji nû ve werin nivîsandin.
Pirsgirêkek din a piçûk heye. Prometheus ne tenê ye ku metrîkên xwe ji her kesî re radigihîne. Hemî pêkhateyên koma meya Kubernetes jî dikarin metrîkên xwe vegerînin.
Lê wekî ku min berê jî got, heke hûn nikaribin xwe bigihînin komê û agahdariya berhev bikin, wê hingê hûn dikarin bi kêmanî zirarê bidin.
Ji ber vê yekê ez ê zû du awayan nîşan bidim ka meriv çawa komek Kubernetes dikare hilweşîne.
Dema ku ez vê ji we re bibêjim hûn ê bikenin, ev du dozên jiyana rast in.
Rêbaza yekê. Kêmbûna çavkaniyê.
Werin em podek din a taybetî bidin destpêkirin. Wê beşek bi vî rengî hebe.
resources:
requests:
cpu: 4
memory: 4Gi Wekî ku hûn dizanin, daxwaz mîqdara CPU û bîranîna ku li ser mêvandarê ji bo podên taybetî yên bi daxwazan ve hatî veqetandin e. Ger di komek Kubernetes de mêvandarek me ya çar-bingeh hebe, û çar podên CPU-yê bi daxwazan bigihîjin wir, ev tê vê wateyê ku dê ti podên bi daxwazek din nikaribin werin vê mêvandarê.
Ger ez podek wusa bimeşînim, wê hingê ez ê fermanê bimeşînim:
$ kubectl scale special-pod --replicas=...Wê hingê kesek din dê nikaribe li koma Kubernetes bicîh bike. Ji ber ku hemî nod dê ji daxwaziyan biqedin. Û bi vî awayî ez ê koma weya Kubernetes rawestim. Ger ez vê êvarê bikim, ez dikarim ji bo demek pir dirêj veqetandinê rawestim.
Ger em dîsa li belgeya Kubernetes binerin, em ê vê tiştê bi navê Rêzeya Sînor bibînin. Ew çavkaniyan ji bo tiştên komê saz dike. Hûn dikarin di yaml de hêmanek Rêzeya Sînor binivîsin, wê li hin cîhên navan bicîh bikin - û dûv re di vê cîhê navan de hûn dikarin bibêjin ku we çavkaniyên xwerû, herî zêde û hindiktirîn ji bo podan hene.
Bi arîkariya tiştek weha, em dikarin bikarhêneran di navên hilberên taybetî yên tîmê de di şiyana ku her cûre tiştên nebaş li ser pêlên xwe destnîşan bikin sînordar bikin. Lê mixabin, tewra ku hûn ji bikarhênerê re bibêjin ku ew nekarin podên bi daxwazên zêdetirî CPU-yê dest pê bikin, fermanek pîvanek wusa ecêb heye, an jî ew dikarin bi navgîniya dashboardê pîvanê bikin.
Û ev e ku rêbaza hejmara du ji tê. Em 11 pods dest pê dikin. Yanzdeh milyar e. Ev ne ji ber ku min jimareyek wusa peyda kir, lê ji ber ku min ew bi xwe dît.
Çîroka rastîn. Derengê êvarê ez ê ji ofîsê derkevim. Ez komek pêşdebiran dibînim ku li quncikê rûniştine, bi dilşikestî bi laptopên xwe re tiştek dikin. Ez diçim cem xortan û jê dipirsim: “Çi hat serê we?”
Demek berê, dora neh êvarê, yek ji pêşdebiran amade bû ku biçe malê. Û min biryar da: "Ez ê naha serlêdana xwe bikim yek." Min yek pê kir, lê Înternet hinekî hêdî bû. Wî careke din pê li yek kir, wî pê li yekê kir û pê li Enter kir. Min li ser her tiştê ku ji destê min hat hejand. Dûv re Înternet ket jiyanê - û her tişt dest pê kir ku bi vê hejmarê kêm bibe.
Rast e, ev çîrok li ser Kubernetes pêk nehat, wê demê ew Nomad bû. Bi wê yekê bi dawî bû ku piştî saetekê ji hewildanên me yên ji bo rawestandina Nomad ji hewildanên domdar ên mezinbûnê, Nomad bersiv da ku ew dest ji mezinbûnê bernade û tiştek din nake. "Ez westiyam, ez diçim." Û wî kil kir.
Bi xwezayî, min hewl da ku heman tiştî li ser Kubernetes bikim. Kubernetes bi yazdeh mîlyar potan ne kêfxweş bû, wî got: "Ez nikarim. Ji parêzvanên devê navxweyî derbas dibe." Lê 1 pod dikaribû.
Di bersiva yek milyar de, Kube xwe nekişand. Wî bi rastî dest bi pîjbûnê kir. Her ku pêvajo ber bi pêş ve diçû, ew qas zêdetir wext digirt ku ew podên nû biafirîne. Lê dîsa jî pêvajo berdewam kir. Pirsgirêk tenê ev e ku heke ez dikarim podan bêsînor di nav cîhê navên xwe de vekim, wê hingê jî bêyî daxwaz û sînoran ez dikarim bi hin peywiran re ew qas podan bidim destpêkirin ku bi alîkariya van peywiran girêk dê dest pê bikin ku di bîranînê de, di CPU de zêde bibin. Dema ku ez ew qas pod dest pê dikim, divê agahdariya ji wan bikeve hilanînê, ango hwd. Û gava ku pir agahdarî digihîje wir, hilanînê dest pê dike ku pir hêdî vedigere - û Kubernetes dest pê dike ku bêhêz bibe.
Û pirsgirêkek din... Wekî ku hûn dizanin, hêmanên kontrolê yên Kubernetes ne yek tiştek navendî ne, lê çend pêkhate ne. Bi taybetî, rêveberek kontrolker, plansazker, û hwd heye. Hemî van xortan dê di heman demê de dest bi karên nehewce, bêaqil bikin, ku bi demê re dê dest pê bike ku bêtir û bêtir dem bigire. Rêvebirê kontrolker dê podên nû biafirîne. Scheduler dê hewl bide ku ji wan re nodek nû bibîne. Bi îhtimaleke mezin hûn ê di demek nêz de girêkên nû yên di koma xwe de biqedin. Koma Kubernetes dê hêdî û hêdî dest bi xebatê bike.
Lê min biryar da ku ez hê bêtir biçim. Wekî ku hûn dizanin, di Kubernetes de tiştek wusa heye ku jê re xizmet tê gotin. Welê, bi xwerû di komên we de, bi îhtîmalek mezin, karûbar bi karanîna tabloyên IP-yê dixebite.
Mînakî, hûn mîlyarek pods dimeşînin, û dûv re skrîptek bikar tînin da ku zorê bidin Kubernetis ku karûbarên nû biafirîne:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done Li ser hemî girêkên komê, dê bêtir û bêtir qaîdeyên nû yên iptables bi hevdemî werin çêkirin. Wekî din, dê ji bo her karûbarek mîlyarek qaîdeyên iptables bêne çêkirin.
Min ev tişt li ser çend hezar, heta deh kontrol kir. Û pirsgirêk ev e ku jixwe di vê astê de kirina ssh ji nodê re pir pirsgirêk e. Ji ber ku pakêt, di gelek zincîran re derbas dibin, dest pê dikin ku ne pir baş hîs bikin.
Û ev jî hemû bi alîkariya Kubernetes çareser dibe. Tiştek kotaya Çavkaniyek wusa heye. Hejmara çavkanî û tiştên berdest ji bo cîhê navan di komê de destnîşan dike. Em dikarin di her navekî koma Kubernetes de hêmanek yaml biafirînin. Bi karanîna vê nesnê, em dikarin bibêjin ku ji bo vê cîhê navan hejmarek daxwaz û sînorên me hatine veqetandin, û paşê em dikarin bibêjin ku di vê navan de 10 karûbar û 10 pod têne çêkirin. Û pêşdebirek yekane dikare bi kêmanî êvaran xwe xeniqîne. Kubernetes ê jê re bibêje: "Hûn nekarin pêlavên xwe bi wê mîqdarê mezin bikin, ji ber ku çavkanî ji kotayê derbas dike." Ew e, pirsgirêk çareser kirin. .
Di vî warî de xalek pirsgirêk derdikeve holê. Hûn hîs dikin ku çiqas dijwar e ku meriv navekî li Kubernetes biafirîne. Ji bo afirandina wê, divê em gelek tiştan li ber çavan bigirin.
Kotaya çavkaniyê + Rêzeya Sînor + RBAC
• Navekî biafirîne
• Di hundurê de sînorek çêbikin
• Di hundurê kotaya çavkaniyê de çêbikin
• Ji bo CI hesabek xizmetê çêbikin
• Rolebinding ji bo CI û bikarhêneran biafirînin
• Bi bijartî pêlavên karûbarê pêwîst dest pê bikin
Ji ber vê yekê ez dixwazim vê derfetê bikar bînin û pêşveçûnên xwe parve bikin. Tiştek wisa heye ku jê re dibêjin operator SDK. Ev rêyek e ku komek Kubernetes ji bo wê operatoran binivîse. Hûn dikarin bi karanîna Ansible daxuyaniyan binivîsin.
Di destpêkê de ew bi Ansible hate nivîsandin, û dûv re min dît ku operatorek SDK-ê heye û rola Ansible di operatorek ji nû ve nivîsand. Ev gotin dihêle hûn di koma Kubernetes de tiştek bi navê fermanek biafirînin. Di hundurê fermanek de, ew dihêle hûn jîngehê ji bo vê fermanê di yaml de diyar bikin. Û di nav hawîrdora tîmê de, ew dihêle ku em diyar bikin ku em gelek çavkaniyan veqetînin.
Little .
Û di encamê de. Bi van hemûyan re çi bikin?
Yekem. Polîtîkaya Ewlekariya Pod baş e. Tevî vê yekê ku yek ji sazkerên Kubernetes heya roja îro wan bikar neynin, hûn hîn jî hewce ne ku wan di komên xwe de bikar bînin.
Siyaseta Torgilokê ne tenê taybetmendiyek din a nehewce ye. Ya ku bi rastî di komekê de hewce ye ev e.
LimitRange / ResourceQuota - wextê karanîna wê ye. Me demek dirêj berê dest bi karanîna vê kir, û ji bo demek dirêj ez bawer bûm ku her kes wê bikar tîne. Derket holê ku ev kêm e.
Ji bilî ya ku min di dema raporê de behs kir, taybetmendiyên nebelge hene ku dihêle hûn êrîşî komê bikin. Di demên dawî de hat berdan .
Hin tişt pir xemgîn û bi êş in. Mînakî, di bin hin mercan de, cubelets di komek Kubernetes de dikarin naveroka pelrêça warlocks bidin bikarhênerek bê destûr.
Talîmat hene ku meriv çawa her tiştê ku min ji we re gotiye dubare bike. Pelên bi mînakên hilberînê yên ku ResourceQuota û Polîtîkaya Ewlekariya Pod dişibin hene. Û hûn dikarin van hemûyan bi dest bixin.
Spas ji bo hemûyan.
Source: www.habr.com