Nosaukumu telpas un cgroups operētājsistēmā Linux: konteineru patiesais pamats

Informatec Digital » Resursi » Nosaukumu telpas un cgroups operētājsistēmā Linux: konteineru patiesais pamats

Ja strādājat ar Docker, Kubernetes vai jebkuru citu konteineru platformu, agrāk vai vēlāk jums būs jāiedziļinās sistēmas iekšējā darbībā. Aiz konteineru palaišanas "maģijas" dažu sekunžu laikā slēpjas divi galvenie Linux kodola komponenti: vārdtelpas un cgroups, kas ir atbildīgs par izolāciju un precīzi noregulētu resursu pārvaldību . To izpratne rada lielu atšķirību starp vienkāršu rīku izmantošanu un infrastruktūras izstrādi.

Šajā rakstā mēs mierīgi, bet neiedziļinoties detaļās, aplūkosim, kā tie darbojas. vārdtelpas (ko process var redzēt) un cgroups (ko process var izmantot)Kā Docker un Kubernetes tos izmanto; kā jūs varat tos pielāgot zemā līmenī, izmantojot tādas komandas kā unshare, ip netns vai rakstot tieši /sys/fs/cgroupUn kādi triki ir noderīgi veiktspējas, drošības un problēmu novēršanas uzlabošanai ražošanas vidē.

Ko konteiners īsti dara Linux sistēmā?

Kad jūs palaižat kaut ko līdzīgu docker runnetiek izveidota maģiska virtuālā mašīna; Jūs iegūstat Linux procesu (vai procesu grupu) ar spēcīgu izolāciju un ierobežotiem resursiem."Triks" ir balstīts uz četriem kodola mehānismiem:

• nosaukumvietasTie kontrolē, ko process redz (PID, tīklu, failu sistēmu, resursdatora nosaukumu utt.).
• CgrupasTie kontrolē, cik daudz procesa var izmantot (CPU, RAM, I/O, PID…).
• Chroot/rootfs izolēts: tie piešķir procesam savu failu sistēmu.
• Parastie Linux procesiGalu galā viss ir atkarīgs no kodola pārvaldītajiem resursdatora PID.

Citiem vārdiem sakot, konteiners ir vienkārši process, kas darbojas ar jaunu vārdtelpu kopu, kas ligzdota vienā vai vairākās cgroups grupās, un ar pielāgotu failu sistēmu . Pārējo apstrādā rīks (Docker, containerd, runc utt.) ar automatizāciju un lietotājam draudzīgām API.

Linux nosaukumtelpas: katra procesa redzamā satura izolēšana

Nosaukumtelpas ir kodola abstrakcijas slānis, kas izveido atsevišķas "pasaules" procesu grupām . Process redz tikai savā nosaukumtelpā esošos resursus; pārējā sistēma joprojām pastāv, bet tai neredzama.

Pašlaik Linux ir vairāki vārdtelpu veidi, katrs no tiem ir vērsts uz noteiktu sistēmas daļu. Apvienojumā tie ļauj konteineru uztvert kā neatkarīgu operētājsistēmu, pat ja tas koplieto kodolu ar resursdatoru.

Galvenie vārdtelpu veidi

Katrs vārdtelpas veids izolē atšķirīgu dimensiju. "Nopietnā" konteinerā ir ierasta prakse vienlaikus izmantot vairākas no tām. Šīs ir vissvarīgākās:

