Une traduction de l'article a été préparée spécialement pour les étudiants du cours Kubernetes Based Infrastructure Platform .
La configuration d'un microservice de base dans Kubernetes est d'une simplicité trompeuse. Dans un article récent, nous avons expliqué à quel point il est facile de commencer à travailler avec des conteneurs. Nous avons assemblé une image Docker simple, l'avons déployée à l'aide de Kubernetes et avons exécuté la demande d'application. Ce n'était pas difficile, mais dans la vie, les architectures cloud sont généralement plus compliquées. Ils comprennent des dizaines, voire des centaines de services avec des bases de données, l'authentification et d'autres éléments qui sont nécessaires dans la réalité.
Les administrer est parfois un mal de tête continu. Dans cet article, nous parlerons d'Istio, un outil pour le maillage de service (nous avons examiné cette architecture plus tôt ) qui fait passer la gestion des déploiements cloud de grande envergure au niveau supérieur.
Les microservices vous offrent une grande évolutivité, et le maillage de service les complète avec les avantages de centralisation typiques des environnements monolithiques (comme les journaux et le contrôle de version). Nous avons écrit plus sur les fonctionnalités et les avantages du maillage de service dans un article précédent de cette série.
La même publication se concentre sur les capacités d'Istio à implémenter un modèle d'architecture cloud à l'aide de réseaux maillés. Nous apprendrons à configurer le plan de contrôle, à considérer les points forts d'Istio et, enfin, à utiliser le service Kubernetes avec lequel nous avons travaillé la dernière fois, à lui ajouter un proxy side-car et à l'associer au plan de contrôle nouvellement créé.
Présentation du plan de données et du proxy side-car
Les deux principaux termes architecturaux d'Istio sont le plan de données et le plan de contrôle. Le plan de données fonctionne avec les données qui sont déplacées dans l'application, transférées vers diverses instances de service et traitées par les services eux-mêmes. Pour sa mise en œuvre, des procurations sidecar sont principalement utilisées. Au niveau de la gestion, l'ordre d'instanciation du service, l'emplacement des données de télémétrie et des informations de service sont déterminés. Les principaux éléments du plan de contrôle sont Pilot et Mixer. Voyons comment tout cela fonctionne.
Le proxy Sidecar fonctionne avec le foyer qui définit votre service dans Kubernetes. Il est ajouté aux principaux composants du service et fonctionne avec le trafic qui va à ce service. Vous pouvez ajouter un sidecar-proxy à la définition de service existante dans l'âtre: seules les lignes définissant le sidecar-proxy seront ajoutées au service et il commencera à fonctionner.
En retour, vous obtiendrez une liste des avantages qui sous-tendent le réseau de maillage cloud Istio. Le proxy Sidecar intercepte le trafic entrant dans le service et permet un routage intelligent. Nous parlons de tâches simples, telles que l'équilibrage de charge ou la gestion des interruptions TLS, qui accélèrent considérablement le travail, et des processus plus complexes, tels que le contrôle de version, le déploiement progressif d'une nouvelle version d'un service et la collecte d'indicateurs d'utilisation des ressources. Sidecar-proxy vous permet d'ajouter toutes ces fonctionnalités à l'architecture existante des microservices sans réorganiser l'ensemble du système .
À mesure que l'objectif initial du proxy side-car devient clair, les avantages d'Istio et du maillage de services cloud dans son ensemble deviennent évidents. En fait, toutes les architectures de sidecar-proxy regroupées, fonctionnant comme des éléments de connexion unifiés entre les modules de service, transitent par tout le trafic passant par l'application. Cela signifie que, si nécessaire, pour renforcer la protection, ils agissent comme un emplacement unique où vous pouvez ajouter des processus d'authentification et le protocole HTTPS entre les services, conserver un journal des événements pour vérifier les anomalies et déployer des outils de contrôle du trafic et de filtrage pour l'authentification.
De plus, comme les proxys sidecar agissent comme des points de terminaison centraux pour la communication entre les services, ils augmentent la résilience de l'application et ajoutent un niveau supplémentaire d'évolutivité. L'un des inconvénients des microservices est que tous les modules de serveur sont isolés, et si quelque chose ne va pas avec le microservice, les demandes peuvent être traitées lentement ou complètement réinitialisées. Grâce aux proxys sidecar, vous pouvez ajouter des délais d'expiration de manière centralisée, configurer un équilibrage de charge intelligent et étendre les capacités de surveillance.
Centralisation: le plan de contrôle
En plus du plan de données, Istio comprend un plan de contrôle. Il joue le rôle d'un contrôleur pour tous les mandataires de side-car exécutés dans l'application et d'un référentiel central pour toutes les informations (telles que les entrées de journal et les informations de version), qui est perçu par les services sur le réseau comme une source unique de données fiables.
Lorsque vous travaillez avec Istio, Kubernetes est le principal moyen d'interagir avec le plan de contrôle. Après avoir installé les packages Istio et ajouté des définitions, vous pouvez utiliser les commandes kubectl qui contrôlent l'état du système pour accéder au plan de contrôle. Par exemple, le processus de mise à jour d'un foyer vers une nouvelle version à l'aide de kubectl commence par la mise à jour des variables du plan de contrôle local.
C'est plus facile à voir en utilisant la commande get-svc dans kubectl - vous obtiendrez une liste de services liés à une bibliothèque particulière. Pour vérifier quels composants Istio sont en cours d'exécution, vous pouvez utiliser la commande suivante:
kubectl get svc -n istio-system
Une liste des principaux éléments du plan de contrôle Istio exécutés en arrière-plan s'affiche. Vous en connaissez peut-être déjà certains, comme Citadel, un service qui gère la protection du trafic entre les services.
Installer Istio
Voyons quelles fonctionnalités Istio prend en charge par défaut. Nous allons installer le plan de contrôle Istio pour administrer l'API HTTP de base décrite dans l' article précédent. Ce service d'API a été défini dans Kubernetes et implémenté comme un seul sous Kubernetes avec une API en cours d'exécution.
Pour installer Istio, suivez les étapes du guide officiel rapide. Commencez par télécharger la dernière version d'Istio à partir de la page appropriée. Le programme est toujours en développement actif, donc fonctionne mieux avec ses dernières versions. Téléchargez simplement le fichier et assurez-vous qu'il est disponible dans le bon répertoire.
Ajoutez ensuite des définitions Istio à Kubernetes afin de pouvoir les utiliser avec l' kubectl ligne de commande kubectl . Ajoutez les fichiers .yaml précédemment obtenus .yaml répertoire d'installation à l'aide de la kubectl apply :
kubectl apply -f install/kubernetes/helm/istio/templates/crds.yaml
Activez ensuite l'installation d'Istio en choisissant une méthode d'authentification. J'utiliserai l'authentification HTTPS mutuelle par défaut, idéale pour les démonstrations et le démarrage. Pour ajouter un maillage de service à un projet existant, vous devez trouver quelques autres options disponibles. À ce stade, vous pouvez exécuter la commande suivante:
kubectl apply -f install/kubernetes/istio-demo-auth.yaml
Après cela, vous pouvez continuer. Vous devrez ajouter la structure Istio aux pods créés précédemment et, pour les nouveaux pods, ajouter Istio en tant que dépendance.
Déploiement d'applications Helloworld
Nous utiliserons l'application d'essai helloworld, qui est décrite dans notre publication précédente. Sera créé: un déploiement, un service, une passerelle et un service virtuel. Mettez à jour le fichier de configuration pour qu'il corresponde aux éléments suivants:
helloworld.yaml
apiVersion: v1 kind: Service metadata: name: helloworld spec: type: ClusterIP ports: - port: 80 targetPort: 8080 selector: app: helloworld --- apiVersion: apps/v1 kind: Deployment metadata: name: helloworld-v1 spec: replicas: 1 selector: matchLabels: app: helloworld template: metadata: labels: app: helloworld version: v1 spec: containers: - name: helloworld-kubernetes - image: haseebm/helloworld-kubernetes ports: - containerPort: 8080 --- apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: helloworld-gateway spec: selector: istio: ingressgateway # use istio default controller servers: - port: number: 80 name: http protocol: HTTP hosts: - "*" --- apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: helloworld spec: hosts: - "*" gateways: - helloworld-gateway http: route: - destination: host: helloworld port: number: 80
Proxy proxy Istio manuel
Istio utilise l'exemple de proxy sidecar pour placer le conteneur proxy Istio sidecar dans un foyer avec le conteneur d'application helloworld.
$ kubectl apply -f <(istioctl kube-inject -f helloworld.yaml) service/helloworld created deployment.extensions/helloworld-v1 created gateway.networking.istio.io/helloworld-gateway created virtualservice.networking.istio.io/helloworld created
Vérifiez que les pods et le service sont effectués:
$ kubectl get pod,svc | grep helloworld pod/helloworld-v1-1cbca3f8d5-achr2 2/2 Running service/helloworld ClusterIP 10.160.58.61
Maintenant, vérifiez le trafic pour l'application helloworld:
$ curl a2******.ap-southeast-1.elb.amazonaws.com/api/hello
Bonjour tout le monde v1
Prochaines étapes
Istio est un excellent moyen de découvrir les réseaux maillés de technologie cloud et la gestion intelligente des microservices en général. Comme nous l'avons déjà écrit plus d'une fois, les microservices correctement administrés présentent de nombreux avantages techniques, notamment en termes de mise à l'échelle. Cependant, pour obtenir ces avantages, vous devez utiliser efficacement les technologies existantes.
À l'avenir, nous examinerons d'autres scénarios d'utilisation d'Istio et des réseaux maillés cloud pour améliorer la sécurité et la gérabilité de notre architecture d'essai. Ainsi, le prochain article se concentrera sur la gestion du déploiement et la gestion des versions dans Istio pour distribuer efficacement les mises à jour de code sans interruption ni dommage aux déploiements.
Asad Faizi
Fondateur et PDG, CloudPlex.io, Inc
asad@cloudplex.io
www.cloudplex.io