Qu’est-ce que le tableau de bord Kubernetes et ses alternatives

Qu’est-ce que le tableau de bord Kubernetes

Kubernetes fournit un composant de ligne de commande (CLI) appelé « kubectl » pour effectuer les opérations de base. Mais il existe deux obstacles importants à l’utilisation de la CLI à l’échelle de l’entreprise

• La courbe d’apprentissage élevée pour que les développeurs adoptent Kubernetes pour le déploiement.
• Travail chronophage et frustrant pour les équipes SRE et Ops pour surveiller et dépanner plusieurs clusters à grande échelle

Dashboard by Kubernetes (également connu sous le nom de Kubernetes Dashboard) est une interface utilisateur Web permettant de déployer des applications dans le cluster Kubernetes, de surveiller la santé de toutes les ressources et de les dépanner en cas de problème. L’application est utile pour les équipes DevOps, Ops et SRE pour gérer les ressources Kubernetes telles que les déploiements, les ensembles d’états, les travaux, etc. On peut rapidement déployer une application à l’aide de fichiers manifestes et mettre à jour l’aide à partir de l’interface utilisateur elle-même.

Fonctionnalités du tableau de bord Kubernetes

Le tableau de bord Kubernetes est convaincant pour l’équipe DevOps en raison de deux fonctionnalités principales :

• Visibilité et dépannage à l’échelle du cluster
• Déploiements basés sur l’interface utilisateur

Visibilité et dépannage à l’échelle du cluster

Le tableau de bord Kubernetes fournira une vue des différentes charges de travail en cours d’exécution et de leur nombre total. Les ingénieurs DevOps obtiendront la visibilité des charges de travail, des services, des configurations et du stockage, ainsi que la vue du cluster.

Affichage de la charge de travail

Sous la vue de la charge de travail, les utilisateurs obtiendront les détails des ressources de charge de travail telles que les déploiements, les pods, les ReplicaSets, les DaemonSets, les tâches et les StatefulSet exécutés dans tous les espaces de noms d’un cluster. On peut également effectuer une recherche granulaire basée sur un espace de noms particulier dans un cluster.

Affichage des modules

L’un des aspects les plus importants des charges de travail peut être le nombre de pods exécutés dans un nœud spécifique et son espace de noms respectif.

Les utilisateurs obtiendront des informations détaillées sur un pod, telles que :

• Métadonnées sur les étiquettes et les annotations
• Consommation de ressources – Utilisation du processeur et de la mémoire
• Date de création et nombre de redémarrages
• Journaux d’événements et réclamation de volume persistant

De même, Kubernetes Dashboard fournit une vue agrégée des espaces de noms et une vue détaillée des services et des objets d’entrée, des configmaps, des politiques réseau, des secrets et des revendications de volume persistant dans un espace de noms.

Vue de service et d’entrée

Le tableau de bord Kubernetes offre une visibilité sur l’exécution des objets Services et Ingress, y compris l’espace de noms auquel appartient chaque service ou entrée, leurs étiquettes et l’adresse IP du cluster. Les utilisateurs peuvent obtenir des informations beaucoup plus détaillées sur chaque service, telles que les étiquettes, les pods, les points de terminaison, etc.

Vue de configuration et de stockage

Semblable à toute autre vue d’objet, le tableau de bord Kubernetes permet les détails des revendications de volume persistant (PCV) dans un cluster ainsi que leur état, volume de stockage, classe de stockage, annotations, étiquettes, espaces de noms, etc. Le tableau de bord affiche également les configurations du applications déployées dans le cluster, qui peuvent être modifiées directement à partir de l’interface utilisateur.

Déploiement basé sur l’interface utilisateur

Le tableau de bord Kubernetes vous permet de déployer toutes les ressources (charge de travail) à partir de l’interface utilisateur. Vous pouvez créer des fichiers manifestes dans le navigateur ou télécharger vos fichiers manifestes à partir d’une source telle que Git. Et le tableau de bord Kubernetes communiquera directement avec le contrôleur Kubernetes pour obtenir un objet d’une ressource créée pour vous. Dans l’exemple ci-dessous, nous avons créé un fichier manifeste pour créer un pod avec l’image NGINX 1.19.0 pour créer un pod.

Architecture de tableau de bord Kubernetes

Kubernetes Dashboard est un service externe développé au-dessus de l’architecture Kubernetes. Sous le capot, le tableau de bord utilise des API pour lire toutes les informations à l’échelle du cluster pour une visibilité dans un seul volet. Il utilise également les API pour déployer des ressources et des applications dans un cluster. Les tableaux de bord CLI et Kubernetes dépendent du serveur kube-API pour traiter les requêtes. Pour démarrer avec la CLI, l’équipe Ops doit déployer le tableau de bord Kubernetes dans le même cluster (similaire au déploiement de Kubectl).

Premiers pas avec le tableau de bord Kubernetes

Pour démarrer avec Kubernetes Dashboard, vous devez exécuter les commandes suivantes dans votre cluster :

Étape 1 : Déployer le tableau de bord Kubernetes

Exécutez la commande ci-dessous pour déployer l’application Kubernetes Dashboard

kubectl apply -fhttps://raw.githubusercontent.com/kubernetes/dashboard/v2.3.1/aio/deploy/recommended.yaml

Pour accéder au tableau de bord Kubernetes depuis la machine locale, on peut créer un canal sécurisé pour accéder au cluster K8s en exécutant la commande suivante :

Vous pouvez accéder à votre tableau de bord à l’aide de l’URL suivante :

http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

Étape 2 : Créer un compte de service

