Calico fir Vernetzung zu Kubernetes: Aféierung an e bëssen Erfahrung

Den Zweck vum Artikel ass de Lieser d'Grondlage vum Vernetzung an d'Gestioun vun Netzwierkpolitiken a Kubernetes virzestellen, souwéi den Drëtt Partei Calico Plugin deen Standardfäegkeeten erweidert. Ënnerwee gëtt d'Liichtegkeet vun der Konfiguratioun an e puer Features bewisen mat echte Beispiller aus eiser Operatiounserfarung.

Eng séier Aféierung an de Kubernetes Netzwierkapparat

E Kubernetes Cluster kann net ouni Netzwierk virgestallt ginn. Mir hu scho Materialien iwwer hir Basics publizéiert: "En illustréierte Guide fir Netzwierker zu Kubernetes"An"Eng Aféierung zu Kubernetes Netzwierkpolitike fir Sécherheetsprofesser".

Am Kontext vun dësem Artikel ass et wichteg ze bemierken datt K8s selwer net verantwortlech ass fir d'Netzverbindung tëscht Container an Noden: fir dëst, verschidde CNI Plugins (Container Networking Interface). Méi iwwer dëst Konzept mir si hunn mir och gesot.

Zum Beispill, déi heefegst vun dëse Plugins ass Flannel - bitt voll Netzverbindung tëscht all Clusternoden andeems Brécke op all Node eropgeet, en Subnet unzeweisen. Wéi och ëmmer, komplett an onreguléiert Accessibilitéit ass net ëmmer gutt. Fir eng Aart vu minimaler Isolatioun am Cluster ze bidden, ass et néideg fir an der Konfiguratioun vun der Firewall ze intervenéieren. Am allgemenge Fall gëtt et ënner der Kontroll vum selwechte CNI gesat, dofir kënnen all Drëtt-Partei Interventiounen an iptables falsch interpretéiert ginn oder ganz ignoréiert ginn.

A "aus der Këscht" fir d'Organisatioun vun Netzwierkpolitikmanagement an engem Kubernetes Cluster gëtt zur Verfügung gestallt NetworkPolicy API. Dës Ressource, verdeelt iwwer ausgewielte Nummraim, ka Reegele enthalen fir den Zougang vun enger Applikatioun op eng aner ze differenzéieren. Et erlaabt Iech och Accessibilitéit tëscht spezifesche Pods, Ëmfeld (Nummraim) oder Blocke vun IP Adressen ze konfiguréieren:

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

Dëst ass net dat primitivst Beispill vun offiziell Dokumentatioun kann eemol a fir all de Wonsch decouragéieren, d'Logik ze verstoen wéi d'Netzpolitik funktionnéiert. Wéi och ëmmer, mir wäerte nach ëmmer probéieren d'Basisprinzipien a Methoden fir de Verkéiersfloss ze veraarbecht mat Netzwierkpolitik ze verstoen ...

Et ass logesch datt et 2 Aarte vu Verkéier gëtt: de Pod erakommen (Ingress) an erausgoen (Egress).

Eigentlech ass d'Politik an dës 2 Kategorien opgedeelt op Basis vun der Bewegungsrichtung.

Déi nächst erfuerderlech Attribut ass e Selektor; deen op deen d'Regel gëllt. Dëst kann e Pod (oder e Grupp vu Pods) oder en Ëmfeld sinn (dh e Nummraum). E wichtegen Detail: béid Aarte vun dësen Objete mussen e Label enthalen (Label an der Kubernetes Terminologie) - dat sinn déi, mat deenen d'Politiker operéieren.

Zousätzlech zu enger endlecher Unzuel vu Selektoren, déi vun enger Aart vu Label vereenegt sinn, ass et méiglech Reegelen wéi "Alles erlaben / verleegnen / jiddereen" a verschiddene Variatiounen ze schreiwen. Fir dësen Zweck ginn Konstruktioune vun der Form benotzt:

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

- an dësem Beispill sinn all Pods an der Ëmwelt vum Entréeën Traffic blockéiert. De Géigendeel Verhalen kann mat der folgender Konstruktioun erreecht ginn:

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

Ähnlech fir erausginn:

  podSelector: {}
  policyTypes:
  - Egress

- fir et auszeschalten. An hei ass wat ze enthalen:

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

