Guide de démarrage rapide pour les clusters Anthos sur Bare Metal

Présentation des clusters Anthos sur Bare Metal

Avec les clusters Anthos sur bare metal, vous pouvez définir quatre types de clusters:

  • admin : cluster utilisé pour gérer les clusters d'utilisateur.
  • user : cluster utilisé pour exécuter des charges de travail.
  • autonome : cluster unique qui peut s'administrer de manière autonome et peut également exécuter des charges de travail, mais qui ne peut ni créer, ni gérer d'autres clusters d'utilisateurs.
  • hybride : cluster unique pour les administrateurs et les charges de travail, qui peut également gérer des clusters d'utilisateurs.

Dans ce guide de démarrage rapide, vous allez déployer un cluster hybride à deux nœuds avec les clusters Anthos sur Bare Metal. Vous apprendrez comment créer un cluster et comment surveiller le processus de création du cluster.

Dans ce guide de démarrage rapide, nous partons du principe que vous possédez des connaissances de base sur Kubernetes.

Se préparer à l'utilisation de clusters sur Bare Metal

Avant de créer un cluster Anthos sur une solution Bare Metal, vous devez effectuer les opérations suivantes :

  1. Créez un projet Google Cloud.
  2. Configurez votre poste de travail administrateur.

Créer un projet Google Cloud

Pour ce guide de démarrage rapide, créez un projet Google Cloud qui organise toutes vos ressources Google Cloud. Pour créer un cluster Anthos sur bare metal, vous devez disposer d'un projet Google Cloud dans lequel votre compte est doté du rôle "Propriétaire".

Pour en savoir plus, consultez la page Créer et gérer des projets.

Configurer une station de travail d'administrateur Linux

Ce guide de démarrage rapide utilise bmctl et kubectl pour créer et utiliser un cluster. Ces outils de ligne de commande sont exécutés sur un poste de travail administrateur Linux. Pour en savoir plus sur la configuration du poste de travail administrateur, consultez la section Prérequis pour le poste de travail administrateur.

Créer les nœuds de votre cluster

Créez deux machines qui serviront de nœuds pour votre cluster :

  • Une machine fonctionne en tant que nœud du plan de contrôle.
  • Une machine fonctionne en tant que nœud de calcul.

Reportez-vous à la section Prérequis pour les machines du nœuds de cluster pour en savoir plus sur les exigences concernant les nœuds de cluster.

Créer un cluster

Pour créer un cluster, procédez comme suit :

  1. Utilisez bmctl pour créer un fichier de configuration.
  2. Modifiez le fichier de configuration de façon à le personnaliser pour votre cluster et votre réseau.
  3. Utilisez bmctl pour créer le cluster à partir du fichier de configuration.

Créer un fichier de configuration

Pour créer un fichier de configuration et activer automatiquement les comptes de service et les API, assurez-vous que vous vous trouvez dans le répertoire baremetal, puis exécutez la commande bmctl avec les options suivantes : 

./bmctl create config -c CLUSTER_NAME \
  --enable-apis --create-service-accounts --project-id=PROJECT_ID

CLUSTER_NAME est le nom du cluster. PROJECT_ID est le projet que vous avez créé dans la section Créer un projet Google Cloud.

La commande ci-dessus crée un fichier de configuration dans le répertoire baremetal à l'emplacement suivant : bmctl-workspace/cluster1/cluster1.yaml

Modifier le fichier de configuration

Pour modifier le fichier de configuration, procédez comme suit :

  1. Ouvrez le fichier de configuration bmctl-workspace/cluster1/cluster1.yaml dans un éditeur.
  2. Modifiez le fichier avec vos exigences spécifiques du nœud et du réseau. Utilisez l'exemple de fichier de configuration ci-dessous pour référence. Ce guide de démarrage rapide n'utilise ni n'inclut d'informations sur OpenID Connect (OIDC).
# 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

Exécuter des vérifications préliminaires et créer le cluster

Avant de créer un cluster, la commande bmctl exécute des vérifications préliminaires sur votre fichier de configuration de cluster. Si les vérifications réussissent, bmctl crée le cluster.

Pour exécuter des vérifications préliminaires et créer le cluster:

  1. Vérifiez que vous êtes bien dans le répertoire baremetal.
  2. Exécutez la commande suivante pour créer le cluster :
    3. ./bmctl create cluster -c CLUSTER_NAME
    Exemple : 
    ./bmctl create cluster -c cluster1

    La commande bmctl surveille les vérifications préliminaires et la création du cluster, puis affiche le résultat à l'écran et écrit des informations détaillées dans les journaux bmctl.

