Calico ya mtandao katika Kubernetes: utangulizi na uzoefu kidogo

Madhumuni ya makala ni kumjulisha msomaji misingi ya mitandao na kudhibiti sera za mtandao katika Kubernetes, pamoja na programu-jalizi ya wahusika wengine ya Calico ambayo huongeza uwezo wa kawaida. Kwa njia hii, urahisi wa usanidi na baadhi ya vipengele vitaonyeshwa kwa kutumia mifano halisi kutoka kwa uzoefu wetu wa uendeshaji.

Utangulizi wa haraka wa kifaa cha mtandao cha Kubernetes

Nguzo ya Kubernetes haiwezi kufikiria bila mtandao. Tayari tumechapisha nyenzo kwa misingi yao: "Mwongozo ulioonyeshwa wa mitandao katika Kubernetes"Na"Utangulizi wa Sera za Mtandao wa Kubernetes kwa Wataalamu wa Usalama'.

Katika muktadha wa kifungu hiki, ni muhimu kutambua kwamba K8s yenyewe haina jukumu la uunganisho wa mtandao kati ya vyombo na nodi: kwa hili, anuwai. Programu jalizi za CNI (Kiolesura cha Mtandao wa Kontena). Zaidi kuhusu dhana hii sisi pia waliniambia.

Kwa mfano, ya kawaida ya programu-jalizi hizi ni Flannel - hutoa muunganisho kamili wa mtandao kati ya nodi zote za nguzo kwa kuinua madaraja kwenye kila nodi, ikiweka subnet kwake. Hata hivyo, ufikiaji kamili na usio na udhibiti sio manufaa kila wakati. Ili kuhakikisha aina fulani ya kutengwa kidogo katika nguzo, ni muhimu kuingilia kati katika usanidi wa firewall. Katika hali ya jumla, imewekwa chini ya udhibiti wa CNI sawa, ndiyo sababu uingiliaji wowote wa tatu katika iptables unaweza kutafsiriwa vibaya au kupuuzwa kabisa.

Na "nje ya boksi" kwa ajili ya kupanga usimamizi wa sera za mtandao katika kundi la Kubernetes hutolewa NetworkPolicy API. Nyenzo hii, iliyosambazwa juu ya nafasi za majina zilizochaguliwa, inaweza kuwa na sheria za kutofautisha ufikiaji kutoka kwa programu moja hadi nyingine. Pia hukuruhusu kusanidi ufikiaji kati ya maganda maalum, mazingira (nafasi za majina) au vizuizi vya anwani za IP:

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

Huu sio mfano wa zamani zaidi nyaraka rasmi inaweza mara moja na kwa wote kukatisha tamaa ya kuelewa mantiki ya jinsi sera za mtandao hufanya kazi. Hata hivyo, bado tutajaribu kuelewa kanuni za msingi na mbinu za kuchakata mtiririko wa trafiki kwa kutumia sera za mtandao...

Ni sawa kwamba kuna aina 2 za trafiki: kuingia kwenye ganda (Ingress) na kutoka kwayo (Egress).

Kweli, siasa imegawanywa katika makundi haya 2 kulingana na mwelekeo wa harakati.

Sifa inayofuata inayohitajika ni kiteuzi; yule ambaye sheria hiyo inatumika kwake. Hii inaweza kuwa ganda (au kundi la maganda) au mazingira (yaani nafasi ya majina). Maelezo muhimu: aina zote mbili za vitu hivi lazima ziwe na lebo (studio katika istilahi za Kubernetes) - hizi ndizo ambazo wanasiasa hufanya kazi nazo.

Mbali na idadi maalum ya viteuzi, vilivyounganishwa na aina fulani ya lebo, inawezekana kuandika sheria kama vile "Ruhusu/katalia kila kitu/kila mtu" katika tofauti tofauti. Kwa kusudi hili, ujenzi wa fomu hutumiwa:

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

- katika mfano huu, maganda yote katika mazingira yamezuiwa kutoka kwa trafiki inayoingia. Tabia ya kinyume inaweza kupatikana kwa ujenzi ufuatao:

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

Vile vile kwa anayetoka:

  podSelector: {}
  policyTypes:
  - Egress

- kuizima. Na hii ndio ya kujumuisha:

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

