{"id":693,"date":"2026-04-15T01:17:53","date_gmt":"2026-04-15T01:17:53","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-google-distributed-cloud-air-gapped-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-distributed-hybrid-and-multicloud\/"},"modified":"2026-04-15T01:17:53","modified_gmt":"2026-04-15T01:17:53","slug":"google-cloud-google-distributed-cloud-air-gapped-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-distributed-hybrid-and-multicloud","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-google-distributed-cloud-air-gapped-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-distributed-hybrid-and-multicloud\/","title":{"rendered":"Google Cloud Google Distributed Cloud air-gapped Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Distributed, hybrid, and multicloud"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Distributed, hybrid, and multicloud<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Google Distributed Cloud air-gapped is a Google Cloud offering designed to run Google-managed Kubernetes-based infrastructure and workloads in environments that <strong>cannot maintain connectivity to Google Cloud or the public internet<\/strong>. It targets disconnected or tightly controlled networks such as defense, intelligence, regulated manufacturing, and critical infrastructure.<\/p>\n\n\n\n<p>In simple terms: <strong>it\u2019s a way to run modern containerized applications (Kubernetes) on-premises in a fully air-gapped environment<\/strong>, while still using Google Cloud\u2019s distributed cloud approach for consistent operations, security, and lifecycle management.<\/p>\n\n\n\n<p>Technically, Google Distributed Cloud air-gapped is an integrated hardware-and-software solution delivered for customer sites. It provides a Kubernetes platform (Google Kubernetes Engine technology adapted for distributed deployments) and supporting components needed to run clusters locally with offline software delivery and updates. Because it is air-gapped, many workflows you might associate with \u201ccloud\u201d (managed control planes, SaaS-based consoles, direct access to public container registries, online upgrades) must be adapted to disconnected operations.<\/p>\n\n\n\n<p><strong>What problem it solves:<\/strong> organizations want cloud-native agility (containers, GitOps, policy-as-code, SRE practices) but must meet strict requirements for network isolation, data sovereignty, and compliance. Google Distributed Cloud air-gapped helps bring those practices to disconnected sites without forcing teams to assemble and maintain everything themselves.<\/p>\n\n\n\n<blockquote>\n<p>Naming note (verify in official docs): Google has used multiple branding generations in this space (including Anthos). Today, the product family is branded <strong>Google Distributed Cloud<\/strong>, with an <strong>air-gapped<\/strong> variant for disconnected environments. If you encounter older \u201cAnthos\u201d terminology in legacy documents, treat it as historical branding and confirm the current product scope in the latest Google Cloud documentation.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Google Distributed Cloud air-gapped?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<p>Google Distributed Cloud air-gapped is intended to provide a <strong>Google Cloud\u2013aligned Kubernetes platform<\/strong> for environments where <strong>no external connectivity<\/strong> is allowed or practical\u2014while supporting enterprise-grade operational requirements such as patching, upgrades, access controls, and audited change management.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities (high-level)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Run containerized workloads on Kubernetes in an air-gapped environment.<\/li>\n<li>Provide standardized cluster lifecycle operations (provisioning, upgrades, node management) using offline procedures.<\/li>\n<li>Support enterprise operations: access control, policy enforcement, logging\/monitoring (local), and workload isolation patterns.<\/li>\n<li>Enable consistent platform practices across distributed sites (to the extent possible without internet connectivity).<\/li>\n<\/ul>\n\n\n\n<p>Because the environment is disconnected, capabilities that require SaaS endpoints or continuous cloud control-plane connectivity are typically <strong>not available<\/strong> or are provided through <strong>offline\/replicated<\/strong> mechanisms. Always verify feature availability for your specific release and configuration in official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Major components (conceptual)<\/h3>\n\n\n\n<p>Exact implementation details vary by release; confirm in current documentation. Common components in an air-gapped distributed Kubernetes platform include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Customer-site hardware footprint<\/strong>: server nodes (control plane and workers), networking, and storage integration appropriate to the validated hardware configuration for the product.<\/li>\n<li><strong>Kubernetes clusters<\/strong>: the runtime environment for workloads.<\/li>\n<li><strong>Cluster lifecycle tooling<\/strong>: installation and upgrade tooling designed for offline media and controlled change windows.<\/li>\n<li><strong>Local artifact\/image management<\/strong>: an approach for hosting container images and platform artifacts inside the air-gapped network (for example, a private registry that you operate or that is included\u2014verify what is bundled vs required).<\/li>\n<li><strong>Observability components<\/strong>: local logging\/monitoring stack or integrations to your existing on-prem tools; optional export paths if your environment supports it (verify).<\/li>\n<li><strong>Security controls<\/strong>: Kubernetes RBAC, network policies, secrets management patterns, and audit logging; integration options depend on deployment (verify).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Distributed cloud \/ on-prem managed platform<\/strong> delivered to customer sites.<\/li>\n<li>Operational model is typically <strong>appliance-like<\/strong> (hardware + software) with structured support and offline update processes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope (regional\/global\/zonal\/project-scoped, etc.)<\/h3>\n\n\n\n<p>Google Distributed Cloud air-gapped is not a typical \u201cregional managed service\u201d like GKE in Google Cloud regions. Instead, it is primarily:\n&#8211; <strong>Site-scoped \/ deployment-scoped<\/strong>: each air-gapped installation is tied to a physical location and its local networks.\n&#8211; <strong>Cluster-scoped<\/strong> for many day-to-day operations (Kubernetes clusters, namespaces, workloads).\n&#8211; Tied to a commercial agreement and support model rather than per-project enablement alone.<\/p>\n\n\n\n<p>Where Google Cloud projects, billing accounts, or organizations are involved (for procurement, support, licensing, or optional integrations), follow the official product guidance\u2014air-gapped deployments commonly require <strong>separate planning<\/strong> for identity, entitlement, and update delivery workflows.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Fit within the Google Cloud ecosystem<\/h3>\n\n\n\n<p>Google Distributed Cloud air-gapped is part of Google Cloud\u2019s <strong>Distributed, hybrid, and multicloud<\/strong> portfolio. It is intended to complement:\n&#8211; <strong>Google Kubernetes Engine (GKE)<\/strong> for connected cloud environments.\n&#8211; Google Cloud\u2019s architecture patterns (GitOps, policy-as-code, zero trust, least privilege).\n&#8211; Hybrid designs where some sites are connected and others must be fully disconnected.<\/p>\n\n\n\n<p>In practice, the air-gapped variant is used when connectivity to Google Cloud services is restricted or prohibited\u2014so you should treat it as its own operational domain with careful supply-chain and lifecycle planning.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Google Distributed Cloud air-gapped?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Modernize legacy environments<\/strong> without violating air-gap requirements.<\/li>\n<li><strong>Standardize platforms<\/strong> across multiple sites (factory floors, bases, ships, substations).<\/li>\n<li>Reduce time-to-deliver for new applications through Kubernetes and containerization\u2014without waiting for network policy changes.<\/li>\n<li>Support long-lived environments with controlled update and accreditation processes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Run <strong>Kubernetes-based workloads<\/strong> in an offline environment.<\/li>\n<li>Support distributed application patterns: local processing, local databases, and local event pipelines.<\/li>\n<li>Provide a structured Kubernetes platform lifecycle rather than a fully bespoke DIY stack.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create repeatable operational procedures for:<\/li>\n<li>Provisioning and scaling clusters.<\/li>\n<li>Applying upgrades using offline artifacts.<\/li>\n<li>Enforcing configuration baselines.<\/li>\n<li>Auditing and change management.<\/li>\n<\/ul>\n\n\n\n<p>Air-gapped operations shift complexity from \u201calways-online automation\u201d to \u201ccontrolled, offline lifecycle management,\u201d and this service is designed with that constraint in mind.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Support strict network isolation (no direct internet access).<\/li>\n<li>Help meet data residency and sovereignty requirements.<\/li>\n<li>Enable controlled software supply chain practices: validated artifacts, offline scanning, and signed approvals (your process + product capabilities; verify exact mechanisms supported).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Execute compute close to the data source to reduce latency.<\/li>\n<li>Keep mission-critical workloads operating even when external links are unavailable by design.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose Google Distributed Cloud air-gapped when:\n&#8211; You have a <strong>hard air-gap requirement<\/strong> (policy or physical) and need Kubernetes.\n&#8211; You need a <strong>repeatable platform<\/strong> across one or more disconnected sites.\n&#8211; You need supportable lifecycle and security controls without relying on public cloud control planes.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>Avoid it (or reassess) when:\n&#8211; You can meet requirements with a connected or partially connected hybrid model; the operational overhead of air-gapped is substantial.\n&#8211; Your organization is not prepared to operate:\n  &#8211; Offline artifact management (images, OS updates, cluster updates),\n  &#8211; Strict change control,\n  &#8211; On-site hardware lifecycle and spares.\n&#8211; You only need a single small Kubernetes cluster and can manage it with a simpler distribution (after reviewing support and compliance requirements).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Google Distributed Cloud air-gapped used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Defense and national security<\/li>\n<li>Critical infrastructure (energy, utilities)<\/li>\n<li>Manufacturing and industrial environments<\/li>\n<li>Healthcare (in tightly controlled environments)<\/li>\n<li>Financial services (for specific isolated zones)<\/li>\n<li>Maritime and remote operations (where connectivity is intermittent or prohibited)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering teams building standardized Kubernetes platforms.<\/li>\n<li>SRE\/operations teams managing always-on, high-assurance environments.<\/li>\n<li>Security engineering and compliance teams enforcing accreditation boundaries.<\/li>\n<li>Application teams modernizing workloads for container platforms.<\/li>\n<li>Edge\/OT (operational technology) teams integrating with factory or facility systems.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Mission applications requiring offline operation.<\/li>\n<li>Data processing at the edge: telemetry aggregation, sensor processing, anomaly detection.<\/li>\n<li>Local control systems dashboards and APIs.<\/li>\n<li>Software-defined radios \/ tactical apps (industry-specific).<\/li>\n<li>On-prem analytics where data cannot leave the site.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Disconnected site cluster<\/strong> with local storage and local load balancing.<\/li>\n<li><strong>Hub-and-spoke operations model<\/strong> where updates and approvals are staged externally then imported via offline media.<\/li>\n<li>Multi-cluster patterns for separation of duties (platform vs workloads; dev\/test vs prod) at a site.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Physically isolated networks with strict ingress\/egress controls.<\/li>\n<li>Secure facilities where removable media must follow chain-of-custody.<\/li>\n<li>Sites with limited staff where platform operations must be highly procedural.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production:<\/strong> common due to strict requirements and criticality.<\/li>\n<li><strong>Dev\/test:<\/strong> often exists but may be separate from production due to accreditation boundaries; some organizations maintain a connected dev environment and a disconnected prod environment, then promote artifacts through a controlled pipeline.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where Google Distributed Cloud air-gapped can fit well. Exact feasibility depends on your environment and supported integrations\u2014verify in official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Secure on-prem Kubernetes for classified workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Need Kubernetes for apps handling sensitive data in a disconnected enclave.<\/li>\n<li><strong>Why this fits:<\/strong> Designed for air-gapped environments with offline lifecycle operations.<\/li>\n<li><strong>Example:<\/strong> A secure facility runs mission apps and internal APIs on Kubernetes, with updates imported monthly via approved media.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Factory-floor analytics without cloud connectivity<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Plant telemetry must be processed locally; internet access is prohibited.<\/li>\n<li><strong>Why this fits:<\/strong> Local compute and container orchestration supports rapid deployment of analytics pipelines.<\/li>\n<li><strong>Example:<\/strong> Edge services aggregate sensor data, generate alerts, and store results on-prem.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Critical infrastructure operations in isolated networks<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> SCADA-adjacent environments require strict segmentation and offline operation.<\/li>\n<li><strong>Why this fits:<\/strong> Provides a standardized platform for modern dashboards and integration services.<\/li>\n<li><strong>Example:<\/strong> A utility runs an internal operational portal and data collectors in an air-gapped zone.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Distributed sites with standardized platform controls<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Many remote sites need the same baseline platform, configs, and policies.<\/li>\n<li><strong>Why this fits:<\/strong> Enables consistent Kubernetes-based deployments across sites (with procedural updates).<\/li>\n<li><strong>Example:<\/strong> A transportation organization deploys the same service stack to multiple depots.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Modernizing legacy apps in a disconnected enclave<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Legacy services must remain on-prem and isolated but need modernization.<\/li>\n<li><strong>Why this fits:<\/strong> Kubernetes provides a controlled path to containerization and incremental refactoring.<\/li>\n<li><strong>Example:<\/strong> A monolith is decomposed into services deployed in namespaces with network policies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) On-site CI runner execution in an air-gapped environment<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Builds must occur inside the enclave; external CI tools cannot connect.<\/li>\n<li><strong>Why this fits:<\/strong> Kubernetes can host runners\/build agents and internal artifact repositories.<\/li>\n<li><strong>Example:<\/strong> A Git server and CI runners build images, push to a local registry, deploy to clusters.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Offline ML inference at the edge (no external calls)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Need local inference with controlled model updates.<\/li>\n<li><strong>Why this fits:<\/strong> Containerized inference services can be deployed and scaled locally.<\/li>\n<li><strong>Example:<\/strong> Video analytics inference runs on-site; models are updated via monthly approved releases.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Local API gateway and service mesh patterns (where supported)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Microservices need traffic management and mTLS internally.<\/li>\n<li><strong>Why this fits:<\/strong> Kubernetes ecosystem supports these patterns; exact components depend on the platform bundle (verify).<\/li>\n<li><strong>Example:<\/strong> Internal services communicate over mTLS with strict policy enforcement.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Data sovereignty and residency enforcement<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Regulations require all processing and storage remain within a site.<\/li>\n<li><strong>Why this fits:<\/strong> Workloads and data remain local; egress can be strictly controlled.<\/li>\n<li><strong>Example:<\/strong> Healthcare imaging workflows process data in a restricted network without cloud access.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Resilient local operations when WAN is unavailable (by design)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Site must remain operational even if external links fail or are removed.<\/li>\n<li><strong>Why this fits:<\/strong> Air-gapped architecture assumes no reliance on external endpoints.<\/li>\n<li><strong>Example:<\/strong> A remote operations site runs scheduling and logistics apps locally 24\/7.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>Because feature sets can evolve by release, treat the list below as the <strong>core, commonly expected capabilities<\/strong> of an air-gapped distributed Kubernetes platform and verify specifics in the official Google Distributed Cloud air-gapped documentation for your version.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Air-gapped Kubernetes platform for running containers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provides Kubernetes clusters on customer-site infrastructure.<\/li>\n<li><strong>Why it matters:<\/strong> Kubernetes is the standard control plane for modern containerized workloads.<\/li>\n<li><strong>Practical benefit:<\/strong> You can deploy apps with standard Kubernetes manifests and tooling (<code>kubectl<\/code>, Helm, GitOps tooling where available).<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Public registries and SaaS endpoints are not reachable; you must manage internal image sources and dependency mirrors.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Offline installation and upgrades (controlled lifecycle)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Supports platform installation and version upgrades using offline artifact bundles and procedural steps.<\/li>\n<li><strong>Why it matters:<\/strong> Security and compliance often require controlled, auditable changes.<\/li>\n<li><strong>Practical benefit:<\/strong> Predictable maintenance windows and reduced \u201csurprise upgrades.\u201d<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Operational overhead is higher; you need rigorous release management and staging environments.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Standard Kubernetes APIs and ecosystem compatibility<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Exposes Kubernetes API server endpoints and standard resources (Deployments, Services, Ingress, etc.).<\/li>\n<li><strong>Why it matters:<\/strong> Portability of skills and manifests across environments.<\/li>\n<li><strong>Practical benefit:<\/strong> Existing Kubernetes CI\/CD patterns can be adapted to offline workflows.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Some cloud-managed add-ons may not be available; confirm supported ingress\/load-balancing and storage options for your hardware.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Workload isolation primitives<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Supports namespaces, RBAC, quotas, network segmentation patterns (for example, NetworkPolicy\u2014verify availability and CNI behavior).<\/li>\n<li><strong>Why it matters:<\/strong> Multi-tenant or multi-team clusters need boundaries.<\/li>\n<li><strong>Practical benefit:<\/strong> Reduced blast radius and improved compliance posture.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> \u201cHard\u201d multi-tenancy has nuances; you may need separate clusters for strict separation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Local observability options (monitoring\/logging)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provides ways to collect metrics and logs locally; may integrate with your on-prem SIEM\/monitoring tools.<\/li>\n<li><strong>Why it matters:<\/strong> You still need SRE-grade visibility without Cloud-hosted tools.<\/li>\n<li><strong>Practical benefit:<\/strong> Faster incident response and capacity planning in disconnected sites.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> If you cannot export telemetry externally, you must size local storage for logs\/metrics carefully.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Security hardening and controlled supply chain (process + platform)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Supports secure-by-default configuration patterns and controlled update delivery.<\/li>\n<li><strong>Why it matters:<\/strong> Air-gapped environments are often high-assurance.<\/li>\n<li><strong>Practical benefit:<\/strong> Improved consistency and auditability of platform changes.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Your organization must still run vulnerability scanning, approvals, and artifact validation; platform capabilities vary.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Role-based access control and auditability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Uses Kubernetes RBAC and audit logs; may support integration with enterprise identity providers depending on configuration (verify).<\/li>\n<li><strong>Why it matters:<\/strong> Least privilege and traceability are mandatory in regulated environments.<\/li>\n<li><strong>Practical benefit:<\/strong> Clear accountability for platform and workload changes.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Identity integration is often one of the most complex parts of air-gapped deployments.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Multi-cluster patterns (where supported)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Supports operating multiple clusters in a site for separation and lifecycle control.<\/li>\n<li><strong>Why it matters:<\/strong> You can isolate dev\/test\/prod or workloads with different accreditation requirements.<\/li>\n<li><strong>Practical benefit:<\/strong> Safer upgrades and clearer blast-radius control.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Operating multiple clusters increases operational burden (patching, monitoring, backup).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>At a high level, Google Distributed Cloud air-gapped runs Kubernetes clusters on customer-site infrastructure. Operators manage the platform from within the air-gapped network using local endpoints and offline artifacts.<\/p>\n\n\n\n<p>Key architectural ideas:\n&#8211; <strong>Control plane lives on-site<\/strong>, not in a public cloud region.\n&#8211; <strong>Workload traffic stays on-site<\/strong> unless you explicitly design controlled egress paths.\n&#8211; <strong>Artifacts (images, upgrades, dependencies)<\/strong> must be imported via offline mechanisms.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow<\/h3>\n\n\n\n<p>Typical flows in an air-gapped cluster:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Admin\/operator flow<\/strong>\n   &#8211; An admin workstation inside the enclave connects to the Kubernetes API server endpoint.\n   &#8211; Admin applies manifests, policies, and performs upgrades (following offline procedures).<\/p>\n<\/li>\n<li>\n<p><strong>Workload deployment flow<\/strong>\n   &#8211; Workloads are defined via Kubernetes manifests (Deployment, Service).\n   &#8211; Container images are pulled from an <strong>internal registry<\/strong> reachable within the enclave.\n   &#8211; Pods start on worker nodes; Services route internal traffic.<\/p>\n<\/li>\n<li>\n<p><strong>User traffic flow<\/strong>\n   &#8211; Internal clients access apps via ClusterIP\/NodePort\/Ingress\/load balancer depending on site networking design and supported features.<\/p>\n<\/li>\n<li>\n<p><strong>Observability flow<\/strong>\n   &#8211; Logs\/metrics collected locally and stored locally, or forwarded to an internal SIEM\/monitoring system.\n   &#8211; External export is generally not assumed.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<p>In disconnected environments, \u201cintegration\u201d typically means:\n&#8211; On-prem identity providers (AD\/LDAP\/OIDC proxies) if supported.\n&#8211; On-prem registries (Harbor, Artifactory, Nexus, or bundled registry\u2014verify).\n&#8211; On-prem monitoring and logging stacks.\n&#8211; External Google Cloud services are generally not directly reachable; if a controlled gateway is permitted, it must be explicitly designed and approved.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<p>Dependencies are commonly:\n&#8211; Internal DNS and NTP (time sync is critical).\n&#8211; Internal PKI or certificate authority workflows.\n&#8211; Hardware management (out-of-band management network).\n&#8211; Storage systems or local disks depending on supported CSI\/storage design.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model (typical)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Kubernetes API authentication: often client certificates and\/or an OIDC integration (deployment-specific).<\/li>\n<li>Authorization: Kubernetes RBAC.<\/li>\n<li>Workload identity: depends on platform features; in air-gapped mode, assume you manage service-to-service credentials and secrets locally unless docs specify otherwise.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model (typical)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cluster networking uses a Kubernetes CNI; ensure your IP addressing plan avoids conflicts with site networks.<\/li>\n<li>Ingress options vary; NodePort is the most universal fallback.<\/li>\n<li>North\/south exposure must be reviewed by security (firewalls, DMZ patterns, reverse proxies).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Plan for storage retention<\/strong> of logs\/metrics inside the enclave.<\/li>\n<li><strong>Plan for offline incident response<\/strong>: you may not be able to \u201cjust open a support ticket with logs attached\u201d without sanitization and approved export paths.<\/li>\n<li>Use GitOps-style desired state where feasible\u2014adapted for offline operation (for example, local Git servers and internal artifact storage).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (conceptual)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  U[Internal Users] --&gt;|HTTP\/HTTPS| EP[Site Endpoint\\n(Reverse proxy \/ Ingress \/ NodePort)]\n  EP --&gt; SVC[Kubernetes Service]\n  SVC --&gt; PODS[Workload Pods\\n(on Worker Nodes)]\n\n  ADM[Admin Workstation\\ninside air-gapped network] --&gt;|kubectl| API[Kubernetes API Server\\n(on-site Control Plane)]\n  API --&gt; PODS\n\n  REG[Internal Container Registry] --&gt;|image pull| PODS\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (site-oriented)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Enclave[\"Air-gapped Site \/ Secure Enclave\"]\n    subgraph OOB[\"Out-of-band Management Network\"]\n      BMC[BMC \/ Hardware Mgmt]\n    end\n\n    subgraph MGMT[\"Platform Management Zone\"]\n      ADMIN[Admin Workstation]\n      GIT[Internal Git Server]\n      REG[Internal Image Registry]\n      MON[Monitoring &amp; Logging\\n(SIEM\/Prometheus\/etc.)]\n      PKI[Internal PKI\/CA]\n      DNS[Internal DNS]\n      NTP[Internal NTP]\n    end\n\n    subgraph K8S[\"Google Distributed Cloud air-gapped\\nKubernetes Cluster(s)\"]\n      CP[Control Plane Nodes]\n      W1[Worker Nodes]\n      W2[Worker Nodes]\n      IN[Ingress\/Reverse Proxy\\n(or NodePort)]\n    end\n\n    USERS[Internal Applications \/ Users]\n  end\n\n  ADMIN --&gt;|kubectl \/ cluster ops| CP\n  GIT --&gt;|GitOps sync (local)| CP\n  REG --&gt;|image pulls| W1\n  REG --&gt;|image pulls| W2\n  MON --&gt;|metrics\/logs| CP\n  MON --&gt;|metrics\/logs| W1\n  MON --&gt;|metrics\/logs| W2\n  PKI --&gt;|cert issuance| CP\n  DNS --&gt; CP\n  NTP --&gt; CP\n  USERS --&gt;|HTTP\/HTTPS| IN --&gt; W1\n  USERS --&gt;|HTTP\/HTTPS| IN --&gt; W2\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<p>Because Google Distributed Cloud air-gapped is a site-installed platform, prerequisites span commercial, physical, and technical readiness. Confirm exact requirements in official docs for your release.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Account\/subscription\/project\/tenancy requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A Google Cloud organization\/billing relationship is typically required for procurement and support.<\/li>\n<li>Entitlements and licensing are governed by your agreement.<\/li>\n<li>Any optional linkage to Google Cloud projects (if supported in your deployment) must be planned with security.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>You will need a combination of:\n&#8211; <strong>Platform administrator<\/strong> access for the distributed cloud installation (site admin).\n&#8211; Kubernetes access:\n  &#8211; Cluster-admin for platform-level operations (limited to trusted operators).\n  &#8211; Namespace-scoped admin for application teams.\n&#8211; Access to internal systems:\n  &#8211; Image registry administration.\n  &#8211; Git server administration (if used).\n  &#8211; Monitoring\/logging administration.<\/p>\n\n\n\n<p>Because \u201cIAM\u201d in air-gapped is often a mix of Kubernetes RBAC + enterprise IdP integration, treat permissions design as part of the platform build.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Billing is typically contractual\/subscription-based rather than metered per API call like many Google Cloud services.<\/li>\n<li>Budget for: hardware footprint, support, spares, on-site operations, and internal dependencies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools needed (typical)<\/h3>\n\n\n\n<p>Inside the enclave, you commonly need:\n&#8211; <code>kubectl<\/code> (Kubernetes CLI)\n&#8211; A container toolchain on a build\/mirroring workstation:\n  &#8211; <code>docker<\/code> or <code>podman<\/code>\n  &#8211; <code>skopeo<\/code> (helpful for mirroring images; optional)\n&#8211; <code>openssl<\/code> and basic network troubleshooting tools (ping, curl, dig\/nslookup)\n&#8211; Any platform-specific lifecycle tooling provided by Google Distributed Cloud air-gapped (names and workflows vary\u2014use official docs for your version)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>This is <strong>site-based<\/strong>; availability is governed by where Google can deliver\/support the solution and any regulatory constraints.<\/li>\n<li>Confirm availability with Google Cloud sales\/support and official product pages.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Limits are frequently tied to:<\/li>\n<li>hardware sizing,<\/li>\n<li>validated configurations,<\/li>\n<li>maximum nodes\/clusters per deployment,<\/li>\n<li>storage throughput,<\/li>\n<li>networking constraints.<\/li>\n<li>Do not assume GKE-in-cloud quotas apply; verify air-gapped limits in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<p>In most air-gapped environments, you must provide (or integrate with):\n&#8211; Internal DNS\n&#8211; Internal NTP\n&#8211; Internal PKI\/certificate workflows (or platform-provided cert management\u2014verify)\n&#8211; Internal container registry (unless one is bundled\u2014verify)\n&#8211; Internal source control \/ artifact management (recommended)\n&#8211; A secure removable media process for importing updates and images<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Google Distributed Cloud air-gapped pricing is not typically a simple per-hour public price like standard cloud services. It is often <strong>contractual<\/strong> and may be influenced by:\n&#8211; hardware configuration,\n&#8211; support level,\n&#8211; term length,\n&#8211; number of sites,\n&#8211; included software components,\n&#8211; professional services and deployment support.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (typical\u2014verify in official pricing)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Subscription \/ annual license<\/strong> for the distributed cloud platform.<\/li>\n<li><strong>Support<\/strong> (enterprise support tiers).<\/li>\n<li><strong>Hardware<\/strong> (if provided\/required as part of the solution) and spares.<\/li>\n<li><strong>Professional services<\/strong> (planning, installation, validation, training).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Air-gapped distributed platforms typically <strong>do not<\/strong> have a free tier in the sense of \u201calways-free usage.\u201d Verify with Google Cloud.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost drivers<\/h3>\n\n\n\n<p>Direct drivers:\n&#8211; Number and size of nodes (compute, RAM) required to meet workload SLOs.\n&#8211; Storage requirements (capacity, performance, redundancy).\n&#8211; Network equipment and segmentation requirements.\n&#8211; High availability designs (more nodes, more racks, more operational overhead).<\/p>\n\n\n\n<p>Indirect\/hidden drivers (often bigger than you expect):\n&#8211; <strong>Offline artifact management<\/strong>: mirroring images, storing them, scanning them, and promoting them through environments.\n&#8211; <strong>Operational staffing<\/strong>: on-call, patch windows, compliance evidence collection.\n&#8211; <strong>Facility and physical security<\/strong>: racks, power, cooling, restricted access.\n&#8211; <strong>Backup and retention<\/strong>: on-prem backup infrastructure and media handling.\n&#8211; <strong>Staging environments<\/strong>: most regulated shops need dev\/test\/pre-prod that mirrors prod.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Air-gapped means you generally avoid internet egress charges, but you introduce:<\/li>\n<li>costs for private internal networks,<\/li>\n<li>costs for controlled gateways (if permitted),<\/li>\n<li>removable media handling and secure transport.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Storage\/compute\/API\/request pricing factors<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Unlike a pure public-cloud service, you\u2019re typically paying for platform entitlement and the infrastructure footprint. API call metering is generally not the focus.<\/li>\n<li>However, your internal dependencies (storage arrays, SIEM licensing, backup software) may add per-capacity or per-ingest charges.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost (practical)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Right-size clusters: separate platform overhead from workload requirements.<\/li>\n<li>Use namespaces and quotas effectively; avoid over-provisioning by default.<\/li>\n<li>Standardize base images and reduce image sprawl to cut registry storage and scanning costs.<\/li>\n<li>Establish clear log retention policies; high-volume logs can explode storage needs.<\/li>\n<li>Invest in automation for offline promotion to reduce labor cost and reduce error rates.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (model, not numbers)<\/h3>\n\n\n\n<p>A \u201cstarter\u201d footprint is usually bounded not by cost per hour but by minimum viable hardware and operational needs:\n&#8211; Small cluster for dev\/test within an enclave\n&#8211; Internal registry + Git server\n&#8211; Local monitoring\/logging with modest retention<\/p>\n\n\n\n<p>Because actual prices are contractual and configuration-dependent, <strong>do not<\/strong> treat any internet-sourced numbers as authoritative. Build a bill-of-materials style estimate and validate with Google Cloud and your procurement team.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations (what to include)<\/h3>\n\n\n\n<p>For production, include:\n&#8211; HA control plane and sufficient worker redundancy (N+1 or more).\n&#8211; Backup\/restore infrastructure and procedures.\n&#8211; Dedicated staging environment for upgrades.\n&#8211; Security tooling: scanning, auditing, privileged access management.\n&#8211; Spares and replacement parts.\n&#8211; Staff time for patching, evidence capture, and incident response.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Official pricing links<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud pricing landing: https:\/\/cloud.google.com\/pricing<\/li>\n<li>Google Distributed Cloud pages (start here and navigate to pricing for your product): https:\/\/cloud.google.com\/distributed-cloud<\/li>\n<li>Pricing details for the air-gapped variant may be contract-specific; confirm with your Google Cloud representative and official documentation for your region and edition.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab is designed to be <strong>realistic and executable<\/strong> if you have access to a Google Distributed Cloud air-gapped environment (or a training environment that simulates one). It focuses on what most teams must do early: verify cluster access, prepare an internal image flow, deploy a simple app, and validate service reachability\u2014without assuming internet access.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Deploy and validate a small \u201cHello from the enclave\u201d web application on a Kubernetes cluster running on Google Distributed Cloud air-gapped, using an <strong>internal container image registry<\/strong> and standard Kubernetes manifests.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Verify you can reach the Kubernetes API server from an admin workstation.\n2. Create a namespace and basic RBAC boundaries (minimal example).\n3. Ensure a container image is available inside the enclave (mirror\/import).\n4. Deploy the application and expose it internally.\n5. Validate access and review logs\/events.\n6. Clean up resources.<\/p>\n\n\n\n<blockquote>\n<p>Assumptions (adapt as needed):\n&#8211; You have a kubeconfig file and credentials to access the cluster.\n&#8211; You have an internal container registry reachable from cluster nodes, or a documented platform-provided registry. If not, work with your platform team to establish one.\n&#8211; You have a workstation inside the air-gapped network with <code>kubectl<\/code> installed.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Confirm access to the cluster (kubeconfig + connectivity)<\/h3>\n\n\n\n<p><strong>1.1 Check <code>kubectl<\/code> is installed<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl version --client\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> <code>kubectl<\/code> prints a client version.<\/p>\n\n\n\n<p><strong>1.2 Point to the kubeconfig<\/strong>\nIf your platform team provided a kubeconfig file path:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export KUBECONFIG=\"$HOME\/kubeconfig-gdc-airgapped\"\n<\/code><\/pre>\n\n\n\n<p><strong>1.3 Verify cluster connectivity<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl cluster-info\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You see the Kubernetes control plane endpoint and basic service endpoints.<\/p>\n\n\n\n<p><strong>1.4 Verify your permissions<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl auth can-i '*' '*' --all-namespaces\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong><br\/>\n&#8211; Platform admins may see <code>yes<\/code>.<br\/>\n&#8211; App operators should not have full privileges; that\u2019s okay. If you get <code>no<\/code>, continue but adjust RBAC steps accordingly.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create a namespace and minimal RBAC (application boundary)<\/h3>\n\n\n\n<p>This step demonstrates how to create a dedicated namespace for a workload and grant a specific user\/group permissions. In air-gapped environments, separation of duties is important for audits.<\/p>\n\n\n\n<p><strong>2.1 Create a namespace<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl create namespace hello-airgap\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Namespace created.<\/p>\n\n\n\n<p><strong>2.2 (Optional) Apply a ResourceQuota<\/strong>\nThis prevents runaway usage. Adjust values for your environment.<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl -n hello-airgap apply -f - &lt;&lt;'EOF'\napiVersion: v1\nkind: ResourceQuota\nmetadata:\n  name: rq-basic\nspec:\n  hard:\n    requests.cpu: \"500m\"\n    requests.memory: \"512Mi\"\n    limits.cpu: \"1\"\n    limits.memory: \"1Gi\"\n    pods: \"10\"\nEOF\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> ResourceQuota created.<\/p>\n\n\n\n<p><strong>2.3 (Optional) Create a Role and RoleBinding<\/strong>\nIf your cluster uses an identity integration, replace the <code>subject<\/code> with the correct user\/group. If you are not sure what identity string to use, skip this and rely on existing access.<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl -n hello-airgap apply -f - &lt;&lt;'EOF'\napiVersion: rbac.authorization.k8s.io\/v1\nkind: Role\nmetadata:\n  name: hello-deployer\nrules:\n- apiGroups: [\"\", \"apps\"]\n  resources: [\"pods\", \"services\", \"configmaps\", \"events\", \"deployments\", \"replicasets\"]\n  verbs: [\"get\", \"list\", \"watch\", \"create\", \"update\", \"patch\", \"delete\"]\nEOF\n<\/code><\/pre>\n\n\n\n<p>Now bind it to a subject (example uses a user string; adjust):<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl -n hello-airgap apply -f - &lt;&lt;'EOF'\napiVersion: rbac.authorization.k8s.io\/v1\nkind: RoleBinding\nmetadata:\n  name: hello-deployer-binding\nsubjects:\n- kind: User\n  name: \"your.user@yourdomain.example\"\n  apiGroup: rbac.authorization.k8s.io\nroleRef:\n  kind: Role\n  name: hello-deployer\n  apiGroup: rbac.authorization.k8s.io\nEOF\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Role and RoleBinding created (or you adjust based on your IdP setup).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Make a container image available inside the air-gapped network<\/h3>\n\n\n\n<p>In an air-gapped setup, Kubernetes nodes <strong>cannot pull images from public registries<\/strong>. You must mirror or import images into an internal registry.<\/p>\n\n\n\n<p>There are multiple approved patterns. Choose the one your security and platform governance allow.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Option A (common): Mirror via a controlled \u201cbridge\u201d process (recommended pattern)<\/h4>\n\n\n\n<p>A connected staging environment downloads the image, scans it, then exports it as a tarball to approved media. Inside the enclave, you import it to the internal registry.<\/p>\n\n\n\n<p><strong>3A.1 On a connected workstation (outside the air gap), pull and save the image<\/strong>\nUse a simple image. For example, <code>nginx<\/code>. (Your org may require a hardened base image instead.)<\/p>\n\n\n\n<pre><code class=\"language-bash\">docker pull nginx:1.27\ndocker save nginx:1.27 -o nginx_1.27.tar\n<\/code><\/pre>\n\n\n\n<p><strong>3A.2 Transfer <code>nginx_1.27.tar<\/code> to the enclave using approved procedures<\/strong>\nFollow your organization\u2019s removable media and chain-of-custody policy.<\/p>\n\n\n\n<p><strong>3A.3 Inside the enclave, load and push to your internal registry<\/strong>\nAssume your internal registry is <code>registry.infra.local<\/code> and you have a project\/repo <code>library<\/code>.<\/p>\n\n\n\n<pre><code class=\"language-bash\">docker load -i nginx_1.27.tar\ndocker tag nginx:1.27 registry.infra.local\/library\/nginx:1.27\ndocker push registry.infra.local\/library\/nginx:1.27\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Image exists in the internal registry and is pullable from cluster nodes.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Option B: Build the image entirely inside the enclave<\/h4>\n\n\n\n<p>If you have a local build pipeline and base images already mirrored, you can build and push without any external pulls. This is often preferred for high-assurance environments.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Deploy the application (Deployment + Service)<\/h3>\n\n\n\n<p>Now deploy an NGINX pod and expose it via a Service.<\/p>\n\n\n\n<p><strong>4.1 Create a Deployment<\/strong>\nReplace the image name with your internal registry image from Step 3.<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl -n hello-airgap apply -f - &lt;&lt;'EOF'\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: hello-web\nspec:\n  replicas: 2\n  selector:\n    matchLabels:\n      app: hello-web\n  template:\n    metadata:\n      labels:\n        app: hello-web\n    spec:\n      containers:\n      - name: nginx\n        image: registry.infra.local\/library\/nginx:1.27\n        ports:\n        - containerPort: 80\n        resources:\n          requests:\n            cpu: 50m\n            memory: 64Mi\n          limits:\n            cpu: 200m\n            memory: 256Mi\nEOF\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Deployment created.<\/p>\n\n\n\n<p><strong>4.2 Watch pods come up<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl -n hello-airgap get pods -w\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Two pods reach <code>Running<\/code>. If they get stuck in <code>ImagePullBackOff<\/code>, go to Troubleshooting.<\/p>\n\n\n\n<p><strong>4.3 Create a Service<\/strong>\nUse ClusterIP first (works everywhere).<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl -n hello-airgap apply -f - &lt;&lt;'EOF'\napiVersion: v1\nkind: Service\nmetadata:\n  name: hello-web-svc\nspec:\n  selector:\n    app: hello-web\n  ports:\n  - name: http\n    port: 80\n    targetPort: 80\n  type: ClusterIP\nEOF\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Service created.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Validate access (port-forward + internal reachability)<\/h3>\n\n\n\n<p><strong>5.1 Port-forward from your workstation<\/strong>\nThis avoids assumptions about ingress\/load balancers.<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl -n hello-airgap port-forward svc\/hello-web-svc 8080:80\n<\/code><\/pre>\n\n\n\n<p>In a second terminal:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -I http:\/\/127.0.0.1:8080\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You receive an HTTP response header like <code>HTTP\/1.1 200 OK<\/code>.<\/p>\n\n\n\n<p><strong>5.2 Check workload logs<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl -n hello-airgap logs deploy\/hello-web --tail=50\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> NGINX access logs appear when you curl.<\/p>\n\n\n\n<p><strong>5.3 Check events (useful in air-gapped debugging)<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl -n hello-airgap get events --sort-by=.metadata.creationTimestamp | tail -n 20\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Events show scheduling, pulling image from internal registry, and container start.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>kubectl cluster-info<\/code> works from the admin workstation.<\/li>\n<li>Pods are <code>Running<\/code> and replicas match desired count:\n  <code>bash\n  kubectl -n hello-airgap get deploy,po<\/code><\/li>\n<li>Service exists:\n  <code>bash\n  kubectl -n hello-airgap get svc hello-web-svc<\/code><\/li>\n<li>Port-forward and curl succeed.<\/li>\n<\/ul>\n\n\n\n<p>If all pass, you\u2019ve validated the critical basics: control-plane access, namespace boundary, internal image supply, and workload scheduling.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues in Google Distributed Cloud air-gapped environments (and what to check):<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong><code>ImagePullBackOff<\/code> \/ <code>ErrImagePull<\/code><\/strong>\n   &#8211; Confirm the image URL is correct and reachable inside the enclave.\n   &#8211; Confirm registry DNS resolves from nodes.\n   &#8211; Confirm registry TLS certs are trusted by nodes (common issue).\n   &#8211; Check pod events:\n     <code>bash\n     kubectl -n hello-airgap describe pod &lt;pod-name&gt;<\/code>\n   &#8211; If registry requires auth, ensure an <code>imagePullSecret<\/code> is configured for the namespace\/service account (your platform team should provide the standard approach).<\/p>\n<\/li>\n<li>\n<p><strong><code>kubectl<\/code> cannot connect \/ timeout<\/strong>\n   &#8211; Validate you are on the correct network segment and firewall rules allow access to the API server endpoint\/port.\n   &#8211; Confirm your kubeconfig server address is correct.\n   &#8211; Confirm your workstation has proper DNS\/NTP (time skew can break TLS).<\/p>\n<\/li>\n<li>\n<p><strong>Pods stuck in <code>Pending<\/code><\/strong>\n   &#8211; Check node readiness:\n     <code>bash\n     kubectl get nodes<\/code>\n   &#8211; Check resource pressure and quotas:\n     <code>bash\n     kubectl -n hello-airgap describe resourcequota rq-basic<\/code>\n   &#8211; Check taints\/tolerations (platform nodes may be tainted).<\/p>\n<\/li>\n<li>\n<p><strong>Port-forward works but internal clients can\u2019t reach the app<\/strong>\n   &#8211; That\u2019s expected if you haven\u2019t configured NodePort\/Ingress\/LoadBalancer for site access.\n   &#8211; Work with your platform networking design to expose the service appropriately.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>Delete the namespace (removes everything created inside it):<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl delete namespace hello-airgap\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Namespace terminates and resources are removed.<\/p>\n\n\n\n<p>If deletion hangs, check for finalizers on resources (rare for this simple lab). Use:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl get namespace hello-airgap -o jsonpath='{.spec.finalizers}'\n<\/code><\/pre>\n\n\n\n<p>Only remove finalizers if you understand why they exist and you have approval.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Design for offline-first<\/strong>: assume no external dependencies at runtime\u2014no external DNS, no public container registry, no SaaS auth callbacks.<\/li>\n<li><strong>Separate clusters by accreditation boundary<\/strong>: when compliance requires strong separation, prefer separate clusters over \u201csoft\u201d multi-tenancy.<\/li>\n<li><strong>Use staged environments<\/strong> (dev\/test\/pre-prod\/prod) even if minimal. Air-gapped upgrades should be rehearsed.<\/li>\n<li><strong>Standardize the platform blueprint<\/strong> across sites: IP plans, DNS patterns, registry naming, namespaces, quotas.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>least privilege<\/strong> via Kubernetes RBAC:<\/li>\n<li>cluster-admin limited to platform\/SRE operators<\/li>\n<li>namespace admin for app teams<\/li>\n<li>read-only roles for auditors\/incident responders<\/li>\n<li>Prefer <strong>group-based bindings<\/strong> (from your enterprise IdP) over individual users (where supported).<\/li>\n<li>Enforce <strong>separation of duties<\/strong>: image promotion and scanning should not be controlled solely by app developers.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Control image sprawl: set image retention policies in your internal registry.<\/li>\n<li>Set log retention to match compliance needs\u2014avoid \u201cretain forever\u201d unless required.<\/li>\n<li>Right-size nodes and avoid excessive reservations; use requests\/limits and quotas.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep container images small and standardized; reduces import\/mirroring overhead and startup time.<\/li>\n<li>Use node affinity\/anti-affinity for critical workloads to spread replicas.<\/li>\n<li>Test storage performance and tune requests\/limits for I\/O-heavy workloads.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Define SLOs and error budgets even in air-gapped environments.<\/li>\n<li>Run multiple replicas for critical services and test failure modes (node loss, storage degradation).<\/li>\n<li>Implement backup\/restore procedures for:<\/li>\n<li>application data,<\/li>\n<li>cluster configuration,<\/li>\n<li>internal registries and Git servers.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Treat upgrades as releases:<\/li>\n<li>document procedures,<\/li>\n<li>capture evidence,<\/li>\n<li>maintain rollback plans.<\/li>\n<li>Maintain an internal runbook library:<\/li>\n<li>cluster access procedures,<\/li>\n<li>certificate rotation,<\/li>\n<li>registry incident response,<\/li>\n<li>node replacement workflow.<\/li>\n<li>Plan spare capacity and hardware replacement timelines.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use consistent naming for:<\/li>\n<li>clusters (site + environment + purpose),<\/li>\n<li>namespaces (team + app),<\/li>\n<li>registries\/repos (org + app + environment),<\/li>\n<li>labels\/annotations for ownership and cost allocation.<\/li>\n<li>Record ownership metadata in labels:<\/li>\n<li><code>owner<\/code>, <code>cost-center<\/code>, <code>data-classification<\/code>, <code>env<\/code>.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<p>Air-gapped does not automatically mean \u201csecure.\u201d It changes the threat model and raises the importance of supply chain and insider risk controls.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Kubernetes RBAC is central. Keep RBAC simple and auditable.<\/li>\n<li>Cluster authentication methods vary; common approaches include client certs and\/or OIDC integration with an enterprise IdP (verify what\u2019s supported and recommended for your release).<\/li>\n<li>Require MFA for operator access to jump hosts and admin workstations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>In transit:<\/strong> Use TLS for Kubernetes API and internal service communication where possible.<\/li>\n<li><strong>At rest:<\/strong> Ensure encryption is configured for:<\/li>\n<li>etcd (Kubernetes state),<\/li>\n<li>persistent volumes,<\/li>\n<li>internal registry storage,<\/li>\n<li>backups.\nExact mechanisms depend on platform and storage choice\u2014verify supported configurations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Minimize north\/south exposure:<\/li>\n<li>Avoid exposing Kubernetes API beyond operator networks.<\/li>\n<li>Keep management endpoints on management VLANs.<\/li>\n<li>Use internal firewalls and segmentation:<\/li>\n<li>management zone vs workload zone vs user zone vs storage networks.<\/li>\n<li>Prefer explicit allowlists.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Don\u2019t store secrets in plain text in Git.<\/li>\n<li>Use Kubernetes Secrets carefully:<\/li>\n<li>restrict RBAC access,<\/li>\n<li>rotate regularly,<\/li>\n<li>consider envelope encryption if supported in your configuration.<\/li>\n<li>For high-assurance environments, integrate with an on-prem secrets manager (HashiCorp Vault or equivalent) if policy requires\u2014verify integration patterns.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable Kubernetes audit logging (where supported\/configured).<\/li>\n<li>Forward logs to your internal SIEM if required.<\/li>\n<li>Protect logs: they are sensitive and often include metadata useful to attackers.<\/li>\n<li>Maintain evidence for:<\/li>\n<li>change approvals,<\/li>\n<li>upgrade actions,<\/li>\n<li>privileged access.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Air-gapped deployments often operate under formal accreditation:<\/li>\n<li>change windows,<\/li>\n<li>vulnerability scanning reports,<\/li>\n<li>patch provenance and approval,<\/li>\n<li>software bill of materials (SBOM) practices (organizational).<\/li>\n<li>Align platform operations with frameworks such as NIST 800-53 or ISO 27001 depending on your compliance landscape.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Allowing developers to import arbitrary container images without scanning\/approval.<\/li>\n<li>Weak controls on removable media used for offline transfers.<\/li>\n<li>Overusing <code>cluster-admin<\/code> and sharing admin kubeconfigs.<\/li>\n<li>Not monitoring internal lateral movement because \u201cthere is no internet.\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Establish a <strong>software supply chain pipeline<\/strong>:<\/li>\n<li>mirror \u2192 scan \u2192 sign\/approve \u2192 import \u2192 deploy.<\/li>\n<li>Use hardened base images and reduce the number of approved images.<\/li>\n<li>Maintain a certificate lifecycle plan (rotation cadence, emergency replacement).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>The air-gapped requirement creates real constraints. Plan for them explicitly.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations (typical)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>No direct access to public container registries, public package repos, or SaaS APIs.<\/li>\n<li>Upgrades require offline artifact handling and often more operator time.<\/li>\n<li>Some managed-cloud conveniences may not be available (depending on the product design and your configuration).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas and capacity constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Capacity is bounded by on-site hardware.<\/li>\n<li>Scaling requires procurement and physical deployment lead time.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regional\/site constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Support and delivery may be limited by geography, regulation, and facility requirements.<\/li>\n<li>Some environments require certified hardware baselines.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Indirect cost can exceed platform subscription:<\/li>\n<li>staffing,<\/li>\n<li>compliance evidence collection,<\/li>\n<li>internal tooling (registry, scanning, SIEM),<\/li>\n<li>backup infrastructure.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Kubernetes ecosystem tools often assume internet access (Helm charts pulling from public repos, images from Docker Hub, external auth callbacks).<\/li>\n<li>You must host:<\/li>\n<li>chart repositories internally (or vendor them into Git),<\/li>\n<li>image registries internally,<\/li>\n<li>dependencies internally.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Time sync (NTP) is critical; certificate validation failures can look like random outages.<\/li>\n<li>Internal DNS issues can break clusters and registries quickly.<\/li>\n<li>Registry TLS trust is a common pain point; standardize internal CAs and distribution.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>\u201cLift and shift\u201d from connected Kubernetes often fails due to:<\/li>\n<li>hidden external dependencies (telemetry exporters, license checks),<\/li>\n<li>external OAuth flows,<\/li>\n<li>public images.<\/li>\n<li>Build a dependency inventory before migration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Vendor-specific nuances<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Distributed Cloud air-gapped is not the same as:<\/li>\n<li>GKE in Google Cloud regions,<\/li>\n<li>generic upstream Kubernetes,<\/li>\n<li>other clouds\u2019 on-prem appliances.\nRead the specific product documentation and validated hardware\/software lists carefully.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>This section compares Google Distributed Cloud air-gapped with nearby options. Availability and capabilities change; verify with official docs and vendor materials.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Key comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Google Distributed Cloud air-gapped<\/strong><\/td>\n<td>Fully disconnected environments needing a supported Kubernetes platform<\/td>\n<td>Designed for air-gapped ops; Google Cloud alignment; structured lifecycle<\/td>\n<td>Higher operational overhead; requires offline supply chain; hardware footprint<\/td>\n<td>When policy requires strict air gap and you want a supported distributed Kubernetes platform<\/td>\n<\/tr>\n<tr>\n<td>Google Distributed Cloud (connected variants)<\/td>\n<td>Hybrid sites with controlled connectivity<\/td>\n<td>More integration with Google Cloud management\/telemetry (where supported)<\/td>\n<td>Not suitable for strict air-gap requirements<\/td>\n<td>When you can allow connectivity and want centralized fleet operations<\/td>\n<\/tr>\n<tr>\n<td>GKE (Google Cloud regions)<\/td>\n<td>Cloud-native workloads in Google Cloud<\/td>\n<td>Fully managed control plane; elastic scaling; rich integrations<\/td>\n<td>Not on-prem; not air-gapped<\/td>\n<td>When workloads can run in public cloud regions<\/td>\n<\/tr>\n<tr>\n<td>Red Hat OpenShift (self-managed)<\/td>\n<td>Enterprises wanting a mature Kubernetes distribution on-prem<\/td>\n<td>Strong ecosystem; many operators; flexible deployments<\/td>\n<td>You manage lifecycle; air-gapped still complex<\/td>\n<td>When you want a vendor distribution with broad enterprise adoption and can manage it yourself<\/td>\n<\/tr>\n<tr>\n<td>Rancher (SUSE) \/ RKE2 \/ K3s<\/td>\n<td>Lightweight or multi-cluster management<\/td>\n<td>Flexible; can be air-gapped with effort<\/td>\n<td>DIY integration; support depends on contracts<\/td>\n<td>When you need flexibility and can own more of the platform engineering burden<\/td>\n<\/tr>\n<tr>\n<td>VMware Tanzu (self-managed)<\/td>\n<td>VMware-centric data centers<\/td>\n<td>Integration with VMware stack<\/td>\n<td>Still requires connectivity planning; licensing complexity<\/td>\n<td>When you are standardized on VMware and prefer VMware-native operations<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Outposts<\/strong><\/td>\n<td>AWS-consistent services on-prem (not fully air-gapped by default)<\/td>\n<td>AWS service consistency<\/td>\n<td>Typically expects connectivity to AWS; air-gap may not be supported<\/td>\n<td>When you want AWS hybrid and connectivity is allowed<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Stack Hub \/ Azure Stack Edge<\/strong><\/td>\n<td>Azure hybrid\/edge patterns<\/td>\n<td>Azure ecosystem integration<\/td>\n<td>Capabilities and connectivity assumptions vary by product<\/td>\n<td>When you want Azure-aligned edge\/on-prem solutions<\/td>\n<\/tr>\n<tr>\n<td>Upstream Kubernetes (kubeadm)<\/td>\n<td>Teams with strong Kubernetes expertise<\/td>\n<td>Maximum control; no vendor lock<\/td>\n<td>Highest DIY burden; compliance burden on you<\/td>\n<td>When you need full control and can staff platform engineering and security deeply<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example (regulated critical infrastructure operator)<\/h3>\n\n\n\n<p><strong>Problem<\/strong>\nA critical infrastructure operator must run operational dashboards, alerting, and local data processing in a network zone that is physically and logically disconnected from the internet. The environment has strict audit requirements, controlled change windows, and long hardware lifecycles.<\/p>\n\n\n\n<p><strong>Proposed architecture<\/strong>\n&#8211; Google Distributed Cloud air-gapped Kubernetes cluster at each site.\n&#8211; Internal container registry with a formal mirror\/scan\/approve\/import pipeline.\n&#8211; Internal Git server hosting:\n  &#8211; Kubernetes manifests,\n  &#8211; Helm charts vendored internally,\n  &#8211; policy configurations.\n&#8211; Local monitoring\/logging stack integrated with internal SIEM.\n&#8211; Strict network segmentation:\n  &#8211; management VLAN for operators,\n  &#8211; workload VLAN for services,\n  &#8211; restricted user access via internal reverse proxy.<\/p>\n\n\n\n<p><strong>Why this service was chosen<\/strong>\n&#8211; Air-gapped requirement is non-negotiable.\n&#8211; Need a supported Kubernetes platform with structured lifecycle management rather than an entirely bespoke build.<\/p>\n\n\n\n<p><strong>Expected outcomes<\/strong>\n&#8211; Standardized deployment model across sites.\n&#8211; Reduced time to deploy updates (within change windows) due to containerization and automation.\n&#8211; Improved audit posture with consistent RBAC and deployment pipelines.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example (R&amp;D lab with disconnected prototype environment)<\/h3>\n\n\n\n<p><strong>Problem<\/strong>\nA small robotics R&amp;D team operates a secure lab network isolated from the corporate network. They need to run microservices for telemetry, UI dashboards, and local inference. They also need repeatability as they scale to multiple lab pods.<\/p>\n\n\n\n<p><strong>Proposed architecture<\/strong>\n&#8211; One Google Distributed Cloud air-gapped cluster per lab pod.\n&#8211; Internal registry running on modest hardware.\n&#8211; GitOps-style workflow using an internal Git server.\n&#8211; Minimal ingress exposure; primarily internal-only access, plus port-forward for debugging.<\/p>\n\n\n\n<p><strong>Why this service was chosen<\/strong>\n&#8211; They need Kubernetes in an offline lab with a supportable platform baseline.\n&#8211; They want to reuse patterns later in more controlled production environments.<\/p>\n\n\n\n<p><strong>Expected outcomes<\/strong>\n&#8211; Consistent developer experience across lab pods.\n&#8211; Faster iteration without breaking air-gap policy.\n&#8211; Clear path to scaling the lab environment with repeatable procedures.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Is Google Distributed Cloud air-gapped the same as GKE?<\/strong><br\/>\n   It uses Kubernetes and aligns with Google Cloud\u2019s Kubernetes approach, but it is not the same as running GKE in Google Cloud regions. The air-gapped variant is designed for disconnected sites with local control planes and offline operations.<\/p>\n<\/li>\n<li>\n<p><strong>Does Google Distributed Cloud air-gapped require an internet connection?<\/strong><br\/>\n   It is designed specifically for environments without internet connectivity. However, installation, support, and update logistics still require a defined offline process. Verify exact connectivity assumptions in official docs.<\/p>\n<\/li>\n<li>\n<p><strong>How do I pull container images without internet access?<\/strong><br\/>\n   Use an internal registry. Mirror\/import images through an approved process (download \u2192 scan \u2192 transfer \u2192 push internally). The tutorial above shows a basic pattern.<\/p>\n<\/li>\n<li>\n<p><strong>Can I use Helm charts in an air-gapped environment?<\/strong><br\/>\n   Yes, but you must host chart repositories internally or vendor charts into your internal Git repo, and ensure all referenced images are available internally.<\/p>\n<\/li>\n<li>\n<p><strong>How are upgrades handled?<\/strong><br\/>\n   Upgrades typically require offline artifact bundles and controlled maintenance windows. The exact upgrade tooling and steps are version-specific\u2014follow the official documentation for your release.<\/p>\n<\/li>\n<li>\n<p><strong>Can I use Cloud Monitoring and Cloud Logging?<\/strong><br\/>\n   In a strict air-gapped deployment, direct integration to Google Cloud SaaS endpoints is generally not possible. You\u2019ll usually run local observability tooling. If your environment allows controlled connectivity, check official docs for supported integration models.<\/p>\n<\/li>\n<li>\n<p><strong>What skills do operators need?<\/strong><br\/>\n   Kubernetes administration, Linux basics, networking, PKI\/certificates, and strong operational discipline for offline change management.<\/p>\n<\/li>\n<li>\n<p><strong>What are the biggest operational risks?<\/strong><br\/>\n   Supply chain process failures (importing unscanned images), certificate\/time sync issues, and insufficient staging\/testing for upgrades.<\/p>\n<\/li>\n<li>\n<p><strong>Can multiple teams share a cluster?<\/strong><br\/>\n   Yes via namespaces\/RBAC\/quotas, but for strict separation you may need separate clusters. This is a governance decision.<\/p>\n<\/li>\n<li>\n<p><strong>How do I handle secrets safely?<\/strong><br\/>\n   Use least privilege, restrict Secret access via RBAC, rotate secrets, and consider integration with an on-prem secrets manager if required by policy.<\/p>\n<\/li>\n<li>\n<p><strong>What does \u201cair-gapped\u201d mean in practice?<\/strong><br\/>\n   No direct connectivity to the internet (and often no connectivity to external corporate networks). All artifacts and updates move through controlled, audited channels.<\/p>\n<\/li>\n<li>\n<p><strong>Do I still need vulnerability scanning if the environment is offline?<\/strong><br\/>\n   Yes. Offline environments still face insider risks and supply chain risks. Scanning and approval become even more important.<\/p>\n<\/li>\n<li>\n<p><strong>How do I troubleshoot if I can\u2019t upload logs to external support?<\/strong><br\/>\n   Establish an internal log collection and sanitization workflow. Plan what you can export and how approvals work. Maintain strong internal runbooks.<\/p>\n<\/li>\n<li>\n<p><strong>Can I run stateful workloads (databases) on it?<\/strong><br\/>\n   Kubernetes can run stateful workloads, but success depends on storage design and operational maturity. Validate storage, backup\/restore, and performance requirements carefully.<\/p>\n<\/li>\n<li>\n<p><strong>Is this a good fit for small edge devices?<\/strong><br\/>\n   Usually not. Google Distributed Cloud air-gapped targets a more substantial on-site footprint. For very small devices, lightweight Kubernetes or device-focused runtimes may be more appropriate.<\/p>\n<\/li>\n<li>\n<p><strong>How do I design DR (disaster recovery) for an air-gapped site?<\/strong><br\/>\n   DR is often site-to-site replication (if permitted) or backup-to-media with strict procedures. Define RPO\/RTO, test restores, and consider multi-site strategies if your compliance rules allow.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Google Distributed Cloud air-gapped<\/h2>\n\n\n\n<p>Use these starting points and always confirm you\u2019re reading the docs for the correct product variant and version.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official product landing page<\/td>\n<td>https:\/\/cloud.google.com\/distributed-cloud<\/td>\n<td>Entry point to Google Distributed Cloud offerings and documentation<\/td>\n<\/tr>\n<tr>\n<td>Official documentation (start page)<\/td>\n<td>https:\/\/cloud.google.com\/docs<\/td>\n<td>Google Cloud documentation hub (navigate to Distributed Cloud \/ air-gapped docs)<\/td>\n<\/tr>\n<tr>\n<td>Architecture Center<\/td>\n<td>https:\/\/cloud.google.com\/architecture<\/td>\n<td>Reference architectures and design guidance (useful for hybrid patterns)<\/td>\n<\/tr>\n<tr>\n<td>Pricing hub<\/td>\n<td>https:\/\/cloud.google.com\/pricing<\/td>\n<td>Official pricing navigation; distributed offerings may be contract-based<\/td>\n<\/tr>\n<tr>\n<td>Google Cloud Skills Boost<\/td>\n<td>https:\/\/www.cloudskillsboost.google<\/td>\n<td>Official hands-on labs platform (availability of air-gapped-specific labs may vary)<\/td>\n<\/tr>\n<tr>\n<td>Google Cloud YouTube<\/td>\n<td>https:\/\/www.youtube.com\/googlecloudtech<\/td>\n<td>Product talks and architecture sessions (filter for Distributed Cloud \/ hybrid topics)<\/td>\n<\/tr>\n<tr>\n<td>Google Cloud Blog<\/td>\n<td>https:\/\/cloud.google.com\/blog<\/td>\n<td>Product updates and announcements; search for Distributed Cloud air-gapped<\/td>\n<\/tr>\n<tr>\n<td>Kubernetes documentation<\/td>\n<td>https:\/\/kubernetes.io\/docs\/<\/td>\n<td>Core Kubernetes concepts used day-to-day in air-gapped clusters<\/td>\n<\/tr>\n<tr>\n<td>Supply-chain security (SLSA)<\/td>\n<td>https:\/\/slsa.dev\/<\/td>\n<td>Framework for securing build and artifact provenance\u2014highly relevant to air-gapped promotion pipelines<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<blockquote>\n<p>Note: The most accurate step-by-step installation\/upgrade procedures for Google Distributed Cloud air-gapped are typically in the product\u2019s official documentation set for your exact release. If you can\u2019t find the air-gapped doc set from the links above, search within cloud.google.com for \u201cGoogle Distributed Cloud air-gapped documentation\u201d and validate the URL is official.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<p>The following are third-party training providers. Review their course outlines and verify instructor credentials, currency, and hands-on lab access for air-gapped topics.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, platform teams<\/td>\n<td>DevOps, Kubernetes, cloud\/hybrid operations concepts<\/td>\n<td>check website<\/td>\n<td>https:\/\/www.devopsschool.com<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate DevOps learners<\/td>\n<td>SCM, CI\/CD, DevOps fundamentals<\/td>\n<td>check website<\/td>\n<td>https:\/\/www.scmgalaxy.com<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud ops and infrastructure teams<\/td>\n<td>Cloud operations, automation, operational practices<\/td>\n<td>check website<\/td>\n<td>https:\/\/www.cloudopsnow.in<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs and reliability-focused engineers<\/td>\n<td>SRE principles, monitoring, incident management<\/td>\n<td>check website<\/td>\n<td>https:\/\/www.sreschool.com<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops teams exploring AIOps<\/td>\n<td>AIOps concepts, automation, monitoring analytics<\/td>\n<td>check website<\/td>\n<td>https:\/\/www.aiopsschool.com<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<p>These sites may offer trainer listings, training services, or related resources. Verify relevance to Google Distributed Cloud air-gapped specifically.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/Kubernetes training content<\/td>\n<td>Individuals and teams seeking guided training<\/td>\n<td>https:\/\/www.rajeshkumar.xyz<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps and CI\/CD training<\/td>\n<td>DevOps engineers and platform teams<\/td>\n<td>https:\/\/www.devopstrainer.in<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps support\/training<\/td>\n<td>Small teams needing flexible help<\/td>\n<td>https:\/\/www.devopsfreelancer.com<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support services and training<\/td>\n<td>Ops teams needing troubleshooting support<\/td>\n<td>https:\/\/www.devopssupport.in<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<p>These organizations may provide consulting services relevant to Kubernetes, DevOps, and cloud\/hybrid operations. Validate specific experience with air-gapped distributed platforms during procurement.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting<\/td>\n<td>Architecture, platform engineering, automation<\/td>\n<td>Designing offline CI\/CD promotion pipeline; Kubernetes operations model<\/td>\n<td>https:\/\/www.cotocus.com<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps consulting and training<\/td>\n<td>DevOps transformation, Kubernetes enablement<\/td>\n<td>Building cluster operations runbooks; RBAC and GitOps process setup<\/td>\n<td>https:\/\/www.devopsschool.com<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting<\/td>\n<td>DevOps practices, CI\/CD, infra automation<\/td>\n<td>Implementing internal registry + scanning workflow; observability stack setup<\/td>\n<td>https:\/\/www.devopsconsulting.in<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before this service<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Kubernetes fundamentals<\/strong>\n   &#8211; Pods, Deployments, Services, Ingress\n   &#8211; Namespaces, RBAC, ConfigMaps, Secrets<\/li>\n<li><strong>Linux and networking<\/strong>\n   &#8211; DNS, TLS, routing basics\n   &#8211; Firewalls and segmentation concepts<\/li>\n<li><strong>Container fundamentals<\/strong>\n   &#8211; Images, registries, tagging, vulnerability basics<\/li>\n<li><strong>Operational discipline<\/strong>\n   &#8211; Change management\n   &#8211; Incident response and runbooks\n   &#8211; Backup\/restore basics<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after this service<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Advanced Kubernetes operations:<\/li>\n<li>cluster upgrades, node maintenance, capacity planning<\/li>\n<li>Supply chain security:<\/li>\n<li>image scanning, signing, SBOM practices, provenance<\/li>\n<li>GitOps in disconnected environments:<\/li>\n<li>internal Git, promotion strategies, environment parity<\/li>\n<li>Observability engineering:<\/li>\n<li>metrics\/log pipelines, retention, SIEM integration<\/li>\n<li>Security engineering for Kubernetes:<\/li>\n<li>network policies, admission policies (where supported), runtime security<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform Engineer (Kubernetes platform)<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>DevOps Engineer (hybrid\/distributed)<\/li>\n<li>Security Engineer (container\/Kubernetes security, compliance)<\/li>\n<li>Systems Engineer (on-prem infrastructure with cloud-native patterns)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud certifications focus mainly on public cloud services; for air-gapped distributed platforms, look for:<\/li>\n<li>Google Cloud architect-level knowledge (for design patterns)<\/li>\n<li>Kubernetes certifications (CKA\/CKAD\/CKS) for hands-on cluster skills<br\/>\nVerify current certification guidance in official Google Cloud certification pages: https:\/\/cloud.google.com\/certification<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<p>Even without a full air-gapped appliance, you can practice the <em>operational patterns<\/em>:\n1. Build an internal registry + mirror pipeline (simulate \u201cair-gapped\u201d by blocking internet egress).\n2. Create an offline Helm chart repository and deploy workloads without external downloads.\n3. Implement namespace multi-tenancy with quotas and RBAC.\n4. Design and test backup\/restore for a stateful app (e.g., PostgreSQL) with local storage.\n5. Create an \u201cupgrade rehearsal\u201d checklist and run it on a staging cluster.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Air-gapped:<\/strong> A network\/environment physically or logically isolated from external networks (especially the internet). Data transfer occurs only through controlled channels.<\/li>\n<li><strong>Artifact bundle:<\/strong> A packaged set of software components used for installation or upgrades, often transferred via offline media.<\/li>\n<li><strong>CNI (Container Network Interface):<\/strong> Kubernetes networking plugin system that defines pod networking behavior.<\/li>\n<li><strong>Cluster control plane:<\/strong> Kubernetes components that manage cluster state (API server, scheduler, controller manager, etcd).<\/li>\n<li><strong>Container registry:<\/strong> A service that stores and serves container images (e.g., Harbor, Artifactory, private Docker registry).<\/li>\n<li><strong>GitOps:<\/strong> Operating model where desired system state is stored in Git and applied automatically\/consistently via controllers.<\/li>\n<li><strong>Ingress:<\/strong> Kubernetes resource that manages external access to services, typically HTTP\/HTTPS, often via an ingress controller.<\/li>\n<li><strong>Kubeconfig:<\/strong> Configuration file used by <code>kubectl<\/code> to connect to a Kubernetes cluster.<\/li>\n<li><strong>Namespace:<\/strong> Kubernetes partitioning mechanism for isolating resources within a cluster.<\/li>\n<li><strong>Network segmentation:<\/strong> Separating networks into zones (management, workloads, users) to reduce attack surface and limit lateral movement.<\/li>\n<li><strong>RBAC:<\/strong> Role-Based Access Control; in Kubernetes, rules mapping identities to allowed operations.<\/li>\n<li><strong>ResourceQuota:<\/strong> Kubernetes object that limits resource consumption per namespace.<\/li>\n<li><strong>SLO\/SLA:<\/strong> Service Level Objective\/Agreement; reliability targets and commitments.<\/li>\n<li><strong>Supply chain security:<\/strong> Practices to ensure software artifacts are trusted (scanned, approved, provenance tracked) before deployment.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Google Distributed Cloud air-gapped is a Google Cloud offering in the <strong>Distributed, hybrid, and multicloud<\/strong> category that brings a Kubernetes platform to <strong>fully disconnected<\/strong> environments. It matters because many organizations need modern cloud-native operations\u2014containers, standardized deployments, policy controls\u2014but must keep systems offline for security, sovereignty, or compliance reasons.<\/p>\n\n\n\n<p>Architecturally, it runs on-site with local control planes, local networking, and offline artifact delivery. Cost is typically contract-based, and the biggest cost drivers are often <strong>operational<\/strong>: offline image and update pipelines, staging environments, staffing, and evidence collection.<\/p>\n\n\n\n<p>Security success depends less on \u201cbeing air-gapped\u201d and more on disciplined controls: least privilege RBAC, internal registry governance, scanning\/approval, strong PKI practices, and segmented networking.<\/p>\n\n\n\n<p>Use Google Distributed Cloud air-gapped when a strict air-gap is mandatory and you want a supported, structured Kubernetes platform for on-prem sites. Next step: read the official Google Distributed Cloud documentation, then build an internal \u201cmirror \u2192 scan \u2192 approve \u2192 import \u2192 deploy\u201d pipeline and practice the hands-on deployment workflow in a staging enclave before moving to production.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Distributed, hybrid, and multicloud<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[60,51],"tags":[],"class_list":["post-693","post","type-post","status-publish","format-standard","hentry","category-distributed-hybrid-and-multicloud","category-google-cloud"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/693","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=693"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/693\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=693"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=693"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=693"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}