How to use Ingress with Traefik 2.0

Traefik Traefik v2 (latest)
1

Hi,
I asked a few questions here: https://github.com/containous/traefik/issues/5866

The most interesting being: how can I actually use ingress with Traefik 2.0?

To add a little more detail:
I have four entrypoints configured: web, websecure, ping and metrics.
If I would use the new CRD, I could of course configure which entrypoint to use for which app.
But, we have a lot of ingresses and do not want to migrate everything, because the standard ingress fits our use-case just perfectly fine.
Also, we use some 3rd-party helm-charts which do not know anything about IngressRoutes. They use the normal Ingress.

So, here comes the real problem: Using an Ingress, Traefik 2.0 has no ability to know which entrypoint to use for the ingress. In the logs, I can see that Traefik just randomly (I guess), assigns endpoints to my Ingress.
For example, I have some webapplication running, that should be connected to the websecure endpoint, but Traefik decides it gets connected to the metrics endpoint. Of course, that does not work at all.

If I am not using your new CRD, how can I still use Ingress with my kind of setup?
Maybe @dduportal can help here, as advised in the issue.

2

It's puzzle me to when using helm chat

3

I don't want to migrate everything either. But I will. Because the old method is not going to get any more love, and because, as you discovered it has it's limitations. This is one of them.

You can solve that by not using 3rd party helm-charts.

You guess wrong. Traefik uses all of them.

You can wait until Allow defining default list of entryPoints for kubernetes ingress provider · Issue #5624 · traefik/traefik · GitHub is fixed, which appears to be exact duplicate of what you are describing, or better yet switch to the IngressRoute.

The only other option is to make sure that routes on different entry points never conflict, but this is not very paractical.

4

I don't want to migrate everything either. But I will. Because the old method is not going to get any more love, and because, as you discovered it has it's limitations. This is one of them.

I think you misunderstood me here. For me ingress does not have any limitations, because my use-case does not need more features.
Also, the "old method" is not old, it is the standard, built-in method of Kubernetes. So I am guessing this will receive more love.

You can solve that by not using 3rd party helm-charts.

That seems a little unrealistic for the most users I think.

1 Like
5

Hi @Furragen, we moved from "Ingress" model (also referenced as "Ingress V1" or "Legacy Ingress") because the featureset was not able to configure Traefik seamlessly.

This fact is shared by other ingress controllers as Contour, to avoid the "Ingress" object to become a bunch of annotations that are not working anymore when you switch ingress controller.

Traefik v2.0 keeps a basic support for these ingress, with only the "non annotations" features that should be used. Restricting an ingress to an entrypoint is not part of the ingress specification, so it is not available with the "default ingress" object model alas, and might not be.

=> We hope that the discussion model around the ingress v2 model will allow such feature and maybe provide a good field for future Traefik versions. As for today with Traefik v2.0 (and upcoming and v2.1), if you want a feature not included in the Ingress featureset, then you must stay in Traefik v1.7, or switch to CRDs.

However, we hear that you might not be able to use 3rd party tools which relies on Ingres objects. We are actively working on this:

  • External-DNS support is being discussed in this issue: https://github.com/containous/traefik/issues/4655 . The feature is ok, the implementation (and future maintenance) is the tricky point.
  • For cert-manager, there might be a documentation to explain how to have it working with Traefik v2.0. You might be inspired by Deploying HTTPS services with Contour and cert-manager , which would be implemented like this:

    Deploy Traefik v2.0 with only CRD enabled
    Describe your routing with IngressRoute and all other CRDs, using all the features from Traefik (entrypoint restrictions, enable middleware for URL rewriting or auth, etc.)
    Create a dummy Ingress object, with the annotation kubernetes.io/ingress.class set to fake, and with all the annotations for your external use cases (external-DNS , certmanager).

Can you elaborate a bit more about the "3rd party" you're using please? it would help us to better understand requirements

1 Like
6

Hi @dduportal ,

I do understand why you added the CRD to Traefik with 2.0 and I also understand, that the annotations can be messy to work with.
But who constantly switches the ingress controller? Until we tested Traefik 2.0 there were zero reasons for us to think about that. Now there are reasons.

Also, again: We do not need any features that are not supported by ingress. Which is why we do not want to migrate.

Can you elaborate a bit more about the "3rd party" you're using please? it would help us to better understand requirements

To give you a little more detail about the 3rd party helm-charts, here is an example:

Harbor is (at core) a container-registry with a lot of useful features. The helm-chart for that is really big.
The helm-chart does not know about your IngressRoute-CRD. It only knows ingress (the kubernetes built-in standard way of exposing your apps to the outer world).
But, if Traefik 2.0 just uses all entrypoints I defined in the config, users of Harbor will most likely not be able to use the webinterface or the api or whatever part that is externally exposed. That is because Traefik may just route traffic from the Harbor-ingress to its metrics-endpoint, because why not?

For us it is not possible to just rewrite and maintain all 3rdparty helm-charts we use. That would just simply be too much.
This will also be a problem with every 3rdparty app anyone deploys where they cannot alter the manifests.

Is the problem more clear now?

So, implementing this feature: Allow defining default list of entryPoints for kubernetes ingress provider · Issue #5624 · traefik/traefik · GitHub would probably solve most problems we (and most likely more people) have.
We could for example just send any traffic of the kubernetes-ingress-provider to the websecure-entrypoint and would probably be fine.

7

Thanks for the details on your use case, it's clearer now.

~2/3 of my customers have 2 or more ingress controllers installed. Neither your case nor mine are representative, truth is somewhere on the middle.
Switching an Ingress controller is also upgrading to a new major version, which breaks things (Nginx 2.x will surely break annotations, HAPRoxy 2 did, Contour as well: it's a common pattern).

However: is there a particular reason to NOT stay with Traefik v1.7 if it fits your needs? This version is maintained for at least 1 year (as you can see on the recent releases of 1.7.x we do not let this version rot), and I'm sure the "ingress v2 problem" will be solved until then?

I feel like this stance is a threat to stop using Traefik, and might not be the most kindest way to advocate for your need on a community (explaining your use case as you did later is waaaaay better). I'm not here to say you have to stay on Traefik, but to explain why, and how to fix. Traefik is a tool with its pro and cons, and it cannot answer to everyone's contexts. If you feel that it's better for you to not switch to Traefik v2, please consider another ingress controller more suited to your need: again it's engineering and there is no absolute golden bullet for everyone.

I hear you, and I would even advocate for you doing this if it is the simplest way, and easiest way to manage your infra. But binding ingress rules to a specific exposed port of an ingress controller is not a feature in the Kubernetes Ingress spec, unless I missed a recent change. If this is the case, I would be interested to learn how to do it with other ingress controller?
If what I'm saying is right, then it means that you hit a limitation of the ingress v1 definition.

For this reason, I'm not sure (but I cannot confirm or deny as I'm not part of the team) if the issue #5624 will be implemented or not, because it would mean adding an annotation for this, right?

I don't understand the issue? If Traefik exposes its public ports 80 and 443, and is configured with 2 entrypoints (web -> 80 and websecure -> 443 ), then the ingress rules will be matching requests incoming on both port, that is all. These concepts are Layer-4 (TCP) related, where there is NO routing. This is why you're using Ingress at Layer-7 with routing based on the HTTP protocol right?
The "ingress" from Harbor's official helm chart provides a set of rules for different HTTP: a request for the webapi of Harbor will be sent to the webapi's (Kubernetes) service as expected because the match is done with hostname AND/or URL's path, right?
Of course I might misunderstand something here, but please help me by defining exactly the challenge.

For this case, I understand the pain for you. Adding more maintenance is always annoying. This is why we tried to leverage this by publishing this tool: GitHub - traefik/traefik-migration-tool: A migration tool from Traefik v1 to Traefik v2 . In my case, I got a Kubernetes Job running daily, responsible for checking my public rules (ingresses, load balancer, DNS, etc.): I've updated it to run the traefik-migration tool and notify me with a "IngressRoute" proposal when there's a new ingress in the cluster. Hope it helps?

