Zur einfachen Installation des Kubernetes Traefik Ingress Controllers solltest Du Helm verwenden. Helm bezeichnet sich selbst als Paketmanager für Kubernetes-Anwendungen. Neben der Installation bietet Helm auch einfache Updates seiner Anwendungen. Wie auch bei kubectl brauchst Du nur die K8s-Config, um direkt loszulegen:
$ helm repo add traefik https://helm.traefik.io/traefik $ helm repo update $ helm install --create-namespace --namespace=traefik-system traefik traefik/traefik
NOTES: The ingress-traefik controller has been installed. It may take a few minutes for the LoadBalancer IP to be available. You can watch the status by running 'kubectl –namespace traefik-system get services -o wide -w traefik'
An example Ingress that makes use of the controller:
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example namespace: foo spec: ingressClassName: traefik rules: - host: www.example.com http: paths: - pathType: Prefix backend: service: name: exampleService port: number: 80 path: / # This section is only required if TLS is to be enabled for the Ingress tls: - hosts: - www.example.com secretName: example-tls
Es ist auch möglich ein Ingress per create zu erzeugen. Hier ein kleines Beispiel dazu
kubectl create ingress webserver-red --namespace red --rule 'ingress-0.training.lab/red*=webserver-red:80' --dry-run=client -o yaml
Bei einem Aufrug mit Hostname ingress-0.training.lab und path red/* gebe die Anfrage weiter an den Service mit Namen webserver-red auf Port 80 Wenn man das * hinter red/ wegläst dann wird „pathType: Exact“ gesetzt statt „pathType: Prefix“
If TLS is enabled for the Ingress, a Secret containing the certificate and key must also be provided:
k create secret tls stirlingpdf-tls --key /home/marko/Downloads/pdftools.tuxnet.lan.key --cert /home/marko/Downloads/pdftools.tuxnet.lan.crt -n stirlingpdf-testing
or
apiVersion: v1 kind: Secret metadata: name: example-tls namespace: foo data: tls.crt: <base64 encoded cert> tls.key: <base64 encoded key> type: kubernetes.io/tls
Es ist auch Möglich ein default TLS in einem TLSStore zu hinterlegen
apiVersion: traefik.io/v1alpha1
kind: TLSStore
metadata:
name: default
namespace: default
spec:
defaultCertificate:
secretName: ingress-certificate
Are you running a Gitea or Gitlab instance inside your Kubernetes cluster? And you want to reach it not only via HTTPS, but also via SSH for easier pulling and pushing?
This article describes how to setup Traefik as ingress controller to do that, using Gitea as an example.
The necessary steps are:
In case you are new to Traefik, we recently published a (German-only) introduction to Traefik.
If you installed gitea from the official helm chart, then you just need to add some lines to your values.yaml to enable the gitea-ssh service:
service: ssh: type: ClusterIP port: 22 clusterIP:
The empty clusterIP is not an error, the default for that values is none, and in this way we overwrite it and tell it to use a real ClusterIP.
After modifying the values.yaml, upgrade gitea using helm, e.g. helm upgrade gitea gitea/gitea -f values.yaml and wait for everything to fully settle. Make sure the pods are up and the service is shown:
$ kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE gitea-http ClusterIP None <none> 3000/TCP 6d3h gitea-postgresql-headless ClusterIP None <none> 5432/TCP 6d3h gitea-postgresql ClusterIP 10.62.43.161 <none> 5432/TCP 6d3h gitea-ssh ClusterIP 10.62.71.156 <none> 22/TCP 3d7h
If you want your Gitea instance to be reachable via port 22, which is the default port for SSH, you run into two problems:
First, the Traefik pods is running with low privileges, i.e. as a non-root user. That means it cannot bind to ports under 1024. That is intentional and good admin practice. Second, your kubernetes node might be using port 22 for its own SSH connection.
So, unless you have important reasons for really using port 22, the safer and easier approach is to use a free high port. In the following example we will be using 55522. See the footnote below if you really need port 22. But be warned…
In case you installed Traefik via the official helm chart, add the following section to your values.yaml file and upgrade Traefik (e.g. helm upgrade traefik traefik/traefik -f values.yaml or similar).
ports: gitea-ssh: port: 55522 expose: true
Verify that the settings are reflected in the Traefik deployment:
$ kubectl get deployment traefik -n traefik-system -o yaml [...] spec: containers: - args: - --global.checknewversion - --global.sendanonymoususage - --entrypoints.gitea-ssh.address=:55522/tcp - --entrypoints.traefik.address=:9000/tcp - --entrypoints.web.address=:8000/tcp - --entrypoints.websecure.address=:8443/tcp [...]
Kubernetes itself only offers a very limited featureset for ingresses, mainly HTTP/HTTPS. This is where Traefik shines, as it comes with its own CRDs (custom resource definitions) that can be used until the Kubernetes ApiGateway specification is stable enough. This ApiGateway is intended as a successor to ingresses and will (hopefully) be supported by all ingress controllers, while the Traefik CRDs are only working with Traefik.
The following IngressRouteTCP resource configures Traefik to forward TCP traffic that is arriving on port 55522 to the gitea-ssh service that is listening on port 22:
apiVersion: traefik.containo.us/v1alpha1 kind: IngressRouteTCP metadata: name: gitea-ssh namespace: gitea spec: entryPoints: - gitea-ssh routes: - match: HostSNI(`*`) services: - name: gitea-ssh port: 22
Side note: The HostSNI option is mandatory for an IngressRouteTCP object, even if it is completely useless in case of SSH. As SSH is not using the TLS protocol, it is not sending any SNI information. This means, that you cannot forward traffic to different recipient services depending on the hostname that is given, like you are used to with HTTP traffic (in webserver terminology this is called virtual hosts or host-based routing). In case of SSH, you need a separate port for each of your services.
As we are not using port 22, we need to configure our clients to use the correct port.
This can be done either during cloning of the repository with git or by setting the appropriate parameters in your ~/.ssh/config file.
And, of course, before you can do that, you need to add your public SSH key to your user’s profile in your Gitea instance.
For git, use the full URL that looks something like ssh:git@gitea.example.org:55522/my-gitea-user/my-repository.git: <code bash> $ git clone ssh:git@gitea.example.org:55522/my-gitea-user/my-repository.git Cloning into 'my-repository'… remote: Enumerating objects: 3, done. remote: Counting objects: 100% (3/3), done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 Receiving objects: 100% (3/3), done. </code> If you want to configure this once so you do not need to remember for each clone, add this to your ~/.ssh/config file:
Host gitea.example.org
Port 55522
Then just clone using the URL without the port number:
$ git clone git@gitea.example.org:/my-gitea-user/my-repository.git Cloning into 'my-repository'... remote: Enumerating objects: 3, done. remote: Counting objects: 100% (3/3), done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 Receiving objects: 100% (3/3), done.
Hooray, it works!
Before you go off to party and celebrate your success: In case it is not only you that will be using this gitea instance, it might make sense to distribute the SSH settings to other users. Those can easily be added to your /etc/ssh_config (or the equivalent on your operation system) via your company’s configuration management system. Ask your local IT administrator and send her my best wishes!
In case you really need Gitea to be reachable on port 22, use the following snippet for your Traefik values.yaml:
ports: gitea-ssh: port: 22 expose: true securityContext: capabilities: drop: [ALL] add: [NET_BIND_SERVICE] runAsGroup: 0 runAsNonRoot: false runAsUser: 0
And yes, this is really NOT A GOOD IDEA…
Um ein für Ingress benötigtes TLS-Zertifikat mit dem cert-manager automatisch zu erstellen, muss zunächst ein Issuer oder ClusterIssuer definiert werden. Der cert-manager stellt die Zertifikate basierend auf diesen Issuers aus.
Beispiel für einen ClusterIssuer mit Let's Encrypt:
apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: letsencrypt-prod spec: acme: server: https://acme-v02.api.letsencrypt.org/directory email: your-email@example.com privateKeySecretRef: name: letsencrypt-prod solvers: - http01: ingress: class: nginx
Sobald der ClusterIssuer vorhanden ist, kann die Ingress-Ressource so konfiguriert werden, dass sie automatisch ein Zertifikat anfordert, indem die entsprechenden Annotationen hinzugefügt werden:
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-ingress annotations: cert-manager.io/cluster-issuer: "letsencrypt-prod" spec: ingressClassName: nginx tls: - hosts: - example.com secretName: example-tls # cert-manager speichert das Zertifikat in diesem Kubernetes-Secret rules: - host: example.com http: paths: - path: / pathType: Prefix backend: service: name: example-service port: number: 80
Dank der Annotation `cert-manager.io/cluster-issuer: „letsencrypt-prod“` erkennt der cert-manager automatisch, dass ein TLS-Zertifikat benötigt wird. Er erstellt daraufhin eine `Certificate`-Ressource und kümmert sich um die Ausstellung und Erneuerung des Zertifikats. Das Zertifikat wird im angegebenen Secret (`example-tls`) gespeichert und vom Ingress-Controller für HTTPS verwendet.
Um Traefik-Ingresse in ArgoCD nicht dauerhaft als „Progressing“ angezeigt zu bekommen, folgende Values im Traefik Helm Chart setzen:
globalArguments: - "--providers.kubernetesingress.ingressendpoint.publishedservice=traefik-system/traefik"