Kurudi kwenye uchaguzi wa programu-jalizi ya CNI kwa nguzo, ni muhimu kuzingatia hilo sio kila programu-jalizi ya mtandao inasaidia NetworkPolicy. Kwa mfano, Flannel iliyotajwa tayari haijui jinsi ya kusanidi sera za mtandao, ambazo inasemwa moja kwa moja katika hazina rasmi. Njia mbadala pia imetajwa hapo - mradi wa Open Source Calico, ambayo huongeza kwa kiasi kikubwa seti ya kawaida ya API za Kubernetes kulingana na sera za mtandao.

Kujua Calico: nadharia

Programu-jalizi ya Calico inaweza kutumika kwa kuunganishwa na Flannel (subproject Channel) au kwa kujitegemea, inayofunika muunganisho wa mtandao na uwezo wa usimamizi wa upatikanaji.

Je, kutumia suluhisho la "boxed" la K8s na seti ya API kutoka Calico hutoa fursa gani?

Hii ndio iliyojumuishwa kwenye NetworkPolicy:

• wanasiasa wamewekewa mipaka na mazingira;
• sera zinatumika kwa maganda yaliyowekwa alama;
• sheria zinaweza kutumika kwa maganda, mazingira au subnets;
• sheria zinaweza kuwa na itifaki, zilizopewa jina au vipimo vya bandari vya ishara.

Hivi ndivyo Calico inavyopanua kazi hizi:

• sera zinaweza kutumika kwa kitu chochote: ganda, chombo, mashine pepe au kiolesura;
• sheria zinaweza kuwa na hatua maalum (marufuku, ruhusa, ukataji miti);
• lengo au chanzo cha sheria kinaweza kuwa bandari, bandari mbalimbali, itifaki, sifa za HTTP au ICMP, IP au subnet (kizazi cha 4 au cha 6), viteuzi vyovyote (nodi, majeshi, mazingira);
• Zaidi ya hayo, unaweza kudhibiti upitishaji wa trafiki kwa kutumia mipangilio ya DNAT na sera za usambazaji wa trafiki.

Ahadi ya kwanza kwenye GitHub kwenye hazina ya Calico ilianza Julai 2016, na mwaka mmoja baadaye mradi huo ulichukua nafasi ya kwanza katika kuandaa muunganisho wa mtandao wa Kubernetes - hii inathibitishwa, kwa mfano, na matokeo ya uchunguzi, iliyofanywa na The New Stack:

Suluhisho nyingi kubwa zinazosimamiwa na K8s, kama vile Amazon EKS, Azure AKS, Google GKE na wengine wakaanza kuipendekeza kwa matumizi.

Kuhusu utendaji, kila kitu ni nzuri hapa. Katika kujaribu bidhaa zao, timu ya ukuzaji wa Calico ilionyesha utendaji wa unajimu, ikiendesha zaidi ya kontena 50000 kwenye nodi 500 za kawaida zenye kiwango cha uundaji cha kontena 20 kwa sekunde. Hakuna matatizo yaliyotambuliwa na kuongeza. Matokeo kama hayo zilitangazwa tayari kwenye tangazo la toleo la kwanza. Masomo huru yanayozingatia matumizi na matumizi ya rasilimali pia yanathibitisha utendakazi wa Calico karibu sawa na wa Flannel. Kwa mfano:

Mradi unaendelea haraka sana, inasaidia kazi katika suluhisho maarufu zinazosimamiwa K8s, OpenShift, OpenStack, inawezekana kutumia Calico wakati wa kupeleka nguzo kwa kutumia. teke, kuna marejeleo ya ujenzi wa mitandao ya Service Mesh (hapa kuna mfano kutumika kwa kushirikiana na Istio).

Fanya mazoezi na Calico

Katika hali ya jumla ya kutumia vanilla Kubernetes, kusakinisha CNI kunakuja kwa kutumia faili calico.yaml, kupakuliwa kutoka kwa tovuti rasmi, kwa kutumia kubectl apply -f.

Kama sheria, toleo la sasa la programu-jalizi linaendana na matoleo ya hivi karibuni 2-3 ya Kubernetes: utendakazi katika matoleo ya zamani haujaribiwi na haujahakikishiwa. Kulingana na wasanidi programu, Calico hutumia kokwa za Linux zaidi ya 3.10 zinazoendesha CentOS 7, Ubuntu 16 au Debian 8, juu ya iptables au IPVS.

Kutengwa ndani ya mazingira

