Calico Kubernetes võrgus: tutvustus ja veidi kogemustest

Artikli eesmärk on tutvustada lugejat Kubernetes'i võrgutegevuse ja võrgupoliitikate haldamise alustega, samuti Calico kolmanda osapoole pluginaga, mis laiendab standardseid võimalusi. Samuti demonstreeritakse mugavust konfigureerimisel ja mõningaid funktsioone reaalsetest kasutuskogemustest.

Kiire sissejuhatus Kubernetes'i võrguseadmesse

Kubernetes'i klastri ettekujutamine on võimatu ilma võrku. Oleme juba avaldanud materjale nende aluselistest põhimõtetest: "Kubernetes'i võrgu toimimise illustreeritud juhend" ja "Kubernetesi võrgupoliitikate sissejuhatus turbespetsialistidele».

Selle artikli kontekstis on oluline märkida, et konteinerite ja sõlmede vahelise võrguühenduse eest ei vastuta ise K8s: selleks kasutatakse erinevaid CNI pluginaid (Container Networking Interface). Selle kontseptsiooni kohta oleme ka rääkinud.

Näiteks, kõige levinum selline plugin — Flannel — tagab täieliku võrguühenduvuse kõigi klastri sõlmede vahel, luues iga sõlme peale sillad ja kinnitades sellele alamvõrgu. Kuid täielik ja reguleerimata kergesti ligipääsetavus ei ole alati kasulik. Teatud minimaalse isolatsiooni tagamiseks klastris on vajalik sekkuda tulemüri seadistusse. Üldiselt on see usaldatud selle sama CNI käe alla, mistõttu mistahes kolmandate osapoolte sekkumised iptables'isse võivad olla valesti tõlgendatud või täielikult ignoreeritud.

Ja "karbist välja" on Kubernetes'i klastris võrgu poliitikate haldamiseks ette nähtud NetworkPolicy API. See ressurss, mis laienevad valitud nimede ruumides, võib sisaldada reegleid, mis eraldavad juurdepääsu erinevate rakenduste vahel. Samuti võimaldab see seadistada ligipääsetavust konkreetsete pod'ide, keskkondade (nimede ruumide) või IP-aadressi plokkide vahel:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

See ei ole kõige primitiivsem näide ametlikust dokumentatsioonist see, et võib igaveseks ära võtta soovi mõista võrgupoliitika tööloogikat. Siiski proovime mõista põhimõtteid ja meetodeid, millega liiklust voogusid töödeldakse võrgupoliitikate abil...

Mõistagi on kaks liiki liiklust: pod'i sisenemine (Ingress) ja pod'ist väljumine (Egress).

Need kaks kategooriat jagunevad liikumissuuna järgi.

Järgmine kohustuslik atribuut on selektor; see, kellele reegel kehtib. See võib olla pod (või pod'ide grupp) või keskkond (st nime ruum). Oluline detail: mõlemad tüübid peavad sisaldama sildit (label Kubernetes'i terminoloogias) — just nendega opereerivad poliitikad.

Lisaks lõpliku arvu selektoritele, mis on seotud mingi sildiga, on võimalik kirjutada reegleid nagu "Lubada/keelata kõik/kõigile" erinevates variatsioonides. Selleks kasutatakse konstruktsioone nagu:

  podSelector: {}
  ingress: []
  policyTypes:
  - Ingress

— selles näites on kõikide pod'ide sisenemine blokeeritud. Vastupidist käitumist saab saavutada järgmise konstruktsiooniga:

  podSelector: {}
  ingress:
  - {}
  policyTypes:
  - Ingress

Sarnane lähtudes väljaminevast liiklusest:

  podSelector: {}
  policyTypes:
  - Egress

— selle keelamiseks. Ja siin on selle lubamiseks:

  podSelector: {}
  egress:
  - {}
  policyTypes:
  - Egress

Tagasi minnes CNI-plugin'i valimise juurde klastrile, tasub märkida, et kõik võrgu pluginad ei toeta NetworkPolicy'ga töötamist.Näiteks juba mainitud Flannel ei oska konfigureerida võrgu poliitikaid, millest on otseselt öeldud ametlikus hoidlas. Seal on mainitud alternatiivi — Open Source projekt Calico, mis oluliselt laiendab Kubernetes'i standard API kogumit võrgu poliitikate osas.

Tutvume Calicoga: teooria

Calico pluginat saab kasutada Flannel'iga (alaprojekt Canal) või iseseisvalt, katab nii võrgu ühenduse tagamise funktsioonid kui ka juurdepääsu juhtimise võimalused.

Milliseid võimalusi pakub "karbi" lahenduse K8s ja Calico API kogumi kasutamine?

Siin on, mis on NetworkPolicy's sisse ehitatud:

• poliitikad on piiratud keskkonnaga;
• poliitikad kehtivad pod'idele, mis on märgitud siltidega;
• reeglid võivad kehtida pod'idele, keskkondadele või alamvõrkudele;
• reeglid võivad sisaldada protokolle, nimelisi või sümboolseid portide viiteid.

Ja nii laiendab Calico neid funktsioone:

• poliitikad võivad kehtida mis tahes objektile: pod, konteiner, virtuaalmasin või liides;
• reeglid võivad sisaldada konkreetset tegevust (keeld, lubamine, logimine);
• reeglite eesmärgiks või allikaks võivad olla port, portide vahemik, protokollid, HTTP- või ICMP-attribuudid, IP või alamvõrk (4 või 6 põlvkond), kõik valijad (sõlmed, hostid, keskkonnad);
• täiendavalt saab reguleerida liikluse läbimist DNAT-i seadete ja liikluse edastamise poliitikate abil.

Esimene commit GitHubis Calico hoidlas pärineb 2016. aasta juulist ja juba aasta hiljem saavutas projekt juhtivad positsioonid Kubernetes'i võrgustikukonnektiivsete lahenduste seas — sellest räägivad näiteks küsitluse tulemused, mille viis läbi The New Stack.:

Paljud suured hallatud K8s lahendused, nagu Amazon EKS, Azure AKS,, Google GKE, ja teised, on hakanud seda soovitama.

Mis puudutab jõudlust, siis seal on kõik suurepärane. Calico arendustiim demonstreeris oma toote testimisel astronoomilisi tulemusi, käivitades üle 50000 konteineri 500 füüsilisel sõlmelt 20 konteinerit sekundis. Probleeme skaleerimisel ei esinenud. Selliseid tulemusi toodi välja juba esimese versiooni kuulutamisel. Iseseisvad uuringud, mis on suunatud läbilaskevõime ja ressursside kasutamise analüüsimisele, kinnitavad samuti Calico jõudlust, mis on peaaegu sarnane Flanneliga. Näiteks:

Projekt areneb väga kiiresti, seda toetatakse populaarsetes hallatud K8s lahendustes, OpenShiftis, OpenStackis, on võimalus kasutada Calicot klastrite seadistamiseks kops, esinevad viidatud Service Mesh-võrkude ehitamisel (siin on näide kasutamisest koos Istio-ga).

Praktika Calicoga

Üldine vanilje Kubernetes'e kasutamise puhul tähendab CNI paigaldamine failide kasutamist calico.yaml,, mis on alla laaditud ametlikult veebilehelt., kasutades kubectl apply -f.

Reeglina on aktuaalne pistikprogramm ühilduv 2-3 viimase Kubernetes'e versiooniga: vanemate versioonidega ei testita ja ei garanteerita tööd. Arendajate sõnul töötab Calico Linuxi kerneliga üle 3.10 CentOS 7, Ubuntu 16 või Debian 8 all, iptables'i või IPVS'i peal.

Isolatsioon keskkonnas

Üldise arusaama saamiseks vaatleme lihtsat juhtumit, et mõista, kuidas Calico võrgupoliitikad erinevad tavalisest ja kuidas reeglite koostamise lähenemine lihtsustab nende lugemist ja konfigureerimise paindlikkust:

Klastris on paigaldatud 2 veebirakendust: Node.js ja PHP, millest üks kasutab Redis't. Et sulgeda PHP juurdepääs Redis'ile, jättes samas ühenduse Node.js'iga, piisab, kui rakendada järgmist poliitikat:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-redis-nodejs
spec:
  podSelector:
    matchLabels:
      service: redis
  ingress:
  - from:
    - podSelector:
        matchLabels:
          service: nodejs
    ports:
    - protocol: TCP
      port: 6379

Sisuliselt lubasime sissetulevat liiklust Redis'ile Node.js'ist. Ja ei keelanud midagi muud. Kui NetworkPolicy on olemas, hakkavad kõik selles mainitud valijad isoleeruma, kui ei ole märgitud teisiti. Samuti ei laiene isoleerimisse reeglid teistele objektidele, mis ei ole katvat valijat.

