Calico ar gyfer rhwydweithio yn Kubernetes: cyflwyniad ac ychydig o brofiad

Pwrpas yr erthygl yw cyflwyno'r darllenydd i hanfodion rhwydweithio a rheoli polisïau rhwydwaith yn Kubernetes, yn ogystal â'r ategyn Calico trydydd parti sy'n ymestyn galluoedd safonol. Ar hyd y ffordd, bydd rhwyddineb cyfluniad a rhai nodweddion yn cael eu dangos gan ddefnyddio enghreifftiau go iawn o'n profiad gweithredu.

Cyflwyniad cyflym i declyn rhwydweithio Kubernetes

Ni ellir dychmygu clwstwr Kubernetes heb rwydwaith. Rydym eisoes wedi cyhoeddi deunyddiau ar eu hanfodion: “Canllaw darluniadol i rwydweithio yn Kubernetes...."Ac"Cyflwyniad i Bolisïau Rhwydwaith Kubernetes ar gyfer Gweithwyr Proffesiynol Diogelwch'.

Yng nghyd-destun yr erthygl hon, mae'n bwysig nodi nad yw K8s ei hun yn gyfrifol am gysylltedd rhwydwaith rhwng cynwysyddion a nodau: ar gyfer hyn, amrywiol ategion CNI (Rhyngwyneb Rhwydweithio Cynhwysydd). Mwy am y cysyniad hwn rydym ni dywedasant wrthyf hefyd.

Er enghraifft, y mwyaf cyffredin o'r ategion hyn yw Flannel — yn darparu cysylltedd rhwydwaith llawn rhwng yr holl nodau clwstwr trwy godi pontydd ar bob nod, gan neilltuo is-rwydwaith iddo. Fodd bynnag, nid yw hygyrchedd cyflawn a heb ei reoleiddio bob amser yn fuddiol. Er mwyn darparu rhyw fath o ynysu lleiaf posibl yn y clwstwr, mae angen ymyrryd yn y ffurfweddiad y wal dân. Yn yr achos cyffredinol, caiff ei roi o dan reolaeth yr un CNI, a dyna pam y gellir dehongli unrhyw ymyriadau trydydd parti mewn iptables yn anghywir neu eu hanwybyddu'n gyfan gwbl.

A darperir “allan o'r bocs” ar gyfer trefnu rheolaeth polisi rhwydwaith mewn clwstwr Kubernetes NetworkPolicy API. Gall yr adnodd hwn, a ddosberthir dros ofodau enw dethol, gynnwys rheolau i wahaniaethu mynediad o un rhaglen i'r llall. Mae hefyd yn caniatáu ichi ffurfweddu hygyrchedd rhwng codennau, amgylcheddau (mannau enwau) neu flociau o gyfeiriadau IP penodol:

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

Nid dyma'r enghraifft fwyaf cyntefig o dogfennaeth swyddogol gall unwaith ac am byth atal yr awydd i ddeall rhesymeg sut mae polisïau rhwydwaith yn gweithio. Fodd bynnag, byddwn yn dal i geisio deall yr egwyddorion a'r dulliau sylfaenol o brosesu llif traffig gan ddefnyddio polisïau rhwydwaith...

Mae'n rhesymegol bod yna 2 fath o draffig: mynd i mewn i'r pod (Ingress) ac allan ohono (Egress).

Mewn gwirionedd, mae gwleidyddiaeth wedi'i rhannu i'r 2 gategori hyn yn seiliedig ar gyfeiriad y symudiad.

Y priodoledd gofynnol nesaf yw dewisydd; yr un y mae'r rheol yn berthnasol iddo. Gall hwn fod yn goden (neu’n grŵp o godennau) neu’n amgylchedd (h.y. gofod enw). Manylion pwysig: rhaid i'r ddau fath o'r gwrthrychau hyn gynnwys label (label yn nherminoleg Kubernetes) - dyma'r rhai y mae gwleidyddion yn gweithredu â nhw.

