Creazione di cluster utente in una configurazione multi-cluster

Version 1.6 (unsupported)

• Ultimi
• Versione 1.16
• Versioni precedenti (non supportate)

Nei cluster Anthos su Bare Metal, i cluster utente eseguono i carichi di lavoro e, in un'architettura multi-cluster, i cluster utente vengono creati e gestiti da un cluster di amministrazione.

Dopo aver creato un cluster di amministrazione, chiamando il comando bmctl create config viene creato un file yaml che puoi modificare per definire il cluster utente. Quindi puoi utilizzare il comando kubectl per applicare la configurazione e creare il cluster utente.

Mantenere i carichi di lavoro fuori dal cluster di amministrazione protegge i dati amministrativi sensibili, come le chiavi SSH archiviate nel cluster di amministrazione, da coloro che non hanno bisogno di accedere a tali informazioni. Inoltre, mantenere i cluster utente separati l'uno dall'altro offre una buona sicurezza generale per i tuoi carichi di lavoro.

Prerequisiti

• bmctl scaricato da gs://anthos-baremetal-release/bmctl/1.6.2/linux-amd64/bmctl
• Cluster di amministrazione funzionante con accesso al server API del cluster (controlPlaneVIP)
• I nodi del cluster di amministrazione devono avere una connettività di rete per tutti i nodi nel cluster utente di destinazione.
• Chiave SSH utilizzata per creare un cluster utente disponibile come utente root o SUDO in tutti i nodi del cluster utente

Crea un file di configurazione del cluster utente

Il file di configurazione per la creazione di un cluster utente è quasi identico a quello utilizzato per la creazione di un cluster di amministrazione. L'unica differenza è che rimuovi la sezione di configurazione delle credenziali locali per rendere la configurazione una raccolta valida di risorse Kubernetes. La sezione di configurazione si trova nella parte superiore del file all'interno della sezione bmctl configuration variables.

Per impostazione predefinita, i cluster utente ereditano le credenziali dal cluster di amministrazione che li gestisce. Puoi sostituire selettivamente alcune o tutte queste credenziali. Per ulteriori dettagli, consulta il file di configurazione del cluster utente di esempio.

Nei passaggi seguenti, controlla attentamente la modifica del file di configurazione. Poiché stai creando il cluster utente con il comando kubectl, la configurazione del cluster utente prevede alcuni controlli preliminari.

1. Crea un file di configurazione del cluster utente con il comando bmctl create config:

   bmctl create config -c USER_CLUSTER_NAME
   

   Ad esempio, esegui il comando seguente per creare un file di configurazione per un cluster utente denominato user1:

   bmctl create config -c user1
   

   Il file è scritto in bmctl-workspace/user1/user1.yaml. Il percorso generico del file è bmctl-workspace/CLUSTER NAME/CLUSTER_NAME.yaml

2. Modifica il file di configurazione con le seguenti modifiche:

   • Rimuovi il percorso dei file delle credenziali locali dalla configurazione. Non sono necessari per un cluster utente e non funzionano con il comando kubectl. Rimuovi i seguenti elementi:

     ....
       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)
     ....
           

   • Modifica la configurazione per specificare un tipo di cluster user anziché admin:

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

   • Assicurati che le specifiche dei cluster di amministrazione e di utenti per i VIP e i pool di indirizzi del bilanciatore del carico siano complementari e non si sovrappongano a quelli esistenti. Di seguito è riportata una coppia di configurazione di cluster di amministrazione e di cluster utente, che specifica il bilanciamento del carico e i pool di indirizzi:

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

   Tieni presente che il resto dei file di configurazione del cluster utente è lo stesso della configurazione del cluster di amministrazione.

3. Controlla bene il file di configurazione del cluster utente. I cluster Anthos sono limitati per i controlli preflight Bare Metal quando crei un cluster utente e coprono solo i controlli a livello di macchina (come la versione del sistema operativo, le versioni software in conflitto e le risorse disponibili).

Crea il cluster utente

Esegui il comando kubectl per applicare la configurazione del cluster utente e creare il cluster:

kubectl --kubeconfig ADMIN_KUBECONFIG apply -f USER_CLUSTER_CONFIG

ADMIN_KUBECONFIG specifica il percorso del file kubeconfig del cluster di amministrazione e USER_CLUSTER_CONFIG specifica il percorso del file yaml del cluster utente modificato nella sezione precedente.

Ad esempio, per un cluster di amministrazione denominato admin e una configurazione del cluster utente denominata user1, il comando sarebbe:

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

In attesa che il cluster utente sia pronto

Per verificare che il cluster utente sia pronto, utilizza il comando kubectl wait per testare una condizione. Quanto segue attende 30 minuti per controllare che lo stato del cluster abbia terminato la riconciliazione e recuperi il file kubeconfig del cluster utente creato:

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

Dove:

• ADMIN_KUBECONFIG specifica il percorso del file kubeconfig del cluster di amministrazione.
• USER_KUBECONFIG specifica il percorso del file kubeconfig dell'utente che vuoi creare.
• USER_CLUSTER_NAME è il nome del cluster utente.

Ad esempio, per un cluster di amministrazione denominato admin e una configurazione del cluster utente denominata user1, il comando sarebbe:

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

In attesa che i pool di nodi worker siano pronti

Nella maggior parte dei casi, devi attendere che i pool di nodi worker siano pronti. In genere, i pool di nodi worker vengono utilizzati per eseguire i carichi di lavoro nei cluster utente.

Per verificare che i pool di nodi worker siano pronti, utilizza il comando kubectl wait per verificare una condizione. In questo caso, il comando attende nuovamente 30 minuti prima che i pool di nodi siano pronti:

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 specifica un pool di nodi che crei con il cluster utente.

Ad esempio, per un cluster di amministrazione denominato admin, una configurazione del cluster utente denominata user1 e un pool di nodi denominato node-pool-1, il comando sarebbe:

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

Esempio di configurazione completa del cluster utente

Di seguito è riportato un file di configurazione del cluster utente di esempio creato dal comando bmctl. Tieni presente che in questa configurazione di esempio vengono utilizzati nomi di cluster segnaposto, VIP e indirizzi. Potrebbero non funzionare per la tua rete.

# 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