AKS on Zwindler's Reflection

Sauvegarder son Kubernetes avec Velero (ex Ark)

Mon, 02 Aug 2021 06:15:00 +0000

Contexte

J’ai écris cet article / tuto en janvier 2019 sans jamais le terminer / mettre en forme. A l’époque, Heptio était en train de se faire racheter par VMware. Au moment où j’allais le poster, VMware a fait quelques modifications dans le tool, notamment en changeant le nom de Ark vers Velero et en l’intégrant à Tanzu (le Kubernetes de VMware).

Idéalement, j’aurais donc aimé réécrire l’article en remettant tout à jour, les noms, les lignes de commandes, etc. Sauf que je ne l’ai jamais fait. Et aujourd’hui, je ne travaille plus sur des clusters Kubernetes avec des workloads majoritairement Stateful et préfère l’approche Déclarative (type FluxCD) dans l’hypothèse où j’aurais un énorme crash à gérer plutôt que de tenter une restauration, avec tous les effets de bords et les risques que ça implique.

Cependant, plutôt que de mettre cet article « presque fini » à la corbeille, je prend donc le parti de le poster « tel quel », avec tous les défauts qu’il pourra avoir (notamment si certaines parties sont outdated). Le concept général lui, restera le même.

Pour illustrer le propos, j’avais déployé un cluster AKS mais ça marche bien évidemment avec n’importe quel cluster Kubernetes.

Générer le cluster K8s AKS

az login
az group create --name myownkubernetescluster --location westeurope \
--subscription "Visual Studio Professional"
az aks create --resource-group myownkubernetescluster --name myawesomeakscluster \
--node-count 3 --enable-addons monitoring --node-vm-size Standard_B2s \
--kubernetes-version 1.10.9 --ssh-key-value ~/.ssh/dgermain_never_expire_rsa_openssl2.pub \
--subscription "Visual Studio Professional"
az aks get-credentials --resource-group myownkubernetescluster --name myawesomeakscluster \
--subscription "Visual Studio Professional"

Éventuellement ajouter les droits pour le dashboard

kubectl create clusterrolebinding kubernetes-dashboard --clusterrole=cluster-admin --serviceaccount=kube-system:kubernetes-dashboard
az aks browse --resource-group myownkubernetescluster --name myawesomecluster

Sauvegarde / restauration avec Velero

Information sur Velero (Ark Heptio) github.com/vmware-tanzu/velero

Comme on est sur Azure dans mon exemple :

github.com/vmware-tanzu/velero-plugin-for-microsoft-azure#setup

On commencer par créer un ressource group spécifique aux backups (pour ne pas tout perdre si le ressource group est supprimé)

AZURE_BACKUP_RESOURCE_GROUP=arkbackups
az group create -n $AZURE_BACKUP_RESOURCE_GROUP --location westeurope \
--subscription "Visual Studio Professional"
AZURE_STORAGE_ACCOUNT_ID="ark$(uuidgen | cut -d '-' -f5 | tr '[A-Z]' '[a-z]')"
az storage account create \
--name $AZURE_STORAGE_ACCOUNT_ID \
--resource-group $AZURE_BACKUP_RESOURCE_GROUP \
--sku Standard_GRS \
--encryption-services blob \
--https-only true \
--kind BlobStorage \
--access-tier Hot \
--location westeurope \
--subscription "Visual Studio Professional"
az storage container create -n arkblob --public-access off \
--account-name $AZURE_STORAGE_ACCOUNT_ID --subscription "Visual Studio Professional"

Récupérer le groupe de ressource du cluster K8s

az group list --query '[].{ ResourceGroup: name, Location:location }' --subscription "Visual Studio Professional"
[...]
{
"Location": "westeurope",
"ResourceGroup": "MC_myownkubernetescluster_myawesomeakscluster_westeurope"
},
{
"Location": "westeurope",
"ResourceGroup": "myownkubernetescluster"
}

Dans le cas d’AKS, il s’agit bien de choisir le groupe qui contient les VMs (MC_myownkubernetescluster_myawesomeakscluster_westeurope), et pas celui que vous avez créé en début de procédure (myownkubernetescluster) qui ne contient que l’objet « Kubernetes service ».

AZURE_RESOURCE_GROUP=MC_myownkubernetescluster_myawesomeakscluster_westeurope

Créer un « Service principal » (compte de service dans Azure). Ne pas oublier de stocker le secret (contenu de la variable AZURE_CLIENT_SECRET) car on y aura plus accès a posteriori.

AZURE_CLIENT_SECRET=`az ad sp create-for-rbac --name "myarkserviceprincipal" --role "Contributor" --query 'password' -o tsv`
AZURE_CLIENT_ID=`az ad sp list --display-name "myarkserviceprincipal" --query '[0].appId' -o tsv`

