Comment démarrer Istio en utilisant Kubernetes en production. Partie 1

Qu'est-ce que Istio ? C'est ce que l'on appelle le maillage de service, une technologie qui ajoute une couche d'abstraction sur le réseau. Nous interceptons tout ou partie du trafic dans le cluster et effectuons avec lui un ensemble spécifique d'opérations. Lequel? Par exemple, nous faisons un routage intelligent, ou nous implémentons l'approche du disjoncteur, nous pouvons organiser un «déploiement canari», basculer partiellement le trafic vers une nouvelle version du service, et nous pouvons limiter les interactions externes et contrôler tous les déplacements du cluster vers le réseau externe. Il est possible de définir des règles de stratégie pour contrôler les campagnes entre différents microservices. Enfin, nous pouvons obtenir l'intégralité de la carte d'interaction sur le réseau et rendre la collection unifiée de métriques complètement transparente pour les applications.

À propos du mécanisme de travail peut être trouvé dans la documentation officielle . Istio est un outil vraiment puissant qui peut résoudre de nombreux problèmes et problèmes. Dans cet article, je voudrais répondre aux questions de base qui se posent généralement au début du travail avec Istio. Cela vous aidera à y faire face plus rapidement.

Principe de fonctionnement

Istio se compose de deux zones principales - plan de contrôle et plan de données. Le plan de contrôle contient les principaux composants qui assurent le bon fonctionnement du reste. Dans la version actuelle (1.0), le plan de contrôle a trois composants principaux: Pilot, Mixer, Citadel. Nous ne considérerons pas Citadel, il est nécessaire de générer des certificats pour assurer un TLS mutuel entre les services. Examinons de plus près l'appareil et le but du pilote et du mélangeur.



Pilot est le principal composant de contrôle qui diffuse toutes les informations sur ce que nous avons dans le cluster - les services, leurs points de terminaison et les règles de routage (par exemple, les règles de déploiement Canary ou les règles de disjoncteur).

Mixer - un composant facultatif du plan de contrôle, qui offre la possibilité de collecter des métriques, des journaux et toutes les informations sur les interactions réseau. Il surveille également le respect des règles de la politique et le respect des limites de taux.

Le plan de données est implémenté à l'aide de conteneurs proxy sidecar. Par défaut, le puissant serveur proxy d'envoyé est utilisé . Il peut être remplacé par une autre implémentation, par exemple nginx (nginmesh).

