Kf si integra perfettamente con Kubernetes e Istio per garantire un'applicazione rigorosa dei criteri di rete.
Per impostazione predefinita, i carichi di lavoro Kf vengono eseguiti nel cluster Kubernetes e risolvono gli indirizzi utilizzando il DNS di Kubernetes. Questo resolver DNS tenterà prima di risolvere gli indirizzi all'interno del cluster e solo se non ne vengono trovati tenterà la risoluzione esterna.
Ogni app Kf viene eseguita con un sidecar Envoy iniettato da Istio o Anthos Service Mesh (ASM). Questo sidecar esegue il proxy di tutto il traffico di rete in entrata e in uscita dal pod Kubernetes.
Ogni pod Kubernetes viene eseguito su un nodo, una macchina fisica o virtuale responsabile della gestione delle immagini dei container che compongono un pod. I nodi esistono su una rete fisica o virtuale.
Insieme, formano una gerarchia di sistemi a cui puoi applicare i criteri di rete. Questi sono elencati di seguito dal meno granulare al più granulare.
Criteri a livello di rete
La protezione dei carichi di lavoro inizia dalla rete su cui è installato il cluster GKE.
Se esegui Kf su un cluster GKE su Google Cloud, Kf consiglia:
- Posiziona il cluster GKE su una rete Virtual Private Cloud (VPC).
- Con l'accesso privato Google abilitato.
- Utilizzo di Cloud NAT per controllare il traffico in uscita.
Criteri a livello di nodo
Puoi configurare i criteri per i container in esecuzione sul nodo utilizzando NetworkPolicies di Kubernetes. Si tratta della mappatura più simile ai criteri di rete Cloud Foundry esistenti in Kubernetes.
I NetworkPolicies sono supportati da un componente aggiuntivo di Kubernetes. Se configuri il tuo cluster GKE, devi abilitare l'applicazione dei criteri di rete.
Kf etichetta le app con kf.dev/networkpolicy=app e le build con kf.dev/networkpolicy=build.
In questo modo puoi scegliere come target NetworkPolicies direttamente per i pod che eseguono app o build.
Ogni spazio Kf crea inizialmente due NetworkPolicy, uno che ha come target le app e uno le build. Puoi modificare la configurazione nei campi spec.networkConfig.(app|build)NetworkPolicy.(in|e)gress dello spazio.
Questi campi possono essere impostati su uno dei seguenti valori:
| Valore enum | Descrizione |
|---|---|
PermitAll |
Consente tutto il traffico. |
DenyAll |
Rifiuta tutto il traffico. |
Per impostazione predefinita, Kf utilizza un criterio di rete permissivo. Ciò consente le seguenti funzionalità utilizzate da Kf:
- Routing nord/sud al gateway di ingresso del cluster
- Traffico in uscita verso internet, ad esempio per recuperare i buildpack
- Routing est/ovest tra app
- Accesso al server DNS di Kubernetes
- Accesso ai registry dei container
- Accesso diretto alla rete VPC
- Accesso ai servizi Google come Cloud Logging
- Accesso al server Workload Identity per la rotazione automatica delle credenziali
Criteri del mesh di servizi
Se hai bisogno di controllo granulare della rete, autenticazione, autorizzazione e osservabilità, puoi applicare i criteri utilizzando Anthos Service Mesh.
Un mesh di servizi è un livello dell'infrastruttura che consente comunicazioni gestite, osservabili e sicure tra i tuoi servizi, consentendoti di creare applicazioni aziendali solide composte da molti microservizi sull'infrastruttura scelta.
Puoi consultare l'elenco delle funzionalità supportate qui.