Calico för nätverk i Kubernetes: introduktion och lite erfarenhet

Syftet med den här artikeln är att introducera läsaren till grunderna för nätverks- och nätverkspolicyhantering i Kubernetes, samt till tredjeparts plugin Calico, som utökar standardfunktionerna. Längs vägen kommer bekvämligheten med konfiguration och vissa funktioner att demonstreras med hjälp av verkliga exempel från vår driftserfarenhet.

En snabb introduktion till Kubernetes Networking

Det är omöjligt att föreställa sig ett Kubernetes-kluster utan ett nätverk. Vi har redan publicerat material om deras grunder: "En illustrerad guide till Kubernetes-nätverk"Och"En introduktion till Kubernetes nätverkspolicyer för säkerhetspersonal".

I samband med denna artikel är det viktigt att notera att K8s själv inte är ansvarig för nätverksanslutning mellan behållare och noder: den använder olika CNI-plugins (Container Networking Interface). Vi kommer att lära oss mer om detta koncept de berättade också för mig.

Till exempel är den vanligaste av dessa plugins Flanell - ger full nätverksanslutning mellan alla klusternoder genom att höja bryggor på varje nod, tilldela ett subnät till den. Men fullständig och oreglerad tillgänglighet är inte alltid fördelaktigt. För att ge en viss minimal isolering i klustret är det nödvändigt att ingripa i brandväggskonfigurationen. I allmänhet ges den under kontroll av samma CNI, på grund av vilken tredje parts ingripanden i iptables kan tolkas felaktigt eller ignoreras helt.

Och "out of the box" för att organisera nätverkspolicyhantering i ett Kubernetes-kluster tillhandahålls NetworkPolicy API. Den här resursen, som sträcker sig över utvalda namnutrymmen, kan innehålla regler för att begränsa åtkomst från ett program till ett annat. Det låter dig också konfigurera tillgänglighet mellan specifika pods, miljöer (namnutrymmen) eller IP-adressblock:

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

Detta är inte det mest primitiva exemplet på officiell dokumentation kan en gång för alla avskräcka dig från att försöka förstå logiken bakom hur nätverkspolicyer fungerar. Men vi kommer fortfarande att försöka förstå de grundläggande principerna och metoderna för att behandla trafikflöden med hjälp av nätverkspolicyer...

Det är logiskt att det finns två typer av trafik: inkommande till podden (Ingress) och utgående från den (Egress).

Faktum är att politiken delas in i dessa två kategorier efter rörelseriktningen.

Nästa obligatoriska attribut är väljaren; den som regeln gäller. Detta kan vara en pod (eller grupp av pods) eller en miljö (dvs. ett namnområde). Viktig detalj: båda typerna av dessa objekt måste innehålla en etikett (etikett i Kubernetes terminologi) — det är de som policyer fungerar med.

Förutom det ändliga antalet väljare förenade av någon etikett, finns det möjlighet att skriva regler som "Tillåt/neka alla/alla" i olika varianter. För detta ändamål används konstruktioner av följande typ:

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

- i det här exemplet nekas alla poddar i miljön inkommande trafik. Det motsatta beteendet kan uppnås med denna konstruktion:

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

Likaså för utgående:

  podSelector: {}
  policyTypes:
  - Egress

– för att stänga av den. Och här är vad du ska aktivera:

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

För att återgå till valet av CNI-plugin för klustret är det värt att notera det Inte alla nätverksplugin stöder arbete med NetworkPolicy. Till exempel kan den redan nämnda Flannel inte konfigurera nätverkspolicyer, vilket är det sägs direkt i det officiella arkivet. Där nämns också ett alternativ - Open Source-projektet Kalikå, vilket avsevärt utökar standarden Kubernetes API när det gäller nätverkspolicyer.

Lär känna Calico: Teori

Calico plugin kan användas i integration med Flannel (delprojekt Canal) eller oberoende, som täcker både funktionerna att säkerställa nätverksanslutning och funktionerna för tillgänglighetshantering.

Vilka möjligheter ger användningen av den färdiga K8s-lösningen och API-setet från Calico?

Här är vad som är inbyggt i NetworkPolicy:

• politiker begränsas av sin omgivning;
• policyer tillämpas på kapslar märkta med etiketter;
• regler kan tillämpas på pods, miljöer eller subnät;
• Regler kan innehålla protokoll, namngivna eller symboliska portreferenser.

Så här utökar Calico dessa funktioner:

• policyer kan tillämpas på alla objekt: pod, container, virtuell maskin eller gränssnitt;
• regler kan innehålla en specifik åtgärd (förbud, tillstånd, loggning);
• målet eller källan till regler kan vara en port, portintervall, protokoll, HTTP- eller ICMP-attribut, IP eller subnät (4:e eller 6:e ​​generationen), valfri väljare (noder, värdar, miljöer);
• Dessutom kan du reglera trafikflödet med hjälp av DNAT-inställningar och policyer för vidarebefordran av trafik.

De första commits på GitHub i Calico-förvaret går tillbaka till juli 2016, och ett år senare tog projektet en ledande position när det gäller att organisera Kubernetes nätverksanslutning - detta framgår till exempel av resultaten av en undersökning, under ledning av The New Stack:

Många stora hanterade lösningar med K8:or, som t.ex Amazon EX, Azure AKS, Googla GKE och andra började rekommendera den för användning.

När det gäller prestanda är allt bra. När de testade sin produkt visade Calicos utvecklingsteam astronomiska prestanda och lanserade över 50000 500 behållare på 20 fysiska noder med en hastighet av XNUMX behållare per sekund. Inga skalningsproblem hittades. Det här är resultaten röstades redan vid tillkännagivandet av den första versionen. Oberoende studier med fokus på genomströmning och resursförbrukning bekräftar också att Calicos prestanda är nästan lika bra som Flannels. Till exempel:

Projektet utvecklas mycket snabbt, stöder arbete i populära lösningar som hanteras K8s, OpenShift, OpenStack, det är möjligt att använda Calico när du distribuerar ett kluster med sparka, det nämns om att bygga Service Mesh-nätverk (här är ett exempel (för användning tillsammans med Istio).

Träna med Calico

I det allmänna fallet med att använda vanilla Kubernetes, kommer installationen av CNI till att använda filen calico.yaml, laddas ner från den officiella webbplatsen, genom att använda kubectl apply -f.

Vanligtvis är den nuvarande versionen av pluginet kompatibel med de två eller tre senaste versionerna av Kubernetes; kompatibilitet med äldre versioner är inte testad eller garanterad. Enligt utvecklarna körs Calico på kärnan. Linux över 3.10 under kontroll CentOS 7, Ubuntu 16 eller Debian 8, över iptables eller IPVS.

Isolering inom miljön

För en allmän förståelse, låt oss titta på ett enkelt fall för att förstå hur nätverkspolicyer i Calico-notation skiljer sig från standard och hur tillvägagångssättet för att komponera regler förenklar deras läsbarhet och konfigurationsflexibilitet:

Klustret har två webbapplikationer utplacerade: Node.js och PHP, varav en använder Redis. För att stänga åtkomsten till Redis från PHP samtidigt som du bibehåller anslutning till Node.js, tillämpa helt enkelt följande policy:

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

I huvudsak har vi tillåtit inkommande trafik till Redis-hamnen från Node.js. Och de förbjöd uppenbarligen inget annat. När en nätverkspolicy dyker upp är alla väljare som nämns i den isolerade om inte annat anges. Isoleringsreglerna gäller dock inte andra objekt som inte omfattas av väljaren.

Exemplet använder apiVersion Kubernetes ur lådan, men ingenting hindrar dig från att använda den resurs med samma namn från Calico-leveransen. Syntaxen där är mer detaljerad, så du måste skriva om regeln för ovanstående fall enligt följande:

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

Ovan nämnda konstruktioner för att tillåta eller neka all trafik via det vanliga NetworkPolicy API innehåller konstruktioner med parenteser som är svåra att förstå och komma ihåg. När det gäller Calico, för att ändra logiken i en brandväggsregel till det motsatta, räcker det att ändra action: Allow på action: Deny.

Isolering av miljön

Låt oss nu föreställa oss en situation där applikationen genererar affärsmått för insamling i Prometheus och vidare analys via Grafana. Nedladdningen kan innehålla känslig data, som återigen är allmänt tillgänglig som standard. Låt oss dölja denna information från nyfikna ögon:

Prometheus placeras vanligtvis i en separat tjänstemiljö - i exemplet skulle detta vara ett namnområde av följande typ:

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

Fält metadata.labels Det visade sig att detta inte var en slump. Som nämnts ovan, namespaceSelector (liksom podSelector) driver etiketter. Så för att tillåta att mätvärden samlas in från alla pods på en specifik port, måste du lägga till en etikett (eller ta en från de befintliga) och sedan tillämpa en konfiguration som:

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

Och om du använder Calico-policyer blir syntaxen:

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

I allmänhet, genom att lägga till policyer av detta slag för specifika behov, kan du skydda mot skadlig eller oavsiktlig störning i driften av applikationer i klustret.

Den bästa praxisen, enligt skaparna av Calico, är "Förbjud allt och öppna uttryckligen vad som är nödvändigt", som dokumenterats i officiell dokumentation (Ett liknande tillvägagångssätt används av andra, i synnerhet, redan nämnda artikel).

Använda ytterligare Calico-objekt

Låt mig påminna dig om att genom den utökade uppsättningen av Calico API:er kan du reglera tillgängligheten av noder, inte begränsat till pods. I följande exempel använder du GlobalNetworkPolicy möjligheten att skicka ICMP-förfrågningar i klustret är stängd (till exempel pingar från en pod till en nod, mellan pods eller från en nod till en pods 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

I fallet ovan är det fortfarande möjligt för klusternoder att "nå" varandra via ICMP. Och detta problem löses med hjälp av medel GlobalNetworkPolicy, tillämpas på enheten 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"]

VPN-fallet

Slutligen kommer jag att ge ett mycket verkligt exempel på att använda Calico-funktioner för ett fall av nära-klusterinteraktion, när standarduppsättningen policyer inte räcker. Klienter använder en VPN-tunnel för att komma åt webbapplikationen, och denna åtkomst är strikt kontrollerad och begränsad till en specifik lista över tjänster som är tillåtna att användas:

Klienter ansluter till VPN via standard UDP-port 1194 och tar vid anslutning emot rutter till klusterundernäten av pods och tjänster. Subnät pushas i sin helhet för att undvika att förlora tjänster vid omstarter och adressändringar.

Porten i konfigurationen är standard, vilket lägger vissa nyanser på processen att konfigurera applikationen och överföra den till Kubernetes-klustret. Till exempel, i samma AWS dök LoadBalancer för UDP upp bokstavligen i slutet av förra året i en begränsad lista över regioner, och NodePort kan inte användas eftersom den vidarebefordras till alla klusternoder och det är omöjligt att skala antalet serverinstanser för feltoleransändamål. Dessutom måste du ändra standardportintervallet...

Som ett resultat av att räkna upp möjliga lösningar valdes följande:

1. Pods med VPN är schemalagda till en nod i läget hostNetwork, det vill säga till den faktiska IP-adressen.
2. Tjänsten postas utanför genom ClusterIP. En port är fysiskt upphöjd på noden, som är tillgänglig från utsidan med vissa reservationer (villkorad närvaro av en riktig IP-adress).
3. Att bestämma noden på vilken podden körs ligger utanför ramen för vår diskussion. Jag kommer bara att säga att du kan koppla tjänsten till noden eller skriva en liten sidovagnstjänst som kommer att övervaka den aktuella IP-adressen för VPN-tjänsten och redigera DNS-posterna som registrerats av klienter - vad din fantasi än tillåter.

Ur ett routingperspektiv kan vi unikt identifiera en klient bakom ett VPN genom dess IP-adress som tillhandahålls av VPN-servern. Nedan är ett primitivt exempel på begränsning av åtkomst till tjänster för en sådan klient, illustrerad med ovannämnda 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]

Här är anslutningar till port 6379 strängt förbjudna, men DNS-tjänsten, som ofta blir lidande när regler skapas, är fortfarande i drift. Eftersom, som tidigare nämnts, när en väljare dyker upp, tillämpas den förinställda förbudspolicyn på den om inte annat anges.

Resultat av

Med hjälp av Calicos utökade API kan du alltså flexibelt konfigurera och dynamiskt ändra routing i och runt ditt kluster. Generellt sett kan dess användning se ut som att skjuta en kanon mot sparvar, och implementeringen av ett L3-nätverk med BGP- och IP-IP-tunnlar ser monstruöst ut i en enkel Kubernetes-installation i ett platt nätverk... Men i andra avseenden ser verktyget ganska lönsamt och användbart ut.

Det är kanske inte alltid möjligt att isolera ett kluster för att uppfylla säkerhetskraven, och det är här Calico (eller en liknande lösning) kommer till undsättning. Exemplen som ges i artikeln (med mindre modifieringar) används i flera av våra kunders installationer i AWS.

PS

Läs även på vår blogg:

• «En introduktion till Kubernetes nätverkspolicyer för säkerhetspersonal";
• "En illustrerad guide till nätverk i Kubernetes": del 1 och 2 (nätverksmodell, överläggsnätverk), del 3 (tjänster och trafikhantering);
• «Container Networking Interface (CNI) är ett nätverksgränssnitt och en standard för Linux-behållare".

Källa: will.com