Zréck op d'Wiel vun engem CNI Plugin fir e Cluster, ass et derwäert ze notéieren net all Netzwierk Plugin ënnerstëtzt NetworkPolicy. Zum Beispill, de schonn ernimmt Flannel weess net wéi Reseau Politiken ze konfiguréieren, déi et gëtt direkt gesot am offiziellen Repository. Do gëtt och eng Alternativ ernimmt - en Open Source Projet Calico, wat de Standardset vu Kubernetes APIen wesentlech erweidert wat d'Netzpolitik ugeet.

Calico kennen ze léieren: Theorie

De Calico Plugin kann an Integratioun mat Flannel benotzt ginn (Subproject erduerch) oder onofhängeg, souwuel d'Netzverbindung an d'Verfügbarkeetsmanagementfäegkeeten ofdecken.

Wéi eng Méiglechkeeten bitt d'Benotzung vun der K8s "boxed" Léisung an dem API Set vu Calico?

Hei ass wat an NetworkPolicy agebaut ass:

• Politiker sinn duerch d'Ëmwelt limitéiert;
• Politiken ginn op Pods applizéiert mat Etiketten markéiert;
• Regele kënnen op Pods, Ëmfeld oder Subnets applizéiert ginn;
• Regelen kënnen Protokoller enthalen, genannt oder symbolesch port Spezifikatioune.

Hei ass wéi Calico dës Funktiounen erweidert:

• Politik kann op all Objet applizéiert ginn: Pod, Container, virtuell Maschinn oder Interface;
• Regele kënnen eng spezifesch Aktioun enthalen (Verbuet, Erlaabnis, Logged);
• d'Zil oder d'Quell vun de Regelen kann e Port sinn, eng Rei vu Ports, Protokoller, HTTP oder ICMP Attributer, IP oder Subnet (4. oder 6. Generatioun), all Selektor (Noden, Hosten, Ëmfeld);
• Zousätzlech kënnt Dir de Passage vum Traffic reguléieren andeems Dir DNAT Astellungen a Verkéier Forwarding Politik benotzt.

Déi éischt Verpflichtungen op GitHub am Calico Repository daten zréck op Juli 2016, an e Joer méi spéit huet de Projet eng féierend Positioun an der Organisatioun vun der Kubernetes Netzwierk Konnektivitéit geholl - dëst ass beweist, zum Beispill, duerch d'Resultater vun der Ëmfro, geleet vum The New Stack:

Vill grouss geréiert Léisunge mat K8s, wéi Amazon EKS, Azur AKS, Google GKE an anerer hunn ugefaang et fir de Gebrauch ze recommandéieren.

Wat d'Performance ugeet, ass alles super hei. Beim Testen vun hirem Produkt huet d'Calico Entwécklungsteam astronomesch Leeschtung bewisen, méi wéi 50000 Container op 500 physesch Noden mat enger Kreatiounsquote vun 20 Container pro Sekonn lafen. Keng Probleemer goufe mat Skaléieren identifizéiert. Esou Resultater ugekënnegt goufen schonn bei der Ukënnegung vun der éischter Versioun. Onofhängeg Studien, déi sech op Duerchgang a Ressourceverbrauch fokusséieren, bestätegen och d'Performance vum Calico ass bal sou gutt wéi dem Flannel. Zum Beispill:

De Projet entwéckelt sech ganz séier, et ënnerstëtzt d'Aarbecht a populäre Léisunge geréiert K8s, OpenShift, OpenStack, et ass méiglech Calico ze benotzen wann Dir e Cluster benotzt kops, et gi Referenzen op de Bau vu Service Mesh Netzwierker (hei ass e Beispill benotzt a Verbindung mat Istio).

Praxis mat Calico

Am allgemenge Fall vu Vanille Kubernetes ze benotzen, installéiert CNI kënnt op d'Benotzung vun der Datei calico.yaml, erofgeluede vun der offizieller Websäit, andeems Dir benotzt kubectl apply -f.

In der Regel ass déi aktuell Versioun vum Plugin kompatibel mat de leschten 2-3 Versioune vu Kubernetes: Operatioun an eelere Versioune gëtt net getest an ass net garantéiert. Laut den Entwéckler leeft Calico op Linux Kernels iwwer 3.10 Lafen CentOS 7, Ubuntu 16 oder Debian 8, uewen op iptables oder IPVS.

Isolatioun bannent der Ëmwelt