8

Thanks @dduportal for the very detailed answer :slight_smile:

~2/3 of my customers have 2 or more ingress controllers installed. Neither your case nor mine are representative, truth is somewhere on the middle.
Switching an Ingress controller is also upgrading to a new major version, which breaks things (Nginx 2.x will surely break annotations, HAPRoxy 2 did, Contour as well: it's a common pattern).

I do not see an upgrade as a switch, but we might disagree on that.

However: is there a particular reason to NOT stay with Traefik v1.7 if it fits your needs? This version is maintained for at least 1 year (as you can see on the recent releases of 1.7.x we do not let this version rot), and I'm sure the "ingress v2 problem" will be solved until then?

The reason is in your words. 1.7.x will be maintained for at least 1 year. After that we may or may not have to switch the controller or upgrade to Traefik 2.0 if the way it works does not change. I would rather act now and get things straight before 1.7.x is out-of-support and we suddenly use unmaintained software in production.

I feel like this stance is a threat to stop using Traefik, and might not be the most kindest way to advocate for your need on a community (explaining your use case as you did later is waaaaay better). I'm not here to say you have to stay on Traefik, but to explain why, and how to fix. Traefik is a tool with its pro and cons, and it cannot answer to everyone's contexts. If you feel that it's better for you to not switch to Traefik v2, please consider another ingress controller more suited to your need: again it's engineering and there is no absolute golden bullet for everyone.

I am sorry if you took this as a threat, it was not meant that way. It just is a thing that crossed my mind as a possible solution if things do not work out.
You cannot and do not have to answer everyones contexts. And I did not ask for that.
Traefik 1.7.x fits our use-case just fine and for us it is a great piece of software that just works perfect. But v2 is something else for us, as you can see.

I hear you, and I would even advocate for you doing this if it is the simplest way, and easiest way to manage your infra. But binding ingress rules to a specific exposed port of an ingress controller is not a feature in the Kubernetes Ingress spec, unless I missed a recent change. If this is the case, I would be interested to learn how to do it with other ingress controller?
If what I'm saying is right, then it means that you hit a limitation of the ingress v1 definition.

Maybe I was not clear enough on our use-case. So, I will try to clarify how we use Traefik and Ingress in k8s-clusters.
Traefik is setup as a ingress-controller in the cluster, running as a daemonset. It has entrypoints for http, https, ping and metrics. So, the containerports are 443 and 80 and something else for the other two.
We now build a service of type NodePort that forwards external traffic to ports 80 and 443 of Traefik.
These NodePorts are loadbalanced by HAProxy-VM's.
If I now deploy an ingress-object for www.example.com and point the DNS to the IP of HAProxy, the request will be forwarded to the NodePort of Traefik and finally to the pods of the app.
This should work with almost any ingress-controller.

For this reason, I'm not sure (but I cannot confirm or deny as I'm not part of the team) if the issue #5624 will be implemented or not, because it would mean adding an annotation for this, right?

And this use-case I described, is why our problems would be solved if Traefik 2.0 would have the default-entrypoints option Traefik 1.7.x has. We could just set this option and everything should just work as before.
This should not need any annotations, because it is an option in the config of Traefik.

Should we need more features, like ingress for tcp-services we can still use IngressRoutes for that.

But...

I don't understand the issue? If Traefik exposes its public ports 80 and 443, and is configured with 2 entrypoints (web -> 80 and websecure -> 443 ), then the ingress rules will be matching requests incoming on both port, that is all. These concepts are Layer-4 (TCP) related, where there is NO routing. This is why you're using Ingress at Layer-7 with routing based on the HTTP protocol right?
The "ingress" from Harbor's official helm chart provides a set of rules for different HTTP: a request for the webapi of Harbor will be sent to the webapi's (Kubernetes) service as expected because the match is done with hostname AND/or URL's path, right?
Of course I might misunderstand something here, but please help me by defining exactly the challenge.

We have four entrypoints configured. Web, websecure, ping and metrics. And if Traefik uses all of them a http-request will most likely end up entering the wrong one.
But maybe I misunderstood the docs and I do not need entrypoints for ping and metrics to still be able to scrape metrics and use readiness-probes.
If we do not need those, Traefik 2.0 could potentially still work for us.

9

I don't see any issue. "Entrypoints" and "Routers" are 2 different objects as you may read in Overview | Traefik | v2.0.

  • The ingress rules submitted to your cluster are converted (internally in Traefik) to routers.
  • Each of these routers is attached to all entrypoints as you saw (because these router comes from the kubernetesingress provider), because this is the default behavior of Traefik v2.
  • This the router which is responsible to match a request (or not), not the entrypoint.

It means that any request incoming on the port 443 of Traefik will enters through the entrypoint named websecure (I assume this is the port 443 for this entry point). As all your routers (from ingress rules) are attached to all entry points, then all routers will try to match the request. (If they are multiple router matching the request, the priorities of router rules allow to select only one).
This router will then treat the requests, whatever port it's coming from.

This work exactly the same as entrypoint + frontend rules with Traefik v1.7, unless you were using the annotation traefik.ingress.kubernetes.io/frontend-entry-points which I understand you did not.

So there should be no issue, except ensuring that your router rules does not conflict cluster-wide,
which would be a wise thing to check :wink: (example: if you have 2 3rd party Helm chart which bot define an ingress with no hostname and a path to /admin for instance).

Does it answer your concern?

10

I don't see any issue. "Entrypoints" and "Routers" are 2 different objects as you may read in

Thats what I understood as well.

Does it answer your concern?

What you wrote is what I understood how it should work, but it does not. But I think we are getting somewhere.

In the debug logs (which would be kind of hard to anonymize, so I cannot post them completely) I see that Traefik infact sees all ingress-objects and converts them to routers.
But: I see a lot of these messages in the debuglogs:

"No entryPoint defined for this router, using the default one(s) instead: [ping web websecure metrics]" routerName=someingress@kubernetes

Traefik also starts to add middlewares:

Creating middleware" middlewareType=Pipelining entryPointName=ping routerName=someingress@kubernetes serviceName=someservice middlewareName=pipelining

So I am guessing something is going wrong somewhere or I understood something wrong.

11

Can you provide a reproducible case please? (at least some Kubernetes YAMl description of your Traefik deployment + an exemple of an ignress) ? Without technical information, it's hard to find the issue :slight_smile:

When you say that it does not work, can you elaborate? Do you see an error when connecting to the public URL of services? what error exactly?

12

I sure can:

I deployed the following yaml to kubernetes:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: whoami
  labels:
    app: whoami
spec:
  replicas: 3
  selector:
    matchLabels:
      app: whoami
  template:
    metadata:
      labels:
        app: whoami
    spec:
      containers:
      - name: whoami
        image: jwilder/whoami
        ports:
        - containerPort: 8000
---
apiVersion: v1
kind: Service
metadata:
  name: whoami
spec:
  selector:
    app: whoami
  ports:
    - protocol: TCP
      port: 8000
      targetPort: 8000
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: test-ingress
spec:
  rules:
  - host: whoami.mydomain.com
    http:
      paths:
      - path: /
        backend:
          serviceName: whoami
          servicePort: 8000

Using Traefik 1.7.19 the name of the pod my request was served by gets displayed in the browser.
Using Traeik v2, I just get 404 page not found.

13

I have upgraded to 2.0.5 and happt. Just looking at this post. How can I expose grafana and Prometheus with Traefik 2.0.5 since those helm charts don't know about crd.

This means I have to run both 1.7 and 2.0.5

Hmmm

14

Hi @ekjuanrejon is there a specific ingress feature in Grafana and Prometheus?
I mean, we are already using both with Traefik v2 ...

15

Am using the following helm chart https://github.com/helm/charts/tree/master/stable/grafana

Which does not know about Traefik crd. Just conscious of this limitation in Traefik 2.0

16

@ekjuanrejon you should use https://github.com/containous/traefik-migration-tool to migrate your ingress to ingress route, as a lot of Traefik v2.0 are already using: it's a nice tools which check ingress yaml and generate Ingressroute yaml, adding tooltip messages when a feature need to be migrated manually.

I used it for the past 4 months, as said earlier in this topic, and it did 95% of the job: was I had to do manually was advanced features so it had to be done.

Everything is written in https://docs.traefik.io/v2.0/migration/v1-to-v2 if you want to give a reference.

17

@dduportal The ingress is not mines. I am using a feed from google

https://kubernetes-charts.storage.googleapis.com/

a lot of community based helm charts are there and most of those helm charts are not using Traefik crd. It is impossible to go an migrate all of those helm charts.

I do like Traefik 2.0 and do like the middleware and can see a lot of use cases but I also use community based helm charts. This charts are crafted by other developers.

As it stands now am forced to have two Traefik ingress controller. 1.7 and 2.0

Not sure what to do. I only want to have one ingress controller. I'll have to look at nginx and see

Traefik 2.0 is nice but does not have full support for kubernetes native ingress. there are tongs of charts out there that use kubernetes native ingress over Traefik crd. With Traefik 2.0 I am unable to use those charts :sleepy:

18

I'm sorry but I can't reproduce, can you share more details (how is Traefik v2.0 deployed? Is Traefik v1 still deployed at the same time? Can you turn Traefik v2 logs in DEBUG and share it with us?)

Here are the steps I took to have this example working:

  • Created a local Kubernetes cluster based on k3s/k3d, exposing ports 80 and 443 for the external load balancer (and no traefik v1 deployment):
k3d create --name=tls --workers=2 --publish="80:80" --publish="443:443" --server-arg="--no-deploy=traefik"
  • Deploy Traefik v2 with the following YAML (extracted from the experimental v2.0 helm chart at https://github.com/containous/traefik-helm-chart with the helm template ... command and adapted to enable the Kubernets "classic" Ingress Provider):
# traefik-ingress.yml
---
kind: Namespace
apiVersion: v1
metadata:
  name: traefik

---
# Source: traefik/templates/rbac/serviceaccount.yaml
kind: ServiceAccount
apiVersion: v1
metadata:
  name: traefik
  namespace: traefik
---
# Source: traefik/templates/crd/ingressroute.yaml
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: ingressroutes.traefik.containo.us
  namespace: traefik
spec:
  group: traefik.containo.us
  version: v1alpha1
  names:
    kind: IngressRoute
    plural: ingressroutes
    singular: ingressroute
  scope: Namespaced

---
# Source: traefik/templates/crd/ingressroutetcp.yaml
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: ingressroutetcps.traefik.containo.us
  namespace: traefik
spec:
  group: traefik.containo.us
  version: v1alpha1
  names:
    kind: IngressRouteTCP
    plural: ingressroutetcps
    singular: ingressroutetcp
  scope: Namespaced
---
# Source: traefik/templates/crd/middlewares.yaml
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: middlewares.traefik.containo.us
  namespace: traefik
spec:
  group: traefik.containo.us
  version: v1alpha1
  names:
    kind: Middleware
    plural: middlewares
    singular: middleware
  scope: Namespaced

---
# Source: traefik/templates/crd/tlsoptions.yaml
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: tlsoptions.traefik.containo.us
  namespace: traefik
spec:
  group: traefik.containo.us
  version: v1alpha1
  names:
    kind: TLSOption
    plural: tlsoptions
    singular: tlsoption
  scope: Namespaced

---
# Source: traefik/templates/rbac/clusterrole.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: traefik
  namespace: traefik
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

---
# Source: traefik/templates/rbac/clusterrolebinding.yaml
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: traefik
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: traefik
subjects:
- kind: ServiceAccount
  name: traefik
  namespace: traefik

---
# Source: traefik/templates/dashboard-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: traefik-dashboard
  namespace: traefik
  labels:
    app: traefik
    chart: "traefik-2.0.0"
    release: "release-name"
    heritage: "Tiller"
spec:
  type: ClusterIP
  selector:
    app: traefik
    release: release-name
  ports:
  - port: 80
    name: traefik
    targetPort: traefik

---
# Source: traefik/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: traefik
  namespace: traefik
  labels:
    app: traefik
    chart: "traefik-2.0.0"
    release: "release-name"
    heritage: "Tiller"
spec:
  type: LoadBalancer
  externalTrafficPolicy: Cluster
  selector:
    app: traefik
    release: release-name
  ports:
  - port: 80
    name: web
    targetPort: web
  - port: 443
    name: websecure
    targetPort: websecure

---
# Source: traefik/templates/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: traefik
  namespace: traefik
  labels:
    app: traefik
    chart: traefik-2.0.0
    release: "release-name"
    heritage: "Tiller"
spec:
  replicas: 1
  selector:
    matchLabels:
      app: traefik
      release: release-name
  template:
    metadata:
      labels:
        app: traefik
        chart: traefik-2.0.0
        release: "release-name"
        heritage: "Tiller"
    spec:
      serviceAccountName: traefik
      terminationGracePeriodSeconds: 60
      containers:
      - image: traefik:2.0.5
        name: traefik
        resources:
          limits:
            cpu: 300m
            memory: 150Mi
          requests:
            cpu: 100m
            memory: 50Mi
        readinessProbe:
          httpGet:
            path: /ping
            port: 9000
          failureThreshold: 1
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 2
        livenessProbe:
          httpGet:
            path: /ping
            port: 9000
          failureThreshold: 3
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 2
        ports:
        - name: web
          containerPort: 8000
          protocol: TCP
        - name: websecure
          containerPort: 8443
          protocol: TCP
        - name: traefik
          containerPort: 9000
          protocol: TCP
        args:
          - "--entryPoints.web.address=:8000"
          - "--entryPoints.websecure.address=:8443"
          - "--entryPoints.traefik.address=:9000"
          - "--api.dashboard=true"
          - "--api.insecure=true"
          - "--ping=true"
          - "--providers.kubernetescrd=true"
          - "--providers.kubernetesingress=true"
          - "--log.level=DEBUG"
---
# Source: traefik/templates/dashboard-hook-ingressroute.yaml
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: traefik-dashboard
  namespace: traefik
  annotations:
    helm.sh/hook: "post-install"
  labels:
    app: traefik
    chart: "traefik-2.0.0"
    release: "release-name"
    heritage: "Tiller"
spec:
  entryPoints:
    - web
  routes:
  - match: Host(`traefik.dashboard`)
    kind: Rule
    services:
    - name:  traefik-dashboard
      port: 80

  • Deploy Traefik with kubectl apply -f ./traefik-ingress.yml

  • Deploy the file you provided with kubectl apply -f ./whoami.yml

  • points the domains traefik.dashboard and whoami.mydomain.com to the external loadbalancer's IP

Then I have this:

image

or with the command line:

curl -v http://whoami.mydomain.com/
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to whoami.mydomain.com (127.0.0.1) port 80 (#0)
> GET / HTTP/1.1
> Host: whoami.mydomain.com
> User-Agent: curl/7.64.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Length: 28
< Content-Type: text/plain; charset=utf-8
< Date: Fri, 22 Nov 2019 10:18:03 GMT
< 
I'm whoami-5ff8cd9445-hws2w
* Connection #0 to host whoami.mydomain.com left intact
* Closing connection 0

=> There is definitively something in your Kubernetes setup which interacts, but it's hard to help you without more information.
Do you have another Ingress controller already installed (Traefik v1 for instance)?

19

That's fine. You used the ingressRoute

I have the following helm chart deployed. using Traefik 1.7

How can I use Traefik 2.0 with the following

20

@ekjuanrejon To use this helm chart "as it", either use IngressRoute, or do not use Traefik v2.0 :slight_smile: