TechOps Examples

Hey — It's Govardhana MK 👋

Welcome to another technical edition.

Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.

Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.

Most browsers get you to the page. Norton Neo gets you to the answer. Magic Box understands your intent before you finish typing — no prompting, no switching apps, no copy-pasting. Built-in AI, instantly and for free. Privacy handled by Norton, by default.

Get Neo for Free

Powered by: Jobsurface.com

Browse 637 Worldwide Jobs Here →

Looking to promote your company, product, service, or event to 49,000+ Cloud Native Professionals? Let's work together. Advertise With Us

Most Kubernetes documentation assumes your cluster has internet access. Pull an image from a public registry, fetch a Helm chart, reach the Kubernetes API from anywhere. This works fine in a cloud environment with unrestricted outbound connectivity. It stops working the moment you move into a regulated industry, a government data centre, a factory floor, or any environment where outbound internet access is either prohibited or unreliable.

These constraints are not edge cases. Healthcare, defence, financial services, and industrial automation all run workloads that cannot phone home to the internet. The question is not whether Kubernetes can work in these environments, it can. But, which deployment model fits the constraint you are actually dealing with.

Let us look at the three most prominent ways to run Kubernetes in restricted and on-premises environments on AWS:

EKS Anywhere is AWS's open source distribution that lets you create and manage Kubernetes clusters on your own infrastructure, whether that is bare metal, VMware, or other supported providers. It is built on the same codebase as EKS and follows the same cluster lifecycle model, but runs entirely within your environment with no dependency on the AWS cloud at runtime. For air gapped deployments, the setup happens in two phases.

Before the cluster is created, the admin machine still has internet access. The eksctl CLI is used from this machine to pull all required container images from ECR public registries and mirror them into a local registry running inside the target environment. This local registry becomes the only image source the cluster will ever use.

Once all images are mirrored and the cluster is created, the environment is cut off from the internet entirely. From this point the admin machine, the management cluster, and the workload cluster all operate within the air gap boundary. The management cluster handles cluster lifecycle operations. The workload cluster runs application pods. When either needs a container image or any other artifact, it fetches it from the local registry, never from the internet.

The discipline required here is significant. Every image upgrade, every new application deployment, and every Kubernetes version update must go through the same mirroring process from an internet-connected machine before being brought into the air gap environment. Teams operating in these environments typically build a formal artifact pipeline that pulls approved images on a schedule, scans them, and loads them into the local registry through a one way transfer mechanism.

Mirroring Kubernetes system images handles the infrastructure layer, but application teams still need a way to package and deliver their own workloads into the air gapped cluster.

Zarf is an open source tool built specifically for this problem. It packages a complete application, container images, Helm charts, Kubernetes manifests, and any other dependencies into a single self contained archive called a Zarf package.

The package is assembled on an internet connected machine where a zarf.yml file declares everything the application needs. Zarf bundles all of it into the archive. That archive is then physically transported into the air gap environment via USB drive, secure file transfer, or whatever controlled mechanism the environment permits, and unpacked on the other side.

Talos OS is a purpose built, immutable Linux distribution designed exclusively for running Kubernetes. It has no shell, no SSH, and no package manager. All node management happens through the Talos API over a secure gRPC channel, which makes it a natural fit for air gapped environments where attack surface reduction is a hard requirement. The combination of Zarf for application delivery and Talos for node management gives air gapped teams a reproducible, auditable pipeline from image to running pod without any internet dependency at runtime.

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)