Résilience et scalabilité

[Challenge 5.1] Résilience et scalabilité Beginner

L’application antennas-incident a 2 endpoints qui fournissent des health checks :

  • q/health/live pour le liveness probe

  • q/health/ready pour le readiness probe

Il va falloir mettre à jour les resources K8s afin d’utiliser ces probes.

Ensuite, il faut mettre en place un HPA (Horizontal Pod Autoscaler). Mettez des valeurs assez basses pour faire réagir simplement le HPA.

Voici un exemple d’un HPA :

kind: HorizontalPodAutoscaler
apiVersion: autoscaling/v2beta2
metadata:
  name: example
  namespace: myspace
spec:
  scaleTargetRef:
    kind: Deployment
    name: mydeployment
    apiVersion: apps/v1
  minReplicas: 1
  maxReplicas: 3
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: AverageValue
          averageValue: 15m

Voilà un exemple de commande permettant de stresser un peu notre backend afin de faire réagir le HPA: oc run stresspod --restart=Never --image registry.access.redhat.com/ubi8/ubi-minimal --command — sh -c "while :; do curl 'http://<antennas-incident service name>/rest/incidents?api_key=<votre secret>' ; done"

Après quelques secondes, vous devriez avoir plusieurs PODs.

Preuves à fournir

  • [Challenge 5.1.1] Screenshot ou manifest yaml du déploiement d’antennas-incident montrant les readinessProbe et livenessProbe

  • [Challenge 5.1.2] Screenshot de la console faisant apparaître "Autoscaled to …​" ou manifest yaml du HPA

Pensez à supprimer le POD "stresspod" si besoin (oc delete po/stresspod) : après quelques minutes, le HPA devrait réduite le nombre de PODs.

Notes : nous avons utilisé ici la fonctionnalité "HorizontalPodAutoscaler" qui permet d’ajuster notre nombre de PODs dynamiquement. Il existe également le "VerticalPodAutoscaler" (https://docs.openshift.com/container-platform/4.8/nodes/pods/nodes-pods-vertical-autoscaler.html) qui permet de modifier dynamiquement les ressources affectées à des PODs.

[Challenge 5.2] Chaos Kube Advanced

Chaos testing with chaoskube - Introduction

GitHub repository du projet: https://github.com/linki/chaoskube/

Le principe est de mettre en place un outil qui va nous permettre de simuler des pannes aléatoires sur un projet afin d’améliorer la résistance des applications pour surmonter ces pannes en utilisant des fonctionnalités de kubernetes.

Installation de chaoskube

Préambule

OpenShift impose un certain nombre de restrictions liées à la sécurité qui n’exitent pas sur d’autres environements kubernetes.

Par example, sur OpenShift les SCCs (Security Context Constraints) ajoute un niveau de sécurité supplémentaire au cluster kubernetes en restreignant les droits alloués aux comptes de services en charge de l’execution des containers.

OpenShift fait également attention à assigner des user ids uniques par pod au sein d’un même projet.

Cependant, ce niveau de sécurité plus élevé demande parfois de réaliser quelques modifications et un peu d’adaptation pour pouvoir deployer des applications qui n’ont pas encore été testées sur OpenShift. À noter que ça n’est pas réciproque, une application packagée et testée pour OpenShift se déploiera généralement sans modification sur une autre distribution kubernetes.

oc new-project chaoskube
oc adm policy add-scc-to-user runasanyuid -z chaoskube
cat <<-EOF > values-override.yaml
podSecurityContext:
   runAsUser:
EOF

Dans le cas présent, on remplace les valeurs de configurations par défaut dans le template helm en créant un fichier values-override.yaml.

Vous pouvez également attribuer une SCC au compte de service chaoskube (anyuid ou runasanyuid en fonction de la version d’OpenShift) pour palier à ce problème.

oc adm policy add-scc-to-user anyuid -z chaoskube

Ou bien, créer un fork du repository git chaoskube, faire la modification dans votre repository et soumettre une pull request aux développeurs de chaoskube.
Déploiement Helm

Ensuite, procéder à l’installation comme spécifié dans la documentation en omettant de créer le namespace:

helm repo add chaoskube https://linki.github.io/chaoskube/
helm install chaoskube chaoskube/chaoskube --atomic --namespace=chaoskube -f ./values-override.yaml

Vérifier le bon déploiement:

$ oc -n chaoskube get pods
NAME                        READY   STATUS    RESTARTS   AGE
chaoskube-b88449d95-zfbv7   1/1     Running   0          6s

$ oc -n chaoskube logs -f $(oc -n chaoskube get pods -l app.kubernetes.io/instance=chaoskube -oname)
...
Cleanup

Chaoskube devrait être déployé et fonctionnel. Cependant, nous souhaitons le paramétrer pour ne cibler que des applications spécifiques et à une fréquence différente.

Pour consulter les paramètres de configuration disponibles, vous pouvez lire la documentation mais également les consulter de la façon suivante:

oc -n chaoskube exec -ti  $(oc -n chaoskube get pods -l app.kubernetes.io/instance=chaoskube -oname) --  /usr/local/bin/chaoskube --help
usage: chaoskube [<flags>]

Flags:
  --help                         Show context-sensitive help (also try --help-long and --help-man).
  --labels=LABELS                A set of labels to restrict the list of affected pods. Defaults to everything.
...

Pour supprimer le déploiement de chaoskube:

helm uninstall chaoskube

Note: un chart helm peut être configuré en utilisant un fichier values.yaml ou values-override.yaml (voir le déploiement initial) qui remplace les paramètres définis par défaut.

[Exercice]

En partant d’un déploiement simple, utiliser chaoskube pour tester la résilience de cette application: * cibler exclusivement le namespace de l’application * tuer des ressources toutes les 15 secondes * s’assurer que les pods sont bien détruits dans le namespace ciblé

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: chaoskube-test
  name: chaoskube-test
  namespace: chaoskube-test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: chaoskube-test
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: chaoskube-test
    spec:
      containers:
      - command:
        - /bin/sh
        - -c
        - sleep INF
        image: quay.io/xymox/ubi8-debug-toolkit:latest
        name: ubi8-debug-toolkit
        resources: {}
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              topologyKey: kubernetes.io/hostname
status: {}
Vous pouvez modifier les paramètres de ce descripteur de déploiement pour augmenter la disponibilité de l’application

Preuves à fournir

  • [Challenge 5.2.1] fichier values-override.yaml + extrait des logs chaoskube prouvant la destruction de pods dans l’intervalle de temps défini

  • [Challenge 5.2.2] Output des pods applicatifs incluant leur statut et leur âge démontrant la disponibilité de l’application malgré les destructions aléatoires

BONUS challenge - Antenna Front chaos

En utilisant le projet antenna-front, configurez chaoskube pour y appliquer le chaos testing.

Preuves à fournir

  • [Challenge 5.2.3] logs chaoskube prouvant la destruction de pods dans l’intervalle de temps défini plus évidences du test de l’API (http) pendant 2 minutes affichant son taux de disponibilité (script utilisé + résultats)