End-to-End Kubernetes with Rancher, RKE2, K3s, Fleet, Longhorn, and NeuVector

Exposing SSH Services: Ingress vs. LoadBalancer

In one of the previous sections, we deployed Gitea using a Helm chart to host our application Git repository (in the local cluster). We tried to push the code, but we had an issue since the SSH service of Gitea was not exposed. The service responsible for handling SSH is the gitea-ssh service, which is of type ClusterIP:

ssh root@$WORKSPACE_PUBLIC_IP
kubectl -n gitea get svc | grep gitea.*ssh

This is what we used when initializing our repository to add a remote origin:

git remote add origin \
  git@gitea.$WORKSPACE_PUBLIC_IP.sslip.io:gitea_admin/todo-app-repository.git

Git should be able to connect to the origin, but we should expose the service to the outside world. In Kubernetes, we have 3 options to expose services:

• NodePort
• LoadBalancer
• Ingress

In this setup, HTTP will not work for Git push or pull operations because Git requires a secure, encrypted connection for these actions, which is typically provided by SSH. SSH operates over the TCP protocol (Layer 4 of the OSI model), while HTTP operates over Layer 7, designed specifically for web traffic. Kubernetes' Ingress is an application-layer (Layer 7) mechanism that handles HTTP/HTTPS traffic by routing it based on URLs, which makes it unsuitable for handling SSH traffic. On the other hand, a LoadBalancer service operates at Layer 4, forwarding raw TCP traffic directly to the internal service without "interpreting" it. Since Git uses SSH for secure communication, especially for pushing code, the SSH service must be exposed through a LoadBalancer to allow external access, which is what makes it suitable for this use case.

To do this, follow these steps to create the LoadBalancer in the local cluster:

• Click on Service Discovery and then Services.
• Select LoadBalancer as the type of Service.
• Choose gitea as the namespace.
• Choose a name for the Service, for example, gitea-ssh-loadbalancer.
• In the Service Ports