Récupérer les sources

Dans mon cas, la dernière version disponible est la v1.6.2, et j’ai besoin des la version linux amd64

mkdir velero && cd velero
wget https://github.com/vmware-tanzu/velero/releases/download/v1.6.2/velero-v1.6.2-linux-amd64.tar.gz
tar -xzf velero-v1.6.2-linux-amd64.tar.gz

Créer un namespace et un service provider (différents de ceux par défaut)

Quelque soit le cloud provider, il faut modifier le fichier config/common/00-prereqs.yaml

Comme indiqué dans la documentation dédiée, ce fichier contient la plupart des informations génériques, notamment, les définitions (CRD pour les backups/restores Ark), le namespace, le service account et les rôles (RBAC).

Dans notre cas, on doit donc modifier le fichier config/common/00-prereqs.yaml pour qu’il créé un autre namespace, qu’on appellera « backup » pour faire original;
On va aussi modifier le nom du service account pour qu’il colle à celui du Service Principal azure (pas obligatoire, mais c’est pour rester cohérent) et surtout son namespace.

vi config/common/00-prereqs.yaml
[...]
---
apiVersion: v1
kind: Namespace
metadata:
name: backup
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: myarkserviceprincipal
namespace: backup
labels:
component: ark
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: ark
labels:
component: ark
subjects:
- kind: ServiceAccount
namespace: backup
name: myarkserviceprincipal
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io

Ensuite, il faut également modifier les spécifiques à notre cloud provider (ici Azure), en particulier le namespace, mais aussi nos informations de connexion à notre blob

Dans le déploiement, changer le namespace et le serviceAccountName

vi config/azure/00-ark-deployment.yaml
---
apiVersion: apps/v1beta1
kind: Deployment
metadata:
namespace: backup
name: ark
[...]
spec:
restartPolicy: Always
serviceAccountName: myarkserviceprincipal
[...]

vi config/azure/05-ark-backupstoragelocation.yaml
---
apiVersion: ark.heptio.com/v1
kind: BackupStorageLocation
metadata:
name: default
namespace: backup
spec:
provider: azure
objectStorage:
bucket: arkblob
config:
resourceGroup: arkbackups
storageAccount: arkANDTHEUUID
vi config/azure/06-ark-volumesnapshotlocation.yaml
---
apiVersion: ark.heptio.com/v1
kind: VolumeSnapshotLocation
metadata:
name: azure-default
namespace: backup
spec:
provider: azure
config:
apiTimeout: 30s
resourceGroup: ark-EUW-sandbox-RG

Créer les objets sur le cluster Kubernetes sur Azure

kubectl --context=myawesomeakscluster apply -f config/common/00-prereqs.yaml
customresourcedefinition.apiextensions.k8s.io/backups.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/schedules.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/restores.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/downloadrequests.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/deletebackuprequests.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/podvolumebackups.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/podvolumerestores.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/resticrepositories.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/backupstoragelocations.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/volumesnapshotlocations.ark.heptio.com created
namespace/backup created
serviceaccount/arkeuwsandboxsp created
clusterrolebinding.rbac.authorization.k8s.io/ark created
kubectl --context=myawesomeakscluster apply -f config/azure/
deployment.apps/ark created
backupstoragelocation.ark.heptio.com/default created
volumesnapshotlocation.ark.heptio.com/azure-default created
daemonset.apps/restic created

A noter : avant le premier appel de ark, sur chaque machine, il faudra spécifier dans quel namespace est ark sur notre cluster K8s.

./ark client config set namespace=backup

Créer le secret du service provider

#AZURE_RESOURCE_GROUP=MC_myownkubernetescluster_myawesomeakscluster_westeurope
AZURE_SUBSCRIPTION_ID=d717105a-ac1d-457c-8ef8-7467aa90df5c
AZURE_TENANT_ID=15eb2494-5298-4347-81a3-e2d3c08a0f82
AZURE_CLIENT_ID=f44ae340-97a2-4d54-bdc5-c4d7b2a49a2a
AZURE_CLIENT_SECRET=r+VGoBqOwraH9uVdk/sED3Ezdb7bIZI1xjvZyyvmnzM=
kubectl --context=myawesomeakscluster --namespace=backup create secret generic ark-azure-credentials \
--from-literal AZURE_SUBSCRIPTION_ID=${AZURE_SUBSCRIPTION_ID} \
--from-literal AZURE_TENANT_ID=${AZURE_TENANT_ID} \
--from-literal AZURE_CLIENT_ID=${AZURE_CLIENT_ID} \
--from-literal AZURE_CLIENT_SECRET=${AZURE_CLIENT_SECRET} \
--from-literal AZURE_RESOURCE_GROUP=${AZURE_RESOURCE_GROUP}
secret/ark-azure-credentials created

