Kurzanleitung zu Anthos-Cluster on Bare Metal

Einführung in Anthos-Cluster on Bare Metal

Mit Anthos-Clustern auf Bare Metal können Sie vier Arten von Clustern definieren:

  • Admin: Ein Cluster zum Verwalten von Nutzerclustern.
  • Nutzer: 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:

  1. Google Cloud-Projekt erstellen
  2. Administratorworkstation konfigurieren

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.

Linux-Administrator-Workstation konfigurieren

In dieser Kurzanleitung werden bmctl und kubectl verwendet, um einen Cluster zu erstellen und damit zu arbeiten. Diese Befehlszeilentools werden auf einer Linux-Administrator-Workstation ausgeführt. Informationen zum Einrichten Ihrer Administratorworkstation finden Sie unter Voraussetzungen für die Administratorworkstation.

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.

Weitere Informationen zu den Anforderungen für die Clusterknoten finden Sie unter Voraussetzungen für Clusterknotenmaschinen.

Cluster erstellen

So erstellen Sie ein Cluster:

  1. Verwenden Sie bmctl, um eine Konfigurationsdatei zu erstellen.
  2. Bearbeiten Sie die Konfigurationsdatei, um sie an Ihren Cluster und Ihr Netzwerk anzupassen.
  3. 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:

  1. Öffnen Sie die Konfigurationsdatei bmctl-workspace/cluster1/cluster1.yaml in einem Editor.
  2. 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
---
# Cluster configuration. Note that some of these fields are immutable once the cluster is created.
# For more info, see https://cloud.google.com/anthos/clusters/docs/bare-metal/1.13/reference/cluster-config-ref#cluster_configuration_fields
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.13.10
  # 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

---
# 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:

  1. Prüfen Sie, ob Sie sich im Verzeichnis baremetal befinden.
  2. Führen Sie den folgenden Befehl aus, um den Cluster zu erstellen.
    3. ./bmctl create cluster -c CLUSTER_NAME
    Beispiel: 
    ./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.

  1. Prüfen Sie, ob Sie sich im Verzeichnis baremetal befinden.
  2. Verwenden Sie den folgenden Befehl mit dem Flag --force, um den Cluster neu zu erstellen:
    3. ./bmctl create cluster -c CLUSTER_NAME --force
    Beispiel: 
    ./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>