api_fingerprint (erforderlich)
|
Der Fingerprint des von Ihnen hochgeladenen API-Signaturschlüssels. |
api_private_key_path (erforderlich)
|
Der vollständige Pfad und Name der Datei, die Ihren Private API-Signaturschlüssel enthält. |
compartment_id (erforderlich)
|
Die OCID des Compartments, in dem Sie die Ressourcen erstellen möchten. |
tenancy_id (erforderlich)
|
Die OCID Ihres Mandanten. |
user_id (erforderlich)
|
Die OCID des Benutzers, den Terraform zur Authentifizierung mit Oracle Cloud Infrastructure verwenden soll. |
ssh_private_key_path |
Der vollständige Pfad und Name der Datei, die den privaten SSH-Schlüssel enthält, der dem Public Key entspricht, den Sie für den Bastion-Host angeben möchten.
Mit diesem Wert wird der Befehl ssh erstellt, mit dem Sie auf den Bastion-Host zugreifen können. Der Befehl ssh wird in der Ausgabe angezeigt, wenn Sie die Terraform-Konfiguration anwenden. Beachten Sie, dass Terraform den Private Key nicht liest oder kopiert.
|
ssh_public_key_path |
Der vollständige Pfad und Name der Datei, die den SSH-Public Key enthält, den Sie für den Bastion-Host angeben möchten. |
label_prefix |
Eine kurze ID, die Sie als Präfix in den Namen der Ressourcen verwenden möchten.
Verwenden Sie eine Zeichenfolge, mit der Sie den Zweck oder die Art der Ressourcen anhand ihrer Namen identifizieren können. Beispiel: Wenn Sie die Terraform-Konfiguration verwenden möchten, um eine Test- oder Staging-Umgebung einzurichten, sollten Sie das Präfix test oder staging verwenden.
|
Bereich |
Die ID des Bereichs, in dem Sie die Ressourcen erstellen möchten. Die ID der Region "US East (Ashburn)" ist z. B. us-ashburn-1.
|
nat_gateway_enabled |
Geben Sie true an, um ein NAT-Gateway für VCN zu erstellen.
Ein NAT-Gateway ist erforderlich, wenn eine der privaten Compute-Instanzen (wie Admin-Host oder Kubernetes-Mitarbeiterknoten) auf Hosts im öffentlichen Internet zugreifen muss.
|
newbits und netnum |
Wenn Sie die Konfiguration anwenden, übergibt Terraform die Werte von newbits und netnum als Argumente an die Terraform-Funktion cidrsubnet(). Diese Funktion berechnet die CIDR-Präfixe der Subnetze für den Bastion-Host, den Admin-Host, Load Balancer-Knoten und die Kubernetes Worker-Knoten.
- Mit
newbits wird die Größe des Subnetzes bestimmt. Dies ist der Unterschied zwischen der Netzmaske von VCN und der Netzmaske, die Sie für das Bastion-Subnetz benötigen.
Beispiel: Wenn Sie ein Subnetz mit der Netzmaske /29 in einer /16 - VCN erstellen möchten, geben Sie 13 als Wert von newbits an (d.h. 29 minus 16).
Ein niedrigerer newbits-Wert führt zu einem Subnetz mit einem größeren Adressraum.
netnum wird verwendet, um die Grenzen des Subnetzes zu bestimmen. Dies ist der nullbasierte Index des Subnetzes, wenn das Netzwerk mit newbits maskiert wird.
Wenn Sie mit dem vorherigen Beispiel newbits=13 und netnum=0 angeben, gibt die Funktion cidrsubnet() das CIDR-Präfix des Subnetzes 10.0.0.0/29 zurück, das der erste /29-Adressraum innerhalb von 10.0.0.0/16 VCN ist.
Standardwerte: netnum = {
admin = 33
bastion = 32
int_lb = 16
pub_lb = 17
workers = 1
}
newbits = {
admin = 13
bastion = 13
lb = 11
workers = 2
}
Wenn Sie diese Variablen bei den Standardwerten belassen und 10.0.0.0/16 als CIDR-Bereich für VCN angeben, berechnet die Terraform-Funktion cidrsubnet() die folgenden CIDR-Präfixe für die Subnetze. Die verfügbaren Adressen werden in Klammern angezeigt. Beachten Sie, dass die ersten beiden Adressen und die letzte Adresse in einem Subnetz vom Networking-Service reserviert werden.
- Bastion-Subnetz:
10.0.1.0/29 (verfügbare Adressen: 10.0.1.2 bis 10.0.1.6, d.h. 5 Hosts)
- Admin-Subnetz:
10.0.1.8/29 (10.0.1.10 für 10.0.1.14; 5 Hosts)
- Internes Load Balancer-Subnetz:
10.0.2.0/27 (10.0.2.2 für 10.0.2.30; 29-Knoten)
- Öffentliches Load Balancer-Subnetz:
10.0.2.32/27 (10.0.2.34 für 10.0.2.62; 29-Knoten)
- Subnetz der Kubernetes-Mitarbeiterknoten:
10.0.64.0/18 (10.0.64.2 bis 10.0.127.254; 16381 Knoten)
Wenn Sie Subnetze benötigen, die unterschiedliche Adressen oder Größen als die Standardeinstellungen haben, sollten Sie die entsprechenden Werte für newbits und netnum bestimmen. Hierzu benötigen Sie grundlegende Kenntnisse zu durchlaufenden IP-Adressen. Weitere Informationen zur Funktion cidrsubnet() finden Sie in der Terraform-Dokumentation.
Stellen Sie sicher, dass sich die hier angegebenen CIDR-Blöcke nicht mit dem CIDR-Block überschneiden, den Sie für die Kubernetes-Pfund (pods_cidr) angeben.
|
service_gateway_enabled |
Geben Sie true an, um ein Servicegateway für VCN zu erstellen.
Ein Servicegateway ist erforderlich, wenn die Compute-Instanzen in VCN auf andere Oracle-Services wie Oracle Cloud Infrastructure Object Storage zugreifen müssen.
|
vcn_cidr |
Ein IPv4 CIDR-Block Ihrer Wahl für VCN.
Der Standard ist 10.0.0.0/16. Der zulässige Bereich ist /16 bis /30
Stellen Sie sicher, dass sich der hier angegebene CIDR-Block nicht mit dem CIDR-Block überschneidet, den Sie für die Kubernetes-Services (services_cidr) angeben.
|
vcn_dns_label |
Das Namenspräfix für den internen DNS-Namen der VCN.
Der hier angegebene Name wird oraclevcn.com vorangestellt, um den DNS-Domainnamen von VCN zu bilden. Beispiel: Wenn Sie oke als Präfix angeben, wäre der DNS-Domainname von VCN oke.oraclevcn.com
|
vcn_name |
Der Name der VCN-Ressource. |
bastion_access |
Der Bereich der IP-Adressen (in CIDR-Notation), aus dem SSH-Zugriff auf die Bastion gewährt werden muss.
Um SSH-Zugriff von einem beliebigen Host (0.0.0.0/0) zuzulassen, lassen Sie die Variable auf den Standardwert ANYWHERE.
|
bastion_enabled |
Geben Sie true an, um einen Bastion-Host zu erstellen.
|
bastion_image_id |
Die OCID des Bildes, mit dem der Bastion-Host erstellt werden soll.
Wenn Sie diese Variable beim Standardwert NONE belassen, wird ein Oracle Autonomous Linux-Bild verwendet.
|
bastion_notification_enabled |
Mit dem Oracle Cloud Infrastructure-Benachrichtigungsservice können Sie Statusmeldungen vom Bastion-Host erhalten, wenn Updates eingespielt werden, oder wenn ein bekannter Auslastungsversuch von Oracle Ksplice ermittelt wurde.
Geben Sie true an, um das Senden von Benachrichtigungen für den Bastion-Host zu aktivieren.
Hinweis: Der Terraform-Code in dieser Lösung konfiguriert nur Benachrichtigungen für den Bastion-Host, wenn Sie das Oracle Autonomous Linux-Standardbild verwenden.
|
bastion_notification_endpoint |
Die E-Mail-Adresse, an die die Benachrichtigungen gesendet werden sollen. Diese Variable ist erforderlich, wenn Sie bastion_notification_enabled auf true setzen.
|
bastion_notification_protocol |
Setzen Sie diese Variable auf EMAIL.
|
bastion_notification_topic |
Ein Name für das zu erstellende Benachrichtigungsthema. Diese Variable ist erforderlich, wenn Sie bastion_notification_enabled auf true setzen.
|
bastion_package_upgrade |
Geben Sie true an, wenn die Sicherheits-Packages des Bastion-Hosts beim ersten Booten des Hosts upgegradet werden sollen.
Wenn diese Variable auf true gesetzt ist, steht sie nach der Bereitstellung des Bastion-Hosts während des Upgrades der Sicherheits-Packages für einen kurzen Zeitraum nicht zur Verfügung. Durch die Aktivierung dieses Upgrades werden jedoch die Sicherheitslücken des Bastion-Hosts minimiert.
|
bastion_shape |
Die Rechenleistungseinheit, die Sie für den Bastion-Host verwenden möchten. |
bastion_timezone |
Die Zeitzone, die für den Bastion-Host konfiguriert werden soll, im IANA-Zeitzonenformat (Beispiel: America/Los_Angeles).
|
admin_enabled |
Geben Sie true an, um einen Admin-Host zu erstellen.
|
admin_image_id |
Die OCID des Bildes, mit dem der Bastion-Host erstellt werden soll.
Wenn Sie diese Variable auf dem Standardwert NONE belassen, wird ein von Oraclebereitgestelltes Linux-Image verwendet.
|
admin_instance_principal |
Geben Sie true an, wenn Sie den Admin-Host aktivieren möchten, um alle Ressourcen in dem von Ihnen angegebenen Compartment zu verwalten.
Verwenden Sie dieses Feature, wenn Sie CLI-Befehle ausführen oder API-Aufrufe vom Admin-Host vornehmen möchten, um Ressourcen in der Topologie zu verwalten.
Hinweis: Jeder Benutzer, der sich mit SSH bei einer Compute-Instanz anmelden kann, übernimmt die Berechtigungen des Instanz-Principals, die der Instanz zugewiesen sind. Berücksichtigen Sie dies, wenn Sie entscheiden, ob der Admin-Host als Instanz-Principal angegeben werden soll. Sie können dieses Feature jederzeit deaktivieren oder aktivieren, ohne dass dies Auswirkungen auf den Admin-Host hat.
Wenn Sie diese Variable auf true festlegen, wird der Admin-Host zu einem Mitglied einer dynamischen Gruppe, und es wird eine Policy-Anweisung erstellt, mit der die dynamische Gruppe alle Ressourcen im Compartment verwalten kann.
|
|
admin_notification_enabled
admin_notification_endpoint
admin_notification_protocol
admin_notification_topic
|
Diese Variablen als Standardwerte beibehalten. Das Aktivieren von Benachrichtigungen für den Admin-Host wird derzeit in diesem Terraform-Code nicht unterstützt. |
admin_package_upgrade |
Geben Sie true an, wenn die Sicherheits-Packages des Admin-Hosts beim ersten Hochfahren des Hosts upgegradet werden sollen.
Wenn diese Variable auf true gesetzt ist, ist sie nach dem Provisioning des Admin-Hosts während des Upgrades der Sicherheits-Packages für einen kurzen Zeitraum nicht verfügbar. Durch die Aktivierung dieses Upgrades werden jedoch die Sicherheitslücken des Admin-Hosts minimiert.
|
admin_shape |
Die Rechenleistungseinheit, die Sie für den Admin-Host verwenden möchten. |
admin_timezone |
Die Zeitzone, die für den Admin-Host konfiguriert werden soll, im IANA-Zeitzonenformat (Beispiel: America/Los_Angeles).
|
availability_domains |
Die Availability-Domain, in der Sie Admin- und Basishosts bereitstellen möchten.
Beispiel: Um den Bastion-Host in der zweiten Availability-Domain bereitzustellen, legen Sie bastion = 2 fest.
Wenn die angegebene Region nur eine Availability-Domain enthält, behalten Sie diese Variable auf den Standardwert 1 bei.
|
tagging |
Geben Sie die Tags an, die Sie den Compute- und Netzwerkressourcen zuweisen möchten. |
allow_node_port_access |
Geben Sie true an, wenn Sie TCP-Verkehr zu den Kubernetes Worker-Knoten zulassen möchten, wenn diese im öffentlichen Modus bereitgestellt werden.
|
allow_worker_ssh_access |
Geben Sie true an, wenn Sie SSH-Verbindungen zu den Kubernetes Worker-Knoten über den Bastion-Host zulassen möchten.
Auch wenn die Worker-Knoten im öffentlichen Modus bereitgestellt werden, müssen SSH-Verbindungen über den Bastion-Host gehen.
Wenn Sie diese Variable auf true setzen, müssen Sie auch bastion_enabled = true festlegen.
|
cluster_name |
Ein Name für das Kubernetes-Cluster. |
dashboard_enabled |
Geben Sie true an, wenn das Standard-Kubernetes-Dashboard erstellt werden soll.
|
kubernetes_version |
Die Version von Kubernetes, die für die Mitarbeiterknoten verwendet werden soll.
Wenn Sie diese Variable zum Standardwert LATEST lassen, wird die zuletzt unterstützte Version ausgewählt. Um eine bestimmte Version zu verwenden, geben Sie diese Version an.
|
node_pools |
Die Anzahl der zu erstellenden Knotenpools, die Größe jedes Pools und die Rechenleistungseinheit, die für die Mitarbeiterknoten verwendet werden soll, im folgenden Format:node_pools = {
"np1" = ["computeShape", numberOfNodes]
"np2" = ["computeShape", numberOfNodes]
"np3" = ["computeShape", numberOfNodes]
...
}
np1, np2 und np3 sind beliebige Namen, die einzelne Knotenpools darstellen.
computeShape ist die Rechenleistungseinheit, die für die Mitarbeiterknoten im Pool verwendet werden soll.
numberOfNodes ist die Anzahl der Kubernetes-Mitarbeiterknoten, die im Pool erstellt werden sollen. In jedem Pool werden mindestens drei Knoten erstellt, auch wenn Sie einen niedrigeren Wert angeben.
Das folgende Beispiel gilt für ein Cluster, das aus zwei Pools besteht, von denen jeder eine andere Rechenleistungseinheit verwendet und eine andere Anzahl von Kubernetes Worker-Knoten enthält: node_pools = {
"np1" = ["VM.Standard2.1", 3]
"np2" = ["VM.Standard2.2", 5]
}
|
node_pool_name_prefix |
Das Namenspräfix für die Knotenpools.
Die Namen der Knotenpools werden generiert, indem die Werte von label_prefix, node_pool_name_prefix und die Knotenpoolnummer verkettet werden. Beispiel: Wenn Sie label_prefix = "prod" und node_pool_name_prefix = "np" angeben, würden die generierten Namen der Knotenpools prod-np-1, prod-np-2, prod-np-3 usw. sein.
|
node_pool_image_id |
Die OCID des Bildes, das für die Kubernetes Worker-Knoten verwendet werden soll.
Wenn Sie diese Variable beim Standardwert NONE belassen, wird ein Bild verwendet, das mit den Werten übereinstimmt, die Sie für node_pool_os und node_pool_os_version angeben.
|
node_pool_os |
Das Betriebssystem, das für die Kubernetes Worker-Knoten verwendet werden soll (Beispiel: "Oracle Linux").
Diese Einstellung wird nur berücksichtigt, wenn Sie node_pool_image_id = "NONE" festlegen.
|
node_pool_os_version |
Die Version des Betriebssystems, die für die Kubernetes-Mitarbeiterknoten verwendet werden soll (Beispiel: "7.7").
Diese Einstellung wird nur berücksichtigt, wenn Sie node_pool_image_id = "NONE" festlegen.
|
pods_cidr |
Ein IPv4 CIDR-Block Ihrer Wahl für die Kubernetes Pods.
Stellen Sie sicher, dass sich der hier angegebene CIDR-Block nicht mit dem CIDR-Block überschneidet, den Sie für VCN (vcn_cidr) angeben.
|
services_cidr |
Ein IPv4 CIDR-Block Ihrer Wahl für die Kubernetes Pods.
Stellen Sie sicher, dass sich der hier angegebene CIDR-Block nicht mit dem CIDR-Block überschneidet, den Sie für VCN (vcn_cidr) angeben.
|
worker_mode |
Geben Sie public an, wenn der Zugriff auf die Worker-Knoten über das öffentliche Internet erfolgen muss. Setzen Sie diese Variable andernfalls auf private.
Wenn Sie worker_mode = "private" festlegen, legen Sie nat_gateway_enabled = true fest.
|
lb_subnet_type und preferred_lb_subnets |
Die Werte, die Sie für lb_subnet_type und preferred_lb_subnets angeben, bestimmen den Typ der Subnetze, die für alle Load Balancer-Knoten verwendet werden müssen, die Sie mit dem Kubernetes-Service vom Typ LoadBalancer bereitstellen.
Öffentliche Load Balancer haben öffentliche IP-Adressen. Interne Load Balancer haben nur private IP-Adressen und sind nicht über das öffentliche Internet zugänglich.
- Wenn Sie öffentliche Load Balancer verwenden möchten, setzen Sie
preferred_lb_subnet = "public" und subnet_type auf "both" oder "public".
- Wenn Sie interne Load Balancer verwenden möchten, setzen Sie
preferred_lb_subnet = "internal" und subnet_type auf "both" oder "internal".
Auch wenn Sie die Load Balancer-Subnetze als intern festlegen, müssen Sie die entsprechenden Annotationen (wie service.beta.kubernetes.io/oci-load-balancer-internal: "true") festlegen, wenn Sie interne Load Balancer-Services erstellen. Die Festlegung der Subnetze, die privat sein sollen, reicht nicht aus.
Informationen zum Erstellen interner Load Balancer finden Sie in der Oracle Cloud Infrastructure-Dokumentation.
|
secret_id |
Die ID des Secret im Oracle Cloud Infrastructure Vault-Service, wobei das Authentifizierungstoken, das für das Abrufen von Anwendungs-Images aus Oracle Cloud Infrastructure Registry verwendet werden soll, gespeichert wird.
Sie müssen außerdem Folgendes festlegen: bastion_enabled = true
admin_enabled = true
admin_instance_principal = true
|
email_address |
Die E-Mail-Adresse, die beim Generieren des Docker-Secrets verwendet werden soll. Eine E-Mail-Adresse ist erforderlich, unabhängig davon, was Sie angeben.
Diese Variable ist erforderlich, wenn Sie secret_id angeben.
|
tenancy_name |
Der Oracle Cloud Infrastructure Object Storage-Namespace des Mandanten, der die Registry enthält, aus der Images für Deployments in das Kubernetes-Cluster abgerufen werden sollen.
Diese Variable ist erforderlich, wenn Sie secret_id angeben.
|
username |
Der Benutzername, für den Sie das Authentifizierungstoken generiert haben, das in secret_id gespeichert ist.
Diese Variable ist erforderlich, wenn Sie secret_id angeben.
|
install_helm |
Geben Sie true an, wenn Helm installiert werden soll.
Helm ist ein Package Manager für Kubernetes.
Um Helm zu installieren, müssen Sie auch admin_instance_principal = true festlegen.
|
helm_version |
Die Version des zu installierenden Helm-Clients.
Tiller (das serverseitige Gegenstück von Helm) wird automatisch upgegradet.
|
install_calico |
Geben Sie true an, wenn Calico installiert werden soll.
Mit Calico können Sie Netzwerk-Policys für Container Workloads implementieren, die in Kubernetes-Clustern bereitgestellt sind.
Wenn Sie install_calico = true festlegen, müssen Sie auch Folgendes festlegen: bastion_enabled = true
admin_enabled = true
admin_instance_principal = true
|
calico_version |
Die zu installierende Version von Calico. |
install_metricserver |
Geben Sie true an, wenn Kubernetes Metrics Server installiert werden soll.
Standardmäßig wird die neueste Version im Namespace kube-system installiert. Der Kubernetes-Metrikserver aggregiert die Ressourcennutzungsdaten für ein Cluster.
Wenn Sie install_metricserver = true festlegen, müssen Sie auch Folgendes festlegen: bastion_enabled = true
admin_enabled = true
admin_instance_principal = true
|
use_encryption |
Wenn Sie Kubernetes secrets mit dem Oracle Cloud Infrastructure Vault-Service verschlüsseln möchten, setzen Sie diese Variable auf true.
Wenn Sie use_encryption = true festlegen, müssen Sie auch Folgendes festlegen: bastion_enabled = true
admin_enabled = true
admin_instance_principal = true
|
existing_key_id |
Die OCID eines vorhandenen Schlüssels, der im Oracle Cloud Infrastructure Vault-Service erstellt wurde.
Diese Variable ist erforderlich, wenn Sie use_encryption auf true setzen.
|
create_service_account |
Wenn Sie externe Prozesse und Tools (wie eine CI/CD-Pipeline) auf das Cluster zugreifen möchten, setzen Sie diese Variable auf true. Ein Service-Account wird mit seinem eigenen Authentifizierungstoken erstellt.
Wenn Sie create_service_account = true festlegen, müssen Sie auch Folgendes festlegen: bastion_enabled = true
admin_enabled = true
admin_instance_principal = true
|
service_account_name |
Der Name des zu erstellenden Service-Accounts. |
service_account_namespace |
Der Kubernetes-Namespace, in dem der Account erstellt werden soll. |
service_account_cluster_role_binding |
Der Name des Clusterrollen-Bindings für den Service-Account. |