A quick guide to deploying and using Traefik 2.0 in Kubernetes

Read the original for a better experience.

Shouneng. Website / 2020/04/08 /…

preface

The last time I installed Traefik, I was still using Traefik version 1.7. The day before yesterday, I was working on a containerization project here. When I was deploying edge nodes, I went to see Traefik again when selecting Ingress Controller.

For the concept of edge nodes, see a previous blog post I summarized.

The purpose of this article is to share the experience of Traefik 2.0.

In this paper, the content

1. Description of options for installing Traefik using Helm in Kubernetes
2. Instructions for configuring edge nodes
3. Instructions for configuring routing for an HTTP and WebSocket back-end service using CRD — IngressRoute from Traefik 2.0
4. Traefik 2.0 features and usage scenarios are briefly summarized

The following prerequisites must be met to read this article:

• The basic concept of Kubernetes should be clear
• Helm component logical structure (Repo, Chart, Release, Template, etc.), basic use experience

Description of options for installing Traefik using Helm in Kubernetes

Install Traefik in K8S, usually using the official Helm Chart. There is no explanation of the options in the official example, so I will download the chart first to see what is available.

Helm Pull Traefik/Traefik -- Version 7.0.0Copy the code

After reviewing it, I have nothing to change except the Node Affinity property I’m going to use to fix Traefik’s Pod to the specified Node, and nothing else in values.yaml.

The following is the part I modified in the chart of Traefik-7.0.0.

affinity:
# # This example pod anti-affinity forces the scheduler to put traefik pods
# # on nodes where no other traefik pods are scheduled.
# # It should be used when hostNetwork: true to prevent port conflicts
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: node-role
          operator: In
          values:
          - ingress-controller
        - key: ingress-controller
          operator: In
          values:
          - traefik
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchExpressions:
        - key: app
          operator: In
          values:
          - software-traefik
      topologyKey: failure-domain.beta.kubernetes.io/zone
  # This example node affinity "forces" the scheduler to put traefik pods
  # on nodes with specified lables.
Copy the code

Traefik is then deployed using the following command.

• I plan to use IP-10-20-1-95 and IP-10-20-1-96 as edge nodes, so LABEL them

  # Specify traefik node label, to be used with node affinity
  kubectl label node ip-10-20-1-95 ip-10-20-1-96 node-role=ingress-controller ingress-controller=traefik
  Copy the code

• Render the template with the helm template command to see what the resulting manifest looks like.

  cd ~/helm/charts/traefik
  mkdir -pv dry-run
  # Render Helm chart into dry-run to check final manifests
  # In dev environment, we can use Traefik dashboard.
  # Can use a fixed IP for Traefik servicehelm template -n traefik-v2 --dry-run --dependency-update --output-dir dry-run traefik-v2-r2 /traefik-7.0.0-customized/traefik \ --set nameOverride=software-traefik \ --set image.name='harbor.YOUR-DOMAIN.com.cn/library/traefik' \
  --set image.tag='2.2.0' \
  --set deployment.replicas=2 \
  --set ports.traefik.hostPort=9000 \
  --set ports.web.hostPort=8000 \
  --set ports.websecure.hostPort=8443 \
  --set additionalArguments="{--accesslog=true}" \
  --set service.type=ClusterIP \
  --set service.spec.clusterIP='10.20.211.200'
  Copy the code

• Official installation of Traefik

  # Install TraefikHelm Upgrade --history-max 10 --atomic --install --namespace Traefik-v2 Traefik-v2./ Traefik-7.0.0-Customized/Traefik / \ helm Upgrade --history-max 10 --atomic --install --namespace Traefik-v2 Traefik-v2./ Traefik-7.0.0-Customized/Traefik / \  --set nameOverride=software-traefik \ --set image.name='harbor.YOUR-DOMAIN.com.cn/library/traefik' \
  --set image.tag='2.2.0' \
  --set deployment.replicas=2 \
  --set ports.traefik.hostPort=9000 \
  --set ports.web.hostPort=8000 \
  --set ports.websecure.hostPort=8443 \
  --set additionalArguments="{--accesslog=true}" \
  --set service.type=ClusterIP \
  --set service.spec.clusterIP='10.20.211.200'
  Copy the code

