Kubernetes-en sarerako Calico: aurkezpena eta esperientzia txiki bat

Artikuluaren helburua irakurlea Kubernetes-en sare-politikak eta sare-politikak kudeatzeko oinarriak ezagutaraztea da, baita gaitasun estandarrak zabaltzen dituen hirugarrenen Calico plugina ere. Bide horretan, konfiguratzeko erraztasuna eta ezaugarri batzuk erakutsiko dira gure esperientzia operatiboko adibide errealak erabiliz.

Kubernetes sareko tresnaren sarrera azkarra

Kubernetes kluster bat ezin da imajinatu sarerik gabe. Dagoeneko argitaratu ditugu haien oinarriei buruzko materialak: “Kubernetes-en sarean lan egiteko gida ilustratua"Eta"Kubernetes sareko politiken sarrera Segurtasun profesionalentzako'.

Artikulu honen testuinguruan, kontuan hartu behar da K8s bera ez dela edukiontzien eta nodoen arteko sare-konektibitatearen arduraduna: horretarako, hainbat CNI pluginak (Container Networking Interfazea). Kontzeptu honi buruz gehiago dugu ere esan zidaten.

Adibidez, plugin hauen artean ohikoena da flannel — Kluster-nodo guztien arteko sare-konektibitate osoa eskaintzen du nodo bakoitzean zubiak altxatuz, azpisare bat esleituz. Hala ere, irisgarritasun osoa eta arautu gabekoa ez da beti onuragarria. Klusterrean nolabaiteko isolamendu minimoa ziurtatzeko, beharrezkoa da suebakiaren konfigurazioan esku hartzea. Kasu orokorrean, CNI beraren kontrolpean jartzen da, eta horregatik iptables-en hirugarrenen esku-hartzeak gaizki interpreta daitezke edo guztiz baztertu daitezke.

Eta Kubernetes kluster batean sare-politiken kudeaketa antolatzeko "kutxatik kanpo" eskaintzen da NetworkPolicy APIa. Baliabide honek, hautatutako izen-espazioetan banatuta, aplikazio batetik bestera sarbidea bereizteko arauak izan ditzake. Gainera, erabilerraztasuna konfiguratzeko aukera ematen du pod, ingurune (izen-espazio) edo IP helbideen bloke jakin batzuen artean:

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

Hau ez da adibiderik primitiboena dokumentazio ofiziala baliteke behingoz sare-politiken funtzionamenduaren logika ulertzeko gogoa galarazi. Hala ere, oraindik saiatuko gara sare-politikak erabiliz trafiko-fluxuak prozesatzeko oinarrizko printzipioak eta metodoak ulertzen...

Logikoa da 2 trafiko mota egotea: podan sartzea (Ingress) eta bertatik irtetea (Egress).

Izan ere, politika bi kategoria hauetan banatzen da mugimenduaren norabidearen arabera.

Beharrezko hurrengo atributua hautatzailea da; araua aplikatzen zaionari. Hau pod bat (edo pods talde bat) edo ingurune bat (hau da, izen-espazio bat) izan daiteke. Xehetasun garrantzitsu bat: bi objektu mota hauek etiketa bat izan behar dute (etiketa Kubernetes terminologian) - hauek dira politikariek funtzionatzen dutenekin.

Etiketa motaren batek batzen dituen hautatzaile kopuru finitu batez gain, "Baimendu/ukatu dena/denoi" bezalako arauak alda daitezke aldaera ezberdinetan. Horretarako, formako eraikuntzak erabiltzen dira:

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

— Adibide honetan, inguruneko pod guztiak blokeatu egiten dira sarrerako trafikotik. Kontrako portaera lor daiteke honako eraikuntza honekin:

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

Era berean, irteerarako:

  podSelector: {}
  policyTypes:
  - Egress

- itzaltzeko. Eta hona hemen zer sartu behar den:

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

