Istio sur GKE

Qu’est-ce qu’Istio?

On peut se poser la question dans un premier temps, mais qu’est-ce donc qu’Istio ? Istio est un service mesh open source offrant un moyen uniforme de connecter, gérer et sécuriser des microservices. Il prend en charge la gestion des flux de trafic entre les services, l'application de stratégies d'accès et l'agrégation de données de télémétrie, le tout sans nécessiter de modification du code de microservice.

Istio donne accès aux fonctionnalités suivantes :

• Equilibrage automatique de la charge pour le trafic HTTP, gRPC, WebSocket, MongoDB et TCP.
• Contrôle précis du comportement du trafic avec des règles de routage riches, des tentatives, des basculements et de l’injection d'erreurs.
• Une couche de stratégie configurable et une API prenant en charge les contrôles d'accès, les limites de débit et les quotas.
• Métriques, journaux et traces automatiques pour tout le trafic d'un cluster, y compris l'entrée et la sortie du cluster.
• Sécurisation de la communication de service à service dans un cluster avec une authentification et une autorisation basées sur une identité forte.
• et d'autres encore que vous pouvez retrouver sur le site d'Istio.

Istio est à l’heure actuelle en version 1.3 pour sa version majeure la plus récente.

Passons maintenant à l’installation d’Istio dans GKE. Pour l’exemple, nous utiliserons GKE car sur GCP l’installation d’Istio est directement embarquée dans la création du cluster Kubernetes, ce qui n’est pas possible sur les autres providers. Nous avons donc sur GCP la possibilité d’installer Istio en mode managé ou en mode OSS (comme pour l’installation sur  AKS (Azure Kubernetes Service), EKS (Elastic Kubernetes Service) ou n’importe quel autre cluster Kubernetes aussi bien que sur Consul).

Installation d’Istio :

Pour installer Istio dans un cluster GKE, deux options s’offrent à nous : la première est d’utiliser l’Istio managé par Google et de l’installer en mode add-on à GKE. L’autre solution consiste à installer Istio nous-mêmes dans le cluster GKE, pour l’installation je me suis basé sur la documentation officielle de GCP. Pour orienter votre choix, voici les avantages et inconvénients de ces deux solutions.

Avantages    Inconvénient        Istio managé    - Version d’Istio packagée avec la version de GKE, donc pas besoin de mise à jour séparée des composants.
- Facilité de déploiement et de maintenance/mise à jour d’Istio.
- Pas de coûts supplémentaire (sauf activation des fonctionnalités de tracing et de logging ajoutera de coûts pour le service stackdriver).    - Pour l’instant n’a accès qu’à la branche de mise à jour à 1.1.X, donc ne bénéficie pas des dernières options comme le SDS
https://istio.io/docs/tasks/security/auth-sds/
(secret discovery service) par exemple.
- Impossibilité d’avoir accès aux access logs des microservices, désactivés sur Istio managé.
- S’il y a un patch de sécurité sur n'importe quelle branche d’Istio 1.1.X ou 1.2.X ou 1.3.X il faudrait attendre que ça soit pris en compte par GCP et que la version d’Istio packagée sorte avec le patch.        Istio OSS    - Peut être sur n'importe quelle branche de release et bénéficier des dernières nouveautés, features, patchs de sécurité sans délai d’attente.
- Accès aux access logs des micro services.
- Pas de coût supplémentaire (sauf activation des fonctionnalités de tracing et de logging qui ajoutera des coûts pour le service stackdriver).    - Un outil en plus à devoir maintenir.
- Un peu plus complexe à installer.

Installation d’Istio via l’add-on GKE

