Exercice 1
Création d’un cluster
Exécutez gcloud config list puis kubectl version pour vérifier que vous êtes connectés au bon projet et que les utilitaires sont bien installés.
Connectez vous à l’interface graphique de la console de GCP pour Kubernetes Engine, activez l’API au besoin, et explorez les options s’offrant à vous, notamment pour la création de cluster et les valeurs par défaut. Pour ce laboratoire nous privilégierons l’utilitaire gcloud sdk. gcloud container clusters --help Pour créer un cluster Kubernetes utilisez la commande gcloud container clusters create test-kubernetes --image-type=cos. Ce cluster sera créé avec les paramètres par défaut tels qu’affichés dans l’interface graphique.
Kubectl est un utilitaire permettant d’interagir avec le plan de contrôle Kubernetes via la composante kube-apiserver. Exécutez kubectl --help. Pour obtenir des informations sur le cluster créé exécutez kubectl cluster-info.
En effet, nous n’avons pas spécifié à quel cluster connecter kubectl. Il se peut toutefois que la commande ait fonctionné implicitement en utilisant une forme d’authentification basique. Référez-vous au message d’avertissement généré lors de la création du cluster. La commande en question permet également de changer le cluster auquel nous sommes connectés. kubectl get nodes affiche les noeuds du cluster.
Mise en place d’une application
Créez et entrez dans le répertoire “kubetest” puis clonez le repo GitHub suivant: “https://github.com/matbilodeau/test-apache-kube”. La commande est git clone https://github.com/matbilodeau/test-apache-kube. Entrez dans ce répertoire et explorez le contenu.
Pour créer votre propre image
Construisez l’image à partir du fichier Dockerfile fourni avec un nom:tag conforme pour la publication vers votre repo puis publiez-la. Modifiez le fichier “apache-deployment.yaml” en conséquence. Continuez avec les instructions ci-dessous.
Pour utiliser une image publique
Kubernetes prend ses instructions sous forme de fichiers “.yaml” appelés manifests. Pour appliquer les modifications selon les manifests fournis (pods, deployment, services, ingress), il faut utiliser kubectl apply -f . ce qui créera toutes les ressources décrites dans les manifests. kubectl get --help La commande sert à afficher des informations sur différents types de ressources; affichez les ressources crées avec kubectl get pods, kubectl get services et kubectl get deployments. L’utilitaire watch permet de répéter une commande et d’afficher le résultat, ce qui peut être très pratique pour surveiller la création de vos ressources, par exemple avec watch kubectl get ingress.
Prenez note qu’il peut y avoir un certain délai avant que la page web ne soit disponible. Le fichier index.html propose d’afficher le hostname mais il s’agit ici de la partie hostname de l’url. Le fichier “index2.html” affiche ce qui ressemble à un CONTAINER ID, celui du container intermédiaire lors de la construction de l’image.
Si vous avez construit vous même votre image, enlevez le # devant echo dans le fichier “entrypoint.sh” puis reconstruisez l’image, par exemple avec un tag “v2”. Modifiez le fichier “apache-deployment.yaml” pour utiliser “matbilodeau/test-apache-kube:v2” ou la vôtre. Rechargez le fichier “index2.html”. Vous avez maintenant l’information du pod qui a répondu à la requête http.
L’explication de la différence entre les deux affichages se trouve dans les instructions de RUN et ENTRYPOINT, plus particulièrement le moment où ils s’exécutent.
Pour tout supprimer, utilisez directement gcloud container clusters delete test-kubernetes. Le même déploiement est utilisé pour l’exercice 2.