TOC

Introduction à Kubernetes

1. Vue d’ensemble

Dans ce tutoriel, nous aurons une brève introduction théorique à Kubernetes. En particulier, nous aborderons les sujets suivants:

  • Besoin d’un outil d’orchestration de conteneur

  • Caractéristiques de Kubernetes

  • L’architecture Kubernetes

  • API Kubernetes

Pour une compréhension plus approfondie, nous pouvons également consulter la page https://kubernetes.io/docs/home/?path=users .

2. Orchestration de conteneur

Dans ce lien:/dockerizing-spring-boot-application[article précédent], nous avons déjà présenté certaines notions de base de Docker, ainsi que la mise en package et le déploiement d’applications personnalisées.

  • En bref, Docker est un environnement d’exécution de conteneur: il fournit des fonctionnalités permettant de conditionner, d’expédier et d’exécuter des instances uniques d’une application de manière standardisée, également appelée conteneur. **

Cependant, à mesure que la complexité augmente, de nouveaux besoins apparaissent. déploiement automatisé, orchestration des conteneurs, planification des applications, octroi de la haute disponibilité, gestion d’un cluster de plusieurs instances d’application, etc.

Il existe de nombreux outils disponibles sur le marché. Toutefois, Kubernetes s’impose de plus en plus comme un concurrent important.

3. Caractéristiques Kubernetes

En bref, Kubernetes est un système permettant d’orchestrer des applications conteneurisées sur un cluster de nœuds, y compris une infrastructure de réseau et de stockage . Certaines des fonctionnalités les plus importantes sont:

  • Planification des ressources: assure que les Pods sont distribués de manière optimale

sur tous les nœuds disponibles ** Mise à l’échelle automatique: avec l’augmentation de la charge, le cluster peut dynamiquement

allouer des noeuds supplémentaires et déployer de nouveaux Pods sur eux ** Auto-guérison: le cluster supervise les conteneurs et les redémarre si

requis, en fonction de politiques définies ** Découverte de services: Pods et Services sont enregistrés et publiés.

via DNS ** Mises à jour roulantes/annulations: supporte les mises à jour roulantes basées sur

redéploiement séquentiel des pods et des conteneurs ** Secret/gestion de la configuration: prend en charge la gestion sécurisée des données sensibles

des données telles que des mots de passe ou des clés API ** Orchestration du stockage: plusieurs solutions de stockage tierces sont

pris en charge, pouvant être utilisés comme volumes externes pour conserver des données

4. Comprendre Kubernetes

Le _ maître maintient l’état souhaité d’un cluster. Lorsque nous interagissons avec notre cluster, e. g. En utilisant l’interface de ligne de commande kubectl_ , nous communiquons toujours avec le maître de notre cluster.

Les nœuds d’un cluster sont les machines (machines virtuelles, serveurs physiques, etc.) qui exécutent nos applications. Le maître contrôle chaque noeud.

Un nœud a besoin d’un conteneur d’exécution . Docker est le runtime le plus couramment utilisé avec Kubernetes.

Minikube est une distribution Kubernetes qui nous permet d’exécuter un cluster à un seul nœud dans une machine virtuelle sur un poste de travail à des fins de développement et de test.

L’API Kubernetes fournit une abstraction des concepts de Kubernetes en les encapsulant dans des objets (nous verrons dans la section suivante).

_ kubectl _ est un outil de ligne de commande que nous pouvons utiliser pour créer, mettre à jour, supprimer et inspecter ces objets API.

5. Objets API Kubernetes

  • Un objet API est un «enregistrement d’intention» ** - une fois que nous avons créé l’objet, le système de cluster travaillera en permanence pour garantir la présence de cet objet.

  • Chaque objet est composé de deux parties: la spécification de l’objet et son statut. La spécification décrit l’état souhaité pour l’objet. Le statut décrit l’état actuel de l’objet et est fourni et mis à jour par le cluster. **

Dans la section suivante, nous aborderons les objets les plus importants.

Après cela, nous examinerons un exemple montrant comment les spécifications et le statut ressemblent en réalité.

5.1. Objets de base