Fir en allgemengt Verständnis, loosst eis en einfache Fall kucken fir ze verstoen wéi d'Netzpolitik an der Calico Notatioun vun de Standarden ënnerscheeden a wéi d'Approche fir Regelen ze kreéieren hir Liesbarkeet a Konfiguratiounsflexibilitéit vereinfacht:

Et ginn 2 Webapplikatiounen am Cluster ofgesat: an Node.js a PHP, eng vun deenen Redis benotzt. Fir den Zougang zu Redis vu PHP ze blockéieren, wärend d'Konnektivitéit mat Node.js behalen, gëlle just déi folgend Politik:

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

Wesentlech hu mir den Entréeën Traffic op de Redis Hafen vum Node.js erlaabt. A si hunn kloer näischt anescht verbueden. Soubal NetworkPolicy erschéngt, fänken all Selectoren, déi dra ernimmt sinn, isoléiert ze ginn, wann net anescht uginn. Wéi och ëmmer, d'Isolatiounsregele gëllen net fir aner Objeten déi net vum Selektor ofgedeckt sinn.

D'Beispill benotzt apiVersion Kubernetes aus der Këscht, awer näischt verhënnert Iech et ze benotzen Ressource mam selwechten Numm vun der Calico Liwwerung. D'Syntax do ass méi detailléiert, also musst Dir d'Regel fir de uewe genannte Fall an der folgender Form iwwerschreiwe:

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

Déi uewe genannte Konstrukter fir all Traffic duerch déi regulär NetworkPolicy API z'erlaaben oder ze refuséieren enthalen Konstruktiounen mat Klammern déi schwéier ze verstoen an ze erënneren. Am Fall vu Calico, fir d'Logik vun enger Firewall Regel op de Géigendeel z'änneren, just änneren action: Allow op action: Deny.

Isolatioun duerch Ëmwelt

Stellt Iech elo eng Situatioun vir, wou eng Applikatioun Geschäftsmetriken generéiert fir Sammelen am Prometheus a weider Analyse mat Grafana. Den Eroplueden kann sensibel Donnéeën enthalen, déi als Standard erëm ëffentlech sichtbar sinn. Loosst eis dës Donnéeë vu virwëtzeg Aen verstoppen:

Prometheus, als Regel, gëtt an engem getrennten Service Ëmfeld plazéiert - am Beispill gëtt et e Nummraum wéi dëst:

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

Beräich metadata.labels dëst huet sech als keen Accident erausgestallt. Wéi uewen ernimmt, namespaceSelector (sou wéi podSelector) funktionnéiert mat Etiketten. Dofir, fir datt Metriken aus all Pods op engem spezifesche Port geholl kënne ginn, musst Dir eng Aart Label addéieren (oder vun existéierenden huelen), an dann eng Konfiguratioun uwenden wéi:

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

A wann Dir Calico Politik benotzt, wäert d'Syntax esou sinn:

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

Am Allgemengen, andeems Dir dës Aarte vu Politiken fir spezifesch Bedierfnesser bäidréit, kënnt Dir géint béiswëlleg oder versehentlech Interferenz an der Operatioun vun Uwendungen am Cluster schützen.

Déi bescht Praxis, laut den Ersteller vu Calico, ass d'Approche "Alles blockéieren an explizit opmaachen wat Dir braucht", dokumentéiert an offiziell Dokumentatioun (anerer verfollegen eng ähnlech Approche - besonnesch an schonn ernimmt Artikel).

Benotzt zousätzlech Calico Objekter

