Kubernetes vous donne beaucoup de flexibilité pour définir la manière dont nous voulons que nos services soient exposés. Vous pouvez configurer vos objets Service pour vous assurer qu'un groupe de pods n'est accessible que dans le cluster ou permettre un accès depuis l'extérieur du cluster. Si votre fournisseur de cloud choisi le prend en charge, vous pouvez même demander une adresse IP ou un nom d’hôte avec équilibrage de charge pour votre service.

1_n436SKaXfNqjrc1ksrHszQ--1-

L'objet Service nous offre un moyen simple de connecter des services fonctionnant dans des pods. Toutefois, si vous souhaitez configurer des règles de routage de base pour différents services ou si vous souhaitez configurer des éléments tels que TLS, la ressource Ingress constitue un moyen beaucoup plus souple de configurer des serveurs externes. accès.

Une entrée peut être supportée par différentes implémentations grâce à l'utilisation de différents contrôleurs d'entrée. Le contrôleur le plus populaire est le contrôleur d’ingénierie NGINX. Cependant, d’autres options sont disponibles, telles que Traefik, Rancher, HAProxy, etc. Chaque contrôleur doit prendre en charge une configuration de base, mais peut même exposer d’autres fonctionnalités (par exemple règles de annotations.

Dans ce guide, nous allons examiner la configuration du contrôleur d’ingénierie NGINX dans notre cluster et créer des itinéraires d’entrée pour un exemple d’application. Vous apprendrez comment sont définis les objets Ingress, notamment comment configurer TLS et l’authentification de base, le tout avec Helm.

1_Rsadjy_45_dFmbzORNl4Mg

Pré-requis :

  • Vous avez des connaissances de base sur les déploiements, services et autres objets API de Kubernetes.
  • Vous avez une connaissance de base des charts de Helm et de leur création.
  • Vous avez un cluster externe Kubernetes s'exécutant sur GKE ou sur une autre plate-forme.
  • La ligne de commande kubectl (CLI kubectl) est installée.
  • Vous avez Helm et Tiller installé.
  • Un nom de domaine avec possibilité de configurer le DNS.
  • Un Mac !

Rappel : création d'un cluster GKE

Dans une fenêtre de console démarrez le processus d'authentification en exécutant la commande suivante:

gcloud init

gcloud config set compute/zone  COMPUTE_ZONE

gcloud auth application-default login

On autorise l'utilisation du plugin kubernetes engine dans la console web de Google et on peut lancer la création du cluster :

gcloud container clusters create MY_KUBERNETES_CLUSTER \
  --enable-cloud-logging \
  --enable-cloud-monitoring \
  --subnetwork default

Dont voici le résultat :

NAME          LOCATION        MASTER_VERSION  MASTER_IP       MACHINE_TYPE   NODE_VERSION  NUM_NODES  STATUS
cluster-helm  europe-west1-b  1.9.7-gke.6     35.240.117.137  n1-standard-1  1.9.7-gke.6   3          RUNNING

Puis:

kubectl cluster-info

Ce qui nous donne :

    MBP-de-admin:~ admin$ kubectl cluster-info
Kubernetes master is running at https://35.240.117.137
GLBCDefaultBackend is running at https://35.240.117.137/api/v1/namespaces/kube-system/services/default-http-backend:http/proxy
Heapster is running at https://35.240.117.137/api/v1/namespaces/kube-system/services/heapster/proxy
KubeDNS is running at https://35.240.117.137/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
kubernetes-dashboard is running at https://35.240.117.137/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy
Metrics-server is running at https://35.240.117.137/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy

Installation de Helm et Tiller

Helm est le moyen le plus simple d'exécuter et de gérer des applications dans un cluster Kubernetes. Helm vous permet d'effectuer des opérations clés pour la gestion d'applications telles que l'installation, la mise à niveau ou la suppression. Comme mentionné précédemment, Helm est composé de deux parties: Helm (le client) et Tiller (le serveur). Suivez les étapes ci-dessous pour terminer l’installation de Helm et de Tiller. Depuis un Mac :

brew install kubernetes-helm

Pour terminer l’installation de Tiller, exécutez la commande ci-dessous:

helm init

Puis pour vérifier :

MBP-de-admin:~ admin$ kubectl --namespace kube-system get pods | grep tiller
tiller-deploy-759b9d56c-tjbzv                            1/1       Running   0          2d

Pour actualiser les repo de Helm :

helm repo update

Malheureusement ce ne fut pas si facile, il faut penser à appliquer ces commandes pour ne pas rencontrer de message d'erreur au moment de l'installation d'un chart sur votre cluster de type :

MBP-de-admin:~ admin$ helm install stable/nginx-ingress --namespace kube-system
Error: no available release name found

La solution passe donc par (ici ) :

kubectl create serviceaccount --namespace kube-system tiller
kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'

Et là ca fonctionne.

chart-illustration

Étape 1: Installez le contrôleur ingress NGINX

La première étape consiste à installer le contrôleur ingress NGINX. Le moyen le plus simple de le faire fonctionner sur n'importe quelle plate-forme consiste à utiliser le chart Helm stable.

helm install stable/nginx-ingress --namespace kube-system

Une fois le contrôleur créé et en cours d’exécution, nous pouvons accéder au serveur NGINX via l’IP LoadBalancer ou NodePort de son service.

Pour l'obtenir :

MBP-de-admin:~ admin$ kubectl get svc olfactory-moose-nginx-ingress-controller -n kube-system
NAME                                       TYPE           CLUSTER-IP      EXTERNAL-IP       PORT(S)                      AGE
olfactory-moose-nginx-ingress-controller   LoadBalancer   10.43.255.128   146.148.126.218   80:31919/TCP,443:30071/TCP   9m

Ce qui donne dans le navigateur l'affichage suivant :

Capture-d-e-cran-2018-10-12-a--08.01.21

"Erreur 404 - default backend", lors de l'accès au serveur Nginx. Cela nous indique que le contrôleur ne sait pas où acheminer notre requête - nous n’avons encore configuré aucune règle - il répond donc avec le backend par défaut.

Etape 2: déployer une application pour débuter

Maintenant que nous avons un contrôleur d'ingress, nous pouvons commencer et créer des règles d’ingress ! Tout d’abord, nous avons toutefois besoin d’une application vers laquelle nous acheminerons les flux.

Helm propose de nombreuses applications facilement déployables pour tester notre controller. Nous utiliserons Joomla pour obtenir une instance de test sur notre cluster.

helm install stable/joomla --name ingress-example

Par défaut, le chart créera un service avec une adresse IP LoadBalancer. Nous pouvons nous assurer que Joomla! fonctionne en utilisant l'IP externe ou le NodePort dans le navigateur. Cependant, comme nous voulons configurer l’accès au CMS via une route distribuée par l'ingress controller, il serait préférable de n’autoriser que le Service à être exposé en interne au sein du cluster (c’est-à-dire avec le type ClusterIP).

Modifiez le service pour qu'il utilise le type ClusterIP et supprimez les ports de nœud associés.

kubectl patch svc ingress-example-joomla --type='json' -p '[{"op":"remove","path":"/spec/ports/0/nodePort"},{"op":"remove","path":"/spec/ports/1/nodePort"},{"op":"replace","path":"/spec/type","value":"ClusterIP"}]'

Nous ne devrions plus avoir accès à Joomla! via les ports IP ou de nœud externes, mais le contrôleur Ingress sera en mesure de le remplacer au sein du cluster.

Avec la commande "helm list", vous aurez accès aux releases déployées sur le cluster :

MacBook-Pro-de-admin:~ admin$ helm list
NAME      	REVISION	UPDATED                 	STATUS  	CHART               	APP VERSION	NAMESPACE  
mean-shark	1       	Wed Oct 10 22:08:54 2018	DEPLOYED	nginx-ingress-0.28.3	0.19.0     	kube-system