Calico ji bo torê li Kubernetes: danasîn û ezmûnek piçûk

Armanca gotarê ew e ku xwendevan bi bingehên torê û rêvebirina polîtîkayên torê yên li Kubernetes, û her weha pêveka sêyemîn a Calico-yê ku kapasîteyên standard dirêj dike bide nasîn. Di rê de, hêsaniya veavakirinê û hin taybetmendî dê bi karanîna mînakên rastîn ên ji ezmûna xebitandina me were destnîşan kirin.

Danasînek bilez a pêveka torê ya Kubernetes

Komek Kubernetes bêyî torê nayê xeyal kirin. Me berê materyalên li ser bingehên wan weşandine: "Rêbernameyek diyarkirî ya torê li Kubernetes"And"Destpêkek Polîtîkayên Tora Kubernetes ji bo Pisporên Ewlekariyê".

Di çarçoveya vê gotarê de, girîng e ku were zanîn ku K8s bixwe ne berpirsiyar e ji girêdana torê ya di navbera konteyneran û nokan de: ji bo vê yekê, cûrbecûr pêvekên CNI (Container Networking Interface). Подробнее об этой концепции мы wan jî ji min re gotin.

Mînakî, ya herî gelemperî ji van pêvekan e Flannel - bi bilindkirina piran li ser her girêkekê, bi veqetandina jêrtorekê di navbera hemî girêkên komê de pêwendiya tevna torê peyda dike. Lêbelê, gihîştina bêkêmasî û nerêkûpêk her gav ne bikêr e. Ji bo peydakirina celebek îzolasyonek hindiktirîn a di komê de, pêdivî ye ku meriv destwerdanê di veavakirina dîwarê agir de bike. Di rewşa gelemperî de, ew di bin kontrola heman CNI de tê danîn, ji ber vê yekê her destwerdanên partiya sêyemîn di iptables de dikare bi xeletî were şîrove kirin an jî bi tevahî were paşguh kirin.

Û ji bo birêxistinkirina rêveberiya polîtîkaya torê di komek Kubernetes de "ji qutiyê" tê peyda kirin NetworkPolicy API. Ev çavkanî, ku li ser cîhên navên hilbijartî hatî belav kirin, dibe ku qaîdeyên ji bo cûdakirina gihîştina ji serîlêdanek ji ya din hebe. Di heman demê de ew dihêle hûn gihîştina di navbera podên taybetî, hawîrdor (navnîşan) an blokên navnîşanên IP-yê de mîheng bikin:

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

Ev ne mînaka herî primitive e belgeyên fermî dibe ku carekê û ji bo her tiştî xwesteka famkirina mentiqê çawa polîtîkayên torê dixebitin cesaret bike. Lêbelê, em ê dîsa jî hewl bidin ku prensîb û rêbazên bingehîn ên hilberandina herikîna trafîkê bi karanîna polîtîkayên torê fam bikin ...

Bi mentiqî ye ku 2 celeb seyrûsefer hene: ketina podê (Ingress) û derketina jê (Derketin).

Bi rastî, siyaset li gorî rêgezên tevgerê di van 2 kategoriyan de tê dabeş kirin.

Taybetmendiya pêwîst a din hilbijêrek e; yê ku qayde jê re derbas dibe. Ev dikare bibe podek (an jî komek pods) an jîngehek (ango navekek). Agahiyek girîng: her du celeb van tiştan divê labelek hebe (awanasî di termînolojiya Kubernetes de) - ev in yên ku siyasetmedar bi wan re tevdigerin.

Ji bilî hejmareke bêdawî ya hilbijêran ku ji hêla celebek etîketê ve têne yek kirin, gengaz e ku meriv qaîdeyên wekî "Destûr / her tiştî înkar / her kes" di cûrbecûr cûda de binivîse. Ji bo vê armancê, avahiyên formê têne bikar anîn:

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

- Di vê nimûneyê de, hemî podên li hawîrdorê ji seyrûsefera hatinê têne asteng kirin. Tevgera berevajî dikare bi avakirina jêrîn pêk were:

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

Bi heman awayî ji bo derketinê:

  podSelector: {}
  policyTypes:
  - Egress

- ji bo vemirandina wê. Û li vir çi tê de heye:

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