Yn ogystal â nifer gyfyngedig o ddetholwyr wedi'u huno gan ryw fath o label, mae'n bosibl ysgrifennu rheolau fel “Caniatáu / gwadu popeth / pawb” mewn amrywiadau gwahanol. At y diben hwn, defnyddir lluniadau'r ffurflen:

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

— yn yr enghraifft hon, mae pob cod yn yr amgylchedd wedi'i rwystro rhag traffig sy'n dod i mewn. Gellir cyflawni'r ymddygiad gwrthgyferbyniol gyda'r lluniad canlynol:

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

Yn yr un modd ar gyfer mynd allan:

  podSelector: {}
  policyTypes:
  - Egress

- i'w ddiffodd. A dyma beth i'w gynnwys:

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

Gan ddychwelyd at y dewis o ategyn CNI ar gyfer clwstwr, mae'n werth nodi hynny nid yw pob ategyn rhwydwaith yn cefnogi NetworkPolicy. Er enghraifft, nid yw'r Wlanen a grybwyllwyd eisoes yn gwybod sut i ffurfweddu polisïau rhwydwaith, sydd dywedir yn uniongyrchol yn y gadwrfa swyddogol. Crybwyllir dewis arall yno hefyd - prosiect Ffynhonnell Agored Calico, sy'n ehangu'n sylweddol y set safonol o Kubernetes APIs o ran polisïau rhwydwaith.

Dod i adnabod Calico: theori

Gellir defnyddio ategyn Calico i integreiddio â Wlanen (is-brosiect Camlas) neu'n annibynnol, gan gwmpasu cysylltedd rhwydwaith a galluoedd rheoli argaeledd.

Pa gyfleoedd y mae defnyddio datrysiad “mewn bocs” K8s a'r set API gan Calico yn eu darparu?

Dyma beth sydd wedi'i ymgorffori yn NetworkPolicy:

• mae gwleidyddion yn cael eu cyfyngu gan yr amgylchedd;
• mae polisïau'n cael eu cymhwyso i godennau sydd wedi'u marcio â labeli;
• gellir cymhwyso rheolau i godennau, amgylcheddau neu is-rwydweithiau;
• gall rheolau gynnwys protocolau, manylebau porthladd a enwir neu symbolaidd.

Dyma sut mae Calico yn ymestyn y swyddogaethau hyn:

• gellir cymhwyso polisïau i unrhyw wrthrych: pod, cynhwysydd, peiriant rhithwir neu ryngwyneb;
• gall rheolau gynnwys gweithred benodol (gwaharddiad, caniatâd, logio);
• gall y targed neu ffynhonnell y rheolau fod yn borthladd, ystod o borthladdoedd, protocolau, priodoleddau HTTP neu ICMP, IP neu is-rwydwaith (4ydd neu 6ed cenhedlaeth), unrhyw ddetholwyr (nodau, gwesteiwyr, amgylcheddau);
• Yn ogystal, gallwch reoli hynt traffig gan ddefnyddio gosodiadau DNAT a pholisïau anfon traffig ymlaen.

Mae'r cyntaf yn ymrwymo ar GitHub yn ystorfa Calico yn dyddio'n ôl i fis Gorffennaf 2016, a blwyddyn yn ddiweddarach cymerodd y prosiect safle blaenllaw wrth drefnu cysylltedd rhwydwaith Kubernetes - mae tystiolaeth o hyn, er enghraifft, gan ganlyniadau'r arolwg, dan arweiniad The New Stack:

Llawer o atebion mawr a reolir gyda K8s, megis Amazon EKS, Azure AKS, Google GKE a dechreuodd eraill ei argymell i'w ddefnyddio.

