Nutzercluster in einer Multi-Cluster-Einrichtung erstellen

In Anthos-Clustern auf Bare-Metal werden Ihre Arbeitslasten auf Nutzerclustern ausgeführt. In einer Multi-Cluster-Architektur werden Nutzercluster von einem Administratorcluster erstellt und verwaltet.

Wenn Sie einen Administratorcluster erstellt haben, wird durch Aufrufen des Befehls bmctl create config eine YAML-Datei erstellt, die Sie zum Definieren des Nutzerclusters bearbeiten können. Anschließend können Sie diese Konfiguration mit dem Befehl kubectl anwenden und dabei den Nutzercluster erstellen.

Durch das Fernhalten der Arbeitslasten vom Administratorcluster schützen Sie vertrauliche administrative Daten wie SSH-Schlüssel, die im Administratorcluster gespeichert sind, vor denjenigen, die keinen Zugriff auf diese Informationen benötigen. Darüber hinaus bietet die Trennung von Nutzerclustern eine gute allgemeine Sicherheit für Ihre Arbeitslasten.

Voraussetzungen

bmctl von gs://anthos-baremetal-release/bmctl/1.6.2/linux-amd64/bmctl heruntergeladen
Laufender Administratorcluster mit Zugriff auf den Cluster-API-Server (die controlPlaneVIP)
Administratorclusterknoten müssen eine Netzwerkverbindung zu allen Knoten im Zielnutzercluster haben
SSH-Schlüssel zum Erstellen des Nutzerclusters ist als Root verfügbar oder SUDO-Nutzerzugriff besteht für alle Knoten im Nutzercluster

Nutzercluster-Konfigurationsdatei erstellen

Die Konfigurationsdatei zum Erstellen eines Nutzerclusters ist fast identisch mit der, die zum Erstellen eines Administratorclusters verwendet wird. Der einzige Unterschied besteht darin, dass Sie den Abschnitt mit der Konfiguration der lokalen Anmeldedaten entfernen, damit die Konfigurationsdatei eine gültige Sammlung von Kubernetes-Ressourcen ist. Der Konfigurationsabschnitt befindet sich ganz oben in der Datei unter dem Abschnitt bmctl configuration variables.

Standardmäßig übernehmen Nutzercluster ihre Anmeldedaten vom Administratorcluster, der sie verwaltet. Sie können einige oder alle diese Anmeldedaten selektiv überschreiben. Weitere Informationen finden Sie in der Beispiel-Nutzercluster-Konfigurationsdatei.

Überprüfen Sie in den folgenden Schritten, wie Sie Ihre Konfigurationsdatei bearbeitet haben. Da Sie den Nutzercluster mit dem Befehl kubectl erstellen, werden in der Nutzerclusterkonfigurationsdatei nur eingeschränkte Preflight-Prüfungen durchgeführt.

Erstellen Sie eine Nutzercluster-Konfigurationsdatei mit dem Befehl bmctl create config:
```
bmctl create config -c USER_CLUSTER_NAME
```
Führen Sie beispielsweise den folgenden Befehl aus, um eine Konfigurationsdatei für einen Nutzercluster user1 zu erstellen:
```
bmctl create config -c user1
```
Die Datei wird in bmctl-workspace/user1/user1.yaml geschrieben. Der generische Pfad zur Datei ist bmctl-workspace/CLUSTER NAME/CLUSTER_NAME.yaml.

Bearbeiten Sie die Konfigurationsdatei mit den folgenden Änderungen:

Entfernen Sie die Dateipfade der lokalen Anmeldedaten aus der Konfiguration. Sie werden nicht für einen Nutzercluster benötigt und funktionieren nicht mit dem Befehl kubectl. Entfernen Sie die folgenden Elemente:

....
  gcrKeyPath: {path to GCR service account key}
  sshPrivateKeyPath: (path to SSH private key, used for node access)
  gkeConnectAgentServiceAccountKeyPath: (path to Connect agent service account key)
  gkeConnectRegisterServiceAccountKeyPath: (path to Hub registration service account key)
  cloudOperationsServiceAccountKeyPath: (path to Cloud Operations service account key)
....

Ändern Sie die Konfiguration, um den Clustertyp user anstelle von admin anzugeben:

....
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: user
....

Achten Sie darauf, dass die Administrator- und Nutzerclusterspezifikationen für die Load-Balancer-VIPs und Adresspools komplementär sind und sich nicht mit vorhandenen Clustern überschneiden. Im Folgenden sehen Sie ein Beispielpaar von Administrator- und Nutzerclusterkonfigurationen, in denen Load-Balancing- und Adresspools angegeben werden:

....
# Sample admin cluster config for load balancer and address pools
  loadBalancer:
    vips:
      controlPlaneVIP: 10.200.0.49
      ingressVIP: 10.200.0.50
    addressPools:
    - name: pool1
      addresses:
      - 10.200.0.50-10.200.0.70
