Débuter avec Kubernetes

Le système d'exploitation du Cloud

a marqué ce sujet comme résolu.

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :

Merci d’avance pour vos commentaires.


Je viens d’ajouter une section au dernier chapitre pour expliquer comment fonctionnent les requêtes et les limites de ressources.

Avant de passer au chapitre sur les services, je vais ajouter un nouveau chapitre dans lequel on adapte le serveur HTTP pour que kubernetes soit capable de le sonder, et donc déterminer quand il est prêt ou pas à répondre à des requêtes et aussi comment on fait passer ce serveur à l’échelle en faisant varier son nombre instances.

Ça nous permettra d’expliquer en détail la stratégie de rolling upgrade que Kubernetes applique avec les deployments.

+0 -0

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :

Merci d’avance pour vos commentaires.


Juste pour ne pas perdre le rythme, malgré le peu de temps dispo que j’ai à consacrer à ce tuto ce week-end, je suis rapidement repassé sur le tuto en rajoutant des liens vers les docs pour encourager les lecteurs qui veulent creuser les sujets dont on parle.

J’ai aussi entamé un second chapitre sur les deployments, en montrant comment on configure les sondes de liveness et de readiness pour un serveur HTTP. Reste à écrire dans ce chapitre :

  • Montrer qu’il faut faire attention avec ces sondes, parce qu’un excès de zèle peut entraîner un système qui se casse la gueule par réaction en chaîne (là où on cherche plutôt à se servir de ces sondes pour garantir une disponibilité et une qualité de service constants),
  • Montrer comment on scale un déploiement (facile),
  • Illustrer l’algorithme de rolling upgrade qui est utilisé par les deployments quand on les met à jour.
+0 -0

Hello,

Hier soir j’ai suivi le tutoriel et voici quelques notes prises en cours de route, en espérant que cela te soit utile.

Le « Cloud »

J’apprécie énormément le rappel sur le cloud que tu as rédigée en préambule, dans la section Le « système d’exploitation du cloud » ?.

Podman vs. Docker

J’ai suivi l’intégralité du tutorial avec podman plutôt que docker. Sous mon système (Fedora), docker n’est qu’un alias pour podman de toute façon :

% docker pull alpine:latest
Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
Resolved "alpine" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull docker.io/library/alpine:latest...

Rien à signaler, je n’ai aucun souci à signaler en prenant podman plutôt que docker.

Kubernetes Provider

Je n’ai pas utilisé l’offre gratuite d’Oketo proposée dans le tutoriel mais j’ai opté pour Linode. La mise en place reste simple : télécharger un fichier YAML depuis l’interface d’administration et régler la variable qui va bien avant d’utiliser kubectl :

export KUBECONFIG=/path/to/mon-kubeconfig.yaml
kubectl get nodes
...

Ton tutoriel n’en fait pas mention, car je suppose que le lien d’Oketo que tu mets s’en charge. Mais je pense qu’un petit paragraphe pour expliquer la méthode « générique » ne serait pas superflu, mais c’est en supposant que le système soit effectivement similaire quelque soit le Kubernetes Provider : télécharger un YAML et mettre la variable KUBECONFIG à la bonne valeur. Si ce n’est que ça, je pense que le tuto gagnerait à le préciser pour gagner en généricité ;)

Hello Kubernetes

Petit détail, à un moment tu dis :

Kubernetes a assigné ce pod à un noeud (une machine) appelé lke24990-et-des-brouettes. Cela signifie qu’il trouvé une machine disponible pour faire tourner notre conteneur et l’a sélectionné tout seul.

Je crois que le préfixe lke est spécifique à Linode (Linode Kubernetes Engine), n’est-ce pas ? Avec un autre fournisseur, on aurait une autre nomenclature ?

Pod vs. container

Je pense avoir compris du premier coup la distinction entre pod et container avec ton explication. Pourtant, il est vrai que je ne voyais pas la différence au début ^^

Repo Dockerhub

Sur ma version, j’ai dû rendre explicite le repo que je voulais utiliser : docker login https://index.docker.io/v1/. Sans préciser cela en second argument, mon système prenait par défaut un repo de Fedora. Peut-être un truc à expliciter ? (sauf si c’est vraiment spécifique à mon système, je ne sais pas trop).

Tu proposes la commandes suivantes :

docker tag sgble/hello-k8s:stateless hello_server

Chez moi elle ne semble pas fonctionner. J’ai pu avancer en permutant les arguments comme cela :

docker tag hello_server sgble/hello-k8s:stateless

Est-ce seulement moi ou s’agit-il d’une coquille ?

Après tout ça, je n’ai pas de souci ;)

Bon courage pour la suite !

+1 -0

Salut. Merci pour ton retour !