Créer des données dans le cluster pour vérifier le fonctionnement

kubectl create ns testrestore
namespace/testrestore created
kubectl run pod ubuntu --image=ubuntu --namespace=testrestore
deployment.apps/pod created
kubectl --namespace=testrestore get all
NAME READY STATUS RESTARTS AGE
pod/pod-5945cc9b88-sq8c8 0/1 RunContainerError 1 14s
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
deployment.apps/pod 1 1 1 0 14s
NAME DESIRED CURRENT READY AGE
replicaset.apps/pod-5945cc9b88 1 1 0 14s

Créer une backup

./ark backup create $(date +"%Y%m%d-%H%M")
Backup request "20190109-1553" submitted successfully.
Run `ark backup describe 20190109-1553` or `ark backup logs 20190109-1553` for more details.
./ark backup describe 09-01-2019
Name: 09-01-2019
Namespace: backup
Labels:
Annotations:
Phase: New
Namespaces:
Included: *
Excluded:
Resources:
Included: *
Excluded:
Cluster-scoped: auto
Label selector:
Storage Location:
Snapshot PVs: auto
TTL: 720h0m0s
Hooks:
Backup Format Version: 0
Started: <n/a>
Completed: <n/a>
Expiration: 0001-01-01 00:00:00 +0000 UTC
Validation errors:
Persistent Volumes:

Restaurer une backup

kubectl --namespace=testrestore delete ns testrestore
namespace "testrestore" deleted
./ark backup get
NAME STATUS CREATED EXPIRES STORAGE LOCATION SELECTOR
20190109-1553 Completed 2019-01-02 14:30:17 +0100 CET 23d default
./ark restore create restore-01 --from-backup 20190109-1553
Restore request "restore-01" submitted successfully.
Run `ark restore describe restore-01` or `ark restore logs restore-01` for more details.

CIVO : du kubernetes managé à partir de 4$/mois, vraiment ?

Fri, 16 Jul 2021 07:00:00 +0000

Pendant la Kubecon EU 2021, un provider que je ne connaissais pas a mis le paquet pour s’assurer de la visibilité : CIVO. Et avec une promesse plus qu’alléchante : un Kubernetes managé basé sur k3s (que j’adore) et avec un tarif à partir de 4$/mois !

Chez les concurrents, on a rien sous les 15€ / mois (Scaleway), quand ce n’est pas 30 voire 80… De quoi piquer ma curiosité donc.

Un de plus ?

J’ai donc pris un compte d’essai proposé par l’entreprise aux participants de la Kubecon et j’ai créé un compte.

La première chose que j’ai testé, c’est l’interface (il y a aussi une CLI). Forcément, chez un pure player, c’est simple et efficace, on s’y retrouve et l’interface est léchée. On est loin du gloubiboulga visuel de chez Azure (cf mon test d’AKS). Après, c’est un minimum… c’est forcément plus simple quand on commence de zéro et qu’on a pas des centaines de produits ;-p.

On a un dashboard avec les opérations réalisées chronologiquement, un menu pour créer des clusters kube, un menu pour créer du compute et des LB « nus ». Rien de bien révolutionnaire, ça fait le job.

La partie « KubeQuest », c’est de la bête gamification (« Créez un cluster pour passer niveau 2!!! »), je ne m’y attarderai même pas.

Bon, on le créé ce cluster à 4$ ?

Bon, ne vous enflammez pas, l’offre « à partir de 4$/mois » ne sera pas utilisable en prod, pas de miracle. Mais c’est déjà un tour de force qu’ils arrivent à le proposer, notamment grâce à k3s.

Pas de surprise, le pricing des nodes est immédiatement affiché, et voilà à quoi ça ressemble :

Pour 4$ par mois, on vous propose un « cluster » d’un seul node, avec seulement 1 vCPU et 1 Go de RAM. Pas de quoi faire tourner grand chose d’autre que quelques containers nginx… Si ça jamais ça fonctionne ?! (on y reviendra)

Au delà, les prix sont similaires à ce que l’on trouve sur le marché « bon marché » (Scaleway notamment). Si on veut être un peu sérieux et comparer ce qui est comparable, on peut booter des machines avec 2vCPU et 4 Go de RAM à16$/mois l’unité (moins de ~13,5€ en ce moment).

Kubernetes easy to install

La plupart des offres managées de Kubernetes (si ce n’est toutes) viennent avec une certaine quantité de personnalisation préinstallée. Chez Azure, vous pouvez choisir parti 2 CNIs et le dashboard (ou pas). Chez Scaleway si c’est Calico qui est préinstallé ou pas.

Chez CIVO, ils ont poussé le concept beaucoup plus loin, en reprenant l’idée de Rancher ou d’Openshift du « marketplace ».

