api_fingerprint (obligatoire)
|
Empreinte de la clé de signature d'API que vous avez téléchargée. |
api_private_key_path (obligatoire)
|
Nom et chemin complet du fichier contenant la clé de signature de l'API privée. |
compartment_id (obligatoire)
|
OCID du compartiment dans lequel créer les ressources. |
tenancy_id (obligatoire)
|
OCID de votre location. |
user_id (obligatoire)
|
OCID de l'utilisateur que Terraform doit utiliser pour l'authentification auprès d'Oracle Cloud Infrastructure. |
ssh_private_key_path |
Chemin d'accès complet et nom du fichier contenant la clé SSH privée correspondant à la clé publique à fournir pour l'hôte de base.
Cette valeur est utilisée pour construire la commande ssh que vous pouvez utiliser pour accéder à l'hôte de base. La commande ssh s'affiche dans la sortie lorsque vous appliquez la configuration Terraform. Terraform ne lit ou ne copie pas la clé privée.
|
ssh_public_key_path |
Chemin d'accès complet et nom du fichier contenant la clé SSH publique à fournir pour l'hôte de base. |
label_prefix |
Identificateur court, qui doit être utilisé comme préfixe dans les noms des ressources.
Utilisez une chaîne qui vous aidera à identifier l'objectif ou la nature des ressources en consultant leurs noms. Par exemple, si vous voulez utiliser la configuration Terraform pour configurer un environnement de test ou de pré-production, utilisez le préfixe test ou staging.
|
zone |
ID de la région dans laquelle vous souhaitez créer les ressources. Par exemple, l'ID de la région Est des Etats-Unis (Ashburn) est us-ashburn-1.
|
nat_gateway_enabled |
Spécifiez true pour créer une passerelle NAT pour VCN.
Une passerelle NAT est requise si l'une des instances de calcul privées (comme l'hôte d'administration ou les noeuds de travail Kubernetes) doit accéder à des hôtes sur l'Internet public.
|
newbits et netnum |
Lorsque vous appliquez la configuration, Terraform transmet les valeurs de newbits et netnum en tant qu'arguments à la fonction Terraform cidrsubnet(). Cette fonction calcule les préfixes CIDR des sous-réseaux pour l'hôte de base, l'hôte d'administration, les noeuds d'équilibreur de charge et les noeuds de salarié Kubernetes.
newbits est utilisé pour déterminer la taille du sous-réseau. Il s'agit de la différence entre le masque de réseau du VCN et celui requis pour le sous-réseau bastion.
Par exemple, pour créer un sous-réseau avec le masque de réseau /29 dans un VCN /16, indiquez 13 comme valeur de newbits (c'est-à-dire 29 moins 16).
Une valeur newbits faible crée un sous-réseau avec un espace d'adressage plus grand.
netnum est utilisé pour déterminer les limites du sous-réseau. Il s'agit de l'indice de sous-réseau basé sur zéro lorsque le réseau est masqué avec newbits.
En reprenant l'exemple précédent, si vous avez indiqué newbits=13 et netnum=0, la fonction cidrsubnet() renvoie le préfixe CIDR de sous-réseau 10.0.0.0/29, c'est-à-dire le premier espace d'adressage /29 dans le VCN 10.0.0.0/16.
Valeurs par défaut : netnum = {
admin = 33
bastion = 32
int_lb = 16
pub_lb = 17
workers = 1
}
newbits = {
admin = 13
bastion = 13
lb = 11
workers = 2
}
Si vous conservez ces variables aux valeurs par défaut et que vous indiquez 10.0.0.0/16 comme plage de CIDR pour le serveur VCN, la fonction Terraform cidrsubnet() calcule les préfixes CIDR suivants pour les sous-réseaux. Les adresses disponibles apparaissent entre parenthèses. Notez que les deux premières adresses et dernière adresse d'un sous-réseau sont réservées par le service réseau.
- Sous-réseau de base :
10.0.1.0/29 (adresses disponibles : 10.0.1.2 à 10.0.1.6, c'est-à-dire 5 hôtes)
- Sous-réseau d'administration :
10.0.1.8/29 (10.0.1.10 à 10.0.1.14 ; 5 hôtes)
- Sous-réseau d'équilibreur de charge interne :
10.0.2.0/27 (10.0.2.2 à 10.0.2.30 ; 29 noeuds)
- Sous-réseau d'équilibreur de charge public :
10.0.2.32/27 (10.0.2.34 à 10.0.2.62 ; 29 noeuds)
- Sous-réseau des noeuds actif Kubernetes :
10.0.64.0/18 (10.0.64.2 à 10.0.127.254 ; 16381 noeuds)
Si vous avez besoin de sous-réseaux possédant des adresses ou des tailles différentes de celles par défaut, vous devez déterminer les valeurs appropriées pour newbits et netnum. Pour cela, vous devez avoir des connaissances de base sur les adresses IP sans classe. Reportez-vous également à la documentation Terraform pour la fonction cidrsubnet().
Assurez-vous que les blocs CIDR spécifiés ici ne se chevauchent pas avec le bloc CIDR que vous indiquez pour les pods Kubernetes (pods_cidr).
|
service_gateway_enabled |
Spécifiez true pour créer une passerelle de service pour VCN.
Une passerelle de service est obligatoire si les instances de calcul de VCN doivent accéder à d'autres services Oracle tels qu'Oracle Cloud Infrastructure Object Storage.
|
vcn_cidr |
Bloc IPv4 CIDR de votre choix pour VCN.
La valeur par défaut est 10.0.0.0/16. La plage autorisée va de /16 à /30.
Assurez-vous que le bloc CIDR que vous indiquez ici ne chevauche pas le bloc CIDR que vous indiquez pour les services Kubernetes (services_cidr).
|
vcn_dns_label |
Préfixe de nom pour le nom DNS interne du serveur VCN.
Le nom que vous indiquez ici est précédé de oraclevcn.com pour former le nom de domaine DNS du serveur VCN. Par exemple, si vous indiquez oke comme préfixe, le nom de domaine DNS de VCN est oke.oraclevcn.com
|
vcn_name |
Nom de la ressource VCN. |
bastion_access |
Plage d'adresses IP (en notation CIDR) à partir de laquelle l'accès SSH à la base doit être autorisé.
Pour autoriser l'accès SSH à partir de n'importe quel hôte (0.0.0.0/0), laissez la variable à sa valeur par défaut, ANYWHERE.
|
bastion_enabled |
Indiquez true pour créer un hôte de base.
|
bastion_image_id |
OCID de l'image à utiliser pour créer l'hôte de base.
Si vous conservez cette variable à la valeur par défaut, NONE, une image Oracle Autonomous Linux est utilisée.
|
bastion_notification_enabled |
Vous pouvez utiliser Oracle Cloud Infrastructure Notification Service pour recevoir les messages de statut de l'hôte de base lorsque des mises à jour sont appliquées ou lorsqu'une tentative d'exploitation connue a été détectée par Oracle Ksplice.
Indiquez true pour activer l'envoi de notifications sur l'hôte de base.
Remarque : Le code Terraform de cette solution configure les notifications pour l'hôte de base uniquement lorsque vous utilisez l'image Linux autonome Oracle par défaut.
|
bastion_notification_endpoint |
Adresse électronique à laquelle les notifications doivent être envoyées. Cette variable est obligatoire si vous affectez la valeur true à bastion_notification_enabled.
|
bastion_notification_protocol |
Définissez cette variable sur EMAIL.
|
bastion_notification_topic |
Nom du sujet de notification à créer. Cette variable est obligatoire si vous affectez la valeur true à bastion_notification_enabled.
|
bastion_package_upgrade |
Spécifiez true si vous souhaitez que les packages de sécurité de l'hôte de base soient mis à niveau lors de la première initialisation de l'hôte.
Lorsque cette variable est définie sur true, après le provisionnement de l'hôte de base, elle n'est plus disponible pendant une courte période pendant la mise à niveau des packages de sécurité. Toutefois, l'activation de cette mise à niveau réduit les vulnérabilités de l'hôte de base.
|
bastion_shape |
Forme de calcul à utiliser pour l'hôte de base. |
bastion_timezone |
Fuseau horaire à configurer pour l'hôte de base, au format de fuseau horaire IANA (par exemple, America/Los_Angeles).
|
admin_enabled |
Spécifiez true pour créer un hôte d'administration.
|
admin_image_id |
OCID de l'image à utiliser pour créer l'hôte de base.
Si vous conservez cette variable à la valeur par défaut, NONE, une image Linux fournie par Oracle est utilisée.
|
admin_instance_principal |
Spécifiez true si vous voulez activer l'hôte d'administration pour gérer toutes les ressources dans le compartiment indiqué.
Utilisez cette fonction si vous envisagez d'exécuter des commandes CLI ou d'effectuer des appels d'API à partir de l'hôte admin pour gérer les ressources dans la topologie.
Remarque : Tout utilisateur pouvant se connecter à une instance de calcul à l'aide de SSH hérite des privilèges instance-principal octroyés à l'instance. Pensez à vous indiquer si l'hôte d'administration est un principal d'instance. Vous pouvez désactiver cette fonction ou à tout moment sans incidence sur l'hôte d'administration.
Si vous définissez cette variable sur true, l'hôte admin devient membre d'un groupe dynamique, et une instruction de stratégie est créée pour permettre au groupe dynamique de gérer toutes les ressources du compartiment.
|
|
admin_notification_enabled
admin_notification_endpoint
admin_notification_protocol
admin_notification_topic
|
Conservez ces variables aux valeurs par défaut. L'activation des notifications pour l'hôte d'administration n'est pas prise en charge actuellement dans ce code Terraform. |
admin_package_upgrade |
Spécifiez true si vous souhaitez que les packages de sécurité de l'hôte d'administration soient mis à niveau lors de la première initialisation de l'hôte.
Lorsque cette variable est définie sur true, une fois les infos de paramétrage fournies pour l'hôte d'administration, elle n'est plus disponible pendant une courte période pendant la mise à niveau des packages de sécurité. Toutefois, l'activation de cette mise à niveau réduit les vulnérabilités de l'hôte d'administration.
|
admin_shape |
Forme de calcul à utiliser pour l'hôte d'administration. |
admin_timezone |
Fuseau horaire à configurer pour l'hôte d'administration, au format de fuseau horaire IANA (par exemple, America/Los_Angeles).
|
availability_domains |
Domaine de disponibilité sur lequel vous voulez provisionner les hôtes d'administration et de base.
Par exemple, pour fournir les infos de paramétrage de l'hôte de base dans le deuxième domaine de disponibilité, définissez bastion = 2.
Si la région que vous avez indiquée contient un seul domaine de disponibilité, conservez cette variable à sa valeur par défaut, 1.
|
tagging |
Indiquez les balises à affecter aux ressources de calcul et de mise en réseau. |
allow_node_port_access |
Indiquez true si vous souhaitez autoriser le trafic TCP vers les noeuds de travail Kubernetes lorsqu'ils sont déployés en mode public.
|
allow_worker_ssh_access |
Spécifiez true si vous souhaitez autoriser les connexions SSH aux noeuds de processus actif Kubernetes via l'hôte de base.
Même si les noeuds actifs sont déployés en mode public, les connexions SSH doivent passer par l'hôte de base.
Si vous définissez cette variable sur true, vous devez également définir bastion_enabled = true.
|
cluster_name |
Nom du cluster Kubernetes. |
dashboard_enabled |
Indiquez true si vous souhaitez créer le tableau de bord Kubernetes par défaut.
|
kubernetes_version |
Version de Kubernetes à utiliser pour les noeuds de salarié.
Si vous conservez cette variable à sa valeur par défaut, LATEST, la dernière version prise en charge est sélectionnée. Pour utiliser une version spécifique, indiquez cette version.
|
node_pools |
Nombre de pools de noeuds à créer, taille de chaque pool et forme de calcul à utiliser pour les noeuds de salarié, au format suivant :node_pools = {
"np1" = ["computeShape", numberOfNodes]
"np2" = ["computeShape", numberOfNodes]
"np3" = ["computeShape", numberOfNodes]
...
}
np1, np2 et np3 sont des noms arbitraires représentant des pools de noeuds individuels.
computeShape est la forme de calcul à utiliser pour les noeuds de salarié dans le pool.
numberOfNodes représente le nombre de noeuds de travail Kubernetes à créer dans le pool. Un minimum de trois noeuds est créé dans chaque pool, même si vous spécifiez une valeur inférieure.
L'exemple suivant concerne un cluster composé de deux pools, chacun utilisant une forme de calcul différente et contenant un nombre différent de noeuds de salarié Kubernetes : node_pools = {
"np1" = ["VM.Standard2.1", 3]
"np2" = ["VM.Standard2.2", 5]
}
|
node_pool_name_prefix |
Préfixe du nom des pools de noeuds.
Les noms des pools de noeuds sont générés par concaténation des valeurs de label_prefix, node_pool_name_prefix et du numéro de pool de noeuds. Par exemple, si vous indiquez label_prefix = "prod" et node_pool_name_prefix = "np", les noms générés des pools de noeuds seront prod-np-1, prod-np-2, prod-np-3, etc.
|
node_pool_image_id |
OCID de l'image à utiliser pour les noeuds de processus actif Kubernetes.
Si vous conservez cette variable à la valeur par défaut, NONE, une image qui correspond aux valeurs indiquées pour node_pool_os et node_pool_os_version est utilisée.
|
node_pool_os |
Système d'exploitation à utiliser pour les noeuds de travail Kubernetes (par exemple, "Oracle Linux").
Ce paramètre est pris en compte uniquement si vous définissez node_pool_image_id = "NONE"
|
node_pool_os_version |
Version du système d'exploitation à utiliser pour les noeuds de travail Kubernetes (par exemple, "7.7").
Ce paramètre est pris en compte uniquement si vous définissez node_pool_image_id = "NONE"
|
pods_cidr |
Bloc IPv4 CIDR de votre choix pour les pods Kubernetes.
Assurez-vous que le bloc CIDR que vous indiquez ici ne chevauche pas le bloc CIDR que vous indiquez pour le VCN (vcn_cidr).
|
services_cidr |
Bloc IPv4 CIDR de votre choix pour les pods Kubernetes.
Assurez-vous que le bloc CIDR que vous indiquez ici ne chevauche pas le bloc CIDR que vous indiquez pour le VCN (vcn_cidr).
|
worker_mode |
Spécifiez public si les noeuds de travail doivent être accessibles à partir du réseau Internet public. Sinon, paramétrez cette variable sur private.
Si vous définissez worker_mode = "private", définissez nat_gateway_enabled = true
|
lb_subnet_type et preferred_lb_subnets |
Les valeurs indiquées pour lb_subnet_type et preferred_lb_subnets déterminent le type de sous-réseau à utiliser pour les noeuds d'équilibreur de charge que vous déployez à l'aide du service Kubernetes de type LoadBalancer.
Les équilibreurs de charge publics possèdent des adresses IP publiques. Les équilibreurs de charge internes disposent uniquement d'adresses IP privées et ne sont pas accessibles à partir du réseau Internet public.
- Si vous prévoyez d'utiliser des équilibreurs de charge publics, définissez
preferred_lb_subnet = "public" et subnet_type sur "both" ou "public"
- Si vous prévoyez d'utiliser des équilibreurs de charge internes, définissez
preferred_lb_subnet = "internal" et subnet_type sur "both" ou "internal"
Même si vous définissez les sous-réseaux d'équilibreur de charge comme internes, vous devez définir les annotations appropriées (telles que service.beta.kubernetes.io/oci-load-balancer-internal: "true") lorsque vous créez des services d'équilibreur de charge internes. Il n'est pas suffisant de définir les sous-réseaux comme privés.
Pour plus d'informations sur la création des équilibreurs de charge internes, reportez-vous à la documentation Oracle Cloud Infrastructure.
|
secret_id |
ID de la clé secrète dans le service Oracle Cloud Infrastructure Vault, où le jeton d'authentification à utiliser pour extraire des images d'application d'Oracle Cloud Infrastructure Registry est stocké.
Vous devez également définir les éléments suivants : bastion_enabled = true
admin_enabled = true
admin_instance_principal = true
|
email_address |
Adresse électronique à utiliser lors de la génération du secret Docker. Une adresse électronique est requise, mais ce que vous spécifiez n'a pas d'importance.
Cette variable est obligatoire si vous spécifiez secret_id.
|
tenancy_name |
Espace de noms Oracle Cloud Infrastructure Object Storage de la location contenant le registre à partir duquel les images doivent être extraites pour les déploiements vers le cluster Kubernetes.
Cette variable est obligatoire si vous spécifiez secret_id.
|
username |
Nom utilisateur pour lequel vous avez généré le jeton d'authentification stocké dans secret_id.
Cette variable est obligatoire si vous spécifiez secret_id.
|
install_helm |
Indiquez true si vous souhaitez installer Helm.
Helm est un gestionnaire de packages pour Kubernetes.
Pour installer Helm, vous devez également définir admin_instance_principal = true.
|
helm_version |
Version du client Helm à installer.
Tiller (l'homologue côté serveur de Helm) est mis à niveau automatiquement.
|
install_calico |
Indiquez true si vous souhaitez installer Calico.
Vous pouvez utiliser Calico pour implémenter les stratégies réseau pour les charges de travail des conteneurs déployées sur des clusters Kubernetes.
Si vous définissez install_calico = true, vous devez également définir les éléments suivants : bastion_enabled = true
admin_enabled = true
admin_instance_principal = true
|
calico_version |
Version de Calico à installer. |
install_metricserver |
Indiquez true si vous souhaitez installer le serveur de mesures Kubernetes.
Par défaut, la dernière version est installée dans l'espace de noms kube-system. Le serveur de mesures Kubernetes agrège les données d'utilisation des ressources dans un cluster.
Si vous définissez install_metricserver = true, vous devez également définir les éléments suivants : bastion_enabled = true
admin_enabled = true
admin_instance_principal = true
|
use_encryption |
Si vous voulez utiliser le service Oracle Cloud Infrastructure Vault pour crypter les secrets de Kubernetes, définissez cette variable sur true.
Si vous définissez use_encryption = true, vous devez également définir les éléments suivants : bastion_enabled = true
admin_enabled = true
admin_instance_principal = true
|
existing_key_id |
OCID d'une clé existante créée dans le service Oracle Cloud Infrastructure Vault.
Cette variable est obligatoire si vous affectez la valeur true à use_encryption.
|
create_service_account |
Si vous voulez que des processus et des outils externes (tels qu'un pipeline d'intégration continue et de déploiement continu) accèdent au cluster, définissez cette variable sur true. Un compte de service est créé avec son propre jeton d'authentification.
Si vous définissez create_service_account = true, vous devez également définir les éléments suivants : bastion_enabled = true
admin_enabled = true
admin_instance_principal = true
|
service_account_name |
Nom du compte de service à créer. |
service_account_namespace |
Espace de noms Kubernetes dans lequel le compte doit être créé. |
service_account_cluster_role_binding |
Nom de la liaison de rôle de cluster pour le compte de service. |