Production-like routing for Kubernetes in Codespaces
Codespaces and Kubernetes in Codespaces
GitHub Codespaces provide a standardized development environment for all developers without having to go through the pain of setting it up on their machines. Since Codespaces are dev containers one could run them in a developer machine too. You can read more about the motivation for creating and using Codespaces here.
Most modern-day applications are not monoliths; they often consist of several services and often follows microservices architecture pattern. These services often depend on each other even in development environments. If you are up for using Codespaces and use Kubernetes for your production workload, Kubernetes in Codespaces can help you build a production-like environment that’s far easier to replicate.
Github Codespaces needs to be enabled at the organization level and is charged per hour. Read more about its billing.
Kubernetes in Codespaces runs a single node k3d cluster within a Codespace. Since k3d is merely a wrapper to run k3s, a fully conformant production-ready Kubernetes distribution, applications run on k3d would not surprise you when moved to Kubernetes in production.
Inner Development Loop (noun)
/ˈinər dəˈveləpmənt lo͞op/
The iterative process of writing, building, and debugging code that a single developer performs before sharing the code, either publically or with their team.
- getambassador.io
In a nutshell, Kubernetes in Codespaces can give you an inner loop development experience that’s very close to production.
The sample IMDB App here could help you get started with Kubernetes in Codespaces, and further experiment by onboarding a new application.
Exposing services individually
Codespaces provides a port-forwarding capability that allows developers to expose their applications to themselves, to anyone in their organization, or to the public. This is very handy when you have an application that’s running directly in the Codespaces container. The Sample IMDB application shows how Codespaces port-forwarding and k3d port-mapping can be used together to expose individual services that use a node-port.
Exposing services through a Load balancer or Ingress
In Kubernetes, most solutions either use a load balancer or an ingress to expose their services to the internet. Hence, it’s only fair to ask for a similar experience in Kubernetes in Codespaces too.
The IMDB application mentioned above has a similar situation- the UI and APIs are hosted separately and the UI expects APIs to be available at /api/ on the same host. The challenge with Codespaces is that the host address is different for different ports exposed on the same Codespace. In the below image, it can be seen that the IMDB App (API) and IMDB UI address has different host addresses.
The section Routing applications through an Ingress in the above-mentioned sample shows how this can also be implemented by using Codespaces port-forwarding, k3d port-mapping, and Kubernetes ingress together.
You could fork the code from meavk/k8s-in-codespaces-routing to try these things instantly.
The ingress is configured as usual with path-based routes. Using k3d port mapping, port 8081 from the cluster is mapped to port 80 on the load balancer. And then Codespaces port forwarding is used to expose port 8081.
