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