A Pod est une unité de base utilisée par Kubernetes. Il encapsule un ou plusieurs conteneurs étroitement liés, ressources de stockage, une adresse IP réseau unique et des configurations sur la façon dont le ou les conteneurs doivent être exécutés, et représente ainsi une instance unique d’une application.

  • Service ** est une abstraction qui regroupe des collections logiques de pods et définit comment y accéder. Les services constituent une interface avec un groupe de conteneurs, ce qui évite aux consommateurs de s’inquiéter de rien au-delà d’un seul emplacement d’accès.

Avec Volumes , les conteneurs peuvent accéder aux ressources de stockage externes (leur système de fichiers étant éphémère), et ils peuvent lire des fichiers ou les stocker de manière permanente. Les volumes prennent également en charge le partage de fichiers entre les conteneurs. Une longue liste de Volume est prise en charge.

Avec Namespaces , Kubernetes offre la possibilité d’exécuter plusieurs clusters virtuels sur un cluster physique. Les espaces de noms fournissent une portée pour les noms de ressources, qui doivent être uniques dans un espace de noms.

5.2. Contrôleurs

En outre, il existe des abstractions de niveau supérieur, appelées contrôleurs. Les contrôleurs s’appuient sur les objets de base et fournissent des fonctionnalités supplémentaires:

Un contrôleur Deployment fournit des mises à jour déclaratives pour les pods et les ReplicaSets. Nous décrivons l’état souhaité dans un objet Deployment et le contrôleur de déploiement modifie l’état actuel en l’état souhaité.

Un ReplicaSet garantit qu’un nombre spécifié de répliques de pod s’exécute à un moment donné.

Avec StatefulSet , , nous pouvons exécuter des applications avec état: différentes du déploiement, les pods auront une identité unique et persistante. À l’aide de StatefulSet, nous pouvons implémenter des applications avec des identifiants réseau uniques ou un stockage persistant, et pouvons garantir un déploiement ordonné et harmonieux, une mise à l’échelle, une suppression et une terminaison, ainsi que des mises à jour mobiles ordonnées et automatisées.

Avec DaemonSet , , nous pouvons nous assurer que tous ou un ensemble spécifique de nœuds de notre cluster exécutent une copie d’un pod spécifique. Cela pourrait être utile si un démon doit être exécuté sur chaque nœud, e. g. pour la surveillance des applications ou pour la collecte des journaux.

Un GarbageCollection s’assure que certains objets sont supprimés, qui avaient un propriétaire auparavant, mais n’en ont plus. Cela aide à économiser des ressources en supprimant des objets, qui ne sont plus nécessaires.

Un Job crée un ou plusieurs pods, s’assure qu’un nombre spécifique d’entre eux se termine avec succès et suit les achèvements réussis. Les tâches sont utiles pour le traitement en parallèle d’un ensemble d’éléments de travail indépendants mais liés, tels que l’envoi d’e-mails, le rendu d’images, le transcodage de fichiers, etc.

5.3. Métadonnées d’objet

Les métadonnées sont des attributs qui fournissent des informations supplémentaires sur les objets.

Les attributs obligatoires sont:

  • Chaque objet doit avoir un Namespace (nous en avons déjà discuté

avant). S’il n’est pas spécifié explicitement, un objet appartient à l’espace de noms default .

  • Un Nom est un identifiant unique pour un objet dans son espace de noms.

  • Un Uid est une valeur unique dans le temps et dans l’espace. Cela aide à distinguer

entre les objets, qui ont été supprimés et recréés.

Il existe également des attributs de métadonnées facultatifs. Certains des plus importants sont:

  • Les étiquettes sont une paire clé/valeur pouvant être attachée à des objets

les classer. Cela nous aide à identifier une collection d’objets satisfaisant une condition spécifique. Ils nous aident à mapper nos structures organisationnelles sur des objets de manière faiblement couplée.

  • Les sélecteurs d’étiquettes nous aident à identifier un ensemble d’objets par leur

Étiquettes.

  • Les annotations sont également des paires clé/valeur. Contrairement aux étiquettes, ils

