Skip to content
This repository has been archived by the owner on Apr 8, 2021. It is now read-only.

Commit

Permalink
Update article
Browse files Browse the repository at this point in the history
  • Loading branch information
@gfaivre
gfaivre committed Jan 29, 2018
1 parent f87bc5b commit 73884c3
Showing 1 changed file with 40 additions and 36 deletions.
76 changes: 40 additions & 36 deletions content/infra/kubernetes-ip-statique-ingress-loadbalancer.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,11 +5,11 @@ date: "2018-01-26"
publishdate: "2018-01-26"
draft: false
slug: "kubernetes-ip-statique-ingress-loadbalancer"
description: "Préparer son environnement pour utiliser l'API openstack d'OVH, pré-requis et installation du client"
description: "Affecter une IP statique dédiée à un Ingress Kubernetes et répartir la charge."

thumbnail: "/images/posts/thumbnails/openstack.png"
header_img: "/images/posts/headers/facade.jpg"
tags: ["kubernetes","k8s","infra","docker"]
tags: ["kubernetes","k8s","infra","docker", "ingress"]
categories: ["Infra", "Kubernetes"]

author_username: "gfaivre"
Expand All @@ -19,13 +19,13 @@ Bonjour à tou(te)s !

Au menu aujourdhui, comment créer une IP publique statique pour Google Cloud et l'affecter à un **«Ingress»** (Je n'ai pas trouvé d'équivalent français satisfaisant).