O ran perfformiad, mae popeth yn wych yma. Wrth brofi eu cynnyrch, dangosodd tîm datblygu Calico berfformiad seryddol, gan redeg mwy na 50000 o gynwysyddion ar 500 o nodau corfforol gyda chyfradd creu o 20 cynhwysydd yr eiliad. Ni nodwyd unrhyw broblemau gyda graddio. Canlyniadau o'r fath eu cyhoeddi eisoes ar gyhoeddiad y fersiwn gyntaf. Mae astudiaethau annibynnol sy'n canolbwyntio ar fewnbwn a defnydd o adnoddau hefyd yn cadarnhau bod perfformiad Calico bron cystal â pherfformiad Flannel. Er enghraifft,:

Mae'r prosiect yn datblygu'n gyflym iawn, mae'n cefnogi gwaith mewn datrysiadau poblogaidd a reolir K8s, OpenShift, OpenStack, mae'n bosibl defnyddio Calico wrth ddefnyddio clwstwr gan ddefnyddio cwps, mae cyfeiriadau at adeiladu rhwydweithiau Rhwyll Gwasanaeth (dyma enghraifft defnyddio ar y cyd ag Istio).

Ymarfer gyda Calico

Yn achos cyffredinol defnyddio Kubernetes fanila, mae gosod CNI yn dibynnu ar ddefnyddio'r ffeil calico.yaml, wedi'i lawrlwytho o'r wefan swyddogol, trwy ddefnyddio kubectl apply -f.

Fel rheol, mae fersiwn gyfredol yr ategyn yn gydnaws â'r 2-3 fersiwn diweddaraf o Kubernetes: nid yw gweithrediad mewn fersiynau hŷn yn cael ei brofi ac nid yw wedi'i warantu. Yn ôl y datblygwyr, mae Calico yn rhedeg ar gnewyllyn Linux uwchben 3.10 yn rhedeg CentOS 7, Ubuntu 16 neu Debian 8, ar ben iptables neu IPVS.

Arwahanrwydd o fewn yr amgylchedd

I gael dealltwriaeth gyffredinol, gadewch i ni edrych ar achos syml i ddeall sut mae polisïau rhwydwaith yn nodiant Calico yn wahanol i rai safonol a sut mae'r dull o greu rheolau yn symleiddio eu darllenadwyedd a'u hyblygrwydd cyfluniad:

Mae 2 raglen we yn cael eu defnyddio yn y clwstwr: yn Node.js a PHP, ac mae un ohonynt yn defnyddio Redis. I rwystro mynediad i Redis o PHP, tra'n cynnal cysylltedd â Node.js, defnyddiwch y polisi canlynol:

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

Yn y bôn fe wnaethom ganiatáu traffig sy'n dod i mewn i borthladd Redis o Node.js. Ac yn amlwg nid oeddent yn gwahardd unrhyw beth arall. Cyn gynted ag y bydd NetworkPolicy yn ymddangos, mae'r holl ddetholwyr a grybwyllir ynddo yn dechrau cael eu hynysu, oni nodir yn wahanol. Fodd bynnag, nid yw'r rheolau ynysu yn berthnasol i wrthrychau eraill nad ydynt wedi'u cynnwys gan y dewiswr.

Mae'r enghraifft yn defnyddio apiVersion Kubernetes allan o'r bocs, ond nid oes dim yn eich atal rhag ei ​​ddefnyddio adnodd o'r un enw o'r cludiad Calico. Mae'r gystrawen yn fwy manwl, felly bydd angen i chi ailysgrifennu'r rheol ar gyfer yr achos uchod yn y ffurf ganlynol:

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

Mae'r lluniadau uchod ar gyfer caniatáu neu wadu pob traffig trwy'r API NetworkPolicy rheolaidd yn cynnwys lluniadau gyda cromfachau sy'n anodd eu deall a'u cofio. Yn achos Calico, i newid rhesymeg rheol wal dân i'r gwrthwyneb, dim ond newid action: Allow ar action: Deny.

