introduction
Les applications Kubernetes doivent être configurées, qu’elles soient liées à l’authentification avec des paramètres tels que les clés API, les jetons ou d’autres informations d’identification, ou des paramètres généraux tels que la configuration de la journalisation, les variables d’environnement ou d’autres indicateurs. Dans Kubernetes, ceux-ci sont généralement gérés avec ConfigMaps ou Secrets. Et la configuration peut être mise à jour, que ce soit pour les mises à jour ou la rotation des informations d’identification, pour activer ou désactiver la connexion, ou pour mettre à jour un paramètre d’environnement particulier. Les mises à jour peuvent avoir lieu fréquemment ou rarement selon l’application, et il y aura des cas où nous souhaiterions que ces mises à jour se reflètent immédiatement dans nos applications. En tant que telle, une application Kubernetes ne serait pas au courant d’une mise à jour de ConfigMap ou Secret, jusqu’à ce qu’elle soit rechargée dans le cadre d’une mise à jour par son jeu de réplicas respectif. À cette fin,
Caractéristiques
Que regarder :
Reloader surveille les ressources suivantes dans un cluster. Ces ressources contiennent généralement la configuration d’une application, par exemple pour spécifier l’environnement, d’autres paramètres ou les informations d’identification pour accéder aux services externes ou aux comptes d’utilisateurs internes.
- ConfigMap
- Secret
Quoi recharger :
Une telle configuration peut être utilisée par des applications, mais les applications dépendantes ne font pas nécessairement partie d’un type de déploiement. Reloader prend donc en charge le déclenchement des mises à jour des ressources Kubernetes suivantes:
- Déploiement
- StatefulSet
- DaemonSet
Comparaison avec des contrôleurs similaires
Vous avez peut-être déjà utilisé un contrôleur similaire sur votre cluster. Il existe d’autres outils open source développés par la communauté qui gèrent des cas d’utilisation similaires à Stakater Reloader, mais les lacunes de ces contrôleurs ont incité notre équipe à développer Reloader en gardant à l’esprit la flexibilité, l’extensibilité et la stabilité.
k8s-trigger-controller :
k8s-trigger-controller est un outil ayant le même objectif que Stakater Reloader. Il y a quelques similitudes entre les deux, mais aussi quelques différences.
ConfigMapController :
Reloader est en fait inspiré de ConfigMapController, mais il existe de nombreuses façons en quoi il diffère de ConfigMapController.
Le tableau suivant présente une comparaison des trois et illustre où Stakater Reloader a l’avantage sur les deux autres:
Comment ça fonctionne :
Regarder la configuration :
Reloader surveillera Secrets et ConfigMaps. Chaque fois qu’il y a une mise à jour dans l’un ou l’autre, Reloader vérifie ensuite si un déploiement, un DaemonSet ou un StatefulSet en dépend. Cette dépendance est gérée à l’aide d’annotations: `configmap.reloader.stakater.com / reload` pour ConfigMap et` secret.reloader.stakater.com / reload` pour Secret. Par exemple, si une «ressource de déploiement» de déploiement est annotée avec «secret.reloader.stakater.com/reload:« nom-secret »», puis une fois que le secret avec le nom «nom-secret» est mis à jour, Reloader cherchera pour les déploiements qui ont l’annotation respective, dans ce cas la «ressource de déploiement», et il évaluera ce déploiement pour la mise à jour.
Vérifier qu’un rechargement est nécessaire :
Une étape supplémentaire consiste à déterminer si une ressource doit être mise à jour ou non. Pour vous assurer que le déploiement doit vraiment être mis à jour et qu’aucune mise à jour inutile n’est déclenchée, Reloader s’assure que les conteneurs du déploiement ont bien une version obsolète de ConfigMap. Cela se fait en incorporant un hachage codé SHA1 de ConfigMap en tant que variable d’environnement des conteneurs. Chaque fois que vous évaluez le conteneur pour la mise à jour, la valeur précédente de la variable d’environnement dans le conteneur est comparée à la valeur nouvellement générée à partir du ConfigMap mis à jour. Si les valeurs diffèrent, cela indique qu’il y a un vrai changement dans ConfigMap et que le déploiement doit en effet être mis à jour.
Mise à jour du déclencheur :
Une fois déterminé que le déploiement doit être mis à jour, Reloader appelle le client Kubernetes pour mettre à jour le déploiement. Le client utilise la stratégie de mise à jour spécifiée dans le manifeste pour la ressource respective à mettre à jour. Si une stratégie de mise à jour n’est pas explicitement définie dans le manifeste, la stratégie par défaut est utilisée. Dans Kubernetes v1.11, la stratégie par défaut pour les déploiements et les StatefulSets est la stratégie RollingUpdate ; et pour DeamonSets, c’est la stratégie OnDelete .
Comment déployer :
Le déploiement de Stakater Reloader sur votre cluster est simple et peut être effectué à l’aide du yaml manifeste de l’outil ou du graphique de barre. Le graphique yaml et helm est disponible publiquement dans le cadre du référentiel git ou du référentiel helm et n’a pas besoin d’être téléchargé explicitement.
Reloader peut être déployé à l’aide de yaml avec la commande suivante:
kubectl apply -f https://raw.githubusercontent.com/stakater/Reloader/master/deployments/kubernetes/reloader.yaml
helm repo add stakater https://stakater.github.io/stakater-charts
helm repo update
helm install stakater / reloader
Par défaut, Reloader surveillera tous les espaces de noms, mais cela peut être limité si nécessaire via l’autorisation RBAC, en utilisant les espaces de noms spécifiés dans ClusterRole et ClusterRoleBinding. Ces modifications peuvent être effectuées manuellement dans le manifeste yaml ou générées par une commande helm.
Pour yaml, le fichier peut être modifié dans un éditeur de texte pour modifier les valeurs des propriétés d’espace de noms sous ClusterRole, ClusterRoleBinding et ServiceAccount
Pour helm, la commande suivante peut être exécutée avec le chemin du dossier des graphiques du référentiel comme l’un des arguments. Cela génère un yaml avec l’espace de noms modifié:
helm --namespace NAMESPACE template deployments / kubernetes / chart / reloader> reloader.yaml
Après ces modifications, le yaml résultant peut être appliqué avec kubectl:
kubectl apply -f reloader.yaml
Une fois Reloader déployé, nous pouvons nous attendre à voir le type suivant d’instructions d’événement dans les journaux de Reloader chaque fois qu’un changement est détecté dans la configuration et les pods mis à jour par Reloader:
Modifications détectées dans le nom secret de type 'SECRET' dans l'espace de noms: test-reloader Ressource de déploiement
mise à jour de type Déploiement dans l'espace de noms: test-reloader
En clôture :
Stakater Reloader a des améliorations significatives par rapport à d’autres contrôleurs open-source similaires. Avec sa prise en charge de différents types de ressources, une licence open-source et une base de code stable, c’est un bon contrôleur à utiliser lorsque les pods doivent être redémarrés automatiquement lors de la mise à jour de la configuration.
Plus d’informations sont disponibles sur le référentiel Github: https://github.com/stakater/reloader
