Pavel Selivanov, Southbridge-solvo-arkitekto kaj instruisto de Slurm, faris prezenton ĉe DevOpsConf 2019. Ĉi tiu prelego estas parto de unu el la temoj de la profunda kurso pri Kubernetes "Slurm Mega".
okazas en Moskvo la 18-20-an de novembro.
— Moskvo, 22-24 novembro.
ĉiam disponebla.
Sub la tranĉo estas transskribaĵo de la raporto.
Bonan posttagmezon, kolegoj kaj tiuj, kiuj simpatias kun ili. Hodiaŭ mi parolos pri sekureco.
Mi vidas, ke hodiaŭ estas multaj sekurgardistoj en la halo. Mi pardonpetas vin anticipe, se mi uzas terminojn de la mondo de sekureco ne ĝuste kiel kutimas por vi.
Okazis, ke antaŭ ĉirkaŭ ses monatoj mi renkontis unu publikan Kubernetes-areton. Publiko signifas, ke ekzistas n-a nombro da nomspacoj; en tiuj nomspacoj estas uzantoj izolitaj en sia nomspaco. Ĉiuj ĉi tiuj uzantoj apartenas al malsamaj kompanioj. Nu, oni supozis, ke ĉi tiu aro devus esti uzata kiel CDN. Tio estas, ili donas al vi aron, ili donas al vi uzanton tie, vi iras tien al via nomspaco, deploji viajn frontojn.
Mia antaŭa kompanio provis vendi tian servon. Kaj mi estis petita piki la areton por vidi ĉu ĉi tiu solvo taŭgas aŭ ne.
Mi venis al ĉi tiu areto. Mi ricevis limigitajn rajtojn, limigitan nomspacon. La uloj tie komprenis kio estas sekureco. Ili legis pri Rol-bazita alirkontrolo (RBAC) en Kubernetes - kaj ili tordis ĝin tiel ke mi ne povis lanĉi podojn aparte de deplojoj. Mi ne memoras la problemon, kiun mi provis solvi lanĉante podon sen deplojo, sed mi vere volis lanĉi nur podon. Por bonŝanco, mi decidis vidi kiajn rajtojn mi havas en la areto, kion mi povas fari, kion mi ne povas fari, kaj kion ili fiaskis tie. Samtempe, mi diros al vi, kion ili malĝuste agordis en RBAC.
Okazis, ke en du minutoj mi ricevis administranton al ilia areto, rigardis ĉiujn najbarajn nomspacojn, vidis tie la kurantajn produktadfrontojn de kompanioj, kiuj jam aĉetis la servon kaj deplojis. Mi apenaŭ povis malhelpi min iri al ies fronto kaj meti iun ĵurvorton sur la ĉefpaĝon.
Mi rakontos al vi per ekzemploj kiel mi faris tion kaj kiel protekti vin kontraŭ ĉi tio.
Sed unue, mi prezentu min. Mia nomo estas Pavel Selivanov. Mi estas arkitekto ĉe Southbridge. Mi komprenas Kubernetes, DevOps kaj ĉiajn fantaziajn aferojn. La Southbridge-inĝenieroj kaj mi konstruas ĉion ĉi, kaj mi konsiliĝas.
Krom niaj ĉefaj agadoj, ni lastatempe lanĉis projektojn nomitajn Slurms. Ni provas alporti nian kapablon labori kun Kubernetes iomete al la amasoj, por instrui aliajn homojn ankaŭ labori kun K8s.
Pri kio mi parolos hodiaŭ? La temo de la raporto estas evidenta - pri la sekureco de la Kubernetes-areo. Sed mi volas tuj diri, ke tiu ĉi temo estas tre vasta - kaj tial mi volas tuj klarigi, pri kio mi certe ne parolos. Mi ne parolos pri hakitaj terminoj, kiuj jam centfoje estis uzataj en Interreto. Ĉiaj RBAC kaj atestiloj.
Mi parolos pri tio, kio doloras min kaj miajn kolegojn pri sekureco en Kubernetes-grupo. Ni vidas ĉi tiujn problemojn kaj inter provizantoj, kiuj provizas Kubernetes-grupojn, kaj inter klientoj, kiuj venas al ni. Kaj eĉ de klientoj, kiuj venas al ni de aliaj konsilantaj administraj kompanioj. Tio estas, la skalo de la tragedio estas fakte tre granda.
Estas laŭvorte tri punktoj pri kiuj mi parolos hodiaŭ:
- Uzantrajtoj vs podrajtoj. Uzantrajtoj kaj podrajtoj ne estas la sama afero.
- Kolektante informojn pri la areto. Mi montros, ke vi povas kolekti ĉiujn informojn, kiujn vi bezonas de aro sen havi specialajn rajtojn en ĉi tiu aro.
- DoS-atako sur la areto. Se ni ne povas kolekti informojn, ni povos ĉiukaze meti areton. Mi parolos pri DoS-atakoj sur cluster-kontrolelementoj.
Alia ĝenerala afero, kiun mi mencios, estas pri kio mi provis ĉion ĉi, pri kiu mi certe povas diri, ke ĉio funkcias.
Ni prenas kiel bazon la instaladon de Kubernetes-grupo uzante Kubespray. Se iu ne scias, tio fakte estas aro de roloj por Ansible. Ni uzas ĝin konstante en nia laboro. La bona afero estas, ke vi povas ruli ĝin ie ajn - vi povas ruli ĝin sur ferpecojn aŭ en nubon ie. Unu instala metodo funkcias principe por ĉio.
En ĉi tiu aro mi havos Kubernetes v1.14.5. La tuta Kubo-grupo, kiun ni konsideros, estas dividita en nomspacojn, ĉiu nomspaco apartenas al aparta teamo, kaj membroj de ĉi tiu teamo havas aliron al ĉiu nomspaco. Ili ne povas iri al malsamaj nomspacoj, nur al sia propra. Sed ekzistas certa administranta konto, kiu havas rajtojn al la tuta areto.
Mi promesis, ke la unua afero, kiun ni faros, estos akiri administrantajn rajtojn al la cluster. Ni bezonas speciale preparitan pod kiu rompos la Kubernetes-areton. Ĉio, kion ni devas fari, estas apliki ĝin al la Kubernetes-grupo.
kubectl apply -f pod.yamlĈi tiu balko alvenos al unu el la mastroj de la Kubernetes-areo. Kaj post tio la areto feliĉe resendos al ni dosieron nomatan admin.conf. En Cube, ĉi tiu dosiero stokas ĉiujn administrantajn atestilojn, kaj samtempe agordas la grapolan API. Jen kiel facile estas akiri administran aliron al, mi pensas, 98% de Kubernetes-grupoj.
Mi ripetas, ĉi tiu pod estis farita de unu programisto en via areto, kiu havas aliron por disfaldi siajn proponojn en unu malgrandan nomspacon, ĉio estas fiksita de RBAC. Li ne havis rajtojn. Sed tamen la atestilo estis resendita.
Kaj nun pri speciale preparita balgo. Ni rulas ĝin sur ajna bildo. Ni prenu debian:jessie kiel ekzemplon.
Ni havas ĉi tiun aferon:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Kio estas toleremo? Majstroj en Kubernetes-areto estas kutime markitaj per io nomata makulo. Kaj la esenco de ĉi tiu "infekto" estas, ke ĝi diras, ke balgoj ne povas esti asignitaj al majstraj nodoj. Sed neniu ĝenas indiki en iu ajn balgo, ke ĝi estas tolerema al la "infekto". La sekcio Toleremo nur diras, ke se iu nodo havas NoSchedule, tiam nia nodo estas tolerema al tia infekto - kaj ne estas problemoj.
Plue, ni diras, ke nia sub estas ne nur tolerema, sed ankaŭ volas specife celi la majstron. Ĉar la majstroj havas la plej bongustan aferon, kiun ni bezonas - ĉiujn atestojn. Tial ni diras nodeSelector - kaj ni havas norman etikedon sur mastroj, kiu ebligas al vi elekti el ĉiuj nodoj en la areto ĝuste tiujn nodojn, kiuj estas majstroj.
Kun ĉi tiuj du sekcioj li certe venos al la majstro. Kaj li rajtos loĝi tie.
Sed nur veni al la mastro ne sufiĉas por ni. Ĉi tio nenion donos al ni. Do poste ni havas ĉi tiujn du aferojn:
hostNetwork: true
hostPID: true Ni precizigas, ke nia pod, kiun ni lanĉas, loĝos en la kerna nomspaco, en la reta nomspaco, kaj en la PID-nomspaco. Post kiam la pod estas lanĉita sur la majstro, ĝi povos vidi ĉiujn realajn, vivajn interfacojn de ĉi tiu nodo, aŭskulti la tutan trafikon kaj vidi la PID de ĉiuj procezoj.
Tiam temas pri malgrandaj aferoj. Prenu etcd kaj legu tion, kion vi volas.
La plej interesa afero estas ĉi tiu funkcio de Kubernetes, kiu ĉeestas tie defaŭlte.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host Kaj ĝia esenco estas, ke ni povas diri en la pod, ke ni lanĉas, eĉ sen rajtoj pri ĉi tiu grapolo, ke ni volas krei volumon de tipo hostPath. Ĉi tio signifas preni la vojon de la gastiganto sur kiu ni lanĉos - kaj preni ĝin kiel volumon. Kaj tiam ni nomas ĝin nomo: gastiganto. Ni muntas ĉi tiun tutan hostPath ene de la pod. En ĉi tiu ekzemplo, al la dosierujo /host.
Mi ripetos ĝin denove. Ni diris al la podo veni al la mastro, ricevi la hostReton kaj hostPID tie - kaj munti la tutan radikon de la mastro ene de ĉi tiu pod.
Vi komprenas, ke en Debian ni havas bash funkcianta, kaj ĉi tiu bash funkcias sub radiko. Tio estas, ni ĵus ricevis radikon sur la majstro, sen havi ajnajn rajtojn en la Kubernetes-grupo.
Tiam la tuta tasko estas iri al la subdosierujo /host /etc/kubernetes/pki, se mi ne eraras, prenu ĉiujn majstrajn atestojn de la grapolo tie kaj, sekve, fariĝu la administranto de la cluster.
Se vi rigardas ĝin tiel, ĉi tiuj estas kelkaj el la plej danĝeraj rajtoj en podoj - sendepende de kiaj rajtoj havas la uzanto:
Se mi havas la rajtojn ruli pod en iu nomspaco de la areto, tiam ĉi tiu pod havas ĉi tiujn rajtojn defaŭlte. Mi povas ruli privilegiitajn podojn, kaj ĉi tiuj ĝenerale estas ĉiuj rajtoj, praktike radiko sur la nodo.
Mia plej ŝatata estas Root-uzanto. Kaj Kubernetes havas ĉi tiun opcion Run As Non-Root. Ĉi tio estas speco de protekto kontraŭ retpirato. Ĉu vi scias kio estas la "moldava viruso"? Se vi subite estas hakisto kaj venas al mia Kubernetes-grupo, tiam ni, malriĉaj administrantoj, demandas: "Bonvolu indiki en viaj podoj, per kiuj vi hakos mian areton, ruliĝu kiel ne-radiko. Alie, okazos, ke vi kuras la procezon en via pod sub radiko, kaj estos tre facile por vi haki min. Bonvolu protekti vin kontraŭ vi mem."
Gastiganta vojo-volumo estas, laŭ mi, la plej rapida maniero akiri la deziratan rezulton de Kubernetes-areto.
Sed kion fari kun ĉio ĉi?
La penso, kiu devus veni al iu normala administranto, kiu renkontas Kubernetes, estas: "Jes, mi diris al vi, Kubernetes ne funkcias. Estas truoj en ĝi. Kaj la tuta Kubo estas abomenaĵo.” Fakte, ekzistas tia afero kiel dokumentado, kaj se vi rigardas tie, estas sekcio .
Ĉi tio estas yaml-objekto - ni povas krei ĝin en la Kubernetes-grupo - kiu kontrolas sekurecajn aspektojn specife en la priskribo de la podoj. Tio estas, fakte, ĝi kontrolas la rajtojn uzi ajnan hostNetwork, hostPID, certajn volumtipojn kiuj estas en la podoj ĉe ekfunkciigo. Kun la helpo de Pod Sekureca Politiko, ĉio ĉi povas esti priskribita.
La plej interesa afero pri la Pod Sekureca Politiko estas, ke en la Kubernetes-areto, ĉiuj PSP-instaliloj ne estas iel ajn priskribitaj, ili estas simple malŝaltitaj defaŭlte. Pod Sekurecpolitiko estas ebligita uzante la akceptan kromprogramon.
Bone, ni deplojigu Pod-Sekurecpolitikon en la areton, ni diru, ke ni havas kelkajn servajn podojn en la nomspaco, al kiu nur administrantoj havas aliron. Ni diru, en ĉiuj aliaj kazoj, balgoj havas limigitajn rajtojn. Ĉar plej verŝajne programistoj ne bezonas ruli privilegiitajn podojn en via areto.
Kaj ĉio ŝajnas esti bona ĉe ni. Kaj nia Kubernetes-areo ne povas esti pirata en du minutoj.
Estas problemo. Plej verŝajne, se vi havas Kubernetes-grupon, tiam monitorado estas instalita sur via areto. Mi eĉ irus ĝis nun por antaŭdiri, ke se via areto havas monitoradon, ĝi nomos Prometeo.
Kion mi estas dironta al vi, estos valida por kaj la Prometheus-funkciigisto kaj Prometheus liverita en ĝia pura formo. La demando estas, ke se mi ne povas eniri administranton en la areton tiel rapide, tiam tio signifas, ke mi devas rigardi pli. Kaj mi povas serĉi helpe de via monitorado.
Verŝajne ĉiuj legas la samajn artikolojn pri Habré, kaj la monitorado troviĝas en la monitora nomspaco. Helm-diagramo estas nomata proksimume same por ĉiuj. Mi supozas, ke se vi helm install stable/prometheus, vi finiĝos kun proksimume la samaj nomoj. Kaj plej verŝajne mi eĉ ne devos diveni la DNS-nomon en via areto. Ĉar ĝi estas norma.
Poste ni havas certajn dev ns, en kiuj vi povas ruli certan pod. Kaj tiam de ĉi tiu podo estas tre facile fari ion tian:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics estas unu el la eksportantoj de Prometheus, kiu kolektas metrikojn de la Kubernetes API mem. Estas multaj datumoj tie, kio funkcias en via areto, kio ĝi estas, kiaj problemoj vi havas kun ĝi.
Kiel simpla ekzemplo:
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
Farante simplan buklan peton de senprivilegia pod, vi povas ricevi la sekvajn informojn. Se vi ne scias, kian version de Kubernetes vi funkcias, ĝi facile diros al vi.
Kaj la plej interesa afero estas, ke krom aliri kube-state-metrics, vi povas same facile aliri Prometeon mem rekte. Vi povas kolekti metrikojn de tie. Vi eĉ povas konstrui metrikojn de tie. Eĉ teorie, vi povas konstrui tian demandon de areto en Prometheus, kiu simple malŝaltos ĝin. Kaj via monitorado ĉesos funkcii de la areto entute.
Kaj ĉi tie staras la demando ĉu iu ekstera monitorado kontrolas vian monitoradon. Mi ĵus ricevis la ŝancon funkcii en Kubernetes-areo sen konsekvencoj por mi mem. Vi eĉ ne scios, ke mi funkcias tie, ĉar ne plu estas monitorado.
Same kiel kun la PSP, oni sentas, ke la problemo estas, ke ĉiuj ĉi tiuj ŝikaj teknologioj - Kubernetes, Prometheus - ili simple ne funkcias kaj estas plenaj de truoj. Ne vere.
Estas tia afero - .
Se vi estas normala administranto, tiam plej verŝajne vi scias pri Reta Politiko, ke ĉi tio estas nur alia yaml, el kiu jam estas multaj en la areto. Kaj iuj Retaj Politikoj certe ne estas bezonataj. Kaj eĉ se vi legas kio estas Reta Politiko, ke ĝi estas yaml-fajroŝirmilo de Kubernetes, ĝi permesas vin limigi alirrajtojn inter nomspacoj, inter podoj, tiam vi certe decidis, ke la fajroŝirmilo en yaml-formato en Kubernetes baziĝas sur la sekvaj abstraktaĵoj. ... Ne, ne . Ĉi tio certe ne estas necesa.
Eĉ se vi ne diris al viaj sekurecaj specialistoj, ke uzante vian Kubernetes vi povas konstrui tre facilan kaj simplan fajroŝirmilon, kaj tre grajnecan ĉe tio. Se ili ankoraŭ ne scias ĉi tion kaj ne ĝenas vin: "Nu, donu al mi, donu al mi..." Tiam ĉiukaze vi bezonas Retan Politikon por bloki aliron al iuj servaj lokoj, kiuj povas esti eltiritaj el via areto. sen ajna rajtigo.
Kiel en la ekzemplo, kiun mi donis, vi povas eltiri kube-ŝtatajn metrikojn de iu ajn nomspaco en la Kubernetes-areto sen havi ajnajn rajtojn fari tion. Retaj politikoj fermis aliron de ĉiuj aliaj nomspacoj al la monitora nomspaco kaj jen ĝi: neniu aliro, neniuj problemoj. En ĉiuj leteroj kiuj ekzistas, kaj la norma Prometheus kaj la Prometheus kiu estas en la funkciigisto, estas simple eblo en la stirvaloroj por simple ebligi retajn politikojn por ili. Vi nur bezonas ŝalti ĝin kaj ili funkcios.
Estas vere unu problemo ĉi tie. Estante normala barba administranto, vi plej verŝajne decidis, ke retaj politikoj ne estas bezonataj. Kaj leginte ĉiajn artikolojn pri rimedoj kiel Habr, vi decidis, ke flanelo, precipe kun gastiga-pordeja reĝimo, estas la plej bona afero, kiun vi povas elekti.
Kion mi faru?
Vi povas provi redeploji la retan solvon, kiun vi havas en via Kubernetes-grupo, provu anstataŭigi ĝin per io pli funkcia. Por la sama Calico, ekzemple. Sed mi volas diri tuj, ke la tasko ŝanĝi la retan solvon en laborklapo de Kubernetes estas tute ne-triviala. Mi solvis ĝin dufoje (ambaŭfoje tamen teorie), sed ni eĉ montris kiel fari ĝin ĉe Slurms. Por niaj studentoj, ni montris kiel ŝanĝi la retan solvon en Kubernetes-areo. Principe, vi povas provi certigi, ke ne estas malfunkcio en la produktadgrupo. Sed verŝajne vi ne sukcesos.
Kaj la problemo estas efektive solvita tre simple. Estas atestiloj en la areto, kaj vi scias, ke viaj atestiloj eksvalidiĝos post unu jaro. Nu, kaj kutime normala solvo kun atestiloj en la areto - kial ni maltrankviliĝas, ni levos novan areton proksime, lasos la malnovan putriĝi kaj redeplojos ĉion. Vere, kiam ĝi putriĝos, ni devos sidi dum unu tago, sed jen nova areto.
Kiam vi levas novan areton, samtempe enmetu Kalikon anstataŭ flanelo.
Kion fari se viaj atestiloj estas eldonitaj dum cent jaroj kaj vi ne redeplojos la areton? Estas tia afero kiel Kube-RBAC-Proxy. Ĉi tio estas tre bonega evoluo, ĝi ebligas al vi enkonstrui sin kiel kroman ujon al iu ajn pod en la Kubernetes-areo. Kaj ĝi fakte aldonas rajtigon al ĉi tiu pod per RBAC de Kubernetes mem.
Estas unu problemo. Antaŭe, ĉi tiu solvo Kube-RBAC-Proxy estis konstruita en la Prometheus de la funkciigisto. Sed tiam li estis for. Nun modernaj versioj dependas de tio, ke vi havas retan politikon kaj fermas ĝin uzante ilin. Kaj tial ni devos reverki la diagramon iomete. Fakte, se vi iras al , estas ekzemploj pri kiel uzi ĉi tion kiel kromĉarojn, kaj la furorlisto devos esti reverkitaj minimume.
Estas unu pli malgranda problemo. Prometeo ne estas la sola kiu disdonas siajn metrikojn al iu ajn. Ĉiuj niaj Kubernetes-grupo-komponentoj ankaŭ povas resendi siajn proprajn metrikojn.
Sed kiel mi jam diris, se vi ne povas aliri la areton kaj kolekti informojn, tiam vi povas almenaŭ fari iom da malbono.
Do mi rapide montros du manierojn kiel Kubernetes-areo povas esti ruinigita.
Vi ridos kiam mi diros al vi ĉi tion, ĉi tiuj estas du realaj kazoj.
Metodo unu. Elĉerpiĝo de rimedoj.
Ni lanĉu alian specialan guŝon. Ĝi havos sekcion kiel ĉi tiu.
resources:
requests:
cpu: 4
memory: 4Gi Kiel vi scias, petoj estas la kvanto de CPU kaj memoro, kiu estas rezervita en la gastiganto por specifaj podoj kun petoj. Se ni havas kvar-kernan gastiganton en Kubernetes-areto, kaj kvar CPU-podoj alvenas tie kun petoj, tio signifas, ke ne pliaj podoj kun petoj povos veni al ĉi tiu gastiganto.
Se mi rulas tian pod, tiam mi funkcios la komandon:
$ kubectl scale special-pod --replicas=...Tiam neniu alia povos deploji al la Kubernetes-areo. Ĉar ĉiuj nodoj elĉerpiĝos de petoj. Kaj tiel mi haltigos vian Kubernetes-grupon. Se mi faras tion vespere, mi povas ĉesigi la deplojojn dum sufiĉe longa tempo.
Se ni denove rigardas la Kubernetes-dokumentadon, ni vidos ĉi tiun aferon nomatan Limiga Gamo. Ĝi fiksas rimedojn por aretobjektoj. Vi povas skribi objekton de Limit Range en yaml, apliki ĝin al certaj nomspacoj - kaj tiam en ĉi tiu nomspaco vi povas diri, ke vi havas defaŭltajn, maksimumajn kaj minimumajn rimedojn por la podoj.
Helpe de tia afero, ni povas limigi uzantojn en specifaj produktaj nomspacoj de teamoj en la kapablo indiki ĉiajn malbonajn aferojn sur siaj podoj. Sed bedaŭrinde, eĉ se vi diras al la uzanto, ke ili ne povas lanĉi podojn kun petoj por pli ol unu CPU, ekzistas tia mirinda skala komando, aŭ ili povas fari skalon per la panelo.
Kaj ĉi tie venas metodo numero du. Ni lanĉas 11 podojn. Tio estas dek unu miliardoj. Ĉi tio ne estas ĉar mi elpensis tian nombron, sed ĉar mi mem vidis ĝin.
Vera rakonto. Malfrue vespere mi estis elironta la oficejon. Mi vidas grupon da programistoj sidantaj en la angulo, freneze farante ion per siaj tekkomputiloj. Mi iras al la infanoj kaj demandas: "Kio okazis al vi?"
Iom pli frue, ĉirkaŭ la naŭa vespere, unu el la programistoj prepariĝis por iri hejmen. Kaj mi decidis: "Mi nun skalos mian kandidatiĝon al unu." Mi premis unu, sed la Interreto iomete malrapidiĝis. Li denove premis tiun, li premis tiun, kaj klakis Enigu. Mi pikis ĉion, kion mi povis. Tiam la Interreto ekviviĝis - kaj ĉio komencis reduktiĝi al ĉi tiu nombro.
Vere, ĉi tiu rakonto ne okazis sur Kubernetes; tiutempe ĝi estis Nomado. Ĝi finiĝis per tio, ke post unu horo da niaj provoj maldaŭrigi Nomadon de persistaj provoj grimpi, Nomado respondis, ke li ne ĉesos grimpi kaj ne faros ion alian. "Mi estas laca, mi foriras." Kaj li kurbiĝis.
Kompreneble, mi provis fari la samon ĉe Kubernetes. Kubernetes ne estis feliĉa kun dek unu miliardoj da podoj, li diris: "Mi ne povas. Superas internajn buŝprotektojn." Sed 1 balgoj povus.
Responde al unu miliardo, la Kubo ne retiriĝis en si mem. Li vere komencis grimpi. Ju pli la procezo iris, des pli da tempo li bezonis por krei novajn podojn. Sed tamen la procezo daŭris. La nura problemo estas, ke se mi povas lanĉi podojn senlime en mia nomspaco, tiam eĉ sen petoj kaj limoj mi povas lanĉi tiom da podoj kun iuj taskoj, ke helpe de ĉi tiuj taskoj la nodoj komencos kuniĝi en memoro, en CPU. Kiam mi lanĉas tiom da podoj, la informoj de ili devus eniri en stokadon, tio estas, ktp. Kaj kiam tro multe da informoj alvenas tie, la stokado komencas reveni tro malrapide - kaj Kubernetes komencas fariĝi obtuza.
Kaj ankoraŭ unu problemo... Kiel vi scias, la kontrolelementoj de Kubernetes ne estas unu centra afero, sed pluraj komponantoj. Precipe, ekzistas regilo-manaĝero, planisto, ktp. Ĉiuj ĉi tiuj uloj komencos fari nenecesan, stultan laboron samtempe, kiu kun la tempo komencos preni pli kaj pli da tempo. La regilo-manaĝero kreos novajn podojn. Scheduler provos trovi novan nodon por ili. Vi plej verŝajne elĉerpiĝos el novaj nodoj en via areto baldaŭ. La Kubernetes-grupo komencos funkcii pli kaj pli malrapide.
Sed mi decidis iri eĉ plu. Kiel vi scias, en Kubernetes ekzistas tia afero nomata servo. Nu, defaŭlte en viaj aretoj, plej verŝajne, la servo funkcias uzante IP-tabelojn.
Se vi rulas unu miliardon da podoj, ekzemple, kaj poste uzas skripton por devigi Kubernetis krei novajn servojn:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done Sur ĉiuj nodoj de la areto, pli kaj pli da novaj iptables-reguloj estos generitaj proksimume samtempe. Plie, unu miliardo iptables reguloj estos generitaj por ĉiu servo.
Mi kontrolis ĉi tiun tutan aferon je pluraj miloj, ĝis dek. Kaj la problemo estas, ke jam ĉe ĉi tiu sojlo estas sufiĉe probleme fari ssh al la nodo. Ĉar pakaĵoj, trairantaj tiom da ĉenoj, komencas sentiĝi ne tre bone.
Kaj ĉi tio ankaŭ estas ĉio solvita kun la helpo de Kubernetes. Estas tia Rimeda kvotobjekto. Agordas la nombron da disponeblaj rimedoj kaj objektoj por la nomspaco en la areto. Ni povas krei yaml-objekton en ĉiu nomspaco de la Kubernetes-grupo. Uzante ĉi tiun objekton, ni povas diri, ke ni havas certan nombron da petoj kaj limoj asignitaj por ĉi tiu nomspaco, kaj tiam ni povas diri, ke en tiu ĉi nomspaco eblas krei 10 servojn kaj 10 podojn. Kaj ununura programisto povas almenaŭ sufoki sin vespere. Kubernetes diros al li: "Vi ne povas grimpi viajn podojn al tiu kvanto, ĉar la rimedo superas la kvoton." Jen, problemo solvita. .
Unu problema punkto ekestas ĉi-rilate. Vi sentas, kiel malfacile fariĝas krei nomspacon en Kubernetes. Por krei ĝin, ni devas konsideri multajn aferojn.
Rimeda kvoto + Limiga Gamo + RBAC
• Krei nomspacon
• Krei limgamon ene
• Krei ene rimedkvoton
• Krei servokonton por CI
• Krei rolligadon por CI kaj uzantoj
• Laŭvole lanĉi la necesajn servajn podojn
Tial mi ŝatus profiti ĉi tiun okazon por konigi miajn evoluojn. Estas tia afero nomata SDK-operatoro. Ĉi tio estas maniero por Kubernetes-grupo skribi operatorojn por ĝi. Vi povas skribi deklarojn uzante Ansible.
Komence ĝi estis skribita en Ansible, kaj tiam mi vidis ke ekzistas SDK-funkciigisto kaj reverkis la Ansible-rolon en funkciigiston. Ĉi tiu deklaro permesas krei objekton en la Kubernetes-grupo nomata komando. Ene de komando, ĝi permesas vin priskribi la medion por ĉi tiu komando en yaml. Kaj ene de la teama medio, ĝi permesas al ni priskribi, ke ni asignas tiom da rimedoj.
Malgranda unu .
Kaj konklude. Kion fari kun ĉio ĉi?
Unue. Pod Sekurecpolitiko estas bona. Kaj malgraŭ tio, ke neniu el la instaliloj de Kubernetes uzas ilin ĝis hodiaŭ, vi ankoraŭ bezonas uzi ilin en viaj aretoj.
Reta Politiko ne estas nur alia nenecesa funkcio. Ĉi tio estas vere necesa en areto.
LimitRange/ResourceQuota - estas tempo uzi ĝin. Ni komencis uzi ĉi tion antaŭ longe, kaj dum longa tempo mi estis certa, ke ĉiuj uzas ĝin. Montriĝis, ke ĉi tio estas malofta.
Krom tio, kion mi menciis dum la raporto, ekzistas nedokumentitaj funkcioj, kiuj permesas vin ataki la areton. Liberigita lastatempe .
Iuj aferoj estas tiel malĝojaj kaj doloraj. Ekzemple, sub certaj kondiĉoj, kubeletoj en Kubernetes-areto povas doni la enhavon de la dosierujo de sorĉistoj al neaŭtorizita uzanto.
Estas instrukcioj pri kiel reprodukti ĉion, kion mi diris al vi. Estas dosieroj kun produktaj ekzemploj pri kiel aspektas ResourceQuota kaj Pod Security Policy. Kaj vi povas tuŝi ĉion ĉi.
Dankon al ĉiuj.
fonto: www.habr.com