api_fingerprint (obbligatorio)
|
L'impronta della chiave di firma API caricata. |
api_private_key_path (obbligatorio)
|
Il percorso completo e il nome del file che contiene la chiave di firma API privata. |
compartment_id (obbligatorio)
|
L'OCID del compartimento in cui si desidera creare le risorse. |
tenancy_id (obbligatorio)
|
L'OCID della tenancy. |
user_id (obbligatorio)
|
L'OCID dell'utente che dovrà essere usato da Terraform per l'autenticazione con Oracle Cloud Infrastructure. |
ssh_private_key_path |
Il percorso completo e il nome del file che contiene la chiave SSH privata corrispondente alla chiave pubblica che si desidera fornire per l'host di base.
Questo valore viene utilizzato per creare il comando ssh che è possibile utilizzare per accedere all'host di base. Il comando ssh viene visualizzato nell'output quando si applica la configurazione Terraform. Tenere presente che Terraform non legge né copia la chiave privata.
|
ssh_public_key_path |
Il percorso completo e il nome del file che contiene la chiave SSH pubblica da specificare per l'host di base. |
label_prefix |
Un identificativo breve, che si desidera utilizzare come prefisso nei nomi delle risorse.
Utilizzare una stringa che consenta di identificare lo scopo o la natura delle risorse mediante la visualizzazione dei relativi nomi. Ad esempio, se si intende utilizzare la configurazione Terraform per impostare un ambiente di test o di posizionamento nell'area intermedia, utilizzare il prefisso test o staging.
|
area |
L'ID dell'area in cui si desidera creare le risorse. Ad esempio, l'ID dell'area US East (Ashburn) è us-ashburn-1.
|
nat_gateway_enabled |
Specificare true per creare un gateway NAT per la VCN.
Un gateway NAT è necessario se una qualsiasi delle istanze di calcolo private (come l'host di amministrazione o i nodi operativi Kubernetes) deve accedere agli host su Internet pubblico.
|
newbits e netnum |
Quando si applica la configurazione, Terraform passa i valori di newbits e netnum come argomenti alla funzione Terraform cidrsubnet(). Questa funzione calcola i prefissi CIDR delle subnet per l'host di base, l'host di amministrazione, i nodi del load balancer e i nodi di lavoro Kubernetes.
newbits viene utilizzato per determinare la dimensione della subnet. È la differenza tra la maschera di rete della rete VCN e la maschera di rete necessaria per la subnet di base.
Ad esempio, per creare una subnet con la maschera di rete /29 in una VCN /16, specificare 13 come valore di newbits (ovvero 29 meno 16).
Un valore newbits inferiore genera una subnet con una maggiore quantità di spazio di indirizzi.
netnum viene utilizzato per determinare i limiti della subnet. Si tratta dell'indice su base zero della subnet quando la rete viene mascherata con newbits.
Se si continua con l'esempio precedente, se si specifica newbits=13 e netnum=0, la funzione cidrsubnet() restituisce il prefisso CIDR della subnet 10.0.0.0/29, ovvero il primo spazio di indirizzi /29 all'interno della VCN 10.0.0.0/16.
Valori predefiniti: netnum = {
admin = 33
bastion = 32
int_lb = 16
pub_lb = 17
workers = 1
}
newbits = {
admin = 13
bastion = 13
lb = 11
workers = 2
}
Se si esce da queste variabili nei valori predefiniti e si specifica 10.0.0.0/16 come intervallo CIDR per la VCN, la funzione Terraform cidrsubnet() calcola i seguenti prefissi CIDR per le subnet. Gli indirizzi disponibili vengono mostrati tra parentesi. I primi due indirizzi e l'ultimo indirizzo di una subnet sono riservati dal servizio di rete.
- Subnet Bastion:
10.0.1.0/29 (indirizzi disponibili: da 10.0.1.2 a 10.0.1.6, ovvero 5 host)
- Subnet di amministrazione:
10.0.1.8/29 (da 10.0.1.10 a 10.0.1.14; 5 host)
- Subnet interna del load balancer:
10.0.2.0/27 (10.0.2.2 in 10.0.2.30; 29 nodi)
- Subnet del load balancer pubblico:
10.0.2.32/27 (10.0.2.34 in 10.0.2.62; 29 nodi)
- Subnet dei nodi di lavoro di Kubernetes:
10.0.64.0/18 (10.0.64.2 in 10.0.127.254; 16381 nodi)
Se sono necessarie subnet con indirizzi o dimensioni diversi dalle impostazioni predefinite, è necessario determinare i valori appropriati per newbits e netnum. A tale scopo, è necessario avere una conoscenza di base sugli indirizzi IP senza classe. Vedere anche la documentazione di Terraform per la funzione cidrsubnet().
Assicurarsi che i blocchi CIDR specificati qui non si sovrappongano al blocco CIDR specificato per i pod Kubernetes (pods_cidr).
|
service_gateway_enabled |
Specificare true per creare un gateway di servizio per la VCN.
Un gateway di servizi è necessario se le istanze di calcolo nella rete VCN devono accedere ad altri servizi Oracle, ad esempio lo storage degli oggetti Oracle Cloud Infrastructure.
|
vcn_cidr |
Blocco CIDR IPv4 di tua scelta per la VCN.
L'impostazione predefinita è 10.0.0.0/16. L'intervallo consentito è da /16 a /30
Assicurarsi che il blocco CIDR specificato qui non si sovrapponga al blocco CIDR specificato per i servizi Kubernetes (services_cidr).
|
vcn_dns_label |
Il prefisso del nome per il nome DNS interno della VCN.
Il nome specificato qui è preceduto dal prefisso oraclevcn.com per formare il nome del dominio DNS della VCN. Ad esempio, se si specifica oke come prefisso, il nome del dominio DNS della VCN sarà oke.oraclevcn.com
|
vcn_name |
Il nome della risorsa VCN. |
bastion_access |
L'intervallo di indirizzi IP (nella notazione CIDR) dai quali è necessario consentire l'accesso SSH alla base.
Per consentire l'accesso SSH da qualsiasi host, ovvero 0.0.0.0/0, lasciare la variabile nel relativo valore predefinito, ANYWHERE.
|
bastion_enabled |
Specificare true per creare un host di base.
|
bastion_image_id |
L'OCID dell'immagine da usare per creare l'host di base.
Se si lascia questa variabile nel valore predefinito NONE, verrà utilizzata un'immagine Oracle Autonomous Linux.
|
bastion_notification_enabled |
È possibile utilizzare il servizio di notifica di Oracle Cloud Infrastructure per ricevere messaggi di stato dall'host di base quando gli aggiornamenti vengono applicati oppure quando Oracle Ksplice ha rilevato un tentativo di esplosione conosciuto.
Specificare true per consentire l'invio di notifiche per l'host di base.
Nota: Il codice Terraform in questa soluzione configura le notifiche per l'host di base solo quando si usa l'immagine Oracle Autonomous Linux predefinita.
|
bastion_notification_endpoint |
L'indirizzo di posta elettronica a cui inviare le notifiche. Questa variabile è obbligatoria se si imposta bastion_notification_enabled su true.
|
bastion_notification_protocol |
Impostare questa variabile su EMAIL.
|
bastion_notification_topic |
Il nome dell'argomento di notifica da creare. Questa variabile è obbligatoria se si imposta bastion_notification_enabled su true.
|
bastion_package_upgrade |
Specificare true se si desidera che i package di sicurezza dell'host di base vengano aggiornati al primo avvio dell'host.
Quando questa variabile è impostata su true, dopo il provisioning dell'host bastion non sarà disponibile per un breve periodo durante l'aggiornamento dei package di sicurezza. Tuttavia, l'abilitazione di questo aggiornamento riduce al minimo le vulnerabilità dell'host di base.
|
bastion_shape |
La forma di computazione che si desidera utilizzare per l'host di base. |
bastion_timezone |
Il fuso orario da configurare per l'host di base nel formato del fuso orario IANA (ad esempio, America/Los_Angeles).
|
admin_enabled |
Specificare true per creare un host di amministrazione.
|
admin_image_id |
L'OCID dell'immagine da usare per creare l'host di base.
Se si lascia questa variabile con il valore predefinito NONE, viene utilizzata un'immagine Linux fornita da Oracle.
|
admin_instance_principal |
Specificare true se si desidera consentire all'host di amministrazione di gestire tutte le risorse del compartimento specificato.
Usare questa funzione se si desidera eseguire i comandi CLI o effettuare chiamate API dall'host di amministrazione per gestire le risorse nella topologia.
Nota: Qualsiasi utente in grado di connettersi a un'istanza di computazione mediante SSH eredita i privilegi di contesto dell'istanza concessi all'istanza. Indicare se si desidera designare l'host di amministrazione come principal di istanza. È possibile disattivare o attivare questa funzione in qualsiasi momento senza alcun impatto sull'host di amministrazione.
Se si imposta questa variabile su true, l'host di amministrazione viene reso membro di un gruppo dinamico e viene creata un'istruzione di criterio per consentire al gruppo dinamico di gestire tutte le risorse nel compartimento.
|
|
admin_notification_enabled
admin_notification_endpoint
admin_notification_protocol
admin_notification_topic
|
Lasciare queste variabili ai valori predefiniti. L'abilitazione delle notifiche per l'host di amministrazione non è attualmente supportata in questo codice Terraform. |
admin_package_upgrade |
Specificare true se si desidera che i package di sicurezza dell'host di amministrazione vengano aggiornati al primo avvio dell'host.
Tenere presente che quando questa variabile è impostata su true, dopo il provisioning dell'host di amministrazione non sarà disponibile per un breve periodo di aggiornamento dei package di sicurezza. L'abilitazione di questo aggiornamento riduce tuttavia le vulnerabilità dell'host di amministrazione.
|
admin_shape |
La forma di computazione che si desidera usare per l'host di amministrazione. |
admin_timezone |
Il fuso orario da configurare per l'host di amministrazione nel formato del fuso orario IANA (ad esempio, America/Los_Angeles).
|
availability_domains |
Il dominio di disponibilità in cui si desidera eseguire il provisioning degli host di amministrazione e di base.
Ad esempio, per eseguire il provisioning dell'host di base nel secondo dominio di disponibilità, impostare bastion = 2.
Se l'area specificata contiene un solo dominio di disponibilità, lasciare questa variabile nel relativo valore predefinito 1.
|
tagging |
Specificare le tag che si desidera assegnare alle risorse di calcolo e di rete. |
allow_node_port_access |
Specificare true se si desidera consentire il traffico TCP ai nodi dei lavoratori di Kubernetes quando vengono distribuiti in modalità pubblica.
|
allow_worker_ssh_access |
Specificare true se si desidera consentire le connessioni SSH ai nodi dei lavoratori di Kubernetes tramite l'host di base.
Si noti che anche se i nodi dei lavoratori vengono distribuiti in modalità pubblica, le connessioni SSH devono passare attraverso l'host di base.
Se si imposta questa variabile su true, è necessario impostare anche bastion_enabled = true.
|
cluster_name |
Un nome per il cluster Kubernetes. |
dashboard_enabled |
Specificare true se si desidera creare il dashboard Kubernetes predefinito.
|
kubernetes_version |
Versione di Kubernetes da utilizzare per i nodi dei lavoratori.
Se si lascia questa variabile con il valore predefinito LATEST, verrà selezionata l'ultima versione supportata. Per utilizzare una versione specifica, specificare tale versione.
|
node_pools |
Il numero di pool di nodi da creare, la dimensione di ogni pool e la forma di computazione da utilizzare per i nodi dei lavoratori nel seguente formato:node_pools = {
"np1" = ["computeShape", numberOfNodes]
"np2" = ["computeShape", numberOfNodes]
"np3" = ["computeShape", numberOfNodes]
...
}
np1, np2 e np3 sono nomi arbitrari che rappresentano singoli pool di nodi.
computeShape è la forma di calcolo da utilizzare per i nodi dei lavoratori nel pool.
numberOfNodes è il numero di nodi di lavoro di Kubernetes da creare nel pool. In ogni pool vengono creati almeno tre nodi, anche se si specifica un valore inferiore.
L'esempio seguente riguarda un cluster costituito da due pool, ciascuno che utilizza una forma di computazione diversa e contenente un numero differente di nodi di lavoro Kubernetes: node_pools = {
"np1" = ["VM.Standard2.1", 3]
"np2" = ["VM.Standard2.2", 5]
}
|
node_pool_name_prefix |
Il prefisso del nome per i pool di nodi.
I nomi dei pool di nodi vengono generati concatenando i valori di label_prefix, node_pool_name_prefix e il numero del pool di nodi. Ad esempio, se si specifica label_prefix = "prod" e node_pool_name_prefix = "np", i nomi generati dei pool di nodi saranno prod-np-1, prod-np-2, prod-np-3 e così via.
|
node_pool_image_id |
L'OCID dell'immagine da usare per i nodi di lavoro di Kubernetes.
Se si lascia questa variabile al valore predefinito NONE, verrà utilizzata un'immagine corrispondente ai valori specificati per node_pool_os e node_pool_os_version.
|
node_pool_os |
Il sistema operativo da utilizzare per i nodi di lavoro di Kubernetes, ad esempio "Oracle Linux".
Questa impostazione viene considerata solo se si imposta node_pool_image_id = "NONE".
|
node_pool_os_version |
La versione del sistema operativo da utilizzare per i nodi dei lavoratori di Kubernetes, ad esempio "7.7".
Questa impostazione viene considerata solo se si imposta node_pool_image_id = "NONE".
|
pods_cidr |
Blocco CIDR IPv4 di tua scelta per i pod Kubernetes.
Assicurarsi che il blocco CIDR specificato qui non si sovrapponga al blocco CIDR specificato per la VCN (vcn_cidr).
|
services_cidr |
Blocco CIDR IPv4 di tua scelta per i pod Kubernetes.
Assicurarsi che il blocco CIDR specificato qui non si sovrapponga al blocco CIDR specificato per la VCN (vcn_cidr).
|
worker_mode |
Specificare public se i nodi dei lavoratori devono essere accessibili tramite la rete Internet pubblica. In caso contrario, impostare questa variabile su private.
Se si imposta worker_mode = "private", impostare nat_gateway_enabled = true
|
lb_subnet_type e preferred_lb_subnets |
I valori specificati per lb_subnet_type e preferred_lb_subnets determinano il tipo di subnet che devono essere utilizzati per qualsiasi nodo del load balancer distribuito utilizzando il servizio Kubernetes di tipo LoadBalancer.
I load balancer pubblici hanno indirizzi IP pubblici. I load balancer interni dispongono solo di indirizzi IP privati e non sono accessibili da Internet pubblico.
- Se si intende utilizzare load balancer pubblici, impostare
preferred_lb_subnet = "public" e subnet_type su "both" o "public"
- Se si intende utilizzare load balancer interni, impostare
preferred_lb_subnet = "internal" e subnet_type su "both" o "internal"
Anche se si impostano le subnet del load balancer in modo che siano interne, è necessario impostare le annotazioni appropriate, ad esempio service.beta.kubernetes.io/oci-load-balancer-internal: "true", quando si creano i servizi del load balancer interno. L'impostazione dell'unione delle subnet in modo che siano private non è sufficiente.
Per informazioni sulla creazione di load balancer interni, vedere la documentazione di Oracle Cloud Infrastructure.
|
secret_id |
L'ID del segreto nel servizio di Oracle Cloud Infrastructure Vault in cui è memorizzato il token di autenticazione da utilizzare per l'estrazione delle immagini applicazione da Oracle Cloud Infrastructure Registry.
È necessario impostare anche quanto segue: bastion_enabled = true
admin_enabled = true
admin_instance_principal = true
|
email_address |
L'indirizzo di posta elettronica da utilizzare quando si genera il segreto Docker. L'indirizzo e-mail è obbligatorio, ma non è importante per quello specificato.
Questa variabile è obbligatoria se si specifica secret_id.
|
tenancy_name |
Lo spazio di nomi dello storage degli oggetti Oracle Cloud Infrastructure della tenancy che contiene il registro dal quale devono essere estratte le immagini per le distribuzioni nel cluster Kubernetes.
Questa variabile è obbligatoria se si specifica secret_id.
|
username |
Il nome utente per il quale è stato generato il token di autenticazione memorizzato in secret_id.
Questa variabile è obbligatoria se si specifica secret_id.
|
install_helm |
Specificare true se si desidera che Helm venga installato.
Helm è un Package Manager per Kubernetes.
Per installare Helm, è necessario impostare anche admin_instance_principal = true.
|
helm_version |
La versione del client Helm da installare.
Tiller (la controparte lato server di Helm) viene aggiornato automaticamente.
|
install_calico |
Specificare true se si desidera installare Calico.
È possibile usare Calico per implementare i criteri di rete per i carichi di lavoro contenitori distribuiti nei cluster Kubernetes.
Se si imposta install_calico = true, è inoltre necessario impostare quanto segue: bastion_enabled = true
admin_enabled = true
admin_instance_principal = true
|
calico_version |
La versione di Calico da installare. |
install_metricserver |
Specificare true se si desidera installare il server delle metriche Kubernetes.
Per impostazione predefinita, la versione più recente viene installata nello spazio di nomi kube-system. Kubernetes Metrics Server aggrega i dati sull'uso delle risorse in un cluster.
Se si imposta install_metricserver = true, è inoltre necessario impostare quanto segue: bastion_enabled = true
admin_enabled = true
admin_instance_principal = true
|
use_encryption |
Se si desidera utilizzare il servizio di Oracle Cloud Infrastructure Vault per cifrare i segreti Kubernetes, impostare la variabile su true.
Se si imposta use_encryption = true, è inoltre necessario impostare quanto segue: bastion_enabled = true
admin_enabled = true
admin_instance_principal = true
|
existing_key_id |
L'OCID di una chiave esistente creata nel servizio Oracle Cloud Infrastructure Vault.
Questa variabile è obbligatoria se si imposta use_encryption su true.
|
create_service_account |
Se si desidera che i processi e gli strumenti esterni, ad esempio una pipeline CI/CD, possano accedere al cluster, impostare questa variabile su true. Un account di servizio viene creato con il proprio token di autenticazione.
Se si imposta create_service_account = true, è inoltre necessario impostare quanto segue: bastion_enabled = true
admin_enabled = true
admin_instance_principal = true
|
service_account_name |
Il nome dell'account di servizio da creare. |
service_account_namespace |
Spazio di nomi Kubernetes in cui deve essere creato l'account. |
service_account_cluster_role_binding |
Il nome dell'associazione del ruolo cluster per l'account di servizio. |