I'm working on a Kubernetes-based application that's complex, with 38 pods and 26 persistent volumes. We've got a new customer that needs a solution to run their app in an air-gapped environment, meaning no external data transfers are allowed. They don't currently have Kubernetes set up, so I'm proposing to provide a VM image that includes K3s and our application pre-installed. All persistent data will be stored on a separate disk image mounted at /local-data. At startup, we'll ensure that all persistent volumes either connect to existing data or new ones are created.
I've confirmed that our app can run behind an ingress with a single IP, and we plan to implement redundancy through two instances across clusters. I foresee various upgrade scenarios, including those with no or new volumes. I'd appreciate any feedback on potential issues, particularly with respect to licensing or existing known challenges.
6 Answers
Have you considered using Talos Linux for this? It supports an image cache that lets you pre-download necessary images, which would suit your air-gapped needs. Upgrades can be managed by just redownloading images to your provisioning media, keeping everything in check.
This setup could be risky. Especially when it comes to air-gapped environments – they can vary widely. You might want to explore multi-tenancy options if data sovereignty is a concern. Also, relying on a single VM isn’t the best practice if backups aren't foolproof.
Our air gap means the only network access is to specific management stations. Multi-tenancy is built into our app, but I'm not sure how it fits the air-gap problem here. We have a backup plan in place, but I’m mainly focused on how to deliver the software securely.
A single VM isn’t ideal, but your geographic redundancy sounds like it can help mitigate some risks. Just keep in mind the potential issues with downtimes.
If your app isn't overly complex, have you considered using Docker Compose instead? Running Kubernetes on a single VM might not make the most sense, especially since it won’t scale much beyond the host node, which kind of defeats the purpose. But if Kubernetes fits best, I'd love to know why you think it's necessary for your use case!
Our app is really intricate with 38 pods, and management wouldn’t approve a switch to Docker since it's too big of a change for us right now.
Kubernetes has its perks beyond just scaling. It offers a unified API for components like load balancers and ingress, making management a lot smoother!
We have a similar setup where the app runs as a VM appliance with locally stored container images. For updates, you can just handle a file upload for new images and keep it simple from the CLI. It could work seamlessly for your air-gapped scenario without any issues!
Providing a VM appliance like this makes sense for your situation. There's no strict need for scaling when you're not required to upgrade constantly. Just ensure you have your backup strategies solidified.
Honestly, why use Kubernetes if all your data stays local? Upgrades may pose a challenge without proper scaling, leading to downtime. You should weigh your options here.
It's a common myth that Kubernetes is only useful for scaling. It’s about deploying a variety of services in a consistent manner, even on a single node. Plus, we run two instances to catch potential downtimes.
We have applications running in K8s elsewhere, so sticking to K8s as an appliance makes maintenance easier while meeting customer requirements.
That's a cool feature! Can the cache include OS packages, or is it just for container images?