Le tableau de bord Kubernetes est installé avec des autorisations RBAC minimales, vous pouvez donc accéder au tableau de bord à l’aide d’un jeton de support. Vous pouvez donc créer un compte de service et le lier à un cluster avec des droits d’administrateur. Vous pouvez utiliser le fichier YAML de compte de service suivant :

apiVersion: v1kind: ServiceAccountmetadata:  name: admin-user  namespace: kubernetes-dashboard

Créez des ressources de service à l’aide de la commande :

kubectl - apply -f <<serviceaccount.yaml>>

Vous pouvez utiliser le ClusterRoleBinding YAML suivant pour créer le compte de service cluster-admin:

apiVersion: v1kind: ClusterRoleBindingmetadata:  name: admin-userroleRef:  apiGroup: rbac.authorization.k8s.io  kind: ClusterRole  name: cluster-adminsubjects:  kind: ServiceAccount  name: admin-user  namespace: kubernetes-dashboard

De même, appliquez le fichier YAML pour créer une ressource ClusterRoleBinding dans votre cluster.

Étape 3 : Générer un jeton de support

Utilisez la commande pour générer le jeton du porteur

kubectl -n kubernetes-dashboard get secret $(kubectl -n kubernetes-dashboard get sa/admin-user -o jsonpath="{.secrets[0].name}") -o go-template="{{.data.token | Base64decode}}"

Étape 4 : Utiliser le jeton et démarrer avec le tableau de bord

Vous pouvez coller le jeton du porteur pour démarrer avec le tableau de bord Kubernetes.

Limites du tableau de bord Kubernetes

L’utilisation d’un tableau de bord Kubernetes basé sur l’interface utilisateur pour remplacer la CLI est sans aucun doute une bonne chose. Cependant, il existe quelques limitations qui limitent ses cas d’utilisation aux seules petites startups :

1. Absence de vue multicluster : Le tableau de bord Kubernetes fournit la vue pertinente pour les espaces de noms dans un seul cluster. Il n’offre pas une vue de plusieurs clusters.
2. RBAC minimal : Kubernetes ne fournit pas de contrôle d’accès granulaire pour les différents utilisateurs. Il faut être dépendant du jeton ou kubeconfig des dossiers.
3. Absence d’authentification unique (SSO) : Kubernetes Dashboard ne fournit pas de services de connexion SSO. L’authentification unique est essentielle pour les moyennes et grandes entreprises afin de sécuriser les ressources et les applications dans Kubernetes.
4. Pas de gestion de nœud : L’équipe Kubernetes Dashboard DevOps pour afficher les informations sur les nœuds telles que l’état, les étiquettes, les limites, les demandes de mémoire/CPU, l’ID de la machine, les adresses, les ressources allouées, les pods, etc. Mais n’autorise aucune disposition pour modifier les nœuds. Ceci est essentiel car si un nœud n’est pas sain, il n’exécutera aucun pod et ne participera pas à l’activité du cluster.
5. Aucune visibilité et gérabilité des graphiques HELM : De nombreuses organisations les utilisent pour déployer leurs applications Kubernetes à grande échelle. Malheureusement, le tableau de bord Kubernetes ne fournit pas la capacité aux tableaux de bord HELM.
6. Absence de vue de l’application : Le tableau de bord Kubernetes fournit la vue des ressources ou des objets, mais a besoin de plus d’informations sur les applications, ce qui complique la modification des déploiements par les développeurs. Sans vue d’application, Kubernetes Dashboard a limité son utilisation à l’équipe Ops uniquement.
7. Audit: Kubernetes Dashboard ne propose pas de rapports d’audit des déploiements, tels que qui, quand et comment une application est déployée.

Notez que bien que le tableau de bord Kubernetes soit également développé pour faciliter le déploiement à partir de l’interface utilisateur, il n’existe aujourd’hui aucun mécanisme pour appliquer des stratégies de déploiement avancées telles que Canary à partir de l’interface utilisateur.

Alternatives open source aux tableaux de bord Kubernetes

Il existe quatre alternatives open source au tableau de bord Kubernetes, construites indépendamment ou au-dessus du projet Dashboard, pour augmenter la capacité de déploiement, de surveillance et de dépannage à partir de l’interface utilisateur.

1. Tableau de bord Devtron Kubernetes :

Devtron fournit une plate-forme DevOps open source native de Kubernetes qui automatise l’ensemble du processus de livraison de logiciels à partir de CI, CD, GitOps, sécurité et gouvernance, déploiement progressif, observabilité, surveillance et dépannage. Le tableau de bord Devtron Kubernetes fournit des fonctionnalités puissantes dans un seul volet pour simplifier la vie des DevOps, des SRE et des développeurs :

2. OpenLens :

Un logiciel open source avec une licence MIT est utilisé pour la gestion multicluster et la surveillance des charges de travail. Il fournit également une gestion de base des ressources HELM et un regroupement des ressources, mais cela peut nécessiter une courbe d’apprentissage. Deuxièmement, il a quelques angles morts car il ne fournit pas de groupes de graphiques HELM pour les déploiements multicluster, les différences de configuration de graphique, etc.

3. Octante :

Tableau de bord open source démarré par VMware mais archivé maintenant – pas de support communautaire et vous êtes seul. Initialement, le projet visait à ce que les développeurs utilisent l’interface utilisateur pour expédier le code plus rapidement dans les clusters. Octane a des fonctionnalités limitées en ce qui concerne la visualisation et la gestion des clusters.

Comparaison tabulaire

Tableau de bord Vanilla Kubernetes vs Tableau de bord Devtron Kubernetes vs OpenLens.

Gestion des clusters et des ressources