Einführung in Anthos-Cluster on Bare Metal
Umfang der Kurzanleitung zu Anthos-Cluster on Bare Metal
Mit Anthos-Cluster auf Bare Metal können Sie vier Clustertypen definieren:
- Admin: Ein Cluster zum Verwalten von Nutzerclustern.
- user – Ein Cluster zum Ausführen von Arbeitslasten.
- standalone – Ein einzelner Cluster, der sich selbst verwalten und zwar Arbeitslasten ausführen, jedoch keine anderen Nutzercluster erstellen oder verwalten kann.
- hybrid – Ein einzelner Cluster für Verwaltung und Arbeitslasten, der auch Nutzercluster verwalten kann.
In dieser Kurzanleitung stellen Sie einen Hybrid-Cluster mit zwei Knoten mit Anthos-Cluster on Bare Metal bereit. Sie erfahren, wie Sie einen Cluster erstellen und den Clustererstellungsprozess überwachen.
In dieser Kurzanleitung werden Grundkenntnisse in Kubernetes vorausgesetzt.
Anthos-Cluster on Bare Metal vorbereiten
Der Installationsbefehl von Anthos-Cluster on Bare Metal namens bmctl
wurde entwickelt, um die Erstellung von Clustern zu optimieren. Der Befehl kann automatisch die erforderlichen Google-Dienstkonten und APIs einrichten, die Sie für Anthos-Cluster on Bare Metal benötigen, und wir verwenden diese automatisierten Dienste in dieser Kurzanleitung.
Sie können die erforderlichen Dienste und APIs auch manuell einrichten, bevor Sie Cluster mit bmctl
erstellen. Wir werden später in diesem Dokument noch auf die Befehlsänderungen hinweisen, die Sie vornehmen müssen. Informationen zum manuellen Einrichten der Google-Dienste finden Sie aber unter Google-Dienste und -Dienstkonten aktivieren.
Bevor Sie einen Cluster mit Anthos-Clustern auf Bare Metal erstellen können, müssen Sie Folgendes tun:
- Erstellen Sie ein Google Cloud-Projekt mit der Rolle Bearbeiter oder Inhaber.
- Laden Sie das
bmctl
-Befehlszeilentool wie unten beschrieben herunter und installieren Sie es. - Linux-Administrator-Workstation zum Ausführen von
bmctl
konfigurieren. Hinweis: Verwenden Sie Cloud Shell nicht als Administrator-Workstation.- Installieren Sie
gcloud
,gsutil
undkubectl
wie unten beschrieben. - Installieren Sie Docker-Version 19.03 oder höher. Anweisungen zum Konfigurieren von Docker finden Sie auf der Seite zum Konfigurieren Ihres Linux-Betriebssystems: CentOS konfigurieren, RHEL konfigurieren oder Ubuntu konfigurieren.
- Verwenden Sie den
root
-Zugriff, um SSH sowohl auf der Administrator-Workstation als auch auf den Rechnern des Remote-Clusterknotenknotens einzurichten. Zuerst muss auf den Remote-Clusterknotenmaschinen die SSH-Passwortauthentifizierungroot
aktiviert sein, damit Schlüssel von der Administrator-Workstation geteilt werden können. Wenn die Schlüssel eingerichtet sind, können Sie die SSH-Passwortauthentifizierung deaktivieren. - Generieren Sie auf der Administrator-Workstation ein privates/öffentliches Schlüsselpaar (keine Passphrase für die Schlüssel festlegen). Die Schlüssel sind erforderlich, um SSH für sichere, passwortlose Verbindungen zwischen der Verwaltungs-Workstation und den Rechnern des Clusterknotens zu verwenden.
ssh-keygen -t rsa
Sie können auch den Nutzerzugriff
SUDO
auf die Clusterknotenmaschinen verwenden, um SSH einzurichten. Für passwortlose Nutzerverbindungen ohne Rootberechtigung müssen Sie jedoch die YAML-Dateicluster config
mit den entsprechenden Anmeldeinformationen aktualisieren. Weitere Informationen finden Sie in der Beispielkonfigurationsdatei für Cluster im Abschnitt#Node access configuration
. - Fügen Sie den Rechnern des Clusterknotens den generierten öffentlichen Schlüssel hinzu. Standardmäßig werden die öffentlichen Schlüssel in der Identitätsdatei
id_rsa.pub
gespeichert.ssh-copy-id -i ~/.ssh/identity_file root@cluster_node_ip
- Deaktivieren Sie die SSH-Passwortauthentifizierung auf den Clusterknoten und verwenden Sie den folgenden Befehl auf der Administrator-Workstation, um zu prüfen, ob die Authentifizierung mit öffentlichem Schlüssel zwischen der Administrator-Workstation und den Clusterknoten ausgeführt wird.
ssh -o IdentitiesOnly=yes -i identity_file root@cluster_node_ip
- Installieren Sie
gcloud-Dienstprogramme installieren
Die Tools gcloud
, gsutil
und kubectl
sind in der gcloud CLI enthalten.
- Installieren und initialisieren Sie die gcloud CLI auf Ihrem Administratorcomputer. Folgen Sie dazu dieser Anleitung. Dabei werden
gcloud
undgsutil
installiert. - gcloud CLI aktualisieren
gcloud components update
Melden Sie sich in Ihrem Google-Konto an, damit Sie Dienste und Dienstkonten verwalten können:
gcloud auth login --update-adc
Ein neuer Browsertab wird geöffnet und Sie werden aufgefordert, ein Konto auszuwählen.
Beachten Sie, dass Sie zu diesem Zeitpunkt ein Google Cloud-Standardprojekt einrichten und andere Dienste und Google-APIs aktivieren können, bevor Sie Cluster mit Anthos-Cluster on Bare Metal erstellen. Wenn Sie ein Standardprojekt festlegen, sparen Sie Zeit, wenn Sie Dienste manuell aktivieren.
Wie in dieser Kurzanleitung gezeigt, können Sie jedoch auch ein Projekt angeben und die erforderlichen Google-Dienste direkt mit dem Befehl
bmctl
einrichten, wenn Sie Ihre Cluster erstellen. Dabei verwendetbmctl
immer die Projekt-ID, die Sie beim Ausführen des Befehls angeben.Verwenden Sie
gcloud
, umkubectl
zu installieren:gcloud components install kubectl
bmctl installieren
Das Befehlszeilentool zum Erstellen von Clustern mit Anthos-Cluster on Bare Metal ist bmctl
.
Sie laden bmctl
aus einem Cloud Storage-Bucket herunter.
So laden Sie bmctl
herunter:
- Erstellen Sie ein neues Verzeichnis für
bmctl
:cd ~
mkdir baremetal
cd baremetal
- Laden Sie
bmctl
aus dem Cloud Storage-Bucket herunter:gsutil cp gs://anthos-baremetal-release/bmctl/1.6.2/linux-amd64/bmctl bmctl
chmod a+x bmctl
- Prüfen Sie anhand der Hilfeinformationen, ob
bmctl
korrekt installiert ist:./bmctl -h
Clusterknoten erstellen
Erstellen Sie zwei Maschinen, die als Knoten für den Cluster dienen:
- Eine Maschine fungiert als Knoten der Steuerungsebene.
- Eine Maschine fungiert als Worker-Knoten.
Beachten Sie, dass Ihre Administrator-Workstation per ssh
auf diese Knoten zugreifen können muss und Zugriff auf die VIP der Steuerungsebene haben muss.
Weitere Informationen zu den Voraussetzungen für die Clusterknoten finden Sie unter Hardware und Betriebssystemanforderungen (Centos, RHEL und Ubuntu).
Cluster erstellen
So erstellen Sie ein Cluster:
- Verwenden Sie
bmctl
, um eine Konfigurationsdatei zu erstellen. - Bearbeiten Sie die Konfigurationsdatei, um sie an Ihren Cluster und Ihr Netzwerk anzupassen.
- Erstellen Sie mit
bmctl
den Cluster aus der Konfigurationsdatei.
Konfigurationsdatei erstellen
Zum Erstellen einer Konfigurationsdatei und zum automatischen Aktivieren von Dienstkonten und APIs müssen Sie sich im Verzeichnis baremetal
befinden. Führen Sie dazu den Befehl bmctl
mit den folgenden Flags aus:
./bmctl create config -c CLUSTER_NAME \ --enable-apis --create-service-accounts --project-id=PROJECT_ID
CLUSTER_NAME ist der Name des Clusters und PROJECT_ID ist ein Google-Projekt, in dem Sie die Rolle Inhaber oder Bearbeiter haben.
Dieser Befehl erstellt eine Konfigurationsdatei im Verzeichnis baremetal
unter bmctl-workspace/cluster1/cluster1.yaml
.
Konfigurationsdatei bearbeiten
So bearbeiten Sie die Konfigurationsdatei:
- Öffnen Sie die Konfigurationsdatei
bmctl-workspace/cluster1/cluster1.yaml
in einem Editor. - Bearbeiten Sie die Datei für Ihre spezifischen Knoten- und Netzwerkanforderungen. Siehe die Beispielkonfigurationsdatei unten. Beachten Sie, dass wir in diesem Schnellstart OpenID Connect (OIDC) weggelassen haben.
# gcrKeyPath: < to GCR service account key> gcrKeyPath: baremetal/gcr.json # sshPrivateKeyPath: < to SSH private key, used for node access> sshPrivateKeyPath: .ssh/id_rsa # gkeConnectAgentServiceAccountKeyPath: < to Connect agent service account key> gkeConnectAgentServiceAccountKeyPath: baremetal/connect-agent.json # gkeConnectRegisterServiceAccountKeyPath: < to Hub registration service account key> gkeConnectRegisterServiceAccountKeyPath: baremetal/connect-register.json # cloudOperationsServiceAccountKeyPath: < to Cloud Operations service account key> cloudOperationsServiceAccountKeyPath: baremetal/cloud-ops.json --- apiVersion: v1 kind: Namespace metadata: name: cluster-cluster1 --- apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: cluster1 namespace: cluster-cluster1 spec: # Cluster type. This can be: # 1) admin: to create an admin cluster. This can later be used to create user clusters. # 2) user: to create a user cluster. Requires an existing admin cluster. # 3) hybrid: to create a hybrid cluster that runs admin cluster components and user workloads. # 4) standalone: to create a cluster that manages itself, runs user workloads, but does not manage other clusters. type: hybrid # Anthos cluster version. anthosBareMetalVersion: 1.6.2 # GKE connect configuration gkeConnect: projectID: PROJECT_ID # Control plane configuration controlPlane: nodePoolSpec: nodes: # Control plane node pools. Typically, this is either a single machine # or 3 machines if using a high availability deployment. - address: CONTROL_PLANE_NODE_IP # Cluster networking configuration clusterNetwork: # Pods specify the IP ranges from which Pod networks are allocated. pods: cidrBlocks: - 192.168.0.0/16 # Services specify the network ranges from which service VIPs are allocated. # This can be any RFC 1918 range that does not conflict with any other IP range # in the cluster and node pool resources. services: cidrBlocks: - 172.26.232.0/24 # Load balancer configuration loadBalancer: # Load balancer mode can be either 'bundled' or 'manual'. # In 'bundled' mode a load balancer will be installed on load balancer nodes during cluster creation. # In 'manual' mode the cluster relies on a manually-configured external load balancer. mode: bundled # Load balancer port configuration ports: # Specifies the port the LB serves the kubernetes control plane on. # In 'manual' mode the external load balancer must be listening on this port. controlPlaneLBPort: 443 # There are two load balancer VIPs: one for the control plane and one for the L7 Ingress # service. The VIPs must be in the same subnet as the load balancer nodes. vips: # ControlPlaneVIP specifies the VIP to connect to the Kubernetes API server. # This address must not be in the address pools below. controlPlaneVIP: CONTROL_PLANE_VIP # IngressVIP specifies the VIP shared by all services for ingress traffic. # Allowed only in non-admin clusters. # This address must be in the address pools below. ingressVIP: INGRESS_VIP # AddressPools is a list of non-overlapping IP ranges for the data plane load balancer. # All addresses must be in the same subnet as the load balancer nodes. # Address pool configuration is only valid for 'bundled' LB mode in non-admin clusters. # addressPools: # - name: pool1 # addresses: # # Each address must be either in the CIDR form (1.2.3.0/24) # # or range form (1.2.3.1-1.2.3.5). # - LOAD_BALANCER_ADDRESS_POOL- # A load balancer nodepool can be configured to specify nodes used for load balancing. # These nodes are part of the kubernetes cluster and run regular workloads as well as load balancers. # If the node pool config is absent then the control plane nodes are used. # Node pool configuration is only valid for 'bundled' LB mode. # nodePoolSpec: # nodes: # - address: LOAD_BALANCER_NODE_IP; # Proxy configuration # proxy: # url: http://[username:password@]domain # # A list of IPs, hostnames or domains that should not be proxied. # noProxy: # - 127.0.0.1 # - localhost # Logging and Monitoring clusterOperations: # Cloud project for logs and metrics. projectID: PROJECT_ID # Cloud location for logs and metrics. location: us-central1 # Whether collection of application logs/metrics should be enabled (in addition to # collection of system logs/metrics which correspond to system components such as # Kubernetes control plane or cluster management agents). # enableApplication: false # Storage configuration storage: # lvpNodeMounts specifies the config for local PersistentVolumes backed by mounted disks. # These disks need to be formatted and mounted by the user, which can be done before or after # cluster creation. lvpNodeMounts: # path specifies the host machine path where mounted disks will be discovered and a local PV # will be created for each mount. path: /mnt/localpv-disk # storageClassName specifies the StorageClass that PVs will be created with. The StorageClass # is created during cluster creation. storageClassName: local-disks # lvpShare specifies the config for local PersistentVolumes backed by subdirectories in a shared filesystem. # These subdirectories are automatically created during cluster creation. lvpShare: # path specifies the host machine path where subdirectories will be created on each host. A local PV # will be created for each subdirectory. path: /mnt/localpv-share # storageClassName specifies the StorageClass that PVs will be created with. The StorageClass # is created during cluster creation. storageClassName: local-shared # numPVUnderSharedPath specifies the number of subdirectories to create under path. numPVUnderSharedPath: 5 --- # Node pools for worker nodes apiVersion: baremetal.cluster.gke.io/v1 kind: NodePool metadata: name: node-pool-1 namespace: cluster-cluster1 spec: clusterName: cluster1 nodes: - address: WORKER_NODE_IP
Preflight-Prüfungen ausführen und Cluster erstellen
Mit dem Befehl bmctl
werden Preflight-Prüfungen in Ihrer Cluster-Konfigurationsdatei durchgeführt, bevor der Cluster erstellt wird. Wenn sie erfolgreich sind, wird der Cluster erstellt.
So führen Sie Preflight-Prüfungen durch und erstellen den Cluster:
- Prüfen Sie, ob Sie sich im Verzeichnis
baremetal
befinden. - Führen Sie den folgenden Befehl aus, um den Cluster zu erstellen.
./bmctl create cluster -c CLUSTER_NAME
./bmctl create cluster -c cluster1
Der Befehl bmctl
überwacht die Preflight-Prüfungen und die Clustererstellung. Anschließend wird die Ausgabe auf dem Bildschirm angezeigt und es werden detaillierte Informationen in die bmctl
-Logs geschrieben.
Die bmctl
-Logs sowie die Preflight-Prüfung und Knoteninstallationslogs befinden sich im folgenden Verzeichnis: baremetal/bmctl-workspace/CLUSTER_NAME/log
Der bmctl
prüft mit einer Preflight-Prüfung die vorgeschlagene Clusterinstallation auf die folgenden Bedingungen:
- Die Linux-Distribution und die Linux-Version werden unterstützt.
- SELinux ist nicht im Modus „Erzwingen“.
- Bei Ubuntu sind AppArmor und UFW nicht aktiv.
- Bei CentOS/RHEL ist „firewalld“ nicht aktiv.
- Google Container Registry ist erreichbar.
- Die VIPs sind verfügbar.
- Die Clustermaschinen haben eine Verbindung zueinander.
- Load-Balancer-Maschinen befinden sich im selben L2-Subnetz.
Es kann einige Minuten dauern, bis die Clustererstellung abgeschlossen ist.
Informationen über Ihren Cluster abrufen
Nachdem der Cluster erstellt wurde, können Sie mit dem Befehl kubectl
Informationen zum neuen Cluster abrufen. Während der Clustererstellung schreibt der Befehl bmctl
eine kubeconfig-Datei für den Cluster, den Sie mit kubectl
abfragen. Die Datei „kubeconfig“ wird in bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig
geschrieben.
Beispiel:
kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig get nodes
Dieser Befehl gibt Folgendes zurück:
NAME STATUS ROLES AGE VERSION node-01 Ready master 16h v1.17.8-gke.16 node-02 Ready <none> 16h v1.17.8-gke.16
Wenn bei der Clustererstellung Preflight-Prüfungen nicht erfolgreich ausgeführt werden, prüfen Sie die Preflight-Prüfungslogs auf Fehler und korrigieren Sie diese in der Cluster-Konfigurationsdatei. Die Preflight-Prüfungslogs befinden sich im Verzeichnis /log
unter
~/baremetal/bmctl-workspace/CLUSTER_NAME/log
Die Preflight-Prüfungslogs für jede Maschine im Cluster befinden sich im Verzeichnis CLUSTER_NAME und sind nach IP-Adresse organisiert. Beispiel:
bmctl-workspace/cluster1/log └── preflight-20201007-034844 ├── 172.17.0.3 ├── 172.17.0.4 ├── 172.17.0.5 ├── 172.17.0.6 ├── 172.17.0.7 └── node-network
Fehler der Preflight-Prüfung ignorieren
Wenn die Clustererstellung nach der Preflight-Überprüfung fehlschlägt, können Sie den Cluster mit dem Flag --force
im Befehl bmctl
neu installieren.
Das Flag --force
installiert über einen vorhandenen Cluster, ignoriert jedoch die Ergebnisse fehlgeschlagener Preflight-Prüfungen aufgrund bereits zugewiesener Serverports.
- Prüfen Sie, ob Sie sich im Verzeichnis
baremetal
befinden. - Verwenden Sie den folgenden Befehl mit dem Flag
--force
, um den Cluster neu zu erstellen:
./bmctl create cluster -c CLUSTER_NAME --force
./bmctl create cluster -c cluster1 --force
Deployment und Dienst erstellen
Dies ist ein Manifest für ein Deployment:
apiVersion: apps/v1 kind: Deployment metadata: name: my-deployment spec: selector: matchLabels: app: metrics department: sales replicas: 3 template: metadata: labels: app: metrics department: sales spec: containers: - name: hello image: "gcr.io/google-samples/hello-app:2.0"
Speichern Sie das Manifest als my-deployment.yaml
und erstellen Sie das Deployment:
kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig create -f my-deployment.yaml
Sehen Sie sich das Deployment an:
kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig get deployments
Die Ausgabe zeigt, dass im Deployment drei Pods ausgeführt werden:
NAME READY UP-TO-DATE AVAILABLE AGE my-deployment 3/3 3 3 16s
Hier ist ein Manifest für einen Dienst vom Typ LoadBalancer:
apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: metrics department: sales type: LoadBalancer ports: - port: 80 targetPort: 8080
Speichern Sie das Manifest als my-service.yaml
und erstellen Sie den Dienst:
kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig create -f my-service.yaml
Lassen Sie den Service anzeigen:
kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig get service my-service
Ausgabe:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S my-service LoadBalancer 172.26.232.2 172.16.1.21 80:30060/TCP
Beachten Sie, dass Anthos-Cluster on Bare-Metal dem Dienst eine externe IP-Adresse zugewiesen hat. Verwenden Sie die externe IP-Adresse, um den Dienst aufzurufen:
curl 172.16.1.21
Die Ausgabe ist eine „Hello World“-Nachricht:
Hello, world! Version: 2.0.0 Hostname: my-deployment-75d45b64f9-6clxj
Hochverfügbare Steuerungsebene erstellen
In dieser Kurzanleitung wird ein einfacher Hybrid-Cluster mit zwei Knoten erstellt. Wenn Sie eine Hochverfügbarkeitssteuerungsebene erstellen möchten, erstellen Sie einen Cluster mit drei Steuerungsebenenknoten.
Bearbeiten Sie beispielsweise die oben gezeigte Konfigurationsdatei, um der Steuerungsebene zusätzliche Knoten hinzuzufügen:
controlPlane: nodePoolSpec: clusterName: cluster1 nodes: # Control Plane node pools. Typically, this is either a single machine # or 3 machines if using a high availability deployment. - address: <Machine 1 IP> - address: <Machine 2 IP> - address: <Machine 3 IP>
Load-Balancer in einem eigenen Knotenpool ausführen
In dieser Kurzanleitung wird ein einfacher Hybrid-Cluster mit zwei Knoten erstellt. Der Load-Balancer wird auf demselben Knoten ausgeführt, auf dem die Steuerungsebene ausgeführt wird.
Wenn der Load-Balancer in einem eigenen Knotenpool ausgeführt werden soll, bearbeiten Sie die nodePoolSpec
-Werte des Abschnitts loadBalancer
Ihrer Konfigurationsdatei:
loadBalancer: nodePoolSpec: clusterName: "cluster1" nodes: - address: <LB Machine 1 IP> - address: <LB Machine 2 IP>