Options et configuration avancées

Par défaut, les certificats dans RKE2 expirent dans 12 mois.

Si les certificats sont expirés ou s’il reste moins de 90 jours avant leur expiration, les certificats sont renouvelés lorsque RKE2 est redémarré.

Les certificats peuvent également être renouvelés manuellement. Pour ce faire, il est préférable d’interrompre le processus rke2-server, de renouveler les certificats, puis de redémarrer le processus :

Pour renouveler les certificats des agents, redémarrez rke2-agent sur les nœuds agents. Les certificats des agents sont renouvelés chaque fois que l’agent démarre.

Il est également possible de renouveler un service individuel en passant l’option --service, par exemple : rke2 certificate rotate --service api-server. Consultez Gestion des certificats pour plus de détails.

Tout fichier trouvé dans /var/lib/rancher/rke2/server/manifests sera automatiquement déployé sur Kubernetes de manière similaire à kubectl apply.

Pour des informations sur le déploiement de graphiques Helm en utilisant le répertoire des manifestes, reportez-vous à la section sur Helm.

RKE2 générera un fichier de configuration pour containerd à /var/lib/rancher/rke2/agent/etc/containerd/config.toml, en utilisant des valeurs spécifiques à la configuration actuelle du cluster et du nœud.

Pour une personnalisation avancée, vous pouvez créer un modèle de configuration containerd dans le même répertoire :

Containerd 2.0 est rétrocompatible avec les versions de configuration antérieures, et RKE2 continuera à rendre la configuration de version 2 héritée à partir de config.toml.tmpl si config-v3.toml.tmpl n’est pas trouvé.

Le fichier modèle est rendu dans la configuration de containerd à l’aide de la bibliothèque text/template. Consultez ContainerdConfigTemplateV3 et ContainerdConfigTemplate dans templates.go pour le contenu par défaut du modèle. Le modèle est exécuté avec une structure ContainerdConfig comme valeur dot (argument de données).

Si vous exécutez RKE2 dans un environnement qui n’a de connectivité externe que par le biais d’un proxy HTTP, vous pouvez configurer vos paramètres de proxy sur le service systemd de RKE2. Ces paramètres de proxy seront ensuite utilisés dans RKE2 et transmis au containerd et au kubelet intégrés, ainsi qu’aux pods statiques du plan de contrôle, etcd et kube-proxy.

Ajoutez les variables nécessaires HTTP_PROXY, HTTPS_PROXY et NO_PROXY au fichier d’environnement de votre service systemd, généralement :

RKE2 ajoutera automatiquement les plages d’adresses IP internes des Pods et des Services du cluster ainsi que le domaine DNS du cluster à la liste des entrées NO_PROXY. Vous devez vous assurer que les plages d’adresses IP utilisées par les nœuds Kubernetes eux-mêmes (c’est-à-dire les IP publiques et privées des nœuds) sont incluses dans la liste NO_PROXY, ou que les nœuds peuvent être atteints via le proxy.

Si vous souhaitez configurer les paramètres du proxy pour containerd sans affecter RKE2 et le Kubelet, vous pouvez préfixer les variables avec CONTAINERD_ :

Les agents RKE2 peuvent être configurés avec les options node-label et node-taint qui ajoutent une étiquette et un taint au kubelet. Les deux options n’ajoutent que des étiquettes et/ou des taints au moment de l’enregistrement, et ne peuvent être ajoutées qu’une seule fois et ne peuvent pas être supprimées par la suite via des commandes rke2.

Si vous souhaitez modifier les étiquettes et les taints du nœud après son enregistrement, vous devez utiliser kubectl. Reportez-vous à la documentation officielle de Kubernetes pour des détails sur la façon d’ajouter taints et étiquettes de nœud.

Les nœuds agents sont enregistrés via une connexion websocket initiée par le processus rke2 agent, et la connexion est maintenue par un équilibreur de charge côté client fonctionnant dans le cadre du processus agent.

Les agents s’enregistrent auprès du serveur en utilisant la partie secrète du cluster du jeton de jointure, ainsi qu’un mot de passe spécifique au nœud généré aléatoirement, qui est stocké sur l’agent à /etc/rancher/node/password. Le serveur stockera les mots de passe pour les nœuds individuels en tant que secrets Kubernetes, et toute tentative ultérieure doit utiliser le même mot de passe. Les secrets de mot de passe des nœuds sont stockés dans l’espace de noms kube-system avec des noms utilisant le modèle <host>.node-password.rke2. Ces secrets sont supprimés lorsque le nœud Kubernetes correspondant est supprimé.

Si le répertoire /etc/rancher/node d’un agent est supprimé, le fichier de mot de passe doit être recréé pour l’agent avant le démarrage, ou l’entrée supprimée du serveur ou du cluster Kubernetes (selon la version de RKE2).

Le script d’installation fournit des unités pour systemd, mais n’active ni ne démarre le service par défaut.

Lors de l’exécution avec systemd, des journaux seront créés dans /var/log/syslog et consultés à l’aide de journalctl -u rke2-server ou journalctl -u rke2-agent.

Un exemple d’installation avec le script d’installation :

Les graphiques du serveur fournis avec rke2 déployés lors du démarrage du cluster peuvent être désactivés et remplacés par des alternatives. Un cas d’utilisation courant consiste à remplacer le graphique rke2-ingress-nginx fourni par une alternative.

Pour désactiver l’un des graphiques système fournis, définissez le paramètre disable dans le fichier de configuration avant le démarrage. Un exemple de désactivation de tous les graphiques système disponibles est :

Dans les régions AWS publiques, pour garantir que RKE2 est activé pour le cloud et capable de provisionner automatiquement certaines ressources cloud, configurez RKE2 avec :

Lors de l’installation de RKE2 dans des régions classifiées (telles que SC2S ou C2S), il y a quelques prérequis supplémentaires à prendre en compte pour s’assurer que RKE2 sait comment et où communiquer en toute sécurité avec les points de terminaison AWS appropriés :

Les options suivantes sont disponibles sous la sous-commande server pour RKE2. Les options permettent de spécifier les demandes et les limites d’UC pour les composants du plan de contrôle au sein de RKE2.

Les valeurs sont une liste délimitée par des virgules de [controlplane-component]-(cpu|memory)=[desired-value]. Les valeurs possibles pour controlplane-component sont :

Ainsi, un exemple de configuration peut ressembler à :

Les valeurs d’unité pour l’UC/mémoire sont identiques aux unités de ressources Kubernetes (Voir : Limites de ressources dans Kubernetes).

Les options suivantes sont disponibles sous la sous-commande server pour RKE2. Ces options spécifient le montage de chemins d’hôte de répertoires du système de fichiers du nœud dans le composant de pod statique qui correspond au nom préfixé.

Les options de configuration suivantes sont disponibles pour la sous-commande server pour RKE2. Ces options spécifient des variables d’environnement supplémentaires au format standard, c’est-à-dire KEY=VALUE pour le composant de pod statique qui correspond au nom préfixé.

Plusieurs variables d’environnement peuvent être spécifiées pour le même composant en passant les valeurs du flag sous forme de tableau dans le fichier de configuration.