Kubernetes: What's the point?
Kubernetes' main interest is to allow companies to focus on how they want applications to work, rather than on specific implementation details. Through abstractions to manage container groups, the behaviours they need are dissociated from the components that provide them.
Kubernetes thus allows to automate and simplify several tasks. First of all, we can mention deployment of multi-container applications. Many applications reside in several containers (database, web front end, cache server...), and microservices are also developed on this model. Generally, the different services are linked by API and web protocols.
This approach has long-term benefits, but requires a lot of work on the short term. Kubernetes reduces the effort required. The user tells Kubernetes how to compose an application from a set of containers, and the platform supports deployment and ensures synchronization of components between them.
This tool Also simplifies the scattering of containerized applications. Applications need to be scaled up to track demand and optimize resource use. Kubernetes allows to automate this scaling. The platform also allows the continuous deployment of new application versions, eliminating maintenance times. Its mechanisms allow to update the images of containers and even to go back in case of a problem.
Kubernetes and its APIs also allow container networking, service discovery and storage. Finally, not being related to a specific cloud environment or technology, Kubernetes can be launched in any environment : public cloud, private stacks, physical or virtual hardware... it is even possible to mix environments.
Kubernetes: How does it work?
Kubernetes is a container management system. The purpose of the software is therefore not to create containers, simply to manage them. To achieve this, Kubernetes uses theprocess automation. This makes it easier for developers to test, maintain or publish applications. Kubernetes architecture has a clear hierarchy:
- Container A container contains software applications and environments.
- Pod : in the Kubernetes architecture, this unit gathers containers to work together for an application.
- Node One or more pods run on a node (node) that can be both a virtual or physical machine.
- Cluster : in Kubernetes, several nodes are gathered in a cluster.
A Kubernetes cluster must have a master The system that controls and controls all other cluster machines. A highly available Kubernetes cluster replicates the master's functions on different machines, but only one master at a time performs the controller-manager and the scheduler.
Each cluster contains nodes Kubernetes. They can be physical or virtual machines. The nodes perform pods: the most basic Kubernet objects that can be created or managed. Each pod is a single instance of an application or process running on Kubernetes, and consists of one or more containers. All containers are launched and replicated in group in the pod. Thus, the user can focus on the application rather than the containers.
The controller is another abstraction to manage how pods are deployed, created or destroyed. Depending on the different applications to be managed, there are different pods. One other abstraction is the service, which ensures the persistence of applications even if pods are destroyed. The service describes how a pod group can be accessed via the network.
There are other key components of Kubernetes. The scheduler distributes workloads between nodes to ensure balance between resources, and ensure that deployments match the needs of applications. The controller manager ensures that the state of the system (applications, workloads...) corresponds to the desired state defined in the Etcd configuration parameters.
Every week, more than 2 billion containers are deployed by Google via Borg, a platform known as Kubernetes' big sister.
Moreover, its development has served as the foundation for Kubernetes technology.
Google has thus become master in the art of using containers for its production workloads and services like Gmail, Search, Apps or Maps all spin in containers.
Kubernetes eliminates many manual processes related to the deployment and scaling of containerized applications.
To make it easier, it helps you manage clusters easily and efficiently, in which you have gathered host groups running Linux containers. These can cover hosts located in public, private or hybrid cloud.
Kubernetes is therefore the perfect platform for hosting cloud-native applications that require rapid scaling, such as streaming data in real time via Apache Kafka.
Usefulness of containers
Before explaining what Kubernetes does, we need to explain what containers are and why they are so used.
First, ask an administrator who has managed a multitude of virtual machines without containers to explain his experience and he will tell you that it is a real nightmare.
With containers, it's different...
A container is a virtual mini machine.
Unlike all other traditional virtual machines, it does not have drivers or peripherals and other components, which makes it smaller, lighter, faster, more efficient and easier to manage.
When Amazon Web Service introduced Amazon EC2 to the public in 2008, it was not expected that this portal, allowing for the provision of virtual servers simply, would revolutionize the work of developers and administrators.
Containerization is a means of running applications on an operating system so that the application is isolated from the rest of the system.
Your application thinks it has its own operating system instance, while there are other containers running on the same system.
It ensures the rapid and stable deployment of applications in any computer environment.
Containers have changed the way in which software is developed, deployed and maintained, which is why this method has been a real success for years.
But this new way of doing things requires appropriate tools to automate deployment, management, networking, scaling and the availability of container-based applications.
They are called container orchestration tools and it is exactly the role of Kubernetes!
And since it is open source, it can be used freely by anyone, anywhere.
How does Kubernetes work?
Kubernetes' main idea is to virtualize machines, storage and networks.
It will therefore deploy containers on all kinds of cloud, virtual machines or physical machines.
And to understand how it works, there are some Kubernetes concepts that you need to know already.
So here's some vocabulary:
- Node
A knot is a physical or virtual machine. Attention It is you who create them and not Kubernetes, so you will need to upstream define your basic infrastructure to deploy your applications. - Pods
The pods work on knots. It is one or more containers that work together as a logical unit.
A node can run several pods. They have the same shared content, all share the sharing IP address, but can also reach others via localhost.
They can also share storage, but won't need to all run on the same machine, as containers can spread over more than one machine.
- Deployment
We call deployment a set of pods. Its role is to ensure that a sufficient number of pods run at the same time to serve the application and stop those that are not necessary (by examining the use of the processor for example).
Operating mode.
First of all, the main abstraction on which Kubernetes rests is the cluster. It is a group of machines that run Kubernetes and the containers it manages.
A cluster must have a master, i.e. a system that controls and controls all other cluster machines.
Each cluster contains Kubernetes nodes that can be physical or virtual machines.
The knots, on the other hand, perform pods.
Each pod represents a single instance of an application or process running on Kubernetes, and consists of one or more containers.
All containers are thrown and replicated in group in the pod. allowing you to focus on the application rather than on containers.
The controller is another abstraction that allows this time to manage how pods are deployed, created or destroyed.
The service is an abstraction that ensures the persistence of applications even if pods are destroyed.
It describes how a group of pods can be accessed via the network.
There are other key components of Kubernetes such as the scheduler that distributes workloads between nodes to ensure balance between resources, and ensure that deployments match the needs of applications.
The controller manager ensures that the system status (applications, workloads...) matches the desired state that has been defined in the Etcd configuration settings.
Why use Kubernetes?
Kubernetes' main interest is to allow you to focus on how you want applications to work, rather than specific implementation details.
Through abstractions that manage container groups, the behaviours they need are separated from the components that supply them.
Kubernetes automates and simplifies several tasks, but it also allows:
- Deploy multi-container applications
- Reduce your efforts by telling Kubernetes how to compose an application from a set of containers, the platform will then support the deployment and ensure the synchronization of components between them.
- Simplifier le scaling d’applications containerisées en mettant à l’échelle pour suivre la demande et optimiser l’usage des ressources des applications qui en ont besoin
- Automatiser cette mise à l’échelle
- Permettre le déploiement continu de nouvelles versions d’applications et éliminant les temps de maintenance
- Permettre le networking des conteneurs, la découverte de service et le stockage.
- Automatiser le provisionnement de serveurs Web en fonction du niveau de trafic Web en production
- Mettre à l’échelle les serveurs Web en fonction de la demande pour les applications logicielles, puis dégrade les instances de serveur Web pendant les temps d’arrêt.
- Disposer de capacités avancées d’équilibrage de charge pour le routage du trafic Web vers les serveurs Web lors des opérations
- Orchestrer des conteneurs sur plusieurs hôtes
- Optimiser l’utilisation de votre matériel afin de maximiser les ressources requises pour l’exécution de vos applications
- Contrôler et automatiser les déploiements et mises à jour d’applications
- Monter et ajouter des systèmes de stockage pour exécuter des applications avec état
- Mettre à l’échelle des applications conteneurisées et leurs ressources
- Gérer des services de façon déclarative et garantir ainsi que les applications déployées s’exécutent toujours de la manière dont vous les avez déployées
- Vérifier l’intégrité de vos applications et les réparer automatiquement grâce au placement, au démarrage, à la réplication et à la mise à l’échelle automatique
Comme avec toutes les machines virtuelles les conteneurs peuvent rencontrer des problèmes qui doivent être suivis et gérés.
Par exemple quand une entreprise de cloud public vous facture le temps processeur ou le stockage vous devez être sûr qu’il n’y a pas de machines orphelines qui tournent pour rien ou à contrario de fournir automatiquement plus de mémoire quand une machine en a besoin et de les alléger lorsque la charge le permet.
Et bien tout cela c’est de l’orchestration et c’est là que Kubernetes va jouer son rôle.
Kubernetes pour prendre des mesures concrètes pour améliorer votre sécurité informatique.
La sécurité des conteneurs peut-être complexe, car elle comporte plusieurs couches.
Kubernetes va vous permettre avec ses outils d’orchestration et de gestion de déployer des conteneurs à grande échelle.
En effet, ses outils vous permettent de créer des services applicatifs sur plusieurs conteneurs, de planifier leur exécution dans un cluster, de les mettre à l’échelle et de gérer leur intégrité.
Kubernetes doit pouvoir s’intégrer aux services de mise en réseau, de stockage, de sécurité et de télémétrie, pour fournir une infrastructure de conteneurs complète.
Une application de conteneurs Linux classique les traite comme des machines virtuelles rapides et efficaces. Mais si vous évoluez vers un environnement de production avec de nombreuses applications, vous allez avoir besoin de plusieurs conteneurs colocalisés qui fonctionnent ensemble pour fournir des services individuels.
Et forcément, votre infrastructure se complexifie au fur et à mesure où le nombre de conteneurs dans votre environnement augmente.
Quelle différence entre Docker et Kubernetes ?
Docker a largement contribué à la démocratisation de conteneurs Linux.
Il n’a pas créé la technologie, mais il a construit un ensemble d’outils et d’API qui ont rendu les conteneurs beaucoup plus faciles à gérer et il est arrivé au moment où l’industrie cherchait un moyen de mieux gérer le Cloud et ses workloads Web.
Docker c’est aussi une société qui a contribué à un ensemble divers d’outils de gestion des cycles de vie des conteneurs.
Docker est d’ailleurs le conteneur le plus populaire.
On compare souvent les deux, Docker et Kubernetes, à tort, car en fait ils sont complémentaires.
Là où Docker Swarm gère le cycle de vie des conteneurs Linux, Kumbernetes fonctionne en complément et gère l’orchestration.
L’un n’est pas une alternative à l’autre. Bien au contraire, Kubernetes peut fonctionner sans Docker et Docker peut fonctionner sans Kubernetes. Mais ils peuvent grandement bénéficier l’un de l’autre.
Docker est un logiciel autonome qui peut être installé sur n’importe quel ordinateur pour exécuter des applications conteneurisées. Il permet d’exécuter, de créer et de gérer des conteneurs sur un seul système d’exploitation.
Mais si Docker est installé sur un groupe d’hôtes (différents systèmes d’exploitation), vous pouvez tirer parti de Kubernetes.
Ces nœuds, ou hôtes Docker, peuvent être des serveurs sans système d’exploitation ou des machines virtuelles.
Comme nous l’avons vu plus haut, Kubernetes vous permet d’automatiser le provisionnement de conteneurs, la mise en réseau, l’équilibrage de charge, la sécurité et la mise à l’échelle sur tous ces nœuds à partir d’une seule ligne de commande ou du tableau de bord.
Mais quelle nécessité d’avoir plusieurs nœuds ?
Tout d’abord pour rendre l’infrastructure plus robuste.
Votre application sera en ligne, même si certains des nœuds sont hors ligne.
Ensuite pour rendre votre application plus évolutive : si la charge de travail augmente, vous n’aurez qu’à créer simplement plus de conteneurs et/ou ajoutez plus de nœuds à votre cluster Kubernetes.
Kubernetes automatise le processus de mise à l’échelle, de gestion, de mise à jour et de suppression des conteneurs.
Et si Docker est au cœur de la conteneurisation, il nous permet d’avoir en premier lieu des conteneurs.
En principe, Kubernetes peut fonctionner avec n’importe quelle technologie de conteneurisation.
Mais les deux options les plus populaires avec lesquelles Kubernetes peut s’intégrer sont rkt et Docker. 4
Mais Docker a pu déployer beaucoup plus d’efforts pour perfectionner son intégration avec Kubernetes, bien plus que toute autre technologie de conteneurisation.
D’ailleurs, Docker Inc., a réalisé l’ampleur que Kubernetes avait prise au point de livrer avec sa propre distribution Kubernetes son logiciel Docker for Desktop (MacOS et Windows).
Donc, si vous étiez hésitant à l’idée d’adopter Kubernetes pour votre produit basé sur Docker, ce dernier point devrait dissiper tous vos doutes.
Les deux projets se sont rencontrés et ont énormément bénéficié de leur symbiose.
Les conteneurs sont une avancée incroyable, car ils permettent de penser les services et les systèmes d’une manière complètement nouvelle et surtout numérique.
Kubernetes a donc de beaux jours devant lui et ne cessera de s’améliorer encore dans l’avenir.
FIDESIO vous accompagne dans la création de votre site Internet grâce à ses équipes de développeurs spécialisés dans les dernières technologies.
Notre agence Web est capable de répondre à tous vos besoins et d’élaborer une véritable stratégie digitale.
En quoi Kubernetes est-il différent de Docker Swarm ?
Docker Swarm a été créé par Docker Inc et s’est développé comme un orchestrateur pour Docker. Kubernetes a été créé à l’origine par Google pour un usage interne (le projet Borg), et maintenant tout le monde Open Source y travaille. Docker Swarm est un système fermé.
Tous deux tentent de résoudre le même problème : l’orchestration de conteneurs sur un grand nombre d’hôtes. Il s’agit de deux systèmes fondamentalement similaires, mais il existe tout de même des différences.
Kubernetes se développe beaucoup plus rapidement et occupe la majeure partie du marché (Kubernetes 51% et Docker Swarm 11%).
Docker Swarm est moins évolutif, il n’y a pas de support intégré pour l’équilibrage de charge, ce que K8S possède. En fait, Docker Swarm ne propose qu’une seule méthode d’équilibrage de charge, qui repose sur l’ouverture d’un port fixe pour chaque service sur chaque serveur inclus dans le cluster.
Contrairement à Docker Swarm, K8S offre une implémentation intégrée pour l’équilibrage de charge interne (est-ouest) et externe (nord-sud). L’équilibrage interne est assuré par l’objet Service et permet d’atteindre, à partir d’une application dans un cluster, toutes les instances vivantes d’une autre application en se référant à l’objet Service. Le Service est un équilibreur de charge interne, qui sait à chaque instant quel backend de l’application est vivant et lequel ne fonctionne pas et envoie les requêtes uniquement aux répliques vivantes.
L’équilibrage de charge externe dans Kubernetes est assuré par le concept NodePort (ouverture d’un port fixe sur l’équilibreur de charge), ainsi que par la primitive LoadBalancer intégrée, qui peut créer automatiquement un équilibreur de charge sur le site cloud si Kubernetes fonctionne dans un environnement cloud , par exemple AWS, Google Cloud, MS Azure, OpenStack, Hidora, etc. Docker Swarm ne fait pas support Auto-Scaling. Ni l’auto-scaling des conteneurs, ni l’auto-scaling des nœuds.
Kubernetes prend en charge toutes les mises à l’échelle automatiques possibles : mise à l’échelle verticale grâce à Vertical Pod Autoscaler, mise à l’échelle automatique horizontale des applications (Horizontal Pod Autoscaler), ainsi que la mise à l’échelle automatique du cluster lui-même (le nombre de nœuds) basée sur Cluster AutoScaler. Cluster Autoscaler ne fonctionne que si vous exécutez Kubernetes sur le site cloud.
Docker Swarm a des difficultés avec la surveillance, vous pouvez surveiller les conteneurs uniquement à l’aide d’outils propriétaires. Le stockage persistant pour les applications à état n’est pas pris en charge de manière native par Docker Swarm. Vous devez travailler avec un système de stockage en réseau, qui n’est pas adapté à tous les types de charges de travail.
Docker Swarm ne fonctionne qu’avec les conteneurs Docker. Alors que K8S peut fonctionner avec de nombreuses options d’exécution de conteneurs, comme Docker, Rocket, ContainerD, et d’autres. Ceci est très important car il n’y a pas de dépendance vis-à-vis de fonctionnalités spécifiques de Docker (certaines d’entre elles ne sont disponibles que dans Docker EE).
Pourquoi avez-vous besoin de l’orchestration des conteneurs ?
Déployez des applications sur des serveurs sans vous soucier de serveurs spécifiques.
Vous avez besoin d’orchestrateurs de conteneurs lorsque vous disposez d’une application microservice composée de plusieurs services, eux-mêmes composés de conteneurs. Et il y a une autre partie – les serveurs sur lesquels cette application peut s’exécuter.
L’orchestrateur de conteneurs effectue de nombreuses tâches. La première tâche consiste à placer initialement les conteneurs de votre application sur le nombre requis de serveurs, en tenant compte de la charge des serveurs, afin d’éviter que le conteneur n’atteigne le serveur surchargé, et en considérant également les besoins en mémoire et en processeur pour un conteneur particulier.
Faire évoluer l’application horizontalement vers le haut et vers le bas.
Il existe un autre scénario, lorsqu’une application doit être mise à l’échelle horizontalement, c’est-à-dire qu’il faut ajouter d’autres conteneurs du même type.
L’orchestrateur de conteneurs se charge d’augmenter ou de diminuer la taille des applications en tenant compte des ressources consommées sur chaque serveur cible, ainsi que des besoins en ressources de chaque application.
Dans ce cas, l’orchestrateur peut support les principes dits d’affinité et d’anfi-affinité. Ce dernier permet de garantir que, par exemple, tous les conteneurs du même type seront lancés de manière garantie sur des serveurs physiques différents.
Restaurer l’application si le serveur sur lequel elle fonctionnait tombe en panne.
C’est ce qu’on appelle l’auto-réparation ou la reprogrammation du conteneur.
Si le serveur tombe en panne, vous devez restaurer correctement l’application. K8S peut surveiller chaque conteneur/pod d’application pour voir si ce conteneur/pod est vivant ou non. Et si ce n’est pas le cas, Kubernetes le redémarre.
En fait, dans K8S, cette fonction s’appelle « maintenir le bon nombre de répliques ».
Dans le cas de Kubernetes, vous pouvez dire, je veux avoir 5 conteneurs de mon WordPress, et K8S s’assurera que vous avez toujours 5 conteneurs.
Si soudainement il y a moins de 5 conteneurs, Kubernetes lancera un nouveau conteneur pour maintenir la quantité. Ceci est important pour le traitement de l’application et la prévision de la charge.
K8S surveille également l’état des serveurs sur lesquels l’application est exécutée, et si le serveur est mort, il reprogrammera tous ses conteneurs sur d’autres serveurs.
Comment K8S se compare-t-il à OpenStack ?
Kubernetes est conçu pour gérer l’orchestration des conteneurs, et OpenStack est initialement conçu pour gérer les machines virtuelles. En d’autres termes, OpenStack est utilisé pour gérer les infrastructures virtuelles traditionnelles, et Kubernetes pour les conteneurs.
Il s’agit de deux systèmes différents, qui sont tous deux des systèmes Open Source, développés par la communauté. La différence est que Kubernetes a été développé à l’origine par Google pendant longtemps sous le nom de Borg et pendant cette période, il est devenu un service stable, même la première version était riche en fonctionnalités et assez stable.
OpenStack a été développé presque à partir de zéro par la communauté et OpenStack est très fragmenté.
La communauté et environ 30 entreprises différentes créent leurs propres versions. K8S est plus comme Apple, et OpenStack est plus comme Android.
Les frais généraux et les délais de mise sur le marché pour l’exploitation de Kubernetes en production sont beaucoup plus faibles qu’avec OpenStack.
En même temps, OpenStack gère les machines virtuelles, par exemple, KVM, Kubernetes peuvent fonctionner au-dessus d’OpenStack et c’est un scénario typique pour les fournisseurs cloud .
Kubernetes est-il uniquement destiné aux applications sans état ?
Kubernetes n’est pas seulement adapté aux applications sans état. Un exemple d’application sans état est généralement constitué par les applications web qui exécutent une fonction, fournissent des pages HTTP et ne stockent pas elles-mêmes leurs états.
Il a été conçu à l’origine pour les applications sans état et support pour les applications avec état était très limité et peu fiable.
Kubernetes prend en charge le concept de volume persistant et de réclamations de volume persistant. Il prend également en charge différents types de volumes, comme les stockages de blocs qui peuvent être montés sur des pods en mode exclusif, ainsi que les stockages de fichiers qui peuvent être montés sur plusieurs pods simultanément en utilisant le protocole NFS, par exemple.
Par conséquent, vous pouvez placer en toute sécurité des bases de données ou des files de messages persistantes dans Kubernetes.
Puis-je l’utiliser pour un déploiement hybride Cloud ? Multi-Cloud?
Initialement, K8S ne pouvait être déployé que dans un seul centre de données et le travail en mode hybride n’était pas disponible.
Ensuite, la fédération Kubernetes a été développée, ce qui a permis d’organiser un scénario hybride lorsqu’il y a plusieurs clusters Kubernetes dans différents centres de données qui sont contrôlés à partir d’un seul panneau de contrôle.
En fait, l’un des clusters devient le cluster fédéré principal et le panneau de contrôle hybride cloud y est installé. Grâce à lui, vous pouvez gérer les déploiements dans plusieurs clusters éloignés les uns des autres.
Mais c’est également possible dans le scénario multicloud . Supposons que vous ayez un cluster sur site, un cluster sur Amazon, un autre sur Google Cloud, tous seront pris en charge.
Dans le cas de plusieurs fournisseurs cloud , il n’est pas nécessaire d’adapter l’application pour travailler à la fois avec plusieurs clusters distants qui travaillent chez Google, Amazon, car le Kubernetes interprétera correctement les annotations dans leurs ressources pour chaque cloud.
Le projet de fédération Kubernetes v1 est en développement depuis longtemps et il est dans une impasse, la fédération Kubernetes v2 est en cours de développement, qui fonctionne fondamentalement d’une manière différente avec un hybride cloud.
Dois-je gérer un équilibreur de charge externe pour exécuter mes applications dans Kubernetes ?
Dans le cas de Docker Swarm, il était nécessaire de gérer un équilibreur de charge externe afin d’équilibrer la charge.
K8S contient un équilibrage automatique de la charge basé sur le concept des services et, en outre, un contrôleur d’entrée qui prend en charge l’équilibrage de la charge par nom et chemin DNS.
De nombreuses options sont prises en charge, il y a également une intégration avec l’équilibreur de charge cloud , si vous travaillez quelque part sur Amazon, google cloud ou open-stack, il y a une intégration prête à l’emploi avec ces équilibreurs de charge.
Quelle est la différence entre une cosse et un conteneur ?
Le problème est que les personnes qui viennent du monde de Docker ne travaillent qu’avec des conteneurs.
Ils essaient de transférer les connaissances qu’ils ont acquises en utilisant Docker Swarm et les conteneurs pour travailler avec Kubernetes. Mais cela ne fonctionne pas de cette façon. Dans Kubernetes, l’unité de contrôle est le pod, pas le conteneur.
Un pod est un groupe d’un ou plusieurs conteneurs qui remplissent la même fonction, c’est-à-dire qu’il s’agit d’un composant d’une seule application. Kubernetes gère les pods, les met à l’échelle et surveille leur état. L’application dans Kubernetes est mise à l’échelle par le nombre de pods, mais pas de conteneurs.
Dans un pod, il y a le plus souvent un conteneur, mais il peut y en avoir plusieurs et cet ensemble de conteneurs est fixé de manière rigide. À l’intérieur d’un pod, les conteneurs ne changent pas d’échelle, ce qui doit être pris en compte lors de la conception des applications.
Comment Kubernetes simplifie-t-il le déploiement de conteneurs ?
Plusieurs avantages que Kubernetes offre d’emblée :
- Dans Kubernetes, la découverte de services est intégrée, c’est-à-dire que lorsqu’un nouveau service apparaît, un nom de domaine unique lui est attribué et les autres services peuvent obtenir des informations sur ce service dans etcd.
- Le deuxième point est que Kubernetes offre des manifestes flexibles pour le déploiement d’applications qui support différentes stratégies de déploiement d’applications conteneurisées. Kubernetes dispose d’un déploiement canari support pour les tests a/b. Il existe également des contrôles de santé intégrés et une surveillance basée sur Prometheus.
- Kubernetes utilise une stratégie de mise à jour continue pour déployer les mises à jour des versions des pods. La stratégie de mise à jour continue permet d’éviter les temps d’arrêt de l’application en maintenant certaines instances en fonctionnement à tout moment pendant l’exécution des mises à jour. Lorsque les nouveaux pods de la nouvelle version de déploiement sont prêts à gérer le trafic, le système les active d’abord et n’arrête les anciens qu’ensuite.
N’hésitez pas à nous contacter. info@ sogesti.ch
