Usare i criteri di rete calico per proteggere il traffico pod

Articolo
05/01/2024

Si applica a: Servizio Azure Kubernetes in Azure Stack HCI 22H2, servizio Azure Kubernetes in Windows Server

Usare questa guida dettagliata per verificare e provare la connettività pod-to-pod di base e per usare i criteri di rete Calico in un cluster in un servizio Azure Kubernetes abilitato dalla distribuzione di Azure Arc. Questo articolo descrive come creare pod client e server nei nodi Linux e Windows, verificare la connettività tra i pod e quindi applicare criteri di rete di base per isolare il traffico pod in AKS Arc.

Prerequisiti

Per distribuire AKS Arc, seguire la procedura per configurare un host del servizio Azure Kubernetes.

Per usare questa guida, è necessario:

Un cluster del carico di lavoro del servizio Azure Kubernetes.
Almeno un nodo di lavoro windows distribuito nel cluster.
Almeno un nodo di lavoro Linux distribuito nel cluster.
Il plug-in di rete Calico deve essere abilitato durante la creazione del cluster del carico di lavoro. Se questo plug-in non è stato abilitato, vedere New-AksHciCluster per istruzioni.

Create pod nei nodi Linux

Prima di tutto, creare un pod client, busybox e pod server, nginx, nei nodi Linux.

Create un file YAML denominato policy-demo-linux.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: calico-demo

---

apiVersion: v1
kind: Pod
metadata:
  labels:
    app: busybox
  name: busybox
  namespace: calico-demo
spec:
  containers:
  - args:
    - /bin/sh
    - -c
    - sleep 360000
    image: busybox:1.28
    imagePullPolicy: Always
    name: busybox
  nodeSelector:
    beta.kubernetes.io/os: linux

---

apiVersion: v1
kind: Pod
metadata:
  labels:
    app: nginx
  name: nginx
  namespace: calico-demo
spec:
  containers:
  - name: nginx
    image: nginx:1.8
    ports:
    - containerPort: 80
  nodeSelector:
    beta.kubernetes.io/os: linux

Applicare il file policy-demo-linux.yaml al cluster Kubernetes

Aprire una finestra di PowerShell e caricare le credenziali per il cluster di destinazione usando il Get-AksHciCredential comando .

kubectl Usare quindi per applicare la policy-demo-linux.yaml configurazione, come indicato di seguito:

kubectl apply -f policy-demo-linux.yaml

Create pod nei nodi Windows

Create un pod client pwsh e un pod server porter nei nodi Windows.

Nota

Il manifesto dei pod usa immagini basate su mcr.microsoft.com/windows/servercore:1809. Se si usa una versione di Windows Server più recente, aggiornare i manifesti per usare un'immagine Server Core corrispondente alla versione di Windows Server.

Create il criterio-demo-windows.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pwsh
  namespace: calico-demo
  labels:
    app: pwsh
spec:
  containers:
  - name: pwsh
    image: mcr.microsoft.com/windows/servercore:1809
    args:
    - powershell.exe
    - -Command
    - "Start-Sleep 360000"
    imagePullPolicy: IfNotPresent
  nodeSelector:
    kubernetes.io/os: windows
---
apiVersion: v1
kind: Pod
metadata:
  name: porter
  namespace: calico-demo
  labels:
    app: porter
spec:
  containers:
  - name: porter
    image: calico/porter:1809
    ports:
    - containerPort: 80
    env:
    - name: SERVE_PORT_80
      value: This is a Calico for Windows demo.
    imagePullPolicy: IfNotPresent
  nodeSelector:
    kubernetes.io/os: windows

Applicare il file policy-demo-windows.yaml al cluster Kubernetes

Aprire una finestra di PowerShell e caricare le credenziali per il cluster di destinazione usando il Get-AksHciCredential comando .

kubectl Usare quindi per applicare la policy-demo-windows.yaml configurazione:

kubectl apply -f policy-demo-windows.yaml

Verificare che i quattro pod vengano creati ed in esecuzione

Nota

A seconda della velocità di download di rete, potrebbe richiedere tempo per avviare i pod di Windows.

Aprire una finestra di PowerShell e caricare le credenziali per il cluster di destinazione usando il Get-AksHciCredential comando .

kubectl Usare quindi per elencare i pod nello calico-demo spazio dei nomi:

kubectl get pods --namespace calico-demo

L'output dovrebbe essere simile all'esempio seguente:

NAME      READY   STATUS              RESTARTS   AGE
busybox   1/1     Running             0          4m14s
nginx     1/1     Running             0          4m14s
porter    0/1     ContainerCreating   0          74s
pwsh      0/1     ContainerCreating   0          2m9s

Ripetere il comando ogni pochi minuti fino a quando l'output mostra tutti e quattro i pod nello stato Esecuzione.

NAME      READY   STATUS    RESTARTS   AGE
busybox   1/1     Running   0          7m24s
nginx     1/1     Running   0          7m24s
porter    1/1     Running   0          4m24s
pwsh      1/1     Running   0          5m19s

Controllare la connettività tra pod in linux e nodi Windows

Ora che i pod client e server vengono eseguiti in nodi Linux e Windows, verificare che i pod client nei nodi Linux possano raggiungere i pod server nei nodi Windows.

Aprire una finestra di PowerShell e caricare le credenziali per il cluster di destinazione usando il Get-AksHciCredential comando .

Usare kubectl per determinare l'indirizzo IP del pod porter:

kubectl get pod porter --namespace calico-demo -o 'jsonpath={.status.podIP}'

Accedere al pod busybox e provare a raggiungere il pod porter sulla porta 80. Sostituire il tag '<porter_ip>' con l'indirizzo IP restituito dal comando precedente.
```
kubectl exec --namespace calico-demo busybox -- nc -vz <porter_ip> 80
```
È anche possibile combinare entrambi i passaggi precedenti:
```
kubectl exec --namespace calico-demo busybox -- nc -vz $(kubectl get pod porter --namespace calico-demo -o 'jsonpath={.status.podIP}') 80
```
Se la connessione dal pod busybox al pod porter ha esito positivo, si ottiene l'output simile all'esempio seguente:
```
192.168.40.166 (192.168.40.166:80) open
```
Nota

Gli indirizzi IP restituiti possono variare a seconda della configurazione dell'ambiente.

Verificare che il pod pwsh possa raggiungere il pod nginx :

kubectl exec --namespace calico-demo pwsh -- powershell Invoke-WebRequest -Uri http://$(kubectl get po nginx -n calico-demo -o 'jsonpath={.status.podIP}') -UseBasicParsing -TimeoutSec 5

Se la connessione ha esito positivo, viene visualizzato l'output simile a:

StatusCode        : 200
StatusDescription : OK
Content           : <!DOCTYPE html>
                    <html>
                    <head>
                    <title>Welcome to nginx!</title>
                    <style>
                        body {
                            width: 35em;
                            margin: 0 auto;
                            font-family: Tahoma, Verdana, Arial, sans-serif;
                        }
                    </style>
                    <...

Verificare che il pod pwsh possa raggiungere il pod porter :

kubectl exec --namespace calico-demo pwsh -- powershell Invoke-WebRequest -Uri http://$(kubectl get po porter -n calico-demo -o 'jsonpath={.status.podIP}') -UseBasicParsing -TimeoutSec 5

In caso di esito positivo, viene visualizzato l'output simile all'esempio seguente:

StatusCode        : 200
StatusDescription : OK
Content           : This is a Calico for Windows demo.
RawContent        : HTTP/1.1 200 OK
                    Content-Length: 49
                    Content-Type: text/plain; charset=utf-8
                    Date: Fri, 21 Aug 2020 22:45:46 GMT

                    This is a Calico for Windows demo.
Forms             :
Headers           : {[Content-Length, 49], [Content-Type, text/plain;
                    charset=utf-8], [Date, Fri, 21 Aug 2020 22:45:46 GMT]}
Images            : {}
InputFields       : {}
Links             : {}
ParsedHtml        :
RawContentLength  : 49

È ora stato verificato che la comunicazione è possibile tra tutti i pod nell'applicazione.

Applicare i criteri al pod client Di Windows

In una distribuzione reale, si vuole assicurarsi che solo i pod che dovrebbero comunicare tra loro sono autorizzati a farlo. Per ottenere questo risultato, si applicano criteri di rete di base che consentono solo al pod busybox di raggiungere il pod porter .

Create il file network-policy.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-busybox
  namespace: calico-demo
spec:
  podSelector:
    matchLabels:
      app: porter
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: busybox
    ports:
    - protocol: TCP
      port: 80

Applicare il file network-policy.yaml

Aprire una finestra di PowerShell.
Caricare le credenziali per il cluster di destinazione usando il Get-AksHciCredential comando .
Usare kubectl per applicare il file network-policy.yaml:
```
kubectl apply -f network-policy.yaml
```

Verificare che il criterio sia effettivo

Con il criterio sul posto, il pod busybox deve comunque essere in grado di raggiungere il pod di porter . Come indicato in precedenza, è possibile combinare i passaggi nella riga di comando:

kubectl exec --namespace calico-demo busybox -- nc -vz $(kubectl get po porter -n calico-demo -o 'jsonpath={.status.podIP}') 80

Tuttavia, il pod pwsh non sarà in grado di raggiungere il pod porter :

kubectl exec --namespace calico-demo pwsh -- powershell Invoke-WebRequest -Uri http://$(kubectl get po porter -n calico-demo -o 'jsonpath={.status.podIP}') -UseBasicParsing -TimeoutSec 5

Il timeout della richiesta con un messaggio simile al seguente:

Invoke-WebRequest : The operation has timed out.
At line:1 char:1
+ Invoke-WebRequest -Uri http://192.168.40.166 -UseBasicParsing -Timeout ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:Htt
pWebRequest) [Invoke-WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
command terminated with exit code 1

In questa demo sono stati configurati pod in nodi Linux e Windows, è stata verificata la connettività dei pod di base e si è tentato di isolare il traffico pod-pod.

Come passaggio finale, è possibile pulire tutte le risorse demo:

kubectl delete namespace calico-demo

Passaggi successivi

In questo articolo si è appreso come proteggere il traffico tra pod usando i criteri di rete. Successivamente, sarà possibile:

Usare i criteri di rete calico per proteggere il traffico pod

Prerequisiti

Create pod nei nodi Linux

Create un file YAML denominato policy-demo-linux.yaml

Applicare il file policy-demo-linux.yaml al cluster Kubernetes

Create pod nei nodi Windows

Create il criterio-demo-windows.yaml

Applicare il file policy-demo-windows.yaml al cluster Kubernetes

Verificare che i quattro pod vengano creati ed in esecuzione

Controllare la connettività tra pod in linux e nodi Windows

Applicare i criteri al pod client Di Windows

Create il file network-policy.yaml

Applicare il file network-policy.yaml

Verificare che il criterio sia effettivo

Passaggi successivi

Commenti e suggerimenti

Commenti e suggerimenti

Risorse aggiuntive