De Pavel Selivanov, Southbridge Solutions Architekt a Slurm Enseignant, huet eng Presentatioun um DevOpsConf 2019. Dës Diskussioun ass Deel vun engem vun den Themen vum am-Déift Cours op Kubernetes "Slurm Mega".
statt zu Moskau 18-20 November.
- Moskau, 22-24 November.
ëmmer verfügbar.
Ënnert dem Schnëtt ass en Transkript vum Bericht.
Gudde Mëtteg, Kolleegen an déi, déi mat hinne sympathéieren. Haut wäert ech iwwer Sécherheet schwätzen.
Ech gesinn, datt et haut vill Sécherheetsleit an der Hal sinn. Ech entschëllegen Iech am Viraus wann ech Begrëffer aus der Welt vun der Sécherheet benotzen net genau wéi dat fir Iech üblech ass.
Et ass sou geschitt, datt ech viru ronn sechs Méint op en ëffentleche Kubernetes-Cluster koum. Ëffentlech heescht datt et eng n. Zuel vun Nummraim gëtt; an dësen Nummraim ginn et Benotzer an hirem Nummraum isoléiert. All dës Benotzer gehéieren zu verschiddene Firmen. Gutt, et gouf ugeholl datt dëse Stärekoup als CDN benotzt soll ginn. Dat ass, si ginn Iech e Stärekoup, si ginn Iech e Benotzer do, Dir gitt do an Ären Nummraum, setzt Är Fronten of.
Meng fréier Firma huet probéiert esou e Service ze verkafen. An ech gouf gefrot de Cluster ze pochen fir ze kucken ob dës Léisung gëeegent ass oder net.
Ech sinn zu dësem Cluster komm. Ech krut limitéiert Rechter, limitéiert Nummraum. D'Jongen do hu verstanen wat Sécherheet war. Si liesen iwwer Roll-baséiert Zougangskontroll (RBAC) zu Kubernetes - a si hunn et verdréit sou datt ech net Pods getrennt vun Deployementer lancéiere konnt. Ech erënnere mech net un de Problem deen ech probéiert hunn ze léisen andeems ech e Pod ouni Deployment starten, awer ech wollt wierklech just e Pod starten. Fir Vill Gléck hunn ech beschloss ze gesinn wat Rechter ech am Cluster hunn, wat ech maache kann, wat ech net maachen a wat se do verschrauft hunn. Zur selwechter Zäit wäert ech Iech soen wat se am RBAC falsch konfiguréiert hunn.
Et ass geschitt, datt ech an zwou Minutten en Admin an hire Stärekoup krut, all d'Nopeschnummraim gekuckt hunn, do déi lafend Produktiounsfronte vu Firmen gesinn hunn, déi de Service scho kaaft hunn an ofgesat hunn. Ech konnt mech kaum ophalen fir op engem seng Front ze goen an e Schwieregkeetswuert op der Haaptsäit ze setzen.
Ech soen Iech mat Beispiller wéi ech dat gemaach hunn a wéi Dir Iech dovunner schützt.
Awer als éischt, loosst mech mech virstellen. Mäin Numm ass Pavel Selivanov. Ech sinn en Architekt zu Southbridge. Ech verstinn Kubernetes, DevOps an all Zorte vu flotte Saachen. D'Southbridge Ingenieuren an ech bauen all dëst, an ech consultéieren.
Zousätzlech zu eisen Haaptaktivitéiten hu mir viru kuerzem Projete mam Numm Slurms lancéiert. Mir probéieren eis Fäegkeet fir mat Kubernetes e bëssen un d'Massen ze bréngen, fir aner Leit ze léieren och mat K8s ze schaffen.
Iwwer wat wäert ech haut schwätzen? D'Thema vum Bericht ass evident - iwwer d'Sécherheet vum Kubernetes-Cluster. Awer ech wëll direkt soen datt dëst Thema ganz grouss ass - an dofir wëll ech direkt klären iwwer wat ech definitiv net schwätzen. Ech wäert net iwwer gehackte Begrëffer schwätzen, déi schonn honnertmol um Internet benotzt goufen. All Zorte vu RBAC an Certificaten.
Ech wäert schwätzen iwwer wat mech a meng Kollegen iwwer Sécherheet an engem Kubernetes Cluster deet. Mir gesinn dës Probleemer souwuel bei Ubidder déi Kubernetes Cluster ubidden wéi och bei Clienten déi bei eis kommen. An och vu Clienten déi bei eis kommen aus anere Berodungsadministratiounsfirmen. Dat ass, d'Skala vun der Tragödie ass eigentlech ganz grouss.
Et gi wuertwiertlech dräi Punkten iwwer déi ech haut wäert schwätzen:
- Benotzerrechter vs Pod Rechter. Benotzerrechter a Podrechter sinn net déiselwecht Saach.
- Sammelt Informatiounen iwwer de Stärekoup. Ech wäert weisen datt Dir all d'Informatioune sammele kënnt, déi Dir braucht aus engem Cluster ouni speziell Rechter an dësem Cluster ze hunn.
- DoS Attack op de Stärekoup. Wa mir d'Informatioun net sammelen kënnen, kënne mir op alle Fall e Cluster setzen. Ech wäert iwwer DoS Attacken op Cluster Kontrollelementer schwätzen.
Eng aner allgemeng Saach, déi ech wäert ernimmen, ass wat ech dat alles getest hunn, op deem ech definitiv soen kann datt et alles funktionnéiert.
Mir huelen als Basis d'Installatioun vun engem Kubernetes Cluster mat Kubespray. Wann iergendeen et net weess, ass dëst tatsächlech eng Rei vu Rollen fir Ansible. Mir benotzen et permanent an eiser Aarbecht. Déi gutt Saach ass datt Dir et iwwerall ka rullen - Dir kënnt et op Eisenstécker oder iergendwou an eng Wollek rullen. Eng Installatiounsmethod funktionnéiert am Prinzip fir alles.
An dësem Stärekoup wäert ech Kubernetes v1.14.5 hunn. De ganze Cube-Cluster, dee mir betruechten, ass an Nummraim opgedeelt, all Nummraum gehéiert zu engem separaten Team, a Membere vun dësem Team hunn Zougang zu all Nummraum. Si kënnen net op verschidden Nummraim goen, nëmmen op hir eegen. Awer et gëtt e gewëssenen Admin Kont deen Rechter op de ganze Cluster huet.
Ech hunn versprach datt dat éischt wat mir maache wäerten ass Admin Rechter fir de Cluster ze kréien. Mir brauchen e speziell preparéierten Pod deen de Kubernetes Cluster briechen. Alles wat mir maache mussen ass et op de Kubernetes Cluster uwenden.
kubectl apply -f pod.yamlDëse Pod kënnt un ee vun de Meeschter vum Kubernetes Cluster. An duerno wäert de Cluster eis glécklech e Fichier mam Numm admin.conf zréckginn. Am Cube späichert dës Datei all Administratorzertifikater, a konfiguréiert gläichzäiteg de Cluster API. Dëst ass wéi einfach et ass den Admin Zougang zu, mengen ech, 98% vu Kubernetes Cluster ze kréien.
Ech widderhuelen, dëse Pod gouf vun engem Entwéckler an Ärem Cluster gemaach, deen Zougang huet fir seng Propositiounen an e klengen Nummraum z'installéieren, et ass alles vum RBAC ageklemmt. Hien hat keng Rechter. Awer trotzdem gouf den Zertifika zréckginn.
An elo iwwer e speziell preparéierten Pod. Mir lafen et op all Bild. Loosst eis debian:jessie als Beispill huelen.
Mir hunn dës Saach:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Wat ass Toleranz? Masters an engem Kubernetes Stärekoup sinn normalerweis mat eppes markéiert genannt Taint. An d'Essenz vun dëser "Infektioun" ass datt et seet datt Pods net op Meeschteschnoden zougewisen kënne ginn. Awer kee stéiert sech an all Pod ze weisen datt et tolerant ass fir d'"Infektioun". D'Toleratiounssektioun seet just datt wann e puer Node NoSchedule huet, dann ass eise Node tolerant fir sou eng Infektioun - an et gi keng Probleemer.
Weider soen mir datt eis Ënner net nëmmen tolerant ass, awer och speziell op de Meeschter wëll zielen. Well d'Meeschteren déi leckerst Saach hunn, déi mir brauchen - all d'Zertifikater. Dofir soen mir nodeSelector - a mir hunn e Standardlabel op Meeschter, wat Iech erlaabt aus all de Wirbelen am Stärekoup genee déi Wirbelen ze wielen déi Meeschter sinn.
Mat dësen zwou Sektiounen wäert hien definitiv bei de Meeschter kommen. An hien dierf do liewen.
Mee just bei de Meeschter kommen geet eis net duer. Dëst wäert eis näischt ginn. Also als nächst hu mir dës zwou Saachen:
hostNetwork: true
hostPID: true Mir spezifizéieren datt eise Pod, dee mir lancéieren, am Kernel Nummraum, am Netznummraum an am PID Nummraum liewen. Wann de Pod um Master lancéiert ass, wäert et fäeg sinn all déi richteg, Live Interfaces vun dësem Node ze gesinn, all Traffic lauschteren an de PID vun alle Prozesser gesinn.
Da geet et ëm kleng Saachen. Huelt etcd a liesen wat Dir wëllt.
Déi interessantst Saach ass dës Kubernetes Feature, déi do par défaut präsent ass.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host A seng Essenz ass datt mir am Pod kënne soen datt mir lancéieren, och ouni Rechter op dëse Cluster, datt mir e Volume vum Typ hostPath erstellen wëllen. Dëst bedeit de Wee vum Host ze huelen op deem mir starten - an et als Volume huelen. An dann nennen mir et Numm: Host. Mir montéieren dëse ganze HostPath am Pod. An dësem Beispill, an den /host Verzeechnes.
Ech widderhuelen et nach eng Kéier. Mir hunn dem Pod gesot fir bei de Master ze kommen, de HostNetwork an den HostPID do ze kréien - a montéiert déi ganz Root vum Master an dësem Pod.
Dir verstitt datt an Debian mir Bash Lafen hunn, an dëse Bash leeft ënner Root. Dat ass, mir kruten just root op de Meeschter, ouni Rechter am Kubernetes Cluster ze hunn.
Dann ass d'ganz Aufgab fir an den Ënnerverzeechnes /host /etc/kubernetes/pki ze goen, wann ech mech net falsch maachen, all d'Meeschterzertifikater vum Cluster do ophuelen an deementspriechend de Clusteradministrator ginn.
Wann Dir et esou kuckt, sinn dëst e puer vun de geféierlechste Rechter a Pods - egal wéi eng Rechter de Benotzer huet:
Wann ech d'Rechter hunn fir e Pod an engem Nummraum vum Cluster ze lafen, dann huet dëse Pod dës Rechter als Standard. Ech kann privilegiéiert Pods lafen, an dës sinn allgemeng all Rechter, praktesch root op der Node.
Mäi Favorit ass Root Benotzer. A Kubernetes huet dës Run As Non-Root Optioun. Dëst ass eng Zort Schutz vun engem Hacker. Wësst Dir wat de "Moldavian Virus" ass? Wann Dir op eemol en Hacker sidd an a mengem Kubernetes-Cluster kommt, da froe mir, aarm Administrateuren: "Gitt w.e.g. an Äre Pods un, mat deenen Dir mäi Cluster hackt, lafen als net-root. Soss wäert et geschéien datt Dir de Prozess an Ärem Pod ënner Root leeft, an et wäert ganz einfach sinn fir mech ze hacken. Schützt Iech w.e.g. virun Iech selwer."
Host Wee Volumen ass menger Meenung no de schnellste Wee fir dat gewënschte Resultat aus engem Kubernetes Cluster ze kréien.
Awer wat maache mat all deem?
De Gedanken, deen un all normalen Administrateur sollt kommen, deen Kubernetes begéint ass: "Jo, ech hunn Iech gesot, Kubernetes funktionnéiert net. Et gi Lächer dran. An de ganze Cube ass Bullshit. Tatsächlech gëtt et sou eppes wéi Dokumentatioun, a wann Dir do kuckt, gëtt et eng Rubrik .
Dëst ass e Yaml Objet - mir kënnen et am Kubernetes Cluster erstellen - deen d'Sécherheetsaspekter speziell an der Beschreiwung vun de Pods kontrolléiert. Dat ass, tatsächlech, et kontrolléiert d'Rechter fir all HostNetwork, HostPID, gewësse Volumentypen ze benotzen déi an de Pods beim Start sinn. Mat der Hëllef vu Pod Sécherheetspolitik kann dëst alles beschriwwe ginn.
Déi interessantst Saach iwwer d'Pod Sécherheetspolitik ass datt am Kubernetes Cluster all PSP Installateuren net nëmmen op iergendeng Manéier beschriwwe ginn, si sinn einfach standardiséiert ausgeschalt. Pod Sécherheetspolitik ass aktivéiert mam Admission Plugin.
Okay, loosst eis Pod Sécherheetspolitik an de Cluster ofsetzen, loosst eis soen datt mir e puer Service Pods am Nummraum hunn, op déi nëmmen Admins Zougang hunn. Loosst eis soen, an all anere Fäll hu Pods limitéiert Rechter. Well déi meescht wahrscheinlech Entwéckler brauchen net privilegiéiert Pods an Ärem Cluster ze lafen.
An alles schéngt gutt mat eis ze sinn. An eise Kubernetes Cluster kann net an zwou Minutten gehackt ginn.
Et gëtt e Problem. Wahrscheinlech, wann Dir e Kubernetes Cluster hutt, da gëtt d'Iwwerwaachung op Ärem Cluster installéiert. Ech géif souguer esou wäit goen wéi virauszesoen datt wann Äre Stärekoup Iwwerwaachung huet, et Prometheus genannt gëtt.
Wat ech Iech elo soen wäert gëlteg sinn fir souwuel de Prometheus Bedreiwer wéi och de Prometheus a senger reiner Form geliwwert. D'Fro ass datt wann ech net sou séier en Admin an de Cluster kréien, da bedeit dat datt ech méi muss kucken. An ech kann mat der Hëllef vun Ärer Iwwerwaachung sichen.
Wahrscheinlech liest jiddereen déiselwecht Artikelen iwwer Habré, an d'Iwwerwaachung läit am Iwwerwaachungsnummraum. Helm Chart gëtt ongeféier d'selwecht fir jiddereen genannt. Ech roden datt wann Dir Helm installéiert stabil / prometheus, Dir wäert mat ongeféier déiselwecht Nimm ophalen. A wahrscheinlech muss ech net emol den DNS Numm an Ärem Cluster roden. Well et ass Standard.
Als nächst hu mir e bestëmmten Dev ns, an deem Dir e bestëmmte Pod lafen kann. An dann aus dësem Pod ass et ganz einfach esou eppes ze maachen:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics ass ee vun de Prometheus Exporter déi Metriken aus der Kubernetes API selwer sammelt. Et gi vill Donnéeën do, wat leeft an Ärem Cluster, wat ass et, wat Problemer Dir mat et.
Als einfach Beispill:
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
Andeems Dir eng einfach Curl Ufro vun engem onprivilegéierte Pod maacht, kënnt Dir déi folgend Informatioun kréien. Wann Dir net wësst wéi eng Versioun vu Kubernetes Dir leeft, wäert et Iech einfach soen.
An déi interessantst Saach ass datt nieft dem Zougang zu Kube-State-Metriken, Dir kënnt grad esou einfach direkt op Prometheus selwer kommen. Dir kënnt Metriken vun do sammelen. Dir kënnt souguer Metriken vun do aus bauen. Och theoretesch kënnt Dir esou eng Ufro aus engem Cluster am Prometheus bauen, wat et einfach ausschalt. An Är Iwwerwachung wäert ophalen aus dem Cluster ze schaffen.
An hei stellt sech d'Fro ob iergendeng extern Iwwerwaachung Är Iwwerwaachung iwwerwaacht. Ech krut just d'Méiglechkeet an engem Kubernetes Cluster ze bedreiwen ouni Konsequenze fir mech selwer. Dir wësst net emol datt ech do schaffen, well et keng Iwwerwaachung méi gëtt.
Just wéi mam PSP, fillt et sech wéi de Problem ass datt all dës ausgefalene Technologien - Kubernetes, Prometheus - se einfach net funktionnéieren a voller Lächer sinn. Net wierklech.
Et gëtt sou eppes - .
Wann Dir en normalen Administrateur sidd, da wësst Dir wahrscheinlech iwwer d'Netzwierkpolitik datt dëst just eng aner Yaml ass, vun deenen et scho vill am Cluster sinn. An e puer Reseau Politiken sinn definitiv net néideg. An och wann Dir liest wat Network Policy ass, datt et eng Yaml Firewall vu Kubernetes ass, et erlaabt Iech Zougangsrechter tëscht Nummraim, tëscht Pods ze limitéieren, dann hutt Dir sécher decidéiert datt d'Firewall am Yaml-Format zu Kubernetes baséiert op den nächsten Abstraktiounen ... Nee, nee. Dëst ass definitiv net néideg.
Och wann Dir Är Sécherheetsspezialisten net gesot hutt datt Dir Är Kubernetes benotzt, kënnt Dir eng ganz einfach an einfach Firewall bauen, an och eng ganz granulär. Wann se dat nach net wëssen an Iech net stéieren: "Ma, gitt mir, gitt mir ..." Dann brauch Dir op jidde Fall Network Policy fir den Zougang zu e puer Serviceplazen ze blockéieren déi aus Ärem Cluster gezunn kënne ginn ouni Autorisatioun.
Wéi am Beispill, deen ech uginn hunn, kënnt Dir Kube Staatsmetriken aus all Nummraum am Kubernetes Cluster opzéien ouni Rechter ze maachen. Netzpolitiken hunn den Zougang vun allen aneren Nummraim zum Iwwerwaachungsnummraum zougemaach an dat ass et: keen Zougang, keng Probleemer. An all Charts déi existéieren, souwuel de Standard Prometheus wéi och de Prometheus deen am Bedreiwer ass, gëtt et einfach eng Optioun an den Helmwäerter fir einfach Netzwierkpolitike fir si z'aktivéieren. Dir musst et just ausschalten a si funktionnéieren.
Et gëtt wierklech ee Problem hei. Als normale bäertege Administrateur ze sinn, hutt Dir héchstwahrscheinlech decidéiert datt d'Netzpolitik net gebraucht gëtt. An nodeems Dir all Zort vun Artikelen iwwer Ressourcen wéi Habr gelies hutt, hutt Dir decidéiert datt Flanell, besonnesch mam Host-Gateway-Modus, dat Bescht ass wat Dir kënnt wielen.
Wat soll ech maachen?
Dir kënnt probéieren d'Netzwierkléisung déi Dir an Ärem Kubernetes-Cluster hutt nei z'installéieren, probéiert et mat eppes méi funktionell ze ersetzen. Fir déi selwecht Calico, zum Beispill. Awer ech wëll direkt soen datt d'Aufgab fir d'Netzwierkléisung an engem Kubernetes Aarbechtscluster z'änneren zimlech net trivial ass. Ech hunn et zweemol geléist (béid Mol awer theoretesch), awer mir hu souguer gewisen wéi et bei Slurms gemaach gëtt. Fir eis Studenten hu mir gewisen wéi een d'Netzwierkléisung an engem Kubernetes Cluster verännert. Am Prinzip, kënnt Dir probéieren sécher ze stellen, datt et keng Ausdauer um Produktiounscluster gëtt. Awer Dir wäert wahrscheinlech net erfollegräich sinn.
An de Problem ass eigentlech ganz einfach geléist. Et gi Certificaten am Cluster, an Dir wësst datt Är Certificaten an engem Joer oflafen. Gutt, an normalerweis eng normal Léisung mat Certificaten am Stärekoup - firwat maache mir Suergen, mir wäerte en neie Stärekoup an der Géigend erhéijen, deen alen verrotten loossen an alles ëmsetzen. Richteg, wann et verrotten ass, musse mir en Dag sëtzen, awer hei ass en neie Stärekoup.
Wann Dir en neie Stärekoup eropgeet, gläichzäiteg Calico setzen anstatt Flanell.
Wat maache wann Är Certificaten fir honnert Joer ausgestallt ginn an Dir wäert de Stärekoup net nei ëmsetzen? Et gëtt sou eppes wéi Kube-RBAC-Proxy. Dëst ass eng ganz cool Entwécklung, et erlaabt Iech selwer als Sidecar Container an all Pod am Kubernetes Cluster z'integréieren. An et füügt tatsächlech Autorisatioun un dësem Pod duerch RBAC vu Kubernetes selwer.
Et gëtt ee Problem. Virdru gouf dës Kube-RBAC-Proxy-Léisung an de Prometheus vum Bedreiwer gebaut. Awer dunn war hien fort. Elo vertrauen modern Versiounen op d'Tatsaach datt Dir eng Netzwierkpolitik hutt an se mat hinnen zoumaachen. An dofir musse mer den Diagramm e bëssen ëmschreiwen. Tatsächlech, wann Dir gitt op , Et gi Beispiller wéi een dat als Sidecars benotzt, an d'Charts musse minimal ëmgeschriwwe ginn.
Et gëtt nach ee klenge Problem. De Prometheus ass net deen eenzegen deen seng Metriken u jidderengem ausdeelt. All eis Kubernetes Cluster Komponente kënnen och hir eege Metriken zréckginn.
Awer wéi ech scho gesot hunn, wann Dir net op de Cluster kënnt an Informatioun sammelt, da kënnt Dir op d'mannst e Schued maachen.
Also ech wäert séier zwee Weeër weisen wéi e Kubernetes Cluster ka ruinéiert ginn.
Dir wäert laachen wann ech Iech dat soen, dëst sinn zwee richteg Liewen Fäll.
Method eng. Ressource Ausschöpfung.
Loosst eis en anere spezielle Pod starten. Et wäert eng Sektioun wéi dës hunn.
resources:
requests:
cpu: 4
memory: 4Gi Wéi Dir wësst, ass d'Ufroen d'Quantitéit u CPU an Erënnerung déi am Host reservéiert ass fir spezifesch Pods mat Ufroen. Wa mir e Véier-Kär-Host an engem Kubernetes-Cluster hunn, a véier CPU-Pods do ukommen mat Ufroen, heescht et datt keng Pods méi mat Ufroe bei dësem Host kommen.
Wann ech esou e Pod lafen, da lafen ech de Kommando:
$ kubectl scale special-pod --replicas=...Da kann keen aneren an de Kubernetes Cluster ofsetzen. Well all Wirbelen aus Ufroe lafen. An domat stoppen ech Äre Kubernetes Stärekoup. Wann ech dat owes maachen, kann ech d'Deployementer zimlech laang stoppen.
Wa mir nach eng Kéier op d'Kubernetes Dokumentatioun kucken, wäerte mir dës Saach gesinn Limit Range genannt. Et setzt Ressourcen fir Clusterobjekter. Dir kënnt e Limit Range Objet an yaml schreiwen, et op bestëmmte Nummraim uwenden - an dann an dësem Nummraum kënnt Dir soen datt Dir Standard, Maximum a Minimum Ressourcen fir d'Pods hutt.
Mat der Hëllef vun esou enger Saach kënne mir Benotzer a spezifesche Produktnameraim vun Teams limitéieren an der Fäegkeet all Zorte vu béis Saachen op hire Pods unzeginn. Awer leider, och wann Dir de Benotzer seet datt se Pods net mat Ufroe fir méi wéi eng CPU lancéiere kënnen, gëtt et sou e wonnerbare Skala Kommando, oder se kënne Skala duerch den Dashboard maachen.
An dat ass wou d'Method Nummer zwee hierkënnt. Mir lancéieren 11 Pods. Dat sinn eelef Milliarden. Dat ass net well ech op esou eng Zuel komm sinn, mee well ech se selwer gesinn hunn.
Real Geschicht. Spéit am Owend war ech amgaang de Büro ze verloossen. Ech gesinn eng Grupp vun Entwéckler, déi am Eck sëtzen, frantesch eppes mat hiren Laptops maachen. Ech ginn op d'Jongen a froen: "Wat ass mat dir geschitt?"
E bësse méi fréi, géint néng den Owend, huet ee vun den Entwéckler sech bereet fir heem ze goen. An ech hunn decidéiert: "Ech wäert elo meng Demande op eng erofsetzen." Ech hunn een gedréckt, awer den Internet huet e bësse verlangsamt. Hien huet deen nach eng Kéier gedréckt, hien huet deen gedréckt, an huet op Enter geklickt. Ech hunn op alles gepickt wat ech konnt. Dunn ass den Internet an d'Liewen komm - an alles huet ugefaang op dës Zuel ze reduzéieren.
True, dës Geschicht huet net op Kubernetes stattfonnt; zu där Zäit war et Nomad. Et ass ofgeschloss mat der Tatsaach, datt no enger Stonn vun eise Versuche fir Nomad vu persistent Versuche fir d'Skala ze stoppen, Nomad huet geäntwert datt hien net ophale géif ze skaléieren an näischt anescht géif maachen. "Ech sinn midd, ech ginn fort." An hien huet sech gekrasch.
Natierlech hunn ech probéiert datselwecht op Kubernetes ze maachen. Kubernetes war net zefridden mat eelef Milliarde Pods, hie sot: "Ech kann net. Iwwerschreift intern Mondschutz." Awer 1 Pods kéinten.
Als Äntwert op eng Milliard huet de Cube sech net a sech zréckgezunn. Hien huet wierklech ugefaang ze scaléieren. Wat de Prozess méi wäit gaang ass, dest méi Zäit huet et him gedauert fir nei Pods ze kreéieren. Awer nach ëmmer ass de Prozess weidergaang. Deen eenzege Problem ass datt wann ech Pods onlimitéiert a mengem Nummraum lancéiere kann, da kann ech och ouni Ufroen a Limiten esou vill Pods mat e puer Aufgaben lancéieren, datt mat der Hëllef vun dësen Aufgaben d'Noden ufänken an der Erënnerung opzemaachen, an der CPU. Wann ech sou vill Pods lancéieren, soll d'Informatioun vun hinnen an d'Späichere goen, dat heescht, etc. A wann ze vill Informatioun do ukomm ass, fänkt d'Späichere ze lues zréck - a Kubernetes fänkt un déif ze ginn.
An nach ee Problem ... Wéi Dir wësst, sinn d'Kubernetes Kontrollelementer net eng zentral Saach, mee verschidde Komponenten. Besonnesch gëtt et e Controller Manager, Scheduler, a sou weider. All dës Kärelen fänken un onnéideg, domm Aarbecht gläichzäiteg ze maachen, déi mat der Zäit méi a méi Zäit wäert huelen. De Controller Manager erstellt nei Pods. Scheduler wäert probéieren en neien Node fir si ze fannen. Dir wäert héchstwahrscheinlech aus neie Wirbelen an Ärem Cluster geschwënn lafen. De Kubernetes Stärekoup fänkt méi lues a méi lues ze schaffen.
Mee ech hu beschloss nach méi wäit ze goen. Wéi Dir wësst, gëtt et zu Kubernetes sou eppes wat e Service genannt gëtt. Gutt, Par défaut an Äre Stärekéip, héchstwahrscheinlech, funktionnéiert de Service mat IP Dëscher.
Wann Dir zum Beispill eng Milliard Pods leeft, a benotzt dann e Skript fir Kubernetis ze zwéngen fir nei Servicer ze kreéieren:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done Op all Wirbelen vum Cluster ginn ëmmer méi nei iptables Regelen ongeféier gläichzäiteg generéiert. Ausserdeem ginn eng Milliard iptables Regele fir all Service generéiert.
Ech hunn dës ganz Saach op e puer dausend iwwerpréift, bis zu zéng. An de Problem ass datt schonn op dëser Schwell et zimmlech problematesch ass ssh op den Node ze maachen. Well Päckchen, duerch sou vill Ketten, fänken un net ganz gutt ze fillen.
An dat gëtt och alles mat der Hëllef vu Kubernetes geléist. Et gëtt esou e Ressource Quoteobjekt. Setzt d'Zuel vun verfügbare Ressourcen an Objeten fir den Nummraum am Cluster. Mir kënnen e Yaml Objet an all Nummraum vum Kubernetes Cluster erstellen. Mat dësem Objet kënne mir soen datt mir eng gewëssen Unzuel vun Ufroen a Limiten fir dësen Nummraum zougewisen hunn, an da kënne mir soen datt et an dësem Nummraum méiglech ass 10 Servicer an 10 Pods ze kreéieren. An een eenzegen Entwéckler kann sech op d'mannst owes erstécken. Kubernetes wäert him soen: "Dir kënnt Är Pods net op dee Betrag skaléieren, well d'Ressource d'Quot iwwerschreift." Dat ass et, de Problem geléist. .
Ee problematesche Punkt entsteet an deem Sënn. Dir fillt wéi schwéier et gëtt en Nummraum a Kubernetes ze kreéieren. Fir et ze kreéieren, musse mir vill Saache berücksichtegen.
Ressource Quote + Limit Range + RBAC
• Schafen engem Nummraum
• Schafen eng limitéieren bannen
• Schafen bannen Ressourcequota
• Schafen eng serviceaccount fir CI
• Schafen rolebinding fir CI an Benotzer
• Optional starten déi néideg Service Pods
Dofir wëll ech dës Geleeënheet notzen fir meng Entwécklungen ze deelen. Et gëtt sou eppes genannt SDK Bedreiwer. Dëst ass e Wee fir e Kubernetes Cluster fir Betreiber dofir ze schreiwen. Dir kënnt Aussoe mat Ansible schreiwen.
Am Ufank gouf et an Ansible geschriwwen, an dunn hunn ech gesinn datt et en SDK Bedreiwer gouf an d'Ansible Roll an en Bedreiwer ëmgeschriwwen. Dës Ausso erlaabt Iech en Objet am Kubernetes Cluster ze kreéieren deen e Kommando genannt gëtt. Bannent engem Kommando erlaabt Iech d'Ëmfeld fir dëse Kommando an yaml ze beschreiwen. An am Teamëmfeld erlaabt et eis ze beschreiwen datt mir sou vill Ressourcen allocéieren.
Net vill .
An zum Schluss. Wat maache mat all deem?
Éischten. Pod Sécherheetspolitik ass gutt. An trotz der Tatsaach, datt kee vun de Kubernetes Installateuren se bis haut benotzen, musst Dir se nach ëmmer an Äre Cluster benotzen.
Netzpolitik ass net nëmmen eng aner onnéideg Feature. Dëst ass wat wierklech an engem Cluster gebraucht gëtt.
LimitRange/ResourceQuota - et ass Zäit et ze benotzen. Mir hunn dëst viru laanger Zäit ugefaang ze benotzen, a laang war ech sécher datt jiddereen et benotzt. Et huet sech erausgestallt datt dëst rar ass.
Zousätzlech zu deem wat ech während dem Bericht ernimmt hunn, ginn et ondokumentéiert Features, déi Iech erlaben de Stärekoup ze attackéieren. Verëffentlecht kuerzem .
E puer Saache si sou traureg a verletzend. Zum Beispill, ënner bestëmmte Konditiounen, Cubelets an engem Kubernetes Stärekoup kann den Inhalt vun der warlocks Verzeechnes un en net autoriséiert Benotzer ginn.
Et gi Instruktioune wéi Dir alles reproduzéieren wat ech Iech gesot hunn. Et gi Dateie mat Produktiounsbeispiller vu wéi ResourceQuota a Pod Sécherheetspolitik ausgesinn. An Dir kënnt all dëst beréieren.
Merci un all.
Source: will.com