• PID nosaukumtelpa: izolē procesa identifikatora telpu. Konteinera ietvaros galvenais process parasti ir PID 1.pat ja resursdatoram ir atšķirīgs numurs. Procesiem no dažādām vārdtelpām var būt viens un tas pats PID, netraucējot viens otram, un tie nevar sūtīt signālus viens otram, ja vien resursdators to nav skaidri atļāvis.
• Tīkla (NET) nosaukumtelpa: izveido neatkarīgu tīkla steku ar savām saskarnēm, maršrutiem, ugunsmūra noteikumiem, ligzdām utt. Katram konteineram ir sava cilpa, savas IP adreses un sava maršrutēšana.Tādā veidā jūs varat atkārtoti izmantot vienu un to pašu IP adresi dažādās vārdtelpās bez konflikta un piemērot izolētus iptables noteikumus.
• Montāžas (MNT) nosaukumtelpa: atdala skatu no stiprinājuma punktiem. Procesi redz tikai savas vārdtelpas failu hierarhijuPat ja zem tiem ir saistīšanas pieslēgumi, koplietoti sējumi, pārklājumi utt. Tas ļauj konteineram šķist, ka tam ir savs "/", nepieskaroties resursdatora faktiskajai saknei.
• UTS nosaukumtelpa: kontrolē resursdatora nosaukumu un NIS domēnu. UTS vārdtelpas ietvaros Jūs varat mainīt resursdatora nosaukumu, neietekmējot resursdatora sistēmu.Ļoti noderīgi konteineru atšķiršanai vai mezglu simulēšanai testa vidēs.
• IPC nosaukumtelpa: izolē System V ziņojumu rindas, semaforus un koplietojamo atmiņu. Novērst dažādu konteineru procesu traucējumus IPC darbībā negadījuma vai sliktas konstrukcijas dēļ.
• Lietotāja nosaukumvietaDroši vien visdelikātākā. Tā ļauj Iekšējo vārdtelpu UID un GID kartēšana ar citu resursdatora IDTas ļauj konteinera "sakni" piesaistīt neprivileģētam lietotājam resursdatorā, ievērojami samazinot privilēģiju eskalācijas risku un uzlabojot konteineru drošība.
• C grupas nosaukumtelpa: nodrošina virtualizētu skatu uz /proc/self/cgroup un cgrupu hierarhija. No konteinera iekšpuses ir redzamas tikai tā paša grupas.Tas slēpj saimnieka faktisko struktūru un pastiprina izolāciju.
• Laika nosaukumtelpa: ļauj piedāvāt dažādas laika uztveres (pulksteņi, piemēram, CLOCK_MONOTONIC vai CLOCK_BOOTTIME) dažādām procesu grupām. Tas ir noderīgi testēšanas scenārijiem vai ļoti smalkai izolācijai.

Visas šīs vārdtelpas ir pieejamas /proc/<pid>/ns/un to var izveidot vai kombinēt ar tādiem rīkiem kā unshare y nsenterKad pēdējais process, kas pieder vārdtelpai, nomirst, šī vārdtelpa tiek automātiski iznīcināta.

Eksperimentēšana ar vārdtelpām no komandrindas

Komanda unshare Tas ir viens no eksperimentēšanas pamatprincipiem: izveido bērnprocesu ar vienu vai vairākām jaunām vārdtelpāmPiemēram, lai pārbaudītu izolētu PID nosaukumvietu:

unshare --pid --fork --mount-proc bash
ps aux
echo $$

Iekšpusē jūs redzēsiet tikai procesus no šīs vārdtelpas, un jūsu čaula tur tiks parādīta kā PID 1, lai gan resursdatoram joprojām būs visi tā ierastie procesi. Tas būtībā ir OCI izpildlaika darbību skelets, kad tiek startēts konteiners.

Tīkla nosaukumtelpas detalizēti

Tīklošanas aspekts ir viens no daudzpusīgākajiem. Veidojot NET vārdtelpu ar ip netns addIegūsiet tukšu steku, izņemot atgriezeniskās saites steku. No turienes varēsiet:

• Savienojiet šo vārdtelpu ar resursdatoru ar pāri veth (divas virtuālas saskarnes, kas savienotas ar loģisku kabeli).
• Izveidojiet tiltus tips br0 un savienot vairākas vārdtelpas ar šo tiltu, lai tās varētu redzēt viena otru, izmantojot privātas IP adreses.
• NAT un pārsūtīšana lai nodrošinātu piekļuvi internetam šiem "pašdarinātajiem konteineriem" ar iptables un /proc/sys/net/ipv4/ip_forward.

Tieši tā, ļoti zemā līmenī, tieši to Docker dara ar tiltu. docker0 un to noklusējuma tīkli: Tas iestata tīkla nosaukumtelpas, veterānu līdziniekus, tiltus un NAT noteikumus. lai konteineri varētu savā starpā sarunāties un iziet ārā.

