CérénIT

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: 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: 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: tlsoptions.traefik.containo.us
spec:
  group: traefik.containo.us
  version: v1alpha1
  names:
    kind: TLSOption
    plural: tlsoptions
    singular: tlsoption
  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:
      - pods
      - 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:
      - ingressroutes
      - ingressroutetcps
      - middlewares
      - tlsoptions
    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.0.4
        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:

Ce mercredi, j’ai le plaisir d’organiser la première édition du Paris Time Series Meetup - il reste des places, vous pouvez encore vous inscrire et nous rejoindre !

Ce meetup est organisé conjointement avec InfluxData suite à ma nomination en tant qu’InfluxAce lors d’InfluxDays London 2019. J’ai alors cherché à organiser le meetup en mettant en avant la communauté et les acteurs français autour de la série temporelle, de ne pas me limiter à des présentations produits mais de les enrichir avec des retours clients et aussi à proposer des usages plus avancés que de stocker ses données et de faire deux à trois graphiques avec ces métriques. Je pense que cette première édition respecte ces critères.

Au programme donc :

  • Time Series with Warp10 - Technology and Advanced Use Cases (because time series are way more than monitoring) par Mathias Herberts (CTO et Fondateur de SenX, la société éditrice de la plateforme opensource Warp10). Le talk sera en français et Mathias nous présentera Warp10 et différents cas d’usages autour de la platforme.

  • Pilotage du monitoring de datacenter grâce au Machine Learning par Christophe Rannou (OVH Machine Learning Services Team Leader) et Clément Bataille (OVH Machine Learning Services, Data Scientist) : Comment OVH utilise le Machine Learning appliqué au monitoring dans le but d’extraire des tendances et de détecter les anomalies afin de se prémunir d’incidents et de passer d’un entretien réactif a un entretien proactif. On y parlera notamment de leur offre Prescience mais pas uniquement !

Le meetup se fera dans les locaux de ManoMano qui nous font le plaisir de nous héberger.

Retrouvez toutes les informations sur la page de l’événement sur Meetup.

Surveillez le Time Series Paris Meetup, car la première édition du Meetup sera annoncée mardi avec une présentation des usages avancées des séries temporelles avec Warp10 (comprendre au-delà du monitoring classique) et une présentation par les équipes OVH sur du monitoring de datacenter aidé par du machine learning et leur offre Préscience.

CI/CD

  • How to trigger multiple pipelines using GitLab CI/CD : depuis une pipeline d’un dépôt gitlab, il va être possible d’appeler les pipelines des autres projets gitlab. Une fonctionnalité intéressante et qui pourrait lever la dépendance à Jenkins lorsque l’on a des pipelines un peu complexes et inter-projets.
  • New up and coming GitLab CI/CD Features : bilan et perspectives par le responsable produit de gitlab sur les fonctionnalités CI/CD qui ont été rajoutées cette année et celles à venir.

Code

Conteneurs & orchestration

SQL

time series

Container et orchestration

  • The Journey to Traefik Enterprise Edition: Product Evaluation
  • Docker Security Update: CVE-2019-5736 and Container Security Best Practices : Vous avez sans doute tous entendus parlé de la faille de runc, sous le doux nom de CVE-2019-5736. Le billet indique qu’il faut utiliser une version 18.06.2+ pour Docker CE et rappelle quelques bonnes pratiques de gestion de containers. Il n’y a pas que les serveurs à mettre à jour, il y a aussi les postes de développeurs, tout aussi exposés.
  • rancher/runc-cve : Pour les gens qui ne peuvent pas mettre à jour le binaire docker, l’équipe de Rancher met à disposition des versions du binaire runc pour les versions depuis docker 1.12.6 jusqu’à 18.06.1
  • CVE 2019-5736 dans runC : l’article indique une façon d’exploiter la faille de RunC.
  • Ansible Operator: What is it? Why it Matters? What can you do with it? : Ansible ne fournit pas un “oprator” en tant que tel pour Kubernetes mais de quoi permettre de créer un operator en se basant sur des playbooks/roles ansible. Ainsi, si votre ressource change d’état par exemple, alors le playbook associé est joué. Idem pour la gestion d’un upgrade, etc. Cela s’inscrit dans la logique de pouvoir développer ses propres Operator sans avoir à les écrire en Go.
  • Mastering the KUBECONFIG file : différentes astuces autour de la gestion du fichier KUBECONFIG.
  • KubeDB : KubeDB est un operator kubernetes qui vise à pouvoir déployer et gérer différentes bases sur un cluster kubernetes. Les bases supportées sont MySQL, Postgres, Elasticsearch, Redis, MongoDB et Memcached. Le niveau de fonctionnalités dépend beaucoup de la base de données retenus (la réplication semble être gérée pour Postgres mais pas pour MySQL par ex). La version 0.10 vient de sortir, apportant le support du cluster Redis
  • Managed Kubernetes Service : OVH vient de lancer son offre kubernetes managé et pour l’utiliser depuis deux mois maintenant, elle fonctionne plutôt bien.

