Hello,

Dans cet article, nous allons voir comment planifier le redémarrage des nodes de votre cluster AKS. Microsoft est responsable de déployer les mises à jour de sécurité sur vos nodes, mais vous avez la responsabilité de redémarrer vos nodes afin que les mises à jours soient appliquées.

Pour planifier ce redémarrage, je vous invite à utiliser l’outil Kured (Kubernetes Reboot Daemon).

Quand une mise à jour est installée et que celle-ci nécessite un redémarrage, un fichier « /var/run/reboot-required » est créé sur chaque node votre cluster.

Dans un second temps, le daemon Kured va vérifier l’existence de ce fichier (par défaut chaque 60 min) et redémarrer chaque node un après l’autre après avoir déplacé les pods sur un autre node de votre cluster.

Afin de déployer Kured au sein de votre cluster, je vous invite à utiliser la commande suivante:

kubectl apply -f https://github.com/weaveworks/kured/releases/download/1.2.0/kured-1.2.0-dockerhub.yaml 

Maxime.

Hello,

Si vous avez un cluster AKS déployé dans votre souscription Azure, vous avez très certainement reçu cet email:

« Les clusters AKS créés avant le mois de mars 2019 possèdent des certificats qui expirent au bout de deux ans. Tout cluster créé après mars 2019 ou tout cluster dont la rotation des certificats a été effectuée dispose de certificats qui expirent au bout de 30 ans. »

Azure Kubernetes Service (AKS) utilise des certificats pour l’authentification avec un grand nombre de ses composants. Régulièrement, vous pouvez être amené à procéder à une rotation de ces certificats pour des raisons de sécurité.

AKS génère et utilise les certificats, autorités de certification et comptes de service suivants :

• Le serveur d’API AKS crée une autorité de certification (CA) appelée « autorité de certification de cluster ».
• Le serveur d’API dispose d’une autorité de certification de cluster, qui signe les certificats pour la communication unidirectionnelle, du serveur d’API vers les kubelets.
• Chaque kubelet crée également une demande de signature de certificat (CSR), qui est signée par l’autorité de certification de cluster, pour la communication du kubelet vers le serveur d’API.
• Le magasin de valeurs de clés etcd dispose d’un certificat signé par l’autorité de certification de cluster, pour la communication émanant de etcd à destination du serveur d’API.
• Le magasin de valeurs de clé etcd crée une autorité de certification qui signe les certificats pour authentifier et autoriser la réplication des données entre les réplicas etcd du cluster AKS.
• L’agrégation d’API utilise l’autorité de certification de cluster pour émettre des certificats destinés à la communication avec d’autres API, telles que Open Service Broker pour Azure. L’agrégation d’API peut également disposer de sa propre autorité de certification pour émettre ces certificats, mais elle utilise actuellement l’autorité de certification de cluster.
• Chaque nœud utilise un jeton de compte de service (SA), qui est signé par l’autorité de certification de cluster.
• Le client kubectl dispose d’un certificat pour communiquer avec le cluster AKS.

Pour effectuer la rotation de l’ensemble des certificats de votre cluster, je vous invite à utiliser la commande suivante:

az aks rotate-certs -g aksmaxime -n aksdemomax

Attention, ceci peut-entrainer une indisponibilité de votre cluster AKS, pendant environ 24 – 30 min …

Maxime.