I'm learning Kubernetes and CI/CD, and I'd like to practice a realistic GitOps workflow with ArgoCD and an external CI system such as GitHub Actions. Minikube and Kind work well locally, but they're isolated, so external services can't reach them and there's no public endpoint to test against. Browser-based Kubernetes labs provide a terminal, but generally don't offer public API access either.
Cloud providers seem like the obvious next step, but they require a payment method and I'm worried about accidentally generating a large bill while experimenting. How do people usually handle this? Is there a safe way to build a realistic pipeline, or should I accept that local clusters are mostly limited to local-only practice?
5 Answers
The main limitation is networking rather than Kubernetes itself. A local cluster can work if you safely expose it through port forwarding or a tunnel, but that adds security and reliability concerns. A remote host is usually simpler for learning an externally triggered workflow. Tools such as an HTTPS tunnel can help for temporary tests, but avoid exposing the Kubernetes API directly to the internet.
A small VPS with k3s is a practical middle ground. You get a real public endpoint and a predictable monthly cost instead of potentially variable cloud charges. It’s usually quick to set up, and you can point your CI pipeline at it just like a small production environment. For safety, use firewall rules, SSH keys, minimal permissions, and delete anything you don’t need.
For a local, self-contained lab, idpbuilder is worth looking at. It can provide a Git service and ArgoCD-oriented development environment without requiring a public cloud account, which is useful for practicing the GitOps flow before moving to a real VPS or managed cluster.
You may not need external CI to practice ArgoCD. Install ArgoCD in your Kind or Minikube cluster and have it watch a GitOps repository. The CI workflow can build and publish an image, then update the manifests or image tag in Git. ArgoCD pulls those changes from the repository, so the cluster doesn’t need to be publicly reachable.
If you do use a cloud provider, start by learning its budgets, quotas, and pricing first. Set billing alerts, restrict the regions and instance types you can use, and keep the cluster small. Terraform can make teardown repeatable, but remember that deleting a cluster may leave resources such as disks, load balancers, or public IPs behind, so verify what remains afterward.
Would you normally use Terraform to create a managed cluster, or provision a VM and install k3s? I’m especially interested in making setup and teardown fast enough for short experiments.