Google pousse à utiliser Istio. Le produit est disponible pour les utilisateurs de Google Cloud sur GKE depuis décembre dernier en version Beta (Sur GCP on peut considérer que la version Beta est prod ready, si vous voulez plus d’informations sur les versions Beta chez GCP, allez sur le lien suivant : https://cloud.google.com/composer/docs/concepts/beta-support?hl=fr). Sur GKE, Istio calque un maillage de service sur vos clusters GKE existants, et rassemble la télémétrie sur leurs conteneurs. Ces données sont ensuite envoyées à Stackdriver ou Prometheus. Grâce à ces outils, vous pouvez surveiller le trafic, les taux d'erreur et les latences de vos microservices basés sur Kubernetes.

Pour installer Istio en mode add-on de GKE, rien de plus simple, on peut soit installer notre cluster via la console GCP soit via la CLI, il suffira de suivre les différentes étapes que nous verrons ci-dessous.

Pour cela, il faut commencer par aller sur la console GCP puis dans la section “Kubernetes engine” :

Vous devrez cliquer sur le bouton “créer un cluster” (l’image ci-dessous montre le cas où vous n’avez pas encore de cluster GKE créé, cela ne crée pas de différences dans la procédure).

Vous aurez ensuite la fenêtre de dialogue suivante, permettant de choisir le nom de votre cluster ainsi que toute sa configuration associée :

Pour activer Istio, il suffira de cliquer sur le bouton “Activer Istio (bêta)” que je vous ai surligné en jaune ci-dessous.

Quand vous cochez la case pour activer Istio afin de l’installer en mode managé sur votre cluster, vous avez le choix entre deux options de sécurité par défaut pour l’ensemble du service mesh, celle que vous choisissez dépend des besoins de votre application initiale. Les deux options sont les suivantes :

Strict mTLS : dans ce mode de sécurité, Istio applique par défaut le chiffrement mutuel TLS (mTLS) entre tous les services et les composants du plan de contrôle du maillage, à moins que vous ne le remplaciez par des règles spécifiques à la destination. Tous les appels dans le maillage sont chiffrés et les services n'accepteront pas le trafic non chiffrés.

Permissive mTLS : dans ce mode de sécurité, par défaut, Istio autorise les services du maillage à accepter le trafic chiffré et non chiffré, et tous les services envoient des appels non chiffrés par défaut. Comme avec mTLS strict, vous pouvez le remplacer pour des services spécifiques. Utilisez cette option si vous avez des services qui doivent toujours accepter le trafic non chiffré, par exemple si vous n'avez pas entièrement migré vos services vers Istio et que le trafic provient de clients hérités en dehors du maillage. Istio sur GKE fournit ce mode plutôt que d'installer simplement Istio sans sécurité activée, car cela facilite la migration ultérieure vers strict mTLS pour une sécurité accrue.

Si vous voulez créer votre cluster via la CLI et non via la console GCP, il vous suffit d'exécuter la commande suivante, en étant bien sûr loggé sur gcloud avec votre account GCP et sur le bon projet GCP où vous voulez installer votre cluster :

gcloud beta container clusters create CLUSTER_NAME \
    --addons=Istio --istio-config=auth=MTLS_STRICT \
    --cluster-version=CLUSTER_VERSION \
    --machine-type=n1-standard-2 \
    --num-nodes=4

Et si vous avez déjà un cluster GKE mais sans l’add-on Istio, il suffira juste de mettre à jour le cluster avec la commande suivante via gcloud. Bien sûr, cette étape est aussi possible via la console GCP, il suffira d’aller sur votre cluster GKE déjà existant et de l’éditer et de cocher la case “Activer Istio (bêta)” comme nous avons fait plus haut.

gcloud beta container clusters update CLUSTER_NAME \
    --update-addons=Istio=ENABLED --istio-config=auth=MTLS_STRICT

Pour simplifier l’exemple, nous créons les ressources à la main mais je vous recommande cependant de gérer votre infrastructure avec de l’IAC (Infrastructure As Code). Voici un exemple de création du cluster GKE avec Terraform en activant Istio :

resource "google_container_cluster" "gke_cluster" {
 provider           = "google-beta"
 name               = "my-gke-cluster"
 location           = "us-central1"
 min_master_version = 1.4

 remove_default_node_pool = true
 initial_node_count       = 1
 maintenance_policy {
   daily_maintenance_window {
     # en heure GMT
     start_time = "04:00"
   }
 }

 istio_config {
   disabled = false
 }

}

resource "google_container_node_pool" "main-gke-simple-node-pool" {
 cluster  = google_container_cluster.gke_cluster.name
 name     = "node-pool"
 location = "us-central1"
 initial_node_count = 1

 autoscaling {
   min_node_count = 1
   max_node_count = 6
 }

 node_config {
   preemptible     = false
   machine_type    = n1-standard-8
   oauth_scopes = [
     "https://www.googleapis.com/auth/logging.write",
     "https://www.googleapis.com/auth/monitoring",
   ]

 }

 management {
   auto_repair  = true
   auto_upgrade = true # Will follow the master version
 }
}

Comme nous pouvons le constater ci-dessus en regardant les informations de notre cluster GKE, nous retrouvons bien dans la section “Fonctionnalités Anthos” Istio activé. Ci-dessous nous retrouverons dans la partie “Charges de travail” les différents composants Istio déployés et si l’installation s’est bien faite, tous les composants seront en état “OK”.

Si on souhaite vérifier via la CLI que l’installation s’est bien faite, il suffira de reproduire ce que j’ai fait ci-dessous, où nous allons vérifier que tous les services et pods se situant dans le namespace “istio-system sont dans l’état “running” :

gcloud container clusters get-credentials CLUSTER_NAME
gcloud container clusters list
kubectl get service -n istio-system
kubectl get pods -n istio-system

Activer sidecar injection

Si vous voulez bénéficier de toutes les features d’Istio, chaque service de votre application doit disposer d’un Envoy sidecar proxy s’exécutant dans son pod. Le proxy Envoy va intercepter tout le trafic entrant et sortant du service et communiquer avec le control plane Istio.
Par défaut, l'auto-injection Istio sidecar est désactivée pour tous les namespaces. Pour l'activer, remplacez NAMESPACE dans la commande suivante par le nom du namespace des services de votre application :

kubectl label namespace NAMESPACE istio-injection=enabled

Tous les pods en cours d'exécution doivent être redémarrés pour que la modification soit prise en compte. En effet, le sidecar est ajouté au moment de la création du pod. Pour désactiver l'injection automatique pour le namespace, supprimez le label et redémarrez les pods pour supprimer leurs sidecars.

Installation d’Istio sur GKE en mode OSS

Pré-requis :

Il faudra installer le client Helm afin d’’exécuter certaines commandes d’installation.

Pour installer Istio sur GKE en mode OSS il vous faudra aussi créer un cluster GKE au préalable ou utiliser un cluster existant. Pour cet article, nous allons créer le cluster GKE comme ce que nous avons fait ci-dessus, il suffira d’installer Istio en mode managé sans l’activer. Pour créer le cluster, nous allons exécuter la commande suivante :

gcloud container clusters create istio-tutorial \
    --machine-type=n1-standard-2 \
    --num-nodes=4

Si vous voulez utiliser un cluster GKE existant, il vous faudra vous assurer qu’il utilise la version par défaut de Kubernetes et que les RBAC (Role Based Access Control) soient activés. Les RBAC sont activés par défaut sur tous les clusters tournant sur la version 1.6 et supérieure,sur une ancienne version, il faudra mettre à jour votre cluster avec l’option suivante “--no-enable-legacy-authorization.”

Connectez-vous ensuite sur votre cluster avec la commande suivante :

gcloud container clusters get-credentials istio-tutorial

Assurez-vous que votre version de kubectl soit la même ou plus récente que celle de votre cluster. Vous pouvez vérifier que vous utilisez bien la dernière version en faisant la commande suivante :

kubectl version

Il faudra aussi accorder des autorisations d'administrateur de cluster à votre utilisateur. Vous devez disposer de ces autorisations pour créer les règles de contrôle d'accès (RBAC) nécessaires pour Istio. Vous pouvez le faire via cette commande :

kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole=cluster-admin \
  --user="$(gcloud config get-value core/account)"

Maintenant que nous avons un cluster GKE fonctionnel avec tous les prérequis nous pouvons télécharger Istio et ensuite nous pourrons enfin attaquer l’installation.

Téléchargement d’Istio

Téléchargez Istio localement. Comme il s’agit de la procédure recommandée, nous allons télécharger un script, mais je vous conseille quand même de regarder le contenu du script avant d’exécuter la commande, afin de savoir ce qu’il va exécuter (spoiler alert : il télécharge la dernière version d’Istio, décompresse l’archive localement et vous affiche les instructions pour l’installer) :

curl -L https://git.io/getLatestIstio | ISTIO_VERSION=1.3.3 sh -

Dans le répertoire d’Istio que nous venons de télécharger, vous retrouverez les fichiers suivants :
Fichier d’installation .yaml pour kubernetes dans “install/”
Exemples d’applications dans “samples/”
Le binaire du client istioctl dans “bin/”
Le fichier de configuration “istio.VERSION”

Nous allons maintenant exporter le client istioctl dans notre PATH :

cd ./istio-1.3.3
Add the istioctl client to your PATH:
export PATH=$PWD/bin:$PATH

Installation d’Istio

La commande d’installation utilise le client Helm, mais pour Istio il n’est pas nécessaire d’installer l’intégralité du tooling Helm au sein du cluster, puisque nous allons juste utiliser le client Helm pour la partie templating.

Vous devrez ensuite créer le namespace “istio-system” :

kubectl create namespace istio-system

Maintenant que tout est prêt pour l’installation, Istio va s’installer dans le namespace que nous venons juste de créer “istio-system”. L’installation inclut les composants core d’Istio, quelques outils et des exemples.
Installez les définitions de ressources personnalisées (CRD) Istio et attendez quelques secondes que les CRD soient validées dans le serveur d'API Kubernetes :

helm template install/kubernetes/helm/istio-init \
  --name istio-init --namespace istio-system | kubectl apply -f -

Vérifiez que les 23 CRDs d’Istio sont validées à l'aide de la commande suivante :

> kubectl get crds -n istio-system | grep 'istio.io\|certmanager.k8s.io' | wc -l
23

Installez Istio avec le profil par défaut. Vous pouvez choisir un autre profil, mais Istio recommande le profil par défaut pour les déploiements en production.

helm template install/kubernetes/helm/istio \
  --name istio --namespace istio-system | kubectl apply -f -

Pour vérifier l’installation, il suffira d’aller voir dans la console GCP ou directement par ligne de commande comme nous l’avons fait lors de l’installation d’Istio en mode managé.

Pour la partie “Mise à jour d’Istio OSS”, il suffira de télécharger les nouvelles sources et de refaire la commande Helm avec le kubectl apply -f -. Vous avez aussi la possibilité d’utiliser kustomize, qui est un outil de templating directement intégré à la commande kubectl au lieu de Helm.

Conclusion

Comme nous l’avons vu, installer Istio reste assez simple, qu’on soit en mode managé ou en mode OSS. Pour ma part, je suis parti sur la version OSS, même s’il faut maintenir un outil en plus, car elle me permet de :

• bénéficier de toutes les features des branches de release supérieures à celle supportée par GCP;
• disposer des access logs des containers;
• disposer des nouvelles mises à jour et des patchs de sécurité le plus rapidement possible, afin d’éviter d’éventuelles failles de sécurité.

Nous n’avons pas pu voir dans cet article toute l’étendue des fonctionnalités d’Istio, mais nous le verrons dans un prochain, c’est promis !