Exoscale SKS : L’offre Kubernetes managée venue des Alpes arrive en force !

Publié le

J’ai eu l’opportunité de tester l’offre Kubernetes managée d’Exoscale. Cette offre, appelée SKS pour « Scalable Kubernetes Service » est en bêta publique depuis le 16 février 2021. Le produit sera GA à partir de mi-mars 2021.

L’interêt d’un tel produit sur le marché pour Exoscale est de pouvoir s’aligner sur ses concurrents en enrichissant son offre Cloud. Pour l’utilisateur final, l'avantage est de simplifier la mise en place d’une plateforme d’hébergement de containers, tout en n'ayant pas à administrer la partie control-plane.

Pourquoi SKS plutôt qu'un autre service Kubernetes managé ?

Il faut reconnaître que les offres Kubernetes managées ne sont pas exclusives à Exoscale. Depuis août 2015, GCS propose ce service, suivi par AWS et Azure (juin 2018). Ces providers leaders du marché, sont soumis à la législation américaine, défavorable à la protection des données, en particulier avec le Patriot Act. On peut ajouter que la tarification est parfois élevée. D'un autre côté, Exoscale étant un Cloud provider basé en Suisse, ses clients profitent d’une réglementation favorable à la confidentialité des données, tout en ayant une tarification prévisible et un rapport prix/performances excellent.

Face à ses concurrents européens (Scaleway, OVH Cloud, etc.), Exoscale propose une qualité de service élevée. Les performances des machines virtuelles notamment en I/O sur disque sont très bonnes (sur ce point, il suffit de faire un benchmark Exoscale vs OVH Cloud par exemple, pour s'en rendre compte). L’équipe Exoscale inclut dans son offre un support technique réactif pour tous ses clients. Même quand le sujet du ticket s'éttend en dehors de leur champ d'action, l’équipe propose des solutions pertinentes. Dans ce domaine, la concurrence propose bien souvent un support premium payant ou alors gratuit mais souvent inefficace.

Pour moi, l’argument clé en faveur de SKS est le suivi des versions : en févrirer 2021, la version 1.20.2 est déjà disponible. De plus, les mises à jour sont simples à exécuter : une seule commande suffit (exo sks upgrade ...) pour faire un rolling-upgrade du cluster vers une nouvelle version.

Quel public cible pour SKS ?

Comme on a pu le voir dans le tutoriel sur la mise en place de Kubernetes chez Exoscale, il n’est pas très compliqué de mettre en place un tel service… pour un spécialiste de la question. Par contre il faut être honnête, l’administrer correctement n’est pas si simple, surtout quand des problèmes surviennent. SKS permet de s’affranchir des tâches de maintenance du control-plane, ce qui permet de se concentrer sur l'utilisation du cluster plutôt que sur son administration.

Le use-case qui me paraît le plus pertinent avec cette offre, serait la mise en place d’une plateforme de développement et d’hébergement d’application web. Par exemple, une agence web pourrait déployer une telle plateforme avec SKS pour l’hébergement, un service Gitlab pour la gestion de leur code, puis l’intégration et le déploiement continu de ce code vers SKS grâce à Gitlab CI et Helm.

Une autre utilisation de SKS serait intéressante avec des instances de type GPU pour divers workloads de calcul lourds (encodage vidéo, apprentissage d'IA, etc). La simplicité à upscale et downscale le cluster permettrait une gestion avantageuse des coûts.

Tests

Pour le moment, l’installation de SKS se fait uniquement avec l’outil exo en ligne de commande ou le provider Terraform d'Exoscale. L'intégration dans l’interface web de gestion d’Exoscale est prévue pour mi-mars 2021. Le cluster provisioné utilise Calico comme plugin CNI, et Docker comme runtime (le choix de Docker est d’ailleurs spécial, sachant que Docker est déprécié depuis Kubernetes 1.20)

Installation avec exo

Nous commençons par créer la security-group pour les nœuds du cluster :

exo firewall create sks-sg
# Node Ports depuis toutes les sources
exo firewall add sks-sg -p tcp -P 30000-32767
# kubectl logs / exec depuis toutes les sources
exo firewall add sks-sg -p tcp -P 10250
# Calico entre les nœuds uniquement
exo firewall add sks-sg -p udp -P 4789 -s sks-sg

Nous provisionnons ensuite le cluster en lui-même :

exo sks create test-sks \
		--description "test-sks" \
		--nodepool-name "test-sks-pool" \
		--nodepool-size 3 \
		--nodepool-security-group "sks-sg" \
		--zone ch-gva-2 \
		--kubernetes-version 1.20.2

Cette opération se termine en un peu plus d'une minute chez moi, avec ce type de résultat :

┼───────────────┼──────────────────────────────────────────────────────────────────┼
│  SKS CLUSTER  │                                                                  │
┼───────────────┼──────────────────────────────────────────────────────────────────┼
│ ID            │ a1632827-d893-4c77-9e06-bf18022febce                             │
│ Name          │ test-sks                                                         │
│ Description   │ test-sks                                                         │
│ Zone          │ ch-gva-2                                                         │
│ Creation Date │ 2021-02-11 15:04:30 +0000 UTC                                    │
│ Endpoint      │ https://a1632827-d893-4c77-9e06-bf18022febce.sks-ch-gva-2.exo.io │
│ Version       │ 1.20.2                                                           │
│ Service Level │ pro                                                              │
│ CNI           │ calico                                                           │
│ Add-Ons       │ exoscale-cloud-controller                                        │
│ State         │ running                                                          │
│ Nodepools     │ 36cb2005-adae-4fe1-a78c-98ac56858884 | test-sks-pool             │
┼───────────────┼──────────────────────────────────────────────────────────────────┼

Il nous reste à exporter la configuration pour se connecter au cluster depuis notre poste :

mkdir -p $HOME/.kube
exo sks kubeconfig test-sks admin -g system:masters -t $((86400 * 7)) > $HOME/.kube/config

Un test rapide nous permet de voir la situation du cluster fraîchement provisionné :

kubectl get pods,svc -o wide --all-namespaces

Voici le résultat :

NAMESPACE     NAME                                          READY   STATUS    RESTARTS   AGE     IP                NODE               NOMINATED NODE   READINESS GATES
kube-system   pod/calico-kube-controllers-86bddfcff-sjqzs   1/1     Running   0          12m     192.168.178.66    pool-8080a-hbmag   <none>           <none>
kube-system   pod/calico-node-798x4                         1/1     Running   0          10m     194.182.162.130   pool-8080a-syoya   <none>           <none>
kube-system   pod/calico-node-qfwf9                         1/1     Running   0          10m     194.182.161.41    pool-8080a-exlqs   <none>           <none>
kube-system   pod/calico-node-x88g2                         1/1     Running   0          10m     194.182.162.67    pool-8080a-hbmag   <none>           <none>
kube-system   pod/coredns-56bd9b9785-g28g8                  1/1     Running   0          12m     192.168.178.65    pool-8080a-hbmag   <none>           <none>
kube-system   pod/kube-proxy-5ckwq                          1/1     Running   0          9m55s   194.182.162.67    pool-8080a-hbmag   <none>           <none>
kube-system   pod/kube-proxy-5hs4x                          1/1     Running   0          9m44s   194.182.161.41    pool-8080a-exlqs   <none>           <none>
kube-system   pod/kube-proxy-95qjr                          1/1     Running   0          9m45s   194.182.162.130   pool-8080a-syoya   <none>           <none>

NAMESPACE     NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                  AGE   SELECTOR
default       service/kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP                  13m   <none>
kube-system   service/kube-dns     ClusterIP   10.96.0.10   <none>        53/UDP,53/TCP,9153/TCP   12m   k8s-app=kube-dns

Dans l'interface de gestion d'Exoscale, nous arrivons à ce résultat :

2021-02-11-Exoscale-Pool.png

Note sur les pools

L’installation du cluster met en place un pool par défaut, ce qui sera suffisant pour un usage basique. Cependant, l’offre SKS permet de gérer plusieurs pools de workers avec les commandes suivantes :

# Ajout d'un pool avec un worker (test-sks-pool-b)
exo sks nodepool add test-sks test-sks-pool-b --size 1 --security-group sks-sg
# Upscale du pool 'test-sks-pool-b' à 4 workers
exo sks nodepool scale test-sks test-sks-pool-b 4
# Downscale du pool 'test-sks-pool-b' à 1 workers
exo sks nodepool scale test-sks test-sks-pool-b 1
# Suppression du pool 'test-sks-pool-b'
exo sks nodepool delete test-sks test-sks-pool-b

Déploiement d’un service de test

Nous créons un fichier whoami.yaml contenant un déploiement de l'image containous/whoami, ainsi qu'un service de type LoadBalancer :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: whoami-deployment
  labels:
    app: whoami
spec:
  replicas: 3
  selector:
    matchLabels:
      app: whoami
  template:
    metadata:
      labels:
        app: whoami
    spec:
      containers:
      - name: whoami
        image: containous/whoami
        ports:
        - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
  name: website
  annotations:
    service.beta.kubernetes.io/exoscale-loadbalancer-zone: "ch-gva-2"
spec:
  selector:
    app: whoami
  type: LoadBalancer
  ports:
  - port: 80

Nous pouvons ensuite installer ces éléments :

kubectl apply -f whoami.yaml
watch kubectl get pods,svc

Nous arrivons rapidement à ce type de sortie :

Every 2.0s: kubectl get pods,svc
NAME                                     READY   STATUS    RESTARTS   AGE
pod/whoami-deployment-7548d6596b-fs4tj   1/1     Running   0          29s
pod/whoami-deployment-7548d6596b-j6jqz   1/1     Running   0          29s
pod/whoami-deployment-7548d6596b-w44cl   1/1     Running   0          29s

NAME                 TYPE           CLUSTER-IP       EXTERNAL-IP       PORT(S)        AGE
service/kubernetes   ClusterIP      10.96.0.1        <none>            443/TCP        3h22m
service/website      LoadBalancer   10.110.101.204   194.182.163.229   80:30200/TCP   29s

Le Load Balancer est visible aussi dans l'interface de gestion :

2021-02-11-Exoscale-LoadBalancer-Short.png

Nous pouvons tester le load-balancing avec l'adresse ip externe du service, 194.182.163.229 via curl :

curl 194.182.163.229

L'application whoami renvoie son hostname, qui, dans ce déploiement, est le nom du Pod :

Hostname: whoami-deployment-7548d6596b-w44cl
IP: 127.0.0.1
IP: 192.168.10.115
RemoteAddr: 192.168.31.192:16028
GET / HTTP/1.1
Host: 194.182.163.229
User-Agent: curl/7.64.1
Accept: */*

Nous relançons cette commande plusieurs fois :

Hostname: whoami-deployment-7548d6596b-j6jqz
IP: 127.0.0.1
IP: 192.168.201.249
RemoteAddr: 192.168.10.64:12653
GET / HTTP/1.1
Host: 194.182.163.229
User-Agent: curl/7.64.1
Accept: */*

(on notera que le Hostname a changé, la requête a été traité par deux Pod différents)

Par défaut le load balancer implémente une politique de round-robin.

Points d’amélioration

L'offre SKS pourrait être améliorée avec les fonctionnalités suivantes :

  • le cluster autoscaling : pour permettre une meilleure mise à l’échelle du cluster, en augmentant ou en diminuant automatiquement le nombre de nœuds de celui-ci. Le Cluster Autoscaler arrivera certainement dans les mois à venir, il est déjà en cours de développement, soyons patients...
  • une offre de block storage : permettrait de provisionner automatiquement des volumes dans le cluster, au travers du mécanisme de PersistentVolumeClaim/PersistantVolume. Il faudrait qu'Exoscale implémente au préalable un service de volumes additionels dans son Cloud. Une solution alternative, est d'utiliser un serveur NFS, ou encore de se tourner vers des solutions comme Longhorn, ou OpenEBS.

Il serait interessant de multiplier les options de configuration :

  • La possibilité d’avoir un autre composant CNI que Calico dans l’offre de base, comme Cilium qui offre des fonctionnalités d’observabilité très interessantes. En attendant, c’est faisable en désactivant le déploiement de la CNI (option --no-cni d'exo sks) puis en installant le plugin souhaité manuellement.
  • Le choix d'un autre runtime que Docker, comme containerd ou CRI-O.
  • Le déploiement automatique d’un Ingress Controller dès l’installation de SKS.

Conclusion

L’offre SKS est très prometteuse. Les choix techniques pour SKS, Docker et Calico sont standards, même si je m'attendais plutôt à trouver containerd ou CRI-O comme runtime.
Cette offre étant très jeune, on peut s’attendre à beaucoup d’évolutions, notamment en terme de fonctionnalité et d’options de configuration.
De par sa simplicité de mise en œuvre, SKS conviendra particulièrement aux structures qui n'ont pas envie d'administrer leur cluster elles même.
Bravo à l’équipe d’Exoscale ! 🎉

Autres références

PHILIPPE CHEPY

Administrateur Système et Développeur