Pavel Selivanov, Southbridge-oplossingsarsjitekt en Slurm-learaar, joech in presintaasje by DevOpsConf 2019. Dit petear is ûnderdiel fan ien fan 'e ûnderwerpen fan' e yngeande kursus oer Kubernetes "Slurm Mega".
fynt plak yn Moskou op 18-20 novimber.
- Moskou, 22-24 novimber.
altyd beskikber.
Under de besuniging stiet in transkripsje fan it rapport.
Goeiemiddei, kollega's en dyjingen dy't mei har sympatisearje. Hjoed sil ik prate oer feiligens.
Ik sjoch dat der hjoed in protte befeiligers yn de seal sitte. Ik ferûntskuldigje jo foarôf as ik termen út 'e wrâld fan feiligens brûke net krekt sa't it foar jo gewoan is.
It barde sa dat ik sawat seis moanne lyn ien iepenbier Kubernetes-kluster tsjinkaam. Iepenbier betsjut dat der in n-de oantal nammeromten is; yn dizze nammeromten binne d'r brûkers isolearre yn har nammeromte. Al dizze brûkers hearre ta ferskate bedriuwen. No, der waard oannommen dat dit kluster brûkt wurde soe as in CDN. Dat is, se jouwe jo in kluster, se jouwe jo dêr in brûker, jo geane dêr nei jo nammeromte, set jo fronten yn.
Myn eardere bedriuw besocht sa'n tsjinst te ferkeapjen. En ik waard frege om it kluster te pokken om te sjen oft dizze oplossing geskikt wie of net.
Ik kaam by dit kluster. Ik krige beheinde rjochten, beheinde nammeromte. De jonges dêr begrepen wat feiligens wie. Se lêze oer Role-basearre tagongskontrôle (RBAC) yn Kubernetes - en se draaiden it sadat ik gjin pods los koe lansearje fan ynset. Ik wit it probleem net dat ik besocht op te lossen troch in pod te lansearjen sûnder ynset, mar ik woe echt gewoan in pod lansearje. Foar goed gelok haw ik besletten om te sjen hokker rjochten ik haw yn it kluster, wat ik dwaan kin, wat ik net kin en wat se dêr fersnipele hawwe. Tagelyk sil ik jo fertelle wat se yn RBAC ferkeard ynsteld hawwe.
It barde sa dat ik yn twa minuten in admin krige yn har kluster, seach nei alle oanbuorjende nammeromten, seach dêr de rinnende produksjefronten fan bedriuwen dy't de tsjinst al kocht en ynset hiene. Ik koe mysels amper ophâlde om nei immen syn front te gean en wat skelwurd op 'e haadside te setten.
Ik sil jo mei foarbylden fertelle hoe't ik dit dien haw en hoe't jo josels hjirmei kinne beskermje.
Mar earst lit ik mysels foarstelle. Myn namme is Pavel Selivanov. Ik bin arsjitekt by Southbridge. Ik begryp Kubernetes, DevOps en allerhanne fancy dingen. De yngenieurs fan Southbridge en ik bouwe dit alles, en ik bin rieplachtsjen.
Neist ús haadaktiviteiten hawwe wy koartlyn projekten lansearre mei de namme Slurms. Wy besykje ús fermogen om mei Kubernetes te wurkjen in bytsje nei de massa te bringen, om oare minsken te learen om ek mei K8's te wurkjen.
Wêr sil ik hjoed oer prate? It ûnderwerp fan it rapport is fanselssprekkend - oer de feiligens fan it Kubernetes-kluster. Mar ik wol daliks sizze dat dit ûnderwerp tige grut is - en dêrom wol ik daliks dúdlik meitsje wêr't ik perfoarst net oer prate sil. Ik sil it net hawwe oer ôfbrutsen termen dy't al hûndert kear op it ynternet binne brûkt. Alle soarten fan RBAC en sertifikaten.
Ik sil prate oer wat my en myn kollega's pynlik meitsje oer feiligens yn in Kubernetes-kluster. Wy sjogge dizze problemen sawol by oanbieders dy't Kubernetes-klusters leverje as ûnder kliïnten dy't nei ús komme. En sels fan kliïnten dy't by ús komme fan oare konsultaasjebedriuwen. Dat is, de skaal fan 'e trageedzje is eins tige grut.
D'r binne letterlik trije punten dêr't ik hjoed oer sil prate:
- Brûkersrjochten vs podrjochten. Brûkersrjochten en podrjochten binne net itselde ding.
- It sammeljen fan ynformaasje oer it kluster. Ik sil sjen litte dat jo alle ynformaasje kinne sammelje dy't jo nedich binne fan in kluster sûnder spesjale rjochten yn dit kluster te hawwen.
- DoS oanfal op it kluster. As wy gjin ynformaasje sammelje kinne, kinne wy yn alle gefallen in kluster pleatse. Ik sil prate oer DoS-oanfallen op klusterkontrôle-eleminten.
In oar algemien ding dat ik sil neame is wêrop ik dit alles hifke, wêrop ik perfoarst kin sizze dat it allegear wurket.
Wy nimme as basis de ynstallaasje fan in Kubernetes-kluster mei Kubespray. As immen it net wit, is dit eins in set rollen foar Ansible. Wy brûke it konstant yn ús wurk. It goede ding is dat jo it oeral kinne rôlje - jo kinne it rôlje op stikken izer of earne yn in wolk. Ien ynstallaasjemetoade wurket yn prinsipe foar alles.
Yn dit kluster sil ik Kubernetes v1.14.5 hawwe. It hiele Cube-kluster, dat wy sille beskôgje, is ferdield yn nammeromten, elke nammeromte heart ta in apart team, en leden fan dit team hawwe tagong ta elke nammeromte. Se kinne net nei ferskate nammeromten gean, allinich nei har eigen. Mar d'r is in bepaald admin-akkount dat rjochten hat foar it heule kluster.
Ik haw tasein dat it earste ding dat wy sille dwaan is adminrjochten te krijen foar it kluster. Wy hawwe in spesjaal taret pod nedich dy't it Kubernetes-kluster sil brekke. Alles wat wy hoege te dwaan is it tapasse op it Kubernetes-kluster.
kubectl apply -f pod.yamlDizze pod sil oankomme by ien fan 'e masters fan' e Kubernetes-kluster. En nei dit sil it kluster lokkich in bestân nei ús weromjaan mei de namme admin.conf. Yn Cube bewarret dit bestân alle administratorsertifikaten, en konfigurearret tagelyk de kluster API. Dit is hoe maklik it is om admin tagong te krijen ta, tink ik, 98% fan Kubernetes-klusters.
Ik werhelje, dizze pod is makke troch ien ûntwikkelder yn jo kluster dy't tagong hat om syn foarstellen yn ien lytse nammeromte yn te setten, it wurdt allegear beklamme troch RBAC. Hy hie gjin rjochten. Mar dochs waard it sertifikaat weromjûn.
En no oer in spesjaal klearmakke pod. Wy rinne it op elke ôfbylding. Litte wy debian:jessie as foarbyld nimme.
Wy hawwe dit ding:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Wat is tolerânsje? Masters yn in Kubernetes-kluster wurde meastentiids markearre mei wat neamd taint. En de essinsje fan dizze "ynfeksje" is dat it seit dat pods net kinne wurde tawiisd oan masterknooppunten. Mar gjinien makket it lestich om yn elke pod oan te jaan dat it tolerant is foar de "ynfeksje". De seksje Toleraasje seit gewoan dat as ien knooppunt NoSchedule hat, dan is ús knooppunt tolerant foar sa'n ynfeksje - en d'r binne gjin problemen.
Fierder sizze wy dat ús ûnder net allinnich tolerant is, mar ek de master spesifyk rjochtsje wol. Om't de masters it lekkerste hawwe dat wy nedich binne - alle sertifikaten. Dat is wêrom wy sizze nodeSelector - en wy hawwe in standert label op masters, dat kinne jo selektearje út alle knopen yn it kluster krekt dy knopen dy't masters.
Mei dizze twa seksjes komt er grif by de master. En dêr sil er wenje meie.
Mar allinne by de master komme is ús net genôch. Dit sil ús neat jaan. Dus neist hawwe wy dizze twa dingen:
hostNetwork: true
hostPID: true Wy spesifisearje dat ús pod, dy't wy lansearje, sil libje yn 'e kernel-nammeromte, yn' e netwurknammeromte, en yn 'e PID-nammeromte. As de pod ienris op 'e master is lansearre, sil it alle echte, live ynterfaces fan dizze knooppunt kinne sjen, nei alle ferkear harkje en de PID fan alle prosessen sjen.
Dan giet it om lytse dingen. Nim etcd en lês wat jo wolle.
It meast nijsgjirrige ding is dizze Kubernetes-funksje, dy't dêr standert oanwêzich is.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host En syn essinsje is dat wy yn 'e pod kinne sizze dat wy lansearje, sels sûnder rjochten foar dit kluster, dat wy in folume fan type hostPath wolle oanmeitsje. Dit betsjut dat jo it paad nimme fan 'e host wêrop wy sille lansearje - en it as folume nimme. En dan neame wy it namme: host. Wy montearje dit heule hostPath yn 'e pod. Yn dit foarbyld, nei de /host-map.
Ik sil it nochris werhelje. Wy fertelden de pod om nei de master te kommen, it hostNetwork en hostPID dêr te heljen - en de hiele root fan 'e master yn dizze pod montearje.
Jo begripe dat wy yn Debian bash rinne, en dizze bash rint ûnder root. Dat is, wy hawwe krekt root krigen op 'e master, sûnder rjochten te hawwen yn' e Kubernetes-kluster.
Dan is de hiele taak om te gean nei de submap /host /etc/kubernetes/pki, as ik my net fersin, helje dêr alle mastersertifikaten fan it kluster op en wurde dêrmei de klusterbehearder.
As jo it op dizze manier sjogge, binne dit guon fan 'e gefaarlikste rjochten yn pods - nettsjinsteande hokker rjochten de brûker hat:
As ik de rjochten haw om in pod út te fieren yn guon nammeromte fan it kluster, dan hat dizze pod dizze rjochten standert. Ik kin rinne befoarrjochte pods, en dit binne oer it algemien alle rjochten, praktysk woartel op it knooppunt.
Myn favoryt is Root-brûker. En Kubernetes hat dizze opsje Run As Non-Root. Dit is in soarte fan beskerming tsjin in hacker. Witte jo wat it "Moldavyske firus" is? As jo ynienen in hacker binne en nei myn Kubernetes-kluster komme, dan freegje wy, earme behearders,: "Jou asjebleaft yn jo pods oan wêrmei jo myn kluster hackje sille, rinne as net-root. Oars sil it barre dat jo it proses yn jo pod ûnder root útfiere, en it sil heul maklik wêze foar jo om my te hacken. Beskermje dysels asjebleaft tsjin dysels."
Hostpaadvolume is, nei myn miening, de rapste manier om it winske resultaat te krijen fan in Kubernetes-kluster.
Mar wat te dwaan mei dit alles?
De gedachte dy't by elke normale behearder komme moat dy't Kubernetes tsjinkomt is: "Ja, ik sei dy, Kubernetes wurket net. Der sitte gatten yn. En de hiele kubus is rommel." Eins is d'r sa'n ding as dokumintaasje, en as jo dêr sjogge, is d'r in seksje .
Dit is in yaml-objekt - wy kinne it oanmeitsje yn it Kubernetes-kluster - dat befeiligingsaspekten spesifyk kontrolearret yn 'e beskriuwing fan' e pods. Dat is, yn feite, it kontrolearret de rjochten om elk hostNetwork, hostPID, bepaalde folumetypen te brûken dy't yn 'e pods binne by it opstarten. Mei help fan Pod Security Policy kin dit alles beskreaun wurde.
It meast nijsgjirrige ding oer it Pod-befeiligingsbelied is dat yn it Kubernetes-kluster alle PSP-ynstallearders net allinich op ien of oare manier beskreaun wurde, se binne standert gewoan útskeakele. Pod Feiligensbelied is ynskeakele mei it admission plugin.
Okee, lit ús Pod Feiligensbelied ynsette yn it kluster, lit ús sizze dat wy wat tsjinstpods hawwe yn 'e nammeromte, wêr't allinich admins tagong hawwe. Litte wy sizze, yn alle oare gefallen hawwe pods beheinde rjochten. Om't wierskynlik ûntwikkelders gjin befoarrjochte pods yn jo kluster hoege út te fieren.
En alles liket goed mei ús. En ús Kubernetes-kluster kin net yn twa minuten hacked wurde.
Dêr is in probleem. Meast wierskynlik, as jo in Kubernetes-kluster hawwe, dan wurdt tafersjoch ynstalleare op jo kluster. Ik soe sels sa fier gean om te foarsizzen dat as jo kluster tafersjoch hat, it Prometheus hjitte.
Wat ik jo sil fertelle sil jildich wêze foar sawol de Prometheus-operator as Prometheus levere yn syn suvere foarm. De fraach is dat as ik net sa gau in admin yn it kluster krije kin, dan betsjut dit dat ik mear sykje moat. En ik kin sykje mei help fan jo tafersjoch.
Wierskynlik lêze elkenien deselde artikels oer Habré, en de monitoaring leit yn 'e monitoaring nammeromte. Helm chart wurdt foar elkenien sawat itselde neamd. Ik tink dat as jo helm ynstallearje stable / prometheus, jo sille einigje mei likernôch deselde nammen. En nei alle gedachten sil ik de DNS-namme yn jo kluster net iens hoege te rieden. Want it is standert.
Dêrnei hawwe wy in bepaalde dev ns, wêryn jo in bepaalde pod útfiere kinne. En dan fan dizze pod is it heul maklik om sa'n ding te dwaan:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics is ien fan 'e Prometheus eksporteurs dy't metriken sammelet fan 'e Kubernetes API sels. Der binne in soad gegevens dêr, wat rint yn jo kluster, wat it is, hokker problemen jo hawwe mei it.
As in ienfâldich foarbyld:
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
Troch in ienfâldich krulfersyk te meitsjen fan in unprivileged pod, kinne jo de folgjende ynformaasje krije. As jo net witte hokker ferzje fan Kubernetes jo rinne, sil it jo maklik fertelle.
En it meast nijsgjirrige is dat jo neist tagong ta kube-state-metriken kinne jo krekt sa maklik tagong krije ta Prometheus sels direkt. Jo kinne dêr metriken sammelje. Jo kinne dêr sels metriken bouwe. Sels teoretysk kinne jo sa'n query bouwe fan in kluster yn Prometheus, dy't it gewoan útsette sil. En jo tafersjoch sil hielendal ophâlde te wurkjen fanút it kluster.
En hjir komt de fraach op oft in eksterne tafersjoch jo tafersjoch kontrolearret. Ik krige krekt de kâns om te operearjen yn in Kubernetes-kluster sûnder gefolgen foar mysels. Jo sille net iens witte dat ik dêr operearje, om't d'r gjin tafersjoch mear is.
Krekt as by de PSP, fielt it as it probleem is dat al dizze fancy technologyen - Kubernetes, Prometheus - se gewoan net wurkje en fol binne mei gatten. Net wirklik.
Der is sa'n ding - .
As jo in normale admin binne, dan wite jo wierskynlik oer Netwurkbelied dat dit gewoan in oare yaml is, wêrfan d'r al in protte binne yn it kluster. En guon netwurkbelied binne perfoarst net nedich. En sels as jo lêze wat Netwurkbelied is, dat it in yaml-firewall fan Kubernetes is, it lit jo tagongsrjochten beheine tusken nammeromten, tusken pods, dan hawwe jo wis besletten dat de firewall yn yaml-formaat yn Kubernetes basearre is op 'e folgjende abstraksjes ... Nee, nee. Dit is perfoarst net nedich.
Sels as jo jo feiligensspesjalisten net hawwe ferteld dat jo jo Kubernetes brûke kinne jo in heul maklike en ienfâldige firewall bouwe, en in heul korrelige ien dêrby. As se dit noch net witte en jo net hinderje: "Nou, jou my, jou my..." Dan hawwe jo yn alle gefallen Netwurkbelied nedich om tagong te blokkearjen ta guon tsjinstplakken dy't út jo kluster helle wurde kinne sûnder autorisaasje.
Lykas yn it foarbyld dat ik joech, kinne jo kube-state-metriken ophelje fan elke nammeromte yn it Kubernetes-kluster sûnder dat jo rjochten hawwe om dat te dwaan. Netwurkbelied hat tagong fan alle oare nammeromten sletten ta de tafersjochnammeromte en dat is it: gjin tagong, gjin problemen. Yn alle charts dy't besteane, sawol de standert Prometheus as de Prometheus dy't yn 'e operator is, is d'r gewoan in opsje yn' e helmwearden om gewoan netwurkbelied foar har yn te skeakeljen. Jo moatte it gewoan ynskeakelje en se sille wurkje.
D'r is hjir echt ien probleem. As in normale bearded admin binne jo wierskynlik besletten dat netwurkbelied net nedich is. En nei it lêzen fan allerhanne artikels oer boarnen lykas Habr, hawwe jo besletten dat flanel, foaral mei host-gateway-modus, it bêste is dat jo kinne kieze.
Wat moat ik dwaan?
Jo kinne besykje de netwurkoplossing dy't jo hawwe yn jo Kubernetes-kluster opnij yn te setten, besykje it te ferfangen mei wat funksjoneeler. Foar deselde Calico, bygelyks. Mar ik wol fuortdaliks sizze dat de taak om de netwurkoplossing te feroarjen yn in Kubernetes-wurkkluster frijwat net-trivial is. Ik haw it twa kear oplost (beide kearen lykwols teoretysk), mar wy lieten sels sjen hoe't jo it dwaan by Slurms. Foar ús studinten lieten wy sjen hoe't jo de netwurkoplossing kinne feroarje yn in Kubernetes-kluster. Yn prinsipe kinne jo besykje om te soargjen dat der gjin downtime op de produksje kluster. Mar jo sille wierskynlik net slagje.
En it probleem is eins hiel ienfâldich oplost. D'r binne sertifikaten yn it kluster, en jo witte dat jo sertifikaten oer in jier ferrinne. No, en meastal in normale oplossing mei sertifikaten yn it kluster - wêrom meitsje wy ús soargen, wy sille in nij kluster yn 'e buert ophelje, de âlde rot litte litte en alles opnij ynsette. Wier, as it rot wurdt, moatte wy in dei sitte, mar hjir is in nij kluster.
As jo in nij kluster ophelje, ynfoegje tagelyk Calico ynstee fan flanel.
Wat te dwaan as jo sertifikaten foar hûndert jier wurde útjûn en jo sille it kluster net opnij ynsette? D'r is sa'n ding as Kube-RBAC-Proxy. Dit is in heul coole ûntwikkeling, it lit jo harsels as sidecar-kontener ynbêde yn elke pod yn it Kubernetes-kluster. En it foeget eins autorisaasje ta oan dizze pod fia RBAC fan Kubernetes sels.
Der is ien probleem. Earder waard dizze Kube-RBAC-Proxy-oplossing ynboud yn 'e Prometheus fan' e operator. Mar doe wie er fuort. No fertrouwe moderne ferzjes op it feit dat jo in netwurkbelied hawwe en it slute mei har. En dêrom sille wy it diagram in bytsje oerskriuwe moatte. Yn feite, as jo gean nei , D'r binne foarbylden fan hoe't jo dit brûke as sidecars, en de charts moatte minimaal opnij skreaun wurde.
Der is noch ien lyts probleem. Prometheus is net de iennichste dy't syn metriken útrikt oan gewoan elkenien. Al ús Kubernetes-klusterkomponinten binne ek yn steat om har eigen metriken werom te jaan.
Mar lykas ik al sei, as jo gjin tagong krije ta it kluster en ynformaasje sammelje, dan kinne jo op syn minst wat skea dwaan.
Dat ik sil gau twa manieren sjen litte hoe't in Kubernetes-kluster kin wurde ferneatige.
Jo sille laitsje as ik jo dit sis, dit binne twa echte libbensgefallen.
Metoade ien. Resource útputting.
Litte wy in oare spesjale pod lansearje. It sil in seksje lykas dizze hawwe.
resources:
requests:
cpu: 4
memory: 4Gi Lykas jo witte, is fersiken it bedrach fan CPU en ûnthâld dat reservearre is op 'e host foar spesifike pods mei oanfragen. As wy in fjouwer-kearn-host hawwe yn in Kubernetes-kluster, en fjouwer CPU-pods komme dêr mei oanfragen, betsjut dit dat gjin pods mei fersiken mear nei dizze host kinne komme.
As ik sa'n pod útfiere, dan sil ik it kommando útfiere:
$ kubectl scale special-pod --replicas=...Dan sil gjinien oars kinne ynsette op it Kubernetes-kluster. Omdat alle knooppunten sille rinne út fersiken. En sa sil ik jo Kubernetes-kluster stopje. As ik dit jûns doch, kin ik de ynset wol hiel lang stilhâlde.
As wy nochris nei de Kubernetes-dokumintaasje sjogge, sille wy dit ding sjen neamd Limit Range. It stelt boarnen yn foar klusterobjekten. Jo kinne in Limit Range-objekt yn yaml skriuwe, it tapasse op bepaalde nammeromten - en dan kinne jo yn dizze nammeromte sizze dat jo standert, maksimum en minimum boarnen hawwe foar de pods.
Mei help fan sa'n ding kinne wy brûkers yn spesifike produktnammeromten fan teams beheine yn 'e mooglikheid om allerhanne ferfelende dingen op har pods oan te jaan. Mar spitigernôch, sels as jo de brûker fertelle dat se pods net kinne starte mei oanfragen foar mear dan ien CPU, is d'r sa'n prachtich skaalkommando, of se kinne skaal dwaan fia it dashboard.
En dit is wêr't metoade nûmer twa komt. Wy lansearje 11 pods. Dat is alve miljard. Dit is net om't ik mei sa'n nûmer kaam, mar om't ik it sels seach.
Echt ferhaal. Jûns let stie ik op it punt om it kantoar te ferlitten. Ik sjoch in groep ûntwikkelders yn 'e hoeke sitten, dwaas wat dwaan mei har laptops. Ik gean nei de jonges en freegje: "Wat is der mei dy bard?"
Efkes earder, jûns om njoggenen hinne, makke ien fan de ûntwikkelders har klear om nei hûs te gean. En ik besleat: "Ik sil myn oanfraach no skaalje nei ien." Ik drukte op ien, mar it ynternet fertrage in bytsje. Hy drukte de iene nochris, hy drukte de iene, en klikte op Enter. Ik pokte op alles wat ik koe. Doe kaam it ynternet ta libben - en alles begon te skaaljen nei dit nûmer.
Wier, dit ferhaal fûn net plak op Kubernetes; op dat stuit wie it Nomad. It einige mei it feit dat nei in oere fan ús besykjen om Nomad te stopjen fan oanhâldende besykjen om te skaaljen, antwurde Nomad dat hy net ophâlde soe mei skaalfergrutting en soe neat oars dwaan. "Ik bin wurch, ik gean fuort." En hy krûlde op.
Natuerlik besocht ik itselde te dwaan op Kubernetes. Kubernetes wie net bliid mei alve miljard pods, hy sei: "Ik kin net. Overtreft ynterne mûlebeskermings." Mar 1 pods koenen.
As antwurd op ien miljard, luts de Kubus net yn himsels werom. Hy begon echt te skaaljen. Hoe fierder it proses gie, hoe mear tiid it him koste om nije podden te meitsjen. Mar dochs gie it proses troch. It ienige probleem is dat as ik pods ûnbeheind kin lansearje yn myn nammeromte, dan kin ik sels sûnder oanfragen en limiten safolle pods mei guon taken lansearje dat mei help fan dizze taken de knopen sille begjinne te foegjen yn it ûnthâld, yn CPU. As ik safolle pods lansearje, moat de ynformaasje fan har yn opslach gean, dat is, ensfh. En as der tefolle ynformaasje komt, begjint de opslach te stadich werom te kommen - en Kubernetes begjint dof te wurden.
En noch ien probleem ... As jo witte, binne de Kubernetes-kontrôle-eleminten net ien sintraal ding, mar ferskate komponinten. Benammen is d'r in controller manager, scheduler, ensfh. Al dizze jonges sille tagelyk begjinne te dwaan ûnnedich, dom wurk, dat mei de tiid sil begjinne te nimmen mear en mear tiid. De controllerbehearder sil nije pods oanmeitsje. Scheduler sil besykje in nij knooppunt foar har te finen. Jo sille nei alle gedachten gau gjin nije knopen yn jo kluster rinne. It Kubernetes-kluster sil stadiger en stadiger begjinne te wurkjen.
Mar ik besleat noch fierder te gean. Sa't jo witte, yn Kubernetes is d'r sa'n ding neamd in tsjinst. No, standert yn jo klusters, wierskynlik wurket de tsjinst mei IP-tabellen.
As jo bygelyks ien miljard pods útfiere en dan in skript brûke om Kubernetis te twingen om nije tsjinsten te meitsjen:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done Op alle knopen fan it kluster sille mear en mear nije iptables-regels sawat tagelyk generearre wurde. Boppedat sille ien miljard iptables-regels wurde generearre foar elke tsjinst.
Ik kontrolearre dit hiele ding op ferskate tûzen, oant tsien. En it probleem is dat it al op dizze drompel frijwat problematysk is om ssh oan 'e knoop te dwaan. Om't pakketten, dy't troch safolle keatlingen geane, begjinne net heul goed te fielen.
En dit is ek allegear oplost mei help fan Kubernetes. Der is sa'n Resource kwota foarwerp. Stelt it oantal beskikbere boarnen en objekten yn foar de nammeromte yn it kluster. Wy kinne in yaml-objekt oanmeitsje yn elke nammeromte fan it Kubernetes-kluster. Mei dit objekt kinne wy sizze dat wy in bepaald oantal oanfragen en limiten hawwe tawiisd foar dizze nammeromte, en dan kinne wy sizze dat yn dizze nammeromte it mooglik is om 10 tsjinsten en 10 pods te meitsjen. En ien ûntwikkelder kin op syn minst jûns choke himsels. Kubernetes sil him fertelle: "Jo kinne jo pods net op dat bedrach skaalje, om't de boarne it kwota grutter is." Dat is it, probleem oplost. .
Ien problematysk punt ûntstiet yn dit ferbân. Jo fiele hoe lestich it wurdt om in nammeromte yn Kubernetes te meitsjen. Om it te meitsjen, moatte wy in protte dingen rekken hâlde.
Boarne kwota + Limit Range + RBAC
• Meitsje in nammeromte
• Meitsje in limytrange binnen
• Meitsje binnen resourcequota
• Meitsje in serviceaccount foar CI
• Meitsje rolebinding foar CI en brûkers
• Opsjoneel starte de nedige tsjinst pods
Dêrom wol ik dizze kâns graach brûke om myn ûntjouwings te dielen. D'r is sa'n ding neamd de SDK-operator. Dit is in manier foar in Kubernetes-kluster om der operators foar te skriuwen. Jo kinne útspraken skriuwe mei Ansible.
Earst waard it skreaun yn Ansible, en doe seach ik dat der in SDK-operator wie en skreau de Ansible-rol yn in operator. Dizze ferklearring lit jo in objekt meitsje yn it Kubernetes-kluster neamd in kommando. Binnen in kommando kinne jo de omjouwing foar dit kommando yn yaml beskriuwe. En binnen de teamomjouwing lit it ús beskriuwe dat wy safolle boarnen tawize.
Little .
En ta konklúzje. Wat te dwaan mei dit alles?
Earste. Pod Feiligensbelied is goed. En nettsjinsteande it feit dat gjin fan 'e Kubernetes-ynstallateurs se oant hjoed de dei brûke, moatte jo se noch brûke yn jo klusters.
Netwurkbelied is net allinich in oare ûnnedige funksje. Dit is wat echt nedich is yn in kluster.
LimitRange/ResourceQuota - it is tiid om it te brûken. Wy begûnen te brûken dit in lange tiid lyn, en foar in lange tiid wie ik wis op dat elkenien brûkte it. It die bliken dat dit seldsum is.
Neist wat ik neamde tidens it rapport, binne d'r net dokuminteare funksjes wêrmei jo it kluster kinne oanfalle. Utjûn koartlyn .
Guon dingen binne sa tryst en kwetsend. Bygelyks, ûnder bepaalde betingsten kinne kubelets yn in Kubernetes-kluster de ynhâld fan 'e warlocks-map jaan oan in net autorisearre brûker.
D'r binne ynstruksjes oer hoe't jo alles kinne reprodusearje wat ik jo fertelde. D'r binne bestannen mei produksjefoarbylden fan hoe ResourceQuota en Pod Security Policy der útsjen. En jo kinne dit alles oanreitsje.
Tank oan allegearre.
Boarne: www.habr.com