„K3S POD“ tinklo prieigos problemų sprendimas „Rancher“

„K3S POD“ tinklo prieigos problemų sprendimas „Rancher“
„K3S POD“ tinklo prieigos problemų sprendimas „Rancher“
Jules David
2025 m. vasario 18 d., antradienis 18:32:51

POD tinklo apribojimų supratimas K3S 🛜

Nustatydami „Kubernetes“ klasterį su „Rancher“ ir „K3S“, tinklų kūrimas gali tapti pagrindiniu iššūkiu. Bendra problema iškyla tada, kai darbuotojo mazgai gali pasiekti išorinius tinklus, tačiau tie mazguose veikiančios ankštys yra ribojamos. Tai gali būti nelinksma, ypač kai jūsų mazgai yra sukonfigūruoti tinkamai, tačiau jūsų ankštys lieka izoliuoti.

Šis scenarijus dažnai susiduriamas su aplinka, kurioje darbuotojų mazgai yra platesnės tinklo architektūros dalis. Pavyzdžiui, jūsų darbuotojo mazgai gali priklausyti 192.168.1.x potinkiui ir gali pasiekti kitą potinklį, pavyzdžiui, 192.168.2.x, statiniais maršrutais. Tačiau tie mazguose veikiančios ankštys negali bendrauti su mašinomis 192.168.2.x.

Iššūkis čia slypi tuo, kaip „Kubernetes“ valdo tinklus ir kaip srautas iš ankščių teka į išorines paskirties vietas. Neturėdami tinkamos konfigūracijos, podos gali galėti pasiekti išteklius tik savo mazgo tinkle, todėl išorinės mašinos nepasiekiamos. Suprasti, kodėl taip atsitinka, labai svarbu rasti sprendimą.

Šiame straipsnyje mes ištirsime, kodėl Pods susiduria su šiais tinklo apribojimais ir kaip jiems leisti pasiekti išorinius potinklius. Vykdydami praktinius veiksmus ir realaus pasaulio pavyzdžius, mes padėsime jums užpildyti šį ryšio spragą. Pasinerkime! 🚀

Komanda Naudojimo pavyzdys
iptables -t nat -A POSTROUTING -s 10.42.0.0/16 -o eth0 -j MASQUERADE Prideda NAT (tinklo adresų vertimo) taisyklę, kad POD galėtų susisiekti su išoriniais tinklais, maskuojant jų šaltinio IP.
echo 1 >echo 1 > /proc/sys/net/ipv4/ip_forward Įgalina IP persiuntimą, leisdami paketus iš vieno tinklo nukreipti į kitą, o tai yra būtina komunikacijai skersai.
ip route add 192.168.2.0/24 via 192.168.1.1 dev eth0 Rankiniu būdu pridedamas statinis maršrutas, nukreipdamas srautą į 192.168.2.x tinklą per 192.168.1.1 šliuzą.
iptables-save >iptables-save > /etc/iptables/rules.v4 Išlieka „iptable“ taisykles, todėl jos išlieka aktyvios po sistemos paleidimo.
systemctl restart networking Iš naujo paleidžiama tinklo paslauga, kad būtų galima pritaikyti naujai sukonfigūruotus maršrutus ir ugniasienės taisykles.
hostNetwork: true „Kubernetes“ POD konfigūracija, leidžianti konteineriui bendrinti pagrindinio kompiuterio tinklą, apeidamas vidinių klasterių tinklų apribojimus.
securityContext: { privileged: true } Suteikia „Kubernetes“ konteinerio padidėjusius leidimus, leidžiančius jam modifikuoti tinklo nustatymus pagrindiniame kompiuteryje.
ip route show Rodoma dabartinė maršruto parinkimo lentelė, padedanti derinti sujungimo problemas tarp potinklių.
command: ["sh", "-c", "ping -c 4 192.168.2.10"] Vykdo pagrindinį tinklo ryšio testą „Kubernetes“ POD viduje, kad patikrintų išorinę prieigą.
echo "192.168.2.0/24 via 192.168.1.1 dev eth0" >>echo "192.168.2.0/24 via 192.168.1.1 dev eth0" >> /etc/network/interfaces Prideda nuolatinį statinį kelią į sistemos tinklo konfigūracijos failą, užtikrinant, kad jis išliks po perkrovos.

