Phenquestions
Dans un article précédent, nous avons déployé un cluster Kubernetes avec un nœud maître et un nœud de travail. Les clusters Kubernetes concernent principalement deux choses ; Nœuds et pods. Les pods sont les applications conteneurisées que vous souhaitez déployer sur le cluster et les nœuds sont les serveurs de calcul individuels responsables de la gestion du cluster ou de l'exécution des applications. Pour simplifier les choses, nous commençons par une application sans état et introduisons divers concepts tels que les étiquettes et les sélecteurs qui sont utilisés pour lier les pods les uns aux autres.
Il existe d'autres concepts importants tels que les jeux de répliques, les services et les déploiements que nous apprendrons tous dans cet article.
Déploiement d'applications traditionnel
Si vous regardez l'approche traditionnelle pour déployer une application Web, l'évolutivité est quelque chose que vous devriez considérer avant de commencer. Si vous avez besoin d'une base de données distincte de votre interface Web, vous feriez mieux de le faire maintenant plutôt que de le faire plus tard. Prévoyez-vous d'exécuter plus d'une application Web? Mieux vaut configurer un serveur proxy inverse au préalable.
Avec Kubernetes, l'approche a changé. Le déploiement peut être effectué en tenant compte des besoins actuels et peut ensuite être étendu à mesure que votre entreprise se développe. La conteneurisation vous permet de séparer les composants essentiels de vos services Web, même lorsqu'ils s'exécutent sur un seul nœud. Plus tard, lorsque vous effectuez une mise à l'échelle horizontale (ce qui signifie que vous ajoutez plus de serveurs à votre environnement), vous devez simplement faire tourner plus de conteneurs, et Kubernetes le programmera sur les nœuds appropriés pour vous. Proxy inverse? Les services Kubernetes viendraient pour résoudre ce problème.
Pods
Dans un premier temps, faisons tourner un pod. Pour ce faire, nous aurions besoin d'un fichier YAML définissant divers attributs du pod.
apiVersion : v1genre: Pod
métadonnées :
nom : nginx
spécification :
conteneurs :
- nom : nginx
image : nginx:1.7.9
ports :
- conteneurPort: 80
Ajoutez le contenu ci-dessus dans un cosse.yaml fichier et enregistrez-le. En regardant le texte ci-dessus, vous pouvez voir que le gentil de ressource que nous créons est un cosse. Nous l'avons nommé nginx, et l'image est nginx:1.7.9 ce qui, par défaut, signifie que Kubernetes récupérera l'image nginx appropriée à partir des images accessibles au public du hub Docker.
Dans les organisations à grande échelle, K8 est souvent configuré pour pointer vers un registre privé à partir duquel il peut extraire les images de conteneur appropriées.
Maintenant, pour démarrer l'exécution du pod :
$kubectl create -f pod.yamlVous ne pouvez pas accéder au pod depuis l'extérieur du cluster. Il n'est pas encore exposé, et il n'existe que sous forme de pod solitaire. Pour vous assurer qu'il est bien déployé, exécutez :
$kubectl obtenir des pods
Pour se débarrasser du pod nommé nginx, exécutez la commande :
$kubectl supprimer le pod nginxDéploiements
Obtenir un seul pod fonctionnel n'est pas le but de Kubernetes, ce que nous voudrions, idéalement, ce sont plusieurs répliques d'un pod, souvent planifiées sur différents nœuds, donc si un ou plusieurs nœuds échouent, le reste des pods sera toujours là pour prendre la charge de travail supplémentaire.
De plus, du point de vue du développement, nous aurions besoin d'un moyen de déployer des pods avec une version plus récente du logiciel et de mettre les anciens pods en veille. Au cas où il y aurait un problème avec le nouveau pod, nous pouvons revenir en arrière en ramenant les anciens pods et en supprimant la version défaillante. Les déploiements nous permettent de le faire.
Voici une manière très courante de définir un déploiement :
apiVersion : apps/v1beta1genre : Déploiement
métadonnées :
nom : nginx-deployment
spécification :
répliques : 2
modèle:
métadonnées :
Étiquettes:
application : nginx
spécification :
conteneurs :
- nom : nginx
image : nginx:1.7.9
ports :
- conteneurPort: 80
Vous remarquerez entre autre un couple clé-valeur qui est :
Étiquettes:
application : nginx
Les étiquettes sont importantes pour la gestion des clusters car elles aident à garder une trace d'un grand nombre de pods tous avec le même devoir. Les pods sont créés sur la commande du nœud maître, et ils communiquent avec le nœud maître. Cependant, nous avons toujours besoin d'un moyen efficace pour qu'ils puissent se parler et travailler ensemble en équipe.
Prestations de service
Chaque pod a sa propre adresse IP interne et une couche de communication comme Flannel aide les pods à communiquer entre eux. Cette adresse IP, cependant, change un peu et, après tout, tout l'intérêt d'avoir de nombreux pods est de les laisser être jetables. Les gousses sont souvent tuées et ressuscitées.
La question qui se pose maintenant est la suivante : comment les pods frontaux communiqueront-ils avec les pods principaux lorsque les choses sont si dynamiques dans le cluster ??
Les services entrent en scène pour résoudre cette complexité. Un service est un autre pod qui agit comme un équilibreur de charge entre un sous-ensemble de pods et le reste du cluster Kubernetes. Il se lie à tous les pods auxquels une étiquette spécifique est attachée, par exemple, la base de données, puis les expose pour le reste du cluster.
Par exemple, si nous avons un service de base de données avec 10 pods de base de données, certains des pods de base de données peuvent apparaître ou être tués, mais le service garantirait que le reste du cluster obtienne le "service" qui est une base de données. Les services peuvent également être utilisés pour exposer le front-end au reste d'Internet.
Voici une définition typique d'un service.
apiVersion : v1genre : Service
métadonnées :
nom : wordpress-mysql
Étiquettes:
application : wordpress
spécification :
ports :
- port : 3306
sélecteur:
application : wordpress
niveau : mysql
clusterIP : aucun
Les pods étiquetés WordPress avec le niveau mysql spécifié sont ceux qui seront récupérés par ce service et exposés aux pods du serveur Web pour une configuration WordPress typique effectuée sur Kubernetes.
Mot de prudence
Lors du déploiement d'une application multi-niveaux géante destinée à une large base de consommateurs, il devient très tentant d'écrire de nombreux services (ou un microservice, comme on les appelle communément). Bien qu'il s'agisse d'une solution élégante pour la plupart des cas d'utilisation, les choses peuvent rapidement devenir incontrôlables.
Les services, comme les pods, sont sujets à l'échec. La seule différence est que lorsqu'un service échoue, beaucoup de pods, qui sont parfaitement fonctionnels, sont rendus inutiles. Par conséquent, si vous avez une grande interconnexion de services (à la fois internes et externes) et que quelque chose échoue, il deviendrait impossible de déterminer le point de défaillance.
En règle générale, si vous avez une visualisation approximative du cluster, ou si vous pouvez utiliser un logiciel comme cockpit pour regarder le cluster et lui donner un sens, votre configuration est bonne. Kubernetes, en fin de compte, est conçu pour réduire la complexité, pas pour l'améliorer.