J’apprécie énormément le rappel sur le cloud que tu as rédigée en préambule, dans la section Le « système d’exploitation du cloud » ?.

Merci. Il faut encore que j’ajoute un dernier paragraphe pour expliquer l’intérêt de Kubernetes par rapport aux offres PaaS qu’on voit un peu partout, mais je suis content que ce chapitre soit utile. :)

Rien à signaler, je n’ai aucun souci à signaler en prenant podman plutôt que docker.

Oui, la seule subtilité arrive quand on utilise un fournisseur avec une vieille infra. Historiquement, les vieilles infra K8S ne supportent que les images Docker et pas OCI. C’est le cas d’okteto qui n’arrive pas à lancer les conteneurs OCI, mais les fournisseurs comme Linode ou GKE n’ont aucun soucis avec ça.

Perso j’utilise aussi podman au quotidien. :)

Ton tutoriel n’en fait pas mention, car je suppose que le lien d’Oketo que tu mets s’en charge. Mais je pense qu’un petit paragraphe pour expliquer la méthode « générique » ne serait pas superflu, mais c’est en supposant que le système soit effectivement similaire quelque soit le Kubernetes Provider : télécharger un YAML et mettre la variable KUBECONFIG à la bonne valeur. Si ce n’est que ça, je pense que le tuto gagnerait à le préciser pour gagner en généricité ;)

En effet, je suis passé super rapidement sur ce chapitre en détaillant la seule offre 100% gratuite, mais je vais le compléter en parlant notamment de Linode, qui est vraiment super-clean au niveau de l’installation.

Les gros fournisseurs comme GKE ou EKS viennent généralement avec leur tooling à eux qui rajoute une petite couche de complexité sur le fichier kubeconfig (les credentials ne sont pas dans le fichier, kubernetes va plutôt faire appelle à gcloud, par exemple, pour lui déléguer l’authentification).

Je suis content de voir que tu aies utilisé Linode avec succès du premier coup parce que c’est l’offre que je compte conseiller en "deuxième position", donc ça confirme un peu ce que je ressentais.

Je crois que le préfixe lke est spécifique à Linode (Linode Kubernetes Engine), n’est-ce pas ? Avec un autre fournisseur, on aurait une autre nomenclature ?

Absolument. Sur GKE et Okteto, le préfixe serait gke-. Je n’ai pas essayé avec d’autres fournisseurs, mais la nomenclature dépend complètement du provider.

Sur ma version, j’ai dû rendre explicite le repo que je voulais utiliser : docker login https://index.docker.io/v1/. Sans préciser cela en second argument, mon système prenait par défaut un repo de Fedora. Peut-être un truc à expliciter ? (sauf si c’est vraiment spécifique à mon système, je ne sais pas trop).

Il va falloir que je réessaye plus sérieusement avec docker ET podman. C’est très possible !

Edit: Dans tous les cas ça ne peut pas faire de mal de spécifier explicitement le registry auquel on se connecte.

Est-ce seulement moi ou s’agit-il d’une coquille ?

C’est très certainement une coquille. Je vais vérifier et corriger ça.

Merci encore pour ton retour ! :)

Edit: je confirme, c’est une coquille de ma part:

$ podman tag -h
Add an additional name to a local image

Description:
  Adds one or more additional names to locally-stored image.

Usage:
  podman tag IMAGE TARGET_NAME [TARGET_NAME...]

Examples:
  podman tag 0e3bbc2 fedora:latest
  podman tag imageID:latest myNewImage:newTag
  podman tag httpd myregistryhost:5000/fedora/httpd:v2

$ docker tag -h
Flag shorthand -h has been deprecated, please use --help

Usage:  docker tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG]

Create a tag TARGET_IMAGE that refers to SOURCE_IMAGE
+0 -0

@nohar As-tu besoin de plus de retours ? Comptes-tu continuer ce tutoriel ?

Je ne veux pas me montrer trop "pressant", c’est juste que je trouverais ça dommage que le travail que tu as déjà investi dans ce tuto ne soit jamais publié ou devienne obsolète avant d’être publié.

Kubernetes est l’une des technologies "hypes" du moment mais aussi que beaucoup de gens ne comprennent pas vraiment donc je trouve ça top d’avoir un tutoriel sur ZdS pour clarifier tout ça, surtout avec une vraie expérience pratique.

Salut.

Je vais reprendre l’écriture de ce tuto, c’est simplement que je manque énormément de temps en ce moment étant donné que j’ai un nourrisson à m’occuper depuis maintenant deux mois.

Mais effectivement, je compte bien continuer la rédaction ce tutoriel (parmi tous ceux que j’ai sur le feu, c’est celui-ci qui a la priorité car c’est lui qui a la plus grande valeur ajoutée).

PS : je ne dirais jamais non à plus de retours sur ce qui est déjà écrit. ^^

+7 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte