Gestion Kubernetes
Kubernetes s'est imposé comme le standard de facto pour l'orchestration des conteneurs, permettant d'automatiser le déploiement, la mise à l'échelle et la gestion d'applications conteneurisées à grande échelle.
Notre service Kubernetes dans le nouveau portail Cloud Services vous offre un environnement Kubernetes puissant et géré. Concrètement, nous prenons en charge la configuration, la maintenance et la gestion complexes du Control Plane Kubernetes (Master Nodes), ce qui vous permet de vous concentrer pleinement sur le développement et l'exploitation de vos applications.
Ce service est intégré de manière transparente à notre portail et s'appuie sur l'infrastructure robuste d'OpenStack et de Gardener pour le provisionnement des Worker Nodes. Profitez en outre d'une intégration simple avec d'autres services du portail, comme notre stockage objet compatible S3 et le service de sauvegarde centralisé.
Le service s'adresse aux développeurs, aux équipes DevOps et aux administrateurs système qui recherchent une plateforme évolutive, fiable et simple à gérer pour leurs charges de travail conteneurisées.
Cette documentation vous guide à travers toutes les étapes nécessaires : des prérequis à la création et à la configuration de votre premier cluster, jusqu'à l'administration quotidienne et à la mise à l'échelle. Nous expliquons les fonctionnalités et options spécifiques dont vous disposez dans notre Cloud Portal.
Sous le capot
Notre service Kubernetes repose sur Gardener, qui gère le control plane de votre cluster sur un Seed cluster partagé, tandis que vos worker nodes s'exécutent dans OpenStack. Vous pouvez créer des clusters dans les deux régions (ch-zh1 Zurich et ch-ge1 Genève).
Architecture Gardener : concept Seed & Shoot, multi-région, control plane vs data plane.
Kubernetes LoadBalancer et Octavia : comment les services type: LoadBalancer créent des load balancers Octavia dans OpenStack.
Prérequis
Ces prérequis sont nécessaires pour créer un cluster Kubernetes dans le Cloud Services Portal.
- Un compte valide dans le Cloud Services Portal.
- Les permissions/rôles requis dans le portail pour créer des clusters Kubernetes.
- Un quota suffisant (vCPU/vRAM/Storage) pour la création.
- Le cas échéant, des outils locaux (kubectl, k9s ...).
Premiers pas

Nous vous proposons deux options pour créer votre cluster Kubernetes dans notre Cloud Services Portal :
- Comme nouveau projet
- Dans un projet existant
Création d'un cluster
Pour créer un cluster, un projet disposant d'un quota suffisant est indispensable. Le guide pas à pas part du principe que l'assistant crée un projet autonome. Pour un projet déjà existant, la sélection du nom et de la taille du projet est naturellement omise.
Pas à pas

Fondamentalement, l'assistant est très simple à utiliser et relativement clair avec les champs de formulaire pour créer un cluster.
-
Cluster Name -> Ne doit pas dépasser 10 caractères.
-
Purpose
- testing -> Pas de monitoring, pas de HA des composants du Kubernetes Controller.
- production -> Monitoring et HA des composants du Controller.
-
Image -> Vous pouvez définir ici la version de l'image Worker souhaitée. Une modification ultérieure n'est pas prise en charge.
-
Kube-Version -> Vous pouvez définir ici la version de Kubernetes requise. Une mise à niveau vers une version supérieure est possible ultérieurement, mais aucune rétrogradation.
-
Flavor -> Les flavors OpenStack possibles pour les Worker Nodes sont définies ici.
-
Zones -> La répartition des Worker Nodes entre nos différentes AZ est définie ici.
-
Worker Count -> Vous pouvez définir ici le nombre minimum et maximum de Workers. Notre service peut détecter des pics de charge et provisionner en conséquence davantage de Workers/ressources pour le cluster.
Note
Veuillez noter que ce processus peut prendre jusqu'à 10 minutes selon le nombre de workers.
Une fois le cluster créé, il apparaît dans la liste :

Accès au cluster
Une fois le cluster Kubernetes créé et en état sain, vous pouvez générer une configuration admin ainsi qu'une configuration viewer.


