Esegui il deployment del progetto base

Hai già una pipeline CI/CD.

Tu può utilizzare l'architettura del parco risorse e del cluster del progetto anche quando per la creazione e il deployment delle applicazioni. Come minimo, consigliamo di eseguire il mirroring delle immagini in due regioni.

Hai una struttura organizzativa esistente che non corrisponde alle basi aziendali progetto.

Avere sono consigliati almeno due ambienti per deployment sequenziali più sicuri. Tu non devi eseguire il deployment di ambienti VPC o cartelle condivise. Tuttavia, non eseguire il deployment di carichi di lavoro appartenenti in ambienti diversi nello stesso cluster.

Non utilizzare IaC.

Se l'attuale processo di deployment delle applicazioni non utilizza IaC, puoi per valutare il tuo livello di preparazione con Terraform on Modello di maturità di Google Cloud. Importa risorse esistenti in un altro progetto Terraform organizzato in modo simile a questo progetto, con la separazione tra multi-tenant e per tenant pipeline di dati. Per creare nuovi cluster, puoi usare i moduli Terraform per Google Cloud.

I cluster sono distribuiti in più progetti all'interno dello stesso completamente gestito di Google Cloud.

Puoi raggruppare i cluster di più progetti in un parco risorse. Verifica che gli spazi dei nomi hanno significati univoci all'interno dello stesso parco risorse. Prima di aggiungere a un parco risorse, chiedi ai team di spostare le loro applicazioni in uno spazio dei nomi con nome univoco (ad esempio, non default).

Puoi quindi raggruppare spazi dei nomi in ambiti.

I cluster si trovano in un'unica regione.

Non è necessario utilizzare più regioni in produzione e non di produzione per adottare il progetto.

Esistono diversi insiemi di ambienti.

Puoi modificare il progetto in modo che ne supporti più o meno ambienti cloud-native.

La creazione di cluster è delegata allo sviluppatore dell'applicazione o all'applicazione gli operatori del settore.

Per ottenere la piattaforma per sviluppatori più sicura e coerente, puoi provare trasferire la proprietà dei cluster dai team delle applicazioni alla piattaforma di sviluppo dell'IA. Se non ci riesci, puoi comunque adottare molte delle pratiche del progetto base. Per Ad esempio, puoi aggiungere i cluster di proprietà di diversi team delle applicazioni a un parco risorse. Tuttavia, quando combini i cluster con proprietà indipendente, non usare Workload Identity o Cloud Service Mesh, in quanto non forniscono un controllo sufficiente che possono specificare le identità dei carichi di lavoro. Utilizza invece un modello personalizzato dell'organizzazione per impedire ai team di abilitare queste funzionalità cluster GKE.

Quando i cluster sono raggruppati in un parco risorse, puoi comunque per controllare e applicare criteri. Puoi utilizzare un modello criterio dell'organizzazione per richiedere la creazione di cluster all'interno di un parco risorse che corrisponde alla cartella di ambiente in cui si trova il progetto del cluster. Tu possono usare la flotta configurazione predefinita per richiedere che i nuovi cluster utilizzino i criteri controllo.

Tutte le applicazioni vengono eseguite nello stesso insieme di cinque cluster.

Il progetto utilizza un insieme di cinque cluster (due in produzione, due in non in produzione e una in fase di sviluppo). Puoi modificare il progetto per di cinque cluster aggiuntivi.

Assegna le applicazioni a gruppi di cinque cluster. Non associare gli ambiti di un'applicazione o gli spazi dei nomi del parco risorse ai cluster in gli altri insiemi. Ti consigliamo di isolare le applicazioni in cluster diversi per completare attività come le seguenti:

• Raggruppa alcune applicazioni con particolari problemi normativi (ad ad esempio PCI DSS).
• Isola le applicazioni che richiedono una gestione speciale durante gli upgrade dei cluster (ad esempio, applicazioni stateful che utilizzano volumi permanenti).
• Isolare le applicazioni con profili di sicurezza rischiosi (ad esempio, l'elaborazione contenuti forniti dagli utenti in un linguaggio non sicuro per la memoria).
• Isola le applicazioni che richiedono GPU, sensibilità ai costi e prestazioni sensibilità.
• Se stai per raggiungere il limite di cluster GKE per il numero di nodi (15.000 nodi), possono creare un nuovo insieme di cluster.
• Usa un VPC condiviso diverso per le applicazioni che devono essere eseguite all'interno di un Perimetro Controlli di servizio VPC. Crea un cluster impostato nel perimetro e uno cluster impostato al di fuori del perimetro.

Evita di creare nuovi set di cluster per ogni applicazione o tenant, perché potrebbe verificarsi una delle seguenti situazioni:

• Applicazioni che non utilizzano in modo appropriato la dimensione minima del cluster (3 VM x 2) regioni) anche con i tipi di istanza più piccoli disponibili.
• Perdita del potenziale di riduzione dei costi dovuto al bin packing di diverse applicazioni.
• La pianificazione della crescita delle capacità, noiosa e incerta, è dovuta all'applicazione della pianificazione a ciascuna applicazione. Le previsioni della capacità sono più accurate quando in forma aggregata per una vasta gamma di applicazioni.
• Ritardi nella creazione di nuovi cluster per nuovi tenant o applicazioni, con conseguente riduzione la soddisfazione dei tenant con la piattaforma. Ad esempio, in alcune organizzazioni, le allocazioni di indirizzi IP richiesti possono richiedere tempo e richiedere ulteriori approvazioni.
• Raggiungere il privato di cluster Kubernetes in una rete VPC.

Gli ambienti di produzione e non di produzione in due regioni.

Per una latenza minore per gli utenti finali in più regioni, puoi eseguire il deployment carichi di lavoro di produzione e non di produzione in più di due regioni (ad ad esempio tre regioni per la produzione, tre per la versione non di produzione e una regione per lo sviluppo). Questa strategia di deployment aumenta i costi l'overhead associato alla gestione delle risorse in altre regioni.

Se tutte le applicazioni hanno requisiti di disponibilità inferiori, puoi carichi di lavoro di produzione e non di produzione in una sola regione (una di produzione, un ambiente non di produzione e un ambiente di sviluppo). Questa strategia consente di ridurre i costi, ma non protegge lo stesso livello di la disponibilità come architettura a due o più regioni.

Se le applicazioni hanno requisiti di disponibilità diversi, puoi creare set di cluster diversi per applicazioni diverse (ad esempio, cluster-set-1 con due ambienti di produzione, due non di produzione ambienti di sviluppo, un ambiente di sviluppo e cluster-set-2 un ambiente di produzione, uno non di produzione e uno di sviluppo software).

La topologia hub-and-spoke soddisfa meglio i tuoi requisiti rispetto VPC condiviso.

Puoi eseguire il deployment del progetto in una configurazione hub e spoke, dove ogni dell'ambiente di sviluppo (sviluppo, produzione e non produzione) è ospitato sul proprio parlato. La topologia hub-and-spoke può aumentare la segregazione degli ambienti. Per per ulteriori informazioni, consulta Hub-and-spoke di rete.

Ogni applicazione ha un repository Git separato.

Alcune organizzazioni utilizzano un singolo repository Git (un monorepo) per il codice sorgente, invece che in più repository. Se usi un monorepo, puoi modifica lo di deployment del progetto per supportare il tuo repository. Completa le seguenti informazioni:

• Anziché creare un nuovo repository per ogni nuova applicazione, crea un nel repository esistente.
• Invece di concedere all'applicazione le autorizzazioni di proprietario sul nuovo repository gruppo di sviluppatori, concedi l'autorizzazione di scrittura sul repository esistente e degli sviluppatori di applicazioni, un revisore obbligatorio per le modifiche nella sottodirectory. Utilizza la Funzionalità e protezione dei rami di CODEOWNERS.