Hi, I'm new to K8 and Traefik. It's supposedly supporting DevOps and it does seem like there is a lot of text to do quite simple things so far but it also basically switches manual configuration of NGINX for trusting and copy pasting yaml. However, I do have some questions:
should I switch to Traefik v2?
how do you issue Let's Encrypt certificates for the three cheeses K8 example?
from the Kubernetes website it seemed like Traefik is merely an Ingress for Kubernetes but looking at Traefik's website it isn't. It seems like Traefik is usually used with Docker directly, instead of a scheduler like K8. Is it?
given Traefik's role as Ingress for K8, if you would want to manage a node with numerous pods, for what would you use K8's API and for what Traefik's?
This community forum is specifically dedicated to Traefik, so it is not really the place to teach you about the whole stack of technologies you're mentioning.
You'd be better off posting to generic forums such as Stack Overflow for this kind of question.
However, when you do have a more precise question about Traefik itself, please do come back and post here.
from the Kubernetes website it seemed like Traefik is merely an Ingress for Kubernetes but looking at Traefik's website it isn't. It seems like Traefik is usually used with Docker directly, instead of a scheduler like K8. Is it?
TL;DR; In the context of Kubernetes, you must specify a Kubernetes "Ingress Rule" for your application. Traefik Ingress Controller watches Kubernetes API for Ingress rules, and dynamically update itself with these rules's configuration.
how do you issue Let's Encrypt certificates for the three cheeses K8 example?
If you followed my advise about using the Helm Chart for installing the Traefik Ingress Controller, then you can customize the installation through helm values, allowing to speicify the ACME/Let's Encrypt settings at installation time (chech the values acme.* in https://github.com/helm/charts/tree/master/stable/traefik#configuration).
Technically, enabling Let's Encrypt in Kubernetes with Traefik v1 requires to change the traefik.toml configuration and add it the right [acme] settings referenced in https://docs.traefik.io/v1.7/configuration/acme/. This traefik.toml is always stored as a Kubernetes ConfigMap, which you can always edit with kubectl edit configmap --namespace <namespace where you installed Traefik> <name of the configmap> if you already installed Traefik.
should I switch to Traefik v2?
I would recommend you to first get started on v1 in Kubernetes to get a better understanding of the Kubernetes ecosystem.
The v2 is in beta, and introduces breaking changes, especially by introducing an alternative to the Kubernetes Ingress Rule. Read more here: https://docs.traefik.io/v2.0/providers/kubernetes-crd/ if you are interested.
Thank you @dduportal. I will try this. I don't use the Helm chart because I use minikube and not a cloud provider that can provide an external load balancer...
I hope your answers answer the following questions as well, referring to that tutorial. Please take a look.
I really liked how simple it was to get the things done that did work, but the security features seem more difficult. There are many questions on this board about those. That's a little unnerving because it is the main reason to use Traefik with K8. But that's an aside.
From the tutorial
"Note
For this example to work you need a TLS entrypoint. You don't have to provide a TLS certificate at this point. For more details see here."
=> What am I looking at "here"?
where is the TOML?
(The TOML is thus stored as a ConfigMap in the kube-system namespace, right? Can the arguments be applied before deploying the traefik ingress or pod?)
Then, Q2; is this an alternative? Or does this "need a TLS entrypoint"?/ Or do you still not need a certificate?:
"To setup an HTTPS-protected ingress, you can leverage the TLS feature of the ingress resource."
And Q3: basic authentication is for the dashboard right or are there more things that need access protection? TLS protects the routed hosts right?
"Basic Authentication
It's possible to protect access to Traefik through basic authentication."
I tried the TLS and authentication sections but they leave the traefik dashboard a 404. I can get the dashboard without this section. However, the main point and where I want to go is, to get Let's Encrypt certification for "the 3 cheeses" (my web domains).
I don't really know the difference between the TLS and Let's Encrypt certificates because before, without K8, I always got https with Let's Encrypt and https is TLS to me.
Can Traefik automatically get LE certificates and wire the new cheese if I merely add a new deployment?
First of all, I insist on the fact that you should really use the Helm chart: as you are in a learning phase of the Kubernetes world (not Traefik as all your questions are related to pure-kubernetes concepts),
starting with the Helm chart avoid you having to understand everything at first.
I don't really get what do you mean? Traefik can run in a secure way without Kubernetes: wether you're using "Bare metal" with the binary, a Docker container on a single Docker Engine, or in Docker Swarm, or whatever other runtime system supporting Traefik, you can always enable both TLS and authentication. Do you have a specific requirements to explain here?
I'm asking this, because having to learn Kubernetes "only" for securing Traefik seems a bit overkill, so maybe I'm missing some context
"here" is a link pointing to https://docs.traefik.io/v1.7/configuration/entrypoints. I feel like this could be rephrased to make it more explicit. If you share this feeling, do not hesitate to contribute to this documentation as it is an open project, so as much yours as ours It's easy: go to the top of the page, and click on the "blue pen" icon, on the right of the title: it will redirect you to a Github web editor so you can edit the Markdown source and propose a change to the project.
You are right, there is no mention of "how/where" the TOML file should be. Another improvement point for this documentation: feel free to contribute as well, but it's dully noted
An "entrypoint" (or a "TLS entrypoint") is a pure Traefik v1.x feature. You have to define 2 entrypoints for Traefik, aka. telling Traefik to listen on the ports 80 and 443. Defining an "entrypoint" as "TLS" is telling Traefik to encrypt the HTTP communication with TLS (aka. "HTTPS") for any request incoming on this entrypoint. It is a configuration item that you shall have to specify either on the traefik.toml, either with a command line flag. You can see the reference for TOML configuration for this topic on this page: https://docs.traefik.io/v1.7/configuration/entrypoints/#tls.
With an entrypoint configured to do HTTPS (e.g. making it a "TLS entrypoint"), Traefik needs a TLS certificates for encrypting the connection. Traefik can be configured to get a collection of TLS certificates (from static files, from Let's Encrypt, etc.), and it also generates a self-signed certificate at startup, under the hood, to use as a "default" certificate.
When Traefik receives an incoming request on the "TLS entrypoint", the hostname of the request (precisely the host on the TLS handshake) is used by Traefik to determine which certificate to use, independently of the provenance of certificates. If no certificate's hostname matches the request, then Traefik uses the "default one", which is the "generated and self signed" by default.
The "TLS feature of ingress resource" is a pure Kubernetes features, that Traefik can use for retrieving TLS certificates, as an alternative to Let's Encrypt or files mounted on the pod: it is easier to manage in Kubernetes clusters. But you can use Let's Encrypt alternatively.
=> My recurrent reminder about using Traefik's Helm Chart, as it takes care all the https ("http+tls") stuff for you ,based on the installation values. It's way easier.
[/quote]
Authentication and TLS (HTTPS) are totally different things: TLS/HTTPS is about encrypting the exchanges between client and server, while "authentication" is the process of proving your identity as a client, to the server (and eventually add authorization based on this authentication).
In Traefik, Authentication can be defined globally for and endpoints, likewise TLS, as described in https://docs.traefik.io/v1.7/configuration/entrypoints/#authentication. This is what to do for the "dashboard", as the entrypoint for the dashboard (("named traefik on port 8080 by default) is also exposing Traefik's API
But you can also enable authentication per "service" (example: http://example.com should be wide open to the world, but http://example.com/admin and http://admin.example.com ask for user/password).
By the way @tmpl, if you are seeking for professional support, you might want to check https://containo.us/traefikee/, as the forum is community based, as Traefik is an Open Source project.
Thank you, I seem to be wasting your time with not using the Helm chart, that however has a [prerequisite](github helm/charts/tree/master/stable/traefik): "You are deploying the chart to a cluster with a cloud provider capable of provisioning an external load balancer (e.g. AWS or GKE)"
I started with minikube delete and then minikube start several times and I do no configuration of Traefik outside the traefik tutorial.
minikube version: v1.2.0
I do have more pods by default than the traefik tutorial though:
Since the combination doesn't seem to work, I am looking at the differences (each works separately).
The hugo example goes without an Ingress. (I think that the EXTERNAL-IP PORT(S) 80:30304/TCP is not available when the minikube Ingress addon is enabled?)
Hi @tmpl thanks for this details. Based on this screenshot, everything is good from Traefik point's of view: I see that Traefik correctly autoconfigured itself from the ingress rules: I see a couple of frontend and backends for Traefik's UI itself, which are correctly linked (as you can see the dashboard on your webbrowser), and a couple for the Hugo application you defined, which looks well: 2 servers for the 2 replicas pods, and frontend linked to the backend.
Your next step is to configure your DNS or /etc/hosts to have the domain hugo-site.minikube to the IP of the NodePort service. It looks like you already did it with traefik-ui.minikube as you can see the dashboard.
I find a log message in the K8 NGINX ingress log:
AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1.1 Safari/605.1.15" 394 0.001 [kube-system-traefik-web-ui-web] 172.17.0.9:8080 432 0.000 200 fb06b048b29e48ac3d361c3a9c66e003
I0729 11:58:50.972573 6 store.go:348] ignoring add for ingress hugo-site based on annotation kubernetes.io/ingress.class with value
but it may be me doing minikube apply -f more than once
actually, I did create -f the first time and when I indeed do $ kubectl apply -f ingress.yaml:
Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply
ingress.extensions/hugo-site configured
-> Given that the nginx version of the hugo pod is 1.16.0, and that the "HTTP/404 error" you have come from a Nginx server in version 1.15.9, then it means that:
Your configuration for the deploymeny of Hugo is not culprit
Traefik is not used for the requests from your host.
It's because the DNS in *.minikube are pointing to the external IP of the minikube VM. So the request you are trying are incoming on the port 80 of the interface eth1 of minikube's VM, which are mapped to the port 30001, associated to the service default-http-backend of type NodePort. This is not what you want obviously
=> Start by deleting the "default nginx controller" of minikube. It can work with it still installed, but let's simplify your environment for the sake of a better learning path.
=> Then, can you try the following request:
curl -v http://hugo-site.minikube: 30380
please?
As you installed Traefik as a service of type "NodePort", then Kubernetes allocated a port on the minikube's VM network interfaces (eth0, eth1 and l0 at least). This port is the public port to be used to reach the service. In the case of your Traefik installation, I see on the output of kubectl get svc --all-namespaces that you gave us earlier, that the allocated external port is 30380.
Let us know if it works with this port.
This should not be a problem as Kubernetes objects are idempotent: you did nothing wrong here.
.