Vous trouverez les journaux bmctl, les vérifications préliminaires et les journaux d'installation de nœud dans le répertoire suivant : baremetal/bmctl-workspace/CLUSTER_NAME/log

Les vérifications préliminaires bmctl vérifient l'installation de cluster proposée pour rechercher les conditions suivantes :

  • La distribution et la version de Linux sont compatibles.
  • SELinux n'est pas en mode d'application forcée.
  • Sur Ubuntu, le pare-feu UFW (Uncomplicated Firewall) n'est pas actif.
  • Google Container Registry est accessible.
  • Les adresses IP virtuelles sont disponibles.
  • Les machines de cluster sont connectées entre elles.
  • Les machines des équilibreurs de charge se trouvent sur le même sous-réseau de couche 2.

La création du cluster peut prendre plusieurs minutes.

Obtenir des informations sur votre cluster

Après avoir créé un cluster, utilisez la commande kubectl pour afficher des informations sur le nouveau cluster. Lors de la création du cluster, la commande bmctl écrit un fichier kubeconfig en rapport avec le cluster, que vous interrogez à l'aide de kubectl. Le fichier kubeconfig est écrit dans bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig.

Exemple : 

kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig get nodes

Cette commande renvoie : 

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

Si la création du cluster échoue aux vérifications préliminaires, recherchez l'erreur dans les journaux de vérification préliminaire, puis corrigez-la dans le fichier de configuration du cluster. Les journaux de la vérification préliminaire se trouvent dans le répertoire /log à l'adresse : 

~/baremetal/bmctl-workspace/CLUSTER_NAME/log

Les journaux de vérification préliminaire correspondant à chaque machine du cluster se trouvent dans le répertoire CLUSTER_NAME et sont organisés par adresse IP. Exemple : 

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

Ignorer les erreurs détectées lors des vérifications préliminaires

Si la création de votre cluster échoue après les vérifications préliminaires, vous pouvez essayer de réinstaller le cluster à l'aide de l'option --force dans la commande bmctl.

L'option --force effectue une installation sur un cluster existant, mais ignore les résultats de tout échec aux vérifications préliminaires en raison de ports de serveur déjà alloués.

  1. Vérifiez que vous êtes bien dans le répertoire baremetal.
  2. Exécutez la commande suivante avec l'option --force pour recréer le cluster :
    3. ./bmctl create cluster -c CLUSTER_NAME --force
    Exemple : 
    ./bmctl create cluster -c cluster1 --force

Créer un déploiement et un service

Voici un fichier manifeste de déploiement. 

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"

Enregistrez le fichier manifeste sous le nom my-deployment.yaml.

Créez le déploiement à l'aide de la commande suivante: 

kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig create -f my-deployment.yaml

Affichez le déploiement : 

kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig get deployments

Le résultat indique que le déploiement comporte trois pods disponibles et prêts : 

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
my-deployment      3/3     3            3           16s

Le fichier manifeste suivant définit un service de type LoadBalancer : 

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: metrics
    department: sales
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 8080

Enregistrez le fichier manifeste sous le nom my-service.yaml.

Créez le service à l'aide de la commande suivante: 

kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig create -f my-service.yaml

Consultez le Service : 

kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig get service my-service

Sortie : 

NAME         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S
my-service   LoadBalancer   172.26.232.2   172.16.1.21   80:30060/TCP

Les clusters Anthos sur Bare Metal donnent au service une adresse IP externe. Utilisez l'adresse IP externe pour appeler le service :

curl 172.16.1.21

Le résultat est un message Hello World :

Hello, world!
Version: 2.0.0
Hostname: my-deployment-75d45b64f9-6clxj

Créer un plan de contrôle à haute disponibilité

Le démarrage rapide a créé un cluster hybride simple à deux nœuds. Si vous souhaitez créer un plan de contrôle à haute disponibilité, créez un cluster comportant trois nœuds de plan de contrôle.

Par exemple, modifiez le fichier de configuration pour ajouter deux nœuds supplémentaires au plan de contrôle :

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>

Exécuter l'équilibreur de charge dans son propre pool de nœuds

Le démarrage rapide a créé un cluster hybride simple à deux nœuds. Ainsi, l'équilibreur de charge s'exécute sur le même nœud qui exécute le plan de contrôle.

Si vous souhaitez que l'équilibreur de charge s'exécute dans son propre pool de nœuds, modifiez les valeurs nodePoolSpec de la section loadBalancer de votre fichier de configuration :

  loadBalancer:
    nodePoolSpec:
      clusterName: "cluster1"
      nodes:
      - address: <LB Machine 1 IP>
      - address: <LB Machine 2 IP>