Dette indlæg vil diskutere, hvad Linux sysctl er i Kubernetes, og hvordan det kan bruges i en klynge af Kubernetes. Sysctl er en grænseflade i Linux-operativsystemet, som gør det muligt for administratoren at ændre parametrene for kernen under kørsel. Her vil vi demonstrere, hvordan man bruger Linux-sysctls i Kubernetes-platformen. Vi vil demonstrere et simpelt eksempel for at hjælpe dig med at forstå, hvilken slags output du kan forvente, mens du implementerer kubectl-kommandoerne til brug af sysctls i Kubernetes.
Hvad er sysctls?
Sysctls er en grænseflade i Linux, som bruges til at justere kerneparametre under kørsel for navneområdet i en container. Disse parametre kan findes i den virtuelle procesfil /proc/sys/, og de dækker forskellige undersystemer som virtuel hukommelse, netværk, kerne osv. Kun navneinddelte sysctls kan indstilles uafhængigt på pods, og Kubernetes afslører sysctl-indstillingerne. Nodeniveau sysctls, som ikke er navneafstande, skal indstilles med andre metoder til sysctls indstilling som node tuning operator. Desuden er det kun sikre sysctls, der er hvidlistet som standard, mens de usikre sysctls skal aktiveres manuelt på noden, så de kan være tilgængelige for brugeren. Lad os nu forstå, hvordan man bruger Linux sysctls i Kubernetes.
Forudsætninger
Før du begynder at lære, hvordan du bruger Linux-sysctls i Kubernetes, skal du sørge for, at du har følgende værktøjer installeret på dit system:
-
- Kubernetes version 1.23 eller enhver anden seneste version
- Ubuntu 20.04 eller enhver anden nyeste version
- Sysctls til pod-understøttelse
- Kubectl kommandolinjeværktøj
- Minikube klynge
Forudsat at dit system opfylder forudsætningskravene, går vi videre til implementeringsafsnittet.
Hvordan bruger man Linux-sysctls i Kubernetes?
Linux-operativsystemet er en platform, der giver dig mulighed for at tune kernerne via sysctls-knapper i netværksstakken. Nogle af sysctl'erne er navngivet for en pod med sin egen konfiguration, mens andre er gyldige for hele systemet. Kubernetes har grupperet sysctls-grænsefladen i to kategorier:
-
- Navneafstand vs sysctls på nodeniveau
- Sikre vs usikre sysctls
Navneafstand vs sysctls på nodeniveau:
I Linux-kernen er de fleste af sysctl'erne navneafstande, hvilket gør det muligt for dig at indstille dem uafhængigt mellem forskellige pods på en node. De navneafstande sysctls er let tilgængelige i en Kubernetes pod. Nogle af de navneinddelte sysctls er som følger:
-
- fs.mqueue.*
- kernel .msg*
- kernel.shm*
- kernel.sem
Sysctlerne på nodeniveau er ikke navneafstande, og klyngeadministratoren skal indstille dem manuelt. Klyngeadministratoren bruger enten et dæmonsæt med en privilegeret beholder eller kan ændre /etc/sysctls.conf-nodens Linux-distribution. Node Tuning Operator kan også bruges til at indstille node niveau sysctls.
Sikre vs usikre sysctls:
Der er to grupper af sysctls: sikker og usikker. De sikre sysctls er korrekt navneafstand, og de er fuldstændigt isolerede i pods på den samme node. De sikre sysctls er aktiveret som standard og kan bruges i en pod ved at ændre pod-specifikationen. De usikre sysctls er dog deaktiveret som standard, og de skal aktiveres manuelt af klyngeadministratoren. De sikre sysctls påvirker ikke deres naboer, da de har korrekt navneafstand. Mens de usikre sysctls uventet kan påvirke deres naboer som at overbelaste et system. Det sikre sæt af sysctls er som følger:
-
- net.ipv4.ping_group_range
- net.ipv4.ip_local_port_range
- kernel.shm_rmid_forced
- net.ipv4.tcp_syncookies
Pointen her, der skal bemærkes, er, at blot at være navneafstand alene ikke er nok til, at sysctl'et kan antages at være sikkert.
Nu hvor vi har forstået begge kategorier af sysctls, lad os gå videre for at lære, hvordan man bruger disse sysctls i Kubernetes. Her vil vi guide dig til, hvordan du bruger både sikre og usikre sysctls, og hvordan du manuelt aktiverer usikre sysctls i Kubernetes.
Trin #1: Start Minikube-klyngen
Kubernetes-platformen kan bruges via nogle klynger, og vi bruger minikube-klyngen her. For at starte minikube-klyngen kan du bruge kommandoen nedenfor:
> start minikube
Dette vil starte minikube-klyngen, hvor du kan køre kubectl-kommandoerne og bruge Linux-sysctl'erne på Kubernetes-platformen. Når du udfører denne kommando, får du et lignende output som det, der er angivet nedenfor:
Trin # 2: Tjek parametrene for sysctls
Sysctls-grænsefladen bruges til at ændre kerneparametrene, som findes i /proc/sys/ virtuelle procesfilen. For at liste alle parametrene kan kommandoen nedenfor bruges:
> sudo sysctl -en
Denne kommando viser alle kerneparametrene fra /proc/sys/ virtuelle procesfilen. Se eksempeloutput givet i snapshot nedenfor:
Trin #3: Aktiver usikre sysctls
De usikre sysctls skal aktiveres manuelt, fordi de er deaktiveret som standard. Klyngeadministratoren aktiverer manuelt de usikre sysctls på en per-node basis. De pods, der har deaktiveret usikre sysctls, kan ikke startes, men kun planlægges. Der er nogle specifikke forhold (såsom tuning af køretidsapplikationer, høj ydeevne osv.), når klyngeadministratoren kan tillade de usikre sysctls. For at aktivere de usikre sysctls på en node-for-node basis, kan du bruge kommandoen kubectl nedenfor:
> kubectl –allowed-unsafe-sysctls \
Dette er en meget grundlæggende og enkel måde at aktivere usikre sysctls ved at bruge kommandoen kubectl.
Desuden kan usikre sysctls aktiveres ved at bruge minikube extra-config flaget. Dette kan gøres ved at bruge kommandoen nedenfor:
Denne kommando giver dig mulighed for at aktivere de usikre sysctls via minikube-klyngen. Det kan dog kun aktivere de navneafstande sysctls. Se eksempeloutput givet i snapshot nedenfor:
Konklusion
Denne artikel gav os et overblik over Linux sysctls-grænsefladen. Vi diskuterede, hvad en Linux-sysctl er, og hvordan den kan bruges i Kubernetes-miljøet. Der er to grupper af sysctls: er sikker og usikker. Den sikre gruppe af sysctls er aktiveret som standard, mens gruppen usikre sysctls er deaktiveret som standard. Ved hjælp af et enkelt og nemt eksempel lærte vi, hvordan man aktiverer de usikre sysctls ved hjælp af kommandoen kubectl og minikube –extra-config flag.