Notes sur Katacoda relatives à l’orchestrateur de conteneur Kubernetes

Notes sur Katacoda relatives à l’orchestrateur de conteneur Kubernetes

Il y a quelques semaines, j’ai consacré deux jours pour suivre les cours relatifs à la solution d’orchestation de *container Kubernetes mise à disposition sur la plateforme Katacoda. Je partage ces notes qui, à l’usage, me servent de pense bête.

Si vous ne connaissez pas ou si vous n’avez pas eu le temps d’essayer Katacoda, et si vous avez un intérêt pour Kubernetes, Docker ou n’importe lequel des cours offerts, vous serez surpris par comment Katacode rend simple, rapide et efficace l’appropriation de nouveaux savoirs sur un large choix de technologies. En complément des cours, ils offrent des bacs à sable, appelés playgrounds, contenant une installation de CoreOS, DC/OS et Kubernetes. En moins de temps qu’il ne faut pour le prononcer, vous serez devant un invite de commande prêt à lancer des commandes pour tester ces technologies.

Lancement d’un cluster composé d’un noeud unique

Apprendre comment lancer un cluster d’un noeud avec Minikube installé en incluant les DNS et Kube UI

L’installation implique:

Minikube s’exécute sur un noeud unique Kubernetes isolé à l’intérieur d’une VM sur votre poste:

À ce stade, Kuberetes est disponible :

Démarrer un conteneur est similaire à la commande Docker :

Kubernetes gère nativement le routage TCP / HTTP :

Comme avec Docker, pour obtenir des informations sur un conteneur telles que la valeur PORT, utilisez les go templates :

Le tableau de bord Kubernetes est disponible sur le port 8080.

Lancement d’un cluster multi noeud avec Kubeadm

Initialiser un cluster Kubernetes avec Kubeadm

Kubeadm gère la configuration du chiffrement TLS, déploie les composants principaux de Kubernetes et s’assure que d’autres nœuds peuvent facilement rejoindre le cluster.

Vous trourerez ici une description détaillée de l’architecture de Kubernetes.

Pour initialiser le cluster:

Pour configurer et connecter le client :

Une alternative consiste à exporter une variable d’environnement pointant sur l’adresse du Kubernetes master :

Le standard CNI ou Container Network Interface définit la manière dont les différents nœuds et leurs charges de travail doivent communiquer.

Une liste de founisseurs de réseau implémentant CNI est disponible ici.

Installation de Weave Net :

Déploiement d’un pod :

Installation du tableau de bord web pour piloter Kubernetes :

Deploiement d’une application web d’exemple

Comment déployer un serveur web d’exemple avec Kubernetes

Cette installation manipule des déclarations de type Pods, Replication Controllers, Services, NodePorts en installant Redis avec un maître pour le stockage et un ensemble répliqué d’esclaves Redis.

Le script de lancement installe ce qui suit :

Le Kubelet est l’agent primaire qui s’exécute sur chaque noeud. Le programme Kurnetes est directement téléchargé depuis Internet (curl suivi chmod u + x)

Le proxy réseau Kubernetes s’exécute sur chaque noeud et est utilisé pour atteindre les services. Il fait TCP, UDP stream forwarding ou round robin TCP, le transfert UDP à travers un ensemble de backends.

La résolution DNS est un service intégré. Kubernetes DNS planifie un Pod et un service DNS sur le cluster et configure les kubelets pour indiquer aux conteneurs individuels d’utiliser l’adresse IP du service DNS pour résoudre les noms DNS.

Pour activer la découverte DNS :

Une fois installé, l’environnement client est disponbile :

Le déploiement du service Kubernetes possède à minima deux définitions:

  • contrôleur de réplication (RC – replication controller): s’assure qu’un pod ou un ensemble homogène de pods est toujours actif et disponible. Il définit le nombre d’instances à exécuter, l’image Docker à utiliser et un nom permettant d’identifier le service.
  • service: définit un ensemble logique de Pods et une politique par laquelle y accéder – parfois appelé un micro-service.

