Blog

déployer une application dans Kubernetes

C’est la suite du billet précédent qui parlait des sidecars Kubernetes que j’ai utilisé pour exposer une application Django (backend + statics). Maintenant que j’ai un service, je dois pouvoir y accéder depuis l’extérieur via une URL ou une IP. Je suis dans un contexte où mon cluster Kubernetes est autohébergé avec un seul node (dans une VM Linux sur mon poste de dev). Pour rappel, seul les plateformes Cloud propose des Load Balancers. Pour palier à ce problème, je vais tout simplement exposer le contrôleur de l’ingress Nginx sur le réseau de la machine hôte.

Installation de Nginx Ingress

Installons le gestionnaire d’Ingress Nginx

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/baremetal/deploy.yaml

Du classique, maintenant patchons le déploiement du contrôleur nginx :

kubectl patch deployment ingress-nginx-controller -n ingress-nginx -p '{"spec":{"template":{"spec":{"hostNetwork":true}}}}'

Vérifions

kubectl get nodes -o wide
NAME                    STATUS   ROLES                  AGE   VERSION        INTERNAL-IP    EXTERNAL-IP   OS-IMAGE                  KERNEL-VERSION                CONTAINER-RUNTIME
localhost.localdomain   Ready    control-plane,master   28m   v1.21.7+k3s1   192.168.0.84   <none>        Oracle Linux Server 8.5   4.18.0-348.2.1.el8_5.x86_64   containerd://1.4.12-k3s1

kubectl get pod -n ingress-nginx
NAME                                            READY   STATUS      RESTARTS   AGE   IP             NODE                    NOMINATED NODE   READINESS GATES
pod/ingress-nginx-controller-7b8bdb996c-5xzlc   1/1     Running     0          23m   192.168.0.84   localhost.localdomain   <none>           <none>

L’IP du contrôleur est bien celui du node. On peut vérifier que sur le node on a bien les ports 80 et 443 en écoute :

netstat -tlnp | grep -E '0.0.0.0:80|0.0.0.0:443'
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      -

Cool !

Déclaration d’un Ingress

Pour valider son fonctionnement je vais déclarer un ingress pour le service créé dans le billet précédent :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$1

spec:
  ingressClassName: nginx
  rules:
    - host: monapp.robert.local
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: monapp-service
              port:
                number: 5000

On applique l’ingress :

kubectl apply -f app-ingress.yml

kubectl get ingress
NAMESPACE   NAME         CLASS   HOSTS                 ADDRESS        PORTS     AGE
default     app    nginx   monapp.robert.local   192.168.0.84   80      13m

kubectl describe ingress monapp
Name:             app
Namespace:        default
Address:          192.168.0.84
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
Rules:
  Host                 Path  Backends
  ----                 ----  --------
  monapp.robert.local
                       /   monapp-service:5000 (10.42.0.8:5000)
Annotations:           nginx.ingress.kubernetes.io/rewrite-target: /$1
Events:
  Type    Reason  Age                From                      Message
  ----    ------  ----               ----                      -------
  Normal  Sync    12m (x2 over 13m)  nginx-ingress-controller  Scheduled for sync

Un pti curl pour valider que cela fonctionne :

curl -Lkv http://192.168.0.84/ -H 'monapp.robert.local'

Hello

C’est simple et efficace pour un environnement de Dev.

Source : https://moonstreet.nl/post/k3s-with-ingress/

Ma problématique : utiliser nginx comme reverse proxy pour exposer une application Django tournant sur un serveur uWSGI, ainsi que ses statics afin de limiter les requêtes HTTP.

pense-bête

Devops

pipx

transformation d’une application pour la rendre cloud native

Ansible collecte énormément de données des serveurs qu’il configure via ce qu’on appelle les facts. Il existe un outil qui répond au nom d’Ansible-CMDB, qui prend en charge plusieurs types de sortie (html, csv, sql, json, markdown …) et qui donc permet d’obtenir rapidement l’état de santé de votre parc informatique. Par exemple, on peut voir quelle version d’OS, le dernier reboot, la version du kernel, la ram, le nombre de cpu, l’occupation des disques, le taux d’utilisation de la RAM, …

Suite à ma à l’écriture de ma configuration Terraform permettant de provisionner des machines EC2 AWS, je me suis fixé comme objectif de configurer Gitlab pour qu’il utilise mes propres runners dynamiquement.

Terraform Cloud

Terraform

L’objectif de ce billet est de mettre en place ce qu’il faut pour qu’à la fin, vous soyez capable de provisionner une machine sur le Cloud de Google avec Terraform et de la configurer avec Ansible.