Pour interagir avec le cluster, on discute avec l'APIServer.
Il s'agit d'une API (webservice), il nous faut donc les choses suivantes :
- Un client
- L'URL de l'APIServer
- Des informations d'authentification
Toutes ces informations sont en général regroupées au sein d'un fichier kubeconfig. La convention est de placer le fichier kubeconfig dans ~/.kube/config.
Bien qu'il soit possible de construire soi-même les requêtes HTTP à envoyer à l'APIServer, il est bien plus simple et efficace d'utiliser un client qui génèrera et exécutera les requêtes pour nous.
Le client de référence, en ligne de commande (CLI) est kubectl. C'est le plus complet et le plus utilisé. Il est écrit en go et, comme tous les programmes go, il est packagé dans un binaire unique ce qui simplifie son installation : il suffit de télécharger le binaire (kubectl.exe sous windows, kubectl sous mac / linux) et de le placer dans le PATH de votre système d'exploitation.
Il existe plein d'autres clients pour Kubernetes dont voici quelques exemples :
- k9s, un compromis agréable entre un outil
CLIet un client lourd. - lens, un client lourd offrant de multiples fonctionnalités (à noter la version 100% libre OpenLens)
- le public Kubernetes pour vscode qui contient un client très simple en plus de nombreux outils (aide à la complétion, linter ...)
Le client a besoin de connaitre l'URL de l'APIServer. Par défaut, si on ne lui donne pas, il tente d'interroger localhost:8080 ce qui ne marche en général pas.
On peut lui faire communiquer avec n'importe lequel des controlplanes vu qu'ils sont tous en communication.
A noter : l'APIServer est forcément exposée en HTTPS et peut, en fonction de l'installation, avoir un certificat auto-signé. Dans ce cas il faut soit ajouter le certificat public dans le fichier kubeconfig afin que kubectl accepte le certificat ou utiliser l'option --insecure-skip-tls-verify pour désactiver la vérification du certificat de l'APIServer.
Interroger l'APIServer sans authentification abouti en général à une erreur 403 Forbidden. L'APIServer accepte, en fonction de sa configuration, différents modes d'authentification dont les jetons (token) et les certificats clients.
En général après l'installation (on-premise ou via un cloud provider) on obtient un token correspondant à un compte root avec les droits cluster-admin.
Il est évidemment conseillé de ne pas utiliser ce compte en régime courant et de privilégier la création de comptes de service (service accounts) à plus faibles privilèges en utilisant le système RBAC de Kubernetes.
A noter : il est aussi possible sur certaines installation de Kubernetes de brancher un système d'authentification déléguée en branchant un fournisseur compatible openidconnect. L'APIServer est alors capable de valider des jetons fournis par une autre autorité (google, github, gitlab ...). L'un des fournisseurs d'identité les plus connu est Keycloak.
Une fois kubectl installé et le fichier kubeconfig placé au bon endroit (~/.kube/config), il est possible de commencer à communiquer avec le cluster.
La commande kubectl get nodes permet de tester la bonne installation et renvoit la liste des noeuds avoir leur version. C'est une opération à haut niveau de droits. Dans le cas où le compte utilisé n'a pas de droits élevés, on peut se contenter de kubectl version. Si la Server version est affichée alors la communication avec l'APIServer est bonne.
La suite logique à ce tutoriel est le déploiement d'une première application sur le cluster : Mon premier déploiement.