Ynysu gan amgylchedd

Nawr dychmygwch sefyllfa lle mae cymhwysiad yn cynhyrchu metrigau busnes i'w casglu yn Prometheus a dadansoddiad pellach gan ddefnyddio Grafana. Gall y llwythiad gynnwys data sensitif, sydd eto i'w weld yn gyhoeddus yn ddiofyn. Gadewch i ni guddio'r data hwn rhag llygaid busneslyd:

Mae Prometheus, fel rheol, yn cael ei roi mewn amgylchedd gwasanaeth ar wahân - yn yr enghraifft bydd yn ofod enw fel hyn:

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

Maes metadata.labels trodd hyn allan yn ddim damwain. Fel y soniwyd uchod, namespaceSelector (yn ogystal a podSelector) yn gweithredu gyda labeli. Felly, er mwyn caniatáu i fetrigau gael eu cymryd o bob cod ar borthladd penodol, bydd yn rhaid i chi ychwanegu rhyw fath o label (neu gymryd o'r rhai presennol), ac yna cymhwyso ffurfweddiad fel:

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

Ac os ydych chi'n defnyddio polisïau Calico, bydd y gystrawen fel hyn:

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

Yn gyffredinol, trwy ychwanegu'r mathau hyn o bolisïau ar gyfer anghenion penodol, gallwch amddiffyn rhag ymyrraeth faleisus neu ddamweiniol yng ngweithrediad ceisiadau yn y clwstwr.

Yr arfer gorau, yn ôl crewyr Calico, yw'r dull “Rhwystro popeth ac agor yr hyn sydd ei angen arnoch yn benodol”, wedi'i ddogfennu yn dogfennaeth swyddogol (mae eraill yn dilyn dull tebyg - yn arbennig, yn erthygl a grybwyllwyd eisoes).

Defnyddio Gwrthrychau Calico Ychwanegol

Gadewch imi eich atgoffa y gallwch chi, trwy'r set estynedig o APIs Calico, reoleiddio argaeledd nodau, heb fod yn gyfyngedig i godennau. Yn yr enghraifft ganlynol gan ddefnyddio GlobalNetworkPolicy mae'r gallu i basio ceisiadau ICMP yn y clwstwr ar gau (er enghraifft, pings o god i nod, rhwng codennau, neu o nod i god 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

Yn yr achos uchod, mae'n dal yn bosibl i nodau clwstwr “estyn allan” i'w gilydd trwy ICMP. Ac mae'r mater hwn yn cael ei ddatrys trwy ddulliau GlobalNetworkPolicy, wedi'i gymhwyso i endid 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"]

Yr Achos VPN

Yn olaf, rhoddaf enghraifft wirioneddol iawn o ddefnyddio swyddogaethau Calico ar gyfer rhyngweithio agos at glwstwr, pan nad yw set safonol o bolisïau yn ddigon. I gael mynediad i'r rhaglen we, mae cleientiaid yn defnyddio twnnel VPN, ac mae'r mynediad hwn wedi'i reoli'n dynn a'i gyfyngu i restr benodol o wasanaethau y caniateir eu defnyddio:

Mae cleientiaid yn cysylltu â'r VPN trwy borthladd CDU safonol 1194 a, phan fyddant wedi'u cysylltu, maent yn derbyn llwybrau i is-rwydweithiau clwstwr codennau a gwasanaethau. Mae is-rwydweithiau cyfan yn cael eu gwthio er mwyn peidio â cholli gwasanaethau yn ystod ailgychwyniadau a newidiadau cyfeiriad.

Mae'r porthladd yn y cyfluniad yn safonol, sy'n gosod rhai naws ar y broses o ffurfweddu'r cais a'i drosglwyddo i glwstwr Kubernetes. Er enghraifft, yn yr un AWS LoadBalancer ar gyfer CDU ymddangosodd yn llythrennol ddiwedd y llynedd mewn rhestr gyfyngedig o ranbarthau, ac ni ellir defnyddio NodePort oherwydd ei anfon ymlaen ar bob nod clwstwr ac mae'n amhosibl graddio nifer yr achosion gweinydd ar gyfer dibenion goddefgarwch fai. Hefyd, bydd yn rhaid i chi newid yr ystod ddiofyn o borthladdoedd ...

O ganlyniad i chwilio trwy atebion posibl, dewiswyd y canlynol:

1. Mae codennau gyda VPN wedi'u hamserlennu fesul nod i mewn hostNetwork, hynny yw, i'r IP gwirioneddol.
2. Mae'r gwasanaeth yn cael ei bostio y tu allan drwy ClusterIP. Mae porthladd wedi'i osod yn gorfforol ar y nod, sy'n hygyrch o'r tu allan gyda mân amheuon (presenoldeb amodol cyfeiriad IP go iawn).
3. Mae penderfynu ar ba nôd y rhosyn codog y tu hwnt i gwmpas ein stori. Fe ddywedaf y gallwch chi “hoelio” y gwasanaeth yn dynn i nod neu ysgrifennu gwasanaeth car ochr bach a fydd yn monitro cyfeiriad IP cyfredol y gwasanaeth VPN ac yn golygu'r cofnodion DNS sydd wedi'u cofrestru gyda chleientiaid - pwy bynnag sydd â digon o ddychymyg.

O safbwynt llwybro, gallwn adnabod cleient VPN yn unigryw yn ôl ei gyfeiriad IP a gyhoeddwyd gan y gweinydd VPN. Isod mae enghraifft gyntefig o gyfyngu ar fynediad cleient o'r fath i wasanaethau, a ddangosir ar y Redis uchod:

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]

Yma, mae cysylltu â phorthladd 6379 wedi'i wahardd yn llym, ond ar yr un pryd mae gweithrediad y gwasanaeth DNS yn cael ei gadw, y mae ei weithrediad yn aml yn dioddef wrth lunio rheolau. Oherwydd, fel y crybwyllwyd yn flaenorol, pan fydd dewiswr yn ymddangos, mae'r polisi gwadu rhagosodedig yn cael ei gymhwyso iddo oni nodir yn wahanol.

Canlyniadau

Felly, gan ddefnyddio API datblygedig Calico, gallwch chi ffurfweddu a newid llwybro yn ddeinamig yn y clwstwr ac o'i amgylch yn hyblyg. Yn gyffredinol, gall ei ddefnydd edrych fel saethu adar y to gyda canon, ac mae gweithredu rhwydwaith L3 gyda thwneli BGP ac IP-IP yn edrych yn wrthun mewn gosodiad Kubernetes syml ar rwydwaith gwastad... Fodd bynnag, fel arall, mae'r offeryn yn edrych yn eithaf hyfyw a defnyddiol .

Efallai na fydd ynysu clwstwr i fodloni gofynion diogelwch bob amser yn ymarferol, a dyma lle mae Calico (neu ateb tebyg) yn dod i'r adwy. Defnyddir yr enghreifftiau a roddir yn yr erthygl hon (gyda mân addasiadau) mewn sawl gosodiad o'n cleientiaid yn AWS.

PS

Darllenwch hefyd ar ein blog:

• «Cyflwyniad i Bolisïau Rhwydwaith Kubernetes ar gyfer Gweithwyr Proffesiynol Diogelwch";
• "Arweinlyfr Darluniadol i Rwydweithio yn Kubernetes": rhannau 1 a 2 (model rhwydwaith, rhwydweithiau troshaenu), rhan 3 (gwasanaethau a phrosesu traffig);
• «Rhyngwyneb Rhwydweithio Cynhwysydd (CNI) - rhyngwyneb rhwydwaith a safon ar gyfer cynwysyddion Linux'.

Ffynhonnell: hab.com