CérénIT

Le blog tech de Nicolas Steinmetz (Time Series, IoT, Web, Ops, Data)

Web, Ops & Data - Décembre 2019

18/12/2019 influxdb docker kubernetes traefik grafana dashboard cassandra reaper warp10 timeseries timescaledb helm machine-learning

Rendez-vous le 21 janvier prochain à la troisième édition du Paris Time Series Meetup consacré à TSL (billet introductif à TSL : TSL: a developer-friendly Time Series query language for all our metrics) et le module RedisTimeSeries qui apporte des fonctionnalités et des structures Time Seriies à Redis. Le meetup était prévu initialement le mardi 17 décembre mais a été reporté du fait des grèves.

Container et orchestration

DockerSlim : le projet vise à réduire la taille de vos images et à améliorer leur sécurité en procédant à différentes optimisations. Cela peut être intéressant dans une stratégie d’améliorations de vos images docker mais à tester néanmoins. Les exemples données partent d’Ubuntu 14.04 dont l’image fait 60 / 65 Mo alors que l’image Ubuntu 16.04 fait moitié moins et Alpine fait 30 fois moins. Donc certains gains semblent faciles à obtenir, à creuser plus en détail.
Kubernetes 1.17: Stability : après une version 1.16 marquée notamment par la dépréciation de certaines APIs, cette version se veut plus une consolidation autour des “Cloud Provider Labels” qui passent en GA, le snapshot de volumes qui passe en beta, ainsi que la couche de stockage CSI avec la poursuite de la migration des plugins “in-tree” vs “out-of-tree”. La fin de cette migration est prévue pour les versions 1.19 / 1.20 et le retrait complet des plugins “in-tree” pour les versions 1.21 / 1.22.
A visual guide on troubleshooting Kubernetes deployments : un guide du troublehooting des déploiements sous kubernetes avec un joli diagramme des cas possibles et les explications associées en repartant d’un exemple simple.
How to migrate from Helm v2 to Helm v3 : les opérations à mener pour migrer de Helm V2 à Helm V3.
Traefik 2.1 : le provider Consul Catalog fait son retour (il était absent en 2.0.x) et diverses améliorations sur la CRD Kubernetes ont été apportées pour mieux gérer le mirroring du traffic, les déploiements canary et la gestion des sessions. La migration ne consistant pas seulement à changer le numéro de version et suite à une remarque de ma part, une note a été ajoutée pour la migration 2.0.x vers 2.1.x

Dataviz

Pro Tips: Dashboard Navigation Using Links : améliorer vos dashboards Grafana avec des liens à différents niveaux dans l’interface pour pointer vers des ressources utiles.

NoSQL

Cassandra Reaper 2.0 was released : la solution de réparation de vos clusters Cassandra passe en 2.0 ; elle apporte un déploiement en mode sidecar (reaper est lancé dans la même jvm que Cassandra), le support d’Apache Cassandra 4.0 (pas encore officiellement disponible), de nouveaux thèmes, une amélioration du support de Postgresql comme backend de déploiement et pleins d’autres choses.

Time Series

Release Announcement: InfluxDB 2.0.0 Alpha 21 : Cette version alpha apporte notamment le début de la transpilation des requêtes InfluxQL en Flux. C’est peut être un des plus gros enjeux pour la migration entre la version 1.x et 2.x d’InfluxDB et la gestion de l’écosystème associé.
Warp 10™ release 2.3.0 : la plateforme Warp10 continue son chemin avec une fonctionnalité intéressante permettant de mieux définir les points que l’on veut récupérer pour une requête donnée (nombre de points, échantillonage, points du début et de fin, etc)
Motion Split : Présentation d’une autre fonctionnalité intéressante de Warp10 2.3.0 si vous suivez des objets qui se déplacent et que vous voulez définir des groupes de points en fonction d’un délai, d’une distance, d’arrêts.
New: Helm Charts for deploying TimescaleDB on Kubernetes : pour ceux qui utilisent TimescaleDB, des charts helm sont à votre disposition pour déployer une instance, avec gestion de la réplication des données.
Time series features extraction using Fourier and Wavelet transforms on ECG data : Application de la théorie des signaux sur des séries temporelles dans le cadre d’analyse d’électrocardiogramme. Cela complète les articles du mois précédent.

