ProHoster > Blogs > Administrācija > Calico tīkla izveidei Kubernetes: ievads un neliela pieredze

Calico tīkla izveidei Kubernetes: ievads un neliela pieredze

Calico tīkla izveidei Kubernetes: ievads un neliela pieredze

Raksta mērÄ·is ir iepazÄ«stināt lasÄ«tāju ar tÄ«kla veidoÅ”anas un tÄ«kla politiku pārvaldÄ«bas pamatiem Kubernetes, kā arÄ« ar treŔās puses Calico spraudni, kas paplaÅ”ina standarta iespējas. Pa ceļam konfigurācijas vienkārŔība un dažas funkcijas tiks demonstrētas, izmantojot reālus piemērus no mÅ«su darbÄ«bas pieredzes.

ÄŖss ievads par Kubernetes tÄ«kla ierÄ«ci

Kubernetes klasteris nav iedomājams bez tÄ«kla. Mēs jau esam publicējuÅ”i materiālus par viņu pamatiem: ā€œIlustrēts ceļvedis Kubernetes tÄ«kla izveidei"Un"Ievads par Kubernetes tÄ«kla politikām droŔības profesionāļiem'.

Å Ä« raksta kontekstā ir svarÄ«gi atzÄ«mēt, ka pats K8s nav atbildÄ«gs par tÄ«kla savienojamÄ«bu starp konteineriem un mezgliem: Å”im nolÅ«kam CNI spraudņi (Container Networking Interface). Vairāk par Å”o koncepciju mēs viņi man arÄ« teica.

Piemēram, visizplatÄ«tākais no Å”iem spraudņiem ir Flaneļa ā€” nodroÅ”ina pilnu tÄ«kla savienojumu starp visiem klastera mezgliem, paceļot tiltus katrā mezglā, pieŔķirot tam apakÅ”tÄ«klu. Tomēr pilnÄ«ga un neregulēta pieejamÄ«ba ne vienmēr ir izdevÄ«ga. Lai nodroÅ”inātu zināmu minimālu izolāciju klasterÄ«, ir jāiejaucas ugunsmÅ«ra konfigurācijā. VispārÄ«gā gadÄ«jumā tas tiek pakļauts viena un tā paÅ”a CNI kontrolei, tāpēc jebkura treŔās puses iejaukÅ”anās iptables var tikt interpretēta nepareizi vai vispār ignorēta.

Un tiek nodroÅ”ināta ā€œno kastesā€ tÄ«kla politikas pārvaldÄ«bas organizÄ“Å”anai Kubernetes klasterÄ« NetworkPolicy API. Å is resurss, kas ir sadalÄ«ts atlasÄ«tajās nosaukumvietās, var saturēt noteikumus, lai atŔķirtu vienas lietojumprogrammas piekļuvi citai. Tas arÄ« ļauj konfigurēt pieejamÄ«bu starp noteiktiem podiem, vidēm (nosaukumvietām) vai IP adreÅ”u blokiem:

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

Šis nav primitīvākais piemērs oficiālā dokumentācija var vienreiz un uz visiem atturēt vēlmi izprast tīkla politikas darbības loģiku. Tomēr mēs joprojām mēģināsim izprast trafika plūsmu apstrādes pamatprincipus un metodes, izmantojot tīkla politikas...

Loģiski, ka ir 2 trafika veidi: ienākoŔā (Ingress) un izejoŔā no tā (Egress).

Calico tīkla izveidei Kubernetes: ievads un neliela pieredze

Faktiski politika ir sadalīta Ŕajās 2 kategorijās, pamatojoties uz kustības virzienu.

Nākamais nepiecieÅ”amais atribÅ«ts ir selektors; tas, uz kuru attiecas noteikums. Tas var bÅ«t aplikums (vai aplikumu grupa) vai vide (t.i., nosaukumvieta). SvarÄ«ga detaļa: abiem Å”o objektu veidiem ir jābÅ«t etiÄ·etei (etiÄ·ete Kubernetes terminoloÄ£ijā) - ar tiem politiÄ·i operē.

Papildus ierobežotam skaitam atlasÄ«tāju, ko apvieno kāda veida etiÄ·ete, dažādās variācijās ir iespējams rakstÄ«t noteikumus, piemēram, ā€œAtļaut/liegt visu/visiemā€. Å im nolÅ«kam tiek izmantotas formas konstrukcijas:

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

ā€” Å”ajā piemērā visi apgabali vidē ir bloķēti ienākoÅ”ajai satiksmei. Pretēju uzvedÄ«bu var panākt ar Ŕādu konstrukciju:

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

Līdzīgi izejoŔajiem:

  podSelector: {}
  policyTypes:
  - Egress

- lai to izslēgtu. Lūk, kas jāiekļauj:

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

