Calico pikeun jaringan di Kubernetes: bubuka sareng pangalaman sakedik

Tujuan tina artikel nyaéta pikeun ngenalkeun pamaca kana dasar-dasar jaringan sareng ngatur kawijakan jaringan di Kubernetes, ogé plugin Calico pihak katilu anu ngalegaan kamampuan standar. Sapanjang jalan, betah konfigurasi sareng sababaraha fitur bakal ditingalikeun nganggo conto nyata tina pangalaman operasi urang.

Perkenalan gancang pikeun alat jaringan Kubernetes

Kluster Kubernetes teu tiasa dibayangkeun tanpa jaringan. Kami parantos nyebarkeun bahan dina dasarna: "Pitunjuk gambar pikeun jejaring di Kubernetes"Jeung"Perkenalan kana Kabijakan Jaringan Kubernetes pikeun Profesional Kaamanan".

Dina kontéks artikel ieu, penting pikeun dicatet yén K8s sorangan henteu tanggung jawab konektipitas jaringan antara wadah sareng titik: pikeun ieu, sagala rupa plugins CNI (Kontainer Networking Interface). Langkung lengkep ihwal konsep ieu urang aranjeunna ogé ngawartoskeun kuring.

Salaku conto, anu paling umum tina plugins ieu nyaéta Flannel - nyadiakeun konektipitas jaringan pinuh antara sakabéh titik klaster ku raising sasak dina unggal titik, assigning a subnet ka dinya. Sanajan kitu, aksés lengkep jeung unregulated teu salawasna mangpaat. Pikeun nyadiakeun sababaraha jenis isolasi minimal dina klaster, perlu pikeun campur dina konfigurasi firewall nu. Dina kasus umum, eta disimpen dina kadali CNI sarua, naha nu mana wae nu interventions pihak-katilu di iptables bisa diinterpretasi leres atanapi dipaliré sakabehna.

Jeung "out of the box" pikeun ngatur manajemén kawijakan jaringan dina klaster Kubernetes disadiakeun NetworkPolicy API. Sumberdaya ieu, disebarkeun dina spasi ngaran anu dipilih, tiasa ngandung aturan pikeun ngabédakeun aksés tina hiji aplikasi ka aplikasi anu sanés. Éta ogé ngamungkinkeun anjeun pikeun ngonpigurasikeun aksés antara pods khusus, lingkungan (spasi ngaran) atanapi blok alamat 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

Ieu sanés conto anu paling primitif dokuméntasi resmi bisa sakali jeung sakabeh discourage kahayang pikeun ngarti logika kumaha kawijakan jaringan jalan. Nanging, urang masih bakal nyobian ngartos prinsip dasar sareng metode ngolah lalu lintas nganggo kawijakan jaringan...

Logis yén aya 2 jinis lalu lintas: asup ka pod (Ingress) sareng kaluar ti dinya (Egress).

Sabenerna, pulitik dibagi kana 2 kategori ieu dumasar kana arah gerakan.

Atribut diperlukeun salajengna nyaeta pamilih a; saha nu aturan lumaku. Ieu bisa mangrupa pod (atawa grup pods) atawa lingkungan (ie a namespace). Rincian anu penting: kadua jinis objék ieu kedah ngandung labél (etiket dina terminologi Kubernetes) - ieu mangrupikeun anu dianggo ku politikus.

Salian sajumlah terbatas pamilih anu dihijikeun ku sababaraha jinis labél, tiasa waé nyerat aturan sapertos "Ngidinan / mungkir sadayana / sadayana" dina variasi anu béda. Pikeun tujuan ieu, konstruksi bentuk dianggo:

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

- dina conto ieu, sadaya pods di lingkungan diblokir tina lalulintas asup. Paripolah sabalikna tiasa dihontal ku konstruksi ieu:

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

Kitu ogé pikeun kaluar:

  podSelector: {}
  policyTypes:
  - Egress

- pikeun mareuman. Sareng ieu anu kalebet:

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

