Guide d’initié sur Splunk pour les conteneurs et Kubernetes

Nos images de conteneurs Splunk Enterprise et Universal Forwarder sur DockerHub sont extraites plusieurs millions de fois par mois. En octobre, nous avons répondu à cette popularité en commençant à prendre en charge les déploiements de Splunk sur une instance unique en conteneurs. Depuis, de nombreux clients ont exprimé le désir d’en savoir plus sur nos réflexions et nos projets dans le domaine des conteneurs, et en particulier l’exécution de Splunk sur Kubernetes.

Nos expériences respectives ont permis d’identifier un certain nombre de détails et de complexités supplémentaires associés à l’exécution de Splunk sur Kubernetes, notamment en termes de sécurité, de stockage persistant, de haute disponibilité et de performances. Ces facteurs sont centraux dans nos réflexions concernant notre orientation future, et ils devront faire l’objet d’une grande attention des clients qui poursuivent leurs propres déploiements.

Sécurité des conteneurs

En tant que fournisseur de logiciels, les conteneurs créent des défis uniques. L’un d’entre eux est la responsabilité supplémentaire qu’il fait peser sur la sécurité. Jusqu’à présent, le code que nous livrions s’interfaçait avec tout le code délivré par les fournisseurs de systèmes d’exploitation. Une ligne claire délimitait la surface d’attaque qu’il nous appartenait de protéger (notre propre code et les bibliothèques que nous y avons intégrées) de celle qui était à la charge des fournisseurs de systèmes d’exploitation (tout le reste). Maintenant que les conteneurs regroupent le code de l’application et du système d’exploitation, cette ligne commence à se déplacer. Pour la première fois, nous devons nous inquiéter des vulnérabilités résidant dans des projets externes comme glibc et bash.

Aujourd’hui, personne ne remettrait en question l’importance exceptionnelle de la sécurité, mais honnêtement, nous n’étions pas prêts à voir cette frontière se déplacer. Nous avons commencé par utiliser Debian pour nos images de conteneur de base et nous étions habitués à nous concentrer uniquement sur la sécurité de « nos » octets. J’utilise régulièrement un éventail de distributions Linux et je les apprécie pour différentes raisons, mais Red Hat excelle clairement en matière de sécurité.

Nous nous en sommes particulièrement rendu compte lorsque nous avons ajouté des inspections de sécurité aux pipelines CICD de nos conteneurs et que nous avons commencé à expérimenter avec différentes images de base. Nos conteneurs bâtis sur les images Debian les plus récentes et les meilleures ont toujours révélé des vulnérabilités non corrigées, tandis que les conteneurs reposant sur CentOS (une variante populaire de Red Hat) étaient presque toujours irréprochables. Il n’y a pas vraiment de quoi être surpris : les frais d’abonnement à Red Hat Enterprise Linux (RHEL) vous donnent droit (entre autres) à une réaction rapide en cas de découverte de vulnérabilité. Pour illustrer ce point, voici les résultats d’inspections récentes réalisées sur nos images Splunk Enterprise 7.2.6 :

• Debian 9 (stretch-slim) : 12 alertes élevées, 33 moyennes, 19 faibles, 46 négligeables, 2 inconnues
• Debian 10 (buster-slim) : 1 alerte élevée, 8 moyennes, 4 faibles, 36 négligeables, 1 inconnue
• Red Hat 8 (ubi-minimal) : 0, rien, nada !  
   

Le problème que nous avions auparavant avec les images de conteneur de Red Hat était que leur licence limitait la redistribution et l’utilisation limitée aux seules machines hôtes RHEL. Bien qu’un grand nombre de clients de Splunk soient également des clients RHEL, beaucoup d’autres ne le sont pas. Cela ne laissait que peu de possibilités, insatisfaisantes de surcroît :

• renoncer à la certification Red Hat et tenter de corriger les vulnérabilités du système d’exploitation (et c’est ce que nous faisions par défaut) ;
• publier et prendre en charge deux images, tout en corrigeant nous-mêmes les vulnérabilités du système d’exploitation (cela aurait nécessité plus de ressources que nous n’en avions).
   

Images de base universelles de Red Hat

Je suis depuis longtemps utilisateur et fan de Red Hat (et de divers cousins RPM) depuis que j’ai commencé à exploiter les versions pré-entreprise dans les années 90. Hier, lors du Red Hat Summit à Boston, mes amis de Fedora ont résolu le problème de la sécurité des conteneurs avec le lancement des Universal Base Images (UBI), ou images de base universelles. Elles intègrent les derniers correctifs de sécurité qui font la réputation de Red Hat, et sont publiées sous une licence plus permissive qui leur permet de s’exécuter sur n’importe quel système d’exploitation hôte (même si nous recommandons toujours d’utiliser RHEL).

Suite à cela, j’ai le plaisir d’annoncer la sortie bêta des nouvelles images de conteneur Splunk Enterprise et Universal Forwarder bâties sur Red Hat. Vous pouvez les télécharger dès maintenant depuis DockerHub en ajoutant « -redhat » à nos balises d’image. Par exemple :

docker pull splunk/splunk:redhat

docker pull splunk/splunk:7.2.6-redhat

docker pull splunk/universalforwarder:redhat

docker pull splunk/universalforwarder:7.2.6-redhat

À l’avenir, nous prévoyons de remplacer nos images basées sur Debian et de faire de Red Hat notre distribution par défaut. Ce changement devrait être tout à fait transparent pour nos clients. Nous travaillons également avec Red Hat pour certifier ces images et espérons les publier prochainement dans le catalogue de conteneurs Red Hat.

Splunk et Kubernetes

Je suis ravi de voir que de plus en plus de nos clients souhaitent exécuter Splunk sur Kubernetes. Nous sommes convaincus que Kubernetes est incroyablement puissant et important, et nous entrevoyons un avenir dans lequel il contribue à simplifier considérablement le déploiement, la supervision et l’administration de Splunk.

Actuellement, nous ne prenons en charge que les déploiements à instance unique de Splunk sur Kubernetes. Bien que certains experts aient réussi à exécuter des déploiements en cluster, de nombreux obstacles rendent cette approche difficile pour le moment. Par nature, Splunk est très dynamique, alors que Kubernetes a été construit initialement pour les microservices sans état. Kubernetes ressemble beaucoup plus à un kit de développement cloud, il offre une flexibilité immense, beaucoup d’accessoires et des kilomètres de corde pour se pendre.

Nous avons précédemment publié un ensemble de modèles YAML utilisables aussi bien pour des déploiements à instance unique que des déploiements en cluster de Splunk sur Kubernetes. Nous avons également expérimenté quelques projets en interne qui pourraient un jour aider à faire de Splunk et Kubernetes les meilleurs amis. J’en parle plus bas pour vous mettre l’eau à la bouche, mais sachez que nous ne les publierons peut-être jamais pour le grand public. Si vous rejoignez les fans de Red Hat à Boston cette semaine, retrouvez l’équipe de Splunk sur le stand 314 pour une démonstration.

Opérateurs Kubernetes

Les modèles YAML deviennent rapidement assez complexes dès que l’on sort du domaine des applications les plus basiques. Ils sont parfaits pour les microservices simples, mais beaucoup moins pour les applications complexes comme Splunk. L’introduction des ressources personnalisées a considérablement ouvert le champ des possibles pour Kubernetes, et elle permet aux développeurs d’aller au-delà des types d’objet intégrés et de créer les leurs. Les ressources personnalisées servent souvent à créer des concepts de niveau supérieur qui combinent plusieurs éléments, pour s’abstraire de la complexité sous-jacente. Si vous êtes programmeur, vous pouvez les voir comme un objet qui fournit une interface plus simple en cachant beaucoup d’autres objets sous son capot. L’opérateur va encore plus loin : c’est un service permanent exécuté dans Kubernetes qui écoute les modifications apportées à un ensemble de ressources personnalisées.

Imaginez qu’un déploiement de Splunk puisse être exprimé sous la forme d’un seul objet SplunkEnterprise. Tout ce qu’un client peut vouloir configurer serait déclaré dans les spécifications de cet objet (ou dans un ConfigMap correspondant). Les clients n’auraient pas à se soucier de Pods, de StatefulSets, de PersistentVolumes ou autres, parce que l’opérateur gérerait toutes ces informations à leur place.

Les opérateurs se distinguent particulièrement des autres approches de packaging d’applications (telles que Service Bundles et les graphiques Helm) destinées aux opérations de jour 2. Les opérateurs peuvent être utilisés pour gérer en toute transparence des volumes de données, les mises à niveau, les redimensionnements, des tâches de maintenance courantes, etc. Les applications avec état comme Splunk nécessitent l’exécution de nombreux processus dans un ordre spécifique. En tant que fournisseur de logiciels, nous pouvons exploiter les opérateurs pour automatiser toutes les bonnes pratiques de gestion de nos produits via le code, plutôt que de demander à du personnel d’exécuter manuellement des procédures. Je pense que cela facilitera considérablement le déploiement, la supervision et la gestion de Splunk pour nos clients.

L’opérateur Splunk

Si vous avez un instant pour passer au stand Splunk au Red Hat Summit cette semaine, pensez à demander la démonstration d’un prototype d’opérateur que nous avons développé en interne. Pour déployer une instance unique de Splunk, il vous suffit d’exécuter une simple commande kubectl apply sur un modèle similaire à ceci :

apiVersion: enterprise.splunk.com/v1alpha1

kind: SplunkEnterprise

metadata:

  name: single

spec:

  config:

    splunkPassword: helloworld456

    splunkStartArgs: --accept-license

  topology:

    standalones: 1

Ceci crée automatiquement des PersistentVolumeClaims (PVCs) et les monte dans /splunk/etc et /splunk/var, de cette façon, si votre serveur meurt et que Kubernetes déplace le pod ailleurs, toutes vos données se déplacent avec lui.

$ kubectl apply -f singleinstance.yml

splunkenterprise.enterprise.splunk.com/single created

$ kubectl get pods

NAME                                        READY STATUS RESTARTS AGE

splunk-operator-79cfbd8746-bgv7f            1/1 Running 0 5d1h

splunk-standalone-single-5f865d6646-h2mpz   1/1 Running 0 44s

$ kubectl get pvc

NAME                               STATUS VOLUME                 CAPACITY ACCESS MODES STORAGECLASS AGE

pvc-etc-splunk-standalone-single   Bound pvc-cfdbeac0-6f9d-11e9-92ac-0acd14da47d0   1Gi RWO gp2 53s

pvc-var-splunk-standalone-single   Bound pvc-cfdce5eb-6f9d-11e9-92ac-0acd14da47d0   50Gi RWO gp2 53

Pas mal, hein ? Et que diriez-vous d’un cluster :

apiVersion: enterprise.splunk.com/v1alpha1

kind: SplunkEnterprise

metadata:

  name: example

spec:

  config:

    splunkPassword: helloworld456

    splunkStartArgs: --accept-license

  topology:

    indexers: 3

    searchHeads: 3

Vous pouvez créer un cluster en quelques minutes tout simplement en changeant les paramètres de topologie. Toutes les étapes manuelles normalement requises pour configurer la mise en cluster des search heads, celle des indexeurs, leur jonction, et plus encore, sont traitées par l’opérateur.

$ kubectl apply -f cluster.yml

splunkenterprise.enterprise.splunk.com/example created

$ kubectl get pods

NAME                                             READY STATUS RESTARTS AGE

splunk-cluster-master-example-59666cd544-6dpfc   1/1 Running 0 4m24s

splunk-deployer-example-69bf676c7d-pgxp9         1/1 Running 0 4m24s

splunk-indexer-example-0                         1/1 Running 0 4m24s

splunk-indexer-example-1                         1/1 Running 0 3m46s

splunk-indexer-example-2                         1/1 Running 0 2m13s

splunk-license-master-example-59db6c48ff-2vqrf   1/1 Running 0 4m24s

splunk-operator-79cfbd8746-bgv7f                 1/1 Running 0 5d1h

splunk-search-head-example-0                     1/1 Running 0 4m24s

splunk-search-head-example-1                     1/1 Running 0 3m45s

splunk-search-head-example-2                     1/1 Running 0 2m9s

Par défaut, cette option utilise notre image splunk/splunk:latest. Vous pouvez utiliser nos nouvelles images Red Hat UBI à la place, en ajoutant un paramètre splunkImage aux spécifications. Que se passe-t-il si vous définissez splunk/splunk:7.2.6-redhat et que vous souhaitez effectuer une mise à niveau vers la version 7.3.0 après sa sortie ? Il vous suffit de changer splunkImage en splunk/splunk:7.3.0-redhat et de relancer kubectl apply. La mise à niveau se fera, même si votre topologie couvre des centaines, voire des milliers de serveurs.

Au-delà des volumes distants 

Vous vous demandez peut-être d’où viennent ces PersistentVolumes magiques ? Normalement, il faudrait un cluster Kubernetes intégrant une configuration StorageClass par défaut qui monte les volumes distants sur votre réseau (volumes EBS, montages NFS, etc.). Cela fonctionne très bien si c’est ce que vous avez, et si vous avez assez de capacité dans votre couche de stockage pour gérer la demande Splunk. Mais Splunk est généralement utilisé pour gérer des big data : autrement dit, un volume très important et une très grande vitesse. Nos plus grands clients gèrent des pétaoctets de données générés chaque jour. À l’échelle des big data, votre couche de stockage peut rapidement devenir un goulot d’étranglement.

La dernière version de Kubernetes 1.14 a introduit les Persistent Local Volumes, ou volumes locaux persistants, comme fonctionnalité GA. Cela vous permet d’utiliser des disques locaux connectés à vos serveurs pour stocker des données Splunk. C’est extrêmement rapide, peut-être aussi rapide que l’exécution de Splunk sur un serveur « bare metal ». C’est super jusqu’à ce que l’un de vos serveurs meure. Les volumes locaux persistants sont liés à un serveur spécifique. Par conséquent, si vous perdez le serveur, vous perdez toutes les données qui y sont stockées. La bonne nouvelle, c’est que vous pouvez utiliser la fonction de réplication de Splunk pour vous protéger contre la perte de données, au moins ce n’est pas pire que ce que vous pouvez avoir aujourd’hui, sans Kubernetes.

Stockage de nouvelle génération

On dispose d’un nombre croissant d’options pour obtenir un stockage persistant dans Kubernetes. On peut par exemple réunir les disques locaux attachés à vos serveurs Kubernetes en un maillage de stockage virtuel, exposé en tant que StorageClass qui soutient vos PersistentVolumes. L’un des produits les plus prometteurs avec lesquels nous avons travaillé récemment est Robin Storage.

Les PersistentVolumes créés à l’aide de Robin répliquent automatiquement les blocs sur plusieurs disques de votre cluster. Si un serveur tombe en panne, Kubernetes redémarre automatiquement vos pods ailleurs, et tous les volumes qu’ils utilisent se déplacent avec eux, sans perte de données. Contrairement aux volumes distants et aux magasins d’objets, vos données restent à l’intérieur de votre cluster, aussi près que possible de votre puissance de calcul. Cela peut réduire les goulets d’étranglement en raccourcissant le chemin réseau. Cela évite également de dépendre de services de stockage externes, ce qui peut être particulièrement intéressant pour les déploiements locaux de Splunk.

Robin Storage peut chiffrer et compresser vos volumes, créer des aperçus et des clones sans copie, sauvegarder et restaurer l’état de clusters entiers. Il déplace vos données à proximité des pods qui y accèdent fréquemment, ce qui peut avoir des avantages significatifs en matière de performance. Selon les développeurs, les performances ne se distinguent de celles d’un serveur bare metal que de 5 à 10 %.

Le déploiement de Robin est facile parce qu’il se présente sous une forme packagée d’opérateur : exécutez une commande kubectl apply... et c’est à peu près tout. Bien sûr, vous devez disposer de disques bruts pour l’utiliser, et vous aurez beaucoup de paramètres supplémentaires à ajuster par la suite. Notre prototype d’opérateur Splunk vous permet de sélectionner la classe de stockage à utiliser via un paramètre storageClassName. Nous avons pu mettre en service un cluster Splunk à l’aide de Robin Storage sur Red Hat OpenShift en quelques minutes, simplement en ajoutant cela à nos exemples YAML présentés ci-dessus.

$ kubectl get pvc

NAME                                    STATUS VOLUME            CAPACITY ACCESS MODES STORAGECLASS AGE

pvc-etc-splunk-cluster-master-example   Bound pvc-51d9dbba-6f9e-11e9-92ac-0acd14da47d0   1Gi RWO robin 4m41s

pvc-etc-splunk-deployer-example         Bound pvc-51e12b99-6f9e-11e9-92ac-0acd14da47d0   1Gi RWO robin 4m41s

pvc-etc-splunk-indexer-example-0        Bound pvc-51eae60e-6f9e-11e9-913c-026cfa37367a   1Gi RWO robin 4m41s

pvc-etc-splunk-indexer-example-1        Bound pvc-69048c78-6f9e-11e9-913c-026cfa37367a   1Gi RWO robin 4m3s

pvc-etc-splunk-indexer-example-2        Bound pvc-a04342fa-6f9e-11e9-913c-026cfa37367a   1Gi RWO robin 2m30s

pvc-etc-splunk-license-master-example   Bound pvc-51d39a4b-6f9e-11e9-92ac-0acd14da47d0   1Gi RWO robin 4m42s

pvc-etc-splunk-search-head-example-0    Bound pvc-51f1f858-6f9e-11e9-913c-026cfa37367a   1Gi RWO robin 4m41s

pvc-etc-splunk-search-head-example-1    Bound pvc-69937886-6f9e-11e9-913c-026cfa37367a   1Gi RWO robin 4m2s

pvc-etc-splunk-search-head-example-2    Bound pvc-a2b86a7a-6f9e-11e9-913c-026cfa37367a   1Gi RWO robin 2m26s

pvc-var-splunk-cluster-master-example   Bound pvc-51db8a61-6f9e-11e9-92ac-0acd14da47d0   50Gi RWO robin 4m41s

pvc-var-splunk-deployer-example         Bound pvc-51e33300-6f9e-11e9-92ac-0acd14da47d0   50Gi RWO robin 4m41s

pvc-var-splunk-indexer-example-0        Bound pvc-51e909ae-6f9e-11e9-913c-026cfa37367a   200Gi RWO robin 4m41s

pvc-var-splunk-indexer-example-1        Bound pvc-6905b8a3-6f9e-11e9-913c-026cfa37367a   200Gi RWO robin 4m3s

pvc-var-splunk-indexer-example-2        Bound pvc-a0445066-6f9e-11e9-913c-026cfa37367a   200Gi RWO robin 2m30s

pvc-var-splunk-license-master-example   Bound pvc-51d47106-6f9e-11e9-92ac-0acd14da47d0   50Gi RWO robin 4m42s

pvc-var-splunk-search-head-example-0    Bound pvc-51f0df75-6f9e-11e9-913c-026cfa37367a   50Gi RWO robin 4m41s

pvc-var-splunk-search-head-example-1    Bound pvc-699475b7-6f9e-11e9-913c-026cfa37367a   50Gi RWO robin 4m2s

pvc-var-splunk-search-head-example-2    Bound pvc-a2b99b41-6f9e-11e9-913c-026cfa37367a   50Gi RWO robin 2m26s

La voie à suivre 

Nous nous attachons à offrir une expérience professionnelle en nous associant à notre écosystème pour proposer des services de pointe et permettre des gains d’agilité et de coût dans un monde multicloud. Nous faisons notre possible pour que notre opérateur Splunk passe du stade de prototype à celui de produit, et nous expérimentons toujours pour trouver ce qui fonctionne le mieux. Si vous souhaitez apprendre et développer avec nous, envoyez-moi un tweet ou un message sur LinkedIn ! Nous apprécions toujours les éclairages des clients et nous sommes toujours ravis de pouvoir essayer de nouvelles choses dans des environnements réels. Une chose semble certaine : Kubernetes est là pour longtemps, et l’avenir nous réserve d’innombrables choses passionnantes.

_{*Cet article est une traduction de celui initialement publié sur le blog Splunk anglais.}