I'm learning Kubernetes and CI/CD. Minikube and Kind work well locally, but they aren't publicly reachable, so I can't easily connect an external GitHub Actions workflow or test a real deployment endpoint. Online labs provide terminals, but usually don't expose public APIs either. Cloud providers seem like the obvious next step, but I'm worried about surprise charges and having to provide a credit card. How do people practice this realistically without spending much, and is there a better approach than accepting a local-only setup?
5 Answers
You may not need external CI access at all. Install ArgoCD inside your Kind cluster and have it watch your GitOps repository. GitHub Actions can build and publish an image or update the repository, while ArgoCD pulls the changes from inside the cluster. That avoids exposing your local Kubernetes API to the internet.
For a real public endpoint, a small VPS running k3s is often simpler than jumping straight to a managed cloud cluster. The fixed monthly price makes budgeting easier, and you can run GitOps and CI/CD against an actual remote environment. For cloud providers, use free-tier resources, budget alerts, spending limits, and automated teardown with Terraform so test environments do not keep running.
It is worth learning the cloud provider's pricing, quotas, budgets, and cleanup tools instead of avoiding cloud entirely. Start with the smallest possible instance, configure alerts before deploying anything, and destroy resources when finished. Terraform makes repeatable creation and teardown much less painful.
A lightweight option is idpbuilder, which can set up a local platform with components such as Gitea and ArgoCD. It gives you a more realistic GitOps environment without paying for a managed cluster or exposing your laptop publicly.
Thanks, idpbuilder looks promising. I hadn't come across it before.
The main limitation is networking rather than Kubernetes. A local cluster cannot receive connections from an external service unless you safely expose it through port forwarding, a tunnel, or a public host. Tunneling tools can work for short experiments, but a remote VPS is usually cleaner and safer for a persistent CI endpoint. You can also host your own Git service if you want the entire workflow under your control.
Would this approach scale to many identical environments, such as a class where 30–50 students each need a temporary cluster? I’m wondering whether people automate separate VPS instances or use another setup.