Vegera bijartina pêvekek CNI ya ji bo komek, hêjayî gotinê ye ne her pêveka torê NetworkPolicy piştgirî dike. Mînakî, Flannel-a ku berê hatî behs kirin nizane ka meriv çawa polîtîkayên torê mîheng dike, kîjan rasterast tê gotin di depoya fermî de. Li wir alternatîfek jî tê gotin - projeyek Çavkaniya Vekirî Calico, ku di warê polîtîkayên torê de komek standard a Kubernetes API-ê bi girîngî berfireh dike.

Naskirina Calico: teorî

Pêveka Calico dikare di entegrasyonê de bi Flannel re were bikar anîn (subproje Cihok) an serbixwe, hem pêwendiya torê û hem jî kapasîteyên rêveberiya peydabûnê vedigire.

Bikaranîna çareseriya K8s "boxed" û API set ji Calico çi fersend peyda dike?

Li vir tiştê ku di NetworkPolicy de hatî çêkirin heye:

• siyasetmedar ji hêla hawirdorê ve têne sînor kirin;
• Polîtîkayên li ser podên ku bi etîketan têne nîşankirin têne sepandin;
• qaîdeyên dikarin li ser pods, jîngeh an subnets bên sepandin;
• qaîdeyên dikarin protokolan, taybetmendîyên porta binavkirî an sembolîk hebin.

Li vir çawa Calico van fonksiyonan dirêj dike:

• Polîtîka dikarin li ser her tiştî bêne sepandin: pod, konteynir, makîneya virtual an navrû;
• qaîdeyên dikarin çalakiyek taybetî hebe (qedexe, destûr, têketin);
• armanc an çavkaniya qaîdeyan dikare benderek, rêzek port, protokol, taybetmendiyên HTTP an ICMP, IP an subnet (nifşa 4-an an 6-an), her hilbijêr (girêk, mêvandar, hawîrdor) be;
• Wekî din, hûn dikarin derbasbûna seyrûseferê bi karanîna mîhengên DNAT û polîtîkayên şandina trafîkê birêkûpêk bikin.

Yekem peywirên li ser GitHub di depoya Calico de ji Tîrmeha 2016-an vedigere, û salek şûnda proje di organîzekirina girêdana torê ya Kubernetes de pozîsyonek pêşeng girt - ev, mînakî, ji hêla encamên anketê ve tê îspat kirin, ji hêla The New Stack ve hatî kirin:

Bi K8-an re gelek çareseriyên birêvebir ên mezin, wek Amazon EKS, Azure AKS, Google GKE û yên din dest pê kirin ku wê ji bo karanîna pêşniyar bikin.

Ji bo performansê, her tişt li vir pir xweş e. Di ceribandina hilbera xwe de, tîmê pêşkeftina Calico performansa astronomîkî nîşan da, zêdetirî 50000 konteyneran li ser 500 girêkên laşî bi rêjeya afirandina 20 konteynir di çirkeyê de dimeşîne. Di pîvandinê de tu pirsgirêk nehatin tespît kirin. Encamên weha hatin ragihandin уже при анонсе первой версии. Независимые исследования, направленные на пропускную способность и объемы потребления ресурсов, также подтверждают производительность Calico, практически не уступающую Flannel. Bo nimûne:

Proje pir zû pêş dikeve, ew piştgirî dide xebata di çareseriyên populer ên K8s, OpenShift, OpenStack de têne rêve kirin, dema ku komek bi kar tînin bikar bînin Calico gengaz e. peîn, li ser avakirina torên Service Mesh referans hene (vir nimûne ye bi Istio re tê bikaranîn).

Bi Calico re pratîk bikin

Di rewşa gelemperî ya karanîna vanilla Kubernetes de, sazkirina CNI bi karanîna pelê tê calico.yaml, ji malpera fermî daxistin, bi karanîna kubectl apply -f.

Wekî qaîdeyek, guhertoya heyî ya pêvekê bi 2-3 guhertoyên herî dawî yên Kubernetes re hevaheng e: operasyona di guhertoyên kevn de nayê ceribandin û ne garantî ye. Li gorî pêşdebiran, Calico li ser kernelên Linux-ê li jor 3.10-ê ku CentOS 7, Ubuntu 16 an Debian 8-ê dimeşîne, li ser iptables an IPVS-ê dimeşîne.

Tecrîd di nava derdorê de

Ji bo têgihiştinek gelemperî, ka em li dozek hêsan binihêrin da ku fêm bikin ka polîtîkayên torê yên di nîşana Calico de ji yên standard çawa cûda dibin û çawa nêzîkatiya çêkirina qaîdeyan xwendin û vesazkirina wan hêsan dike:

Di komê de 2 serîlêdanên webê hene: di Node.js û PHP de, yek ji wan Redis bikar tîne. Ji bo astengkirina gihîştina Redis ji PHP-ê, dema ku pêwendiya bi Node.js re biparêzin, tenê polîtîkaya jêrîn bicîh bînin:

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

Di bingeh de me destûr da seyrûsefera ku ji Node.js ber bi porta Redis ve tê. Û wan eşkere tiştek din qedexe nekir. Gava ku NetworkPolicy xuya dibe, hemî hilbijêrên ku tê de têne destnîşan kirin dest bi veqetandinê dikin, heya ku wekî din neyê destnîşankirin. Lêbelê, qaîdeyên îzolekirinê li ser tiştên din ên ku ji hêla hilbijêr ve nehatine vegirtin derbas nabe.

Mînak bikar tîne apiVersion Kubernetes ji qutîkê derket, lê tiştek nahêle ku hûn wê bikar bînin çavkaniya bi heman navî ji radestkirina Calico. Hevoksaziya li wir berfirehtir e, ji ber vê yekê hûn ê hewce bikin ku qaîdeya rewşa jorîn bi forma jêrîn ji nû ve binivîsin:

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

Avakirinên jorîn ji bo destûr an redkirina hemî seyrûsefera bi rêkûpêk NetworkPolicy API-ya birêkûpêk avaniyên bi parantezê hene ku tênegihîştin û bîranîna wan dijwar e. Di doza Calico de, ji bo guhertina mantiqa qaîdeyek firewall berevajî, tenê biguhezîne action: Allow li ser action: Deny.

Ji hêla hawirdorê ve tecrîd

Naha rewşek bifikirin ku serîlêdan ji bo berhevkirina li Prometheus û analîzên din bi karanîna Grafana metrîkên karsaziyê diafirîne. Dibe ku barkirin daneyên hesas hebe, ku dîsa ji hêla xwerû ve ji raya giştî re tê dîtin. Werin em van daneyan ji çavên dilpak veşêrin:

Prometheus, wekî qaîdeyek, di hawîrdorek karûbarê cihêreng de tête danîn - di nimûneyê de ew ê navek weha be:

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

warê metadata.labels derket holê ku ev ne tesaduf e. Wek ku li jor hat gotin, namespaceSelector (û herwisa podSelector) bi etîketan kar dike. Ji ber vê yekê, ji bo ku rê bidin metrîkên ku ji hemî podên li ser portek taybetî bêne girtin, hûn neçar in ku celebek etîketek lê zêde bikin (an ji yên heyî bistînin), û dûv re veavakirinek mîna:

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

Û heke hûn polîtîkayên Calico bikar bînin, hevoksaz dê bi vî rengî be:

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

Bi gelemperî, bi lê zêdekirina van cûre polîtîkayan ji bo hewcedariyên taybetî, hûn dikarin li dijî destwerdana xirab an qezayî ya di xebata sepanên di komê de biparêzin.

Pratîka çêtirîn, li gorî afirînerên Calico, nêzîkatiya "Her tiştî asteng bikin û tiştê ku hûn hewce ne bi eşkere vekin" e, ku di belgeyên fermî (yên din nêzîkatiyek wekhev dişopînin - bi taybetî, di gotara berê behs kiriye).

Bikaranîna Tiştên Calico yên Zêdeyî

Bihêle ku ez ji we re bi bîr bînim ku bi navgîniya dirêjkirî ya API-yên Calico hûn dikarin hebûna girêkan birêkûpêk bikin, ne tenê bi pods. Di mînaka jêrîn de bi kar tînin GlobalNetworkPolicy şiyana derbaskirina daxwazên ICMP-ê di komê de girtî ye (mînak, ping ji podek ber bi nodek, di navbera podan de, an ji girêkek ji podek IP-yê re)

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

Di rewşa jorîn de, hîn jî gengaz e ku girêkên komê bi riya ICMP-ê bi hev re "bigihîjin". Û ev pirsgirêk bi rêyan çareser dibe GlobalNetworkPolicy, li saziyekê hatiye sepandin 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"]

Doza VPN

Di dawiyê de, ez ê mînakek pir rastîn a karanîna fonksiyonên Calico-yê ji bo rewşa danûstendina nêzîk-kluster-ê bidim, dema ku komek standardek polîtîk ne bes e. Ji bo gihîştina serîlêdana webê, xerîdar tunelek VPN bikar tînin, û ev gihîştin bi tundî tê kontrol kirin û bi navnîşek taybetî ya karûbarên ku ji bo karanîna destûr têne sînordar kirin:

Xerîdar bi porta standard UDP 1194 ve bi VPN-ê ve girêdidin û, dema ku ve girêdayî ye, rêyên berbi jêr-torên komê yên pod û karûbaran distînin. Ji bo ku di dema ji nû ve destpêkirinê û guhertinên navnîşan de karûbaran winda nekin, tevahiyên jêrtorê têne avêtin.

Porta di veavakirinê de standard e, ku hin hûrguliyan li ser pêvajoya mîhengkirina serîlêdanê û veguheztina wê li koma Kubernetes ferz dike. Mînakî, di heman AWS LoadBalancer-ê de ji bo UDP bi rastî di dawiya sala borî de di navnîşek tixûbdar a herêman de xuya bû, û NodePort ji ber şandina wê li ser hemî girêkên komê nikare were bikar anîn û ne gengaz e ku hejmara nimûneyên serverê ji bo pîvandinê were bikar anîn. armancên tolerasyona xeletiyê. Zêdeyî, hûn ê neçar bin ku rêza xwerû ya portan biguhezînin ...

Di encama lêgerîna li çareseriyên gengaz de, jêrîn hate hilbijartin:

1. Podên bi VPN-ê li her girêkek tê plansaz kirin hostNetwork, ango ji IP-ya rastîn re.
2. Karûbar li derve bi navgîniyê tê şandin ClusterIP. Portek bi fizîkî li ser nodê tê saz kirin, ku ji derve ve bi veqetandinên piçûk ve tê gihîştin (hebûna şert a navnîşana IP-ya rastîn).
3. Tesbîtkirina girêka ku pê li ser rabûye li derveyî çarçoweya çîroka me ye. Ez ê tenê bibêjim ku hûn dikarin karûbarê hişk "nenûk bikin" li ser girêkek an karûbarek piçûkek piçûk binivîsin ku dê navnîşana IP-ya heyî ya karûbarê VPN bişopîne û tomarên DNS-ê yên ku bi xerîdaran re hatine tomar kirin biguhezîne - yê ku têra xwe xeyal e.

Ji perspektîfek rêvekirinê, em dikarin bi yekta xerîdarek VPN bi navnîşana IP-ya wê ya ku ji hêla servera VPN ve hatî derxistin nas bikin. Li jêr mînakek seretayî ya sînordarkirina gihîştina xerîdarek weha ya karûbaran heye, ku li ser Redisên jorîn hatî destnîşan kirin:

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]

Li vir, girêdana bi porta 6379-ê bi tundî qedexe ye, lê di heman demê de xebata karûbarê DNS-ê tê parastin, ku fonksiyona wê pir caran dema ku rêgez têne çêkirin diêşe. Ji ber ku, wekî ku berê hate behs kirin, dema ku hilbijêrek xuya dike, heya ku wekî din neyê destnîşan kirin, polîtîkaya înkarê ya xwerû li ser tê sepandin.

Encam

Bi vî rengî, bi karanîna API-ya pêşkeftî ya Calico-yê, hûn dikarin bi nermî mîheng bikin û bi rengek dînamîkî rêgezê li nav û dora komê biguhezînin. Bi gelemperî, karanîna wê dikare mîna gulebarana çivîkan bi topan xuya bike, û pêkanîna torgilokek L3 bi tunelên BGP û IP-IP-ê di sazkirina Kubernetes a hêsan a li ser torgilokek darûz de cinawir xuya dike... Lêbelê, wekî din amûrek pir maqûl û kêrhatî xuya dike. .

Veqetandina komek ji bo bicîhanîna hewcedariyên ewlehiyê dibe ku her gav ne pêkan be, û li vir Calico (an çareseriyek wusa) tê alîkariyê. Mînakên ku di vê gotarê de hatine dayîn (bi guheztinên piçûk) di gelek sazûmanên xerîdarên me de di AWS de têne bikar anîn.

PS

Li ser bloga me jî bixwînin:

• «Destpêkek Polîtîkayên Tora Kubernetes ji bo Pisporên Ewlekariyê»;
• "Rêberek Illustrated ji bo Tora Kubernetes": beşên 1 û 2 (modela torê, torên sergirtî), beşa 3 (xizmet û pêvajoya trafîkê);
• «Navbera torê ya konteyner (CNI) - navgîniya torê û standard ji bo konteynerên Linux".

Source: www.habr.com