Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- it-wiki:kubernetes:ingress-nginx-loadbalancer [2023/10/09 09:39] – marko
+++ it-wiki:kubernetes:ingress-nginx-loadbalancer [2025/02/19 13:17] (aktuell) – gelöscht marko
@@ Zeile 1: / Zeile 1: @@
-====== Kubernetes Nginx Ingress Controller ======
-===== Installation Kubernetes Nginx Ingress Controller =====
-Zur einfachen Installation des Kubernetes Nginx 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:
-<code bash>
-    $ helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
-    $ helm repo update
-    $ helm install my-ingress ingress-nginx/ingress-nginx
-</code>
-----
-NOTES:
-The ingress-nginx 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 default get services -o wide -w my-ingress-ingress-nginx-controller'
-An example Ingress that makes use of the controller:
-<code bash>
-  apiVersion: networking.k8s.io/v1
-  kind: Ingress
-  metadata:
-    name: example
-    namespace: foo
-  spec:
-    ingressClassName: nginx
-    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
-</code>
-If TLS is enabled for the Ingress, a Secret containing the certificate and key must also be provided:
-<code bash>
-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
-</code>
-or
-<code bash>
-  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
-</code>
-----
-Mit diesen Befehlen startet Helm alle nötigen Komponenten im default Namespace und gibt diesen das Label my-ingress. Für den Nginx Ingress Controller wird ein deployment, ein replicaset und ein pod erstellt. Alle http/s-Anfragen müssen an diesen pod weitergeleitet werden, damit dieser anhand von vHosts und URI-Pfaden die Anfragen sortieren kann. Dafür wurde ein service vom Typ loadbalancer erstellt, welcher auf eine öffentliche IP lauscht und den ankommenden Traffic auf den Ports 443 und 80 an unseren pod weiterleitet. Ein ähnliches Konstrukt wird auch für das default-backend angelegt, auf welche ich hier aber nicht näher eingehe. Damit Du den Überblick nicht verlierst, kannst Du Dir alle beteiligten Komponenten mit kubectl anzeigen lassen:
-<code bash>
-    $ kubectl get all -l app.kubernetes.io/instance=my-ingress
-</code>
-===== Beispielanwendungen: Apache und Nginx =====
-===== Forwarding SSH traffic inside Kubernetes using Traefik =====
-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:
-  - enable the gitea-ssh service
-  - configure Traefik to recognize and open the new ports
-  - create an ingressrouteTCP resource to tell Traefik what to do
-  - configure your client
-  - make sure everything is working
-In case you are new to Traefik, we recently published a (German-only) introduction to Traefik.
-=== enable the gitea-ssh service ===
-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:
-<code bash>
-service:
-  ssh:
-    type: ClusterIP
-    port: 22
-    clusterIP:
-</code>
-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:
-<code bash>
-$ 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
-</code>
-=== configure Traefik to recognize the gitea-ssh port ===
-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).
-<code bash>
-ports:
-  gitea-ssh:
-    port: 55522
-    expose: true
-</code>
-Verify that the settings are reflected in the Traefik deployment:
-<code bash>
-$ 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
-[...]
-</code>
-=== create an IngressRouteTCP resource ===
-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:
-<code bash>
-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
-</code>
-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.
-=== configure your client to use the proper port ===
-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:
-<code bash>
-Host gitea.example.org
-     Port 55522
-</code>
-Then just clone using the URL without the port number:
-<code bash>
-$ 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.
-</code>
-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!
-=== Footnotes ===
-In case you really need Gitea to be reachable on port 22, use the following snippet for your Traefik values.yaml:
-<code bash>
-ports:
-  gitea-ssh:
-    port: 22
-    expose: true
-securityContext:
-  capabilities:
-    drop: [ALL]
-    add: [NET_BIND_SERVICE]
-  runAsGroup: 0
-  runAsNonRoot: false
-  runAsUser: 0
-</code>
-And yes, this is really NOT A GOOD IDEA…