Come funziona Bridge per Kubernetes

Nota

Microsoft prevede di non gestire più attivamente il progetto Bridge to Kubernetes. Nei prossimi mesi il progetto verrà passato a uno stato di archiviazione. Nel frattempo, il progetto è ancora disponibile per l'uso e il download. Durante questo periodo, ci auguriamo di esplorare e consigliare progetti della community che offrono vantaggi simili a Bridge to Kubernetes per l'uso futuro. In caso di domande, contattare Microsoft nella bacheca dei problemi in GitHub.

Bridge to Kubernetes è uno strumento di sviluppo iterativo per la creazione di applicazioni di microservizi destinate a Kubernetes. L'estensione Bridge to Kubernetes è disponibile per Visual Studio e Visual Studio Code (VS Code).

Bridge a Kubernetes consente di eseguire ed eseguire il debug del codice nel computer di sviluppo. Il computer è ancora connesso al cluster Kubernetes con il resto dell'applicazione o dei servizi. Se si dispone di un'architettura di microservizi di grandi dimensioni con molti servizi e database interdipendenti, la replica di tali dipendenze nel computer di sviluppo può essere difficile. La compilazione e la distribuzione di codice nel cluster Kubernetes per ogni modifica del codice possono risultare lente, dispendiose in termini di tempo e difficoltà.

Bridge a Kubernetes crea una connessione tra il computer di sviluppo e il cluster. Questo approccio evita di dover compilare e distribuire il codice nel cluster. È possibile testare e sviluppare il servizio nel contesto, connesso al cluster. Questo approccio consente di eseguire il debug senza creare altre configurazioni di Docker o Kubernetes.

Bridge a Kubernetes reindirizza il traffico tra il cluster Kubernetes connesso e il computer di sviluppo. Il codice locale e i servizi nel cluster Kubernetes possono comunicare come se fossero nello stesso cluster Kubernetes.

Bridge a Kubernetes consente di replicare le variabili di ambiente e i volumi montati nel cluster Kubernetes nel computer di sviluppo. L'accesso alle variabili di ambiente e ai volumi montati consente di lavorare sul codice senza dover replicare tali dipendenze.

Requisiti

Nota

Bridge a Kubernetes non funziona con i cluster Docker per Desktop Kubernetes. Per usare Bridge to Kubernetes, sono necessarie una delle configurazioni seguenti:

• VS Code con l'estensione Bridge to Kubernetes installata.
• Visual Studio 2019 versione 16.7 o successiva in esecuzione in Windows 10 o versione successiva. Assicurarsi che sia installato il carico di lavoro ASP.NET e sviluppo Web. Installare l'estensione Bridge in Kubernetes.

È possibile usare Bridge per Kubernetes per stabilire una connessione al cluster Kubernetes. Questa connessione reindirizza il traffico da e verso un pod esistente nel cluster al computer di sviluppo.

Nota

Quando si usa Bridge to Kubernetes, viene richiesto il nome del servizio per il reindirizzamento al computer di sviluppo. Questa opzione è un modo pratico per identificare un pod per il reindirizzamento. Tutto il reindirizzamento tra il cluster Kubernetes e il computer di sviluppo è destinato a un pod. Per altre informazioni, vedere Rendere disponibile un servizio.

In VS Code Bridge to Kubernetes supporta tutti i linguaggi purché sia possibile eseguirli in locale. In Visual Studio Bridge to Kubernetes supporta .NET Core. Bridge a Kubernetes non supporta .NET Framework in Visual Studio perché richiede il supporto dei nodi Windows.

Attenzione

Bridge to Kubernetes è destinato solo agli scenari di sviluppo e test. Non è progettato o supportato per l'uso con cluster di produzione o servizi attivi in uso.

Per le funzionalità correnti e i piani futuri, vedere la roadmap di Bridge to Kubernetes.

Stabilire una connessione

Quando Bridge a Kubernetes stabilisce una connessione al cluster, esegue le azioni seguenti:

• Richiede di configurare il servizio da sostituire nel cluster, la porta nel computer di sviluppo da usare per il codice e l'attività di avvio per il codice come azione una tantum.
• Sostituisce il contenitore nel pod nel cluster con un contenitore dell'agente remoto che reindirizza il traffico al computer di sviluppo.
• Esegue kubectl port-forward nel computer di sviluppo per inoltrare il traffico dal computer di sviluppo all'agente remoto in esecuzione nel cluster.
• Raccoglie informazioni sull'ambiente dal cluster usando l'agente remoto. Queste informazioni sull'ambiente includono variabili di ambiente, servizi visibili, montaggi di volumi e montaggi segreti.
• Configura l'ambiente in Visual Studio in modo che il servizio nel computer di sviluppo possa accedere alle stesse variabili come se fosse in esecuzione nel cluster.
• Aggiorna il file hosts per eseguire il mapping dei servizi nel cluster agli indirizzi IP locali nel computer di sviluppo. Queste voci di file host consentono al codice in esecuzione nel computer di sviluppo di effettuare richieste ad altri servizi in esecuzione nel cluster. Per aggiornare il file hosts , Bridge to Kubernetes richiede l'accesso amministratore nel computer di sviluppo.
• Avvia l'esecuzione e il debug del codice nel computer di sviluppo. Se necessario, Bridge to Kubernetes libera le porte necessarie nel computer di sviluppo arrestando i servizi o i processi che attualmente usano tali porte.

