Možno poznáte vtip o jednotke dočasnosti.
Jeden furt.
Vychádza z pomerne univerzálnej skúsenosti IT sveta: dočasné riešenia, ktoré fungujú dostatočne dobre, majú zvláštnu tendenciu zostať s nami oveľa dlhšie, než sme pôvodne plánovali.
A na Kubernetes to sedí dokonale.
Z malého experimentu produkčná platforma
Typický príbeh Kubernetes klastra často začína nevinne.
„Vyskúšame si na tom jednu aplikáciu.“
Nasadíme prvý workload. Funguje. Pridáme druhý. Potom monitoring, interné API, databázové služby, integračné komponenty a ďalšie aplikácie.
Vďaka stabilite platformy, automatizácii a relatívne jednoduchému nasadzovaniu workloadov sa z pôvodného experimentálneho klastra postupne stane dôležitá infraštruktúra.
A spolu s počtom aplikácií rastie aj počet Kubernetes Service objektov.
A práve tu sa môže ozvať jedno z rozhodnutí, ktoré sme urobili pri úplnom začiatku životného cyklu klastra.
Čo ak vám jednoducho dôjdu ClusterIP adresy?
Pri vytváraní Kubernetes klastra sa definuje rozsah IP adries určených pre služby typu ClusterIP. Na strane kube-apiserver ho tradične určuje parameter:
--service-cluster-ip-range
Ak ste napríklad pri vzniku klastra nastavili relatívne malý rozsah a počet služieb postupne rástol, mohli ste sa časom dostať až na jeho limit.
Výsledok?
Pri pokuse vytvoriť ďalší Service vás Kubernetes privítal hláškou:
error: failed to create ClusterIP service: Internal error occurred: failed to allocate a serviceIP: range is full
Inými slovami:
Došli IP adresy pre Kubernetes Services.
A hoci problém znie jednoducho, jeho riešenie historicky také jednoduché nebolo.
Keď zmena jednej siete znamenala veľkú operáciu
Prvá myšlienka je logická: keď je rozsah malý, jednoducho ho zväčšíme.
Napríklad z /24 na /16.
Lenže Service IP range je jedným zo základných sieťových parametrov klastra a jeho dodatočná zmena mohla byť pomerne invazívnou operáciou.
V závislosti od konkrétnej Kubernetes distribúcie, CNI pluginu a ďalších komponentov mohol postup vyzerať približne takto:
- naplánovať maintenance window,
- upraviť konfiguráciu
kube-apiserver, - zosúladiť konfiguráciu všetkých control-plane uzlov,
- reštartovať príslušné komponenty,
- skontrolovať existujúce Services a ich ClusterIP adresy,
- upraviť konfiguráciu
kube-proxy, - preveriť CNI plugin,
- preveriť service mesh a ďalšie sieťové komponenty,
- validovať DNS a routing,
- monitorovať, troubleshootovať...
...a ako nepovinný jedenásty krok:
11. modliť sa.
Alternatívou bolo vytvorenie nového klastra s vhodnejšie navrhnutým Service IP rozsahom a následná migrácia workloadov.
Ani jeden variant nie je presne ten typ práce, ktorý by si Kubernetes administrátor dobrovoľne pridával do kalendára.
Našťastie Kubernetes dnes ponúka oveľa elegantnejšie riešenie.
ServiceCIDR prichádza na pomoc
Kubernetes priniesol mechanizmus MultiCIDRServiceAllocator, ktorý umožňuje pracovať s viacerými rozsahmi IP adries určenými pre Kubernetes Services.
Funkcionalita sa prvýkrát objavila už v Kubernetes 1.27 a postupne dozrievala. Od Kubernetes 1.33 je stabilná – GA.
Spolu s ňou máme v Kubernetes API objekt:
ServiceCIDR
V klastri nájdeme aj štandardný objekt s názvom:
kubernetes
Jeho obsah si môžeme pozrieť napríklad:
kubectl get servicecidr
Výsledok môže vyzerať napríklad takto:
NAME CIDRS AGE
kubernetes 10.96.0.0/28 17d
Tento objekt reprezentuje základný rozsah IP adries používaný pre Kubernetes Services.
A teraz prichádza tá zaujímavá časť.
Potrebujete viac IP adries? Pridajte ďalší ServiceCIDR
Ak sa kapacita pôvodného rozsahu začne blížiť k limitu, nemusíte nevyhnutne prerábať celý Service network existujúceho klastra.
Môžete jednoducho vytvoriť ďalší ServiceCIDR s novým alebo vhodne rozšíreným rozsahom.
Napríklad:
apiVersion: networking.k8s.io/v1
kind: ServiceCIDR
metadata:
name: additional-services
spec:
cidrs:
- 10.97.0.0/16
A aplikovať ho:
kubectl apply -f servicecidr.yaml
Od tejto chvíle má Kubernetes k dispozícii ďalší priestor, z ktorého môže prideľovať ClusterIP adresy novým Services.
Bez migrácie existujúcich workloadov.
Bez prestavby celého klastra.
Bez jedenásťkrokového záchranného plánu.
Z jedenástich krokov jeden
Ak to výrazne zjednodušíme, nový postup vyzerá takto:
1. Vytvorte nový objekt ServiceCIDR.
A to je v zásade celé.
Samozrejme, pri návrhu nového rozsahu stále platí základná sieťarská disciplína. Adresný priestor musí byť navrhnutý tak, aby nevytváral konflikty s ostatnou adresáciou používanou v infraštruktúre, a v produkčnom prostredí je vhodné mať jeho prideľovanie pod kontrolou.
Kubernetes napríklad umožňuje pomocou Validating Admission Policy obmedziť, aké ServiceCIDR rozsahy môžu administrátori v klastri vytvárať.
Samotné rozšírenie kapacity Service IP priestoru je však oproti minulosti dramaticky jednoduchšie.
Malá zmena, ktorá môže ušetriť veľký problém
ServiceCIDR možno na prvý pohľad nepôsobí ako revolučná Kubernetes funkcionalita.
Nie je to nový scheduler, nový typ workloadu ani technológia, o ktorej sa bude hovoriť na každej cloud-native konferencii.
Je to však presne ten typ funkcionality, ktorý oceníte v momente, keď ho skutočne potrebujete.
Pretože infraštruktúra má jednu nepríjemnú vlastnosť:
to, čo dnes navrhujeme ako „dostatočne veľké“, nemusí byť dostatočne veľké o tri roky.
A keď sa z malého experimentálneho Kubernetes klastra stane kritická produkčná platforma, schopnosť rozšíriť Service IP priestor bez komplikovanej migrácie môže znamenať rozdiel medzi rutinnou administrátorskou operáciou a veľmi nepríjemným víkendom.
Takže ak prevádzkujete Kubernetes 1.33 alebo novší a ešte ste sa s objektom ServiceCIDR nestretli, stojí za to sa s ním zoznámiť skôr, než vám dôjdu ClusterIP adresy.
Pretože tentoraz už nemusí platiť, že:
jeden furt.