La définition RC connecte les esclaves Redis à son agent en utilisant “GET_HOSTS_FROM” avec la valeur “dns” pour rechercher les informations d’hôtes de service à partir de DNS lors de l’exécution.

Le service défini comme NodePort provisionne des ports connus et partagés sur l’ensemble du cluster. C’est comme -p 80:80 dans Docker.

Pour trouver le NodePort affecté en utilisant kubectl:

Lancement de Conteneurs avec Kubectl

Utiliser Kubectl pour démarrer des conteneurs et les rendre accessible

Kubectl permet d’enregistrer et de lancer des définition de type Deployments, Replication Controllers et de les exposer en tant que définition de type Services sans avoir à écrire de définition en YAML.

Un contrôleur de déploiement est un objet Kubernetes qui fournit des mises à jour déclaratives pour Pods et ReplicaSets.

Sa définition décrit un état souhaité dans un objet Déploiement et le contrôleur applique la transition de l’état actuel à l’état souhaité à un rythme qu’il contrôle. Les déploiements sont utilisés pour créer de nouveaux ReplicaSets ou pour supprimer des déploiements existants et adopter toutes leurs ressources avec de nouveaux déploiements.

L’exécution de Kubectl est similaire à l’exécution de Docker mais au niveau du cluster et permet de créer un déploiement.

Afficher l’état des déploiements:

Décrire le processus de déploiement (éventuellement avec le nom de la capsule à la fin) :

Exposer un port depuis l’IP externe de l’hôte :

Cette dernière commande crée un service exposant le port “8000”:

Lorsque vous utilisez le docker avec l’option hostport, le pod n’est pas un service et est exposé via un mappage de port Docker. Avec docker ls, on voit que ce n’est pas le container qui expose les ports mais le pod. Les autres conteneurs du pod partagent le même espace de noms de réseau. Cela améliore les performances du réseau et permet à plusieurs conteneurs de communiquer sur la même interface réseau.

Changer l’échelle du nombre de pods en cours d’exécution pour un déploiement ou un contrôleur de réplication particulier :

Déployer des conteneurs à l’aide de YAML

Découvrir comment utiliser les définitions YAML pour déployer des conteneurs

Les définitions YAML définissent les objets Kubernetes planifiés pour le déploiement. Les objets peuvent être mis à jour et redéployés dans le cluster pour modifier la configuration.

Une définition de service correspond à des applications utilisant des étiquettes (“label” en anglais):

Les capacités de mise en réseau sont contrôlées via la définition du service avec nodePort:

Utilisez kubectl apply  pour refléter les modifications apportées à un fichier de définition:

Creation de routes Ingress

Définir le routage Ingress basé sur l’hôte et le chemin

Ingress contrôle les connexions entrantes au cluster, permettant au trafic externe d’atteindre le Pod souhaité. Les fonctionnalités permettent d’accéder à des URL externes, de gérer le trafic de balancement de la charge, d’activer SSL, d’offrir un hébergement virtuel basé sur le nom …

Ingress est synonyme de connexions entrantes, tandis que egress correspond aux connexions sortantes. Kubernetes, dans sa dernière version, prend en charge les stratégies pour les deux types.

Les règles d’entrée peuvent être basées sur un hôte (domaine), ou le chemin de la requête, ou une combinaison des deux.

Pour déployer les types d’objet ingress :

Pour visualiser toutes les règles Ingress :

Je viens d’apprendre une nouvelle astuce avec HTTP et curl utile pour les tests. Au lieu de créer une nouvelle entrée dans “/etc/hosts” pour simuler un nom d’hôte HTTP, passez l’en-tête “Host”:

Utiliser Kubernetes pour la gestion de Secrets et de mots de passe

Conserver vos secrets en toute sécurité