Je n’ai plus qu’à vous souhaiter des bonnes fêtes de fin d’année ; nous nous retrouvons l’année prochaine !

Exporter les métriques Traefik dans InfluxDB dans un contexte Kubernetes

05/12/2019 kubernetes traefik influxdb métrique timeseries

Traefik, depuis sa version V1, permet d’envoyer des métriques vers différents backends (StatsD, Prometheus, InfluxDB et Datadog). J’ai enfin pris le temps d’activer cette fonctionnalité et de creuser un peu le sujet étant donné que le dashboard de Traefik V2 n’affiche plus certaines de ses statistiques.

La documentation de Traefik sur le sujet :

Commençons par créer une base traefik dans InfluxDB (version 1.7.8)

influx
Connected to http://localhost:8086 version 1.7.8
InfluxDB shell version: 1.7.9
> auth
username: XXX
password: XXX
> CREATE DATABASE traefik
> CREATE USER traefik WITH PASSWORD '<password>'
> GRANT ALL ON traefik to traefik
> SHOW GRANTS FOR traefik
database privilege
-------- ---------
traefik  ALL PRIVILEGES
> quit

Dans mon cas, l’accès à InfluxDB se fait en https au travers d’une (autre) instance Traefik. J’utilise donc la connexion en http plutôt qu’en udp.

Cela donne les instructions suivantes en mode CLI :

    --metrics=true
    --metrics.influxdb=true
    --metrics.influxdb.address=https://influxdb.domain.tld:443
    --metrics.influxdb.protocol=http
    --metrics.influxdb.database=traefik
    --metrics.influxdb.username=traefik
    --metrics.influxdb.password=<password>

J’ai gardé les valeurs par défaut pour addEntryPointsLabels (true), addServicesLabels (true) et pushInterval (10s).

Cela donne le Deployment suivant :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: traefik2-ingress-controller
  labels:
    k8s-app: traefik2-ingress-lb
spec:
  replicas: 2
  selector:
    matchLabels:
      k8s-app: traefik2-ingress-lb
  template:
    metadata:
      labels:
        k8s-app: traefik2-ingress-lb
        name: traefik2-ingress-lb
    spec:
      serviceAccountName: traefik2-ingress-controller
      terminationGracePeriodSeconds: 60
      containers:
      - image: traefik:2.0.6
        name: traefik2-ingress-lb
        ports:
          - name: web
            containerPort: 80
          - name: admin
            containerPort: 8080
          - name: secure
            containerPort: 443
        readinessProbe:
          httpGet:
            path: /ping
            port: admin
          failureThreshold: 1
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 2
        livenessProbe:
          httpGet:
            path: /ping
            port: admin
          failureThreshold: 3
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 2
        args:
          - --entryPoints.web.address=:80
          - --entryPoints.secure.address=:443
          - --entryPoints.traefik.address=:8080
          - --api.dashboard=true
          - --api.insecure=true
          - --ping=true
          - --providers.kubernetescrd
          - --providers.kubernetesingress
          - --log.level=ERROR
          - --metrics=true
          - --metrics.influxdb=true
          - --metrics.influxdb.address=https://influxdb.domain.tld:443
          - --metrics.influxdb.protocol=http
          - --metrics.influxdb.database=traefik
          - --metrics.influxdb.username=traefik
          - --metrics.influxdb.password=<password>

Appliquer le contenu du fichier dans votre cluster Kubernetes

kubectl apply -f deployment.yml -n <namespace>

Sur le dashboard Traefik, dans la section “Features”, la boite “Metrics” doit afficher “InfluxDB”, comme ci-dessous :