....
....
# Sample user cluster config for load balancer and address pools
loadBalancer:
    vips:
      controlPlaneVIP: 10.200.0.71
      ingressVIP: 10.200.0.72
    addressPools:
    - name: pool1
      addresses:
      - 10.200.0.72-10.200.0.90
....

Beachten Sie, dass die weiteren Konfigurationsdateien für Nutzercluster mit denen der Administratorclusterkonfiguration identisch sind.

Prüfen Sie nochmals die Konfigurationsdatei des Nutzerclusters. Es gibt eine begrenzte Anzahl von Preflight-Prüfungen für Anthos-Cluster auf Bare Metal, wenn Sie einen Nutzercluster erstellen. Diese betreffen nur Prüfungen auf Maschinenebene (wie die Betriebssystemversion, in Konflikt stehende Softwareversionen und verfügbare Ressourcen).

Nutzercluster erstellen

Führen Sie den Befehl kubectl aus, um die Nutzerclusterkonfiguration anzuwenden und den Cluster zu erstellen:

kubectl --kubeconfig ADMIN_KUBECONFIG apply -f USER_CLUSTER_CONFIG

ADMIN_KUBECONFIG gibt den Pfad zur kubeconfig-Datei des Administratorclusters an und USER_CLUSTER_CONFIG gibt den Pfad zur YAML-Datei des Nutzerclusters an, die Sie im vorherigen Abschnitt bearbeitet haben.

Für einen Administratorcluster mit dem Namen admin und eine Nutzerclusterkonfiguration mit dem Namen user1 würde der Befehl beispielsweise so aussehen:

kubectl --kubeconfig bmctl-workspace/admin/admin-kubeconfig apply /
  -f bmctl-workspace/user1/user1.yaml

Warten, bis der Nutzercluster bereit ist

Prüfen Sie mit dem Befehl kubectl wait, ob der Nutzercluster bereit ist. Beim folgenden Befehl wird 30 Minuten gewartet, um zu prüfen, ob der Clusterstatus abgeglichen wurde, und es wird die Nutzercluster-kubeconfig-Datei abgerufen:

kubectl --kubeconfig ADMIN_KUBECONFIG wait \
  cluster USER_CLUSTER_NAME -n cluster-USER_CLUSTER_NAME \
  --for=condition=Reconciling=False --timeout=30m && \
  kubectl --kubeconfig ADMIN_KUBECONFIG get secret USER_CLUSTER_NAME-kubeconfig \
  -n cluster-USER_CLUSTER_NAME \
  -o 'jsonpath={.data.value}' | base64 -d > USER_KUBECONFIG

Dabei gilt:

ADMIN_KUBECONFIG gibt den Pfad zur Datei „kubeconfig“ des Administratorclusters an.
USER_KUBECONFIG gibt den Pfad zur kubeconfig-Datei an, die Sie erstellen möchten.
USER_CLUSTER_NAME ist der Name Ihres Nutzerclusters.

Für einen Administratorcluster mit dem Namen admin und eine Nutzerclusterkonfiguration mit dem Namen user1 wäre der Befehl beispielsweise:

kubectl --kubeconfig bmctl-workspace/admin/admin-kubeconfig wait  \
  cluster user1 -n cluster-user1 --for=condition=Reconciling=False --timeout=30m &&  \
  kubectl --kubeconfig bmctl-workspace/admin/admin-kubeconfig get secret  \
  user1-kubeconfig -n cluster-user1 -o 'jsonpath={.data.value}' | base64  \
  -d > bmctl-workspace/user1/user1-kubeconfig

Warten, bis Worker-Knotenpools bereit sind

In den meisten Fällen müssen Sie auch warten, bis die Worker-Knoten bereit sind. Normalerweise verwenden Sie Worker-Knotenpools für Ihre Nutzercluster, um Arbeitslasten auszuführen.

Prüfen Sie mit dem Befehl kubectl wait, ob die Worker-Knoten bereit sind. In diesem Fall wartet der Befehl noch 30 Minuten, bis die Knotenpools bereit sind:

kubectl --kubeconfig ADMIN_KUBECONFIG wait cluster USER_CLUSTER_NAME \
  -n cluster-USER_CLUSTER_NAME --for=condition=Reconciling=False --timeout=30m && \
  kubectl --kubeconfig ADMIN_KUBECONFIG wait nodepool NODE_POOL_NAME \
  -n cluster-USER_CLUSTER_NAME --for=condition=Reconciling=False --timeout=30m && \
  kubectl --kubeconfig ADMIN_KUBECONFIG get secret \
  USER_CLUSTER_NAME-kubeconfig -n cluster-USER_CLUSTER_NAME -o \
  'jsonpath={.data.value}' | base64 -d >  USER_KUBECONFIG

NODE_POOL_NAME gibt einen Knotenpool an, den Sie mit dem Nutzercluster erstellen.

Für einen Administratorcluster mit dem Namen admin, eine Nutzerclusterkonfiguration mit dem Namen user1 und einen Knotenpool namens node-pool-1 würde der Befehl so lauten:

kubectl --kubeconfig bmctl-workspace/admin/admin-kubeconfig wait \
  cluster user1 -n cluster-user1 --for=condition=Reconciling=False --timeout=30m && \
  kubectl --kubeconfig bmctl-workspace/admin/admin-kubeconfig wait \
  nodepool node-pool-1 -n cluster-user1 --for=condition=Reconciling=False --timeout=30m && \
  kubectl --kubeconfig bmctl-workspace/admin/admin-kubeconfig get secret \
  user1-kubeconfig -n cluster-user1 -o \
  'jsonpath={.data.value}' | base64 -d > bmctl-workspace/user1/user1-kubeconfig

Beispiel für die vollständige Konfiguration eines Nutzerclusters

Das folgende Beispiel zeigt eine Konfigurationsdatei für einen Nutzercluster, die mit dem Befehl bmctl erstellt wurde. Beachten Sie, dass in dieser Beispielkonfiguration Platzhalter für Clusternamen, VIPs und Adressen verwendet werden. Sie funktionieren in Ihrem Netzwerk möglicherweise nicht.

# Sample user cluster config:

apiVersion: v1
kind: Namespace
metadata:
name: cluster-user1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: user1
namespace: cluster-user1
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: user
# Anthos cluster version.
anthosBareMetalVersion: 1.6.2
# GKE connect configuration
gkeConnect:
projectID: GOOGLE_PROJECT_ID
# To override default credentials inherited from the admin cluster:
# 1. Create a new secret in the admin cluster
# 2. Uncomment the section below and refer to the secret created above
# # Optionally override default secret inherited from the admin cluster.
# connectServiceAccountSecret:
# name: GKE_CONNECT_AGENT_SA_SECRET
# namespace: cluster-user1
# # Optionally override default secret inherited from the admin cluster.
# registerServiceAccountSecret:
# name: GKE_CONNECT_REGISTER_SA_SECRET
# namespace: cluster-user1
# 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: 10.200.0.4
# 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:
- 10.96.0.0/12
# Credentials specify the secrets that hold SSH key and image pull credential for the new cluster.
# credentials:
# # Optionally override default ssh key secret inherited from the admin cluster.
# sshKeySecret:
# name: SSH_KEY_SECRET
# namespace: cluster-user1
# # Optionally override default image pull secret inherited from the admin cluster.
# imagePullSecret:
# name: IMAGE_PULL_SECRET
# namespace: cluster-user1
# 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: 10.200.0.71
# 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: 10.200.0.72
# 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).
- 10.200.0.72-10.200.0.90
# 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:
# 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: $GOOGLE_PROJECT_ID
# Cloud location for logs and metrics.
location: us-central1
# Optionally override default secret inherited from the admin cluster.
# serviceAccountSecret:
# name: $CLOUD_OPERATIONS_SA_SECRET
# namespace: cluster-user1
# 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
# Authentication; uncomment this section if you wish to enable authentication to the cluster with OpenID Connect.
# authentication:
# oidc:
# # issuerURL specifies the URL of your OpenID provider, such as "https://accounts.google.com". The Kubernetes API
# # server uses this URL to discover public keys for verifying tokens. Must use HTTPS.
# issuerURL:
# # clientID specifies the ID for the client application that makes authentication requests to the OpenID
# # provider.
# clientID:
# # clientSecret specifies the secret for the client application.
# clientSecret:
# # kubectlRedirectURL specifies the redirect URL (required) for the gcloud CLI, such as
# # "http://localhost:[PORT]/callback".
# kubectlRedirectURL: <Redirect URL for the gcloud CLI; optional, default is "http://kubectl.redirect.invalid">
# # username specifies the JWT claim to use as the username. The default is "sub", which is expected to be a
# # unique identifier of the end user.
# username: <JWT claim to use as the username; optional, default is "sub">
# # usernamePrefix specifies the prefix prepended to username claims to prevent clashes with existing names.
# usernamePrefix:

# # group specifies the JWT claim that the provider will use to return your security groups.
# group:
# # groupPrefix specifies the prefix prepended to group claims to prevent clashes with existing names.
# groupPrefix:

# # scopes specifies additional scopes to send to the OpenID provider as a comma-delimited list.
# scopes:
# # extraParams specifies additional key-value parameters to send to the OpenID provider as a comma-delimited
# # list.
# extraParams:
# # certificateAuthorityData specifies a Base64 PEM-encoded certificate authority certificate of your identity
# # provider. It's not needed if your identity provider's certificate was issued by a well-known public CA.
# certificateAuthorityData:
# Node access configuration; uncomment this section if you wish to use a non-root user
# with passwordless sudo capability for machine login.
# nodeAccess:
# loginUser:
---
# Node pools for worker nodes
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
name: node-pool-1
namespace: cluster-user1
spec:
clusterName: user1
nodes:
- address: 10.200.0.5