Cours de virtualisation avancée: Kubernetes, suite

1. Déploiement

1.1. Rolling Updates

Permet des mises à jour d'images sans temps de coupure 

---
...
spec:
  ...
  strategy: 
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
  ...
  • maxUnavailable: défini le nombre maximal de replicas indisponibles
  • maxSurge: défini le nombre maximal de replicas à mettre à jour en même temps

Ensuite, mettre à jour l'image avec: 

kubectl set image deployment/<nom déploiement> <nom conteneur>=<nouvelle image:tag>

But:

  • Mettre à jour l'application sans downtime

1.2. Déploiement blue / green

Client
Service
Déploiement
green
Déploiement
blue
Client
Service
Déploiement
green
Déploiement
blue

  • On déploie la nouvelle version en parallèle de l'ancienne
  • Une fois que tout est déployé on redirige le trafic vers le nouveau déploiement

But:

  • Tester le déploiement de la nouvelle version avant de la basculer en prod

1.3. Déploiement canary

Client
Service
Version 1
Version 2

  • On déploie la nouvelle version en parallèle de l'ancienne avec moins de replicas
  • Automatiquement une petite partie des clients tomberont sur la nouvelle version

But:

  • Faire tester à quelques utilisat(eur|rice)s aléatoires la nouvelle version

2. Mise à l'échelle (scaling)

  • Nécessaire quand la charge augmente
  • Par exemple pour suivre l'augmentation du trafic de notre application

2.1. Verticale (vertical scaling)

2.1.1. Fonctionnement

  • On augmente la puissance des nœuds
  • Augmente les capacité de l'application existante
  • L'application n'a pas besoin d’être capable de gérer la réplication

2.1.2. Inconvénients

  • Augmentation des coûts
  • Coûts pas toujours proportionnels à la puissance des nœuds
  • Si nœud déjà au max: comment faire ?

2.2. Horizontale (horizontal scaling)

2.2.1. Fonctionnement

  • On ajoute des nœuds (et donc des nouvelles instances) à l'infra
  • La charge de travail est donc répartie entre les instances
  • L'application a besoin d’être capable de gérer la réplication

2.2.2. Inconvénients

  • Augmentation des coûts
  • On peut se retrouver avec beaucoup de nœuds

2.3. Horizontal scaling dans K8S

doc doc 

kubectl autoscale deployment <nom déploiement> \
        --cpu-percent=50 --min=1 --max=10

Demande au cluster de créer entre min et max replicas selon la charge du CPU du nœud

2.4. Vertical scaling dans K8S

Compliqué à mettre en place sur sa propre infra étant donné qu'il faut changer les ressources des machines.

3. Réseau

3.1. Rappels

podpodpod
Coté cluster
podpod
Service
Service
Ingress
Ingress

3.2. Ingress

doc doc

  • Permet d'exposer nos services en dehors du cluster
  • Assez similaire à un reverse proxy comme vous aviez déjà vu avec Nginx
  • Nécessite des ressources configurées par les administrat(eur|rice)s du cluster
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
spec:
  defaultBackend:
    service:
      name: testsvc
      port:
        number: 80

❯ kubectl get ingress test-ingress
NAME           HOSTS     ADDRESS           PORTS     AGE
test-ingress   *         107.178.254.228   80        59s
  • Peut aussi servir de routeur HTTP en dirigeant le trafic des routes vers différents services
...
  - host: foo.bar.com
    http:
      paths:
      - path: /foo
        pathType: Prefix
        backend:
          service:
            name: service1
            port:
              number: 4200
      - path: /bar
        pathType: Prefix
        backend:
          service:
            name: service2
            port:
              number: 8080

4. Sécurité et gestion d'utilisat(eur|rice)s

4.1. Contrôle d'accès basé sur les rôles (RBAC)

doc

  • Permet de réguler l'accès aux ressources en fonction de rôles attribués aux utilisat(eur|rice)s

4.1.1. Role et ClusterRole

Pour créer les rôles (au sens large) 

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
  • Ce rôle permet de définir un accès en lecture seule aux pods de l'espace de noms default
  • Le type Role concerne toujours l'espace de noms dans lequel il est créé
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # pas de "namespace"
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
  • Ce rôle permet de définir un accès en lecture seule aux pods dans n'importe quel espace de noms

4.1.2. RoleBinding et ClusterRoleBinding

Pour accorder les rôles (au sens large) à un.e ou des utilisat(eur|rice)s, ou un groupe 

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane # sensible à la casse
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

5. Helm

doc

  • Une sorte de "gestionnaire de paquets" pour Kube
  • Permet de "packager" des applications
  • Permet d'installer des outils "grand public" sans se prendre la tête

5.1. Exemple d'utilisation

6. Aller plus loin