logo
< Back Post-Image

Managed OVH Kubernetes

By Kevin Lefevre at 7 May 2020

On peut distinguer deux types de clusters Kubernetes, ceux qui sont managés et ceux qui ne le sont pas. Un Kubernetes managé est un cluster Kubernetes dont vous ne gérez pas le control plane. Généralement via une interface web ou une API, vous pouvez demander la création d’un cluster Kubernetes. On considère que le control plane est managé car vous n’aurez pas à faire les updates vous même, la supervision est souvent déjà configurée etc. Les workers peuvent être parfois managés, c’est le cas notamment avec les managed node groups sur EKS ou les node pools sur GKE.

Les workers peuvent parfois être serverless, par exemple avec EKS/Fargate associé par Virtual Kubelet dont nous avons parlé sur ce blog

Dans les deux cas, les ressources de calcul sont généralement à votre charge.

La quasi totalité des cloud public providers fournissent une solution managée de Kubernetes :

Toutes ces solutions ont en commun d’être certifiées conformes par la CNCF.

kubernetes certified

Après avoir testé la solution Kapsule de Scaleway, nous allons aujourd’hui tester le Kubernetes managé d’OVH.

Pricing

Comme beaucoup de fournisseurs, le service managé est gratuit et la facturation est realisée uniquement sur les noeuds, suivant les types d’instances.

Déploiement d’OVH Kubernetes

Il est possible dans un premier temps d’accéder au service Kubernetes managé depuis votre console OVH public Cloud.

Il est ensuite possible de sélectionner la région ainsi que la version du cluster. Les versions proposées vont de 1.15 à 1.17. Nous allons déployer un cluster en 1.17.

Le cluster est disponible en 5 minutes, il est temps d’ajouter des nœuds. La console OVH propose une interface pour gérer le cluster et les nœuds. Les nœuds disponibles sont les même instances que celles proposées par le public cloud OVH. Pour le moment les nœuds sont rajoutés de manière individuelle mais le concept de node pool et d’autoscaling sera disponible cette année.

Pour le moment, pas de GPU avec Kubernetes mais un OVH lab est en cours d’élaboration qui permettra d’ajouter des nœuds bare metal avec des GPU.

Rajouter des nœuds se fait simplement dans l’interface :

Récupération du Kubeconfig

Le Kubeconfig est téléchargeable également depuis l’interface. Il est ensuite possible d’accéder au cluster:

$ export KUBECONFIG=$(pwd)/kubeconfig.yml

$ kubectl get nodes -o wide

NAME          STATUS   ROLES    AGE    VERSION   INTERNAL-IP     EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
particule     Ready    <none>   17m    v1.17.5   51.210.39.198   <none>        Ubuntu 18.04.4 LTS   4.15.0-96-generic   docker://18.6.3
particule-b   Ready    <none>   109s   v1.17.5   51.210.36.244   <none>        Ubuntu 18.04.4 LTS   4.15.0-96-generic   docker://18.6.3

$ kubectl get pods -o wide --all-namespaces

NAMESPACE     NAME                                   READY   STATUS    RESTARTS   AGE     IP              NODE          NOMINATED NODE   READINESS GATES
kube-system   canal-br6v7                            2/2     Running   0          2m21s   51.210.36.244   particule-b   <none>           <none>
kube-system   canal-zrl4j                            2/2     Running   0          17m     51.210.39.198   particule     <none>           <none>
kube-system   coredns-76bd8dbd8c-gm9bk               1/1     Running   0          2m11s   10.2.0.5        particule     <none>           <none>
kube-system   coredns-76bd8dbd8c-hg49c               1/1     Running   0          32m     10.2.0.2        particule     <none>           <none>
kube-system   kube-dns-autoscaler-64bc6d94b9-79x2z   1/1     Running   0          32m     10.2.0.3        particule     <none>           <none>
kube-system   kube-proxy-rmglz                       1/1     Running   0          17m     51.210.39.198   particule     <none>           <none>
kube-system   kube-proxy-tr8s9                       1/1     Running   0          2m21s   51.210.36.244   particule-b   <none>           <none>
kube-system   metrics-server-857c75cd6f-7mxx6        1/1     Running   0          31m     10.2.0.4        particule     <none>           <none>
kube-system   wormhole-4dztq                         1/1     Running   0          2m21s   51.210.36.244   particule-b   <none>           <none>
kube-system   wormhole-pvzjf                         1/1     Running   0          17m     51.210.39.198   particule     <none>           <none>

