In diesem Dokument wird gezeigt, wie Sie minimale vSphere- und Google Cloud-Umgebungen für eine kleine Proof-of-Concept-Installation von Anthos-Cluster auf VMware (GKE On-Prem) einrichten.
Die Installation umfasst eine Administrator-Workstation, einen Administratorcluster und einen Nutzercluster.
Hinweise
Lesen Sie sich Anthos-Cluster auf VMware – Übersicht durch.
Weitere Informationen finden Sie unter vSphere-Lizenzanforderungen. Für diese minimale Installation ist eine vSphere Standard-Lizenz ausreichend.
Sie benötigen eine laufende Instanz von vCenter Server.
Sie benötigen ein vCenter-Nutzerkonto mit ausreichenden Berechtigungen. Notieren Sie sich den Nutzernamen und das Passwort für dieses Konto.
CPU-, RAM- und Speicherbedarf
Für diese minimale Installation können Sie einen einzelnen physischen Host verwenden, auf dem ESXi ausgeführt wird.
Das sind die Mindestressourcenanforderungen für Ihren ESXi-Host:
- 8 physische CPUs bei 2,7 GHz mit aktiviertem Hyperthreading
- 80 Gibibyte (GiB) RAM
Der Mindestspeicherbedarf beträgt 470 GiB.
Beispiel für Host und Datenspeicher
Hier sehen Sie ein Beispiel für einen ESXi-Host und einen vSphere-Datenspeicher, die die Anforderungen erfüllen:
ESXi-Host-Konfiguration:
- Hersteller: Dell Inc.
- Physische CPUs: 8 CPUs bei 2,7 GHz
- Prozessortyp: Intel(R) Xeon(R) Platinum 8168 CPU @ 2,70 GHz
- Prozessor-Sockets: 2
- ESXi-Version: 6.7U3
- vCenter-Serverversion: 6.7U3
- Hyperthreading: aktiviert
Datastore-Konfiguration:
- Typ: VMFS 6.82
- Laufwerkstyp: SSD
- Anbieter: DELL
- Laufwerkstyp: logisch
- RAID-Level: RAID1
vSphere-Objekte
Richten Sie in der vSphere-Umgebung die folgenden Objekte ein:
Load-Balancing
Die Cluster in dieser minimalen Installation verwenden den Load-Balancer MetalLB. Dieser Load-Balancer wird auf den Clusterknoten ausgeführt, sodass keine zusätzlichen VMs für das Load-Balancing erforderlich sind
IP-Adressen planen
Wenn Sie später einfache Cluster erstellen, geben Sie statische IP-Adressen für Ihre Clusterknoten an.
Für diese kleine Installation empfehlen wir, dass sich Ihre Administrator-Workstation, Ihre Administratorclusterknoten und die Nutzerclusterknoten in demselben VLAN in Ihrem vSphere-Netzwerk befinden. Angenommen, alle IP-Adressen im Bereich 172.16.20.0/24 werden an ein bestimmtes VLAN weitergeleitet. Nehmen wir außerdem an, dass Ihr Netzwerkadministrator besagt, dass Sie für VMs und virtuelle IP-Adressen (VIPs) 172.16.20.49 bis 172.16.20.72 verwenden können.
Das folgende Diagramm zeigt ein VLAN mit einer Administrator-Workstation, einem Administratorcluster und einem Nutzercluster. Beachten Sie, dass VIPs nicht in Verbindung mit einem bestimmten Knoten in einem Cluster angezeigt werden. Das liegt daran, dass der MetalLB-Load-Balancer wählen kann, welcher Knoten das VIP für einen einzelnen Dienst ankündigt. Im Nutzercluster könnte beispielsweise ein Worker-Knoten 172.16.20.63 und ein anderer Worker-Knoten 172.16.20.64 ankündigen.
Beispiel-IP-Adresse: Administrator-Workstation
Für die Administrator-Workstation verwendet dieses Beispiel die erste Adresse in dem Bereich, der Ihnen von Ihrem Netzwerkadministrator zugewiesen wird: 172.16.20.49.
Beispiel-IP-Adressen: Clusterknoten
Die folgende Tabelle enthält ein Beispiel für die Verwendung von IP-Adressen für Clusterknoten. Die Tabelle zeigt zwei zusätzliche Knoten: admin-vm-5 und user-vm-4. Die zusätzlichen Knoten werden während des Clusterupgrades, -updates und der automatischen Reparatur benötigt. Weitere Informationen finden Sie unter Knoten-IP-Adressen verwalten.
| VM-Hostname | Beschreibung | IP-Adresse |
|---|---|---|
| admin-vm-1 | Knoten der Steuerungsebene für den Administratorcluster | 172.16.20.50 |
| admin-vm-2 | Add-on-Knoten des Administratorclusters | 172.16.20.51 |
| admin-vm-3 | Add-on-Knoten des Administratorclusters | 172.16.20.52 |
| admin-vm-4 | Knoten der Steuerungsebene für den Nutzercluster Dieser Knoten befindet sich im Administratorcluster. |
172.16.20.53 |
| admin-vm-5 | 172.16.20.54 | |
| user-vm-1 | Worker-Knoten des Nutzerclusters | 172.16.20.55 |
| user-vm-2 | Worker-Knoten des Nutzerclusters | 172.16.20.56 |
| user-vm-3 | Worker-Knoten des Nutzerclusters | 172.16.20.57 |
| user-vm-4 | 172.16.20.58 |
Beispiel-IP-Adressen: VIPs für den Administratorcluster
Die folgende Tabelle enthält ein Beispiel dafür, wie Sie VIPs für Ihren Administratorcluster angeben können:
| VIP | Beschreibung | IP-Adresse |
|---|---|---|
| VIP für den Kubernetes API-Server des Administratorclusters | Auf dem Load-Balancer für den Administratorcluster konfiguriert | 172.16.20.59 |
| Add-ons-VIP des Administratorclusters | Auf dem Load-Balancer für den Administratorcluster konfiguriert | 172.16.20.60 |
Beispiel-IP-Adressen: VIPs für den Nutzercluster
Die folgende Tabelle enthält ein Beispiel dafür, wie Sie VIPs für Ihren Nutzercluster angeben können.
Beachten Sie, dass die VIP für den Kubernetes API-Server des Nutzerclusters auf dem Load-Balancer des Administratorclusters konfiguriert ist. Das liegt daran, dass der Kubernetes API-Server für einen Nutzercluster auf einem Knoten im Administratorcluster ausgeführt wird.
In den Clusterkonfigurationsdateien heißt das Feld, in dem Sie die VIP für einen Kubernetes API-Server angeben, controlPlaneVIP:
| VIP | Beschreibung | IP-Adresse |
|---|---|---|
| VIP für den Kubernetes API-Server des Nutzerclusters | Auf dem Load-Balancer für den Administratorcluster konfiguriert | 172.16.20.61 |
| Ingress-VIP | Auf dem Load-Balancer für den Nutzercluster konfiguriert | 172.16.20.62 |
| Dienst-VIPs | Zehn Adressen für Dienste vom Typ LoadBalancer.Nach Bedarf auf dem Load-Balancer für den Nutzercluster konfiguriert. Beachten Sie, dass dieser Bereich die Ingress-VIP enthält. Dies ist eine Anforderung für den MetalLB-Load-Balancer. |
172.16.20.62 - 172.16.20.71 |
IP-Adressen für Pods und Dienste
Bevor Sie einen Cluster erstellen, müssen Sie einen CIDR-Bereich angeben, der für Pod-IP-Adressen verwendet werden soll, und einen weiteren CIDR-Bereich, der für die ClusterIP-Adressen von Kubernetes-Diensten verwendet wird.
Legen Sie fest, welche CIDR-Bereiche Sie für Pods und Dienste verwenden möchten. Wenn Sie keinen anderen Grund haben, können Sie die folgenden Standardbereiche verwenden:
| Zweck | CIDR-Standardbereich |
|---|---|
| Administratorcluster-Pods | 192.168.0.0/16 |
| Nutzercluster-Pods | 192.168.0.0/16 |
| Dienste des Administratorclusters | 10.96.232.0/24 |
| Nutzercluster-Dienste | 10.96.0.0/20 |
Die Standardwerte veranschaulichen diese Punkte:
Der Pod-CIDR-Bereich kann für mehrere Cluster identisch sein.
Der Dienst-CIDR-Bereich eines Clusters darf sich nicht mit dem Dienst-CIDR-Bereich eines anderen Clusters überschneiden.
In der Regel benötigen Sie mehr Pods als Dienste. Daher benötigen Sie für einen bestimmten Cluster wahrscheinlich einen Pod-CIDR-Bereich, der größer als der Dienst-CIDR-Bereich ist. Der Standard-Pod-Bereich für einen Nutzercluster hat beispielsweise 2^(32–16) = 2^16 Adressen, der Standarddienstbereich für einen Nutzercluster jedoch nur 2^(32–20) = 2^12 Adressen.
Überlappung vermeiden
Es kann sinnvoll sein, nicht standardmäßige CIDR-Bereiche zu verwenden, um eine Überschneidung mit IP-Adressen zu vermeiden, die in Ihrem Netzwerk erreichbar sind. Die Dienst- und Pod-Bereiche dürfen sich nicht mit einer Adresse außerhalb des Clusters überschneiden, die Sie von innerhalb des Clusters erreichen möchten.
Angenommen, der Dienstbereich lautet 10.96.232.0/24 und der Pod-Bereich lautet 192.168.0.0/16. Traffic, der von einem Pod an eine Adresse in einem dieser Bereiche gesendet wird, wird als clusterintern behandelt und erreicht kein Ziel außerhalb des Clusters.
Insbesondere dürfen sich die Bereiche für Dienste und Pods nicht überschneiden mit:
IP-Adressen von Knoten in einem beliebigen Cluster
Von Load-Balancer-Maschinen verwendete IP-Adressen
Von Knoten der Steuerungsebene und Load-Balancern verwendete VIPs
IP-Adresse von vCenter-Servern, DNS-Servern und NTP-Servern
Wir empfehlen, die von RFC 1918 definierten privaten IP-Adressbereiche für Ihre Pod- und Dienstbereiche zu verwenden.
Dies ist ein Grund für die Empfehlung, RFC 1918-Adressen zu verwenden. Angenommen, Ihr Pod- oder Dienstbereich enthält externe IP-Adressen. Traffic von einem Pod an eine dieser externen Adressen wird als clusterinterner Traffic behandelt und erreicht das externe Ziel nicht.
DNS-Server und Standardgateway
Bevor Sie Ihre Administrator- und Nutzercluster erstellen, müssen Sie die IP-Adressen der folgenden Elemente kennen:
Einen DNS-Server, der von Ihrer Administrator-Workstation und Clusterknoten verwendet werden kann
Die IP-Adresse des Standardgateways für das Subnetz mit Ihrer Administrator-Workstation und Clusterknoten. Angenommen, Ihre Administrator-Workstation, Administratorclusterknoten und Nutzerclusterknoten befinden sich alle im Subnetz 172.16.20.0/24. Die Adresse des Standardgateways für das Subnetz kann 172.16.20.1 sein.
Firewall und Proxy konfigurieren
Konfigurieren Sie die Firewall und den Proxy gemäß den Proxy- und Firewallregeln.
Google Cloud-Ressourcen einrichten
Wählen Sie ein vorhandenes Google Cloud-Projekt aus oder erstellen Sie ein neues. Notieren Sie sich die ID Ihres Google Cloud-Projekts.
Erstellen Sie in Ihrem Google Cloud-Projekt ein Dienstkonto für den Zugriff auf Anthos-Cluster auf VMware-Komponenten. Dies wird als Dienstkonto für den Komponentenzugriff bezeichnet:
gcloud iam service-accounts create component-access-sa \
--display-name "Component Access Service Account" \
--project PROJECT_ID
Ersetzen Sie PROJECT_ID durch die ID Ihres Google Cloud-Projekts.
Erstellen Sie einen JSON-Schlüssel für das Dienstkonto für den Komponentenzugriff:
gcloud iam service-accounts keys create component-access-key.json \ --iam-account SERVICE_ACCOUNT_EMAIL
Ersetzen Sie SERVICE_ACCOUNT_EMAIL durch die E-Mail-Adresse des Dienstkontos für den Komponentenzugriff.
Weisen Sie Ihrem Dienstkonto für den Komponentenzugriff IAM-Rollen zu:
gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:SERVICE_ACCOUNT_EMAIL" \
--role "roles/serviceusage.serviceUsageViewer"
gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:SERVICE_ACCOUNT_EMAIL" \
--role "roles/iam.roleViewer"
gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:SERVICE_ACCOUNT_EMAIL" \
--role "roles/iam.serviceAccountViewer"
Weitere Informationen zum Dienstkonto für den Komponentenzugriff und zum Zuweisen von IAM-Rollen finden Sie unter Dienstkonten und Schlüssel.
Google APIs aktivieren
Aktivieren Sie die folgenden Google APIs in Ihrem Google Cloud-Projekt.
gcloud services enable --project PROJECT_ID \
anthos.googleapis.com \
anthosgke.googleapis.com \
anthosaudit.googleapis.com \
cloudresourcemanager.googleapis.com \
container.googleapis.com \
gkeconnect.googleapis.com \
gkehub.googleapis.com \
serviceusage.googleapis.com \
stackdriver.googleapis.com \
opsconfigmonitoring.googleapis.com \
monitoring.googleapis.com \
logging.googleapis.com \
iam.googleapis.com \
storage.googleapis.com