Afin qu'Istio fonctionne de manière totalement transparente pour les applications, il existe un système d'injection automatique. La dernière implémentation est adaptée aux versions de Kubernetes 1.9+ (webhook d'admission mutationnelle). Pour les versions 1.7, 1.8 de Kubernetes, il est possible d'utiliser l'initialiseur.

Les conteneurs Sidecar sont connectés au Pilot via le protocole GRPC, ce qui permet d'optimiser le modèle de push des changements intervenant dans le cluster. GRPC a commencé à être utilisé dans Envoy depuis la version 1.6, à Istio, il est utilisé depuis la version 0.8 et est un pilote-agent - un wrapper sur golang sur l'envoyé qui configure les paramètres de lancement.

Pilot et Mixer sont des composants complètement sans état, tous les états sont conservés en mémoire. La configuration pour eux est spécifiée en tant que ressources personnalisées Kubernetes, qui sont enregistrées dans etcd.
Istio-agent reçoit l'adresse pilote et lui ouvre un flux GRPC.

Comme je l'ai dit, Istio implémente toutes les fonctionnalités de manière totalement transparente pour les applications. Voyons comment. L'algorithme est le suivant:

1. Déployez une nouvelle version du service.
2. Selon l'approche d'injection du conteneur side-car, un conteneur istio-init et un conteneur istio-agent (envoyé) sont ajoutés au stade de l'application de la configuration, ou ils peuvent déjà être insérés manuellement dans la description Pod de l'entité Kubernetes.
3. Le conteneur istio-init est un script qui applique les règles iptables pour le foyer. Il existe deux options pour configurer l'habillage du trafic dans le conteneur istio-agent: utilisez les règles de redirection iptables ou TPROXY . Au moment de la rédaction, l'approche par défaut avec les règles de redirection est utilisée. Dans istio-init, il est possible de configurer quel trafic doit être intercepté et acheminé vers istio-agent. Par exemple, pour intercepter tout le trafic entrant et sortant, vous devez définir les paramètres -i et -b sur * . Vous pouvez spécifier des ports spécifiques à intercepter. Afin de ne pas intercepter un sous-réseau spécifique, vous pouvez le spécifier en utilisant l'indicateur -x .
4. Après l'exécution des conteneurs init, les principaux sont lancés, y compris pilote-agent (envoyé). Il se connecte au pilote déjà déployé via GRPC et reçoit des informations sur tous les services et politiques de routage existants dans le cluster. Selon les données reçues, il configure les clusters et leur attribue directement les noeuds finaux de nos applications dans le cluster Kubernetes. Il convient également de noter un point important: l'envoyé configure dynamiquement des écouteurs (IP, paires de ports) qu'il commence à écouter. Par conséquent, lorsque les demandes entrent dans le pod, elles sont redirigées à l'aide des règles de redirection iptables dans le sidecar, l'envoyé peut déjà traiter ces connexions avec succès et comprendre où acheminer le trafic proxy. Toujours à ce stade, des informations sont envoyées au mélangeur, dont nous discuterons plus tard, et en envoyant des plages de suivi.

En conséquence, nous obtenons tout un réseau de serveurs proxy envoyés, que nous pouvons configurer à partir d'un point (pilote). Toutes les demandes entrantes et sortantes passent par l'envoyé. De plus, seul le trafic TCP est intercepté. Cela signifie que l'IP du service Kubernetes se résout à l'aide de kube-dns sur UDP sans modification. Ensuite, après résolution, la demande sortante est interceptée et traitée par l'envoyé, qui décide déjà à quel point final envoyer la demande (ou non, en cas de politiques d'accès ou de déclenchement d'algorithmes de disjoncteur).

Avec Pilot trié, vous devez maintenant comprendre comment fonctionne le Mixer et pourquoi il est nécessaire. Vous pouvez lire la documentation officielle à ce sujet ici .

Le mélangeur dans sa forme actuelle se compose de deux composants: istio-télémétrie, istio-policy (avant la version 0.8, il était un composant d'istio-mixer). Les deux sont mixeurs, chacun étant responsable de sa tâche. La télémétrie Istio reçoit via GRPC du sidecar Report conteneurs des informations sur qui va où et avec quels paramètres. Istio-policy accepte les demandes de vérification pour vérifier si les règles de politique sont satisfaites. Les contrôles de politique sont effectués, bien sûr, pas pour chaque demande, mais sont mis en cache sur le client (en side-car) pendant un certain temps. Les chèques de rapport sont envoyés par des demandes groupées. Nous verrons un peu plus tard comment configurer et quels paramètres vous devez envoyer.

Le mélangeur est censé être un composant hautement disponible qui fournit un travail ininterrompu sur la collecte et le traitement des données de télémétrie. Le système se révèle être un tampon à plusieurs niveaux. Initialement, les données sont mises en mémoire tampon du côté du sidecar des conteneurs, puis du côté du mélangeur, puis envoyées aux serveurs dits du mélangeur. Par conséquent, si l'un des composants du système tombe en panne, le tampon augmente et se bloque après la récupération du système. Les backends du mélangeur sont les points de terminaison pour l'envoi de données de télémétrie: statsd, newrelic, etc. Vous pouvez écrire votre backend, c'est assez simple, et nous verrons comment le faire.



Pour résumer, le schéma de travail avec l'istio-télémétrie est le suivant.

1. Le service 1 envoie une demande au service 2.
2. Lorsque vous quittez le service 1, la demande est enveloppée dans son propre side-car.
3. L'envoyé Sidecar surveille le déroulement de la demande de service 2 et prépare les informations nécessaires.
4. L'envoie ensuite à istio-télémétrie à l'aide de la demande de rapport.
5. Istio-telemetry détermine s'il faut envoyer ce rapport aux backends, à quelles données et quelles données envoyer.
6. Istio-telemetry envoie les données du rapport au backend si nécessaire.

Voyons maintenant comment se déployer dans le système Istio, composé uniquement des principaux composants (pilote et envoyé side-car).

Tout d'abord, regardons la configuration principale (maillage) que Pilot lit:

 apiVersion: v1 kind: ConfigMap metadata: name: istio namespace: istio-system labels: app: istio service: istio data: mesh: |- #      tracing  (pilot  envoy'  ,     ) enableTracing: false #     mixer endpoint',  sidecar      #mixerCheckServer: istio-policy.istio-system:15004 #mixerReportServer: istio-telemetry.istio-system:15004 #   ,    envoy  Pilot (    envoy proxy) rdsRefreshDelay: 5s # default   envoy sidecar defaultConfig: #   rdsRefreshDelay discoveryRefreshDelay: 5s #    (     envoy) configPath: "/etc/istio/proxy" binaryPath: "/usr/local/bin/envoy" #    sidecar  (, ,      tracing span') serviceCluster: istio-proxy # ,    envoy  ,        drainDuration: 45s parentShutdownDuration: 1m0s #    REDIRECT  iptables.    TPROXY. #interceptionMode: REDIRECT # ,     admin   sidecar  (envoy) proxyAdminPort: 15000 # ,     trace'  zipkin  (     ,       ) zipkinAddress: tracing-collector.tracing:9411 # statsd     envoy  () # statsdUdpAddress: aggregator:8126 #    Mutual TLS controlPlaneAuthPolicy: NONE # ,     istio-pilot  ,     service discovery  sidecar  discoveryAddress: istio-pilot.istio-system:15007 

Tous les principaux composants du plan de contrôle sont situés dans l'istio-système d'espace de noms de Kubernetes.

Au minimum, nous devons déployer uniquement Pilot. Pour ce faire, nous utiliserons cette configuration.

Et configurez manuellement le sidecar d'injection du conteneur.

Conteneur init:

 initContainers: - name: istio-init args: - -p - "15001" - -u - "1337" - -m - REDIRECT - -i - '*' - -b - '*' - -d - "" image: istio/proxy_init:1.0.0 imagePullPolicy: IfNotPresent resources: limits: memory: 128Mi securityContext: capabilities: add: - NET_ADMIN 

Et side-car:

  name: istio-proxy args: - "bash" - "-c" - | exec /usr/local/bin/pilot-agent proxy sidecar \ --configPath \ /etc/istio/proxy \ --binaryPath \ /usr/local/bin/envoy \ --serviceCluster \ service-name \ --drainDuration \ 45s \ --parentShutdownDuration \ 1m0s \ --discoveryAddress \ istio-pilot.istio-system:15007 \ --discoveryRefreshDelay \ 1s \ --connectTimeout \ 10s \ --proxyAdminPort \ "15000" \ --controlPlaneAuthPolicy \ NONE env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace - name: INSTANCE_IP valueFrom: fieldRef: fieldPath: status.podIP - name: ISTIO_META_POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: ISTIO_META_INTERCEPTION_MODE value: REDIRECT image: istio/proxyv2:1.0.0 imagePullPolicy: IfNotPresent resources: requests: cpu: 100m memory: 128Mi limits: memory: 2048Mi securityContext: privileged: false readOnlyRootFilesystem: true runAsUser: 1337 volumeMounts: - mountPath: /etc/istio/proxy name: istio-envoy 

Pour que tout démarre correctement, vous devez obtenir ServiceAccount, ClusterRole, ClusterRoleBinding, CRD for Pilot, dont la description se trouve ici .

En conséquence, le service dans lequel nous injectons le side-car avec l'envoyé doit démarrer avec succès, obtenir toutes les découvertes du pilote et traiter les demandes.

Il est important de comprendre que tous les composants du plan de contrôle sont des applications sans état et peuvent être mis à l'échelle horizontalement sans aucun problème. Toutes les données sont dans etcd en tant que descriptions personnalisées des ressources Kubernetes.

Istio a également (jusqu'à présent expérimentalement) la capacité de s'exécuter en dehors du cluster et la capacité de surveiller et de tâtonner pour la découverte de services entre plusieurs clusters Kubernetes. Vous pouvez en savoir plus à ce sujet ici .

Pour une installation multi-cluster, les restrictions suivantes doivent être prises en compte:

1. Le pod CIDR et le service CIDR doivent être uniques sur tous les clusters et ne doivent pas se chevaucher.
2. Tous les pod CIDR doivent être disponibles à partir de n'importe quel pod CIDR entre les clusters.
3. Tous les serveurs API Kubernetes doivent être accessibles les uns aux autres.

Ce sont les informations initiales pour vous aider à démarrer avec Istio. Cependant, il existe encore de nombreux pièges. Par exemple, les fonctionnalités de routage du trafic externe (vers l'extérieur du cluster), les approches de débogage des side-cars, le profilage, la configuration d'un mélangeur et l'écriture d'un backend de mélangeur personnalisé, la configuration du mécanisme de traçage et son fonctionnement à l'aide d'envoyé.
Nous considérerons tout cela dans les publications suivantes. Posez vos questions, je vais essayer de les couvrir.