Sidecar Kubernetes, C’est quoi Kubernetes :
Avant de parle des SideCar Kubernetes voyons c’est quoi Kubernetes. Kubernetes est un moteur d’orchestration de conteneurs open source pour automatiser le déploiement, la mise à l’échelle et la gestion des applications conteneurisées. Un pod est le bloc de base de l’application Kubernetes. Kubernetes gère les pods au lieu des conteneurs et les pods encapsulent les conteneurs. Un pod peut contenir un ou plusieurs conteneurs, stockage, adresses IP et options qui régissent la manière dont les conteneurs doivent s’exécuter à l’intérieur du pod.
Un pod qui contient un conteneur fait référence à un pod conteneur unique et c’est le cas d’utilisation de Kubernetes le plus courant. Un pod qui contient plusieurs conteneurs co-liés fait référence à un pod multi-conteneurs. Il existe peu de modèles pour les pods à plusieurs conteneurs, l’un d’eux est le modèle de conteneur sidecar Kubernetes.
Dans cet article, nous verrons ce modèle en détail avec un exemple de projet d’une application avec sidecar Kubernetes
Que sont les conteneurs Sidecar
Les conteneurs Sidecar sont les conteneurs qui doivent fonctionner avec le conteneur principal du pod. Ce modèle side-car étend et améliore la fonctionnalité des conteneurs actuels sans le modifier. De nos jours, nous savons que nous utilisons la technologie des conteneurs pour envelopper toutes les dépendances pour que l’application s’exécute n’importe où. Un conteneur ne fait qu’une chose et le fait très bien.
Imaginez que le pod avec un seul conteneur fonctionne très bien et que vous souhaitez ajouter des fonctionnalités au conteneur actuel sans toucher ni modifier, comment pouvez-vous ajouter la fonctionnalité supplémentaire ou étendre la fonctionnalité actuelle? Ce modèle de conteneur side-car aide vraiment exactement dans cette situation.
Si vous regardez le diagramme ci-dessus, vous pouvez définir n’importe quel nombre de conteneurs pour les conteneurs Sidecar et votre conteneur principal fonctionne avec succès. Tous les conteneurs seront exécutés en parallèle et toute la fonctionnalité ne fonctionnera que si les deux types de conteneurs fonctionnent correctement. La plupart du temps, ces conteneurs side-car sont simples et petits et consomment moins de ressources que le conteneur principal.
Exemple de projet
Implémentons un projet simple deploiement d’une application avec un sidecar Kubernetes pour comprendre ce modèle. Voici un pod simple qui a des conteneurs principaux et side-car. Le conteneur principal est nginx servant sur le port 80 qui prend l’index.html de l’ emplacement du workdir de montage du volume . Le conteneur Sidecar avec l’image busybox crée des journaux au même emplacement avec un horodatage. Étant donné que le conteneur Sidecar et le conteneur principal s’exécutent en parallèle, Nginx affichera les nouvelles informations du journal chaque fois que vous cliquez sur le navigateur.
| apiVersion: v1 | |
|
kind: Pod |
|
| metadata: | |
| name: sidecar-container-demo | |
| spec: | |
| containers: | |
| – image: busybox | |
| command: [« /bin/sh »] | |
| args: [« -c », « while true; do echo echo $(date -u) ‘Hi I am from Sidecar container’ >> /var/log/index.html; sleep 5;done »] | |
| name: sidecar-container | |
| resources: {} | |
| volumeMounts: | |
| – name: var-logs | |
| mountPath: /var/log | |
| – image: nginx | |
| name: main-container | |
| resources: {} | |
| ports: | |
| – containerPort: 80 | |
| volumeMounts: | |
| – name: var-logs | |
| mountPath: /usr/share/nginx/html | |
| dnsPolicy: Default | |
| volumes: | |
| – name: var-logs | |
| emptyDir: {} |
// create the pod
kubectl create -f pod.yml// list the pods
kubectl get po// exec into pod
kubectl exec -it sidecar-container-demo -c main-container -- /bin/sh
# apt-get update && apt-get install -y curl
# curl localhost
Vous pouvez installer curl, interroger l’hôte local et vérifier la réponse.
Test avec un objet de déploiement Sidecar sur Kubernetes
Créons un objet de déploiement avec la même spécification de pod avec 5 répliques. J’ai créé un service avec le type de port NodePort afin que nous puissions accéder au déploiement à partir du navigateur. Les pods sont dynamiques ici et le contrôleur de déploiement essaie toujours de maintenir l’état souhaité, c’est pourquoi vous ne pouvez pas avoir une seule adresse IP statique pour accéder aux pods afin que vous deviez créer un service qui expose le port statique au monde extérieur. Le service interne correspond au port 80 en fonction des sélecteurs. Vous verrez cela en action dans un moment.
Deployment
Examinons l’objet de déploiement ci-dessous où nous définissons un conteneur principal et deux conteneurs side-car. Tous les conteneurs fonctionnent en parallèle. Les deux conteneurs side-car créent des journaux à l’emplacement / var / log. Le conteneur principal Nginx sert ces fichiers journaux comme lorsque nous avons atteint le serveur Web NGINX à partir du port 80. Vous verrez cela en action dans un moment.
| apiVersion: apps/v1 | |
| kind: Deployment | |
| metadata: | |
| creationTimestamp: null | |
| labels: | |
| app: nginx-webapp | |
| name: nginx-webapp | |
| spec: | |
| replicas: 5 | |
| selector: | |
| matchLabels: | |
| app: nginx-webapp | |
| strategy: {} | |
| template: | |
| metadata: | |
| creationTimestamp: null | |
| labels: | |
| app: nginx-webapp | |
| spec: | |
| containers: | |
| – image: busybox | |
| command: [« /bin/sh »] | |
| args: [« -c », « while true; do echo echo $(date -u) ‘Hi I am from Sidecar container 1’ >> /var/log/index.html; sleep 5;done »] | |
| name: sidecar-container1 | |
| resources: {} | |
| volumeMounts: | |
| – name: var-logs | |
| mountPath: /var/log | |
| – image: busybox | |
| command: [« /bin/sh »] | |
| args: [« -c », « while true; do echo echo $(date -u) ‘Hi I am from Sidecar container 2’ >> /var/log/index.html; sleep 5;done »] | |
| name: sidecar-container2 | |
| resources: {} | |
| volumeMounts: | |
| – name: var-logs | |
| mountPath: /var/log | |
| – image: nginx | |
| name: main-container | |
| resources: {} | |
| ports: | |
| – containerPort: 80 | |
| volumeMounts: | |
| – name: var-logs | |
| mountPath: /usr/share/nginx/html | |
| dnsPolicy: Default | |
| volumes: | |
| – name: var-logs | |
| emptyDir: {} | |
| status: {} | |
| — | |
| apiVersion: v1 | |
| kind: Service | |
| metadata: | |
| name: nginx-webapp | |
| labels: | |
| run: nginx-webapp | |
| spec: | |
| ports: | |
| – port: 80 | |
| protocol: TCP | |
| selector: | |
| app: nginx-webapp | |
| type: NodePort |
Suivons ces commandes pour tester le déploiement.
// create a deployment
kubectl create -f manifest.yml// list the deployment, pods, and service
kubectl get deploy -o wide
kubectl get po -o wide
kubectl get svc -o wide
déploiement en actionDans le diagramme ci-dessus, vous pouvez voir 5 pods s’exécutant dans différentes adresses IP et l’objet de service mappe le port 32123 au port 80 . Vous pouvez en fait accéder à ce déploiement à partir du navigateur à partir de l’adresse IP du maître kubernetes 192.168.64.2 et du port de service 32123 .
http://192.168.64.2:32123
// exec into main container of the pod
kubectl exec -it nginx-webapp-7c8b4d4f8d-9qmdm -c main-container -- /bin/sh// install curl
# apt-get update && apt-get install -y curl
# curl localhost
Motif de Sidecar en actionSidecar Kubernetes ,comment configurer les limites de ressources
La configuration des limites de ressources est très importante lorsqu’il s’agit de conteneurs Sidecar. Le point principal que nous devons comprendre ici est que tous les conteneurs fonctionnent en parallèle.Par conséquent, lorsque vous configurez les limites de ressources pour le pod, vous devez en tenir compte.
- La somme de toutes les limites de ressources des conteneurs principaux ainsi que des conteneurs side-car (puisque tous les conteneurs fonctionnent en parallèle)
Quand devrions-nous utiliser ce modèle
Voici quelques-uns des scénarios dans lesquels vous pouvez utiliser ce modèle
- Chaque fois que vous souhaitez étendre les fonctionnalités du pod de conteneur unique existant sans toucher à celui existant.
- Chaque fois que vous souhaitez améliorer les fonctionnalités du pod de conteneur unique existant sans toucher à celui existant.
- Vous pouvez utiliser ce modèle pour synchroniser le code du conteneur principal avec l’extraction du serveur git.
- Vous pouvez utiliser ce modèle pour envoyer des événements de journal au serveur externe.
- Vous pouvez utiliser ce modèle pour les tâches liées au réseau.
Résumé
- Un pod qui contient un conteneur fait référence à un pod conteneur unique et c’est le cas d’utilisation de Kubernetes le plus courant.
- Un pod qui contient plusieurs conteneurs co-liés fait référence à un pod multi-conteneurs.
- Le modèle de conteneur Sidecar est l’un des modèles que nous utilisons régulièrement pour étendre ou améliorer les conteneurs préexistants.
- Les conteneurs Sidecar fonctionnent en parallèle avec le conteneur principal. Vous devez donc prendre en compte les limites de ressources des conteneurs side-car lors de la définition des limites de demande / ressource pour le pod.
- Les conteneurs d’application et les conteneurs Sidecar s’exécutent en parallèle, ce qui signifie que tous les conteneurs s’exécutent en même temps. Vous devez donc résumer toutes les limites de demande / ressource des conteneurs tout en définissant les limites de demande / ressource pour le pod.
- Vous devez configurer les vérifications de l’état des conteneurs side-car en tant que conteneurs principaux pour vous assurer qu’ils sont sains.
- Tous les pods de l’objet de déploiement n’ont pas d’adresses IP statiques, vous avez donc besoin d’un objet de service à exposer au monde extérieur.
- L’objet de service est mappé en interne sur le port du conteneur de port en fonction des sélecteurs.
- Vous pouvez utiliser ce modèle là où votre application ou vos conteneurs principaux doivent étendre ou améliorer la fonctionnalité actuelle.
Conclusion
Il est toujours bon de connaître les modèles Kubernetes déjà éprouvés. Assurez-vous que tous vos conteneurs side-car sont simples et suffisamment petits, car vous devez additionner toutes les ressources / limites de demande tout en définissant les limites de ressources pour le pod. Vous devez vous assurer que les conteneurs Sidecar sont également sains en configurant des vérifications de l’état. Il est donc important de savoir quand combiner vos fonctionnalités dans le conteneur principal ou avoir un conteneur séparé.
Vous pouvez lire aussi sur comment adopter GitOps pour Kubernetes
