Istio on IBM Cloud

Istio est une couche de maillage de services configurable et open source qui connecte, surveille et sécurise les conteneurs dans un cluster Kubernetes. Istio fonctionne uniquement nativement avec Kubernetes, mais sa nature open source permet à quiconque d'écrire des extensions, ce qui fait qu'Istio peut fonctionner sur n'importe quel logiciel de cluster.

Kubernetes est un outil d' orchestration de conteneurs , dont l'une des unités de base est le nœud. Un nœud est constitué d'un ou plusieurs conteneurs, ainsi que d'autres composants. Kubernetes gère la disponibilité et la consommation de ressources des nœuds, en ajoutant des pods au fur et à mesure que la demande augmente grâce à l'autoscaler de pods. Istio injecte des conteneurs supplémentaires dans le pod pour ajouter de la sécurité, de la gestion et de la surveillance.

Comme il s'agit d'un logiciel open source, Istio peut fonctionner sur n'importe quel fournisseur de cloud public qui le prend en charge et sur n'importe quel cloud privé dont les administrateurs sont prêts à s'occuper.

Lorsque les organisations passent aux microservices, elles doivent prendre en charge des dizaines ou des centaines d'applications spécifiques. La gestion séparée de ces terminaux implique la prise en charge d'un grand nombre de machines virtuelles (VM), y compris à la demande. Un logiciel de cluster comme Kubernetes peut créer des pods et les faire évoluer, mais Kubernetes ne fournit pas de routage, de règles de trafic, ni d'outils de surveillance ou de débogage solides.

Saisir le maillage du service.

Avec l'augmentation du nombre de services, le nombre de moyens de communication potentiels augmente de manière exponentielle. Deux services n'ont que deux voies de communication. Trois services en ont six, tandis que 10 services en ont 90. Un maillage de services offre un moyen unique de configurer ces voies de communication en créant une politique pour la communication.

Un maillage de services instrumente les services et dirige le trafic de communication selon une configuration prédéfinie. Au lieu de configurer un conteneur en cours d'exécution ou d'écrire du code pour le faire, un administrateur peut fournir une configuration au maillage de services et lui demander d'effectuer ce travail. Auparavant, cela devait se faire avec les serveurs web et la communication de service à service.

La façon la plus courante de procéder dans un cluster est d'utiliser le modèle sidecar. Un sidecar est un nouveau conteneur, à l'intérieur du pod, qui achemine et observe le trafic de communication entre les services et les conteneurs.

Istio se superpose à Kubernetes, en ajoutant des conteneurs qui sont essentiellement invisibles pour le programmeur et l'administrateur. Intitulés conteneurs sidecar, ils agissent comme un intermédiaire, pour diriger le trafic et surveiller les interactions entre les composants. L'association de ces deux éléments se fait de trois manières différentes.

Configuration : la principale méthode pour définir la configuration avec Kubernetes est la commande kubectl, généralement kubectl -f <filename>, où le fichier est un fichier YAML. Les utilisateurs d'Istio peuvent soit exécuter de nouveaux et différents types de fichiers YAML avec kubectl soit utiliser la nouvelle commande optionnelle ioctl.

Surveillance : Istio permet de surveiller l'état de vos applications exécutées avec Kubernetes. Istio permet de gérer et de visualiser l'état de santé des applications, offrant ainsi une meilleure visibilité que la surveillance générale des clusters et des nœuds qu'offre Kubernetes.

Gestion : l'interface d'Istio étant essentiellement la même que celle de Kubernetes, sa gestion nécessite peu de travail supplémentaire. Istio permet à l'utilisateur de créer des politiques qui affectent et gèrent l'ensemble du cluster Kubernetes, réduisant ainsi le temps de gestion de chaque cluster tout en éliminant le besoin de code de gestion personnalisé.

Istio utilise une version fortement étendue d'Envoy pour effectuer la surveillance, la gestion et la journalisation. Chaque pod doit être suivi, et Istio doit agréger et fournir des informations sur tous les pods. Une alternative possible à l'utilisation d'Istio serait de déployer Envoy dans le cluster Kubernetes directement et d'écrire du code de gestion. Il s'agit essentiellement de recréer Istio, avec les coûts et les bogues associés à un projet de développement personnalisé.