Kubernetes 1.16 est disponible depuis quelque temps et se déploie progressivement sur de nombreuses plateformes Kubernetes managées. Vous avez peut-être entendu parler des dépréciations d'API. Plutôt simples à traiter, ces évolutions peuvent néanmoins perturber sérieusement vos services si elles passent inaperçues.
La dépréciation d'API, qu'est-ce que c'est ?
À mesure que les fonctionnalités de Kubernetes évoluent, les API doivent suivre le mouvement. Des règles encadrent cette évolution pour garantir compatibilité et stabilité¹. Cela ne se produit pas à chaque version, mais tôt ou tard, vous devrez adopter la nouvelle version et le nouveau format de l'API, l'ancien n'étant plus pris en charge.
Pourquoi est-ce un enjeu majeur avec la version 1.16 ?
Plusieurs API dépréciées avaient été conservées au fil des dernières versions de K8s et disparaissent définitivement avec Kubernetes 1.16. Voici les groupes d'API et versions concernés :
- Deployment —
extensions/v1beta1,apps/v1beta1etapps/v1beta2 - NetworkPolicy —
extensions/v1beta1 - PodSecurityPolicy —
extensions/v1beta1 - DaemonSet —
extensions/v1beta1etapps/v1beta2 - StatefulSet —
apps/v1beta1etapps/v1beta2 - ReplicaSet —
extensions/v1beta1,apps/v1beta1etapps/v1beta2
Si vous tentez de créer une ressource avec l'une d'elles sous 1.16, l'opération échouera, tout simplement.
Comment savoir si je suis concerné ?
Vous pouvez passer en revue manuellement tous vos manifestes, mais l'opération est chronophage. Il est facile d'en oublier, et l'exercice devient vite ingérable lorsque plusieurs équipes déploient sur le même cluster ou que les manifestes ne sont pas centralisés au même endroit. C'est précisément là qu'intervient Kube-No-Trouble, alias kubent.
Où est l'astuce ?
L'information sur la version d'API utilisée pour créer une ressource donnée n'est normalement pas accessible : la ressource est toujours convertie en interne et stockée dans la version de stockage privilégiée. Cela dit, si vous utilisez kubectl ou Helm pour déployer vos ressources, le manifeste d'origine est lui aussi conservé dans le cluster, ce dont nous pouvons tirer parti².
Comment résoudre vos déboires liés aux dépréciations
La méthode d'installation la plus simple est la suivante :
sh -c "$(curl -sSL 'https://git.io/install-kubent')"
Cette commande installe la dernière version de kubent dans /usr/local/bin ³.
Configurez le contexte courant de kubectl pour qu'il pointe vers le cluster à vérifier, puis lancez l'outil kubent :
Fig. 1 : exemple de sortie d'une exécution de kubent
Kubent se connecte à votre cluster, récupère toutes les ressources potentiellement concernées, les analyse et affiche un récapitulatif de celles qui le sont effectivement.
Vous pouvez aussi utiliser l'option -f json pour obtenir une sortie au format JSON, plus adaptée si vous souhaitez l'intégrer dans votre pipeline CI/CD ou exploiter les résultats par la suite. Le README du dépôt doitintl/kube-no-trouble détaille l'ensemble des options de configuration disponibles.
Que faire des ressources détectées ?
Dans certains cas, il suffit de modifier l'apiVersion dans votre manifeste ; dans d'autres, la structure a évolué et demande des ajustements. Gardez aussi à l'esprit que de nombreuses valeurs par défaut ont changé entre les versions⁴ : en vous contentant de modifier l'apiVersion et d'appliquer le même manifeste, vous obtiendrez un résultat différent. Par exemple, l'updateStrategy.type de StatefulSet est passé de OnDelete à RollingUpdate, avec un comportement radicalement différent à la clé.
La commande kubectl convert, jadis utilisée, est aujourd'hui dépréciée et risque de ne pas convertir correctement vos ressources au regard des valeurs par défaut évoquées plus haut.
La meilleure approche consiste sans doute à appliquer directement les ressources (vous les avez déjà sous la main si vous les avez détectées avec kubent), puis à en récupérer la nouvelle version via l'API. La transformation vers la nouvelle version est ainsi réalisée correctement. Vous avez peut-être remarqué que kubectl est quelque peu non déterministe quant à la version qu'il renvoie. Pour demander une version d'API précise, utilisez la forme complète :
kubectl get ingress.v1beta1.extensions -o yaml
Vos retours sont les bienvenus !
Nous espérons que cet article vous aidera à repérer et à traiter l'utilisation d'API dépréciées dans vos clusters Kubernetes avant qu'elles ne vous causent des ennuis.
L'outil kubent n'en est qu'à ses débuts et je serais ravi de recueillir vos commentaires, vos suggestions et votre avis sur son utilité. Bon vent ! ⛵⛵⛵
- [1] Le document Deprecation Policy de Kubernetes définit la manière dont les différentes parties du système peuvent être rendues obsolètes puis supprimées.
- [2] Soit sous la forme d'une annotation
kubectl.kubernetes.io/last-applied-configurationdans le cas de kubectl, soit sous la forme d'un ConfigMap ou d'un Secret dans le cas de Helm. - [3] Si, comme moi, vous vous méfiez des scripts trouvés au hasard d'un article de blog, téléchargez la dernière version adaptée à votre plateforme et décompressez-la à l'endroit de votre choix.
- [4] À ce sujet, l'article de David Schweikert Kubernetes 1.16 API deprecations and changed defaults est une excellente lecture.
Références complémentaires :
- Kube-No-Trouble — dépôt GitHub de kubent — https://github.com/doitintl/kube-no-trouble
- Deprecated APIs Removed In 1.16: Here's What You Need To Know, article de Vallery Lancey — https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/