Avis d’expert : Il y a les bons et les mauvais Kubernetes

Kubernetes et l’orchestration de conteneurs sont des sujets qui font vibrer l’actualité.

La révolution des conteneurs apporte d’avantage de contrôle et de flexibilité dans la gestion des applications.
Forts de plusieurs années de mise en œuvre et d’exploitation, nous avons appris à identifier les erreurs, nous permettant de corriger rapidement les incidents.
Dans la plus part des cas, ces incidents d’exploitation et de sécurité sont liés aux fonctionnalités et à la configuration de Kubernetes.

La véritable question étant : quelle est la différence entre un bon et un mauvais Kubernetes ?
Le mauvais Kubernetes… Extrêmement simple ! Il voit un manifeste YAML, BIM !!! Il orchestre !
Et le bon kubernetes… Pareil ? Absolument pas !
Alors qu’est-ce qu’un bon Kubernetes ??

Le bon Kubernetes n’a pas de SPOF

Il est important d’installer le cluster Kubernetes en HA, c’est-à-dire avoir au minimum 3 masters.
Ainsi, les services vitaux comme l’API (porte d’entrée du cluster) et la base ETCD (base de données hébergeant l’état du cluster) sont redondés.
Plus d’inquiétude, le service sera alors garanti en cas d’arrêt d’une des machines – que ce soit une panne ou une maintenance planifiée.
De même il est recommandé d’avoir un système de stockage résilient et distribué qui peut être piloté via API comme Ceph pour le stockage des données des workloads.

Le bon Kubernetes se passe des registres externes

Oubliez les accès aux registres publiques comme Docker Hub ou gcr.io.
Un registre interne assurera une gestion plus simple pour les développeurs mais aussi sa disponibilité sans avoir d’accès à Internet.
Pour sécuriser vos déploiements et être autonome, il est vital de monter votre propre registry.

Le bon Kubernetes limite les Privilèges

Sur Kubernetes comme sur un système Linux, hors de question de donner l’accès root aux applications.
Et pourtant les conteneurs que vous allez déployer – surtout s’ils viennent d’un éditeur tierce – ne respecteront pas toujours cette règle.
Il est indispensable d’activer les PodSecurityPolicy pour adapter les droits et fonctionnalités des conteneurs.
Les PSP permettent de forcer l’exécution d’un Pod dans un contexte sécurisé.
Par exemple un Pod sans la capacité NET_BIND ne pourra pas ouvrir de ports en écoute sur le système hôte.

Le bon Kubernetes dispose d’un tableau de bord

Dernier point et sans doute le plus important : la partie Metrics, nécessaire au suivi d’exploitation.
Sans tableau de bord, il est difficile de suivre l’état de santé de votre cluster Kubernetes.
Grâce à Prometheus et Grafana il est possible de visualiser la consommation des ressources en temps réel et d’accéder à l’historique pour analyser l’origine d’un incident.
Vous pourrez aussi produire rapidement des reporting sur l’activité et le capa-planning de vos solutions.

Grâce à ces retours d’expérience, SUSE ne cesse de faire évoluer et d’améliorer en permanence l’offre Containers as a Service Platform (CaaSP) afin de vous faire bénéficier d’une solution d’infrastructure éprouvée et reconnue.

Découvrez tous nos articles sur SUSE CaaSP