Uso di Bridge to Kubernetes

Dopo aver stabilito una connessione al cluster, eseguire ed eseguire il debug del codice in modo nativo nel computer, senza containerizzazione. Il codice interagisce con il cluster. Qualsiasi traffico di rete ricevuto dall'agente remoto viene reindirizzato alla porta locale specificata durante la connessione. Il codice in esecuzione in modo nativo può accettare ed elaborare tale traffico. Le variabili di ambiente, i volumi e i segreti del cluster vengono resi disponibili per il codice in esecuzione nel computer di sviluppo.

Bridge a Kubernetes aggiunge voci di file host e port forwarding al computer per sviluppatori. Il codice può inviare il traffico di rete ai servizi in esecuzione nel cluster usando i nomi dei servizi del cluster. Il traffico viene inoltrato ai servizi in esecuzione nel cluster. Il traffico viene instradato tra il computer di sviluppo e il cluster per tutto il tempo di connessione.

Bridge to Kubernetes consente inoltre di replicare le variabili di ambiente e i file montati disponibili per i pod nel cluster nel computer di sviluppo tramite il KubernetesLocalProcessConfig.yaml file . È anche possibile usare questo file per creare nuove variabili di ambiente e montaggi di volumi.

Nota

Per la durata della connessione al cluster, più 15 minuti, Bridge to Kubernetes esegue un processo denominato EndpointManager con autorizzazioni di amministratore nel computer locale.

È possibile eseguire il debug in parallelo, con più servizi. Avviare tutte le istanze di Visual Studio come servizi di cui si vuole eseguire il debug. Assicurarsi che i servizi siano in ascolto su porte diverse in locale. Configurarli ed eseguirne il debug separatamente. L'isolamento non è supportato in questo scenario.

Configurazione aggiuntiva

Il file KubernetesLocalProcessConfig.yaml consente di replicare le variabili di ambiente e i file montati disponibili per i pod nel cluster. Quando si usa Visual Studio, il file KubernetesLocalConfig.yaml deve trovarsi nella stessa directory del file di progetto per il servizio. Per altre informazioni, vedere Configurare Bridge to Kubernetes.

Uso delle funzionalità di routing per lo sviluppo in isolamento

Per impostazione predefinita, Bridge to Kubernetes reindirizza tutto il traffico per un servizio al computer di sviluppo. È invece possibile usare le funzionalità di routing per reindirizzare solo le richieste da un sottodominio al computer di sviluppo. Queste funzionalità di routing consentono di usare Bridge to Kubernetes per sviluppare in isolamento ed evitare l'interruzione di altro traffico nel cluster.

L'animazione seguente mostra due sviluppatori che lavorano sullo stesso cluster in isolamento:

Quando si abilita l'isolamento, Bridge to Kubernetes esegue le azioni seguenti oltre a connettersi al cluster Kubernetes:

• Verifica che il cluster Kubernetes non abbia Azure Dev Spaces abilitato.
• Replica il servizio scelto nel cluster nello stesso spazio dei nomi e aggiunge un'etichetta routing.visualstudio.io/route-from=SERVICE_NAME e routing.visualstudio.io/route-on-header=kubernetes-route-as=GENERATED_NAME annotazione.
• Configura e avvia gestione routing nello stesso spazio dei nomi nel cluster Kubernetes. Gestione routing usa un selettore di etichette per cercare l'etichetta routing.visualstudio.io/route-from=SERVICE_NAME e routing.visualstudio.io/route-on-header=kubernetes-route-as=GENERATED_NAME annotazione durante la configurazione del routing nello spazio dei nomi.

Nota

Bridge a Kubernetes verifica se Azure Dev Spaces è abilitato nel cluster Kubernetes. Viene richiesto di disabilitare Azure Dev Spaces prima di poter usare Bridge per Kubernetes.

La gestione routing esegue le azioni seguenti all'avvio:

• Duplica tutti i dati in ingresso, inclusi i dati di ingresso del servizio di bilanciamento del carico, presenti nello spazio dei nomi usando il GENERATED_NAME per il sottodominio.
• Crea un pod envoy per ogni servizio associato a dati in ingresso duplicati con il sottodominio GENERATED_NAME .
• Crea un altro pod envoy per il servizio su cui si sta lavorando in isolamento. Questa configurazione consente di instradare le richieste con il sottodominio al computer di sviluppo.
• Configura le regole di routing per ogni pod envoy per gestire il routing per i servizi con il sottodominio.

Il diagramma seguente illustra un cluster Kubernetes prima che Bridge a Kubernetes si connetta al cluster:

Il diagramma seguente illustra lo stesso cluster con Bridge to Kubernetes abilitato in modalità di isolamento. Qui è possibile visualizzare il servizio duplicato e i pod di richiamo che supportano il routing in isolamento.

Quando il cluster riceve una richiesta con il sottodominio GENERATED_NAME , aggiunge un'intestazione kubernetes-route-as=GENERATED_NAME alla richiesta. I pod envoy gestiscono il routing che richiede al servizio appropriato nel cluster. Per una richiesta al servizio su cui si sta lavorando in isolamento, il cluster reindirizza la richiesta al computer di sviluppo dall'agente remoto.

Quando il cluster riceve una richiesta senza il sottodominio GENERATED_NAME , non aggiunge un'intestazione alla richiesta. I pod envoy gestiscono il routing che richiede al servizio appropriato nel cluster. Per una richiesta per il servizio che viene sostituito, i pod lo instradano al servizio originale anziché all'agente remoto.

Importante

Ogni servizio nel cluster deve inoltrare l'intestazione kubernetes-route-as=GENERATED_NAME durante l'esecuzione di richieste aggiuntive. Ad esempio, quando serviceA riceve una richiesta, effettua una richiesta a serviceB prima di restituire una risposta. In questo esempio serviceA deve inoltrare l'intestazione kubernetes-route-as=GENERATED_NAME nella richiesta a serviceB. Alcuni linguaggi, ad esempio ASP.NET, possono avere metodi per la gestione della propagazione delle intestazioni.

Quando si disconnette dal cluster, per impostazione predefinita, Bridge to Kubernetes rimuove tutti i pod envoy e il servizio duplicato.

Nota

La distribuzione e il servizio di gestione routing rimangono in esecuzione nello spazio dei nomi. Per rimuovere la distribuzione e il servizio, eseguire i comandi seguenti per lo spazio dei nomi.

kubectl delete deployment routingmanager-deployment -n NAMESPACE
kubectl delete service routingmanager-service -n NAMESPACE

Diagnostica e registrazione

Quando si usa Bridge to Kubernetes per connettersi al cluster, il computer registra la diagnostica. Li archivia nella directory TEMP del computer di sviluppo nella cartella Bridge to Kubernetes.

Autorizzazione del controllo degli accessi in base al ruolo di Kubernetes

Kubernetes fornisce Controllo di accesso basato sui ruoli per gestire le autorizzazioni per utenti e gruppi. Per informazioni, vedere la documentazione di Kubernetes. È possibile impostare le autorizzazioni per un cluster abilitato per il controllo degli accessi in base al ruolo creando un file YAML e usando kubectl per applicarlo al cluster.

Per impostare le autorizzazioni nel cluster, creare o modificare un file YAML, ad esempio permissions.yml. Usare lo spazio dei nomi per <namespace> gli utenti e i gruppi che necessitano dell'accesso.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: bridgetokubernetes-<namespace>
  namespace: development
subjects:
  - kind: User
    name: jane.w6wn8.k8s.ginger.eu-central-1.aws.gigantic.io
    apiGroup: rbac.authorization.k8s.io
  - kind: Group
    name: dev-admin
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: admin
  apiGroup: rbac.authorization.k8s.io

Applicare le autorizzazioni usando il comando seguente:

kubectl -n <namespace> apply -f <yaml file name>

Limiti

Bridge to Kubernetes presenta le limitazioni seguenti:

• Un pod può avere un solo contenitore in esecuzione in tale pod per connettersi correttamente a Bridge a Kubernetes.
• Attualmente, i pod Da Bridge a Kubernetes devono essere contenitori Linux. I contenitori di Windows non sono supportati.
• Bridge a Kubernetes richiede autorizzazioni elevate per l'esecuzione nel computer di sviluppo per modificare il file hosts.
• Il bridge a Kubernetes non può essere usato nei cluster con Azure Dev Spaces abilitato.

Passaggi successivi

Per iniziare a usare Bridge to Kubernetes per connettersi al computer di sviluppo locale al cluster, vedere Usare Bridge to Kubernetes (VS) o Usare Bridge to Kubernetes (VS Code).