Installazione del componente aggiuntivo del motore di policy di rete Calico - Amazon EKS
Installazione di CalicoDemo policy Stars Remove Calico

Installazione del componente aggiuntivo del motore di policy di rete Calico

Project Calico è un motore di policy di rete per Kubernetes. Con l'applicazione della policy di rete Calico, puoi implementare la segmentazione della rete e l'isolamento dei tenant. Questa funzione è utile in ambienti multi-tenant, in cui è necessario isolare i tenant tra loro oppure quando si desidera creare ambienti separati per lo sviluppo, la gestione temporanea e la produzione. Le policy di rete sono simili ai gruppi di sicurezza AWS, nel senso che è possibile creare regole di rete in ingresso e in uscita. Invece di assegnare le istanze a un gruppo di sicurezza, si assegnano policy di rete ai pods utilizzando selettori di pod ed etichette.

Considerazioni

  • Calico non è supportato quando si utilizza Fargate con Amazon EKS.

  • Calico aggiunge regole a iptables sul nodo che potrebbero avere una priorità maggiore rispetto alle regole esistenti già implementate al di fuori di Calico. Considera l'aggiunta delle regole iptables esistenti alle policy Calico per evitare che le regole al di fuori della policy Calico vengano sovrascritte da Calico.

  • Se utilizzi la versione 1.10 o precedente del componente aggiuntivo CNI di Amazon VPC, il flusso di traffico dai gruppi di sicurezza per pods verso i pods sulle interfacce di rete di filiali non è soggetto all'applicazione delle policy di rete Calico ed è limitato esclusivamente all'applicazione dei gruppi di sicurezza di Amazon EC2. Se utilizzi la versione 1.11.0 o successiva del componente aggiuntivo CNI di Amazon VPC, il flusso di traffico verso i pods sulle interfacce di rete di filiali è soggetto all'applicazione delle policy di rete Calico, se imposti POD_SECURITY_GROUP_ENFORCING_MODE=standard per il componente aggiuntivo CNI di Amazon VPC.

  • L'impostazione della famiglia IP per il cluster deve essere IPv4. Non puoi utilizzare il componente aggiuntivo Calico Network Policy Engine se il tuo cluster è stato creato per utilizzare la famiglia IPv6.

Prerequisiti

  • Un cluster Amazon EKS esistente. Per implementarne uno, consulta Guida introduttiva ad Amazon EKS.

  • Lo strumento a riga di comando kubectl è installato sul dispositivo o AWS CloudShell. La versione può essere uguale, o immediatamente precedente o successiva, alla versione Kubernetes del cluster. Ad esempio, se la versione del cluster è 1.23, puoi usare kubectl versione 1.22, 1.23 o 1.24. Per installare o aggiornare kubectl, consulta Installazione o aggiornamento di kubectl:

La procedura seguente illustra come installare Calicosui nodi Linux nel cluster Amazon EKS. Per installare Calico sui nodi Windows, consulta Utilizzo diCalico su container Windows di Amazon EKS.

Installazione di Calico sui nodi Linux di Amazon EKS

Importante

Amazon EKS non conserva i manifesti o i grafici utilizzati nelle procedure seguenti. Ti consigliamo quindi di installare Calico su Amazon EKS tramite l'operatore Calico al posto di questi grafici o manifesti. Per ulteriori informazioni, consulta Annuncio importante: Amazon EKS non conserverà e non aggiornerà più i grafici Calico in questo repository su GitHub. Se riscontri problemi durante l'installazione e l'utilizzo di Calico, sottoponi i problemi direttamente all'operatore Calico e al progetto Calico. È sempre necessario contattare Tigera per la compatibilità di qualsiasi nuovo operatore Calico e versione di Calico prima di installarli sul cluster.

  1. Puoi installare Calico utilizzando manifesti Kubernetes o Helm.

    Helm
    Prerequisito

    Helm versione 3.0 o successiva deve essere installato sul computer. Per installare o aggiornare Helm, consultare Utilizzo di Helm con Amazon EKS.

    Installazione di Calico con Helm

    1. Aggiungi Project Calico al tuo repository Helm.

      helm repo add projectcalico https://docs.projectcalico.org/charts

    2. Se già hai aggiunto Calico, puoi aggiornarlo per ottenere l'ultima versione rilasciata.

      helm repo update

    3. Installa la versione 3.21.4 o successiva dell'operatore Calico Tigera e le definizioni delle risorse personalizzate.

      helm install calico projectcalico/tigera-operator --version v3.21.4
    Manifests

    Applica i manifesti Calico al cluster.

    kubectl apply -f https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/master/config/master/calico-operator.yaml
kubectl apply -f https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/master/config/master/calico-crs.yaml

  2. Visualizza le risorse nello spazio dei nomi tigera-operator.

    kubectl get all -n tigera-operator

    Di seguito è riportato l'output di esempio.

    NAME                                   READY   STATUS    RESTARTS   AGE
pod/tigera-operator-768d489967-6cv58   1/1     Running   0          27m

NAME                              READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/tigera-operator   1/1     1            1           27m

NAME                                         DESIRED   CURRENT   READY   AGE
replicaset.apps/tigera-operator-768d489967   1         1         1       27m

    I valori nelle colonne DESIRED e READY del replicaset devono corrispondere.

  3. Visualizza le risorse nello spazio dei nomi calico-system.

    kubectl get all -n calico-system

    Di seguito è riportato l'output di esempio.

    NAME                                           READY   STATUS    RESTARTS   AGE
pod/calico-kube-controllers-5cd7d477df-2xqpd   1/1     Running   0          40m
pod/calico-node-bm5fb                          1/1     Running   0          40m
pod/calico-node-wfww4                          1/1     Running   0          40m
pod/calico-typha-86c697dbdc-n7qff              1/1     Running   0          40m

NAME                                      TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
service/calico-kube-controllers-metrics   ClusterIP   10.100.77.235   <none>        9094/TCP   40m
service/calico-typha                      ClusterIP   10.100.164.91   <none>        5473/TCP   40m

NAME                                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR              AGE
daemonset.apps/calico-node              2         2         2       2            2           kubernetes.io/os=linux     40m

NAME                                      READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/calico-kube-controllers   1/1     1            1           40m
deployment.apps/calico-typha              1/1     1            1           40m

NAME                                                 DESIRED   CURRENT   READY   AGE
replicaset.apps/calico-kube-controllers-5cd7d477df   1         1         1       40m
replicaset.apps/calico-typha-86c697dbdc              1         1         1       40m

    L'output è lievemente differente a seconda che l'implementazione sia stata effettuata utilizzando i manifesti o il grafico Helm. I valori nelle colonne DESIRED e READY del calico-node daemonset devono corrispondere. Anche i valori nelle colonne DESIRED e READY per i due replicasets devono corrispondere. Il numero di nella colonna DESIRED per daemonset.apps/calico-node varia in base al numero di nodi nel tuo cluster.

  4. Verifica che i registri per uno dei tuoi pod calico-node, calico-typha e tigera-operator pods non contengano ERROR. Sostituisci i valori nei comandi seguenti con i valori restituiti nell'output dei passaggi precedenti. 

    kubectl logs tigera-operator-768d489967-6cv58 -n tigera-operator | grep ERROR
kubectl logs calico-node-bm5fb -c calico-node -n calico-system | grep ERROR
kubectl logs calico-typha-86c697dbdc-n7qff -n calico-system | grep ERROR

    Se non viene restituito alcun output dai comandi precedenti, nei tuoi registri non dovrebbe esserci alcun ERROR e tutto dovrebbe funzionare correttamente.

  5. Se stai utilizzando la versione 1.9.3 o successiva del Amazon VPC CNI plugin for Kubernetes, abilita il plug-in per aggiungere l'indirizzo IP del pod a un'annotazione nelle specifiche del pod calico-kube-controllers-579b45dcf-z5tsf. Per ulteriori informazioni su questa impostazione, consulta ANNOTATE_POD_IP su GitHub.

    1. Scopri quale versione del plug-in è installata sul tuo cluster con il comando seguente.

      kubectl describe daemonset aws-node -n kube-system | grep amazon-k8s-cni: | cut -d ":" -f 3

      Di seguito è riportato l'output di esempio.

      v1.10.4-eksbuild.1

    2. Crea un file di configurazione che puoi applicare al tuo cluster che concede a aws-node Kubernetes clusterrole l'autorizzazione per l'applicazione della patch ai pods.

      cat << EOF > append.yaml
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - patch
EOF

    3. Applica le autorizzazioni aggiornate al tuo cluster.

      kubectl apply -f <(cat <(kubectl get clusterrole aws-node -o yaml) append.yaml)

    4. Imposta la variabile di ambiente per il plug-in.

      kubectl set env daemonset aws-node -n kube-system ANNOTATE_POD_IP=true

    5. Accertati che l'annotazione sia stata aggiunta al calico-kube-controllers-5cd7d477df-2xqpd pod. Sostituisci 5cd7d477df-2xqpd con l'ID del pod restituito in un passaggio precedente.

      kubectl describe pod calico-kube-controllers-5cd7d477df-2xqpd -n calico-system | grep vpc.amazonaws.com/pod-ips

      Di seguito è riportato l'output di esempio.

      vpc.amazonaws.com/pod-ips: 192.168.25.9

Demo policy Stars

Questa sezione illustra la demo della policy Stars fornita nella documentazione di Project Calico e non è richiesta per la funzionalità Calico sul cluster. La demo consente di creare un servizio client, di front-end e di back-end sul cluster Amazon EKS. Inoltre, la demo consente di creare un'interfaccia utente grafica di gestione che mostra i percorsi di ingresso e uscita disponibili tra ogni servizio. Ti consigliamo di completare la demo su un cluster su cui non esegui carichi di lavoro di produzione.

Prima di creare eventuali policy di rete, tutti i servizi sono in grado di comunicare in modo bidirezionale. Dopo l'applicazione delle policy di rete, puoi vedere che il client può comunicare solo con il servizio di front-end, mentre il back-end accetta traffico solo dal front-end.

Per eseguire la demo policy Stars

  1. Applica i servizi di front-end, back-end, client e dell'interfaccia utente di gestione:

    kubectl apply -f https://docs.projectcalico.org/v3.5/getting-started/kubernetes/tutorials/stars-policy/manifests/00-namespace.yaml
kubectl apply -f https://docs.projectcalico.org/v3.5/getting-started/kubernetes/tutorials/stars-policy/manifests/01-management-ui.yaml
kubectl apply -f https://docs.projectcalico.org/v3.5/getting-started/kubernetes/tutorials/stars-policy/manifests/02-backend.yaml
kubectl apply -f https://docs.projectcalico.org/v3.5/getting-started/kubernetes/tutorials/stars-policy/manifests/03-frontend.yaml
kubectl apply -f https://docs.projectcalico.org/v3.5/getting-started/kubernetes/tutorials/stars-policy/manifests/04-client.yaml

  2. Visualizza tutti i pods nel cluster.

    kubectl get pods -A

    Di seguito è riportato l'output di esempio.

    Nell'output, dovresti vedere i pods negli spazi dei nomi mostrati nel seguente output. I NOMI dei pod e il numero di pods nella colonna READY sono diversi da quelli del seguente output. Non continuare finché non vedi pods con nomi simili e tutti hanno il valore Running nella colonna STATUS.

    NAMESPACE         NAME                                       READY   STATUS    RESTARTS   AGE
...
client            client-xlffc                               1/1     Running   0          5m19s
...
management-ui     management-ui-qrb2g                        1/1     Running   0          5m24s
stars             backend-sz87q                              1/1     Running   0          5m23s
stars             frontend-cscnf                             1/1     Running   0          5m21s
...

  3. Per connetterti all'interfaccia utente di gestione, inoltra la porta locale 9001 al servizio management-ui in esecuzione sul cluster:

    kubectl port-forward service/management-ui -n management-ui 9001

  4. Aprire un browser sul sistema locale e specificare l'indirizzo http://localhost:9001/. Dovresti visualizzare l'interfaccia utente di gestione seguente. Il nodo C è il servizio client, il nodo F è il servizio front-end e il nodo B è il servizio di back-end. Ogni nodo dispone di accesso di comunicazione completo a tutti gli altri nodi, come indicato dalle righe colorate in grassetto.

    Apri policy di rete

  5. Applicare le seguenti policy di rete per isolare tra loro i servizi:

    kubectl apply -n stars -f https://docs.projectcalico.org/v3.5/getting-started/kubernetes/tutorials/stars-policy/policies/default-deny.yaml
kubectl apply -n client -f https://docs.projectcalico.org/v3.5/getting-started/kubernetes/tutorials/stars-policy/policies/default-deny.yaml

  6. Aggiorna il tuo browser. Poiché l'interfaccia utente di gestione non può più raggiungere i nodi, essi non vengono visualizzati nell'interfaccia utente.

  7. Applica le seguenti policy di rete per consentire all'interfaccia utente di gestione di accedere ai servizi:

    kubectl apply -f https://docs.projectcalico.org/v3.5/getting-started/kubernetes/tutorials/stars-policy/policies/allow-ui.yaml
kubectl apply -f https://docs.projectcalico.org/v3.5/getting-started/kubernetes/tutorials/stars-policy/policies/allow-ui-client.yaml

  8. Aggiorna il tuo browser. L'interfaccia utente di gestione può raggiungere nuovamente i nodi, ma i nodi non sono in grado di comunicare tra loro.

    Policy di rete accesso interfaccia utente

  9. Applicare le seguenti policy di rete per consentire il traffico dal servizio front-end al servizio back-end:

    kubectl apply -f https://docs.projectcalico.org/v3.5/getting-started/kubernetes/tutorials/stars-policy/policies/backend-policy.yaml

  10. Aggiorna il tuo browser. Puoi vedere che il front-end può comunicare con il back-end.

    Policy da front-end a back-end

  11. Applica la seguente policy di rete per consentire il traffico dal client al servizio di front-end.

    kubectl apply -f https://docs.projectcalico.org/v3.5/getting-started/kubernetes/tutorials/stars-policy/policies/frontend-policy.yaml

  12. Aggiorna il tuo browser. Puoi vedere che il client può comunicare con il servizio di front-end. Il servizio di front-end può ancora comunicare con il servizio di back-end.

    Policy di rete finale

  13. (Facoltativo) Al termine della demo, puoi eliminare le relative risorse.

    kubectl delete -f https://docs.projectcalico.org/v3.5/getting-started/kubernetes/tutorials/stars-policy/manifests/04-client.yaml
kubectl delete -f https://docs.projectcalico.org/v3.5/getting-started/kubernetes/tutorials/stars-policy/manifests/03-frontend.yaml
kubectl delete -f https://docs.projectcalico.org/v3.5/getting-started/kubernetes/tutorials/stars-policy/manifests/02-backend.yaml
kubectl delete -f https://docs.projectcalico.org/v3.5/getting-started/kubernetes/tutorials/stars-policy/manifests/01-management-ui.yaml
kubectl delete -f https://docs.projectcalico.org/v3.5/getting-started/kubernetes/tutorials/stars-policy/manifests/00-namespace.yaml

    Anche dopo l'eliminazione delle risorse, possono essere presenti regole iptables sui nodi di lavoro che potrebbero interferire in modo imprevisto con la rete nel cluster. L'unico modo sicuro per rimuovere Calico è terminare tutti i nodi e riavviarli. Per terminare tutti i nodi, impostare il conteggio desiderato del Gruppo Auto Scaling su 0, quindi eseguire il backup al numero desiderato oppure terminare semplicemente i nodi. Se non riesci a riciclare i nodi, consulta Disabilitazione e rimozione della policy Calico nel repository Calico per la procedura più recente.

Remove Calico

Rimuovi Calico utilizzando il metodo con cui hai installato Calico.

Helm

Rimozione di Calico dal tuo cluster

helm uninstall calico
Manifests

Rimozione di Calico dal tuo cluster

kubectl delete -f https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/master/config/master/calico-crs.yaml
kubectl delete -f https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/master/config/master/calico-operator.yaml