Global http to https redirect in v2

what did you use for a dummy service, something that takes almost no resources I presume?

It appears that you are mixing up a service and a pod. Otherwise resource usage of a service would be no concern.

A service is not live without a deployment and the subsequent running/ready pod which consumes resources, all for what should be an inconsequential config.

No, I'm not mixed up at all.

"not live"? What do you mean?

An IngressRoute won't be live unless there is a live kubernetes service (see the error I posted). A kubernetes service won't be live without a ready kubernetes deployment/pod.

In order to create a global https redirect, I need all of the above, and the running pod (that is never hit) consumes resources.

It appears that you use "live" in some colloquial meaning but you do not define what that meaning is. If you look at kubertens documentation there is no categorization of kubernetes objects or CRDs to live and not-live (except for liveness probe that only applies to pods). They either exist in the cluster or they do not.

So when you say:

A service is not live without a deployment

This is either incorrect (it's perfectly possible to create a service without a depoyment), or irrelevant (the fact that a service is not related to other kubernetes object does not matter for traefik).

So I'm asking again, what do you mean by saying that a service (or IngressRoute ) is "live"?

Ok, please provide a sample of an IngressRoute with a kubernetes service that is "registered" with kubernetes and has no errors in the log that can satisfy this global https redirect case. Can you? I do not believe you can.

Live is in referring to a liveness probe, a kubernetes term from the the deployment manifest measures a pod's state. A service is useless without a deployment, just as an IngressRoute without a service. Colloquial no, transitive, yes. A service cannot transitively be live unless it is linked to a pod that is both "ready" and "live".

Feel free to parse semantics all you like, as far as I can tell, you need all of the above to perform a global https redirect.

All I'm saying, and I feel I'm repeating myself is that you can create a service without pod or deployment, and this will be enough for the purpose of IngressRoute. The error that you cited is because you did not created the service.

No arrguments, that having a dummy service just for the purpose of pleasuring traefik seems unnescessary, the point is, it does not cost any non-trivial resources, and you do not need deployment and/or pods for that to work.

You can not. As I posted above, a service descriptor pointed at a non-existent deployment yields:

Cannot create service: service not found traefik/dummy.

Where traefik is the namespace and dummy is the non-existent deployment.

Well that must be because you need to point and IngressRoute to a service, not to a deployment, no?

IngressRoute in the above case points to a service and the service points to a non-existent deployment.

In the above case no service definition was actually given, so it's hard to reason about it. I would question why would some one point a service to a non-existent deployment.

"service not found" means that there is no service defined with that name. Please check if you have service named dummy in namespace named traefik at the point in time when you get this error message.

The entire point of this is to create a global https redirect in v2 (see the title). I wish to do so in kubernetes via config only without using additional memory or compute resources.

If you can accomplish this, please provide a working example.

If you can accomplish this, please provide a working example.

I think it's better to go the opposite way. If you have problems, please post all your relevant configs and all relevant parts of debug logs, and we can try and work through them.

My apologies for reopening an old thread, but I'm also experiencing issues when trying to set up a global https redirect using IngressRoute on Kubernetes.

I've tried to create the redirect using the following manifests:

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: http-catchall
spec:
  entryPoints:
  - web
  routes:
  - match: HostRegexp(`my.domain.*`)
    kind: Rule
    services:
    - name: traefik-redirect-dummy
      port: 80
    middlewares:
    - name: https-redirect
---
apiVersion: traefik.containo.us/v1alpha1
kind: Middleware 
metadata:
  name: https-redirect
spec:
  redirectScheme:
    scheme: https
    permanent: true
---
apiVersion: v1
kind: Service
metadata:
  name: traefik-redirect-dummy
  namespace: traefik-v2
spec:
  ports:
  - name: web
    port: 80
    protocol: TCP
    targetPort: web
  type: ClusterIP

However, this results in the traefik log being spammed with "endpoint not found" errors
time="2020-03-11T16:00:12Z" level=error msg="endpoints not found for traefik-v2/traefik-redirect-dummy" providerName=kubernetescrd ingress=http-catchall namespace=traefik-v2
I'm assuming this is because there are no pods to back up the service, I'm guessing this is what @rosskevin was talking about.
I've tried using a headless IP but then it just spams the logs with different errors.

Any advice on how this can be resolved, besides spinning up a useless pod that backs this service, as mentioned earlier in this thread?

Hi All,

Just wanted to post a solution that worked for me on k8s without having to create a "dummy" service:

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: http-catchall
spec:
  entryPoints:
  - web
  routes:
  - match: HostRegexp(`{host:.+}`)
    kind: Rule
    services:
    - kind: TraefikService
      name: noop@internal
    middlewares:
    - name: https-redirect
---
apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: https-redirect
spec:
  redirectScheme:
    scheme: https
    permanent: true

To get round the need to create a dummy service, the http-catchall ingressroute is set to point to the noop@internal service, which according to the following was "made to be used with redirect":

For reference, we're using:

  • Traefik 2.2 installed via helm
  • k8s on AWS installed via kops
  • An AWS ELB in L7 mode with TLS termination on the ELB

Just a note that the new redirection system is working on entrypoint level and creates middlewares and uses the noop service automatically behind the scenes. Your config above is not using that. (Which is fine, I'm just pointing this out to avoid possible confusion)

Can you provide an example for the new redirection in v2.2.
I have the following in my config.yml and this does not do seem to work. I am not clear on the values that need to go in redirections section. I tried all the combination and nothing seem to work. Can you please help

   entryPoints:
      http:
        address: ":80"
      https:
        address: ":443"
    providers:
      kubernetesIngress:
       ingressClass: traefik-ingress
      kubernetesCRD:
        ingressClass: traefik
    http:
      redirections:
          entryPoint:
            to: https
            scheme: https

Ingress annotation is as follows

annotations:
    kubernetes.io/ingress.class: traefik-ingress
    traefik.ingress.kubernetes.io/router.entrypoints: https
    traefik.ingress.kubernetes.io/router.tls: "true"

There should be an example under https://docs.traefik.io/v2.2/routing/entrypoints/#redirection

At appears that you have entryPoint and http at the same level in your yaml, can you doublecheck?

Thanks a lot @zespri. The issue was related to incorrect yaml configuration as you pointed out. Interestingly, I did not see any errors in logs

Traefik ignores unknown sections, since under certain scenarios they can be used for traefik unrelated purposes. I would personally prefer if traefik could issue at least a warning.