DNS

(No)SQL

  • Contrainte d’exclusion : nous connaissons tous les contraintes d’unicité mais parfois cela ne suffit pas. L’exmple montre comment mettre en place une contrainte d’exclusion sur la base de filtre de plage de réseaux : 192.168.122.0/28 est compris dans 192.168.122.0/24, donc si le 2nd est entré dans la base, le 1er ne pourra jamais être ajouté car il y a recouvrement. On retrouve un autre exemple de cette contrainte d’exclusion sur des dates dans l’astuce de la semaine de l’édition 289 de Posrgres Weekly.
  • Understanding Database Sharding : un billet très explicite sur le partitionnement (sharding) de base de données, pourquoi et comment le faire. Il rappelle aussi les inconvénients à le faire et ce qu’il vaut mieux faire avant d’en arriver au sharding.
  • TiDB: Distributed NewSQL with Kevin Xu : TIDB est une base qui se déploie sur Kubernetes et qui s’appuie sur RocksDB. Elle se veut “NewSQL” dans le sens où elle veut supporter à la fois des transactions et de l’analytique. Elle veut offrir notamment un support de MySQL mais dans les faits, le support reste encore limité. Pour ceux qui veulemnt déployer du MySQL sur Kubernetes avec du sharding, il vaut mieux aller voir du coté de Vitess
  • Farewell to fsync(): 10× faster database tests with Docker : alors que l’actualité était plutôt sur le fait que Postgres gérait mieux les erreurs lors d’un fsync(), l’astuce consiste ici à désactiver fsync() et/ou à mettre le dossier des données de votre base en RAM pour accélérer les temps de déroiulement de tests. Testé chez un client, c’est un gain d’au moins 20s qui a été constaté sur une opération de quelques minutes (< 5).

Timeseries

  • Tutorial: Time Series Analysis with Pandas : un tutoriel assez progressif et didactique sur la manipulation de données temporelles avec Pandas.
  • TSL: a developer-friendly Time Series query language for all our metrics : L’équipe d’OVH Metrics a crée son propre langage de requêtage orienté séries temporelles pour Prometheus et Warp10. Le billet raconte leur épopée dans le monde des base de données temporelles et comment ils en sont arrivés à créer TSL. On retrouve une syntaxe fonctionnelle et qui se retrouve assez proche de celle de Flux, qui lui supporte InfluxDB et Prometheus.

Container et orchestration

  • The Journey to Traefik Enterprise Edition: Product Evaluation
  • Docker Security Update: CVE-2019-5736 and Container Security Best Practices : Vous avez sans doute tous entendus parlé de la faille de runc, sous le doux nom de CVE-2019-5736. Le billet indique qu’il faut utiliser une version 18.06.2+ pour Docker CE et rappelle quelques bonnes pratiques de gestion de containers. Il n’y a pas que les serveurs à mettre à jour, il y a aussi les postes de développeurs, tout aussi exposés.
  • rancher/runc-cve : Pour les gens qui ne peuvent pas mettre à jour le binaire docker, l’équipe de Rancher met à disposition des versions du binaire runc pour les versions depuis docker 1.12.6 jusqu’à 18.06.1
  • CVE 2019-5736 dans runC : l’article indique une façon d’exploiter la faille de RunC.
  • Ansible Operator: What is it? Why it Matters? What can you do with it? : Ansible ne fournit pas un “oprator” en tant que tel pour Kubernetes mais de quoi permettre de créer un operator en se basant sur des playbooks/roles ansible. Ainsi, si votre ressource change d’état par exemple, alors le playbook associé est joué. Idem pour la gestion d’un upgrade, etc. Cela s’inscrit dans la logique de pouvoir développer ses propres Operator sans avoir à les écrire en Go.
  • Mastering the KUBECONFIG file : différentes astuces autour de la gestion du fichier KUBECONFIG.
  • KubeDB : KubeDB est un operator kubernetes qui vise à pouvoir déployer et gérer différentes bases sur un cluster kubernetes. Les bases supportées sont MySQL, Postgres, Elasticsearch, Redis, MongoDB et Memcached. Le niveau de fonctionnalités dépend beaucoup de la base de données retenus (la réplication semble être gérée pour Postgres mais pas pour MySQL par ex). La version 0.10 vient de sortir, apportant le support du cluster Redis
  • Managed Kubernetes Service : OVH vient de lancer son offre kubernetes managé et pour l’utiliser depuis deux mois maintenant, elle fonctionne plutôt bien.

DNS

(No)SQL

  • Contrainte d’exclusion : nous connaissons tous les contraintes d’unicité mais parfois cela ne suffit pas. L’exmple montre comment mettre en place une contrainte d’exclusion sur la base de filtre de plage de réseaux : 192.168.122.0/28 est compris dans 192.168.122.0/24, donc si le 2nd est entré dans la base, le 1er ne pourra jamais être ajouté car il y a recouvrement. On retrouve un autre exemple de cette contrainte d’exclusion sur des dates dans l’astuce de la semaine de l’édition 289 de Posrgres Weekly.
  • Understanding Database Sharding : un billet très explicite sur le partitionnement (sharding) de base de données, pourquoi et comment le faire. Il rappelle aussi les inconvénients à le faire et ce qu’il vaut mieux faire avant d’en arriver au sharding.
  • TiDB: Distributed NewSQL with Kevin Xu : TIDB est une base qui se déploie sur Kubernetes et qui s’appuie sur RocksDB. Elle se veut “NewSQL” dans le sens où elle veut supporter à la fois des transactions et de l’analytique. Elle veut offrir notamment un support de MySQL mais dans les faits, le support reste encore limité. Pour ceux qui veulemnt déployer du MySQL sur Kubernetes avec du sharding, il vaut mieux aller voir du coté de Vitess
  • Farewell to fsync(): 10× faster database tests with Docker : alors que l’actualité était plutôt sur le fait que Postgres gérait mieux les erreurs lors d’un fsync(), l’astuce consiste ici à désactiver fsync() et/ou à mettre le dossier des données de votre base en RAM pour accélérer les temps de déroiulement de tests. Testé chez un client, c’est un gain d’au moins 20s qui a été constaté sur une opération de quelques minutes (< 5).

Timeseries

  • Tutorial: Time Series Analysis with Pandas : un tutoriel assez progressif et didactique sur la manipulation de données temporelles avec Pandas.
  • TSL: a developer-friendly Time Series query language for all our metrics : L’équipe d’OVH Metrics a crée son propre langage de requêtage orienté séries temporelles pour Prometheus et Warp10. Le billet raconte leur épopée dans le monde des base de données temporelles et comment ils en sont arrivés à créer TSL. On retrouve une syntaxe fonctionnelle et qui se retrouve assez proche de celle de Flux, qui lui supporte InfluxDB et Prometheus.

L’objectif est 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 de secrets et de ne plus avoir à provisionner un volume pour les stocker.

Installons déjà 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 issuer.yml

Notre contexte de déploiement utilisant Traefik comme ingress, je remets ci-dessous la configuration que j’utilise avec les ajustements nécessaires pour l’utilisation de cert-manager. Il n’est en effet plus possible et il devient désormais inutile de déclarer la section “acme” dans traefik.toml. J’ai aussi supprimé la redirect automatique http vers https, il faudra la gérer au niveau des ingress.

Créons le namespace traefik :

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

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: traefik
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: traefik-ingress-controller
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
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
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: traefik
---
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: traefik

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
data:
  traefik.toml: |
    defaultEntryPoints = ["http", "https"]

    logLevel = "INFO"

    insecureSkipVerify = true

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

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

    [kubernetes]

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

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

---
kind: Deployment
apiVersion: apps/v1
metadata:
  name: traefik-ingress-controller
  labels:
    k8s-app: traefik-ingress-lb
spec:
  replicas: 1
  selector:
    matchLabels:
      k8s-app: traefik-ingress-lb
  template:
    metadata:
      labels:
        k8s-app: traefik-ingress-lb
        name: traefik-ingress-lb
    spec:
      serviceAccountName: traefik-ingress-controller
      terminationGracePeriodSeconds: 60
      containers:
      - image: traefik:1.7.16
        name: traefik-ingress-lb
        volumeMounts:
        - mountPath: /config
          name: traefik-config
        ports:
        - name: http
          containerPort: 80
        - name: admin
          containerPort: 8080
        - name: secure
          containerPort: 443
        args:
        - --configfile=/config/traefik.toml
      volumes:
        - name: traefik-config
          configMap:
            name: traefik-conf

Nous déployons donc :

  • Traefik en Deployment
  • Les ports 80, 443 et 8080 sont définis
  • La configuration est une ConfigMap

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

---
kind: Service
apiVersion: v1
metadata:
  name: traefik-ingress-service-clusterip
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: 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: traefik-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 traefik/traefik-api-ingress.yml :

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: traefik
    cert-manager.io/issuer: letsencrypt-prod
    traefik.ingress.kubernetes.io/redirect-entry-point: https
    traefik.ingress.kubernetes.io/redirect-permanent: "true"
    ingress.kubernetes.io/ssl-redirect: "true"
    ingress.kubernetes.io/ssl-temporary-redirect: "false"
  name: traefik-web-ui
spec:
  rules:
  - host: traefik.k8s.cerenit.fr
    http:
      paths:
      - path: /
        backend:
          serviceName: traefik-ingress-service-clusterip
          servicePort: admin
  tls:
  - hosts:
    - traefik.k8s.cerenit.fr
    secretName: traefik-cert

L’idée est donc de rentre le dashboard accessible via l’url traefik.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éé.

Les annotations permettent :

  • de déclarer le type d’ingress à utiliser ; ici: traefik
  • de déclarer que le certificat qui doit être fourni par cert-manager est un certificat de type Let’s Encrypt
  • de faire une redirection http vers https systématique.

Les deux premières annotations permettent de ne pas avoir à déclarer soi même le certificat - il est automatiquement généré via ingress-shim. Cela vous fait donc un objet kubernetes en moins à gérer dans votre configuration. Si vous ne souhaitez pas vous appuyer sur ce méchanisme d’ingress-shim, il vous faudra ne pas utiliser ces annotations et gérer vous même un objet “Certificate”.

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

kubectl create -f traefik/

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

kubectl describe certificate traefik-cert

Et voilà - maintenant que le problème des certificats est corrigé, je vais pouvoir passer dans un contexte de déploiement multi-nodes.

Le Blog

Nous partageons ici notre veille et nos réflexions

Nuage de tags

docker kubernetes elasticsearch kafka postgres traefik ansible grafana python aws influxdb sécurité tick mysql redis timeseries cloud ovh chronograf swarm test cassandra hashicorp ksql log microservice serverless spark terraform angularjs cncf confluent container docker-compose graphql helm javascript machine-learning opensource rancher service-mesh stream timescaledb windows api architecture arm csp devops dns documentation elastic git hpkp iac ingress java kafka-streams kapacitor kibana lambda lean licence microsoft monitoring nginx npm orientdb prometheus redhat rest rethinkdb reverse-proxy rook sql ssh telegraf agile apm azure bash big-data bilan cert-manager certificat cli cluster continous-delivery continous-integration cookie cérénit fluxlang gcp gdpr grav hsts https hypriot istio json k3s kubedb lets-encrypt linux load-balancer mobile mongodb perspective php pip ptsm replication rpi rsyslog s3 scale scaleway schema secrets solr sre systemd vault virtualenv vue.js wagtail warp10 yarn accessibilité akka alerte alibaba amazon-emr anonymisation anthos ara automatisation bastion beam beat bounded-context branche brigade browser buildkit cd cdc ceph certificats checklist chrome ci cloud-init cloud-native cloud-storage clusterip cockroachdb code codeurs-en-seine confluence consul containerd continous-deployment coreos cors cqrs crash cron crontab csrf css curl d3.js daemonset dashboard data-pipelining data.gouv.fr datacenter dataviz date ddd debezium debian deployment desktop devoxx diff distributed-systems dive docker-app docker-hub docker-registry documentdb dokcer draft drop-in déploiement ebs ec2 edge elassandra electron elk engineering etcd event-sourcing facebook falcor feature-policy feed filebeat firebase firefox fish flash flask fleet flink fluentd flux foundation framework frontend fsync fullstack github gitlab gke glacier glowroot google google-cloud-next gpu grid géospatial hacker hadoop haproxy hdfs header html html5 http http/3 hue ia iaac ibm immutable incident index influxace influxcloud influxdata influxdays infrastructure-as-code ingénierie inspec jenkins jq jquery jwt k3d k8s k9s kubeadm kubecon kubectl laravel liste-de-diffusion loadbalancer logstash logstatsh loi maesh mailing-list management mariadb meetup message metallb micro-service molecule mot-de-passe multi-cloud médecine métrique newsletter nodeport nomad nosql null opendata openebs openmetrics openshit openssh openweb operator over-engineering packaging pandas partiql password percona performance persistent-volume-claim pipeline pipenv pod portainer prediction prescience publicité push pyenv quasardb quay queue quic ram rambleed raml react reaper recaptcha recherche registry reindex reinvent reliability responsive revocation revue-de-code rkt rolespec root rpo rto runc rwd résilience scanner search select serverless-architecture service-worker sha1 sharding shell shipyard société souveraineté-numérique spinnaker sri ssh-agent ssl statistique superset sympa syslog-ng test-unitaire tidb tiers timer timezone tls training travail ubuntu unikernel unit ux vendredi vie-privée virtualbox virtualisation vitess vm vnc volume voxxeddays vpc vscode yubikey

Syndication

Atom