La solution de CNI utilisée est canal, qui combine flannel et calico pour les network policy.

Pour l’instant le trafic transit sur le réseau public d’OVH et est chiffré via la solution CNI wormhole. L’integration au vRack et la possibilité de créer des clusters privés sera ajoutée dans l’année.

Comment automatiser ?

OVH dispose d’un provider Terraform, malheureusement la ressource Kubernetes n’est pas disponible pour le moment mais on nous dit dans l’oreillette que ca ne saurait tarder.

Il est tout de même possible de déployer via l’API, cette API est également accessible via une WebUI qui propose de piloter les différents services offert par OVH.

Fonctionnalités disponibles

Parmi les fonctionnalités exposées, on notera l’intégration au stockage persistant Cinder pour les workloads statefuls (support du redimensionnement), la gestion de l’autoscaling des pods via HPA ainsi que l’intégration des loadbalancers.

Une liste des différentes fonctionnalités est disponible ici.

Mini demo

Pour tester les loadbalancers et les volumes Cinder, vous pouvez utiliser ce yaml :

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-world
  labels:
    app: hello-world
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello-world
  template:
    metadata:
      labels:
        app: hello-world
    spec:
      containers:
      - name: hello-world
        image: particule/helloworld:latest
        ports:
        - containerPort: 80
        volumeMounts:
        - mountPath: "/claim"
          name: pv-storage
      volumes:
      - name: pv-storage
        persistentVolumeClaim:
          claimName: pv-claim
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: hello-world
  name: hello-world
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
  selector:
    app: hello-world
  type: LoadBalancer
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pv-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

Puis:

$ kubectl apply -f ovh.yaml
deployment.apps/hello-world created
service/hello-world created
persistentvolumeclaim/pv-claim created

Après quelques minutes, les ressources sont disponibles.

$ kubectl get pods

NAME                           READY   STATUS    RESTARTS   AGE
hello-world-6cf5f597cb-6jvrj   1/1     Running   0          5m19s

$ kubectl get pv

NAME                                                                     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM              STORAGECLASS            REASON   AGE
ovh-managed-kubernetes-rq4ajb-pvc-aa2e0e0c-d44b-4210-89f0-293f6ed7f94a   10Gi       RWO            Delete           Bound    default/pv-claim   csi-cinder-high-speed            10m

$ kubectl get pvc

NAME       STATUS   VOLUME                                                                   CAPACITY   ACCESS MODES   STORAGECLASS            AGE
pv-claim   Bound    ovh-managed-kubernetes-rq4ajb-pvc-aa2e0e0c-d44b-4210-89f0-293f6ed7f94a   10Gi       RWO            csi-cinder-high-speed   10m

$ kubectl get svc

NAME          TYPE           CLUSTER-IP   EXTERNAL-IP                         PORT(S)        AGE
hello-world   LoadBalancer   10.3.46.3    6epat74kjk.lb.c1.gra7.k8s.ovh.net   80:32063/TCP   8m3s

Notre service est accessible sur l’url http://6epat74kjk.lb.c1.gra7.k8s.ovh.net

On peut également voir dans le pod notre volume persistant monté dans /claim.

$ kubectl exec -it hello-world-6cf5f597cb-6jvrj -- /bin/sh

$ df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/sdb                  9.8G     36.0M      9.7G   0% /claim

Fonctionnalité prévues

Nous les avons mentionnées en cours d’article mais un petit récapitulatif ne fait pas de mal :

  • Intégration au vRack pour les clusters et réseaux privés.
  • Autoscaling des nœuds via la fonction de node groups
  • Nœuds baremetal et GPU.

Conclusion

Le service reste pour le moment un peu limité en terme de fonctionnalités mais une fois intégré avec le catalogue de services OVH et notamment le vRack, les possibilités d’intégration seront fortement étendues. Pour nous, intégrer ce service aux modules Terraform est également un “must have”.