Version 1.7. Cette version n'est plus compatible. Pour plus d'informations, consultez la politique de compatibilité avec les versions. Pour en savoir plus sur la mise à niveau vers la version 1.8, consultez la page Mettre à niveau Anthos sur solution Bare Metal dans la documentation de la version 1.8.

Versions compatibles: 1.14 | 1.13 | 1.12

Guide de démarrage rapide sur Anthos clusters on bare metal

Avec les clusters Anthos sur solution Bare Metal, vous pouvez définir quatre types de clusters:

Administrateur : cluster permettant de gérer les clusters d'utilisateur.
Utilisateur : cluster utilisé pour exécuter des charges de travail
Autonome : cluster unique pouvant s'administrer et exécuter des charges de travail, mais qui ne peut pas créer ni gérer d'autres clusters d'utilisateur
Hybride : cluster unique pour les administrateurs et les charges de travail, qui peut également gérer des clusters d'utilisateur

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 :

Créez un projet Google Cloud.
Installez Google Cloud CLI.
Configurez une station de travail d'administrateur Linux.
Installez l'outil bmctl.

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 une solution Bare Metal, vous devez disposer d'un projet Google Cloud dans lequel votre compte dispose de l'un des rôles suivants :

Éditeur
Owner

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

Installer Google Cloud CLI

Ce guide de démarrage rapide utilise les outils kubectl et bmctl pour créer et configurer des clusters. Pour installer ces outils, vous avez besoin de gcloud et de gsutil. Google Cloud CLI inclut les outils de ligne de commande gcloud, gsutil et kubectl.

Pour installer les outils nécessaires, procédez comme suit :

Sur votre poste de travail administrateur, installez et initialisez Google Cloud CLI en suivant ces instructions. Ce processus installe gcloud et gsutil.
Mettez à jour Google Cloud CLI :
```
gcloud components update
   
```
Connectez-vous avec votre compte Google pour gérer vos services et comptes de service :
```
gcloud auth login --update-adc
```
Un nouvel onglet de navigateur vous invite à choisir un compte.
Installez kubectl à l'aide de gcloud :
```
gcloud components install kubectl
```

Configurer une station de travail d'administrateur Linux

Après avoir installé gcloud, gsutil et kubectl, configurez une station de travail d'administrateur Linux. N'utilisez pas Cloud Shell comme station de travail administrateur.

Installez Docker version 19.03 ou ultérieure. Pour apprendre à configurer Docker, accédez à la page correspondant à votre distribution Linux :
Pour utiliser l'accès root, configurez le SSH sur le poste de travail administrateur et sur les machines distantes du nœud de cluster. Au départ, vous devez activer l'authentification par mot de passe SSH root sur les machines distantes du nœud de cluster pour partager les clés du poste de travail administrateur. Une fois les clés en place, vous pouvez désactiver l'authentification par mot de passe SSH.
Générez une paire de clés privée/publique sur le poste de travail d'administrateur. Ne définissez pas de phrase secrète pour les clés. Vous avez besoin des clés afin d'utiliser SSH pour les connexions sécurisées et sans mot de passe entre le poste de travail d'administration et les machines du nœud de cluster. Générez les clés à l'aide de la commande suivante :
```
ssh-keygen -t rsa
```
Vous pouvez également utiliser l'accès utilisateur SUDO aux machines du nœud de cluster pour configurer SSH, mais pour les connexions utilisateur non racine sans mot de passe, vous devez mettre à jour le fichier de configuration de cluster avec les identifiants appropriés. Pour en savoir plus, consultez la section #Node access configuration de l'exemple de fichier de configuration de cluster.
Ajoutez la clé publique générée aux machines du nœud de cluster. Par défaut, les clés publiques sont stockées dans le fichier d'identité id_rsa.pub.
```
ssh-copy-id -i ~/.ssh/IDENTITY_FILE root@CLUSTER_NODE_IP
```
Désactivez l'authentification par mot de passe SSH sur les machines de nœud de cluster. Utilisez la commande suivante sur le poste de travail administrateur pour vérifier le fonctionnement de l'authentification par clé publique entre le poste de travail administrateur et les machines de nœud de cluster.
```
ssh -o IdentitiesOnly=yes -i IDENTITY_FILE root@CLUSTER_NODE_IP
```

Télécharger et installer l'outil bmctl

Vous utilisez l'outil de ligne de commande bmctl pour créer des clusters dans des clusters Anthos sur Bare Metal. La commande bmctl configure automatiquement les comptes de service Google et active les API dont vous avez besoin pour utiliser les clusters Anthos sur solution Bare Metal dans le projet spécifié.

Si vous souhaitez créer vos propres comptes de service ou définir une autre configuration manuelle de projet, consultez la page Activer les services et comptes de service Google avant de créer des clusters avec bmctl.

Pour télécharger et installer l'outil bmctl, procédez comme suit :

Créez un répertoire pour bmctl:
```
cd ~
mkdir baremetal
cd baremetal
```

Téléchargez bmctl à partir du bucket Cloud Storage:

gsutil cp gs://anthos-baremetal-release/bmctl/1.7.1/linux-amd64/bmctl bmctl
chmod a+x bmctl

Vérifiez que bmctl est correctement installé en consultant les informations d'aide:
```
./bmctl -h
```

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.

Consultez la page matériel et la configuration système requise (Centos, RHEL etUbuntu) pour en savoir plus sur les exigences des nœuds de cluster.

Créer un cluster

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

Utilisez bmctl pour créer un fichier de configuration.
Modifiez le fichier de configuration de façon à le personnaliser pour votre cluster et votre réseau.
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 d'être dans le répertoire baremetal et 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 :

Ouvrez le fichier de configuration bmctl-workspace/cluster1/cluster1.yaml dans un éditeur.
Modifiez le fichier avec vos exigences spécifiques du nœud et du réseau. Utilisez l'exemple de fichier de configuration suivant. 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
---
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.7.1
  # 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

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:

Vérifiez que vous êtes bien dans le répertoire baremetal.
Exécutez la commande suivante pour créer le cluster :

./bmctl create cluster -c CLUSTER_NAME

./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 application forcée.
Pour Ubuntu, AppArmor et UFW sont désactivés.
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 le résultat suivant :

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 vérification préliminaire se trouvent dans le répertoire /log à l'adresse suivante :

~/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 le réinstaller à 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.

Vérifiez que vous êtes bien dans le répertoire baremetal.
Exécutez la commande suivante avec l'option --force pour recréer le cluster :

./bmctl create cluster -c CLUSTER_NAME --force

./bmctl create cluster -c cluster1 --force

Créer un déploiement et un service

Voici une définition de ressource personnalisée pour un 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 la définition de ressource personnalisée 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

La définition de ressource personnalisée suivante 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 la définition de la ressource personnalisée 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>