Lors de la première partie, nous avons évoqué la complexité de choisir une charte Helm, pour mettre en place un cluster Elasticsearch sur kubernetes. Dans cette 2ème partie, nous allons aller encore plus loin et nous aventurer dans les périples des opérateurs.
Les opérateurs sont une nouvelle approche pour la gestion et le déploiement d’une application sur kubernetes. Ils ont été introduit par CoreOS pour étendre l’API kubernetes. Les opérateurs sont utilisés principalement pour l’abstraction d’un concept ou l’automatisation de tâches d’administration ou des tâches de gestion de cycle de vie. Parmi les premiers opérateurs, on trouve l’operateur d’un cluster ETCD et l’operateur de mise en place de Prometheus.
L’opérateur d’Elastic.io
Elastic.io a annoncé le début d’un nouveau chapitre de son histoire avec le cloud native et kubernetes.
Nous avons des promesses audacieuses dès le départ :
- La gestion et la supervision de cluster ES multiple
- La gestion de mise à jour des versions ES avec simplicité
- La scalabilité des clusters ES (plus grand mais également plus petit cluster)
- La gestion de la configuration des clusters ES
- La gestion dynamique des volumes et du stockage (en locale)
La première version Béta de l’opérateur voit le jour il y a peu de temps et nous promet plus de maturité :
- Le retour vers une implémentation à base de StatefulSet (vous pouvez consulter nos remarques dans la première partie)
- Optimisation de la mise à jour des clusters ES avec un volume considérable de données.
- Nouvelle version de l’API (de l’opérateur)
Demo
Assez de théorie, testons le nouvel opérateur d’Elastic
Setup
Afin de s’approcher au plus prêt des conditions réelle de la production, nous allons opter pour un cluster sur le cloud. Nous allons utiliser eksctl, un outil créé par weave.works et validé par AWS comme l’outil ligne de commande privilégié pour créer des cluster EKS.
Donc la simple commande eksctl create cluster, avec les permissions AWS qui vont bien, donne la création d’un cluster comme dans cet exemple :
Bloc de code :
[ℹ] using region us-west-2
[ℹ] setting availability zones to [us-west-2a us-west-2c us-west-2b]
[ℹ] subnets for us-west-2a - public:192.168.0.0/19 private:192.168.96.0/19
[ℹ] subnets for us-west-2c - public:192.168.32.0/19 private:192.168.128.0/19
[ℹ] subnets for us-west-2b - public:192.168.64.0/19 private:192.168.160.0/19
[ℹ] nodegroup "ng-98b3b83a" will use "ami-05ecac759c81e0b0c"
[AmazonLinux2/1.11]
[ℹ] creating EKS cluster "floral-unicorn-1540567338" in "us-west-2" region
[ℹ] will create 2 separate CloudFormation stacks for cluster itself and the
initial nodegroup
[ℹ] if you encounter any issues, check CloudFormation console or try 'eksctl
utils describe-stacks --region=us-west-2 --name=floral-unicorn-1540567338'
[ℹ] 2 sequential tasks: { create cluster control plane
"floral-unicorn-1540567338", create nodegroup "ng-98b3b83a" }
[ℹ] building cluster stack "eksctl-floral-unicorn-1540567338-cluster"
[ℹ] deploying stack "eksctl-floral-unicorn-1540567338-cluster"
[ℹ] building nodegroup stack
"eksctl-floral-unicorn-1540567338-nodegroup-ng-98b3b83a"
[ℹ] --nodes-min=2 was set automatically for nodegroup ng-98b3b83a
[ℹ] --nodes-max=2 was set automatically for nodegroup ng-98b3b83a
[ℹ] deploying stack "eksctl-floral-unicorn-1540567338-nodegroup-ng-98b3b83a"
[✔] all EKS cluster resource for "floral-unicorn-1540567338" had been created
[✔] saved kubeconfig as "~/.kube/config"
[ℹ] adding role
"arn:aws:iam::376248598259:role/eksctl-ridiculous-sculpture-15547-NodeInstanceRole-1F3IHNVD03Z74"
to auth ConfigMap
[ℹ] nodegroup "ng-98b3b83a" has 1 node(s)
[ℹ] node "ip-192-168-64-220.us-west-2.compute.internal" is not ready
[ℹ] waiting for at least 2 node(s) to become ready in "ng-98b3b83a"
[ℹ] nodegroup "ng-98b3b83a" has 2 node(s)
[ℹ] node "ip-192-168-64-220.us-west-2.compute.internal" is ready
[ℹ] node "ip-192-168-8-135.us-west-2.compute.internal" is ready
[ℹ] kubectl command should work with "~/.kube/config", try 'kubectl get nodes'
[✔] EKS cluster "floral-unicorn-1540567338" in "us-west-2" region is ready
Si nous voulons affiner davantage le cluster, nous pouvons passer la configuration sous forme de fichier yaml:
Bloc de code :
eksctl create cluster -f cluster.yaml
Bloc de code :
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: basic-cluster
region: eu-north-1
nodeGroups:
- name: ng-1
instanceType: m5.large
desiredCapacity: 10
- name: ng-2
instanceType: m5.xlarge
desiredCapacity: 2
Pour plus d’information, vous pouvez consulter le site de l’outil https://eksctl.io/
Installation de l’opérateur
Nous suivrons [le guide d’installation] (https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-quickstart.html) les Versions Supportées sont: Kubernetes: 1.11+ et Elasticsearch: 6.8+, 7.1+. Nous commençons par l’installation des CRD
Pour les versions de kuberntes en 1.13 et postérieures :
Bloc de code :
kubectl apply -f https://download.elastic.co/downloads/eck/1.0.0-beta1/all-in-one.yaml
Pour les versions 1.12 et inférieures:
Bloc de code :
kubectl apply -f https://download.elastic.co/downloads/eck/1.0.0-beta1/all-in-one-no-vali...
Nous pouvons suivre l’état d’avancement de la mise en place de l’opérateur par :
Bloc de code :
kubectl -n elastic-system get statefulset.apps/elastic-operator
Pour voir les logs:
Bloc de code :
kubectl -n elastic-system logs -f statefulset.apps/elastic-operator
Création d’un cluster Elasticsearch
Une fois que nous avons créé l’opérateur, créons notre cluster ElasticSearch :
Bloc de code :
cat <Tester le Cluster Elasticsearch
Puisque nous avons une nouvelle ressource, voyons le status donné par kubernetes pour notre nouveau cluster :
Bloc de code :
kubectl get elasticsearch
NAME HEALTH NODES VERSION PHASE AGE
quickstart green 1 7.4.1 Ready 1m
Accès au cluster Elasticsearch
Lors de la création de cluster elasticsearch, l’opérateur a rajouté un service Kubernetes pour y accéder :
Bloc de code :
kubectl get service quickstart-es-http
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
quickstart-es-http ClusterIP 10.15.251.145 9200/TCP 3m
Mais connaitre l’adresse d’accès n’est pas suffisant puisque l’opérateur met en place quelques bonnes pratiques, comme la mise en place de l’authentification et l’utilisation du protocole HTTPS.
L’opérateur a créé l’utilisateur elastic, nous allons récupérer le mot de passe confiné dans un secret kubernetes :
Bloc de code :
PASSWORD=$(kubectl get secret quickstart-es-elastic-user -o=jsonpath='{.data.elastic}' | base64 --decode)
Pour tester la connexion au cluster ES :
Bloc de code :
kubectl port-forward service/quickstart-es-http 9200 &
curl -u "elastic:$PASSWORD" -k "https://localhost:9200"
Conclusion
Dans cet article nous avons présenté l’opérateur ECK (Elasticsaerch Cloud Kubernetes) qui apporte une abstraction de la couche kubernetes et une facilité de manipulation et gestion du cycle de vie de plusieurs cluster Elasticsearch sur kubernetes. Nous avons présenté une demo qui montre les premières manipulations d’un cluster elasticsearch crée avec l’opérateur. Pour plus d’information comme la gestion des certificats ou la création d’une entité Kibana, nous proposons de consultat la documentation d’Elastic.io.