Warning
Veuillez noter que ces identifiants d'accès ne sont valables que 24 heures pour des raisons de sécurité, indépendamment du nombre de jours indiqué dans le champ !
Utiliser la configuration Kubernetes avec Kubectl
Après le téléchargement, vous recevez un fichier YAML qui ressemble à ceci :
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUQ1akNDQWs2Z0F3SUJBZ0lRSlRoRUhBWjlrMzJMZDlnQWg5bFhGREFOQmdrcWhraUc5dzBCQVFzRkFEQU4KTVFzd0NRWURWUVFERXdKallUQWVGdzB5TlRBME1UUXhNRFExTVRsYUZ3MHpOVEEwTVRReE1EUTJNVGxhTUEweApDekFKQmdOVkJBTVRBbU5oTUlJQm9qQU5CZ2txaGtpRzl3MEJBUUVGQUFPQ0FZOEFNSUlCaWdLQ0FZRUE0aEU1CmpQUHZFNDFiUnNuUHV5a0J2WkthR3ovTWJKa3Ewb0liQzlVVlVYTW1EV0hqeWpjeHdLK0haZ2NSNG1VY0VseXQKVVk1dSt1UGF1SlpFQjk3a3hCRTY0U2h4WFdDK0VReDJzNHZBdFhjVkxadFdyTGJ4cjNrVnY4ZjUxY280SWpoOApJOGZmVk51cDVvbmpia0ZqWTQwQjg2c0gzeUg3OUoyWVEyWC9zUTZrajhDVEVxUFRRZGcvNGZ3Ymh5WUpRQVpqCjQwbHZWTTVCcndPVm1KMDEzZkkyNVlmME15dDJuUjRlMGo2TVlVZEhxclFScjh2bStXc1BzbHN0M1YzdE02YWcKQ0p3NU40VXlrSDZRUVNRcmdLS0ZmNmMrbVJNT0VIWS9WZGVack5SWWtIQmVZY2x0OVIxTkMzK3hjK2ZaM3ZyeAp5ZVFsS3NzV0x1Ly8yTElVWVlCbE5FWDhadzhuRW9Id3Q5OEZkQTN4ZHRHdXJkcGJ6MHFNZVVRK1VtblZPWTRLCldpTlR6WHkvVlpLVFFmWkFER1dJdVZxUFAxVnh0Z2I5d2tscjhRd28xVFljV25aMFRML3JLa3gvemNYK1pGbW8KbXVseUg2OTl6ZnZpdFBkWWdLT0c5MVl0Q2grM1F2bmlxbEFIUy9BZjRYL2F4Z2dsbWYwZURUaXVXMFhwQWdNQgpBQUdqUWpCQU1BNEdBMVVkRHdFQi93UUVBd0lCcGpBUEJnTlZIUk1CQWY4RUJUQURBUUgvTUIwR0ExVWREZ1FXCkJCU3hIYm9seTV4NFJXbS9aeW1ibENndllrL3d4ekFOQmdrcWhraUc5dzBCQVFzRkFBT0NBWUVBS0FIL0RBRlUKZ0Jibm5zV3JRVWppMVYxajVWNW5TWHM3K2JCT2MxSVdqT3VjSDVhc3Y3OGlHaC9WV21pblFwS0ZPNTAwWFREMgp3T29ubVN1dE9sLzFpa0E1M29Mb25TdU9JWG5vdXYzVFc2SUo1WExsT3k4QU1FY0FrQy9KN2NrdS9CZUJ1QTMvClJ2eU51U1RpN2p5S1l4WnhXZDRzYnNESkZ1Qi9ycFBhSmtEcTZYRTFCTWJOeUd2UTduZDJucXhINDBCaWtiZ2MKOEpuTjFRb2N3b25WSFR2YWtkZGtUa1E2emgraDlMcUJBdy9UR0pvdmJRM1o1bFJJUDBqdGFXVnVrNlovK3k2RApIZWdDZkMraWlOOTVpalVrY25nMkZMVE9wSm5BdHloRnNtUlFKSjM3cGZhcWxrMXNPeHoyUUIxaGpMOHRveHNTCmJwbkZURW5tclQwc29uQjhUZXgzSzlrT2FrcGVuQXZ3cG1OQXhCd2RodHpyRFdUSnAzUmx4S2F0NENLR2U0R0kKVjFrSEVkczN6RjFJK0VjOW5obXVxcEViNEdXbzNsVTJMVllwSnBscnd3QnhFbHU1TzN4b0IxM1hTME96TittTgpmdWpNemZNakkzazBpODd5cVFlRm5kcVQ4ZjJhVFFieVovYWNLdVNGTDRzV0xQTWtmTDFoQWVBOAotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
server: https://api.kc-6iizv1z.ew5cmpb.gardener.ewcs.ch
name: garden-8586188f435346b4af787015734ef963--kc-6iizv1z-external
- Le nom correspond au nom du cluster + rôle.
Sur votre client
Vous pouvez désormais copier ce fichier YAML vers
/home/[user]/.kube/config
Ou définir un export qui référence ce YAML :
export KUBECONFIG=/tmp/kubeconfig-kv-6iiuvlz-admin.yml
Exemple
Vous pouvez maintenant interroger facilement le cluster à l'aide de l'outil en ligne de commande kubectl :
root@kube-trial:~/# kubectl get nodes
NAME STATUS ROLES AGE VERSION
shoot--ew5cmpb--kc-6iizv1z-default-worker-z1-5c69c-mpnzr Ready <none> 84m v1.31.3
Dans ce cas, le cluster ne dispose que d'un seul Worker Node.
Modifier le cluster
Vous accédez au formulaire de mise à jour via le menu déroulant :