Loosst mech Iech drun erënneren datt duerch den erweiderten Set vu Calico APIs Dir d'Disponibilitéit vun Noden reguléiere kënnt, net limitéiert op Pods. Am folgende Beispill benotzt GlobalNetworkPolicy d'Fäegkeet fir ICMP Ufroen am Cluster ze passéieren ass zou (zum Beispill Pings vun engem Pod op en Node, tëscht Pods oder vun engem Node op en 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

Am uewe genannte Fall ass et nach ëmmer méiglech fir Clusterknäppchen ze "erreechen" iwwer ICMP. An dëst Thema gëtt mat Mëttelen geléist GlobalNetworkPolicy, op eng Entitéit applizéiert 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"]

De VPN Fall

Schlussendlech wäert ech e ganz realt Beispill ginn fir Calico Funktiounen ze benotzen fir de Fall vun der No-Cluster Interaktioun, wann e Standard Set vu Politiken net genuch ass. Fir Zougang zu der Webapplikatioun ze benotzen, benotzen d'Clienten e VPN-Tunnel, an dësen Zougang ass enk kontrolléiert a limitéiert op eng spezifesch Lëscht vu Servicer erlaabt ze benotzen:

Cliente verbannen mam VPN iwwer Standard UDP Hafen 1194 a kréien, wann se verbonne sinn, Strecken op de Cluster-Subnets vu Pods a Servicer. Ganz Subnets ginn gedréckt fir Servicer net während Neistarten an Adressännerungen ze verléieren.

Den Hafen an der Konfiguratioun ass Standard, wat e puer Nuancen op de Prozess vun der Konfiguratioun vun der Applikatioun imposéiert an op de Kubernetes Cluster transferéiert. Zum Beispill, am selwechten AWS LoadBalancer fir UDP erschéngt wuertwiertlech um Enn vum leschte Joer an enger limitéierter Lëscht vu Regiounen, an NodePort kann net benotzt ginn wéinst senger Forwarding op all Clusternoden an et ass onméiglech d'Zuel vun de Serverinstanzen ze skaléieren fir Feeler Toleranz Zwecker. Plus, Dir musst d'Standardpalette vu Ports änneren ...

Als Resultat vun der Sich no méigleche Léisunge goufe folgend gewielt:

1. Pods mat VPN si pro Node geplangt hostNetwork, dat ass, op déi aktuell IP.
2. De Service gëtt ausserhalb duerch gepost ClusterIP. E Port ass kierperlech um Node installéiert, dee vu baussen zougänglech ass mat klengen Reservatiounen (bedingt Präsenz vun enger richteger IP Adress).
3. Bestëmmung vum Node op deem de Pod opgestan ass iwwer den Ëmfang vun eiser Geschicht. Ech soen just datt Dir de Service op e Node enk "nageln" kënnt oder e klenge Sidecar-Service schreiwen, deen déi aktuell IP Adress vum VPN-Service iwwerwaacht an d'DNS-Records, déi mat Clienten registréiert sinn, änneren - wien och genuch Fantasi huet.

Aus enger Routing Perspektiv kënne mir e VPN Client eenzegaarteg identifizéieren duerch seng IP Adress déi vum VPN Server erausginn ass. Drënner ass e primitivt Beispill fir den Zougang vun esou engem Client zu Servicer ze beschränken, illustréiert op der uewe genannter 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]

Hei ass d'Verbindung mam Hafen 6379 strikt verbueden, awer gläichzäiteg ass d'Operatioun vum DNS-Service bewahrt, de Fonctionnement vun deem zimmlech dacks leid wann d'Regelen ausgeschafft ginn. Well, wéi virdru scho gesot, wann e Selektor erschéngt, gëtt d'Standardverleegungspolitik drop ugewannt, wann net anescht uginn.

Resultater

Also, andeems Dir Calico's fortgeschratt API benotzt, kënnt Dir flexibel Routing an a ronderëm de Cluster konfiguréieren an dynamesch änneren. Am Allgemengen kann seng Notzung ausgesinn wéi Spatzen mat enger Kanoun ze schéissen, an d'Ëmsetzung vun engem L3-Netz mat BGP- an IP-IP-Tunnelen gesäit monstréis aus an enger einfacher Kubernetes-Installatioun op engem flaache Netz ... Wéi och ëmmer, soss gesäit d'Tool ganz viabel an nëtzlech aus. .

E Cluster ze isoléieren fir d'Sécherheetsufuerderungen z'erreechen ass vläicht net ëmmer machbar, an dat ass wou Calico (oder eng ähnlech Léisung) zur Rettung kënnt. D'Beispiller an dësem Artikel (mat klengen Ännerungen) ginn a verschiddenen Installatiounen vun eise Clienten an AWS benotzt.

PS

Liest och op eisem Blog:

• «Eng Aféierung zu Kubernetes Netzwierkpolitike fir Sécherheetsprofesser";
• "En Illustréierte Guide fir Netzwierker a Kubernetes": Deeler 1 an 2 (Netzmodell, Overlay Netzwierker), Deel 3 (Servicer a Verkéiersveraarbechtung);
• «Container Networking Interface (CNI) - Netzwierk Interface a Standard fir Linux Container".

Source: will.com