CNI plugin baten aukeraketara itzuliz, kluster baterako, aipatzekoa da sareko plugin guztiek ez dute NetworkPolicy onartzen. Adibidez, lehen aipatutako Flannel-ek ez daki sare-politikak nola konfiguratu, zein zuzenean esaten da biltegi ofizialean. Alternatiba bat ere aipatzen da hor - Open Source proiektu bat Calico, eta horrek nabarmen zabaltzen du Kubernetes APIen multzo estandarra sare-politikei dagokienez.

Calico ezagutzea: teoria

Calico plugina Flannel-ekin (azpiproiektua) integratzeko erabil daiteke Canal) edo modu independentean, sareko konektagarritasuna eta erabilgarritasuna kudeatzeko gaitasunak barne hartuta.

Zer aukera ematen du K8s "kutxadun" irtenbidea eta Calicoren API multzoa erabiltzeak?

Hona hemen NetworkPolicy-n integratutakoa:

• politikariak ingurumenak mugatzen ditu;
• politikak etiketaz markatutako leketan aplikatzen dira;
• arauak pod, ingurune edo azpisareetan aplika daitezke;
• arauek protokoloak, portuen zehaztapen izendunak edo sinbolikoak izan ditzakete.

Hona hemen Calicok funtzio hauek nola zabaltzen dituen:

• politikak edozein objekturi aplika dakizkioke: leka, edukiontzi, makina birtuala edo interfazea;
• arauek ekintza zehatz bat izan dezakete (debekua, baimena, erregistroa);
• arauen xedea edo iturria portu bat, portu sorta bat, protokoloak, HTTP edo ICMP atributuak, IP edo azpisarea (4. edo 6. belaunaldia), edozein hautatzaileak (nodoak, ostalariak, inguruneak) izan daitezke;
• Gainera, trafikoaren joan-etorria erregula dezakezu DNAT ezarpenak eta trafikoa birbidaltzeko politikak erabiliz.

GitHub-en Calico biltegiko lehen konpromisoak 2016ko uztailekoak dira, eta urtebete geroago proiektuak lidergo postua hartu zuen Kubernetes sareko konektibitatea antolatzeko - hori frogatzen dute, adibidez, inkestaren emaitzek. The New Stack-ek zuzenduta:

K8s-ekin kudeatutako soluzio handi asko, esaterako Amazon EKS, Azure AKS, Google GKE eta beste batzuk erabiltzeko gomendatzen hasi ziren.

Errendimenduari dagokionez, hemen dena bikaina da. Beren produktua probatzean, Calico garapen-taldeak errendimendu astronomikoa frogatu zuen, 50000 edukiontzi baino gehiago exekutatzen baititu 500 nodo fisikotan, segundoko 20 edukiontzi sortzeko abiadurarekin. Eskalatzeko arazorik ez da identifikatu. Horrelako emaitzak iragarri ziren lehen bertsioaren iragarpenean jada. Errendimenduan eta baliabideen kontsumoan zentratzen diren ikerketa independenteek Calicoren errendimendua Flannel-en bezain ona dela baieztatzen dute. Adibidez:

Proiektua oso azkar garatzen ari da, K8s, OpenShift, OpenStack kudeatutako soluzio ezagunetan lana onartzen du, Calico erabil daiteke kluster bat zabaltzen denean. kops, badaude Service Mesh sareen eraikuntzari buruzko erreferentziak (hona hemen adibide bat Istiorekin batera erabilia).

Praktikatu Calico-rekin

Vanilla Kubernetes erabiltzearen kasu orokorrean, CNI instalatzea fitxategia erabiltzean datza calico.yaml, webgune ofizialetik deskargatu, erabiliz kubectl apply -f.

Oro har, pluginaren egungo bertsioa Kubernetesen azken 2-3 bertsioekin bateragarria da: bertsio zaharretako funtzionamendua ez da probatzen eta ez dago bermatuta. Garatzaileen arabera, Calico 3.10etik gorako Linux nukleoetan exekutatzen da CentOS 7, Ubuntu 16 edo Debian 8, iptables edo IPVS-en gainean.

Inguruaren barruan isolamendua

Ulermen orokorra lortzeko, ikus dezagun kasu sinple bat Calico idazkeran sare-politikak nola desberdintzen diren ulertzeko eta arauak sortzeko ikuspegiak irakurgarritasuna eta konfigurazio-malgutasuna nola errazten dituen ulertzeko:

Klusterrean 2 web aplikazio zabalduta daude: Node.js eta PHP-n, horietako batek Redis erabiltzen du. PHP-tik Redis-erako sarbidea blokeatzeko, Node.js-ekin konektagarritasuna mantenduz, aplikatu hurrengo politika:

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

Funtsean, sarrerako trafikoa baimendu genuen Redis ataka Node.js-etik. Eta argi eta garbi ez zuten beste ezer debekatu. NetworkPolicy agertu bezain laster, bertan aipatzen diren hautatzaile guztiak isolatzen hasten dira, kontrakoa zehaztu ezean. Hala ere, isolamendu-arauak ez dira aplikatzen hautatzaileak jasotzen ez dituen beste objektu batzuei.

Adibideak erabiltzen ditu apiVersion Kubernetes kaxatik kanpo, baina ezerk ez dizu eragozten erabiltzea Calico entregatik izen bereko baliabidea. Bertan dagoen sintaxia zehatzagoa da, beraz, goiko kasurako araua berridatzi beharko duzu forma honetan:

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

NetworkPolicy API arruntaren bidez trafiko guztia baimendu edo ukatzeko aipatutako eraikuntzak parentesiekin ulertzen eta gogoratzen zailak diren eraikuntzak dituzte. Calicoren kasuan, suebakiaren arau baten logika alderantziz aldatzeko, aldatu besterik ez dago action: Allow on action: Deny.

Inguruaren araberako isolamendua

Orain imajinatu egoera bat non aplikazio batek Prometheus-en biltzeko negozio-neurriak sortzen dituen eta Grafana erabiliz aztertzeko. Kargatzeak datu sentikorrak izan ditzake, lehenespenez berriro publikoki ikus daitezkeenak. Ezkuta ditzagun datu hauek begirik gabeko begietatik:

Prometheus, oro har, zerbitzu-ingurune bereizi batean jartzen da - adibidean honelako izen-espazio bat izango da:

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

Field metadata.labels hau ez zen istripua izan. Goian esan bezala, namespaceSelector (baita podSelector) etiketekin funtzionatzen du. Hori dela eta, ataka zehatz bateko ontzi guztietatik neurketak hartu ahal izateko, etiketa moduko bat gehitu beharko duzu (edo daudenetatik hartu), eta, ondoren, honelako konfigurazio bat aplikatu:

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

Eta Calico politikak erabiltzen badituzu, sintaxia hau izango 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

Oro har, behar zehatzetarako politika mota hauek gehituz gero, klusterreko aplikazioen funtzionamenduan interferentzia gaizto edo ustekabeetatik babes dezakezu.

Praktika onena, Calicoren sortzaileen arabera, "Blokeatu dena eta ireki behar duzuna esplizituki" ikuspegia da, dokumentuan dokumentatua. dokumentazio ofiziala (beste batzuek antzeko ikuspegia jarraitzen dute - bereziki, in lehen aipatutako artikulua).

Calico Objektu gehigarriak erabiltzea

Gogorarazten dizut Calico APIen multzo hedatuaren bidez nodoen erabilgarritasuna arautu dezakezula, ez podetara mugatu. Hurrengo adibidean erabiliz GlobalNetworkPolicy klusterrean ICMP eskaerak pasatzeko gaitasuna itxita dago (adibidez, ping-ak pod batetik nodo batera, pod artean edo nodo batetik IP pod batera):

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

Goiko kasuan, oraindik posible da klusterreko nodoek elkarrengana "heltzea" ICMP bidez. Eta arazo hau bideen bidez konpontzen da GlobalNetworkPolicy, entitate bati aplikatuta 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 kasua

Azkenik, Calico funtzioak erabiltzearen adibide oso erreal bat emango dut kluster hurbileko elkarrekintzaren kasuan, politika-multzo estandar bat nahikoa ez denean. Web-aplikaziora sartzeko, bezeroek VPN tunel bat erabiltzen dute, eta sarbide hori zorrotz kontrolatuta dago eta erabiltzeko baimendutako zerbitzuen zerrenda zehatz batera mugatuta dago:

Bezeroak VPNra konektatzen dira 1194 UDP ataka estandarraren bidez eta, konektatzen direnean, pods eta zerbitzuen kluster azpisareetarako ibilbideak jasotzen dituzte. Azpisare osoak bultzatzen dira, berrabiarazi eta helbideak aldatzean zerbitzuak ez galtzeko.

Konfigurazioko ataka estandarra da, eta horrek ñabardura batzuk ezartzen ditu aplikazioa konfiguratzeko eta Kubernetes klusterera transferitzeko prozesuan. Esate baterako, UDP-rako AWS LoadBalancer berean iazko amaieran agertu zen literalki eskualdeen zerrenda mugatu batean, eta NodePort ezin da erabili kluster nodo guztietan birbidaltzen duelako eta ezinezkoa da zerbitzariaren instantzia kopurua eskalatu. akatsen tolerantzia helburu. Gainera, ataken sorta lehenetsia aldatu beharko duzu...

Irtenbide posibleak bilatu ondoren, honako hau aukeratu da:

1. VPN duten pod-ak nodo bakoitzeko programatzen dira hostNetwork, hau da, benetako IPra.
2. Zerbitzua kanpoan argitaratzen da ClusterIP. Portu bat fisikoki instalatuta dago nodoan, kanpotik eskura daitekeen erreserba txikiekin (IP helbide erreal baten presentzia baldintzatua).
3. Leka hazten den nodoa zehaztea gure istorioaren esparrutik kanpo dago. Besterik gabe, esango dut zerbitzua nodo batean ondo "iltzatu" dezakezula edo VPN zerbitzuaren uneko IP helbidea kontrolatuko duen alboko zerbitzu txiki bat idatzi eta bezeroekin erregistratutako DNS erregistroak editatuko dituena - irudimen nahikoa duenak.

Bideratze-ikuspegitik, VPN bezero bat VPN zerbitzariak emandako IP helbidearen arabera identifika dezakegu. Jarraian, horrelako bezero baten zerbitzuetarako sarbidea mugatzeko adibide primitibo bat dago, goian aipatutako Redis-an ilustratua:

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]

Hemen, 6379 atakara konektatzea guztiz debekatuta dago, baina, aldi berean, DNS zerbitzuaren funtzionamendua mantentzen da, zeinaren funtzionamendua sarritan jasaten du arauak idaztean. Zeren eta, lehen esan bezala, hautatzaile bat agertzen denean, ukatze-politika lehenetsia aplikatzen zaio bestela zehaztu ezean.

Emaitzak

Horrela, Calicoren API aurreratua erabiliz, malgutasunez konfiguratu eta dinamikoki alda ditzakezu bideraketa klusterrean eta inguruan. Orokorrean, bere erabilerak kanoi batekin txolarreak jaurtitzea bezalakoa izan daiteke, eta BGP eta IP-IP tunelekin L3 sare bat ezartzeak izugarrizko itxura ematen du Kubernetes instalazio soil batean sare lau batean... Hala ere, bestela tresnak nahiko bideragarria eta erabilgarria dirudi. .

Segurtasun-baldintzak betetzeko kluster bat isolatzea agian ez da beti bideragarria izango, eta hortik dator Calico (edo antzeko irtenbide bat) erreskatatzera. Artikulu honetan emandako adibideak (aldaketa txikiekin) gure bezeroen AWSko hainbat instalaziotan erabiltzen dira.

PS

Irakurri ere gure blogean:

• «Kubernetes sareko politiken sarrera Segurtasun profesionalentzako»;
• "Kubernetes-en sareak egiteko gida ilustratua": 1. eta 2. zatiak (sare-eredua, gainjarritako sareak), 3. zatia (zerbitzuak eta trafikoaren tratamendua);
• «Container Networking Interface (CNI) - sareko interfazea eta estandarra Linux edukiontzietarako'.

Iturria: www.habr.com