K3S -i kaunade võrgulepääsuprobleemide lahendamine rantšoris

POD -võrgu piirangute mõistmine K3S -is 🛜

Kubernetese klastri seadistamisel koos ranturi ja K3 -dega võib võrgustike loomine muutuda suureks väljakutseks. Tavaline probleem tekib siis, kui töötajate sõlmed võivad jõuda väliste võrkudeni, kuid nende sõlmede piires töötavad kaunad on piiratud. See võib olla pettumust valmistav, eriti kui teie sõlmedel on korralikud marsruudid konfigureeritud, kuid teie kaunad jäävad isoleerituks.

Seda stsenaariumi esineb sageli keskkonnas, kus töötajate sõlmed on osa laiemast võrguarhitektuurist. Näiteks võivad teie töötaja sõlmed kuuluda alamvõrku 192.168.1.x ja pääseb staatiliste marsruutide kaudu teisele alamvõrgule, näiteks 192.168.2.x. Nendel sõlmedel töötavad kaunad ei suuda aga aastatel 192.168.2.x masinatega suhelda.

Siin seisneb väljakutse selles, kuidas Kubernetes haldab võrkude loomist ja kuidas liiklus voolab kaunadest välistesse sihtkohtadesse. Ilma nõuetekohase konfigureerimiseta võivad kaunad pääseda ressurssidele ainult oma sõlme võrgus, jättes välised masinad kättesaamatuks. Lahenduse leidmiseks on ülioluline mõista, miks see juhtub.

Selles artiklis uurime, miks podid seisavad nende võrgupiirangutega silmitsi ja kuidas võimaldada neil juurde pääseda välistele alamvõrkudele. Praktiliste sammude ja reaalse maailma näidete kaudu aitame teil seda ühenduvuse lõhet ületada. Sukeldugem sisse! 🚀

K3S-i kaunade võrguülese ühenduvuse tagamine

Juurutamisel K3S Rancheri abil võivad tekkida võrgustikuprobleemid, kui kaunad peavad suhtlema masinatega väljaspool nende vahetut alamvõrku. Esitatud skriptid käsitlevad seda probleemi, muutes marsruutimisreegleid ja konfigureerides NAT -i (võrguaadressi tõlge). Üks võtme skript kasutab iptable Maskeeriva reegli rakendamiseks, tagades, et POD -liiklus näib tulevat töötajate sõlmest. See võimaldab välisetel masinatel reageerida kaunadele, ületades vaikevõrgu isolatsiooni.

Teine lähenemisviis hõlmab staatiliste marsruutide käsitsi lisamist. Tööliste sõlmedel on sageli juurdepääs muudele võrkudele staatiliste marsruutide kaudu, kuid Kubernetes kaunad ei pärsi neid marsruute vaikimisi. Käivitades skripti, mis lisab selgesõnaliselt marsruudi sõlmevärava kaudu 192.168.2.x, veendume, et kaunad jõuavad nende masinateni. See on hädavajalik keskkondades, kus suhtleb mitu sisevõrku, näiteks erinevate osakondade jaoks eraldi VLAN -idega ettevõtted.

Protsessi automatiseerimiseks a Kubernetes daemonset saab juurutada. See tagab, et võrgustiku konfiguratsioone rakendatakse järjepidevalt kõigi klastri sõlmede vahel. DEEMONSET juhib privilegeeritud konteinerit, mis täidab võrgustiku käske, muutes selle skaleeritavaks lahenduseks. See meetod on eriti kasulik suure töötajate sõlmede laevastiku haldamisel, kus iga sõlme käsitsi konfigureerimine oleks ebapraktiline. Kujutage ette pilvepõhist rakendust, mis vajab juurdepääsu pärandmebaasile, mis on hostitud teises alamvõrgus-see seadistamine tagab sujuva ühenduvuse.

Lõpuks on testimine ülioluline. Esitatud skript juurutab lihtsa hõivatud kasti kauna, mis üritab välist masinat püüda. Kui ping õnnestub, kinnitab see, et ühenduvuse parandus töötab. Seda tüüpi reaalmaailma kinnitamine on hindamatu tootmiskeskkonnas, kus katkised võrgukonfiguratsioonid võivad põhjustada teenuse häireid. Kombineerides neid lähenemisviise-NAT, staatilisi marsruute, Kubernetes automatiseerimist ja reaalajas testimist-loome K3S-klastrites vastupidava lahenduse võrguülese juurdepääsu jaoks. 🚀

#!/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

#!/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

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

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-i võrgustiku optimeerimine mitme-subnet-suhtluse jaoks

Üks ülioluline, kuid sageli tähelepanuta jäetud aspekt K3S -i võrgustike loomine on konteinerivõrgu liidese (CNI) roll POD -ühenduvuse haldamisel. Vaikimisi kasutab K3S oma CNI -na Flannelit, mis lihtsustab võrkude loomist, kuid ei pruugi toetada täiustatud marsruutimist kastist välja. Juhtudel, kui kaunad peavad pääsema ressurssidele väljaspool nende esmast alamvõrku, võib flanelli asendamine funktsioonirikkama CNI-ga, nagu Calico või Cilium, pakkuda täiendavat paindlikkust ja kohandatud marsruutimisvõimalusi.

Teine oluline tegur on DNS -i eraldusvõime. Isegi kui marsruutimine on korralikult konfigureeritud, võivad kaunad siiski ebaõigete DNS -sätete tõttu väliste teenustega ühenduse loomise nimel vaeva näha. Kubernetes tugineb tavaliselt südamikutele, mis ei pruugi hostinimede automaatselt välistest võrkudest lahendada. Kohandatud DNS -sätete konfigureerimine klastris aitab tagada sujuva suhtluse kaunade ja masinate vahel teiste alamvõrkude vahel, parandades nii juurdepääsetavust kui ka jõudlust.

Turvalisuse kaalutlused mängivad ka võtmerolli. POD -juurdepääsu laiendamisel väljaspool kohalikku võrku tuleb tundlike ressursside paljastamise vältimiseks hoolikalt kohandada tulemüüri reegleid ja võrgupoliitikat. Kubernetes võrgupoliitika rakendamine võib piirata tarbetut liiklust, võimaldades samal ajal vajalikke ühendusi. Näiteks võib POD -is töötav veebiteenus vajada juurdepääsu kaug andmebaasile, kuid see ei tohiks olla piiramatu juurdepääs kõigile välistele masinatele. Nende poliitikate haldamine suurendab tõhusalt turvalisust, säilitades samal ajal vajaliku ühenduvuse. 🔐