Controllo del traffico tra i pod con le politiche Kubernetes

Cloud privato virtuale

Puoi utilizzare le politiche Kubernetes per controllare il traffico di rete tra i pod nel tuo cluster e per isolare i microservizi dell'applicazione l'uno dall'altro all'interno di uno spazio dei nomi o tra gli spazi dei nomi.

Livello di applicazione: endpoint host del nodo di lavoro

Comportamento predefinito: nel tuo cluster non esiste alcuna politica di rete Kubernetes per impostazione predefinita. Per impostazione predefinita, qualsiasi pod ha accesso a qualsiasi altro pod nel cluster. Inoltre, qualsiasi pod ha accesso a qualsiasi servizio esposto dalla rete di pod, come un servizio di metriche, il DNS del cluster, il server API o qualsiasi servizio che crei manualmente nel tuo cluster.

Caso di utilizzo: le politiche di rete Kubernetes specificano in che modo i pod possono comunicare con altri pod e con endpoint esterni. Sia il traffico di rete in entrata che quello in uscita può essere consentito o bloccato in base al protocollo, la porta o gli indirizzi IP di origine o destinazione. Il traffico può inoltre essere filtrato in base alle etichette di pod e spazio dei nomi. Quando le politiche di rete Kubernetes vengono applicate, vengono automaticamente convertite in politiche di rete Calico. Il plugin di rete Calico nel tuo cluster applica queste politiche configurando le regole di Linux Iptables sui nodi di lavoro. Le regole iptables fungono da firewall per il nodo di lavoro per definire le caratteristiche che il traffico di rete deve soddisfare per essere inoltrato alla risorsa di destinazione.

Se la maggior parte o tutti i pod non richiedono l'accesso a pod o servizi specifici e vuoi garantire che i pod per impostazione predefinita non possano accedere a questi pod o servizi, puoi creare una politica di rete Kubernetes per bloccare il traffico in ingresso a questi pod o servizi.

Per ulteriori informazioni su come le Kubernetes politiche di rete controllano il traffico da pod a pod e per ulteriori esempi di politiche, consultare la Kubernetes documentazione.

Isolamento dei servizi dell'applicazione all'interno di uno spazio dei nomi

Il seguente scenario dimostra come gestire il traffico tra i microservizi dell'applicazione all'interno di uno spazio dei nomi.

Un team Accounts distribuisce più servizi dell'applicazione in uno spazio dei nomi, ma devono essere isolati per consentire solo le comunicazioni necessarie tra i microservizi sulla rete pubblica. Per l'applicazione Srv1, il team ha servizi di front-end, back-end e database. Ogni servizio viene etichettato con l'etichetta app: Srv1 e l'etichetta tier: frontend, tier: backend o tier: db.

Utilizzare una politica di rete per gestire il traffico tra spazi dei nomi.
Utilizzare una politica di rete per gestire il traffico dello spazio dei nomi

Il team Accounts vuole consentire il traffico dal front-end al back-end e dal back-end al database. Usano le etichette nelle loro politiche di rete per indicare quali flussi di traffico sono consentiti tra i microservizi.

Innanzitutto, creano una politica di rete Kubernetes che consente il traffico dal front-end al back-end:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-allow
spec:
  podSelector:
    matchLabels:
      app: Srv1
      tier: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: Srv1
          Tier: frontend

La spec.podSelector.matchLabels sezione elenca le etichette per il servizio Srv1 back-end in modo che la politica si applichi solo a quei pod. La spec.ingress.from.podSelector.matchLabels sezione elenca le etichette per il servizio Srv1 front-end in modo che l'ingresso sia consentito solo da quei pod.

Quindi, creano una politica di rete Kubernetes simile che consente il traffico dal back-end al database:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: db-allow
spec:
  podSelector:
    matchLabels:
      app: Srv1
      tier: db
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: Srv1
          Tier: backend

La spec.podSelector.matchLabels sezione elenca le etichette per il servizio Srv1 database in modo che la policy si applichi solo a quei pod. La spec.ingress.from.podSelector.matchLabels sezione elenca le etichette per il servizio Srv1 back-end in modo che l'ingresso sia consentito solo da quei pod.

Il traffico può ora transitare dal front-end al back-end e dal back-end al database. Il database può rispondere al back-end e il back-end può rispondere al front-end, ma non è possibile stabilire connessioni di traffico inverso.

Isolamento dei servizi dell'applicazione tra gli spazi dei nomi

Il seguente scenario dimostra come gestire il traffico tra i microservizi dell'applicazione tra più spazi dei nomi.

I servizi di proprietà di diversi sottogruppi devono comunicare tra loro, ma sono distribuiti in spazi dei nomi diversi all'interno dello stesso cluster. Il team Accounts distribuisce i servizi di front-end, back-end e database per l'applicazione Srv1 nello spazio dei nomi accounts. Il team Finance distribuisce i servizi di front-end, back-end e database per l'applicazione Srv2 nello spazio dei nomi finance. Entrambi i team etichettano ciascun servizio con l'etichetta app: Srv1 o app: Srv2 e l'etichetta tier: frontend, tier: backend o tier: db. Etichettano anche gli spazi dei nomi con l'etichetta usage: accounts o usage: finance.

Utilizzare una politica di rete per gestire il traffico tra spazi dei nomi.
Utilizzare una politica di rete per gestire il traffico tra spazi dei nomi

Srv2 del team Finance deve richiamare le informazioni dal back-end Srv1 del team Accounts. Quindi il team Accounts crea una politica di rete Kubernetes che usa le etichette per consentire tutto il traffico dallo spazio dei nomi finance al back-end Srv1 nello spazio dei nomi accounts. Il team specifica anche la porta 3111 per isolare l'accesso tramite solo tale porta.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  Namespace: accounts
  name: accounts-allow
spec:
  podSelector:
    matchLabels:
      app: Srv1
      Tier: backend
  ingress:
  - from:
    - NamespaceSelector:
        matchLabels:
          usage: finance
      ports:
        port: 3111

La spec.podSelector.matchLabels sezione elenca le etichette per il servizio Srv1 back-end in modo che la politica si applichi solo a quei pod. La spec.ingress.from.NamespaceSelector.matchLabels sezione elenca l'etichetta per lo spazio dei nomi finance in modo che l'ingresso sia consentito solo dai servizi in quello spazio dei nomi.

Il traffico può ora transitare dai microservizi finance al back-end Srv1 accounts. Il back-end Srv1 accounts può rispondere ai microservizi finance, ma non può stabilire una connessione di traffico inverso.

In questo esempio, è consentito tutto il traffico proveniente da tutti i microservizi nello spazio dei nomi finance. Non puoi consentire il traffico da specifici pod dell'applicazione in un altro spazio dei nomi in quanto podSelector e namespaceSelector non possono essere combinati.