Version 1.6. 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.7, consultez la page Mettre à niveau Anthos sur solution Bare Metal dans la documentation de la version 1.7.

Versions compatibles : 1.14 | 1.13 | 1.12

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

Présentation des clusters Anthos sur Bare Metal

Champ d'application du démarrage rapide pour les clusters Anthos sur Bare Metal

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

admin : cluster utilisé pour gérer des 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 pour les clusters Anthos sur Bare Metal

La commande d'installation des clusters Anthos sur Bare Metal, appelée bmctl, a été conçue pour simplifier la création de clusters. La commande peut configurer automatiquement les comptes de service et les API Google dont vous avez besoin pour les clusters Anthos sur Bare Metal, et nous utiliserons ces services automatisés dans ce guide de démarrage rapide.

Si vous le souhaitez, vous pouvez également configurer manuellement les services et les API nécessaires avant de créer des clusters avec bmctl. Nous verrons les modifications de commandes que vous devrez effectuer ultérieurement dans ce document. Pour configurer manuellement les services Google dont vous avez besoin, consultez la section Activer des services Google et des comptes de service.

Avant de créer un cluster à l'aide d'clusters Anthos sur bare metal, vérifiez les points suivants:

Créez un projet Google Cloud dans lequel vous avez le rôle d'Éditeur ou de Propriétaire.
Téléchargez et installez l'outil de ligne de commande bmctl comme décrit ci-dessous.
Configurez un poste de travail d'administrateur Linux pour exécuter bmctl. Remarque : N'utilisez pas Cloud Shell comme poste de travail d'administrateur.
1. Installez gcloud, gsutil et kubectl comme décrit ci-dessous.
2. Installez Docker version 19.03 ou ultérieure. (Pour obtenir des instructions sur la configuration de Docker, consultez la page sur la configuration de votre système d'exploitation Linux : Configurer CentOS, Configurer RHEL ou Configurer Ubuntu.)
3. À l'aide de 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.
4. Générez une paire de clés privée/publique sur le poste de travail administrateur (ne définissez pas de phrase secrète pour les clés). Les clés sont nécessaires 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.
```
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 YAML cluster config avec les identifiants appropriés. Pour en savoir plus, consultez la section #Node access configuration dans l'exemple de fichier de configuration de cluster.
5. 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
```
6. Désactivez l'authentification par mot de passe SSH sur les machines de nœud de cluster et utilisez la commande suivante sur le poste de travail d'administrateur pour vérifier le fonctionnement de l'authentification par clé publique entre le poste de travail d'administrateur et les machines de nœud de cluster.
```
ssh -o IdentitiesOnly=yes -i identity_file root@cluster_node_ip
```

Installer les utilitaires gcloud

Les outils gcloud, gsutil et kubectl sont inclus dans gcloud CLI.

Sur votre machine d'administration, installez et initialisez gcloud CLI en suivant les instructions de cette page. Ce processus installe gcloud et gsutil.
Mettre à jour la CLI gcloud
```
gcloud components update
```
Connectez-vous à votre compte Google pour gérer les services et les comptes de service:
```
gcloud auth login --update-adc
```
Un nouvel onglet de navigateur vous invite à choisir un compte.

Notez qu'à ce stade, vous pouvez configurer un projet Google Cloud par défaut et activer d'autres services et API Google avant de créer des clusters Anthos sur Bare Metal. Définir un projet par défaut vous fait gagner du temps lorsque vous activez des services manuellement.

Toutefois, comme indiqué dans ce guide de démarrage rapide, vous pouvez également spécifier un projet et configurer les services Google requis directement à l'aide de la commande bmctl lorsque vous créez vos clusters. Lorsque vous effectuez cette opération, bmctl utilise toujours l'ID du projet que vous spécifiez lors de l'exécution de la commande.
Installez kubectl à l'aide de gcloud :
```
gcloud components install kubectl
```

Installer bmctl

L'outil de ligne de commande permettant de créer des clusters Anthos sur Bare Metal est bmctl. Vous téléchargez le fichier bmctl à partir d'un bucket Cloud Storage.

Pour télécharger 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.6.2/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.

Notez que votre poste de travail d'administrateur doit pouvoir se connecter en ssh à ces nœuds et avoir accès à l'adresse IP virtuelle du plan de contrôle.

Consultez les exigences concernant le matériel et le système d'exploitation (Centos, RHEL et Ubuntu) afn d'en savoir plus sur les éléments requis pour les 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 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 de votre cluster et PROJECT_ID est un projet Google dans lequel vous avez un rôle de propriétaire ou d'éditeur.

Cette commande crée un fichier de configuration dans le répertoire baremetal à l'adresse 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 en fonction des exigences spécifiques du nœud et du réseau. Consultez l'exemple de fichier de configuration ci-dessous. Notez que dans ce guide de démarrage rapide, nous avons omis 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.6.2
# 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 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:
- 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 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: 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
---
# 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_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 l'opération réussit, le cluster est créé.

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.

Les journaux bmctl , ainsi que les journaux de vérification préliminaire et d'installation de nœud se trouvent dans le répertoire 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.
Pour Ubuntu, AppArmor et UFW sont désactivés.
Pour CentOS/RHEL, le pare-feu est désactivé.
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 L2.

La création du cluster peut prendre plusieurs minutes.

Obtenir des informations sur un cluster

Une fois le cluster créé, la commande kubectl affiche des informations le concernant. 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 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 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, puis créez le déploiement :

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 en cours d'exécution :

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

Voici le fichier manifeste d'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, puis créez le service :

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

Output:

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

Notez que les clusters Anthos sur Bare Metal ont attribué une adresse IP externe au service. 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é

Ce guide de démarrage rapide permet de créer 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 affiché ci-dessus pour ajouter des 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

Ce guide de démarrage rapide permet de créer un cluster hybride simple à deux nœuds. 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>