Version 1.9. Diese Version wird nicht mehr unterstützt. Weitere Informationen finden Sie in der Richtlinie zu unterstützten Versionen. Informationen zum Upgrade auf Version 1.10 finden Sie in der Dokumentation zu 1.10 unter Upgrade von Anthos on Bare Metal.

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

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. Wenn Sie einen Cluster in Anthos-Clustern auf Bare-Metal erstellen möchten, benötigen Sie ein Google Cloud-Projekt, in dem Ihr Konto eine der folgenden Rollen hat:

Bearbeiter
Inhaber

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 und gsutil 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, um kubectlzu installieren:
```
gcloud components install kubectl
```

Linux-Administrator-Workstation konfigurieren

Konfigurieren Sie nach der Installation von gcloud, gsutil und kubectl eine Linux-Administrator-Workstation. Verwenden Sie Cloud Shell nicht als Administrator-Workstation.

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-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.
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.9.8/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 undUbuntu), 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.9.8
  # 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_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, 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 --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:

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>