Balik deui ka pilihan plugin CNI pikeun klaster, éta sia noting yén teu unggal plugin jaringan ngarojong NetworkPolicy. Contona, Flannel geus disebutkeun teu nyaho kumaha carana ngonpigurasikeun kawijakan jaringan, nu eta ceuk langsung dina gudang resmi. Alternatipna ogé disebatkeun di dinya - proyék Open Source Calico, anu sacara signifikan ngalegaan set standar API Kubernetes dina hal kawijakan jaringan.

Ngauningaan Calico: téori

Plugin Calico tiasa dianggo dina integrasi sareng Flannel (subproyek solokan gede) atawa mandiri, ngawengku duanana konektipitas jaringan jeung kamampuhan manajemén kasadiaan.

kasempetan naon ngagunakeun K8s "boxed" solusi jeung set API ti Calico nyadiakeun?

Ieu naon anu diwangun kana NetworkPolicy:

• politikus diwatesan ku lingkungan;
• kawijakan dilarapkeun ka pods ditandaan ku labél;
• aturan bisa dilarapkeun ka pods, lingkungan atawa subnets;
• aturan bisa ngandung protokol, ngaranna atawa spésifikasi port simbolis.

Kieu kumaha Calico ngalegaan fungsi ieu:

• kawijakan bisa dilarapkeun ka objék naon: pod, wadahna, mesin virtual atawa panganteur;
• aturan bisa ngandung hiji aksi husus (larangan, idin, logging);
• udagan atawa sumber aturan bisa port a, sauntuyan palabuhan, protokol, HTTP atawa atribut ICMP, IP atawa subnet (generasi 4 atawa 6), sagala pamilih (titik, host, lingkungan);
• Salaku tambahan, anjeun tiasa ngatur lalu lintas nganggo setélan DNAT sareng kawijakan neraskeun lalu lintas.

Kahiji commits on GitHub dina Repository Calico tanggal deui ka Juli 2016, sarta sataun saterusna proyek nyandak posisi ngarah dina pangatur konektipitas jaringan Kubernetes - ieu dibuktikeun, contona, ku hasil survéy, dilakukeun ku The New Stack:

Loba solusi junun badag kalayan K8s, kayaning Amazon EKS, Azure AKS, Google GKE jeung nu lianna mimiti nyarankeun eta pikeun pamakéan.

Sedengkeun pikeun pagelaran, sagalana hébat dieu. Dina nguji produkna, tim pamekaran Calico nunjukkeun pagelaran astronomis, ngajalankeun langkung ti 50000 wadah dina 500 titik fisik kalayan laju nyiptakeun 20 wadah per detik. Henteu aya masalah anu diidentifikasi sareng skala. Hasilna kitu diumumkeun geus di pengumuman tina versi munggaran. Studi mandiri anu museurkeun kana throughput sareng konsumsi sumber daya ogé mastikeun yén kinerja Calico ampir saé sapertos Flannel. contona:

Proyék ieu ngembang pisan gancang, éta ngarojong gawé dina solusi populér junun K8s, OpenShift, OpenStack, kasebut nyaéta dimungkinkeun pikeun ngagunakeun Calico nalika deploying klaster maké. kops, aya rujukan pikeun pangwangunan jaringan Service Mesh (ieu mangrupikeun conto dipaké babarengan jeung Istio).

Latihan kalawan Calico

Dina kasus umum ngagunakeun vanili Kubernetes, masang CNI turun ka ngagunakeun file calico.yaml, diundeur ti ramatloka resmi, ku ngagunakeun kubectl apply -f.

Sakumaha aturan, versi plugin ayeuna cocog sareng 2-3 versi panganyarna tina Kubernetes: operasi dina versi heubeul teu diuji sarta teu dijamin. Numutkeun para pamekar, Calico dijalankeun dina kernel Linux di luhur 3.10 ngajalankeun CentOS 7, Ubuntu 16 atanapi Debian 8, di luhur iptables atanapi IPVS.

Isolasi dina lingkungan

Pikeun pamahaman umum, hayu urang tingali hiji pasualan basajan pikeun ngarti kumaha kawijakan jaringan dina notasi Calico béda ti standar jeung kumaha pendekatan nyieun aturan simplifies readability tur kalenturan konfigurasi maranéhna:

Aya 2 aplikasi wéb anu disebarkeun dina kluster: dina Node.js sareng PHP, salah sahijina nganggo Redis. Pikeun meungpeuk aksés ka Redis tina PHP, bari ngajaga konektipitas sareng Node.js, ngan ukur nerapkeun kawijakan ieu:

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

Intina kami diwenangkeun lalulintas asup ka port Redis ti Node.js. Jeung maranéhna jelas teu nyaram nanaon sejenna. Pas NetworkPolicy némbongan, sadaya pamilih anu disebatkeun di dinya ngawitan diisolasi, iwal mun disebutkeun. Sanajan kitu, aturan isolasi teu dilarapkeun ka objék séjén teu katutupan ku pamilih nu.

Contona ngagunakeun apiVersion Kubernetes out of the box, tapi teu aya anu nyegah anjeun ngagunakeunana sumberdaya nu ngaranna sarua ti pangiriman Calico. Sintaksis aya langkung rinci, janten anjeun kedah nyerat deui aturan pikeun kasus di luhur dina bentuk ieu:

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

Konstruksi anu disebatkeun di luhur pikeun ngawenangkeun atanapi nolak sadaya lalu lintas ngalangkungan API NetworkPolicy biasa ngandung konstruk sareng kurung anu hese ngartos sareng diinget. Dina kasus Calico, pikeun ngarobah logika aturan firewall ka sabalikna, ngan robah action: Allow dina action: Deny.

Isolasi ku lingkungan

Ayeuna bayangkeun kaayaan dimana aplikasi ngahasilkeun métrik bisnis pikeun koleksi di Prometheus sareng analisa salajengna nganggo Grafana. Unggahan éta tiasa ngandung data sénsitip, anu tiasa ditingali deui sacara umum sacara standar. Hayu urang nyumputkeun data ieu tina prying panon:

Prometheus, sakumaha aturan, ditempatkeun dina lingkungan layanan misah - dina conto eta bakal namespace kawas kieu:

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

médan metadata.labels ieu tétéla teu kacilakaan. Sakumaha didadarkeun di luhur, namespaceSelector (sakumaha ogé podSelector) beroperasi kalawan labél. Ku alatan éta, pikeun ngidinan métrik dicokot tina sakabéh pods dina port husus, Anjeun kudu nambahkeun sababaraha jenis labél (atawa nyokot tina nu geus aya), lajeng nerapkeun konfigurasi kawas:

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

Sareng upami anjeun nganggo kawijakan Calico, sintaksisna bakal sapertos kieu:

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

Sacara umum, ku nambihan kawijakan sapertos ieu pikeun kabutuhan khusus, anjeun tiasa ngajagaan tina gangguan anu jahat atanapi teu kahaja dina operasi aplikasi dina kluster.

Praktek anu pangsaéna, numutkeun panyipta Calico, nyaéta pendekatan "Blok sadayana sareng sacara eksplisit muka naon anu anjeun peryogikeun", didokumentasikeun dina dokuméntasi resmi (batur nuturkeun pendekatan anu sami - khususna, di geus disebutkeun artikel).

Ngagunakeun Objék Calico tambahan