Atgriežoties pie CNI spraudņa izvēles klasterim, ir vērts to atzÄ«mēt ne katrs tÄ«kla spraudnis atbalsta NetworkPolicy. Piemēram, jau pieminētais Flanel neprot konfigurēt tÄ«kla politikas, kuras tas teikts tieÅ”i oficiālajā repozitorijā. Tur ir minēta arÄ« alternatÄ«va - Open Source projekts Calico, kas ievērojami paplaÅ”ina Kubernetes API standarta komplektu tÄ«kla politiku ziņā.

Calico tīkla izveidei Kubernetes: ievads un neliela pieredze

IepazīŔanās ar Calico: teorija

Calico spraudni var izmantot integrācijā ar Flannel (apakÅ”projekts Kanāls) vai neatkarÄ«gi, aptverot gan tÄ«kla savienojamÄ«bas, gan pieejamÄ«bas pārvaldÄ«bas iespējas.

Kādas iespējas sniedz K8s ā€œkastesā€ risinājuma un API komplekta izmantoÅ”ana no Calico?

Lūk, kas ir iebūvēts NetworkPolicy:

  • politiÄ·us ierobežo vide;
  • politikas tiek piemērotas pākstÄ«m, kas marķētas ar etiÄ·etēm;
  • noteikumus var piemērot podiem, vidēm vai apakÅ”tÄ«kliem;
  • noteikumi var saturēt protokolus, nosauktas vai simboliskas portu specifikācijas.

Lūk, kā Calico paplaŔina Ŕīs funkcijas:

  • politikas var tikt piemērotas jebkuram objektam: podam, konteineram, virtuālajai maŔīnai vai interfeisam;
  • noteikumi var ietvert konkrētu darbÄ«bu (aizliegumu, atļauju, reÄ£istrÄ“Å”anu);
  • noteikumu mērÄ·is vai avots var bÅ«t ports, portu diapazons, protokoli, HTTP vai ICMP atribÅ«ti, IP vai apakÅ”tÄ«kls (4. vai 6. paaudze), jebkuri atlasÄ«tāji (mezgli, saimnieki, vides);
  • Turklāt jÅ«s varat regulēt trafika pāreju, izmantojot DNAT iestatÄ«jumus un trafika pāradresācijas politikas.

Pirmās saistÄ«bas GitHub Calico repozitorijā datētas ar 2016. gada jÅ«liju, un gadu vēlāk projekts ieņēma vadoŔās pozÄ«cijas Kubernetes tÄ«kla savienojamÄ«bas organizÄ“Å”anā ā€“ par to liecina, piemēram, aptaujas rezultāti, diriģēja The New Stack:

Calico tīkla izveidei Kubernetes: ievads un neliela pieredze

Daudzi lieli pārvaldÄ«ti risinājumi ar K8, piemēram Amazon EX, Azure AKS, Google GKE un citi sāka ieteikt to lietoÅ”anai.

Runājot par veiktspēju, Å”eit viss ir lieliski. Pārbaudot savu produktu, Calico izstrādes komanda demonstrēja astronomisku veiktspēju, darbinot vairāk nekā 50000 500 konteineru 20 fiziskos mezglos ar izveides ātrumu XNUMX konteineri sekundē. Ar mērogoÅ”anu netika konstatētas nekādas problēmas. Tādi rezultāti tika paziņoti jau pie pirmās versijas izziņoÅ”anas. NeatkarÄ«gi pētÄ«jumi, kas koncentrējas uz caurlaidspēju un resursu patēriņu, arÄ« apstiprina, ka Calico veiktspēja ir gandrÄ«z tikpat laba kā Flannel. Piemēram:

Calico tīkla izveidei Kubernetes: ievads un neliela pieredze

Projekts attÄ«stās ļoti ātri, tas atbalsta darbu populāros risinājumos, kas tiek pārvaldÄ«ti K8s, OpenShift, OpenStack, ir iespējams izmantot Calico, izvietojot klasteru, izmantojot sitiens, ir atsauces uz Service Mesh tÄ«klu izveidi (Å”eit ir piemērs lieto kopā ar Istio).

Trenējies ar Calico

Parasti vaniļas Kubernetes izmantoÅ”anas gadÄ«jumā CNI instalÄ“Å”ana ir saistÄ«ta ar faila izmantoÅ”anu calico.yaml, lejupielādēts no oficiālās vietnes, izmantojot kubectl apply -f.

Kā likums, paÅ”reizējā spraudņa versija ir saderÄ«ga ar jaunākajām 2-3 Kubernetes versijām: darbÄ«ba vecākās versijās netiek pārbaudÄ«ta un netiek garantēta. Saskaņā ar izstrādātāju teikto, Calico darbojas uz Linux kodoliem virs 3.10, kuros darbojas CentOS 7, Ubuntu 16 vai Debian 8, papildus iptables vai IPVS.

Izolācija vidē

VispārÄ«gai izpratnei apskatÄ«sim vienkārÅ”u gadÄ«jumu, lai saprastu, kā tÄ«kla politikas Calico apzÄ«mējumā atŔķiras no standarta un kā kārtulu izveides pieeja vienkārÅ”o to lasāmÄ«bu un konfigurācijas elastÄ«bu:

Calico tīkla izveidei Kubernetes: ievads un neliela pieredze

KlasterÄ« ir izvietotas 2 tÄ«mekļa lietojumprogrammas: Node.js un PHP, no kurām viena izmanto Redis. Lai bloķētu piekļuvi Redis no PHP, vienlaikus saglabājot savienojumu ar Node.js, vienkārÅ”i piemērojiet Å”o politiku:

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

BÅ«tÄ«bā mēs atļāvām ienākoÅ”o trafiku uz Redis portu no Node.js. Un viņi skaidri neko citu neaizliedza. TiklÄ«dz parādās NetworkPolicy, visi tajā minētie atlasÄ«tāji tiek izolēti, ja vien nav norādÄ«ts citādi. Tomēr izolācijas noteikumi neattiecas uz citiem objektiem, kas nav ietverti atlasÄ«tājā.

Piemērā izmanto apiVersion Kubernetes ir izņemts no kastes, taču nekas neliedz to izmantot tāda paÅ”a nosaukuma resurss no Calico piegādes. Sintakse ir detalizētāka, tāpēc jums bÅ«s jāpārraksta noteikums iepriekÅ”minētajam gadÄ«jumam Ŕādā formā:

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

IepriekÅ” minētās konstrukcijas visas trafika atļauÅ”anai vai aizliegÅ”anai, izmantojot parasto NetworkPolicy API, satur konstrukcijas ar iekavām, kuras ir grÅ«ti saprast un atcerēties. Calico gadÄ«jumā, lai mainÄ«tu ugunsmÅ«ra noteikuma loÄ£iku uz pretējo, vienkārÅ”i mainiet action: Allow par action: Deny.

Izolācija no vides

Tagad iedomājieties situāciju, kad lietojumprogramma Ä£enerē biznesa rādÄ«tājus apkopoÅ”anai programmā Prometheus un turpmākai analÄ«zei, izmantojot Grafana. AugÅ”upielāde var saturēt sensitÄ«vus datus, kas pēc noklusējuma atkal ir publiski skatāmi. Paslēpsim Å”os datus no ziņkārÄ«go acÄ«m:

Calico tīkla izveidei Kubernetes: ievads un neliela pieredze

Prometheus, kā likums, tiek ievietots atseviŔķā pakalpojumu vidē - piemērā tā bÅ«s Ŕāda nosaukumvieta:

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

Lauks metadata.labels izrādÄ«jās, ka tā nav nejauŔība. Kā iepriekÅ” minēts, namespaceSelector (kā arÄ« podSelector) darbojas ar etiÄ·etēm. Tāpēc, lai ļautu iegÅ«t metriku no visiem konkrēta porta apgabaliem, jums bÅ«s jāpievieno sava veida etiÄ·ete (vai jāņem no esoÅ”ajām) un pēc tam jāpiemēro konfigurācija, piemēram:

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

Un, ja izmantojat Calico politikas, sintakse būs Ŕāda:

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

Parasti, pievienojot Ŕāda veida politikas īpaŔām vajadzībām, varat aizsargāt pret ļaunprātīgu vai nejauŔu iejaukŔanos klastera lietojumprogrammu darbībā.

Pēc Calico veidotāju domām, labākā prakse ir pieeja ā€œBloķējiet visu un skaidri atveriet to, kas jums nepiecieÅ”amsā€, kas dokumentēta oficiālā dokumentācija (citi izmanto lÄ«dzÄ«gu pieeju - jo Ä«paÅ”i, in jau pieminētais raksts).

Papildu Calico objektu izmantoŔana

AtgādināŔu, ka, izmantojot paplaÅ”ināto Calico API komplektu, varat regulēt mezglu pieejamÄ«bu, ne tikai podi. Nākamajā piemērā, izmantojot GlobalNetworkPolicy iespēja nodot ICMP pieprasÄ«jumus klasterÄ« ir aizvērta (piemēram, ping no apoka uz mezglu, starp podiem vai no mezgla uz IP pod):

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

IepriekÅ” minētajā gadÄ«jumā klasteru mezgli joprojām var ā€œsasniegtā€ viens otru, izmantojot ICMP. Un Å”is jautājums tiek atrisināts ar lÄ«dzekļiem GlobalNetworkPolicy, attiecas uz entÄ«tiju 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"]

