Architecte de vos plateformes/produits et agitateur de séries temporelles

Conception, développement, déploiement et exploitation de vos plateformes, applications et données.

Contactez-nous !
Accueil >

Kubernetes @ OVH - Traefik en DaemonSets

kubernetes traefik ovh daemonset

Sortant de la formation Déployer ses applications avec Kubernetes animée par Jérome Petazzoni - slides - j’ai voulu mettre en oeuvre différents enseignements. OVH proposant un service kubernetes managé en version beta basé sur une infrastructure Openstack, j’en ai profité pour jouer un peu avec.

En parcourant la documentation disponible et le canal gitter, on note que :

  • La version de kubernetes est la version 1.11.3
  • Les services de type Load Balancer ne sont pas encore supportés - cela devrait arriver prochainement
  • Il faut en attendant passer par un NodePort pour accéder aux applications.

J’ai voulu donc voir comment déployer Traefik sur mon cluster qui ne contient qu’une seule node pour me facilier la gestion des volumes. En effet, la classe de stockage “cinder” ne supporte pas un accès depuis plusieurs nodes (ReadOnlyMany ou mieux ReadWriteMany) mais seulement depuis une node (ReadWriteOnce).

C’est donc clairement sous-optimal comme configuration mais ça permet de se faire la main à un prix raisonnable et sans trop se casser la tête. Dans le cadre d’un vrai déploiement, il faudrait trouver une solution de stockage plus intéressante pour les données de traefik (en l’occurence les certificats).

L’idée est donc de déployer Traefik sous la forme d’un DaemonSet et de mapper les ports 80/443 de chaque node du cluster.

Pour se faire, Traefik founi un exemple de DaemonSet que j’ai largement repris.

Commençons par traefik/rbac.yml - le fichier défini le compte de service (Service Account), le rôle au niveau du cluster (Cluster Role) et la liaison entre le rôle et le compte de service (Cluster Role Binding)

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: traefik-ingress-controller
  namespace: kube-system
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: traefik-ingress-controller
rules:
  - apiGroups:
      - ""
    resources:
      - services
      - endpoints
      - secrets
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - extensions
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: traefik-ingress-controller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: traefik-ingress-controller
subjects:
- kind: ServiceAccount
  name: traefik-ingress-controller
  namespace: kube-system

Ensuite, pour Traefik, j’ai besoin d’un fichier traefik.toml avec la configuration que je mets à disposition sous la forme d’une ConfigMap dans un fichier traefik/traefik-toml-configmap.yml :

apiVersion: v1
kind: ConfigMap
metadata:
  name: traefik-conf
  namespace: kube-system
data:
  traefik.toml: |
    defaultEntryPoints = ["http", "https"]

    insecureSkipVerify = true

    [entryPoints]
      [entryPoints.http]
        address = ":80"
        [entryPoints.http.redirect]
          entryPoint = "https"
      [entryPoints.https]
        address = ":443"
        [entryPoints.https.tls]
      [entryPoints.api]
        address = ":8080"

    [acme]
    email = "contact@cerenit.fr"
    storage = "/acme/acme.json"
    entryPoint = "https"
    onHostRule = true
    [acme.httpChallenge]
      entryPoint = "http"

    [api]
    entryPoint = "api"
    dashboard = true
    debug = false

Le dashboard est à protéger par une authentification pour éviter tout accès non souhaité. Je l’ai supprimé de la configuration par simplicité.

Ensuite, pour stocker mes certificats, il me faut un volume que je défini via le fichier traefik/traefik-certificates-pvc.yml :

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: traefik-certificates
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 1Gi
  storageClassName: cinder-classic

1 Go pour des certificats, c’est clairement trop mais il n’est pas possible pour le moment d’avoir un stockage plus réduit.

Je peux donc enfin déployer Traefik via le fichier traefik/traefik-ds.yml :

---
kind: DaemonSet
apiVersion: extensions/v1beta1
metadata:
  name: traefik-ingress-controller
  namespace: kube-system
  labels:
    k8s-app: traefik-ingress-lb
spec:
  template:
    metadata:
      labels:
        k8s-app: traefik-ingress-lb
        name: traefik-ingress-lb
    spec:
      hostNetwork: true
      serviceAccountName: traefik-ingress-controller
      terminationGracePeriodSeconds: 60
      containers:
      - image: traefik
        name: traefik-ingress-lb
        volumeMounts:
        - mountPath: /config
          name: traefik-config
        - mountPath: /acme
          name: certificates
        ports:
        - name: http
          containerPort: 80
          hostPort: 80
        - name: https
          containerPort: 443
          hostPort: 443
        - name: admin
          containerPort: 8080
          hostPort: 8080
        securityContext:
          capabilities:
            drop:
            - ALL
            add:
            - NET_BIND_SERVICE
        args:
        - --kubernetes
        - --logLevel=INFO
        - --configfile=/config/traefik.toml
      volumes:
        - name: traefik-config
          configMap:
            name: traefik-conf
        - name: certificates
          persistentVolumeClaim:
            claimName: traefik-certificates
---
kind: Service
apiVersion: v1
metadata:
  name: traefik-ingress-service
  namespace: kube-system
spec:
  selector:
    k8s-app: traefik-ingress-lb
  ports:
    - protocol: TCP
      port: 80
      name: web
    - protocol: TCP
      port: 8080
      name: admin
    - protocol: TCP
      port: 443
      name: https

Nous déployons donc :

  • Traefik en DaemonSet
  • Les ports 80, 443 et 8080 sont ouverts au niveau de l’hôte
  • La configuration est une ConfigMap
  • Les certificats sont à déployer dans un volume

A partir de ce moment là, vous avez accès au dashboard via http://<node ip>:8080/

Pour améliorer un peu les choses, nous pouvons vouloir donner accès au dashboard via une url et sécurisé par un certificat Let’s Encrypt.

Pour se faire, il faut déclarer un Ingress, dans le fichier traefik/traefik-api-ingress.yml :

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: traefik-web-ui
  namespace: kube-system
spec:
  rules:
  - host: traefik.k8s.cerenit.fr
    http:
      paths:
      - path: /
        backend:
          serviceName: traefik-ingress-service
          servicePort: admin

Il ne nous reste plus qu’à faire :

kubectl create -f traefik/
ingress.extensions/traefik-web-ui created
persistentvolumeclaim/traefik-certificates created
daemonset.extensions/traefik-ingress-controller created
service/traefik-ingress-service created
serviceaccount/traefik-ingress-controller created
clusterrole.rbac.authorization.k8s.io/traefik-ingress-controller created
clusterrolebinding.rbac.authorization.k8s.io/traefik-ingress-controller created

Dès lors, vous pouvez accéder au dashboard de Traefik via l’url définie.

Nous arrivons au bout de ce tutoriel permettant de jouer rapidement avec Traefik sous la forme d’un DaemonSet. Le contenu est criticable et améliorable par bien des aspects :

  • Il faudrait ne pas exposer le port 8080 de Traefik au niveu de la node et n’y accéder que via le service,
  • Le stockage des certificats est à améliorer dans un contexte multi-nodes
  • …

N’hésitez pas à me faire part de vos retours.

Web, Ops & Data - Décembre 2018

python grafana aws confluence licence opensource traefik windows openssh cloud etcd cncf vault hashicorp test kubernetes load-balancer metallb chrome edge

Cloud

  • AWS Re:Invent 2018 : Difficle de passer à coté des annonces d’AWS - AWS re:Invent 2018 - Jour 1, AWS re:Invent 2018 - Jour 2, AWS re:Invent - Jour 3, AWS re:Invent - Jour 4 : le résumé des sorties de la conférence AWS re:Invent 2018 par le cabinet Ippon.
  • #9 - Quentin Adam - Horacio Gonzales - Steven Le-Roux - La guerre du cloud : dans cet épisoide du podcast databuzzword, il est question de guerre du cloud, du multi-cloud, d’AWS et de ses “partenariats” et du cloud chinois et russe.
  • Episode 63 : “Re-Invent le Cloud” : L’épisode 63 de BigDataHebdo s’intéresse aussi aux annonces de la conférence d’AWS et discute aussi d’AWS et du monde de l’opensource.
  • License Changes for Confluent Platform : la sortie de l’offre Kafka managé n’a pas plus à Confluent. A l’instar de Redis et MongoDB, c’est au tour de Confluent d’adopter une licence plus restrictive pour les fournisseurs de cloud dans le cadre de la distribution de sa platforme Confluent. La licence de Kafka est inchangé, cela concerne l’API Rest, la Schema REgistry, KSQL et des connecteurs confluent.
  • Copyleft and community licenses are not without merit, but they are a dead end : Paul Dix, le CTO D’InfluxData donne son avis sur les changements de licences en cours. Un point intéressant est que ce changement de license vers des licences de type “Community” va surtout pénaliser les développeurs en créant une incertitude autour du mode de collaboration/contribution et peuvent aussi chercher à créer un monopole pour les services SasS créés par l’éditeur du produit. Oui il est dommage qu’AWS par ex ne contribue pas à Kafka/Confluent dans le cadre de son offre managée, mais par la même occasion Confluent se crée un monopole de fait sur l’offre SaaS autour de KSQL. Est-ce vraiment mieux ? En ce sens, Paul préfère alors soit du tout open ou tout fermé - mais que la solution du milieu n’est pas si idéale que ça (surtout pour des couches basses des produits sur lequel nous sommes censés bâtir quelque chose).
  • We need Sustainable Free and Open Source Communities : Pour finir sur une note plus optimiste, l’auteur cherche à renverser la conversation en regardant comment créer des communautés soutenables et faire en sorte que la licence permette de soutenir la communauté. Pas sur que les libristes les plus convaincus n’y voient pas une atteinte aux libertés du logiciel justement : “Any commercial activity around the software must further the sustainability of the community, and the potential for commercial benefit must be available to all. The incentives in any commercial model must bend away from the creation of proprietary downstream software”

Container et orchestration

  • Introducing Traefik Enterprise Edition : le reverse proxy Traefik voit apparaitre une version Entreprise qui se veut plus distribuée avec l’apparition d’un “data plane” qui gère les connexions et joue le rôle de reverse proxy et un “control plane” qui coordonne le bon fonctionnement des noeuds.
  • CNCF to Host etcd : la base clé/valeur distribuée etcd et qui sert notamment de datastore pour kubernetes va être hébergé par la CNCF. Elle fut développée initiallement par CoreOS, désormais propriété de Red Hat (et donc IBM).
  • [Podcast] PodCTL – Kube Security, Kube 1.13 and KubeCon :
  • MetalLB : MetalLB propose de fournir un service de type load balancer prévu pour cluster Kubernetes dans un contexte bare metal (ie non cloud).
  • MetalLB, with David Anderson : Episode du Kubernetes Podcast sur MetalLB avec son auteur pour une présentation de la solution.

Dataviz

  • Grafana v5.4 Released : une version de consolidation avec des améliorations sur la temporisation des alertes avant de l’émettre. D’autres améliorations sur l’intégration Google Stackdriver, l’éditeur de requêtes MySQL et des améliorations sur les panels et des préférences d’équipes.

Langages

Il ne me reste plus qu’à vous souhaiter de bonnes fêtes de fin d’année et à vous retrouver l’année prochaine pour de nouvelles aventures.

Méthodologie

  • Infliger de l’aide : Quand une personne demande de l’aide et qu’on n’y met pas d’empathie, on peut alors lui infliger de l’aide - Je pense que je vais reprendre ce concept et l’appliquer.

Sécurité

Tests

Web

Windows

Web, Ops & Data - Aout 2018

docker kubernetes cassandra reaper istio service-mesh cloud opensource redis kafka mysql postgres confluent openmetrics prometheus fluxlang influxdb timescaledb

Cloud & Open Source

Container et orchestration

(Big) Data & (No)SQL

  • Reaper 1.2 Released : l’outil de gestion des “réparations” des données d’un keyspace Cassandra, initialement réalisé par Spotify et désormais maintenu par The Last Pickle, vient de sortir en version 1.2 avec son lot d’améliorations. Pour un client, il a été déployé, ce qui me permet de pouvoir contribuer modestement (#472, #473, #474)
  • Re-Bootstrapping Without Bootstrapping : que faire lorsqu’un noeud d’un cluster Cassandra est sorti depuis plus longtemps que le temps de grace défini ? Le billet répond à la question pour ne pas repartir de zéro et le faire de façon “marginale”.
  • Introducing Confluent Platform 5.0 : à l’occasion de la sortie d’Apache Kafka 2.0, une nouvelle version de la plateforme Confluent sort également avec les dernières nouveautés de KSQL, des améliorations coté stabilité/sécurité (Auth LDAP, Disaster Recovery, etc). Allez lire les notes pour en savoir plus et voir ce qui relève de la version 0SS et de la version Entreprise.
  • Showdown: MySQL 8 vs PostgreSQL 10 – Hacker Noon : l’article confirme qu’avec MySQL 8.0, MySQL rattraperait Postgres au niveau des grandes fonctionnalités de base.

DevOps

  • The Site Reliability Workbook : Google sort un complément à son livre “Site Reliability Engineering”. Le livre est sensé donner des conseils pratiques ou partager des eemples issus de la réalité dans le cadre de la mise en place d’une démarche SRE.

Timeseries

  • Querying Prometheus with Flux (video - slides) : Paul Dix, CTO d’InfluxData, montre comment il est possible de requêter des données issues de Prometheus via Flux, le nouveau langage qu’InfluxData est en train de créer et dont l’objectif est de pouvoir manipuler des données temporelles. Ce cas permet de montrer l’utilisation de Flux dans un contexte autre qu’InfluxDB.
  • CNCF to Host OpenMetrics in the Sandbox : OpenMetrics est une initiative de standardisation des formats de métriques - le projet rentre donc dans l’initiative de la CNCF.
  • OpenMetrics to Join the CNCF ; Paul Dix a annoncé le support de ce format comme “citoyen de première classe” pour une version ultérieure d’InfluxDB. Le billet fait l’état des lieux du support au niveau de Telegrad et de Kapacitor.
  • Prometheus Graduates Within CNCF : toujours coté CNCF, Prometheus, la plateforme de métriques, est le second projet (après Kubernetes) à passer au niveau officiel.
  • TimescaleDB vs. InfluxDB: purpose built differently for time-series data : Comparaison par les gens de TimescaleDB entre leur produit TimescaleDB et InfluxDB. Même s"il est forcément un peu biaisé, il reste intéressant.

Web, Ops & Data - Juillet 2018

grafana kubernetes service-mesh ansible brigade helm draft sql devops architecture microservice flux tick influxdb docker chronograf fluxlang

Architecture

  • Goodbye Microservices: From 100s of problem children to 1 superstar : L’article fait pas mal de “bruit” en ce moment mais je ne suis pas sur qu’ils arrivent à la bonne conclusion au final ; Partir de microservices et multiples dépots gits pour revenir à un monolithe/mono dépot git, j’ai l’impression que la réponse au travers des outils n’adresse pas le problème de fond à savoir la gouvernance de l’ensemble. En effet, si les versions différaient tant que cela, l’approche centralisé a peut être mis un terme en forçant tout le monde à se rencentrer sur une version donnée mais s’il n’y a pas de règles, le résultat sera le même prochainement mais ils auront moins de liberté.
  • Miniservices as a Realistic Alternative to Microservices : du coup, pour réduire les frictions, certains proposent de faire des micro-services plus gros avec le risque d’arriver à plein de moyens monolites…
  • Je mets donc pour rappel cet article que j’ai déjà mentionné : Enough with the microservices. Il rappelle que c’est surtout la modularité et une architecture propre du code qui donne de la flexibilité. Et puis tout le monde n’a ni le contexte, ni la maturité pour se lancer dans les micro-services.

Automatisation

  • Ansible 2.6: Your Time Has Come! : une version de consolidation avec des améliorations coté cloud et surtout sur l’utilisation de la mémoire lordque l’on utilise les “Dynamic Includes”.

Container et Orchestration

  • Blog: Kubernetes 1.11: In-Cluster Load Balancing and CoreDNS Plugin Graduate to General Availability : Kubernetes continue son travail de consolidation et de stabilisation.
  • Service Mesh: Promise or Peril? : si les service mesh peuvent paraitre attrayant, leur intégration n’est pas forcément évidente et il faut aussi prévoir cette couche intermédiaire dans le développement de votre application. Leur utilisation n’est donc pas toujours recommmandée/souhaitable - l’article propose de faire le point sur le sujet.
  • Container Native Development with Ralph Squillace : cet épisode de podcast petmet d’avoir une présentation d’Helm (package manager), Bridage (gestion de workflow kubernetes) et Draft (aide à la conteneurisation d’une app). D’autres outils sont mentionnés en fin d’épisode pour agrémenter son quotidien (extension vscode, etc).
  • Extending Support Cycle for Docker Community Edition : A l’occasion de la sortie de Docker CE 18.06, quelques ajustements : les versions stables sortiront tous les 6 mois maintenant (et plus tous les 3 mois) et avec une période de maintenance de 7 mois, le canal edge (monthly release) est arrêté au profit d’un canal nightly, docker for Windows/Mac gardent une release mensuelle (pour le canal edge), plus de packaging par distribution pour mieux coller à l’actualité de la distribution.

Dataviz

DevOps

  • Une décennie DevOps, quels enseignements tirer ? : synthèse globale et assez factuelle sur 10 ans de DevOps qui a le mérite de signaler les points où ce n’est pas encore ça. Courage, la transformation/l’adoption est en cours malgré tout.

(No)SQL

Timeseries

Web, Ops & Data - Juin 2018

mysql redis kubernetes aws terraform cdc debezium kafka azure elasticsearch ksql kapacitor docker docker-compose docker-app buildkit hashicorp consul service-mesh istio

Big Data, Machine Learning & co

Cloud

Container & Orchestration

  • Making Compose Easier to Use with Application Packages : Docker Inc. sort un nouveau produit appelé “docker-app”. Il se veut comme une surcouche à docker-compose en permettant d’injecter des variables dans vos fichiers docker-compose.yml. Ainsi, vous n’auriez plus qu’un seul fichier docker-compose avec ses variables et les valeurs de ses variables dans des fichiers additionnels. Lors de l’exécution du container, docker-app réconcilie les deux et lance le conteneur avec les bonnes valeurs. Docker Swarm et Kubernetes seraient supportés si l’on en croit les exemples. Rigolo, sur le principe, c’est exactement ce que je fais pour une mission actuellement…
  • Découverte de Buildkit : dans le cadre du découpage de Docker en programme modulaire indépendant, Moby avait lancé Buildkit. Il s’agit du builder d’images. L’article présente son fonctionnement et son architecture.
  • HashiCorp Consul 1.2: Service Mesh : Hashicorp sort en beta son offre de service mesh basé sur Consul. Après le “Service Discovery” et le “Service Configuration”, voilà le Service Mesh. A voir dans la vraie vie mais on retrouve apparemment pas mal de fonctionnalités disponibles dans Istio.

(No)SQL

  • Vitess : J’en avais entendu parler, j’ai profité d’un épisode de Software Engineering Daily pour en savoir un petit peu plus : Je ne suis pas encore au bout du podcast mais cela semble être une couche entre l’application et la DB - elle analyse la requête et la distribue ensuite au sein du cluster. Vitess permettrait notamment que le développeur n’ait pas à connaitre la logique de clustering/sharding des données. L’overhead n’a pas encore été mentionné.
  • Redis 5.0 RC1 : la version 5.0 de Redis pointe le bout de son nez avec notamment le type de donnée Stream - cf Introduction to redis streams
  • Streaming Data out of the Monolith: Building a Highly Reliable CDC Stack : un CDC, Change Data Capture, est un système qui capture les changements de données (INSERT, UPDATE, DELETE) d’une source de données. BlaBlaCar explique ici comment ils ont mis en place leur CDC sur la base de Debezium et Kafka. Un des défis à relever étant la gestion de la déduplication des données.
  • Elasticsearch 6.3.0 Released : plein de nouveautés mais la plus symoblique étant un début de support d’un requêtage SQL dans Elasticsearch.

Sécurité

  • Attacking Private Networks from the Internet with DNS Rebinding : TL;DR Following the wrong link could allow remote attackers to control your WiFi router, Google Home, Roku, Sonos speakers, home thermostats and more. il est donc possible d’abuser un navigateur via un DNS malicieux et donc être en mesure de scanner le réseau local de la personne abusée. Il faut donc considérer le réseau local comme une zone hostile et y appliquer les bonnes pratiques habituelles (authentification, urls en https, etc)

Timeseries

Astuce(s) du mois

Faîtes-vous plaisir et écouter le podcast Artisan Développeur - dans des formats de 10mn environ, un sujet autour de l’agilité, des tests, du TDD, de la responsabilité des développeurs, de SaFE, et de tout ce qui fait partie de notre quotidien de développeurs sont abordés. Depuis quelques épisodes, cela se fait en duo avec d’autres personnes (comme JP Lambert) ce qui rend les échanges encore plus intéressants. Vous retrouvez le podcast sur Soundcloud, Pocketcasts, etc.