ne sont pas utilisés pour identifier des objets. Au lieu de cela, ils peuvent stocker des informations sur leurs objets respectifs, telles que des informations de construction, de publication ou d’image.

5.4. Exemple

Après avoir discuté de l’API de Kubernetes en théorie, nous allons maintenant examiner un exemple.

Les objets API peuvent être spécifiés sous forme de fichiers JSON ou YAML. Cependant, la documentation recommande YAML pour la configuration manuelle.

Dans ce qui suit, nous définirons la partie de spécification pour le déploiement d’une application sans état. Après cela, nous verrons comment un statut renvoyé par le cluster pourrait ressembler.

La spécification d’une application appelée demo-backend pourrait ressembler à ceci: 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-backend
spec:
  selector:
      matchLabels:
        app: demo-backend
        tier: backend
  replicas: 3
  template:
    metadata:
      labels:
        app: demo-backend
        tier: backend
    spec:
      containers:
        - name: demo-backend
          image: demo-backend:latest
          ports:
            - containerPort: 8080

Comme nous pouvons le voir, nous spécifions un objet Deployment , appelé demo-backend .

La partie spec: ci-dessous est en fait une structure imbriquée et contient les objets API suivants, décrits dans les sections précédentes:

  • replicas: 3 spécifie un ReplicationSet avec le facteur de réplication 3

(i. e. nous aurons trois instances du Deployment ) ** template: spécifie un Pod

  • Dans ce Pod, nous pouvons utiliser spec: conteneurs: pour en affecter un ou

plusieurs conteneurs à notre Pod. Dans ce cas, nous avons un conteneur appelé demo-backend , qui est instancié à partir d’une image également appelée demo-backend , version latest et écoute le port 8080 ** Nous attachons également des étiquettes à notre pod: app: demo-backend et __tier:

backend ** Avec selector: matchLabels: , nous lions notre Pod au Deployment__

contrôleur (mappage aux étiquettes app: demo-backend et tier: backend )

Si nous interrogons l’état de notre Deployment à partir du cluster, la réponse ressemblera à ceci: 

Name:                   demo-backend
Namespace:              default
CreationTimestamp:      Thu, 22 Mar 2018 18:58:32 +0100
Labels:                 app=demo-backend
Annotations:            deployment.kubernetes.io/revision=1
Selector:               app=demo-backend
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=demo-backend
  Containers:
   demo-backend:
    Image:        demo-backend:latest
    Port:         8080/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Progressing    True    NewReplicaSetAvailable
  Available      True    MinimumReplicasAvailable
OldReplicaSets:  <none>
NewReplicaSet:   demo-backend-54d955ccf (3/3 replicas created)
Events:          <none>

Comme nous pouvons le constater, le déploiement semble être opérationnel et nous pouvons reconnaître la plupart des éléments de notre spécification.

Nous avons un déploiement avec un facteur de réplication de 3, avec un pod contenant un conteneur, instancié à partir de image demo-backend: latest .

Tous les attributs, présents dans la réponse mais non définis dans notre spécification, sont des valeurs par défaut.

6. Débuter avec Kubernetes

Nous pouvons exécuter Kubernetes sur différentes plates-formes: de notre ordinateur portable aux machines virtuelles d’un fournisseur de cloud, ou d’un rack de serveurs sans système d’exploitation.

  • Pour commencer, Minikube pourrait être le choix le plus simple: il nous permet d’exécuter un cluster à nœud unique sur un poste de travail local pour le développement et les tests. . **

Consultez la page official[officielle ]pour en savoir plus sur les solutions de machine locale, les solutions hébergées, les distributions à exécuter sur des clouds IaaS, etc.

7. Conclusion

Dans cet article, nous avons passé en revue quelques notions de base sur Kubernetes.

En termes simples, nous avons couvert les aspects suivants:

  • Pourquoi nous pourrions avoir besoin d’un outil d’orchestration de conteneur

  • Certaines des caractéristiques les plus importantes de Kubernetes

  • L’architecture Kubernetes et ses composants les plus importants

  • API Kubernetes et comment l’utiliser pour spécifier l’état souhaité de

notre cluster

Related