Užtikrinant „K3S POD“ kryžminio tinklo ryšį

Dislokuojant K3s Naudodamiesi „Rancher“, tinklų kūrimo klausimai gali kilti, kai ankštys turi bendrauti su mašinomis, esančiomis už jų tiesioginio potinklio. Scenarijai pateikė išspręsti šią problemą modifikuodami maršruto parinkimo taisykles ir konfigūruodami NAT (tinklo adresų vertimas). Naudojamas vienas pagrindinis scenarijus Iptables Norėdami pritaikyti maskuojančią taisyklę, užtikrinant, kad POD srautas atrodo iš paties darbuotojo mazgo. Tai leidžia išorinėms mašinoms reaguoti į POD, įveikti numatytąją tinklo izoliaciją.

Kitas požiūris apima rankiniu būdu pridedant statinius maršrutus. Darbuotojų mazgai dažnai turi prieigą prie kitų tinklų statiniais maršrutais, tačiau „Kubernetes“ ankštys nepaveldėja šių maršrutų pagal numatytuosius nustatymus. Vykdydami scenarijų, kuris aiškiai prideda maršrutą į 192.168.2.x per mazgo šliuzą, įsitikiname, kad ankštys gali pasiekti tas mašinas. Tai labai svarbu aplinkoje, kurioje turi bendrauti keli vidiniai tinklai, pavyzdžiui, įmonės, turinčios atskirus VLAN skirtingiems departamentams.

Norėdami automatizuoti procesą, a Kubernetes Daemonset galima dislokuoti. Tai užtikrina, kad tinklo konfigūracijos būtų nuosekliai taikomos visuose klasterio mazguose. „Daemonset“ vykdo privilegijuotą konteinerį, kuris vykdo tinklo komandas, todėl tai yra keičiamas sprendimas. Šis metodas yra ypač naudingas tvarkant didelį darbuotojų mazgų parką, kai rankiniu būdu sukonfigūruoti kiekvieną mazgą būtų nepraktiška. Įsivaizduokite, kad debesyje pagrįsta programa, kuriai reikalinga prieiga prie senosios duomenų bazės, esančios kitame potinklyje,-ši sąranka užtikrina sklandų ryšį.

Galiausiai bandymai yra labai svarbūs. Pateiktame scenarijuje diegia paprastas „Busybox“ pod, bandantis surišti išorinį kompiuterį. Jei „Ping“ pavyks, tai patvirtina, kad ryšio taisymas veikia. Šio tipo realaus pasaulio patikrinimas yra neįkainojamas gamybos aplinkoje, kur sugedusios tinklo konfigūracijos gali sukelti paslaugų sutrikimus. Derindami šiuos metodus-NAT, statinius maršrutus, „Kubernetes“ automatizavimą ir tiesioginį testavimą-mes sukuriame patikimą sprendimą, skirtą prieigai prie tinklų K3S grupėse. 🚀

Užtikrinant POD ryšį su išoriniais tinklais K3S

„Iptables“ naudojimas, norint sukonfigūruoti NAT, skirtą „Pod Communication“

#!/bin/bash
# Enable IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
# Add NAT rule to allow pods to access external networks
iptables -t nat -A POSTROUTING -s 10.42.0.0/16 -o eth0 -j MASQUERADE
# Persist iptables rule
iptables-save > /etc/iptables/rules.v4
# Restart networking service
systemctl restart networking

Leidžiant K3S ankštoms pasiekti išorinius potinklius per maršruto įpurškimą

Naudojant statinius maršrutus ir CNI konfigūracijas

#!/bin/bash
# Add a static route to allow pods to reach 192.168.2.x
ip route add 192.168.2.0/24 via 192.168.1.1 dev eth0
# Verify the route
ip route show
# Make the route persistent
echo "192.168.2.0/24 via 192.168.1.1 dev eth0" >> /etc/network/interfaces
# Restart networking
systemctl restart networking

Naudojant „Kubernetes Daemonset“, norint pritaikyti tinklo taisykles

„Kubernetes Daemonset“ diegimas, norint sukonfigūruoti mazgų tinklą

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: k3s-network-fix
spec:
  selector:
    matchLabels:
      app: network-fix
  template:
    metadata:
      labels:
        app: network-fix
    spec:
      hostNetwork: true
      containers:
      - name: network-fix
        image: alpine
        command: ["/bin/sh", "-c"]
        args:
        - "ip route add 192.168.2.0/24 via 192.168.1.1"
        securityContext:
          privileged: true

Testavimo tinklo ryšio iš POD

Naudojant „Kubernetes“ „BusyBox“ pod, norint patikrinti tinklo prieigą

apiVersion: v1
kind: Pod
metadata:
  name: network-test
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["sh", "-c", "ping -c 4 192.168.2.10"]
  restartPolicy: Never

K3S tinklo optimizavimas daugialypiam ryšiui

Vienas esminis, bet dažnai nepastebėtas aspektas K3S tinklų kūrimas yra konteinerių tinklo sąsajos (CNI) vaidmuo valdant POD ryšį. Pagal numatytuosius nustatymus „K3S“ naudoja flanelę kaip savo CNI, kuris supaprastina tinklų kūrimą, tačiau gali nepalaikyti išplėstinio maršruto nustatymo iš dėžutės. Tais atvejais, kai ankščiai turi pasiekti išteklius už savo pagrindinio potinklio ribų, „Flanel“ pakeitimas labiau turtingu CNI, pavyzdžiui, „Calico“ ar „Cilium“, gali suteikti papildomo lankstumo ir pasirinktinių maršrutų parinkčių.

Kitas svarbus veiksnys yra DNS skiriamoji geba. Net jei maršrutizavimas yra tinkamai sukonfigūruotas, POD vis tiek gali stengtis prisijungti prie išorinių paslaugų dėl neteisingų DNS nustatymų. „Kubernetes“ paprastai priklauso nuo „CoredNs“, kuri gali automatiškai neišspręsti pagrindinio kompiuterių vardų iš išorinių tinklų. Pasirinktinių DNS parametrų konfigūravimas klasteryje gali padėti užtikrinti sklandų ryšį tarp ankščių ir mašinų kituose potinkliuose, pagerinant prieinamumą ir našumą.

Saugumo sumetimai taip pat vaidina pagrindinį vaidmenį. Plėtant POD prieigą už vietinio tinklo ribų, ugniasienės taisyklės ir tinklo politika turi būti atsargiai koreguojamos, kad būtų išvengta neskelbtinų išteklių. „Kubernetes“ tinklo politikos įgyvendinimas gali apriboti nereikalingą srautą, tuo pačiu leisdama reikiamus ryšius. Pvz., POD veikiančioje žiniatinklio paslaugoje gali prireikti prieigos prie nuotolinės duomenų bazės, tačiau neturėtų turėti neribotos prieigos prie visų išorinių mašinų. Šios politikos valdymas efektyviai padidina saugumą išlaikant reikalingą ryšį. 🔐

Dažnai užduodami klausimai apie K3S tinklų kūrimą ir prieigą

  1. Kodėl darbuotojo mazgai gali pasiekti išorinius tinklus, tačiau ankštys negali?
  2. Podos naudoja vidinį K3s Tinklas, atskirai nuo pagrindinio kompiuterio tinklo kamino. Pagal numatytuosius nustatymus jie ne paveldi darbuotojo mazgo statinių maršrutų.
  3. Kaip galiu leisti „K3S Pod“ pasiekti išorinį potinklį?
  4. Galite modifikuoti maršruto parinkimo taisykles naudodami iptables arba pridėkite statinius maršrutus su ip route add Norėdami įjungti POD ryšį su išorinėmis mašinomis.
  5. Ar flanelė palaiko kryžminio pobūdžio maršrutą?
  6. Ne, flanelė pagal numatytuosius nustatymus nepateikia išplėstinio maršruto. Pakeitus jį „Calico“ ar „Cilium“, galima labiau kontroliuoti tinklo politiką ir maršrutus.
  7. Ar „Kubernetes“ tinklo politika gali padėti valdyti išorinę prieigą?
  8. Taip, jie leidžia apibrėžti taisykles, kuriomis POD gali susisiekti su išorinėmis paslaugomis, pagerinti saugumą ir ryšį.
  9. Koks yra geriausias būdas išbandyti, ar podus gali pasiekti išorinę mašiną?
  10. Diegkite laikiną podą naudodami kubectl run su tokiu vaizdu kaip „BusyBox“, tada naudokite ping arba curl POD viduje, kad patikrintumėte ryšį.

„Kubernetes Pod“ ryšio patobulinimas

K3S tinklo konfigūravimui, kad būtų galima palaikyti „Cross-subnet“ prieigą, reikalingas maršruto strategijų, ugniasienės reguliavimo ir „Kubernetes“ tinklo politikos derinys. Naudojant „iptables“, statinius maršrutus ar pažangų CNI, norint efektyviai išspręsti šias problemas, svarbu suprasti, kaip bendrauti ankštys yra svarbiausia. Šie sprendimai užtikrina, kad „Kubernetes“ diegimas gali būti mastelio keitimas be tinklo kliūčių.

Testavimas ir patvirtinimas yra toks pat svarbus kaip įgyvendinimas. Naudojant tokius įrankius kaip „UsionBox“ tiesioginio tinklo testavimui, padeda patvirtinti ryšio pataisas. Gerai optimizuota tinklo sąranka ne tik pagerina našumą, bet ir stiprina saugumą. Turėdami tinkamą konfigūraciją, „K3S“ grupės gali sklandžiai prisijungti prie išorinių sistemų, todėl diegimas tampa universalesnis. 🔧

Tolesnis skaitymas ir nuorodos
  1. Oficialios rančos dokumentacija K3S tinkle: „Rancher K3S“ tinklų kūrimas
  2. „Kubernetes“ oficialus tinklo politikos vadovas: „Kubernetes“ tinklo politika
  3. „Calico CNI“, skirta pažangių „Kubernetes“ tinklų kūrimui: Projektas „Calico“
  4. „Linux iptables“ ir geriausios maršruto parinkimo praktika: „Netfilter“/„iptables Howto“
  5. „Kubernetes Pod“ tinklo supratimas: CNCF „Kubernetes“ tinklas 101
Patikimi šaltiniai ir techninės nuorodos
  1. Oficialus „Kubernetes“ tinklo dokumentacija, skirta suprasti „POD-I-External“ tinklo ryšį: „Kubernetes“ tinklų kūrimas .
  2. „Rancher“ oficialus K3S tinklų kūrimo ir trikčių šalinimo ryšio problemų konfigūravimo vadovas: „Rancher K3S“ tinklų kūrimas .
  3. „Calico“ pažangios „Kubernetes“ tinklų sprendimai, įskaitant kryžminio pobūdžio maršrutą: „Calico“ tinklų kūrimas .
  4. Flanelės dokumentacija, skirta suprasti numatytąjį K3S tinklo elgseną: Flanelės github .
  5. „Linux iptables“ ir maršruto parinkimo konfigūracijos, kad būtų galima išplėsti POD prieigą už darbuotojų mazgų ribų: Iptables archwiki .