<span class="side-note light">🚧</span>Cet article suppose que vous disposez d'un cluster Kubernetes fonctionnel sur Google Cloud Platform et que vous avez déjà créé un projet (au sens GCP) si ça n'est pas le cas rendez-vous [ici](https://console.cloud.google.com/projectselector/kubernetes)
<span class="side-note light">🚧</span>Cet article suppose que vous disposez d'un cluster Kubernetes fonctionnel sur Google Cloud Platform et que vous avez déjà créé un projet (au sens GCP) si ça n'est pas le cas rendez-vous [ici](https://console.cloud.google.com/projectselector/kubernetes)<!--more-->

---
**Objectifs:**

- Réserver une IP statique
- Configurer un «Ingress» et un «Service» pour qu'ils utilisent cette IP et qu'ils utilisent 2 instances pour servir le client.
- Configurer un **«Ingress»** et un **«Service»** pour qu'ils utilisent cette IP et qu'ils utilisent 2 instances pour servir le client.

**Pré-requis GCP:**

Expand All @@ -45,7 +45,7 @@ Avant de réserver notre IP, assurez-vous que la configuration projet est correc

<span class="side-note light">📌</span>Si vous souhaitez savoir quelle sont les variables déjà configurées sur votre poste un `gcloud config list` devrait faire l'affaire.

Pour consulter une «clé» particulière (par exemple le projet configuré) nous utiliserons le flag `get-value`.
Pour consulter une clé particulière (par exemple le projet configuré) nous utiliserons le flag `get-value`.

`gcloud config get-value project` renverra la valeur de la variable projet.

Expand All @@ -63,7 +63,7 @@ gcloud config set compute/zone europe-west1

## Création de l'adresse

Attention subtilité !
<span class="side-note light">🚧</span>**Attention subtilité !**
Si vous passez le flag `--global` votre IP ne sera pas affectée à une zone géographique, si vous souhaitez avoir une l'IP localisée il faut spécifier la zone à laquelle elle sera rattachée:

{{< highlight shell >}}
Expand All @@ -74,16 +74,15 @@ gcloud compute addresses create cramaillote-endpoint --global
gcloud compute addresses create cramaillote-endpoint --region=europe-west1 --description="Cramaillote project"
{{< /highlight >}}

<span class="side-note light">📌</span>**NB:** Par défaut c'est une adresse de type IPv4 qui est créée, c'est modifiable avec le flag `--ip-version=IPV6`

NB: Par défaut c'est une adresse de type IPv4 qui est créée, c'est modifiable avec le flag `--ip-version=IPV6`

__Récupérer des infos sur l'adresse nouvellement créée__
### Récupérer des infos sur l'adresse nouvellement créée

Pour vérifier la bonne création de notre IP `gcloud compute addresses describe cramaillote-endpoint --region=europe-west1`

Sortie:
**Sortie:**

```
{{< highlight shell >}}
address: 35.195.235.95
creationTimestamp: '2018-01-26T01:11:12.026-08:00'
description: Cramaillote project
Expand All @@ -93,23 +92,24 @@ name: cramaillote-endpoint
region: https://www.googleapis.com/compute/v1/projects/elao-sandbox/regions/europe-west1
selfLink: https://www.googleapis.com/compute/v1/projects/elao-sandbox/regions/europe-west1/addresses/cramaillote-endpoint
status: RESERVED
```
{{< /highlight >}}


Première étape terminée !
Il nous «reste» à utiliser cette IP afin de pouvoir exposer notre application nous allons donc créer:

* Un «Service» de type `NodePort`
* Un «Ingress» avec notre IP publique et qui aura pour «backends» notre «Pod» Nginx (constitué donc, de 2 instances).
* Un **«Service»** de type `NodePort`
* Un **«Ingress»** avec notre IP publique et qui aura pour «backends» notre **«Pod»** Nginx (constitué donc, de 2 instances).

L'objectif final étant d'avoir un Ingress avec une IP publique statique qui fait office de répartiteur de charge vers 2 «backends» Nginx.
L'objectif final étant d'avoir un **Ingress** avec une IP publique statique qui fait office de répartiteur de charge vers 2 «backends» Nginx.

# Création des instances Nginx

Nous créons rapidement les instances applicatives qui seront chargées de nous répondre.

Pour cet exemple je suis parti sur une image faisant tourner un nginx qui doit me retourer le nom de l'instance sur laquelle il fonctionne.

```
{{< highlight nginx >}}
server {
listen 8080 default_server;
server_name _;
Expand All @@ -121,11 +121,12 @@ server {
return 200 "Hostname: $HOSTNAME";
}
}
```
{{< /highlight >}}


On déploie nos instances avec le manifeste suivant:

```
{{< highlight yaml >}}
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
Expand All @@ -147,13 +148,13 @@ spec:
ports:
- containerPort: 8080
imagePullPolicy: Always
```
{{< /highlight >}}

# Création de l'«Ingress»

Avec le manifeste suivant nous créons donc un «Ingress» qui va venir consommer notre IP publique et assurer le routage vers le «Service» `cramaillote-app`
Avec le manifeste suivant nous créons donc un **«Ingress»** qui va venir consommer notre IP publique et assurer le routage vers le **«Service»** `cramaillote-app`

```
{{< highlight yaml >}}
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
Expand All @@ -162,32 +163,35 @@ metadata:
kubernetes.io/ingress.global-static-ip-name: cramaillote-endpoint
spec:
backend:
serviceName: cramaillote-app
serviceName: cramaillote-app-service
servicePort: 8080
```
{{< /highlight >}}


Application du manifest `kubectl apply -f cramaillote-ingress.yml`

Une fois l'«Ingress» créé il devrait vous répondre sa page par défaut:
Une fois l'**«Ingress»** créé il devrait vous répondre sa page par défaut:

```
{{< highlight shell >}}
curl http://35.195.235.95
default backend - 404
```
{{< /highlight >}}

On notera l'affectation de notre IP statique grâce à l'annotation `kubernetes.io/ingress.global-static-ip-name`. Si rien n'est spécifié l'«Ingress» se verra affecter une adresse IP temporaire (qui changera donc à chaque fois qu'il sera détruit / recréé).
On notera l'affectation de notre IP statique grâce à l'annotation `kubernetes.io/ingress.global-static-ip-name`. Si rien n'est spécifié l'**«Ingress»** se verra affecter une adresse IP temporaire (qui changera donc à chaque fois qu'il sera détruit / recréé).

<span class="side-note light">💡</span>**Astuce**: Si vous avez déjà créé votre «Ingress» et souhaitez conserver votre IP, il est possible de «promouvoir» une IP temporaire en statique avec le flag `--addresses` de la manière suivante:
<span class="side-note light">💡</span>**Astuce**: Si vous avez déjà créé votre **«Ingress»** et souhaitez conserver votre IP, il est possible de «promouvoir» une IP temporaire en statique avec le flag `--addresses` de la manière suivante:

`gcloud compute addresses create ADDRESS-1 ADDRESS-2 --addresses 162.222.181.197,162.222.181.198 --region europe-west1`
```
gcloud compute addresses create ADDRESS-1 ADDRESS-2 --addresses 162.222.181.197,162.222.181.198 --region europe-west1
``
On notera également la possibilité de fournir plusieurs adresses sur la même instruction.
# Création du «Service»
Pour terminer nous mettons en place le dernier «maillon» qui va venir se positionner entre notre «Ingress» et nos instances.
Pour terminer nous mettons en place le dernier «maillon» qui va venir se positionner entre notre **«Ingress»** et nos instances.
```
{{< highlight yaml >}}
apiVersion: v1
kind: Service
metadata:
Expand All @@ -203,15 +207,15 @@ spec:
protocol: TCP
port: 8080
targetPort: 8080
```
{{< /highlight >}}
Que l'on applique: `kubectl apply -f cramaillote-service.yml`
**Astuce**: La création de l'ensemble des éléments constituant notre infrastructure est un peu fastidieuse, celle-ci est gérable de manière globale avec des outils de déploiement spécifiques à Kubernetes comme [Helm](https://helm.sh/)
# Conclusion:
Même s'il est possible d'exposer directement un «Service» en le définissant comme répartiteur de charge, l'«Ingress» nous permet d'ajouter de la logique de routage en frontal de nos applications.
Il est en effet possible, de «router» les requêtes arrivant sur l'«Ingress» sur des «backends» différents à partir de règles que l'on défini.
Chose intéressante, un même «Ingress», sur ce même principe de règles de routage, peut être utilisé pour répondre à deux noms de domaine différent.
Pour termienr, nous utilisons un service HTTP pour notre exemple mais il est bien évident que les «Ingress» peuvent être configurés pour répondre à n'importe quel type de service.
Même s'il est possible d'exposer directement un **«Service»** en le définissant comme répartiteur de charge, l'**«Ingress»** nous permet d'ajouter de la logique de routage en frontal de nos applications.
Il est en effet possible, de «router» les requêtes arrivant sur l'**«Ingress»** vers des «backends» différents à partir de règles que l'on a défini.
Chose intéressante, un même **«Ingress»**, sur ce même principe de règles de routage, peut être utilisé pour répondre à deux noms de domaine différents.
Pour terminer, nous utilisons un service HTTP pour notre exemple mais il est bien évident que les **«Ingress»** peuvent être configurés pour répondre à n'importe quel type de service.

0 comments on commit 73884c3

Please sign in to comment.