Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi.

Datastore de cluster

La capacité d’exécuter Kubernetes en utilisant un datastore autre qu’etcd distingue K3s des autres distributions Kubernetes. Cette fonctionnalité offre de la flexibilité aux opérateurs Kubernetes. Les options de datastore disponibles vous permettent de sélectionner un datastore qui correspond le mieux à votre cas d’utilisation. Par exemple :

  • Si votre équipe n’a pas d’expertise dans l’exploitation d’etcd, vous pouvez choisir une base de données SQL de niveau entreprise comme MySQL ou PostgreSQL.

  • Si vous devez exécuter un cluster simple et éphémère dans votre environnement CI/CD, vous pouvez utiliser la base de données SQLite intégrée.

  • Si vous souhaitez déployer Kubernetes en périphérie et que vous avez besoin d’une solution à haute disponibilité mais ne pouvez pas vous permettre la surcharge opérationnelle liée à la gestion d’une base de données en périphérie, vous pouvez utiliser le datastore intégré à haute disponibilité de K3s, basé sur etcd intégré.

K3s prend en charge les options de datastore suivantes :

  • Intégré SQLite
    SQLite ne peut pas être utilisé sur des clusters avec plusieurs serveurs.
    SQLite est le datastore par défaut et sera utilisé si aucune autre configuration de datastore n’est présente et qu’aucun fichier de base de données etcd intégré n’est présent sur le disque.

  • etcd intégré
    Consultez la documentation etcd intégré à haute disponibilité pour plus d’informations sur l’utilisation d’etcd intégré avec plusieurs serveurs. L’etcd intégré sera automatiquement sélectionné si K3s est configuré pour initialiser un nouveau cluster etcd, rejoindre un cluster etcd existant, ou si des fichiers de base de données etcd sont présents sur le disque au démarrage.

  • Base de données externe
    Consultez la documentation Haute Disponibilité DB Externe pour plus d’informations sur l’utilisation de datastores externes avec plusieurs serveurs.
    Les datastores externes suivants sont pris en charge :

    • etcd (certifié contre la version 3.5.21)

    • MySQL (certifié contre les versions 5.7 et 8.0)

    • MariaDB (certifié contre les versions 10.11 et 11.4)

    • PostgreSQL (certifié contre les versions 15.12, 16.7 et 17.3)

Support des instructions préparées

K3s nécessite un support des instructions préparées de la base de données. Cela signifie que les gestionnaires de connexions tels que PgBouncer peuvent nécessiter une configuration supplémentaire pour fonctionner avec K3s.
Configurations multimaster

Les bases de données multi-maîtres qui définissent auto_increment_increment ou auto_increment_offset à une valeur supérieure à 1 ne sont pas prises en charge. Kine s’attend à ce que la révision commence à 0 et augmente toujours exactement de 1 lorsqu’une clé est insérée avec succès. Cela affecte des produits tels que Galera pour MySQL/MariaDB.

Paramètres de configuration du datastore externe :

Si vous souhaitez utiliser un datastore externe tel que PostgreSQL, MySQL ou etcd, vous devez définir le paramètre datastore-endpoint afin que K3s sache comment s’y connecter. Vous pouvez également spécifier des paramètres pour configurer l’authentification et le chiffrement de la connexion. Le tableau ci-dessous résume ces paramètres, qui peuvent être passés sous forme de drapeaux CLI ou de variables d’environnement.

Drapeau CLI Variable d’environnement Description

--datastore-endpoint

K3S_DATASTORE_ENDPOINT

Spécifiez une chaîne de connexion PostgreSQL, MySQL ou etcd. Ceci est une chaîne utilisée pour décrire la connexion au datastore. La structure de cette chaîne est spécifique à chaque backend et est détaillée ci-dessous.

--datastore-cafile

K3S_DATASTORE_CAFILE

Fichier de l’autorité de certification TLS (CA) utilisé pour sécuriser la communication avec le datastore. Si votre datastore traite des requêtes via TLS en utilisant un certificat signé par une autorité de certification personnalisée, vous pouvez spécifier cette CA à l’aide de ce paramètre afin que le client K3s puisse vérifier correctement le certificat.

--datastore-certfile

K3S_DATASTORE_CERTFILE

Fichier de certificat TLS utilisé pour l’authentification basée sur le certificat client à votre datastore. Pour utiliser cette fonctionnalité, votre datastore doit être configuré pour prendre en charge l’authentification basée sur le certificat client. Si vous spécifiez ce paramètre, vous devez également spécifier le paramètre datastore-keyfile.

--datastore-keyfile

K3S_DATASTORE_KEYFILE

Fichier de clé TLS utilisé pour l’authentification basée sur le certificat client à votre datastore. Voir le paramètre datastore-certfile précédent pour plus de détails.

En tant que meilleure pratique, nous recommandons de définir ces paramètres en tant que variables d’environnement plutôt que comme arguments de ligne de commande afin que vos identifiants de base de données ou d’autres informations sensibles ne soient pas exposés dans les informations du processus.

Format et fonctionnalité de l’endpoint du datastore

Comme mentionné, le format de la valeur passée au paramètre datastore-endpoint dépend du backend du datastore. Les détails suivants décrivent ce format et cette fonctionnalité pour chaque datastore externe pris en charge.

  • PostgreSQL

  • MySQL / MariaDB

  • etcd

Dans sa forme la plus courante, le paramètre endpoint du datastore pour PostgreSQL a le format suivant :

postgres://username:password@hostname:port/database-name

Des paramètres de configuration plus avancés sont disponibles. Pour plus d’informations à ce sujet, veuillez consulter https://godoc.org/github.com/lib/pq..

Si vous spécifiez un nom de base de données et qu’il n’existe pas, le serveur tentera de le créer.

Si vous ne fournissez que postgres:// comme endpoint, K3s tentera de faire ce qui suit :

  • Se connecter à l’hôte local en utilisant postgres comme nom d’utilisateur et mot de passe.

  • Créer une base de données nommée kubernetes.

Dans sa forme la plus courante, le paramètre datastore-endpoint pour MySQL et MariaDB a le format suivant :

mysql://username:password@tcp(hostname:3306)/database-name

Des paramètres de configuration plus avancés sont disponibles. Pour plus d’informations à ce sujet, veuillez consulter https://github.com/go-sql-driver/mysql#dsn-data-source-name.

Notez qu’en raison d’un problème connu dans K3s, vous ne pouvez pas définir le paramètre tls. La communication TLS est prise en charge, mais vous ne pouvez pas, par exemple, définir ce paramètre sur "skip-verify" pour amener K3s à ignorer la vérification du certificat.

Si vous spécifiez un nom de base de données et qu’il n’existe pas, le serveur tentera de le créer.

Si vous ne fournissez que mysql:// comme endpoint, K3s tentera de faire ce qui suit :

  • Connectez-vous au socket MySQL à /var/run/mysqld/mysqld.sock en utilisant l’utilisateur root sans mot de passe

  • Créez une base de données avec le nom kubernetes

Dans sa forme la plus courante, le paramètre datastore-endpoint pour etcd a le format suivant :

https://etcd-host-1:2379,https://etcd-host-2:2379,https://etcd-host-3:2379\

Ce qui précède suppose un cluster etcd typique de trois nœuds. Le paramètre peut accepter une ou plusieurs URL etcd séparées par des virgules.