Einführung in 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 wird davon ausgegangen, dass Sie Grundkenntnisse in Kubernetes haben.
Vorbereitung auf Anthos-Cluster on Bare Metal
Bevor Sie einen Cluster in Anthos-Clustern auf Bare-Metal erstellen, müssen Sie Folgendes tun:
- Google Cloud-Projekt erstellen
- Installieren Sie Google Cloud CLI.
- Linux-Administrator-Workstation konfigurieren
- Sie haben das
bmctl
-Tool installiert.
Google Cloud-Projekt erstellen
Erstellen Sie für diese Kurzanleitung ein neues Google Cloud-Projekt, das alle Ihre Google Cloud-Ressourcen organisiert. Zum Erstellen eines Clusters in Anthos-Cluster auf Bare-Metal benötigen Sie ein Google Cloud-Projekt, in dem Ihr Konto die Rolle "Inhaber" hat.
Weitere Informationen finden Sie unter Projekte erstellen und verwalten.
Google Cloud CLI installieren
In dieser Kurzanleitung werden die Tools kubectl
und bmctl
zum Erstellen und Einrichten von Clustern verwendet. Zum Installieren dieser Tools benötigen Sie gcloud
und gsutil
.
Google Cloud CLI enthält die gcloud
-, gsutil
- und kubectl
-Befehlszeilentools.
Gehen Sie so vor, um die erforderlichen Tools zu installieren:
- Installieren und initialisieren Sie Google Cloud CLI auf Ihrer Administrator-Workstation mit dieser Anleitung. Dabei werden
gcloud
undgsutil
installiert. - Aktualisieren Sie Google Cloud CLI:
gcloud components update
Melden Sie sich mit Ihrem Google-Konto an, um Ihre Dienste und Dienstkonten zu verwalten:
gcloud auth login --update-adc
Ein neuer Browsertab wird geöffnet und Sie werden aufgefordert, ein Konto auszuwählen.
Verwenden Sie
gcloud
, umkubectl
zu installieren:gcloud components install kubectl
Linux-Administrator-Workstation konfigurieren
Konfigurieren Sie nach der Installation von gcloud
, gsutil
und kubectl
eine Linux-Administrator-Workstation.
Verwenden SieCloud Shell nicht als Administrator-Workstation.
- Installieren Sie
gcloud
,gsutil
undkubectl
wie im vorherigen Abschnitt beschrieben. - Installieren Sie Docker-Version 19.03 oder höher. Informationen zum Konfigurieren von Docker finden Sie auf der Seite zur Linux-Distribution:
- Wenn Sie den Zugriff
root
verwenden möchten, richten Sie SSH sowohl auf der Administrator-Workstation als auch auf den Rechnern des Remote-Clusterknotens ein. 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. Legen Sie keine Passphrase für die Schlüssel fest. Sie benötigen die Schlüssel, um SSH für sichere, passwortlose Verbindungen zwischen der Administrator-Workstation und den Rechnern des Clusterknotens zu nutzen. Generieren Sie die Schlüssel mit dem folgenden Befehl:
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 Clusterkonfigurationsdatei 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
bmctl-Tool herunterladen und installieren
Sie verwenden das bmctl
-Befehlszeilentool, um Cluster in Anthos-Clustern on Bare Metal zu erstellen.
Mit dem Befehl bmctl
werden die Google-Dienstkonten automatisch eingerichtet und die APIs aktiviert, die Sie benötigen, um Anthos-Cluster auf Bare-Metal in Ihrem angegebenen Projekt zu verwenden.
Wenn Sie eigene Dienstkonten erstellen oder stattdessen andere manuelle Projekte einrichten möchten, lesen Sie die Informationen unter Google-Dienste und -Dienstkonten aktivieren, bevor Sie Cluster mit bmctl
erstellen.
So laden Sie das bmctl
-Tool herunter und installieren es:
- 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.12.9/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 Ihren Cluster dienen:
- Eine Maschine fungiert als Knoten der Steuerungsebene.
- Eine Maschine fungiert als Worker-Knoten.
Gehen Sie zu Hardware und Betriebssystemanforderungen (Centos, RHEL und Ubuntu), um mehr über die Anforderungen für die Clusterknoten zu erfahren.
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. PROJECT_ID ist das Projekt, das Sie unter Google Cloud-Projekt erstellen erstellt haben.
Der obige Befehl erstellt eine Konfigurationsdatei im Verzeichnis baremetal
unter dem folgenden Pfad: 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. Verwenden Sie die Beispielkonfigurationsdatei unten als Referenz. In dieser Kurzanleitung werden keine Informationen zu OpenID Connect (OIDC) verwendet oder einbezogen.
# 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.12.9
# 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 virtual IPs 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 load balancer 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 virtual IP (VIP) addresses: 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.
# These IP addresses do not correspond to physical network interfaces.
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
# NodeConfig specifies the configuration that applies to all nodes in the cluster.
nodeConfig:
# podDensity specifies the pod density configuration.
podDensity:
# maxPodsPerNode specifies the maximum number of pods allowed on a single node.
maxPodsPerNode: 250
# containerRuntime specifies which container runtime to use for scheduling containers on nodes.
# containerd and docker are supported.
containerRuntime: containerd
---
# 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_1_IP
- address: WORKER_NODE_2_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 die Prüfungen erfolgreich sind, erstellt bmctl
den Cluster.
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_NAMEBeispiel:
./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
, Preflight-Prüfungen und Knoteninstallationslogs finden Sie 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“.
- Unter Ubuntu ist Unkomplizierte Firewall (UFW) 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 Layer-2-Subnetz.
Die Erstellung eines Clusters kann einige Minuten dauern.
Informationen zu Ihrem Cluster abrufen
Nachdem Sie erfolgreich einen Cluster erstellt haben, verwenden Sie den kubectl
-Befehl, um Informationen über den neuen Cluster anzuzeigen. Während der Clustererstellung schreibt der Befehl bmctl
eine kubeconfig-Datei für den Cluster, den Sie mit kubectl
abfragen können. 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-Prüfung fehlschlägt, können Sie versuchen, den Cluster mithilfe des Flags --force
im Befehl bmctl
neu zu 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 --forceBeispiel:
./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
:
Erstellen Sie das Deployment mit dem folgenden Befehl:
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 das Deployment drei verfügbare und einsatzbereite Pods hat:
NAME READY UP-TO-DATE AVAILABLE AGE my-deployment 3/3 3 3 16s
Das folgende Manifest definiert 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
:
Erstellen Sie den Dienst mit dem folgenden Befehl:
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
Anthos-Cluster on Bare Metal geben dem Dienst eine externe IP-Adresse. 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 der Kurzanleitung wurde 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 zum Beispiel die Konfigurationsdatei, um der Steuerungsebene zwei 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 der Kurzanleitung wurde 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>