Version 1.6. Diese Version wird nicht mehr unterstützt. Weitere Informationen finden Sie in der Richtlinie zu unterstützten Versionen. Informationen zum Upgrade auf Version 1.7 finden Sie unter Upgrade von Anthos auf BareMetal ausführen in der Dokumentation zu 1.7.

Verfügbare unterstützte Versionen: 1.14 | 1.13 | 1.12

Kurzanleitung zu Anthos-Cluster on Bare Metal

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.
1. Installieren Sie gcloud, gsutil und kubectl wie unten beschrieben.
2. 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.
3. 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-Passwortauthentifizierung root 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.
4. 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-Datei cluster config mit den entsprechenden Anmeldeinformationen aktualisieren. Weitere Informationen finden Sie in der Beispielkonfigurationsdatei für Cluster im Abschnitt #Node access configuration.
5. 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
```
6. 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
```

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 und gsutil 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 verwendet bmctl immer die Projekt-ID, die Sie beim Ausführen des Befehls angeben.
Verwenden Sie gcloud, um kubectlzu 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>