Les options suivantes sont disponibles ici :
- Mettre à jour la version de Kubernetes
- Faire passer le Purpose de
TestingàProduction
Note
Selon l'historique, vous vous trouvez peut-être déjà en statut Production.
Veuillez noter qu'il n'est pas possible de revenir au statut testing, car
cela n'est techniquement pas possible.
Il en va de même pour la version Kubernetes du cluster ; si vous avez déjà sélectionné la version la plus récente, aucune version plus récente ne vous sera proposée. Nous nous efforçons toujours de vous fournir les dernières versions de Kubernetes.
Warning
Veuillez noter que les modifications apportées au Purpose ou à la version déclenchent une opération majeure sur le cluster et nécessitent donc du temps.
Worker Nodes
Vos workers peuvent être gérés via le menu déroulant Worker-Groups.

- Seul le nombre des Worker-Groups existantes peut être modifié.
- Si vous souhaitez une répartition sur plusieurs AZ, vous devez créer un nouveau Worker-Group et éventuellement supprimer l'ancien.
Créer un nouveau Worker-Group
Le bouton [Create worker group]{.title-ref} ouvre le formulaire suivant pour définir un nouveau Worker-Group.

- Ici, comme dans le formulaire initial, vous pouvez définir des Worker-Groups supplémentaires pour votre cluster Kubernetes.
Note
Ici aussi, le quota du projet doit être respecté, car il ne peut pas être dépassé, ce qui pourrait entraîner une erreur lors de la création des Worker-Nodes. Veuillez consulter l'onglet Notifications.
Worker Groups dans Kubectl
root@kube-trial:~/.kube# kubectl get nodes
NAME STATUS ROLES AGE VERSION
shoot--ew5cmpb--kc-6iizv1z-default-worker-z1-5c69c-mpnzr Ready <none> 127m v1.31.3
shoot--ew5cmpb--kc-6iizv1z-test-z1-5cc9c-wb2zf Ready <none> 2m2s v1.31.3
- Les Worker-Groups se distinguent par leur nom.
Supprimer un Worker-Group
Vous pouvez supprimer les Worker Groups existants jusqu'à en conserver un seul, afin que le cluster reste fonctionnel.
Warning
Selon le déploiement et la définition de l'affinité des worker nodes, il peut arriver qu'un de vos Worker-Groups ne puisse pas être supprimé, car cela compromettrait sinon l'intégrité de votre déploiement.
La suppression des Groups est lancée via le bouton [Delete it]{.title-ref}.
Note
Veuillez noter que ce processus nécessite également du temps, car les Nodes doivent être « drained » et les Pods déplacés.
Supprimer le cluster
La suppression du cluster est tout aussi simple que celle des Worker-Groups ; l'ensemble du cluster peut être supprimé via le menu déroulant de la page Cluster Management.
Prérequis pour supprimer un cluster :
Warning
Les clusters sur lesquels des déploiements sont encore en cours ne peuvent pas être supprimés !!!