Hayu atuh ngingetan yén ngaliwatan set nambahan Calico API anjeun bisa ngatur kasadiaan titik, teu diwatesan ka pods. Dina conto di handap ieu ngagunakeun GlobalNetworkPolicy Kamampuhan pikeun ngalangkungan pamundut ICMP dina kluster ditutup (contona, ping tina pod ka titik, antara pods, atanapi tina titik ka pod 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

Dina kasus di luhur, masih mungkin pikeun titik klaster "ngahontal" ka silih via ICMP. Sareng masalah ieu direngsekeun ku cara GlobalNetworkPolicy, dilarapkeun ka hiji éntitas 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"]

Kasus VPN

Tungtungna, abdi bakal masihan conto pisan nyata ngagunakeun fungsi Calico pikeun kasus interaksi deukeut-cluster, lamun susunan standar kawijakan teu cukup. Pikeun ngaksés aplikasi wéb, klien nganggo torowongan VPN, sareng aksés ieu dikontrol ketat sareng dugi ka daptar jasa khusus anu diidinan dianggo:

Klién nyambung ka VPN liwat port UDP standar 1194 sareng, nalika disambungkeun, nampi rute ka subnet kluster pods sareng jasa. Sakabéh subnet didorong supados henteu kaleungitan jasa nalika ngamimitian deui sareng parobihan alamat.

Pelabuhan dina konfigurasi nyaéta standar, anu nyababkeun sababaraha nuansa dina prosés ngonpigurasikeun aplikasi sareng nransferkeunana kana klaster Kubernetes. Contona, dina sarua AWS LoadBalancer pikeun UDP mucunghul sacara harfiah dina ahir taun ka tukang dina daptar kawates wewengkon, sarta NodePort teu bisa dipaké alatan diteruskeun na dina sakabéh titik klaster sarta mustahil mun skala jumlah instansi server pikeun. tujuan toleransi kasalahan. Tambih Deui, anjeun kedah ngarobih kisaran standar port ...

Salaku hasil tina milarian solusi anu mungkin, ieu dipilih:

1. Pods sareng VPN dijadwalkeun per node in hostNetwork, nyaeta, ka IP sabenerna.
2. jasa ieu dipasang di luar ngaliwatan ClusterIP. Pelabuhan dipasang sacara fisik dina node, anu tiasa diaksés ti luar kalayan pesenan minor (aya saratna alamat IP nyata).
3. Nangtukeun titik dimana ros pod di luar ruang lingkup carita urang. Kuring ngan bakal nyebutkeun yén anjeun bisa pageuh "paku" jasa kana titik atawa nulis ladenan sidecar leutik anu bakal ngawas alamat IP ayeuna tina layanan VPN tur ngédit rékaman DNS didaptarkeun ku klien - saha anu boga imajinasi cukup.

Tina sudut pandang routing, urang tiasa ngaidentipikasi klien VPN sacara unik ku alamat IPna anu dikaluarkeun ku server VPN. Di handap ieu conto primitif pikeun ngawatesan aksés klien sapertos kana jasa, digambarkeun dina Redis anu disebut di luhur:

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]

Di dieu, ngahubungkeun ka port 6379 mastikeun dilarang, tapi dina waktos anu sareng operasi layanan DNS dilestarikan, anu fungsina mindeng sangsara nalika nyieun aturan. Kusabab, sakumaha anu disebatkeun sateuacana, nalika pamilih némbongan, kabijakan nolak standar diterapkeun ka dinya iwal mun disebutkeun.

hasil

Ku kituna, ngagunakeun API canggih Calico urang, anjeun flexibly bisa ngonpigurasikeun tur dinamis ngarobah routing di na sabudeureun kluster. Sacara umum, pamakéan na bisa kasampak kawas shooting sparrows kalawan mariem a, sarta ngalaksanakeun hiji jaringan L3 kalawan BGP na IP-IP torowongan Sigana monstrous dina instalasi Kubernetes basajan dina jaringan datar ... Sanajan kitu, disebutkeun alat nu Sigana rada giat tur mangpaat. .

Ngasingkeun klaster pikeun nyumponan sarat kaamanan henteu salawasna tiasa dilaksanakeun, sareng ieu tempatna Calico (atanapi solusi anu sami) nyalametkeun. Conto anu dipasihkeun dina tulisan ieu (kalayan modifikasi leutik) dianggo dina sababaraha pamasangan klien kami di AWS.

PS

Baca ogé dina blog urang:

• «Perkenalan kana Kabijakan Jaringan Kubernetes pikeun Profesional Kaamanan";
• "Panduan Gambar pikeun Jaringan di Kubernetes": bagian 1 jeung 2 (model jaringan, jaringan overlay), bagian 3 (jasa sareng pamrosésan lalu lintas);
• «Container Networking Interface (CNI) - panganteur jaringan sareng standar pikeun wadah Linux".

sumber: www.habr.com