Un cluster Kubernetes infogéré sur le Stack Harbor PaaS s’installe depuis le Marketplace, catégorie Clusters. L’installeur vous guide à travers topologie, contrôleur d’ingress, stockage et observabilité optionnelle — il provisionne le cluster, joint les nœuds control-plane et workers, et exécute une vérification de santé avant de vous rendre la main.
Cette page décrit chaque option pour vous permettre de choisir la bonne forme du premier coup.
Ouvrir l’installeur
Ouvrez le Marketplace du tableau de bord, passez à Clusters, et choisissez Kubernetes Cluster (utilisez la recherche si non en première page). L’installeur s’ouvre dans une boîte. Les champs ci-dessous apparaissent à peu près dans l’ordre des invites.
Version
Le menu liste les versions mineures de Kubernetes que le paquet de la plateforme supporte actuellement. Le paquet est typiquement une ou deux mineures derrière la pointe amont, donc la plus récente entrée du menu est la plus récente livrée ici, pas la plus récente sur github.com/kubernetes/kubernetes.
Si vous bâtissez du neuf, prenez la version la plus élevée listée. Si vous alignez sur une flotte qui tourne une version plus ancienne, prenez la mineure correspondante.
La version Kubernetes peut être mise à niveau plus tard — voir Mise à niveau Kubernetes — donc ce choix n’est pas définitif, mais une mise à niveau mineure est une vraie opération, pas un clic.
Dashboard
Deux distributions de Kubernetes-Dashboard sont supportées :
- v2 — le Kubernetes Dashboard amont standard. Choix par défaut.
- Skooner — un dashboard alternatif avec une UX différente. Certaines métriques de Skooner ne s’affichent pas correctement quand le contrôleur d’ingress HAProxy est sélectionné.
Topologie
Deux formes pré-cuites :
- Development — un nœud control-plane et un ou plusieurs nœuds workers évolutifs horizontalement. Le control-plane unique est un point de défaillance unique. À utiliser pour développement, outillage interne ou charges non critiques.
- Production — trois nœuds control-plane derrière deux ou plus répartiteurs d’API, avec deux ou plus nœuds workers évolutifs horizontalement. C’est la topologie à utiliser pour de vraies charges.
La topologie development est peu coûteuse et rapide à provisionner ; la topologie production survit à la perte d’un control-plane. La consigne de l’installeur est franche : la topologie development n’est pas recommandée pour la production car un seul control-plane ne peut pas gérer une vraie charge de façon fiable.
Contrôleur d’ingress
Trois contrôleurs d’ingress livrés en standard :
- NGINX — défaut recommandé. Le plus flexible des trois ; la surface d’annotations la plus large et la documentation la plus mature.
- Traefik — empreinte mémoire plus petite, bons défauts, configuration plus concise.
- HAProxy — haute performance, à utiliser quand le comportement de NGINX ne colle pas au modèle de routage.
Le choix colle : le sélecteur à l’installation ne permet pas de basculer plus tard depuis le module de gestion. Un changement après installation est possible mais manuel — le support Stack Harbor peut aider si vous devez le faire.
Deployment
Deux options pour le contenu initial du cluster :
- Cluster propre avec un exemple
HelloWorldpré-déployé. Utile pour vérifier ingress, DNS et dashboard de bout en bout au premier démarrage. - Custom chart Helm ou commande shell. Permet de pointer l’installeur vers un chart Helm ou un script qui amorce votre application directement dans le cluster.
Pour la plupart des équipes, Cluster propre est le bon choix — séparez le provisionnement du cluster du provisionnement de l’application pour que les échecs de l’un ne bloquent pas l’autre.
Stockage NFS
Activez NFS Storage pour attacher un palier de stockage NFS dédié avec provisionnement dynamique de volumes. Cela ajoute une StorageClass que les pods peuvent demander via PersistentVolumeClaim sans configuration manuelle de provisionneur.
Désactivez si vous comptez enregistrer votre propre storage class (par exemple un pilote CSI de fournisseur cloud). Le faire depuis zéro exige une vraie connaissance de Kubernetes — la plateforme n’intermédie pas.
Modules
Trois modules optionnels également installables plus tard via le panneau Add-Ons du palier Master :
- Prometheus & Grafana — pile d’observabilité empaquetée. Recommandé. Alloue environ 5 Go de stockage persistant et 500 Mo de RAM.
- Jaeger Tracing — opérateur et collecteur de tracing distribué.
- Remote API Access — nécessaire pour
kubectldepuis un poste local (voir accès au cluster). Recommandé si quelqu’un de l’équipe travaille hors du tableau de bord.
Environnement
- Environment — le nom interne d’environnement. Non modifiable plus tard ; apparaît dans les noms DNS.
- Display Name — alias d’affichage dans le tableau de bord.
- Region — la région plateforme pour le cluster, si plus d’une est disponible.
Installer
Cliquez sur Install. La plateforme provisionne les conteneurs sous-jacents, joint le control-plane, applique le CNI, installe le contrôleur d’ingress choisi et les modules optionnels, puis exécute une vérification de santé. Le flot complet est automatisé et prend typiquement quelques minutes pour la topologie development, plus longtemps pour production.
À la fin de l’installeur, la fenêtre de succès expose :
- L’URL du Kubernetes Dashboard et le jeton d’amorçage.
- L’URL de la Remote API (si activée).
- L’URL de l’application exemple (si un cluster propre avec exemple a été choisi).
Les mêmes informations sont envoyées au propriétaire du compte par courriel — conservez ce courriel jusqu’à ce que les identifiants soient stockés ailleurs de manière fiable.