Pour ce projet nous allons utiliser quelques outils :

  • SuperGloo est un nouveau projet open source qui aide à gérer les maillages de service à grande échelle. SuperGloo fournit une couche d'abstraction avisée qui simplifie l'installation, la gestion et les opérations d'un ou plusieurs services maillés, tels que Istio, AWS App Mesh, Linkerd et HashiCorp Consul. Prise en charge sur site, dans le cloud ou toute combinaison dont vous avez besoin.
  • Flagger est un projet open source intéressant qui automatise la promotion des déploiements canaris de vos services Kubernetes. Vous associez une ressource personnalisée (CRD) Flagger Canary Kubernetes à votre déploiement et Flagger suit vos règles définies pour vous aider à déployer une nouvelle version. Il détecte le déploiement d'une nouvelle version de votre service, instancie votre nouvelle version parallèlement à votre version existante, déplace lentement le trafic de requête entre les deux versions et utilise vos contrôles d'intégrité de métrique Prometheus définis pour déterminer si Flagger doit continuer à acheminer davantage de trafic vers la nouvelle version ou revenir à l’ancienne version. Etant donné qu'un fichier Canary CRD est un fichier YAML, vous disposez ainsi d'une méthode déclarative pour vous assurer que toutes les mises à niveau de service respectent la stratégie de déploiement sophistiquée préconisée et complètent les pipelines GitOps utilisés dans Weave Flux et JenkinsX.
  • Kind for Kubernetes.

Installer Kubernetes et Helm

La première étape de notre voyage consiste à faire fonctionner un cluster Kubernetes local Kind. C’est un moyen rapide et léger d’augmenter/réduire un cluster local en supposant que vous avez Docker en cours d’exécution sur votre poste, par exemple, Docker Desktop.

Cet exemple fonctionne aussi avec minikube si vous préférez. Le code suivant décrit les bases dont vous avez besoin pour la plupart des clusters Kubernetes.  

  • Crée un cluster type avec un nœud de plan de contrôle et un nœud de travail
  • Configure KUBECONFIG comme Kind et crée un fichier kubeconfig séparé pour chaque type de cluster
  • Installe Helm et Tiller avec un compte de service pour Tiller

On commence par créer un cluster Kind :

# Create Kubernetes cluster using Kubernetes IN Docker (kind)
# Install: `go get -u sigs.k8s.io/kind`
cat <<EOF | kind create cluster --wait 60s --config -
apiVersion: kind.sigs.k8s.io/v1alpha3
kind: Cluster
nodes:
- role: control-plane
- role: worker
EOF

# Configure environment for kubectl to connect to kind cluster
export KUBECONFIG="$(kind get kubeconfig-path)"

# Install Helm and Tiller
kubectl --namespace kube-system create serviceaccount tiller

kubectl create clusterrolebinding tiller-cluster-rule \
  --clusterrole=cluster-admin \
  --serviceaccount=kube-system:tiller

helm init --service-account tiller

Installer SuperGloo et installation d'Istio

C’est là que la magie opère, alors prenons un peu de temps pour expliquer tout ce qui se passe à cause de ces quelques lignes de code.

# Install Solo.io SuperGloo Service Mesh Operator
supergloo init

# Wait for SuperGloo to start
kubectl --namespace supergloo-system rollout status deployment/supergloo --watch=true

# Use SuperGloo to install and configure Istio the easy way
supergloo install istio \
  --name=flagger-test \
  --namespace=supergloo-system \
  --installation-namespace=istio-system \
  --version=1.0.6 \
  --auto-inject=true \
  --grafana=false \
  --jaeger=false \
  --mtls=false \
  --prometheus=true \
  --update=true

La deuxième commande kubectl --namespace supergloo-system rollout status ... est un hack permettant d’attendre que le déploiement de SuperGloo soit complètement déployé et en cours d’exécution. Cela revient à utiliser l’option --wait sur une installation de Helm.  

La commande supergloo install istio ... déclare une ressource personnalisée et le contrôleur SuperGloo installe et configure Istio comme déclaré. Dans ce cas, nous installons la version 1.0.6 d’Istio avec l’installation Prométhée d’Istio et avec le déploiement par Istio de sidecars dans tous les pods des espaces-noms avec le label istio-injection = enabled, c’est-à-dire le comportement par défaut d’Istio pour l’auto-injection. Cette commande impérative supergloo install istio crée le manifeste suivant que vous pouvez appliquer si vous le souhaitez. Reportez-vous à la spécification d'installation complète pour plus de détails.

apiVersion: supergloo.solo.io/v1
kind: Install
metadata:
  name: flagger-test
  namespace: supergloo-system
spec:
  installationNamespace: istio-system
  mesh:
    istio:
      enableAutoInject: true
      installPrometheus: true
      version: 1.0.6

Installer Flagger

Voici un résumé rapide de l’installation de Flagger. Plus de détails sur le site Flagger Doc.  

  • Ajouter une référence à Flagger helm repo
  • Attendez que Tiller soit complètement opérationnel. Un problème uniquement pour les scripts rapides qui créent des clusters Kubernetes à partir de zéro
  • Créer une liaison de rôle de cluster permettant à Flagger de modifier les ressources SuperGloo/Istio
  • Installez Flagger en vous référant au Prometheus fourni par Istio et en indiquant à Flagger que SuperGloo est le contrôleur de maillage.
  • Installez les tableaux de bord de Grafana de Flagger qui ne sont pas utilisés dans le cadre de cette démonstration
  • Installez le LoadTester de Flagger qui peut aider à générer du trafic de test lors d’un déploiement de Canary s’il n’ya pas suffisamment de trafic utilisateur