Kwa uelewa wa jumla, hebu tuangalie kesi rahisi ili kuelewa jinsi sera za mtandao katika nukuu ya Calico zinavyotofautiana na zile za kawaida na jinsi mbinu ya kuunda sheria hurahisisha usomaji wao na kunyumbulika kwa usanidi:

Kuna programu 2 za wavuti zilizowekwa kwenye nguzo: katika Node.js na PHP, ambayo moja hutumia Redis. Ili kuzuia ufikiaji wa Redis kutoka PHP, wakati unadumisha muunganisho na Node.js, tumia sera ifuatayo:

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

Kwa hakika tuliruhusu trafiki inayoingia kwenye bandari ya Redis kutoka Node.js. Na kwa wazi hawakukataza kitu kingine chochote. Mara tu NetworkPolicy inapoonekana, wateuzi wote waliotajwa ndani yake huanza kutengwa, isipokuwa ikiwa imeainishwa vinginevyo. Hata hivyo, sheria za kutengwa hazitumiki kwa vitu vingine ambavyo havijafunikwa na kiteuzi.

Mfano hutumia apiVersion Kubernetes nje ya boksi, lakini hakuna kinachokuzuia kuitumia rasilimali ya jina moja kutoka kwa utoaji wa Calico. Sintaksia hapo ina maelezo zaidi, kwa hivyo utahitaji kuandika upya sheria ya kesi iliyo hapo juu katika fomu ifuatayo:

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

Miundo iliyotajwa hapo juu ya kuruhusu au kukataa trafiki yote kupitia API ya kawaida ya NetworkPolicy ina miundo yenye mabano ambayo ni vigumu kuelewa na kukumbuka. Katika kesi ya Calico, kubadilisha mantiki ya sheria ya firewall kinyume chake, badilisha tu action: Allow juu ya action: Deny.

Kutengwa na mazingira

Sasa fikiria hali ambapo programu hutoa vipimo vya biashara kwa ajili ya kukusanywa katika Prometheus na uchanganuzi zaidi kwa kutumia Grafana. Upakiaji unaweza kuwa na data nyeti, ambayo inaonekana tena kwa umma kwa chaguomsingi. Wacha tufiche data hii kutoka kwa macho ya kutazama:

Prometheus, kama sheria, huwekwa katika mazingira tofauti ya huduma - kwa mfano itakuwa nafasi ya majina kama hii:

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

Shamba metadata.labels hii iligeuka kuwa sio bahati mbaya. Kama ilivyoelezwa hapo juu, namespaceSelector (pia podSelector) hufanya kazi na lebo. Kwa hivyo, ili kuruhusu vipimo kuchukuliwa kutoka kwa maganda yote kwenye mlango maalum, itabidi uongeze aina fulani ya lebo (au kuchukua kutoka kwa zilizopo), na kisha uweke usanidi kama:

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

Na ikiwa utatumia sera za Calico, syntax itakuwa kama hii:

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

Kwa ujumla, kwa kuongeza aina hizi za sera kwa mahitaji maalum, unaweza kulinda dhidi ya kuingiliwa kwa nia mbaya au kwa bahati mbaya katika utendakazi wa programu katika kundi.

Mbinu bora, kulingana na waundaji wa Calico, ni mbinu ya "Zuia kila kitu na ufungue kwa uwazi unachohitaji", iliyorekodiwa katika nyaraka rasmi (wengine hufuata mbinu kama hiyo - haswa, in makala iliyotajwa tayari).

Kutumia Vitu vya Ziada vya Calico

Acha nikukumbushe kwamba kupitia seti iliyopanuliwa ya API za Calico unaweza kudhibiti upatikanaji wa nodi, sio tu kwa maganda. Katika mfano ufuatao kwa kutumia GlobalNetworkPolicy uwezo wa kupitisha maombi ya ICMP kwenye nguzo imefungwa (kwa mfano, pings kutoka kwa ganda hadi nodi, kati ya maganda, au kutoka nodi hadi ganda la IP):

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

Katika kesi iliyo hapo juu, bado inawezekana kwa nodi za nguzo "kufikia" kwa kila mmoja kupitia ICMP. Na suala hili linatatuliwa kwa njia GlobalNetworkPolicy, inatumika kwa huluki 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"]

Kesi ya VPN

Mwishowe, nitatoa mfano halisi wa kutumia vitendaji vya Calico kwa kesi ya mwingiliano wa karibu wa nguzo, wakati seti ya kawaida ya sera haitoshi. Ili kufikia programu ya wavuti, wateja hutumia njia ya VPN, na ufikiaji huu unadhibitiwa kwa uthabiti na mdogo kwa orodha mahususi ya huduma zinazoruhusiwa kutumika:

Wateja huunganishwa kwenye VPN kupitia lango la kawaida la UDP 1194 na, linapounganishwa, hupokea njia hadi kwenye vikundi vidogo vya maganda na huduma. Subnet nzima husukumwa ili usipoteze huduma wakati wa kuanzisha upya na kubadilisha anwani.

Bandari katika usanidi ni ya kawaida, ambayo inaweka nuances kadhaa kwenye mchakato wa kusanidi programu na kuihamisha kwa nguzo ya Kubernetes. Kwa mfano, katika AWS LoadBalancer sawa ya UDP ilionekana halisi mwishoni mwa mwaka jana katika orodha ndogo ya mikoa, na NodePort haiwezi kutumika kwa sababu ya usambazaji wake kwenye nodi zote za nguzo na haiwezekani kuongeza idadi ya matukio ya seva kwa madhumuni ya uvumilivu wa makosa. Pia, itabidi ubadilishe safu chaguomsingi ya bandari...

Kama matokeo ya kutafuta suluhisho zinazowezekana, zifuatazo zilichaguliwa:

1. Maganda yaliyo na VPN yamepangwa kwa kila nodi ndani hostNetwork, yaani, kwa IP halisi.
2. Huduma inatumwa nje kupitia ClusterIP. Bandari imewekwa kimwili kwenye nodi, ambayo inapatikana kutoka nje na uhifadhi mdogo (uwepo wa masharti ya anwani halisi ya IP).
3. Kuamua nodi ambayo pod rose ni zaidi ya upeo wa hadithi yetu. Nitasema tu kwamba unaweza "kupigilia msumari" huduma kwa nodi au kuandika huduma ndogo ya kando ambayo itafuatilia anwani ya sasa ya IP ya huduma ya VPN na kuhariri rekodi za DNS zilizosajiliwa na wateja - yeyote ambaye ana mawazo ya kutosha.

Kwa mtazamo wa uelekezaji, tunaweza kutambua mteja wa VPN kwa njia ya kipekee kwa anwani yake ya IP iliyotolewa na seva ya VPN. Ufuatao ni mfano wa awali wa kuzuia ufikiaji wa mteja kama huyo kwa huduma, unaoonyeshwa kwenye Redis iliyotajwa hapo juu:

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]

Hapa, kuunganisha kwa bandari 6379 ni marufuku madhubuti, lakini wakati huo huo uendeshaji wa huduma ya DNS huhifadhiwa, utendaji ambao mara nyingi huteseka wakati wa kuunda sheria. Kwa sababu, kama ilivyotajwa hapo awali, kiteuzi kinapotokea, sera ya kukataa chaguomsingi inatumika kwake isipokuwa ikiwa imebainishwa vinginevyo.

Matokeo ya

Kwa hivyo, kwa kutumia API ya hali ya juu ya Calico, unaweza kusanidi kwa urahisi na kubadilisha uelekezaji ndani na karibu na nguzo. Kwa ujumla, matumizi yake yanaweza kuonekana kama shomoro wa risasi na kanuni, na kutekeleza mtandao wa L3 na vichuguu vya BGP na IP-IP inaonekana kuwa mbaya sana katika usakinishaji rahisi wa Kubernetes kwenye mtandao wa gorofa ... Walakini, vinginevyo chombo kinaonekana kuwa muhimu na muhimu. .

Kutenga kikundi ili kukidhi mahitaji ya usalama huenda kusiwezekani kila wakati, na hapa ndipo Calico (au suluhisho sawa) huja kusaidia. Mifano iliyotolewa katika makala hii (iliyo na marekebisho madogo) inatumika katika usakinishaji kadhaa wa wateja wetu katika AWS.

PS

Soma pia kwenye blogi yetu:

• «Utangulizi wa Sera za Mtandao wa Kubernetes kwa Wataalamu wa Usalama";
• "Mwongozo Ulioonyeshwa kwa Mtandao katika Kubernetes": sehemu ya 1 na 2 (mfano wa mtandao, mitandao inayowekelea), Sehemu ya 3 (huduma na usindikaji wa trafiki);
• «Kiolesura cha Mtandao wa Kontena (CNI) - kiolesura cha mtandao na kiwango cha vyombo vya Linux'.

Chanzo: mapenzi.com