Traefik Dashboard avec les métriques InfluxDB activés

Vous pouvez alors vous connecter à votre instance InfluxDB pour valider que des données sont bien insérées :

influx
Connected to http://localhost:8086 version 1.7.8
InfluxDB shell version: 1.7.9
> auth
username: traefik
password:
> use traefik
Using database traefik
> show measurements
name: measurements
name
----
traefik.config.reload.lastSuccessTimestamp
traefik.config.reload.total
traefik.entrypoint.connections.open
traefik.entrypoint.request.duration
traefik.entrypoint.requests.total
traefik.service.connections.open
traefik.service.request.duration
traefik.service.requests.total

Il ne vous reste plus qu’à utiliser Chronograf ou Grafana pour visualiser vos données et définir des alertes.

Un exemple rapide avec la répartition des codes HTTP dans Grafana :

Graphiques des données de Traefik depuis InfluxDB dans Grafana

Kubernetes @ OVH - Traefik2 et Cert Manager pour le stockage des certificats en secrets

08/11/2019 kubernetes traefik ovh secrets cert-manager

Avec la sortie de Traefik 2, il était temps de mettre à jour le billet Kubernetes @ OVH - Traefik et Cert Manager pour le stockage des certificats en secrets pour tenir compte des modifications.

L’objectif est toujours de s’appuyer sur Cert-Manager pour la génération et le stockage des certificats Let’s Encrypt qui seront utilisés par Traefik. L’idée est de stocker ces certificats sous la forme d’un objet Certificate et de ne plus avoir à provisionner un volume pour les stocker. On peut dès lors avoir plusieurs instances de Traefik et non plus une seule à laquelle le volume serait attaché.

Installation de cert-manager :

# Install the CustomResourceDefinition resources separately
kubectl apply --validate=false -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.11/deploy/manifests/00-crds.yaml

# Create the namespace for cert-manager
kubectl create namespace cert-manager

# Add the Jetstack Helm repository
helm repo add jetstack https://charts.jetstack.io

# Update your local Helm chart repository cache
helm repo update

# Install the cert-manager Helm chart
helm install \
  --name cert-manager \
  --namespace cert-manager \
  --version v0.11.0 \
  jetstack/cert-manager

Nous allons ensuite devoir créer un Issuer dans chaque namespace pour avoir un générateur de certificats propre à chaque namespace. Cela est notamment du au fait que Traefik s’attend à ce que le secret et l’ingress utilisant ce secret soient dans le même namespace. Nous spécifions également que nous utiliserons traefik comme ingress pour la génération des certificats.

cert-manager/issuer.yml:

apiVersion: cert-manager.io/v1alpha2
kind: Issuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    # The ACME server URL
    server: https://acme-v02.api.letsencrypt.org/directory
    # Email address used for ACME registration
    email: user@example.com
    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
      name: letsencrypt-prod
    # Enable HTTP01 validations
    solvers:
    - selector: {}
      http01:
        ingress:
          class: traefik

Puis créons le “issuer” dans la/les namespace(s) voulu(s) :

# Create issuer in a given namespace
kubectl create -n <namespace> -f cert-manager/issuer.yml

Installons ensuite traefik V2

Créons le namespace traefik2 :

# Create namespace
kubectl create ns traefik2
# Change context to this namespace so that all commands are by default run for this namespace
# see https://github.com/ahmetb/kubectx
kubens traefik2

En premier lieu, Traefik V2 permet d’avoir un provider Kubernetes qui se base sur des Custom Ressources Definition (aka CRD).

Créeons le fichier traefik2/crd.yml :

---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: ingressroutes.traefik.containo.us
spec:
  group: traefik.containo.us
  version: v1alpha1
  names:
    kind: IngressRoute
    plural: ingressroutes
    singular: ingressroute
  scope: Namespaced
---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: middlewares.traefik.containo.us
spec:
  group: traefik.containo.us
  version: v1alpha1
  names:
    kind: Middleware
    plural: middlewares
    singular: middleware
  scope: Namespaced
---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: ingressroutetcps.traefik.containo.us
spec:
  group: traefik.containo.us
  version: v1alpha1
  names:
    kind: IngressRouteTCP
    plural: ingressroutetcps
    singular: ingressroutetcp
  scope: Namespaced
---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: ingressrouteudps.traefik.containo.us
spec:
  group: traefik.containo.us
  version: v1alpha1
  names:
    kind: IngressRouteUDP
    plural: ingressrouteudps
    singular: ingressrouteudp
  scope: Namespaced
---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: tlsoptions.traefik.containo.us
spec:
  group: traefik.containo.us
  version: v1alpha1
  names:
    kind: TLSOption
    plural: tlsoptions
    singular: tlsoption
  scope: Namespaced
---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: tlsstores.traefik.containo.us
spec:
  group: traefik.containo.us
  version: v1alpha1
  names:
    kind: TLSStore
    plural: tlsstores
    singular: tlsstore
  scope: Namespaced
---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: traefikservices.traefik.containo.us
spec:
  group: traefik.containo.us
  version: v1alpha1
  names:
    kind: TraefikService
    plural: traefikservices
    singular: traefikservice
  scope: Namespaced

Vous pouvez retrouver les sources de ces CRD.

Continuons avec traefik2/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). Si vous venez d’une installation avec Traefik 1, ce n’est pas tout à fait la même définition des permissions.

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: traefik2-ingress-controller
  namespace: traefik2
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: traefik2-ingress-controller
  namespace: traefik2
rules:
  - apiGroups:
      - ""
    resources:
      - services
      - endpoints
      - secrets
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - extensions
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - extensions
    resources:
      - ingresses/status
    verbs:
      - update
  - apiGroups:
      - traefik.containo.us
    resources:
      - middlewares
      - ingressroutes
      - traefikservices
      - ingressroutetcps
      - ingressrouteudps
      - tlsoptions
      - tlsstores
    verbs:
      - get
      - list
      - watch
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: traefik2-ingress-controller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: traefik2-ingress-controller
subjects:
- kind: ServiceAccount
  name: traefik2-ingress-controller
  namespace: traefik2

Nous pouvons alors songer à déployer Traefik V2 sous la forme d’un Deployment. Mais avant de produire le fichier, ce qu’il faut savoir ici :

lorsque cert-manager fait une demande de certificat, il crée un ressource de type Ingress. Dès lors, il faut activer les deux providers kubernetes disponibles avec Traefik V2 : KubernetesCRD et KubernetesIngress. Le premier provider permettra de profiter des nouveaux objets fournis par la CRD et le second permet que Traefik gère les Ingress traditionnelles de Kubernetes et notamment celles de cert-manager.
Contrairement à la version 1 de Traefik, le provider KubernetesIngress ne supporte pas les annotations
En activant le provider KubernetesIngress, on se simplifie aussi la migration d’un socle Traefik V1 vers V2, au support des annotations près.

traefik2/deployment.yml :

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: traefik2-ingress-controller
  labels:
    k8s-app: traefik2-ingress-lb
spec:
  replicas: 2
  selector:
    matchLabels:
      k8s-app: traefik2-ingress-lb
  template:
    metadata:
      labels:
        k8s-app: traefik2-ingress-lb
        name: traefik2-ingress-lb
    spec:
      serviceAccountName: traefik2-ingress-controller
      terminationGracePeriodSeconds: 60
      containers:
      - image: traefik:2.1.1
        name: traefik2-ingress-lb
        ports:
          - name: web
            containerPort: 80
          - name: admin
            containerPort: 8080
          - name: secure
            containerPort: 443
        readinessProbe:
          httpGet:
            path: /ping
            port: admin
          failureThreshold: 1
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 2
        livenessProbe:
          httpGet:
            path: /ping
            port: admin
          failureThreshold: 3
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 2
        args:
          - --entryPoints.web.address=:80
          - --entryPoints.secure.address=:443
          - --entryPoints.traefik.address=:8080
          - --api.dashboard=true
          - --api.insecure=true
          - --ping=true
          - --providers.kubernetescrd
          - --providers.kubernetesingress
          - --log.level=DEBUG

Pour permettre au cluster d’accéder aux différents ports, il faut définir un service via le fichier traefik2/service.yml :

---
kind: Service
apiVersion: v1
metadata:
  name: traefik2-ingress-service-clusterip
spec:
  selector:
    k8s-app: traefik2-ingress-lb
  ports:
    - protocol: TCP
      port: 80
      name: web
    - protocol: TCP
      port: 8080
      name: admin
    - protocol: TCP
      port: 443
      name: secure
  type: ClusterIP

Et pour avoir un accès de l’extérieur, il faut instancier un load-balancer via le fichier traefik/traefik-service-loadbalancer.yml

---
kind: Service
apiVersion: v1
metadata:
  name: traefik-ingress-service-lb
spec:
  selector:
    k8s-app: traefik2-ingress-lb
  ports:
    - protocol: TCP
      port: 80
      name: web
    - protocol: TCP
      port: 443
      name: secure
  type: LoadBalancer

Pour donner l’accès au dashboard via une url sécurisée par un certificat Let’s Encrypt, il faut déclarer un Ingress, dans le fichier traefik2/api-ingress.yml :

---
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: traefik2-web-ui
spec:
  entryPoints:
    - secure
  routes:
    - match: Host(`traefik2.k8s.cerenit.fr`)
      kind: Rule
      services:
        - name: traefik2-ingress-service-clusterip
          port: 8080
  tls:
    secretName: traefik2-cert
---
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: traefik2-web-ui-http
spec:
  entryPoints:
    - web
  routes:
    - match: Host(`traefik2.k8s.cerenit.fr`)
      kind: Rule
      services:
        - name: traefik2-ingress-service-clusterip
          port: 8080

L’idée est donc de rentre le dashboard accessible via l’url traefik2.k8s.cerenit.fr.

La section tls de l’ingress indique le nom d’hôte pour lequel le certificat va être disponible et le nom du secret contenant le certificat du site que nous n’avons pas encore créé.

Il nous faut donc créer ce certificat :

apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
  name: traefik2-cert
  namespace: traefik2
spec:
  secretName: traefik2-cert
  issuerRef:
    name: letsencrypt-prod
  commonName: traefik2.k8s.cerenit.fr
  dnsNames:
    - traefik2.k8s.cerenit.fr

Il ne reste plus qu’à faire pour instancier le tout :

kubectl apply -f traefik2/

Pour la génération du certificat, il conviendra de vérifier la sortie de

kubectl describe certificate traefik2-cert

A ce stade, il nous manque :

L’authentification au niveau accès
La redirection https

C’est là que les Middlewares rentrent en jeu.

Pour la redirection https: traefik2/middleware-redirect-https.yml

apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: https-only
spec:
  redirectScheme:
    scheme: https

Pour l’authentification : traefik2/middleware-auth.yml

apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: auth-traefik-webui
spec:
  basicAuth:
    secret: traefik-auth

Il faut alors créer un secret kubernetes qui contient une variable users contenant la/les ligne(s) d’authentification :

apiVersion: v1
kind: Secret
metadata:
  name: traefik-auth
  namespace: traefik2
data:
  users: |2
    dGVzdDokYXByMSRINnVza2trVyRJZ1hMUDZld1RyU3VCa1RycUU4d2ovCnRlc3QyOiRhcHIxJGQ5aHI5SEJCJDRIeHdnVWlyM0hQNEVzZ2dQL1FObzAK

Cela correspond à 2 comptes test/test et test2/test2, encodés en base64 et avec un mot de passe chiffré via htpasswd.

test:$apr1$H6uskkkW$IgXLP6ewTrSuBkTrqE8wj/
test2:$apr1$d9hr9HBB$4HxwgUir3HP4EsggP/QNo0

On peut alors mettre à jour notre fichier traefik2/api-ingress.yml et rajouter les deux middlewares que nous venons de définir :

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: traefik2-web-ui
spec:
  entryPoints:
    - secure
  routes:
    - match: Host(`traefik2.k8s.cerenit.fr`)
      middlewares:
        - name: auth-traefik-webui
      kind: Rule
      services:
        - name: traefik2-ingress-service-clusterip
          port: 8080
  tls:
    secretName: traefik2-cert
---
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: traefik2-web-ui-http
spec:
  entryPoints:
    - web
  routes:
    - match: Host(`traefik2.k8s.cerenit.fr`)
      middlewares:
        - name: https-only
      kind: Rule
      services:
        - name: traefik2-ingress-service-clusterip
          port: 8080

Et pour le prendre en compte:

kubectl apply -f traefik2/

Vous devez alors avoir une redirection automatique vers le endpoint en https et une mire d’authentification.

Pour ceux qui font une migration dans le même cluster de Traefik V1 vers Traefik V2 :

Si vous avez chaque instance Traefik avec son LoadBalancer et donc son IP dédiée, alors pour que les demandes de certificats ne soient pas interceptées par Traefik V1, il faudra personnaliser l’ingressClass de Traefik et créer un issuer cert-manager qui utilise cette même ingressClass.
Si vous utilisiez les annotations pour générer vos certificats, il vous faut passer par un object Certificate
Comme dit plus haut, en activant le provider kubernetesIngress, vous pouvez directement migrer sur un socle Traefik v2 puis migrer progressivement vos Ingress vers des IngressRoute. Pas besoin de faire une migration en mode big bang.

Sources utiles:

Web, Ops & Data - Octobre 2019

30/10/2019 kafka traefik kubernetes ksql kafka-streams gke anthos helm

Rendez-vous le 5 Novembre prochain à la seconde édition du Paris Time Series Meetup consacré à QuasarDB pour des cas d’usages autour de la finance et des transports.

Cloud

The $10m engineering problem : retour d’expérience intéressant sur l’optimisation de sa facture cloud et donc l’accroissement de sa marge opérationnelle.

Container et Orchestration

What’s Going on with GKE and Anthos? : Si on rapproche ça avec le fait que Google ait gardé le lead sur knative plutôt que de le confier à une fondation, on peut avoir quelques sueurs froides sur le potentiel lock-in ou alors d’une offre k8s à 2 vitesses (GKE tel qu’on le connait actuellement et Anthos GKE avec des fonctionnalités & souscriptions additionnelles…). La seule limite que je vois à ça pour le moment est le fait que Google a vendu k8s comme runtime universel de workload et qu’ils ont besoin de garder cela pour piquer des parts de marché à AWS & Azure…
Traefik 2.0 with Kubernetes et Advanced Traefik 2.0 with Kubernetes : pas encore implémenté mais a priori tout ce qu’il faut savoir pour passer de Traefik 1.x vers Traefik 2.x sous Kubernetes
Helm 2.15.0 Released : dernière version stable à apporter des nouveautés a priori avant migration vers la version 3.0. La version 2.x va passer en maintenance (correctifs de bugs & sécurité) et s’éteindra progressivement (6 mois après la release de Helm 3, elle ne prendra que des correctifs de sécurité et fin du support au bout d’un an). En attendant, cette version apporte notamment le paramètre --output <table|json|yaml> à certaines commandes. Pratique quand on manipule les sorties de Helm dans des scripts…
Comparing Ingress controllers for Kubernetes : une comparaison de 11 Ingress Controller (Nginx, Traefik, Kong, HAProxy, etc) sur une douzaine de fonctionnalités.

(Big) data

Why I Recommend My Clients NOT Use KSQL and Kafka Streams : la gestion des états et la capacité à pouvoir savoir à quel offset d’un topic kafka reprendre sa consommation peut être un sujet surtout dans le cadre d’une grosse volumétrie qui peut empêcher que le cas de reprendre la consommation du topic depuis son origine. Si Kafka Streams était doté de ce fameux “checkpoint” cela pourrait simplifier la chose. L’autre cas étant sur l’absence de “shuffle sort” utilisé dans des contexte analytiques. Du coup Kafka streams crée des topics supplémentaires pour le besoin et cela peut nuire au bon fonctionnement de votre cluster.
Change data capture in production with Apache Flink - David Morin & Yann Pauly : un retour d’expérience très riche et très complet sur l’utilisation de Flink chez OVH, les problématiques qu’ils ont rencontré et comment ils ont itéré sur leur pipeline d’ingestion de données. La version française donnée à DataOps.rocks devrait être disponible sous peu.

Web, Ops & Data - Septembre 2019

26/09/2019 kafka traefik service-mesh maesh rook ceph kubernetes kubectl ksql kafka-streams telegraf docker log

Container et Orchestration

Traefik 2.0 : la version tant attendue du reverse proxy “cloud native” Traefik sort en version 2.0 avec une réécriture complète et plein de nouvelles fonctionnalités : support du reverse proxy pour tcp et plus uniquement http, introduction des “middleware” pour de la configuration plus flexible, une CRD Traefik pour Kubernetes, un nouveau dashboard, le support du déploiement en mode canary, “mirroring” de traffic, etc. Il y a un guide de migration pour passer de la V1 à la v2.
Announcing Maesh, a Lightweight and Simpler Service Mesh Made by the Traefik Team : l’équipe Containous, qui est derrière Traefik, sort sa solution de Service Mesh : Maesh. Elle respecte la spécification Service Mesh Interface (SMI) et a pour principal intérêt pour moi de ne pas modifier les objets kubernetes pour se déployer en mode sidecar (contrairement à Istio pour ne pas le nommer).
Qu’est-ce qu’un Service Mesh ? : article d’information/rappel sur ce qu’est un Service Mesh et son intérêt dans une architecture micro-services.
Rook v1.1: Accelerating Storage Providers & Rook v1.1: Ceph CSI, Bucket Provisioning, External Clusters, and much more!: rajout du support de Yugabyte, passage du support de EdgeFS d’alpha à beta, pleins d’améliorations pour Ceph, dont la gestion des clusters Ceph externes au cluster Kubernetes.
Kubernetes 1.16: Custom Resources, Overhauled Metrics, and Volume Extensions & Release Notes : Passage en GA des CRD, des admissions webhooks, Refonte des métriques, le redimensionnement des volumes passe de alpha > beta, Support ipv4/ipv6 au niveau pods & services, dépreciation des api extensions/v1beta1, apps/v1beta1 et apps/v1beta2, plein de fonctionnalités pour les conteneurs Windows, etc.
Deprecated APIs Removed In 1.16: Here’s What You Need To Know : ce qu’il faut savoir sur la dépréciation des API listées ci-dessus
[ANNOUNCE] Security release of kubectl versions v1.16.0 / 1.15.4 / 1.14.7 and 1.13.11 - CVE-2019-11251 : une nouvelle faille sur kubectl cp et cette commande semble supprimée dans la version 1.16.

Data

Say Hello World to event streaming : Confluent publie des tutoriels sur Kafka, Kafka Streams et KSQL pour illustrer différents cas d’usages avec le code associé. Ils ont l’air assez bien fait.

Time Series

Release Announcement: Telegraf 1.12.0 : Telegraf, le collecteur de métriques/logs passent en version 1.12 avec 13 nouveaux plugins dont un pour l’ingestion des logs docker et plein d’autres améliorations. L’autre grande nouveauté est l’arrivée des plugins - il est possible d’ajouter des plugins à Telegrad de façon dynamique ; il n’est plus nécessaire de recompiler telegrad avec ces plugins en son sein.

1 2 3 4 5