Avant de boostraper votre cluster, vous avez accès à tout un magasin d’applications (ni plus ni moins que des charts helm avec une icône pour cliquer dessus) et éventuellement une très petite personnalisation avec un dropdown menu (mais vraiment trivial, très peu de choix).

Et là, pour le coup en terme d’UX je trouve ça très très malin. En quelques clics, j’ai (dé)sélectionné les composants qui m’intéressent et ils ont été préinstallés pour moi avec mon cluster.

On peut même préinstaller des produits de sécurité, notamment Kyverno avec un ensemble de règles de sécurité préconfigurées.

Et c’est pas fini !

Pour ce qui est des composants d’infrastructure, je comprend l’incentive. Pour certains devs, l’infra c’est ch***t.

Mon cluster je le veux up and running sans perte de temps, sans pour autant que mes données soient à poil sur Internet

Mais comme tout ce qui « cache » la complexité du métier d’Ops (cf mon article « Au secours, le métier d’Ops va disparaître »), la difficulté n’est pas tant le déploiement que le « day 2 operations ». Et si vous voulez modifier un paramètre, vous êtes marrons.

Tout de même, préconfigurer cette partie dès le bootstrap du cluster est malin. Et ce qui est encore plus malin, c’est qu’ils ont open sourcé leur marketplace.

Qu’est ce qu’ils y gagnent, me direz vous ?

Et bien, s’il y a un nouveau « shiny composant » qui fait rêver tout le monde, vous pouvez aller faire une PR pour ajouter une tuile dans l’UI de CIVO. Comme ça vous bossez pour eux. Elle est pas belle la vie ? ;-p (je troll, mais je trouve ça cool, en vrai).

Et le cluster, il boote vite ?

C’est un peu la guéguerre entre Kubernetes managés à qui bootstrappera le control plane et les workers le plus vite. Azure met plus de 20 minutes. OVH bootstrappe le control plane en une minute mais met des plombes à sortir les VMs à cause de leur OpenStack. Exoscale fait le tout (control plane + workers) en moins de 2 minutes.

CIVO nous promet 90 secondes et c’était pas loin d’être vrai. Je ne dirai pas que c’est les plus rapides mais ils sont dans le top 3 de tous les kubes managés que j’ai pu tester, sans hésiter.

Une fois le cluster opérationnel, on vous propose évidemment de télécharger votre kubeconfig et roule ma poule

Mais qu’est ce qu’on peut faire tourner dans Kube avec 1 (ou 4) Go de RAM ?

Le souci avec ce genre de « petites machines », c’est que si vous n’avez pas OS et kubernetes optimisés, une part non négligeable de la VM ne sera pas utilisable pour vos workloads et vous n’aurez que (dans le pire des cas) 2 Go de libre.

Et c’est là toute la « malinerie » d’utiliser k3s plutôt qu’un k8s vanilla. k3s est spécialement pensé pour tourner sur des petites machines (en edge notamment). J’avais pu installer un master kubernetes sur un raspberry pi 1 (model B, 1 CPU ridicule et 512 Mo de RAM) tellement l’empreinte mémoire demandée est faible.

Associé à un magasin d’applications maison pré-tuné pour consommer peu (très petites requests pour fit les petites machines sans tout bloquer), on arrive avec des nodes quasiment sans overhead. Dans cet exemple, j’ai cliqué sur plusieurs composants (cert-manager, kyverno, ha-proxy, prometheus+alertmanager+grafana, metrics-server, falco). Je me retrouve avec des nodes (4vCPU 8Go) quasiment vides !

kubectl --kubeconfig civo-zwindler-kubeconfig top nodes
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
k3s-zwindler-deadbeef-node-pool-31af 230m 5% 945Mi 12%
k3s-zwindler-deadbeef-node-pool-6609 97m 2% 471Mi 6%
k3s-zwindler-deadbeef-node-pool-e07c 141m 3% 874Mi 11%

Du coup, pour du lab perso ou des workloads qui nécessitent très peu de puissance, l’offre de CIVO est plutôt bien positionnée. Je ne suis pas complètement convaincu de l’intérêt de l’offre extra small à 4$ qui est plus là pour la prouesse technique qu’une réelle utilisation. Mais dès small ou medium, on a un service qui fonctionne, moins cher que de nombreux concurrents et surtout bien plus optimisé en terme de ratio overhead/puissance totale.

Au delà de kubernetes, l’offre est quasiment inexistante. Des VMs (plus chères que les workers kubes !!! wtf) et des loadbalancer à 10$/mois (Scaleway le fait à 8€, on est dans les prix « pas cher ») et c’est tout…

Autant dire que c’est kubernetes ou rien. Du coup, est ce qu’il y a un marché pour ce besoin, je ne suis pas certain… mais pourquoi pas ? En tout cas, bonne surprise !

J’ai testé pour vous : l’offre Kubernetes as a service d’OVH

Tue, 09 Jul 2019 11:30:50 +0000

OVH sort son offre Kubernetes managée

Vous avez peut être vu passer l’actualité début février, OVH a lancé (comme d’autres cloud providers) son offre Kubernetes as a service (KaaS).

Cette blague hilarante vous est offerte par zwindler !

Comme beaucoup de techno non triviales, une offre managée, c’est un bon moyen de mettre le pied à l’étrier si vous ne connaissez pas encore Kubernetes. C’est aussi un bon moyen pour OVH pour ne pas trop se laisser distancer par les géants américains.

En avril dernier, j’ai pu participer à un meetup dans les locaux d’OVH et de rencontrer les personnes qui avaient mis en place cette technologie. Du coup, je vous propose un petit article dans lequel on va voir ensemble à quoi ça ressemble.

Côté tarif

C’est le nerf de la guerre. Comme tous les autres (à l’exception notable d’EKS d’Amazon), vous ne payez que pour les workers, pas pour les masters (le control plane donc). Niveau tarif pour les workers, c’est simple, ce sont les tarifs applicables sur l’offre cloud public d’OVH.

La plus petite machine que vous pouvez sélectionner est un machine Linux de type B2-7, avec 2 vCPUs, 7 Go de RAM et 50 Go de SSD local.

C’est suffisant pour faire des tests, mais en production on en voudra au minimum 3, ce qui à 22€HT/mois pièce vous fera quand même environ 75€ / mois.

Au final, on est objectivement moins cher que ce que j’avais pu tester sur AKS. Car pour rappel, j’avais monté un cluster de machines de type B2ms avec 2 vCPU et 8 Go de RAM pour 30€ / mois, donc identique. SAUF que ces machines sont des machines dites “burstable” (vous n’avez qu’une portion d’un vCPU, que vous ne pouvez dépasser que pour une durée réduite avant de subir un throttling). Des machines équivalentes reviendraient sur Azure à utiliser des D2, pour un tarif de 83€TTC / mois… par machine !!!

Le fait que le control plane (les masters) ne soient pas payant est à la fois un avantage et un inconvénient. Pour OVH, je n’ai pas encore la réponse, mais lorsque j’avais testé AKS d’Azure, j’avais demandé au commercial ce qui se passait si mon control plane était HS (vu que c’est eux qui gèrent, je ne peux pas prendre la main pour le fixer). Il m’avait répondu texto : “comme c’est un produit gratuit, on ne s’engage sur aucune SLA (seulement un SLO de 2h)”. De quoi refroidir quand on est habitué à avoir la main sur son cluster Kubernetes.

Et si on testait ?

Assez parlé ! Dans mon manager d’OVH, j’ai créé un nouveau projet, que j’ai nommé de manière originale “Kubernetes Project”. Puis, j’ai créé un cluster Kubernetes en cliquant sur “Créer un cluster Kubernetes”

Actuellement, seul le DC “Graveline 5” semble capable d’accueillir l’offre KaaS d’OVH. Un point qu’il faudra améliorer dans le futur pour pouvoir se construire une infrastructure réellement résiliente.

Edit: Une deuxième région sera disponible dans le mois (cf Maxime Hurtrel, PM K8s chez OVH)

Niveau version de Kubernetes, bonne nouvelle, OVH s’est donné les moyens de proposer des versions très à jour de Kubernetes. Toutes les versions depuis la 1.11 jusqu’à la version 1.14 sont disponibles. La 1.14, qui n’a que quelques mois, est devenue dispo chez OVH assez rapidement. On peut imaginer que la 1.15 de Kubernetes qui vient tout juste de sortir (mi juin) sera probablement assez vite disponible aussi.

A titre de comparaison, chez Azure, ils sont assez bons dans ce domaine, et pourtant ils n’ont la 1.14 qu’en preview. Le mauvais élève Amazon est à la traîne avec seulement la 1.12 (pourtant sortie en septembre 2018).

“Ca va trop vite”

Cette partie là est relativement impressionnante. La création d’un nouveau cluster est extrêmement rapide.

Au total, l’instanciation d’un cluster met moins d’une minute, là où AKS en nécessite une 20aine (en comptant les workers certes, mais bon la moitié du temps le portal ou l’appel à l’API plante !).

Ceci est du à la façon dont le control plane a été créé et conçu par les équipes d’OVH (j’y reviendrais juste après) et est clairement une réussite. Pour avoir déployé à la main Kubernetes un paquet de fois et avec de nombreuses méthodes différentes (cf mes divers articles sur le sujet), c’est la méthode la plus rapide d’installer Kubernetes, et de loin.

L’architecture du control plane

Un des trucs sympas avec OVH, c’est qu’ils n’hésitent pas à communiquer sur les détails techniques. Certes, ils ne sont pas les seuls, mais c’est toujours agréables.

Lors du CNCF Meetup, Kevin Georges, Pierre Peronnet et Sébastien Jardin nous ont donc présenté les entrailles de leur Kubernetes as a service.

L’idée principale est que le control plane doit être le plus léger possible, pour coûter le moins cher possible à OVH (vu que c’est gratuit), tout en restant résilient.

La solution qui a été retenue pour arriver à une solution acceptable a été de déployer les services nécessaires au control plane de Kubernetes (control malanger, api server, scheduler) dans … un Kubernetes ! La seule brique non containerisée est etcd, et il s’agit ici d’un cluster dédié sur des machines physiques (ce qui explique probablement la limitation au DC Graveline).

Dans tous les cas, ça explique probablement aussi la vitesse de démarrage d’un nouveau cluster : il faut juste lancer 3 containers et zou, un nouveau cluster.

Source : OVH https://www.ovh.com/fr/blog/kubinception-using-kubernetes-to-run-kubernetes/

L’article technique détaillant tout ça est dispo sur le site d’OVH, je n’en dis pas plus, ils l’expliquent mieux que moi.

Les workers

Pour la partie Workers, plutôt que de développer sa propre API et l’intégrer comme module du projet Kubernetes (comme les autres gros cloud providers, qui ont leur code embarqué dans celui de Kubernetes), la team chez OVH en charge du projet s’est appuyée sur de l’existant : leurs propres services OpenStack fournissent déjà l’ensemble des briques dont ils ont besoin pour créer des VMs à la volées et les intégrer à des clusters Kubernetes.

Quand j’ai demandé au Meetup combien de temps il fallait pour “poper” un nouveau worker, un des trois speakers m’a dit, tout désolé “on ne fait pas de miracles, il faut quelques minutes”. Il n’a pas compris le pauvre quand j’ai éclaté de rire (parce que sur Azure, ça prend des plombes).

Ajouter des workers

La procédure est assez simple, mais se fait au travers de l’interface (comme la création du cluster). Je suis quasiment certain que tout doit pouvoir se piloter par API (je vois mal pourquoi ils auraient fait autrement pour un service tout neuf), pour autant, je n’en ai pas trouvé de trace dans la documentation officielle (pas à jour avec la nouvelle interface et encore un peu light)

Bon, alors je suis peut être mal tombé, mais quand j’ai cliqué dans l’interface pour ajouter des nodes, ça a quand même pris énormément de temps (facile 20-30 minutes). Du coup j’étais un peu (très) déçu…

Après investigation, en fait… c’est l’interface qui déconne ! En réalité, mon nœud était UP depuis longtemps déjà.

Je m’en suis rendu compte en faisant un petit kubectl get nodes et j’ai vu que mon node “Ready” depuis 28 minutes était encore marqué “En cours d’installation” …

kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
vm1.12-1 Ready <none> 28m v1.12.7 51.77.204.236 <none> Container Linux by CoreOS 2135.4.0 (Rhyolite) 4.19.50-coreos-r1 docker://18.6.3

Se connecter au cluster

D’ailleurs, comment on s’y connecte ? Pas de souci de ce côté, OVH vous simplifie la vie en vous proposant de télécharger directement votre fichier kubeconfig préconfiguré, prêt à utiliser.

Si vous en avez plusieurs, pour rappel, vous pouvez utiliser le flag “–kubeconfig=kubeconfig.yml”

En vrai, un node ne met que 3 minutes à poper

Du coup, j’ai voulu retester le démarrage d’une nouvelle VM, en sachant que le temps indiqué sur l’interface web n’est pas bon.

Après quelques tests, en 3 minutes, le node apparait en “Not Ready”, puis passe “Ready” au bout de quelques secondes. On est donc très proche de ce dont j’avais pu parler avec les gens d’OVH du coup, c’est très bon comme temps de boot.

Ouf, on est rassurés !

Mise à jour

Un point sympa que permettent les solutions de type KaaS est la gestion des mises à jour depuis votre interface de gestion. Mettre à jour Kubernetes, c’est pénible. La moitié du temps, on a peur de tout casser.

Alors je ne dis pas que rien ne va casser avec le Kubernetes d’OVH, mais comme l’infra est cadrée et gérée par eux, j’imagine que c’est suffisamment bien testé dans des conditions similaires aux vôtres pour être un peu plus serein le jour où ça arrive.

A noter, contrairement à AKS, vous n’avez que peu la main sur les mises à jour. Cela se limite à ça, et je n’ai pas trouver comment monter de la 1.12 à la 1.13 par exemple…

Edit: Toujours selon Maxime Hurtrel, ça devrait arriver bientôt

Conclusion : au delà du compute, l’UI

Dans les points qui déchirent : OVH sait fournir un control plane à une vitesse à faire pâlir d’envie tous les concurrents.

Cependant, cela se fait sur un cluster Kubernetes mono DC (DC5 Graveline), avec la partie etcd externalisée à part, sur un cluster mutualisé. Je ne fais pas de jugement de valeur car, contrairement à OVH qui est transparent, je n’ai pas d’info technique sur les versions proposées par la concurrence.

En revanche, je peux comparer avec un cluster que j’installe moi même, et là clairement, je suis un cran en dessous en terme de ce qui peut être fait en terme de sécurisation de mon cluster.

Pour ce qui est de l’interface, elle souffre un peu de sa jeunesse. Il n’y a rien de plus que les onglets pour créer un cluster et pour ajouter ou supprimer des nœuds (et encore, pas plus d’info sur ces nœuds que leur nom et leur taille !).

Un dernier onglet existe pour “visualiser” ses containers et ses services, mais il est pour l’instant vide et sera de toute façon probablement moins utile que le dashboard ou tout autre outil existant (sauf à fournir un énorme effort de dev sur ce point).

Encore un exemple de la jeunesse de la solution et particulièrement de son interface : OVH pope des VMs (workers) très vite, ce qui devrait être super cool et soulever les foules… mais si on teste la solution rapidement, comme l’interface ne l’indique pas, on pourrait penser que ce n’est pas le cas ! Dommage !

Edit: Le problème est connu et en cours de fix

[Le tweet n’est plus disponible]

Et pour ce qui est des mises à jour, c’est le flou total. On vous explique que tout est maintenu à jour, mais les montées de versions majeurs sur un cluster ne semble pas disponible pour l’instant.

Dans les points pas glop : aucune trace dans la doc d’API pour créer des clusters à la volée ou les gérer de manière automatisée via Ansible ou autre…

Edit: l’API est là

[Le tweet n’est plus disponible]

Bref, vous l’aurez compris, techniquement c’est une réussite. Chez OVH, ils savent gérer des VMs et des containers et ça se voit. Mais l’offre KaaS d’OVH manque peut être encore d’un petit coup de polish pour qu’on se sente bien chez soi, et pleinement en confiance. Et c’est d’autant plus rageant que la solution a plein de bons points, que le travail abattu (en peu de temps) est colossal.

Je voudrais donc tenter de terminer sur une note positive, car c’est mon ressenti au global. Pour avoir rencontré des membres de l’équipes (de vrais passionnés), j’ai envie de croire que ce produit est amené à grandir, et ses petits défauts de jeunesse à disparaître.

A suivre donc !

Bonus GPU

Dans les petits “trucs” qui m’ont fait sourire, j’ai vu passer un tweet indiquant qu’OVH se lançait également (en alpha par contre pour l’instant) dans Kubernetes managé avec des instances baremetal avec GPU.

Je n’ai pas forcément de workload en tête, mais pour ceux qui veulent lancer des containers avec des calculs GPU, c’est une option qui peut faire sens.

Si vous voulez en savoir plus, c’est par ici :

Labs OVH GPU baremetal k8s nodes

J’ai testé pour vous AKS, la plateforme Kubernetes managée d’Azure

Tue, 18 Dec 2018 12:45:33 +0000

AKS = Azure Kubernetes Service

Après EKS (Amazon) et GKE (Google) (et plein d’autres en fait), Azure a fini par lancer aussi son service managé de Kubernetes (preview en octobre 2017).

Ce service ne doit pas être confondu avec ACI (Azure Container Instances) qui est le service d’Azure CaaS, où vous pouvez instancier les containers à la demande sur les Kubernetes d’Azure, où Kubernetes vous est complètement caché.

Vous verrez aussi peut être dans la littérature des références à ACS (l’ancien nom d’AKS) ou alors de ACS-engine, qui est le projet utilisé par Azure pour déployer des clusters Kubernetes (sur du IaaS) pour leur besoins propres et qu’ils ont open sourcé.

Il s’agit donc bien d’un service fourni par Azure, qui masque toute la complexité du déploiement des machines et des composants de Kubernetes. Vous n’aurez pas accès aux VMs, on n’est donc pas sur du IaaS. Mais contrairement à ACI, vous aurez les pleins pouvoir sur le control plane de Kubernetes, et vous pourrez l’administrer comme bon vous semble.

C’est vraiment facile à installer ?

Oui, c’est vraiment simple. L’installation peut se faire depuis le portail ou en quelques commandes « az cli »

Pour tout vous dire, Microsoft a même pousser le vice jusqu’à faciliter l’installation du binaire kubectl, ainsi que la configuration de votre cluster dans les contextes (via des commandes « az cli »). Dans l’absolu, les commandes qu’on va faire ci dessous sont équivalentes à celles que j’ai décrites dans l’article Installer kubectl et Configurer kubectl.

Nice to have

C’est parti !!

Depuis le portail, cherchez « Kubernetes services », puis cliquez sur « Add ».

Et si vous préférez comme moi le faire en lignes de commande, ça donne quelque chose comme ça :

az group create --name myownkubernetescluster --location westeurope --subscription "mysubscription"
az aks create --resource-group myownkubernetescluster --name myawesomeclsuter --node-count 3 --enable-addons monitoring --node-vm-size Standard_B2s --kubernetes-version 1.10.9 --ssh-key-value ~/.ssh/mypublicsshkey.pub --subscription "mysubscription"

Si vous l’avez fait depuis le portail, vous verrez également une popup sur la droite pour vous aider à configurer kubectl (mais vous pouvez aussi les utiliser si vous avez monté le cluster avec les commandes précédentes aussi).

Les commandes à lancer après avoir déployé le cluster sont les suivantes :

az aks install-cli
Downloading client to /usr/local/bin/kubectl from https://storage.googleapis.com/kubernetes-release/release/v1.12.0/bin/linux/amd64/kubectl
Please ensure that /usr/local/bin is in your search PATH, so the `kubectl` command can be found.

Si vous essayez de les lancer sans avoir fait votre az login, vous aurez l’erreur suivante

az aks get-credentials --resource-group myownkubernetescluster --name myawesomeclsuter
Resource group 'test_AKS' could not be found.

On se logue, donc

az login
Note, we have launched a browser for you to login. For old experience with device code, use "az login --use-device-code"

Comme l’indique la commande, az cli à récemment changé de méthode d’authentification par défaut.

Si vous lancez ces commandes et que vous n’avez pas d’environnement graphique (dans une petite VM par exemple), vous pouvez toujours utiliser l’ancienne méthode avec un code à recopier dans une page web avec la commande suivante :

az login --use-device-code
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code TOTOTOTOTO to authenticate.

Dans mon cas, j’ai accès à un abonnement Visual Studio en plus de mes souscriptions habituelles.

Par défaut, cette souscription est filtrée, donc az cli continuera à ne pas « voir » le ressource group que j’aurai créé pour l’occasion. L’idéal est de l’indiquer explicitement en ajoutant un « –subscription ». Une autre solution, plus simple, pour éviter le problème est de positionner cette souscription comme « par défaut »

az account set --subscription "Visual Studio"

Maintenant ça devrait marcher. On récupère les crédentials et les informations du contexte.

Par défaut, az cli va merger ces informations avec votre .kube/config existant s’il existe. Si vous avez peur qu’il fasse des bêtises, pensez à le sauvegarder avant.

az aks get-credentials --resource-group myownkubernetescluster --name myawesomeclsuter
/root/.kube/config has permissions "644".
It should be readable and writable only by its owner.
Merged "testaksdge" as current context in /root/.kube/config

Maintenant que l’outil az cli a configuré notre contexte pour nous, on peut interagir avec le cluster normalement :

kubectl get nodes
NAME STATUS ROLES AGE VERSION
aks-nodepool1-36034183-0 Ready agent 26m v1.10.9
aks-nodepool1-36034183-1 Ready agent 26m v1.10.9
aks-nodepool1-36034183-2 Ready agent 26m v1.10.9

Lancer le « proxy » (pour afficher le dashboard et accéder à l’API)

az aks browse --resource-group myownkubernetescluster --name myawesomeclsuter
[...]
Proxy running on http://127.0.0.1:8001/
Press CTRL+C to close the tunnel...
[...]

Etape supplémentaire si vous avez activé le RBAC

Si vous avez activé le RBAC, ce que je vous conseille fortement et qui devrait être le choix par défaut, votre dashboard n’aura pratiquement accès à rien !

Il faut lui ajouter des droits sur le cluster. La procédure complète d’Azure vous indique la marche à suivre ici. Ce que eux conseillent, qui est effectivement le plus simple (mais pas le plus sage), est de donner les droits cluster-admin au service account kubernetes-dashboard…

kubectl create clusterrolebinding kubernetes-dashboard --clusterrole=cluster-admin --serviceaccount=kube-system:kubernetes-dashboard

Mais attention aux conséquences ! De très nombreuses personnes laissent le dashboard ouvert sur Internet et si EN PLUS votre dashboard est admin du cluster, vous allez rapidement miner des cryptocurrencies et lancer des mails de SPAM à votre insu…

N’autorisez donc pas le portail depuis l’extérieur.

Et après ?

Dans le cycle de vie d’un cluster Kubernetes, deux tâches vont très vite vous intéresser. Sauvegarder vos objets (ce qu’on peut faire avec Ark de Heptio) et mettre à jour votre cluster (ce qu’on peut faire avec AKS).

Ces deux points seront le focus d’articles futurs ;-)