Kubernetes vous permet de créer des secrets qui sont montés dans un pod via des variables d’environnement ou un volume. Cela permet aux secrets, tels que les certificats SSL ou les mots de passe, d’être gérés de manière sécurisée par une équipe d’infrastructure au lieu d’avoir les mots de passe stockés dans les artefacts de déploiement de l’application.

Les secrets sont créés en tant qu’objets Kubernetes.

Voici à quoi ils ressemblent:

Créer et visualiser des secrets:

Si vous utilisez docker ps et que vous vous demandez quels sont les conteneurs de pause, voici comment Eric Paris les décrit :

Le conteneur de pause est un conteneur qui contient l’espace de noms du réseau pour le pod. Cela ne fait rien d’utile. (C’est en fait juste un peu d’assemblage qui s’endort et ne se réveille jamais)

Cela signifie que votre conteneur ‘apache’ peut mourir, et revenir à la vie, et toute la configuration du réseau sera toujours là. Normalement, si le dernier processus dans un espace de noms réseau meurt, l’espace de noms serait détruit et la création d’un nouveau conteneur Apache nécessiterait la création de toute nouvelle configuration réseau. Avec pause, vous aurez toujours cette dernière chose dans l’espace de noms.

Un pod dont les variables d’environnement sont remplies comprend quelque chose comme:

kubectl exec  est conçu sur l’exemple de docker exec.

Pour afficher les variables environnementales peuplées:

Pour monter le fichier secret, créez le pod avec un volume et montez-le:

Attention, les autorisations doivent être correctement appliquées, la valeur par défaut est ‘444’.

Bilans de santé Liveness et Readiness

Assurer la santé des conteneurs en utilisant des sondes Liveness et Readiness

La sonde Readiness Probes vérifie si une application est prête à commencer le traitement du trafic. Cette sonde résout le problème au démarrage d’un conteneur, quand le processus continue de se préparer et de se configurer, ce qui signifie qu’il n’est pas prêt à recevoir du trafic.

Les sondes Liveness Probes garantissent que l’application est saine et capable de traiter les demandes.

Déploiement de vos sources jusqu’à Kubernetes

Partir du code source jusqu’au lancement de services dans Kubernetes

La propriété .spec.revisionHistoryLimit  spécifie le nombre d’anciens ReplicaSets à conserver pour permettre un rollback.

La propriété imagePullPolicy accepte comme valeur “Always” (default), “Never” ou “IfNotPresent”.

La propriété  dnsPolicy accepte comme valeur “ClusterFirst” (default), “ClusterFirstWithHostNet” ou “Default”.

Un registre de conteneur est un service central qui héberge des images.

Pour insérer un conteneur local dans un registre de conteneur personnalisé :

Le registre peut être référencé dans le nom de l’image Docker lors de la définition d’un déploiement :

Kubernetes kubectl  lit automatiquement “~ / .kube / config”.

Forge automatise le déploiement de services dans Kubernetes et effectue les opérations suivantes:

  • Construire le Dockerfile
  • Pousser l’image dans un registre
  • Définition du déploiement
  • Déployer le conteneur dans Kubernetes

Le gestionnaire de packages/pods Helm

Utilisation du gestionnaire de paquets Helm pour déployer Redis dans Kubernetes

Helm est le gestionnaire de paquets pour Kubernetes. Les packages sont appelés charts (diagrammes) et sont constitués de ressources Kubernetes préconfigurées.

Helm a deux parties: un client (helm) et un serveur (tiller); Tiller s’exécute à l’intérieur de votre cluster Kubernetes et gère les versions (installations) de vos charts.

Pour installer Helm:

Pour récupérer des informations sur des packages:

Monocular est une interface Web permettant de gérer les applications Kubernetes sous forme de charts Helm.


Also published on Medium.

By | 2018-01-08T20:14:15+00:00 January 8th, 2018|Conteneur|0 Comments

About the Author:

Leave A Comment

Time limit is exhausted. Please reload the CAPTCHA.