Pievienojamās un lietotāju nosaukumtelpas rootfs un drošībai

Ar `mount namespace` varat eksperimentēt ar konteinera failu sistēmas izveidi, neizmantojot Docker. Tipisks modelis ir šāds:

• Lai saliktu vai sagatavotu minimālais rootfs (piemēram, Alpine minirootfs, ko lejupielādējis wget un izvilkts direktorijā).
• Izveidojiet piestiprināšanas vārdtelpu un dariet to pivot_root o chroot uz to direktoriju.
• Salieciet /proc, /sys un citas pseidosistēmu sistēmas jaunajā saknē.

Ar to jūsu čaula redzēs tikai šo failu sistēmu, bet Jūs joprojām esat parasts resursdatora process ar savu īsto PID un administratora kontrolējams.Ja izmantojat arī lietotājvārdtelpu ar --map-root-userJums var būt iekšēja "sakne", kas atrodas ārpus lietotāja bez privilēģijām.

Cgroups: cik daudz resursu katrs process var patērēt

Lai gan vārdtelpas nosaka, ko process var redzēt, cgroups ierobežo, cik daudz sistēmas resursu procesu grupa var patērēt . Tās tika ieviestas kodola 2.6.24 versijā un tagad ir būtiskas jebkurā mūsdienu konteineru platformā.

Konceptuālā līmenī c grupa ir direktorijā /sys/fs/cgroup ar failiem, kuros aprakstīti ierobežojumi, prioritātes un metrikasPievienojot PID atbilstošajam failam (piemēram, cgroup.procs), uz šo procesu attiecas šie noteikumi.

Resursu kontrolieri grupās cgroups

C grupas sastāv no kontrolieriem (apakšsistēmām), kas iedarbojas uz konkrētiem resursiem. Visbiežāk izmantotās ir:

• CPU: kontrolē piešķirto centrālā procesora laiku. Ar akcijas definē relatīvo prioritāti; ar kvotas stingri ierobežojumi (piemēram, 50 ms centrālā procesora taimauts uz 100 ms periodu); ar CPU komplekti Jūs piesaistāt procesus konkrētiem kodoliem.
• atmiņa: ierobežo RAM un mijmaiņas apjomu. Ļauj Stingri un viegli ierobežojumi, OOM killer iestatījumi, statistika un atmiņas spiediensĻoti noderīgi, lai novērstu pakalpojuma patērēšanu visā serverī.
• Bloķēt I/O (blkio / io): ierobežo joslas platumu un IOPS katrai ierīcei. Jūs varat piešķirt proporcionālu svaru vai iestatīt precīzus ierobežojumus baitos/s ops/s.
• tīklsPastāv mehānismi joslas platuma un pakešu ierobežošanai, lai gan atbalsts ir mazāk nobriedis un parasti tiek apvienots ar tc un QoS.
• PID: atzīmējiet maksimālais procesu/pavedienu skaits kas var izveidot grupu, mazinot atzarošanās bumbas vai koda kļūdas, kas aktivizē pavedienus.

Praktiskā ideja ir ļoti vienkārša: jūs ievietojat savu lietojumprogrammu cgroup un norādāt maksimālo CPU, atmiņas, I/O un PID . Pēc tam kodols rūpējas par noteikumu ieviešanu.

cgroups v1 salīdzinājumā ar cgroups v2

Ražošanas vidē jūs atradīsiet divu veidu cgroups, un ir svarīgi skaidri saprast, kurā teritorijā jūs staigājat:

• cgroup v1Katram kontrolierim ir sava neatkarīga hierarhija. Jums ir maršruti, piemēram /sys/fs/cgroup/cpu/..., /sys/fs/cgroup/memory/..., Uc Tas ir elastīgs, bet sarežģīti pārvaldāms lielā mērogā.Daudzas klasiskās izplatīšanas un platformas to joprojām izmanto vai atbalsta saderības labad.
• cgroup v2: visu grupē zem viena vienota hierarhija en /sys/fs/cgroupIerobežojumi tiek konfigurēti, izmantojot tādus failus kā cpu.max, memory.max, io.max un tamlīdzīgi. Tas vienkāršo pārvaldību un uzlabo resursu precīzu sadaliMūsdienu distribūcijas pēc noklusējuma parasti izmanto 2. versiju, dažreiz ar hibrīda režīmu.

En /proc/cgroups Varat redzēt, kuri kontrolieri ir iespējoti, cik aktīvu cgroups ir un vai izmantojat 1. vai 2. versiju (2. versijā redzēsiet vienotu hierarhiju ar ID 0). Komanda mount | grep cgroup Tas arī norāda failu sistēmas veidu (cgroup2fs nozīmē v2, tmpfs (parasti norāda uz v1).

Manuāla cgrupu izveide un tipiskie ierobežojumi

Lai pilnībā izprastu Docker darbības principus, ir vērts manuāli izveidot cgroups. Vispārīgais modelis ir šāds:

• Izveidojiet cgroup direktoriju.
• Konfigurējiet ierobežojuma/prioritātes failus (CPU, atmiņa, I/O, PID…).
• Pievienojiet PID cgroup, ierakstot cgroup.procs o tasks (1. versijā).

Piemēram, cgroups v2 vidē centrālā procesora un atmiņas vajadzībām varētu būt kaut kas līdzīgs šim:

mkdir /sys/fs/cgroup/test_app
echo "+cpu +memory +io +pids" > /sys/fs/cgroup/cgroup.subtree_control
echo "50000 100000" > /sys/fs/cgroup/test_app/cpu.max
echo "512M" > /sys/fs/cgroup/test_app/memory.max
echo $$ > /sys/fs/cgroup/test_app/cgroup.procs

Tādējādi pašreizējais process ir ierobežots līdz 50% no kodola un 512 MB RAMJa jūs sākat kaut ko intensīvu (piemēram, dd piemēram, uz /dev/null), jūs redzēsiet, ka sistēma nedarbojas nepareizi. Cgroups v1 shēmā shēma ir līdzīga, bet ar tādiem failiem kā cpu.shares, cpu.cfs_quota_us, memory.limit_in_bytesutt., katrs savā hierarhijā.

Kā Docker, Kubernetes un kodols sakrīt

Virs vārdtelpām un cgroups ir vairāki programmatūras slāņi, kas nodod atbildību viena otrai, līdz tie sasniedz kodolu. Pat ja rīka nosaukums mainās, gala rezultāts vienmēr ir viens un tas pats: kodola izsaukumi, lai izveidotu vārdtelpas, konfigurētu cgroups un pievienotu failu sistēmas.

Tipisks konteineru "kaudze" mūsdienās izskatās apmēram šādi:

• Orķestrācijas slānisKubernetes, Docker Swarm, Nomad… Tie nodrošina pod/pakalpojuma dzīves ciklu, plānošanu, mērogošanu un atbalstu. mikropakalpojumu arhitektūras.
• augsta līmeņa konteinera izpildlaiksDocker Engine, konteinerizēts, CRI-O. Viņi saņem orķestrētāja pavēles un pārvērš tās konkrētās darbībās. (lejupielādēt attēlus, izveidot konteinerus, pārvaldīt momentuzņēmumus utt.).
• Zema līmeņa OCI izpildlaiksRunc, crun un līdzīgi rīki ievieš OCI specifikāciju un ir tieši atbildīgi par tās ieviešanu. viņi zvana clone(), unshare(), mount() un uzņēmums lai materializētu konteineru.
• Linux kodolsTas nodrošina vārdtelpas, cgroups, OverlayFS un visus citus primitīvus. Šeit notiek īstā "maģija".

Kad tu met docker runCeļš ir: CLI klients → dockerd → containerd → runc → kodola izsaukumi. Šajā ceļā tiek izveidotas nosaukumtelpas, piešķirtas cgroups, rootfs tiek piemontēts ar OverlayFS un sējumiem, un tiek savienotas tīkla saskarnes un tilts. Tas, ko jūs redzat kā "konteineru", kodolam ir saujiņa procesu ar noteiktiem karodziņiem un īpašiem ceļiem..

Prasības un iepriekšējās pārbaudes sistēmā

Pirms sākat eksperimentēt ar vārdtelpām un cgroups serverī, ieteicams pārliecināties, vai aparatūra un kodols atbilst saprātīgām minimālajām prasībām , it īpaši, ja plānojat iestatīt kaut ko līdzīgu ražošanas videi.

Kā atsauci parasti ieteicams vismaz 2 loģiskais centrālais procesors (CPU), 4 GB RAM (vēlams 8 GB vai vairāk) , aptuveni 20 GB brīvas vietas diskā un kodols 3.10 vai jaunāks (ideālā gadījumā 4.x vai 5.x, lai būtu visas cgroups v2 priekšrocības un modernās funkcijas).

Lai pārbaudītu, vai kodols atbalsta vārdtelpas un cgroups, vienkārši pārbaudiet izmantotās versijas konfigurācijas failu:

grep -E "CONFIG_.*_NS" /boot/config-$(uname -r)
grep -E "CONFIG_CGROUP" /boot/config-$(uname -r)

Šādām opcijām vajadzētu tur parādīties CONFIG_NAMESPACES, CONFIG_PID_NS, CONFIG_NET_NS, CONFIG_CGROUPS, CONFIG_MEMCG, CONFIG_CGROUP_SCHED atzīmēts kā =yBez tā tev nebūs daudz spēles laika.

Vēl viena praktiska detaļa ir tā, vai sistēma atļauj izveidot lietotāju vārdtelpas bez root tiesībāmTas ir ļoti noderīgi testēšanai un dažiem rīkiem. To kontrolē ar sysctl. kernel.unprivileged_userns_cloneJa tas ir uz 0, jums tas būs jāaktivizē (vai jāizmanto sviedri visur).

C grupu un vārdtelpu izpēte "īstās" ierīcēs

Diezgan vienkāršs veids, kā internalizēt šos jēdzienus, ir aplūkot, kā pati sistēma un jūsu konteineri tos izmanto . Daži noderīgi padomi:

• ls /proc/self/ns/ Tas parāda vārdtelpas, kurām pieder jūsu pašreizējā čaula (cgroup, ipc, mnt, net, pid, user, uts…).
• systemd-cgtop Tas parāda centrālā procesora, atmiņas un I/O izmantošanu pa cgroup, ļoti līdzīgi kā top bet grupēti pēc pakalpojumiem un konteineriem.
• En /sys/fs/cgroup Jūs varat atrast cgroups, ko Docker vai Podman izveido katram konteineram, parasti izmantojot konteinera ID ceļā. Iekšpusē, cgroup.procs Uzskaitiet saistītos PID.
• /proc/<pid>/cgroup Tas norāda, kurām cgrupām ir piešķirts konkrēts process, kas ir ideāli piemērots problemātiskas lietotnes izsekošanai.

Jūs redzēsiet, ka konteineri ir vienkārši vēl viens cgroups hierarhijas atzars ar saviem centrālā procesora, atmiņas, blkio un citiem ierobežojumiem, tāpat kā jūs tos varētu izveidot manuāli . Docker skaistums slēpjas apstāklī, ka tas to dara automātiski un ar lietotājam draudzīgu API.

Veiktspējas, NUMA un afinitātes stratēģijas

Augstas slodzes scenārijos (lielas datubāzes, intensīva apstrāde, straumēšana utt.) vienkārša "konteineru palaišana" nav pietiekama. Tas, kā katram pakalpojumam tiek piešķirts centrālais procesors un atmiņa, būtiski ietekmē veiktspēju.

Izmantojot cpuset draiveri, varat piešķirt procesus vai pakalpojumus noteiktām centrālo procesoru un NUMA mezglu kopām. Tas ir pavisam vienkārši:

mkdir /sys/fs/cgroup/cpuset/dedicated_cpus
echo "4-7" > /sys/fs/cgroup/cpuset/dedicated_cpus/cpuset.cpus
echo "0" > /sys/fs/cgroup/cpuset/dedicated_cpus/cpuset.mems
echo 1 > /sys/fs/cgroup/cpuset/dedicated_cpus/cpuset.cpu_exclusive

Tas ļauj rezervēt kodolu grupu konkrētam pakalpojumam un novērst pārējās sistēmas traucējumus. Tas samazina troksni, pavedienu migrāciju un latentuma problēmas , kas bieži rodas, kad visi konkurē par vieniem un tiem pašiem centrālajiem procesoriem.

Atmiņas līmenī numactl apvienošana ar cgroups (vai tieši izmantojot atmiņas kontrollera NUMA pogas, ja tādas ir pieejamas) palīdz saglabāt datus fiziskajā mezglā vistuvāk kodoliem, kas tos izmanto. Tas ir pamanāms latentuma jutīgās lietojumprogrammās.

C grupu un vārdtelpu uzraudzība un novērojamība

Resursu ierobežojumu noteikšana ir laba, bet Ja neizmērīsi notiekošo, vari iešaut sev kājā, pat to neapzinoties.cgroup v2 žurnālos piedāvā diezgan daudz noderīgu rādītāju. *.stat, *.events y *.pressure.

Daži praktiski piemēri:

• cpu.stat Tas norāda, cik daudz centrālā procesora laika grupa ir izmantojusi, cik reižu tā ir tikusi ierobežota utt.
• memory.current y memory.max Tie parāda pašreizējo patēriņu un konfigurēto ierobežojumu.
• memory.events Tas reģistrē OOM, sasniegtos mīkstos limitus un citus bailes.
• io.stat uzkrāj lasīšanas/rakstīšanas reižu skaitu katrā ierīcē.

Lai iegūtu īsu pārskatu, systemd-cgtop Tas ir ļoti praktiski, un, ja vēlaties kaut ko industriālāku, tādi rīki kā cPadomnieks Viņi eksportē Docker/containerd cgroup metrikas uz Prometheus, ļaujot bez liekas piepūles izveidot pilnīgus informācijas paneļus Grafana, kas ir ideāli piemērots uzlabots sistēmas monitors.

Atkļūdojot vārdtelpas problēmas, tiek izmantoti vienkārši skripti, kas šķērso /proc/<pid>/ns/ un salīdziniet simbolisko saišu palīdzību lai zinātu, kuri procesi koplieto vienu un to pašu vārdtelpuvai lai atrastu “pazaudētu” tīkla nosaukumtelpu, kas ir iestrēgusi.

Systemd izmantošana kā cgroup pārvaldnieks

Vairumā mūsdienu izplatījumu systemd lielā mērā paļaujas uz cgroups, lai pārvaldītu pakalpojumus, sektorus un darbības jomas . Kad definējat vienību ar resursu robežām, systemd faktiski izveido cgroup šim pakalpojumam un konfigurē tās apstrādātājus.

Pakalpojums, kas deklarēts ar tādām direktīvām kā:

CPUQuota=50%
CPUWeight=500
MemoryMax=512M
IOReadBandwidthMax=/dev/sda 10M

Tas nozīmē cgroup ierobežojumus centrālā procesora, atmiņas un I/O jaudai šīs vienības procesam. Tas ļauj saskaņot "klasisko" pakalpojumu pārvaldību ar konteinera modeli, izmantojot to pašu pamatā esošo kodola apakšsistēmu. Plašāku informāciju par systemd un tā prasībām skatiet sadaļā systemd izmaiņas.

Komandām, kas apvieno tradicionālos pakalpojumus ar konteineriem (ļoti bieži), paļaušanās uz systemd, lai iestatītu ierobežojumus kritiskajiem dēmoniem, ir elegants veids, kā novērst resursu iznīcināšanu podu dēļ konteinerizētā vidē.

Vidēs ar vairākām darba slodzēm, sākot no datubāzēm līdz uzraudzības aģentiem un pielāgotām lietojumprogrammām, vārdtelpu un cgroups apgūšana ļauj definēt spēcīgas izolācijas politikas, pielāgot pakalpojuma kvalitāti un nodrošināt, ka katram komponentam ir sava labi kontrolēta centrālā procesora un atmiņas sadale . Izpratne par to, kā Docker, Kubernetes un systemd izmanto šīs kodola iespējas, ļauj jums izstrādāt drošākas vairāku nomnieku infrastruktūras, atkļūdot sarežģītas problēmas (no OOM līdz I/O sastrēgumiem) un maksimāli izmantot aparatūru, nezaudējot stabilitāti.