Instructions for configuring edge nodes

First of all, I will explain what Edge Node is. The so-called Edge Node is a Node inside a cluster that exposes service capabilities outside the cluster. Services outside the cluster call services inside the cluster through this Node, and Edge Node is an Endpoint for communication between inside and outside the cluster.

The nodes deployed by Traefik are fixed to ip-10-20-1-95 and IP-10-20-1-96 by node Affinity.

Pod runs as hostPort, so Traefik can be accessed outside the cluster via NODE_IP:PORT.

Configure load balancing on the external order of 4 layers, and the back-end points to the Traefik ports of IP-10-20-1-95 and IP-10-20-1-96.

Instructions for configuring routing for an HTTP and WebSocket back-end service using CRD — IngressRoute with Traefik 2.0

1. Create secret for TLS certificates. Note that the file name in secret must have a fixed value

   Traefik IngressRoute must be in the same namespace as TLS secret to obtain secret.

   # Create secret for Traffic ingressRoute to use
   # Secret must be in the same namespace with ingressRoute
   # The filename inside the secret must be 'tls.crt' and 'tls.key'
   cat<<-'EOF' | kubectl apply -f -
   apiVersion: v1
   kind: Secret
   metadata:
     name: secret-name
     namespace: namespace-name
     # `type` is not needed to be specified
     # type: kubernetes.io/tls
   
   data:
     tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0...
     tls.key: LS0tLS1CRUdJTiBSU0EgUFJJVk...
   EOF
   Copy the code

   Optionally, TLSStore can define a default secret.

   # This is optional, if you only use one cert, e.g. "*.example.com", you can use TLSStore to define a default TLS secret to be used in ingressRoute
   cat<<-'EOF' | kubectl apply -f -
   apiVersion: traefik.containo.us/v1alpha1
   kind: TLSStore
   metadata:
     name: tlsstore-name
     namespace: namespace-name
   
   spec:
     defaultCertificate:
       secretName: secret-name
   EOF
   Copy the code

2. Create IngressRoute to configure the actual routing rules in Traefik. By the way, the specs on Traefik’s website are not very detailed.

cat<<-'EOF' | kubectl apply -f -
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: svc-your-app-http
  namespace: namespace-name
spec:
  entryPoints:
    - web
  routes:
    - match: Host(`YOUR-APP.YOUR-DOMAIN.com.cn`)
      middlewares:
        - name: svc-YOUR-APP-redirectscheme-to-https
      kind: Rule
      services:
        - name: YOUR-APP
          port: 80
---
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: svc-your-app-https
  namespace: namespace-name
spec:
  entryPoints:
    - websecure
  routes:
    - match: Host(`YOUR-APP.YOUR-DOMAIN.com.cn`)
      middlewares:
        - name: svc-YOUR-APP-headers
      kind: Rule
      services:
        - name: YOUR-APP
          port: 80
  tls:
    secretName: secret-name
    domains:
    - main: YOUR-DOMAIN.com.cn
      sans:
      - YOUR-APP.YOUR-DOMAIN.com.cn
    # certResolver: default
    # options: {}
---
apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: svc-YOUR-APP-redirectscheme-to-https
  namespace: namespace-name
spec:
  redirectScheme:
    scheme: https
    permanent: true
---
apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: svc-YOUR-APP-headers
spec:
  headers:
    customRequestHeaders:
      X-Forwarded-Proto: "https"
Copy the code

Traefik 2.0 features and usage scenarios are briefly summarized

Traefik 2.0 adds much anticipated TCP and UDP proxies, and can be configured with fairly flexible forwarding rules, such as forwarding the /dashboard/ path to the Web-UI Service under the same Host(app.example.com), And/API/is forwarded to the API Service.

There is also a variety of built-in Middleware available, such as operations on request headers, redirects, path interceptions, basicauth, and so on. Application Load Balancing and Network Load Balancing are both powerful.