Ambienti multipli (gestione temporanea, controllo qualità, produzione e così via) con Kubernetes

Qual è considerata una buona pratica con K8S per la gestione di più ambienti (QA, Staging, Produzione, Sviluppo, ecc.)?

Ad esempio, supponiamo che un team stia lavorando a un prodotto che richiede la distribuzione di alcune API, insieme a un'applicazione front-end. Di solito, questo richiederà almeno 2 ambienti:

• Messa in scena: per iterazioni / test e convalida prima del rilascio al client
• Produzione: questo è l'ambiente a cui il cliente ha accesso. Dovrebbe contenere funzionalità stabili e ben testate.

Quindi, supponendo che il team utilizzi Kubernetes, quale sarebbe una buona pratica per ospitare questi ambienti? Finora abbiamo considerato due opzioni:

1. Usa un cluster K8s per ogni ambiente
2. Utilizza un solo cluster K8 e conservali in spazi dei nomi diversi.

(1) Sembra l'opzione più sicura poiché riduce al minimo i rischi di potenziali errori umani e guasti della macchina, che potrebbero mettere in pericolo l'ambiente di produzione. Tuttavia, ciò comporta il costo di più macchine master e anche il costo di una maggiore gestione dell'infrastruttura.

(2) Sembra che semplifichi la gestione dell'infrastruttura e della distribuzione perché c'è un singolo cluster, ma solleva alcune domande come:

• Come ci si assicura che un errore umano possa avere un impatto sull'ambiente di produzione?
• Come ci si assicura che un carico elevato nell'ambiente di staging non provochi una perdita di prestazioni nell'ambiente di produzione?

Potrebbero esserci altre preoccupazioni, quindi mi rivolgo alla comunità K8s su StackOverflow per avere una migliore comprensione di come le persone affrontano questo tipo di sfide.

Considerazioni su più cluster

Dai un'occhiata a questo post del blog di Vadim Eisenberg ( IBM / Istio ): Elenco di controllo: pro e contro dell'utilizzo di più cluster Kubernetes e come distribuire i carichi di lavoro tra di loro .

Vorrei evidenziare alcuni dei pro / contro:

Motivi per avere più cluster

• Separazione produzione / sviluppo / test: specialmente per testare una nuova versione di Kubernetes, di una rete di servizi, di altri software di cluster
• Conformità: secondo alcune normative alcune applicazioni devono essere eseguite in cluster separati / VPN separate
• Migliore isolamento per la sicurezza
• Cloud / on-premise: per suddividere il carico tra i servizi on-premise

Motivi per avere un singolo cluster

• Riduci i costi di configurazione, manutenzione e amministrazione
• Migliora l'utilizzo
• Riduzione dei costi

Considerando un ambiente non troppo costoso, con una manutenzione media, e tuttavia garantendo l'isolamento della sicurezza per le applicazioni di produzione, consiglierei:

• 1 cluster per DEV e STAGING (separati da spazi dei nomi, forse anche isolati, utilizzando le politiche di rete, come in Calico )
• 1 cluster per PROD

Parità ambientale

È una buona pratica mantenere lo sviluppo, la messa in scena e la produzione il più simili possibile:

Le differenze tra i servizi di supporto significano che si verificano minuscole incompatibilità, causando il fallimento della produzione del codice che ha funzionato e ha superato i test di sviluppo o di gestione temporanea. Questi tipi di errori creano attriti che disincentivano la distribuzione continua.

Combina un potente strumento CI / CD con il timone . È possibile utilizzare la flessibilità dei valori helm per impostare le configurazioni predefinite, sovrascrivendo semplicemente le configurazioni che differiscono da un ambiente all'altro.

GitLab CI / CD con AutoDevops ha una potente integrazione con Kubernetes, che ti consente di gestire più cluster Kubernetes già con supporto helm.

Gestione di più cluster ( kubectlinterazioni)

Quando lavori con più cluster Kubernetes, è facile confondere i contesti ed eseguire kubectlnel cluster sbagliato. Oltre a ciò, Kubernetes ha limitazioni per la mancata corrispondenza delle versioni tra client ( kubectl) e server (master kubernetes), quindi eseguire comandi nel contesto corretto non significa eseguire la versione client corretta.

Per ovviare a questo:

• Utilizzare asdfper gestire più kubectlversioni
• ImpostaKUBECONFIG env var per cambiare tra multiplekubeconfig file
• Uso kube-ps1 per tenere traccia del contesto / spazio dei nomi corrente
• Usa kubectxekubens per cambiare rapidamente tra cluster / spazi dei nomi
• Usa gli alias per combinarli tutti insieme

Ho un articolo che esemplifica come eseguire questa operazione: Utilizzo di diverse versioni di kubectl con più cluster Kubernetes

Raccomando anche le seguenti letture:

• Padroneggiare il file KUBECONFIG di Ahmet Alp Balkan ( Google Engineer )
• Come Zalando gestisce oltre 140 cluster Kubernetes di Henning Jacobs ( Zalando Tech )

Sicuramente usa un cluster separato per lo sviluppo e la creazione di immagini docker in modo che i tuoi cluster di staging / produzione possano essere bloccati in termini di sicurezza. Sta staging + productiona te decidere se utilizzare cluster separati per rischio / costo - certamente tenerli separati aiuterà a evitare di staginginfluenzareproduction .

Consiglio vivamente anche di utilizzare GitOps per promuovere versioni delle tue app tra i tuoi ambienti.

Per ridurre al minimo l'errore umano, ti consiglio anche di cercare di automatizzare il più possibile per il tuo CI / CD e la promozione.

Ecco una demo su come automatizzare CI / CD con più ambienti su Kubernetes utilizzando GitOps per la promozione tra ambienti e ambienti di anteprima su richieste pull che è stata eseguita in tempo reale su GKE sebbene Jenkins X supporti la maggior parte dei cluster kubernetes

Dipende da cosa vuoi testare in ciascuno degli scenari. In generale, tenterei di evitare di eseguire scenari di test sul cluster di produzione per evitare effetti collaterali non necessari (impatto sulle prestazioni, ecc.).

Se la tua intenzione è testare con un sistema di gestione temporanea che imiti esattamente il sistema di produzione ti consiglio di avviare una replica esatta del cluster completo e spegnerlo dopo aver terminato il test e spostare le distribuzioni in produzione.

Se il tuo scopo è testare un sistema di staging che consenta di testare l'applicazione da distribuire, eseguirò un cluster di staging più piccolo in modo permanente e aggiornerei le distribuzioni (con anche una versione ridotta delle distribuzioni) come richiesto per il test continuo.

Per controllare i diversi cluster, preferisco avere una macchina ci / cd separata che non fa parte del cluster ma utilizzata per l'avvio e l'arresto dei cluster, nonché per eseguire il lavoro di distribuzione, l'avvio dei test, ecc. Ciò consente di impostare e spegnere cluster come parte di scenari di test automatizzati.

È chiaro che mantenendo il cluster di produzione separato da quello di staging, si riduce il rischio di potenziali errori che incidono sui servizi di produzione. Tuttavia questo ha un costo di più infrastruttura / gestione della configurazione, poiché richiede almeno:

• almeno 3 master per il cluster di produzione e almeno un master per quello di staging
• 2 File di configurazione Kubectl da aggiungere al sistema CI / CD

Non dimentichiamo inoltre che potrebbero esserci più di un ambiente. Ad esempio ho lavorato presso aziende dove ci sono almeno 3 ambienti:

• QA: qui dove facevamo le distribuzioni quotidiane e dove facevamo il nostro QA interno prima di rilasciarlo al cliente)
• QA client: qui è stato eseguito il deployment prima della distribuzione in produzione in modo che il client potesse convalidare l'ambiente prima di rilasciare in produzione)
• Produzione: qui vengono distribuiti i servizi di produzione.

Penso che i cluster effimeri / su richiesta abbiano senso ma solo per alcuni casi d'uso (test di carico / prestazioni o integrazione / test end-to-end molto «grandi») ma per ambienti più persistenti / appiccicosi vedo un sovraccarico che potrebbe essere ridotto eseguendoli all'interno di un singolo cluster.

Immagino di voler contattare la comunità di k8s per vedere quali modelli vengono utilizzati per tali scenari come quelli che ho descritto.

A meno che la conformità o altri requisiti non impongano diversamente, preferisco un singolo cluster per tutti gli ambienti. Con questo approccio, i punti di attenzione sono:

• Assicurati di raggruppare anche i nodi per ambiente utilizzando le etichette. È quindi possibile utilizzare le nodeSelectorrisorse on per assicurarsi che siano in esecuzione su nodi specifici. Ciò ridurrà le possibilità che il consumo (eccessivo) di risorse si diffonda tra gli ambienti.

• Considera i tuoi spazi dei nomi come sottoreti e proibisci tutto il traffico in uscita / ingresso per impostazione predefinita. Vedi https://kubernetes.io/docs/concepts/services-networking/network-policies/ .

• Avere una strategia per la gestione degli account di servizio. ClusterRoleBindingsimplicano qualcosa di diverso se un cluster ospita più di un ambiente.

• Usa il controllo quando usi strumenti come Helm. Alcuni grafici installano palesemente account di servizio con autorizzazioni a livello di cluster, ma le autorizzazioni per gli account di servizio dovrebbero essere limitate all'ambiente in cui si trovano.

L'utilizzo di più cluster è la norma, in fondo alla lista per imporre una forte separazione tra produzione e "non produzione".

In questo spirito, tieni presente che GitLab 13.2 (luglio 2020) ora include:

Distribuzione di più cluster Kubernetes in Core

L'utilizzo di GitLab per distribuire più cluster Kubernetes con GitLab richiedeva in precedenza una licenza Premium.
La nostra comunità ha parlato e abbiamo ascoltato: la distribuzione su più cluster è utile anche per i singoli contributori.
In base al tuo feedback, a partire da GitLab 13.2, puoi distribuire a più gruppi e cluster di progetto in Core.

Vedi documentazione e problema /

Penso che l'esecuzione di un singolo cluster abbia senso perché riduce l'overhead e il monitoraggio. Ma devi assicurarti di mettere in atto criteri di rete, controllo degli accessi.

Criteri di rete: per impedire al carico di lavoro dell'ambiente dev / qa di interagire con i negozi di produzione / staging.

Controllo degli accessi: chi ha accesso a risorse di ambiente diverse utilizzando ruoli cluster, ruoli ecc.