Näites kasutatakse apiVersion Kubernetes'ist "kastist välja", kuid miski ei takista kasutamast selle nimega ressurssi Calico tarnest. Sünaktsioon seal on laiem, seega tuleb ülaltoodud juhtumi reegel ümber kirjutada järgmisel kujul:

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-redis-nodejs
spec:
  selector: service == 'redis'
  ingress:
  - action: Allow
    protocol: TCP
    source:
      selector: service == 'nodejs'
    destination:
      ports:
      - 6379

Ülalmainitud konstruktsioonid, mis lubavad või keelavad kogu liikluse tavalise NetworkPolicy API kaudu, sisaldavad keerulisi, mis on raskesti mõistetavad ja meeldejäävad süntaksid sulgudes. Calico puhul piisab tulemüüri reegli loogika muutmiseks vastupidiseks "action: Allow" muutmisest action: Allow . Tundub, et action: Deny.

Isolatsioon keskkondade kaupa

Kujutame nüüd olukorda, kus rakendus genereerib ärimõõdikud, et neid koguda Prometheusesse ja edasiseks analüüsiks Grafanas. Ekspordis võivad olla tundlikud andmed, mis vaikimisi on taas kõikidele nähtavad. Sulgeme need andmed võõraste silmade eest:

Prometheus on tavaliselt paigutatud eraldi teeninduskeskkonda — selles näites on see järgmise nimega namespace:

apiVersion: v1
kind: Namespace
metadata:
  labels:
    module: prometheus
  name: kube-prometheus

Väli metadata.labels see ei olnud juhuslik. Nagu eespool mainitud, namespaceSelector (nagu ka podSelector) opereerib siltidega. Seega, et lubada metrikate kogumist kõigist pod'idest teatud portidel, tuleb lisada mõni silt (või võtta olemasolevatest) ja seejärel rakendada konfigureerimist nagu:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-metrics-prom
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          module: prometheus
    ports:
    - protocol: TCP
      port: 9100

Ja Calico poliitikate kasutamisel on süntaks järgmine:

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-metrics-prom
spec:
  ingress:
  - action: Allow
    protocol: TCP
    source:
      namespaceSelector: module == 'prometheus'
    destination:
      ports:
      - 9100

Üldiselt, lisades selliseid poliitikaid konkreetsete vajaduste jaoks, saab ära hoida pahatahtlikku või juhuslikku sekkumist rakenduste tööse klastris.

Parimaks praktikaks, nagu Calico loojad usuvad, on lähenemine "Keela kõik ja ava selgelt vajalik", kinnitatud ametlikust dokumentatsioonist (sarnast lähenemist järgivad ka teised — eelkõige, juba mainitud artiklis).

Lisa Calico objekte

Tuletan meelde, et laienenud Calico API abil saab reguleerida sõlmede kättesaadavust, piirdumata ainult pod'idega. Järgnevas näites, kasutades GlobalNetworkPolicy suletakse ICMP päringute edastamine klastris (näiteks pingid pod'ist sõlmele, pod'ide vahel või sõlmelt IP pod'ile):

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: block-icmp
spec:
  order: 200
  selector: all()
  types:
  - Ingress
  - Egress
  ingress:
  - action: Deny
    protocol: ICMP
  egress:
  - action: Deny
    protocol: ICMP

Ülaltoodud juhul jääb sõlmedel klastris võimalus omavahel ICMP kaudu "ühenduda". Ja see probleem lahendatakse GlobalNetworkPolicy, mis on rakendatud üksusele HostEndpoint:

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: deny-icmp-kube-02
spec:
  selector: "role == 'k8s-node'"
  order: 0
  ingress:
  - action: Allow
    protocol: ICMP
  egress:
  - action: Allow
    protocol: ICMP
---
apiVersion: crd.projectcalico.org/v1
kind: HostEndpoint
metadata:
  name: kube-02-eth0
  labels:
    role: k8s-node
spec:
  interfaceName: eth0
  node: kube-02
  expectedIPs: ["192.168.2.2"]

VPNi juhtum

Lõpuks toon välja täiesti reaalse näite Calico funktsioonide kasutamisest klastriga seotud suhtlemisel, kus tavaliste poliitikate komplektist ei piisa. Veebirakendusele juurdepääsuks klientide poolt kasutatakse VPN tunnelit, ja see juurdepääs on rangelt kontrollitav ja piiratud teatud lubatud teenuste nimekirjaga:

Kliendid ühendatakse VPN-iga läbi standardse UDP-porti 1194 ja ühenduse loomisel saavad nad marsruudid klusterministe pod'ide ja teenuste alavõrkudesse. Alamvõrgud push'itakse täielikult, et mitte kaotada teenuseid taaskäivitamise ja aadresside muutumise ajal.

Konfiguratsioonis olev port on standardne, mis toob kaasa teatud nüansid rakenduse konfigureerimise protsessis ja selle üleviimisel Kubernetes-kliendisse. Näiteks ilmnes AWS LoadBalancer'is UDP tugi alles eelmisel aastal piiratud piirkondades, ja NodePort'i ei saa kasutada, kuna see suunab kõikidesse klusteri sõlmedesse ning see muudab serverite eksemplaride arvu skaleerimise tõrkeotstarbeliseks võimatuks. Peale selle tuleb muuta vaikimisi valitud portide vahemikku...

Võimalike lahenduste läbivaatamise tulemusena valiti järgmine:

1. VPN pod'id on planeeritud sõlmele režiimis hostNetwork, st tegeliku IP-aadressiga.
2. Teenust eksponeeritakse väljapoole läbi ClusterIP. Sõlmel tõstetakse füüsiliselt port, mis on väljastpoolt kergelt kergesti ligipääsetav (tingimuslikult on olemas tegelik IP-aadress).
3. Pod'i tõusmise sõlme määratlemine jääb meie jutust väljapoole. Ütlen vaid, et teenust on võimalik rangelt "kinni panna" sõlmele või kirjutada väike sidecar-teenus, mis jälgib VPN-teenuse praegust IP-aadressi ja muudab DNS-kirjeid klientide juures — kellel jagub fantaasiat.

Marsruudi seisukohalt saame selgelt tuvastada VPN'i kliendi tema IP-aadressi järgi, mida VPN-server välja annab. Allpool on primitiivne näide juurdepääsu piiramisest sellisele kliendile teenustele, joonistus ülaltoodud Redis'il:

apiVersion: crd.projectcalico.org/v1
kind: HostEndpoint
metadata:
  name: vpnclient-eth0
  labels:
    role: vpnclient
    environment: production
spec:
  interfaceName: "*"
  node: kube-02
  expectedIPs: ["172.176.176.2"]
---
apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: vpn-rules
spec:
  selector: "role == 'vpnclient'"
  order: 0
  applyOnForward: true
  preDNAT: true
  ingress:
  - action: Deny
    protocol: TCP
    destination:
      ports: [6379]
  - action: Allow
    protocol: UDP
    destination:
      ports: [53, 67]

Siin on rangelt keelatud ühendamine porti 6379, kuid samas on säilinud DNS-teenuse töö, mille toimimine kannatab reeglite koostamisel üsna tihti. Sest nagu eelnevalt mainitud, kehtib valiku korral vaikimisi keelav poliitika, kui ei öelda teisiti.

Summary

Seega võimaldab Calico laiendatud API paindlikult konfigureerida ja dünaamiliselt muuta suunamist klastris ja selle ümber. Üldiselt võib selle kasutamine tunduda nagu, et tulistatakse ubadega kanade pihta, ning L3-võrgu juurutamine BGP- ja IP-IP-tunnelitega näib monstruuosne lihtsustatud Kubernetes'i paigaldises tasapinnalises võrgus… Siiski on tööriist muus osas täiesti elujõuline ja kasulik.

Klastri isolatsiooni tagamine turvanõuete täitmiseks ei ole alati rakendatav, ja just sellistel juhtudel tuleb appi Calico (või sarnane lahendus). Artiklis toodud näited (pärast väikest kohandamist) on kasutusel mitmes meie klientide paigalduses AWS-is.

P.S.

Lugege ka meie blogist:

• «Kubernetesi võrgupoliitikate sissejuhatus turbespetsialistidele»;
• «Kubernetese võrgu ülesehituse illustreeritud juhend»: osa 1 ja 2 (võrgu mudel, ülekandevõrgud), osa 3 (teenused ja liikluse käsitlemine);
• «Container Networking Interface (CNI) — võrgu liidese ja standard Linuxi konteineritele».

Allikas: habr.com