VPN lieta

Visbeidzot, es sniegÅ”u ļoti reālu piemēru Calico funkciju izmantoÅ”anai gandrÄ«z klastera mijiedarbÄ«bas gadÄ«jumā, kad nepietiek ar standarta politiku kopu. Lai piekļūtu tÄ«mekļa lietojumprogrammai, klienti izmanto VPN tuneli, un Ŕī piekļuve tiek stingri kontrolēta un ierobežota ar noteiktu pakalpojumu sarakstu, kas atļauts izmantot:

Calico tīkla izveidei Kubernetes: ievads un neliela pieredze

Klienti savienojas ar VPN, izmantojot standarta UDP portu 1194, un, kad ir izveidots savienojums, tie saņem marÅ”rutus uz podziņu un pakalpojumu klasteru apakÅ”tÄ«kliem. Visi apakÅ”tÄ«kli tiek virzÄ«ti, lai restartÄ“Å”anas un adreÅ”u maiņas laikā nezaudētu pakalpojumus.

Konfigurācijas ports ir standarta, kas uzliek dažas nianses lietojumprogrammas konfigurÄ“Å”anas un pārsÅ«tÄ«Å”anas uz Kubernetes klasteru procesā. Piemēram, tajā paŔā AWS LoadBalancer for UDP parādÄ«jās burtiski pagājuŔā gada beigās ierobežotā reÄ£ionu sarakstā, un NodePort nevar izmantot, jo tas tiek pārsÅ«tÄ«ts visos klastera mezglos un nav iespējams mērogot servera gadÄ«jumu skaitu kļūdu tolerances nolÅ«kos. Turklāt jums bÅ«s jāmaina noklusējuma portu diapazons...

Iespējamo risinājumu meklÄ“Å”anas rezultātā tika izvēlēts sekojoÅ”ais:

  1. Pods ar VPN ir ieplānots katram mezglam hostNetwork, tas ir, uz faktisko IP.
  2. Pakalpojums tiek izlikts ārpus caur ClusterIP. Mezglā ir fiziski uzstādīts ports, kuram var piekļūt no ārpuses ar nelielām atrunām (reālas IP adreses nosacīta klātbūtne).
  3. MÅ«su stāsta ietvaros nav iespējams noteikt mezglu, uz kura pāksts roze. Es tikai teikÅ”u, ka jÅ«s varat cieÅ”i ā€œpiespraustā€ pakalpojumu mezglam vai uzrakstÄ«t nelielu blakusvāģa pakalpojumu, kas uzraudzÄ«s paÅ”reizējo VPN pakalpojuma IP adresi un rediģēs klientiem reÄ£istrētos DNS ierakstus - kuram ir pietiekami daudz iztēles.

No marÅ”rutÄ“Å”anas viedokļa mēs varam unikāli identificēt VPN klientu pēc tā IP adreses, ko izsniedzis VPN serveris. Tālāk ir sniegts primitÄ«vs piemērs Ŕāda klienta piekļuves pakalpojumiem ierobežoÅ”anai, kas parādÄ«ts iepriekÅ” minētajā Redis:

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]

Å eit ir stingri aizliegts pieslēgties portam 6379, bet tajā paŔā laikā tiek saglabāta DNS pakalpojuma darbÄ«ba, kuras darbÄ«ba diezgan bieži cieÅ”, izstrādājot noteikumus. Tā kā, kā minēts iepriekÅ”, kad tiek parādÄ«ts atlasÄ«tājs, tam tiek piemērota noklusējuma aizlieguma politika, ja vien nav norādÄ«ts citādi.

Rezultāti

Tādējādi, izmantojot Calico uzlaboto API, varat elastÄ«gi konfigurēt un dinamiski mainÄ«t marÅ”rutÄ“Å”anu klasterÄ« un ap to. Kopumā tā lietoÅ”ana var izskatÄ«ties pēc zvirbuļu Å”auÅ”anas ar lielgabalu, un L3 tÄ«kla ievieÅ”ana ar BGP un IP-IP tuneļiem vienkārŔā Kubernetes instalācijā plakanā tÄ«klā izskatās zvērÄ«gi... Tomēr citādi rÄ«ks izskatās diezgan dzÄ«votspējÄ«gs un noderÄ«gs. .

Klastera izolÄ“Å”ana, lai tā atbilstu droŔības prasÄ«bām, ne vienmēr var bÅ«t iespējama, un Å”eit palÄ«gā nāk Calico (vai lÄ«dzÄ«gs risinājums). Å ajā rakstā sniegtie piemēri (ar nelielām izmaiņām) tiek izmantoti vairākās mÅ«su klientu instalācijās AWS.

PS

Lasi arī mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru