Kf si integra strettamente con Kubernetes e Istio per fornire un'applicazione solida dei criteri di rete.
Per impostazione predefinita, i carichi di lavoro Kf vengono eseguiti nel cluster Kubernetes e risolvono gli indirizzi utilizzando DNS Kubernetes. Questo resolver DNS tenterà prima di risolvere gli indirizzi all'interno del cluster e, se non ne viene trovato nessuno, tenterà una risoluzione esterna.
Ogni app Kf viene eseguita con un sidecar Envoy inserito da Istio o da Anthos Service Mesh (ASM). Questo file collaterale funge da proxy per 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 container che costituiscono un pod. I nodi esistono su una rete fisica o virtuale.
Insieme, formano una gerarchia di sistemi in cui è possibile applicare criteri di rete. Queste sono elencate di seguito a partire dal 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:
- Collocare 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. Queste sono le mappature più vicine ai criteri di rete Cloud Foundry esistenti in Kubernetes.
I criteri di rete sono supportati da un componente aggiuntivo di Kubernetes. Se configuri il tuo cluster GKE, devi abilitare l'applicazione forzata di NetworkPolicy.
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 ai pod che eseguono app o build.
Ogni spazio Kf crea due criteri di rete con cui iniziare, uno per le app e l'altro per le build. Puoi modificare la configurazione nei campi spec.networkConfig.(app|build)NetworkPolicy.(in|e)gress dello spazio.
Questi campi possono essere impostati con uno dei seguenti valori:
| Valore numerico | Descrizione |
|---|---|
PermitAll |
Consente tutto il traffico. |
DenyAll |
Nega 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 in entrata del cluster
- In uscita verso internet, ad esempio per recuperare i Buildpack
- Routing est/ovest tra app
- Accesso al server DNS di Kubernetes
- Accesso ai registri di container
- Accesso diretto alla rete VPC
- Accesso a 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, autenticazione, autorizzazione e osservabilità del networking granulari, puoi applicare i criteri utilizzando Anthos Service Mesh.
Un mesh di servizi è un livello di 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.