Start with the simple problem: the cloud is wonderful, but it is not always where your work needs to happen.

The cloud has an address

When people say “the cloud,” it sounds as if computing floats somewhere in the sky. In reality, cloud computing happens inside very large buildings called data centers, filled with computers. A cloud company such as Google runs these buildings in many cities, and each group of them is called a region. When you use the public cloud, your work runs in one of those regions.

For most work, that is perfectly fine. But sometimes the distance or the rules make it a bad fit. Four reasons come up again and again.

• Speed. Information takes time to travel. A robot arm on a factory floor cannot wait for a message to go to a city a thousand kilometres away and back before it moves.
• Rules. Some laws and company policies say that certain data must stay inside a country, a building or even a locked room.
• Connection. Ships, mines, remote clinics and military sites may have slow, expensive or no internet at all.
• Existing investment. A company may own thousands of computers it paid for already and does not want to throw them away on the first day.

So what is Google Distributed Cloud?

Google Distributed Cloud, often shortened to GDC, is a portfolio of products that extends Google Cloud’s infrastructure and services to places outside Google’s own regions: your own data centers, edge locations such as stores and factories, and fully isolated environments. It is not a single product. It is a family. Each member makes a different promise about who owns the hardware, who runs it and whether it may talk to the internet at all. Chapter 3 introduces the whole family.

What ties them together is a common way of working. Applications are packaged in containers and run on Kubernetes, an open system for running and managing many applications across many computers. If your team learns this way of working once, it applies across all the places GDC reaches.

A short history

Google first offered hybrid tools under the brand Anthos, introduced around 2019, which let companies run Kubernetes clusters on their own hardware and manage them from Google Cloud. In 2022, Google announced Google Distributed Cloud as a wider umbrella, adding edge hardware that Google supplies and an option for completely disconnected “air-gapped” sites. The older Anthos software offerings continued under the new name, and the fleet management side later became part of a platform called GKE Enterprise. Names and packaging in this area have changed more than once, so always check the current Google Cloud documentation before planning around a name.

Why teams choose it

Teams choose GDC because it lets them keep the working style of the cloud while respecting the limits of the real world. They can run close to machines and customers, keep data where the law requires, operate without a constant internet link and move to the cloud step by step rather than in one risky leap.

A handful of words appear everywhere in this topic. Learn them once and the rest becomes easy.

On-premises, hybrid and multicloud

On-premises, often shortened to on-prem, means computers that sit in buildings you control, such as your own data center, rather than in a cloud provider’s building. A hybrid cloud mixes on-prem systems with a public cloud and lets them work together. A multicloud setup uses more than one public cloud provider. GDC is mainly a hybrid tool, and it can also help in multicloud designs because Kubernetes runs nearly everywhere.

Edge

The edge means the place where data is created or used, far from the big data centers: a shop, a factory, a hospital, a cell tower, a ship. Edge computing means doing the computing there instead of sending everything far away.

Latency and bandwidth

Latency is the delay between asking for something and getting an answer. Bandwidth is how much data can be sent per second. A video camera can create more data than a thin internet line can carry, so it is smarter to process the pictures on the spot and send only the results.

Air-gapped

An air-gapped system has no connection to the public internet or to outside networks at all. The name comes from the idea of a literal gap of air between it and the outside world. It is used where secrecy and safety matter most.

Data residency, data sovereignty and operational sovereignty

These three phrases sound alike but differ.

• Data residency means data is stored in a particular place, such as a given country.
• Data sovereignty means data is subject to the laws of the country where it is stored or owned, and cannot be demanded by foreign authorities without that country’s rules applying.
• Operational sovereignty means the people who run and support the system, and the tools they use, are under local control too, so that an outside company’s staff cannot reach into the system.

Kubernetes words you will meet

A container is a sealed package holding an application and everything it needs to run. A cluster is a group of computers working together under Kubernetes. Each computer in a cluster is a node. The control plane is the brain of the cluster that decides what runs where. A fleet is a named group of clusters, perhaps hundreds, that you manage together.

A quick glossary table

The family has a few members. What separates them is simple: who supplies the hardware, who runs it and whether it may connect to Google Cloud.

The members at a glance

Three questions that sort the family

Comparing the members

Almost every real GDC project starts from one of a few pressures. Seeing them helps you judge whether your situation truly needs it.

A reality check: do you really need it?

A useful test is to ask what would happen if the workload simply ran in a Google Cloud region. If the honest answer is “nothing bad,” then you probably do not need GDC. Every extra place you run software adds cost, planning and people effort. Choose GDC when a real constraint of distance, law, connection or existing equipment forces your hand.

Nearly everything in GDC rests on a few ideas. This chapter explains them from scratch.

The problem containers solve

An application often works on the developer’s laptop and fails on the server because of small differences, such as a different version of a supporting program. A container packs the application together with exactly the pieces it needs, so it runs the same way everywhere.

What Kubernetes does

One container is easy. Ten thousand containers across a hundred computers are not. Kubernetes is the open-source system that handles the hard parts: it starts containers, restarts them when they crash, spreads them across computers, adds more copies when demand rises and rolls out new versions gently. You tell Kubernetes the desired state, such as “keep five copies of the checkout service running,” and it works constantly to make reality match.

The parts of a cluster

Virtual machines still matter

Not every program is ready to be a container. Many older applications run inside virtual machines, which are software-made computers that behave like separate real ones. GDC’s Kubernetes-based tools can run virtual machines alongside containers, so a company can keep an old application running while it slowly modernizes, all under one management system.

Desired state and reconciliation

A key idea worth remembering is reconciliation. Kubernetes continuously compares what you asked for with what exists, and fixes any difference. If a node dies, the missing pods are started elsewhere. This self-healing is exactly what you want when a site has no on-site expert.

Put the pieces on one map and you will see that most GDC designs share the same shape.

The two halves

Every GDC design has two halves. One half is the management side, usually in Google Cloud, where you see all your clusters, set rules and watch their health. The other half is the local side, which is the clusters running in your data centers or edge sites, doing the real work for real users and machines. The two halves are joined by a secure connection, except in air-gapped designs, where the management side lives inside the sealed site too.

flowchart LR
  A["Google Cloud Console and Fleet Management"] --> B["Secure Connection"]
  B --> C["Data Center Cluster"]
  B --> D["Factory Edge Cluster"]
  B --> E["Store Edge Cluster"]
  F["Git Repository of Desired State"] --> A
  C --> G["Local Apps and Data"]
  D --> H["Local Apps and Data"]
  E --> I["Local Apps and Data"]

Walking through the map

On the left sits the management side. Teams keep their desired settings in a Git repository, which is a version-controlled store of files that records every change and who made it. Google Cloud’s fleet tools read those settings and show the health of every registered cluster in a single view. A secure connection, such as a private network link or an encrypted tunnel, joins the management side to each site. At each site, a cluster runs local apps and keeps local data. If the connection breaks, the local apps keep running.

The main components

The consistency promise

The biggest benefit of this shape is consistency. The same container, the same way of describing it and the same tools work whether the cluster is in Google Cloud, in your data center or in a shop. Teams do not need a different skill set for each place.

This is the member of the family that most companies meet first, because it works with equipment they already own.

What you get

GDC software is Google’s version of Kubernetes that you install on your own servers. It comes in two main flavours. One runs on top of a virtualization layer from VMware, which many companies already use. The other, called bare metal, runs directly on physical servers with no virtualization layer in between, which saves overhead and suits edge sites and performance-sensitive work.

Cluster types

In this option you will hear of admin clusters and user clusters. The admin cluster is a small management cluster that creates and looks after the others. User clusters are where your applications run. In bare metal there are also simpler layouts, such as a single standalone cluster, or a hybrid layout where management and workloads share a cluster, which is handy for small edge sites. The exact layouts and names change between versions, so check the current documentation.

What you must provide

Because you own the hardware, certain things are yours to supply and look after.

• Servers that meet the supported hardware and operating system requirements.
• Networking: addresses, switches and a way to reach Google Cloud if you want fleet management.
• Load balancing: Kubernetes needs something to spread incoming traffic. The software can bring its own bundled load balancer, or you can connect an existing one.
• Storage: disks or storage systems linked through standard Kubernetes storage drivers.
• Upgrades: you plan and run version updates, using the tools Google provides.

Connection to Google Cloud

Clusters register into a fleet by making an outbound connection to Google Cloud. They appear in the Google Cloud console, can use features such as logging and monitoring, and can receive settings from Git. Because the connection is outbound, you usually do not need to open incoming holes in your firewall. If the connection drops, the cluster keeps running its applications, though the management view may go stale until the link returns.

When this option fits best

It fits a company with a large, existing data center and skilled staff, which wants the cloud operating style without buying new hardware. It also suits edge sites where the company already has servers. It fits less well when the team is small and does not want the work of running hardware, in which case the connected option may be easier.

For places where you want cloud behaviour with as little local hardware work as possible, Google supplies and manages the equipment.

What it is

GDC connected is a service in which Google provides the hardware, usually in the form of ready-built servers or racks, and manages a large part of the software on it. It is placed at your edge sites, such as stores, factories, stadiums or warehouses, and at telecom operators’ locations. It is linked to Google Cloud, so you manage it with the same console and tools as the rest of your cloud. It was earlier known as GDC Edge.

How a site is set up

Who it is built for

Operating in the real world

Edge sites are often in ordinary buildings, not purpose-built data centers. Hardware must survive dust, warm back rooms and occasional power cuts. Planning for network failure is equally important: the site’s applications must keep working with the link down and catch up when it returns. Deliveries, installation visits and replacement parts add practical steps that a pure cloud project never has.

When the rule is “nothing may connect to the outside,” the cloud itself must be brought inside the fence.

What it is

GDC air-gapped is a complete cloud-like platform that runs entirely inside a customer’s isolated facility, with no connection to the public internet and none to Google Cloud. It provides familiar building blocks, such as Kubernetes, virtual machines, storage, databases, security tools and a growing set of data and AI services, so teams inside the fence can develop and run applications as they would in the public cloud. It was earlier known as GDC Hosted.

Who needs it

Typical customers are national governments, defense and intelligence organizations, critical infrastructure operators and some highly regulated companies. They need strict separation from outside networks, and often need operational sovereignty, which means the people who run the platform are under local control. In some countries Google works with local partner companies who operate or support such platforms under that country’s rules. Details differ by country and change over time.

flowchart LR
  subgraph O["Outside World"]
    S["Secure Transfer Station"]
  end
  subgraph Z["Air-Gapped Zone"]
    I["Isolated Platform Control"]
    W["Workloads and Data"]
    M["Local Monitoring and Logging"]
  end
  S -->|"approved updates only"| I
  I --> W
  W --> M

How it stays up to date

If nothing connects, how do security fixes and new versions arrive? Through a controlled process. Updates are prepared outside, checked and delivered into the facility through approved physical media or a strictly controlled transfer station, then installed by authorized staff. Everything is inspected and logged. This is slower than a cloud that updates itself, and it is a trade-off customers accept in return for isolation.

Everything local

Because it cannot call Google Cloud, an air-gapped platform must carry its own versions of everything: identity and access control, logging, monitoring, key management, container registries and so on. Teams cannot rely on outside services, public package websites or internet documentation while working. Planning for that, by mirroring needed software inside the fence beforehand, is part of the project.

Certifications and trust

Customers of this kind of platform care about independent certifications and government approvals, which prove that the design meets strict standards. Which approvals a given product version holds depends on the country and changes over time, so check the current list with Google or your partner rather than assuming.

Running one cluster is easy. Running five hundred the same way is the real challenge, and fleets are the answer.

What is a fleet?

A fleet is a logical group of clusters that you manage together, wherever they run: in Google Cloud, in your data center or at the edge. Registering a cluster into a fleet lets you see it in one console, apply common settings, grant access in a uniform way and treat many clusters as one family. Fleet features are part of the GKE Enterprise platform, and details of packaging may change.

Configuration as code and GitOps

GitOps is a way of working in which the desired state of your systems is kept in Git, and software constantly makes the real systems match the files. Changing a setting means changing a file, getting it reviewed and approving it. No one needs to log in to a store’s cluster to change anything. A tool called Config Sync runs at each cluster, pulls the approved files and applies them.

sequenceDiagram
  participant Dev as Developer
  participant G as Git Repository
  participant A as Config Agent at Site
  participant K as Site Cluster
  participant F as Fleet Management
  Dev->>G: Approve change to desired state
  A->>G: Pull latest desired state
  A->>K: Apply the change
  K-->>A: Report current state
  A-->>F: Send status for the fleet view
  Note over A,K: If the link is down the site keeps running the last known state

Policy guardrails

Policy Controller is a tool that checks every change against your rules before it is accepted. A rule might say “no container may run as the all-powerful administrator” or “every application must carry an owner label.” Rules apply the same way at every site, which prevents small differences from creeping in and causing trouble.

Service mesh

A service mesh is a layer that handles communication between the many small services of an application. It can encrypt traffic between them, retry failed calls, measure delays and control which service may talk to which. Cloud Service Mesh is Google’s managed option. It is especially valuable across many sites, because the same traffic rules can apply everywhere.

Safe rollouts across many sites

Changing five hundred sites at once is a gamble. A safer approach is a staged rollout. Start with one test site, then a small group of low-risk sites, then wider groups, watching health at each step and stopping if trouble appears. Fleet tools make this natural because you can label clusters by group and apply changes to one label at a time.

Follow one customer purchase through a store cluster, then follow an application through its whole life.

The life of one request

The life of an application

Operations people often describe the work in three stages called Day 0, Day 1 and Day 2.

Retiring things properly

Applications and whole sites eventually end. Retiring a site means moving or deleting its data in line with the rules, removing its credentials, taking it out of the fleet and, for hardware, wiping and returning or recycling it securely. Forgotten sites with live credentials are a quiet security risk.

The network is the thread that ties your sites to each other and to the cloud. Understanding it prevents most surprises.

Three kinds of network

• The local network inside a site, linking servers, devices and users.
• The wide-area link between a site and the rest of your organization, or Google Cloud.
• The cluster network inside Kubernetes, which gives every pod an address and controls who can talk to whom.

Linking sites to Google Cloud

Sites that connect to Google Cloud commonly use a virtual private network, which is an encrypted tunnel over the internet, or a dedicated interconnect, which is a private physical line with steadier speed and delay. Which one fits depends on cost, volume and reliability needs. Some customers use two links, for example one private line and one tunnel as backup.

Load balancing and addresses

Kubernetes needs a way to spread incoming traffic across copies of an application. In a public cloud, a load balancer service does this automatically. On your own hardware, you must provide it. Options include a bundled software load balancer shipped with the GDC software, a hardware load balancer you already own or a manual setup. Planning address ranges carefully matters too, because overlapping addresses between sites and the cloud cause painful problems later.

Designing for a weak or missing link

Never assume the wide-area link is always up. Good designs follow a few habits.

• Local first. Serve users from local data and local services.
• Store and forward. Save outgoing data in a local queue and send it when the link returns.
• Small, safe updates. Do not depend on a huge download over a thin line. Send compact changes and cache images locally.
• Clear conflict rules. When a site and the cloud both changed the same record while disconnected, decide in advance which version wins.

Name lookup and certificates

Two quiet helpers deserve a mention. DNS is the system that turns names into network addresses, and local sites often need their own local DNS so that names still work when the link is down. Certificates are digital badges that prove identity and enable encryption. They expire, and an expired certificate on a remote site can bring services down. Automating renewal avoids this.

Containers come and go, but data must stay. This chapter explains how data is kept safe and where it lives.

Why storage needs care

Kubernetes can destroy and recreate containers whenever it likes. If the data lives inside the container, it disappears with it. Important data therefore lives on persistent volumes, which are pieces of storage that outlive any single container. Kubernetes talks to the real storage through a standard connector layer called CSI (Container Storage Interface), so many different storage systems can be used.

Storage choices at a site

Backup and recovery

Two numbers shape every backup plan. The recovery point objective, or RPO, is how much recent data you can afford to lose, for example “no more than fifteen minutes.” The recovery time objective, or RTO, is how long you can afford to be down, for example “back within one hour.” Choose them from business needs, then design backups and copies to meet them. A backup that has never been tested is only a hope, so practise restoring.

Data placement decisions

For each kind of data ask three questions. Must it stay at the site? May it be copied to a regional hub? Can it go to Google Cloud? Raw video might stay at the site, summaries might go to a regional hub and totals might go to the cloud. Writing these rules down, as a data classification, makes both design and audits much easier.

Keeping copies in step

When the same data lives in several places, copies can drift apart. Decide whether a site is the source of truth for a type of data, or the cloud is, and design flows in one direction where possible. Two-way changes to the same record are the hardest to get right and need clear conflict rules.

Many of the newest uses of GDC come from bringing artificial intelligence to where the data already is.

Why AI at the edge or on-prem?

Artificial intelligence models need data. Sometimes that data is a live video stream, a set of private patient records or a classified document library. Sending it far away may be too slow, too costly or not allowed. Running the model locally keeps the data in place, gives fast answers and avoids repeated transfer charges.

Training versus inference

Training is the heavy, expensive process of teaching a model from large amounts of data. Inference is using a trained model to answer a question or classify a picture. Training often stays in large data centers or in Google Cloud, where computing power is plentiful. Inference is what most commonly runs at the edge or on-prem, because it needs less power and benefits most from being close to the data.

What you need to plan

• Accelerators. Many models run best on graphics processing units (GPUs) or similar chips. These are limited and costly at a site, so size them carefully.
• Model delivery. Models are large files. Plan how new versions reach each site safely and how you roll back.
• Monitoring quality. A model that quietly gets worse over time causes bad decisions. Measure accuracy, not only uptime.
• Data handling. Decide what is kept, what is deleted and what may leave the site.

Google’s AI on GDC

Google has announced ways to run its own AI models and tooling, including its Gemini family, on GDC, with options for both connected and air-gapped environments and with support for specialised accelerator hardware. Availability, model versions, supported hardware and regions evolve quickly, so confirm the current list with Google before planning around a specific model.

Spreading computing across many places spreads the attack surface too. Security must be designed in from the start.

Shared responsibility

In every cloud arrangement, some security jobs belong to the provider and some to you. In GDC, the split depends on the member of the family.

Exact divisions are set in the service documents and contracts, so read them rather than assuming.

Zero trust

Zero trust is the idea that nothing is trusted just because of where it sits. A request from inside the network is checked as carefully as one from outside. Every user, device and service must prove identity and be allowed only what it needs. This idea fits distributed systems well, because the “inside” is no longer one building.

Plan for the compromised site

With many sites, one will eventually be lost, stolen or attacked. Design so that this costs little: give each site credentials that reach only that site, make secrets easy to rotate and be able to cut a site off from the fleet quickly. This idea is called limiting the blast radius.

When the computers are far away and nobody is in the room, good instruments are your eyes and ears.

Three kinds of signals

• Logs are written records of what happened, such as “payment accepted” or “disk almost full.”
• Metrics are numbers measured over time, such as processor use, free memory or requests per second.
• Traces follow a single request through many services, showing where time was spent.

Where the signals go

For connected clusters, logs and metrics can flow to Google Cloud’s logging and monitoring tools, where you see all sites together. Managed Service for Prometheus lets you use a popular open metrics system without running its storage yourself. For air-gapped sites, observability tools must run inside the fence, and operators watch from there. In every case, decide what must be kept locally because the link might be down when you need the data most.

Alerts worth having

• A site that has stopped reporting for longer than expected, which may mean a link or power problem.
• Disk or memory approaching limits.
• A cluster version nearing the end of its support period.
• Certificate expiry in the next few weeks.
• Drift between the desired state in Git and the actual state at a site.

Upgrades: the never-ending chore

Kubernetes releases a new minor version every few months, and each version is supported for a limited time. Falling behind means missing security fixes and eventually running unsupported software. Upgrades in GDC are planned events: test on a copy first, upgrade a few low-risk sites next, watch carefully and then continue in waves. Software and hardware firmware must both be kept current. For the software option, you run upgrades with Google’s tools. For connected, Google handles much of the platform upgrade work in agreed windows. For air-gapped, upgrades come through the controlled transfer process.

The public cloud feels endless. On GDC, the hardware is finite, so planning replaces magic.

Finite capacity changes the rules

In a public cloud region you can usually ask for more machines and receive them within minutes. At a store or a factory you have the servers that were installed, and no more. Adding capacity means ordering hardware, shipping it, installing it and testing it. This makes capacity planning a core skill: estimate peak demand, add a safety margin and watch usage trends so you order before you run out.

What makes things fast

• Proximity. Running next to users and machines removes most of the delay.
• Local data. Serving from local storage avoids the wide-area trip.
• Right-sized nodes. Matching processor, memory and accelerators to the workload avoids waste and slowness.
• Caching. Keeping frequent answers close, including container images, speeds up everything and saves bandwidth.

High availability inside a site

High availability means a system keeps working when parts fail. Inside one site, run several copies of each important service on different nodes, keep spare capacity so a lost node’s work can move elsewhere, and use more than one power feed and network switch where the site allows. Small edge sites often accept lower availability for the sake of cost, but the business must choose that knowingly.

Availability across sites

flowchart LR
  U["Users"] --> L["Traffic Routing"]
  L --> A["Site A Cluster"]
  L --> B["Site B Cluster"]
  A  R["Data Replication"]
  B  R
  A --> C["Google Cloud Backup and Analytics"]
  B --> C

For important services, two or more sites can share the load and replicate data between them. If one site fails, traffic moves to another. This costs more and brings its own difficulties, such as keeping data in step and avoiding “split brain,” where two sites each think they are in charge. Use it where the business value justifies the effort.

Disaster recovery

Disaster recovery is the plan for a large failure, such as a fire or a flood. Common patterns, from cheapest to fastest, are: keep backups and rebuild (slow, cheap); keep a small standby site ready to scale up (medium); and keep a second site always running in step (fast, costly). Choose by comparing the cost of downtime with the cost of the standby, and test the plan.

No tool is perfect. A fair look at both sides helps you decide when GDC is the right fit.

The big trade-offs in plain words

Control against effort. The more of the stack you own, the more you can tune and the more you must maintain. The software option gives the most control and takes the most work. Connected hands more of the work to Google at the price of choosing among defined configurations.

Isolation against freshness. A fully isolated system is the safest from outside threats, but it receives updates and new features more slowly and lacks easy access to outside services.

Locality against elasticity. Running near the data gives speed and compliance, but gives up the almost endless on-demand capacity of the public cloud.

Consistency against simplicity. A uniform fleet is easier to manage than a mixed one, but achieving uniformity across many sites demands discipline and good tooling.

A pattern is a proven way to solve a common problem. An anti-pattern is a tempting mistake that causes trouble later.

Useful patterns

Anti-patterns to avoid

A short checklist you can use on your next project.

Best practices

Common mistakes

A simple troubleshooting order

When a site misbehaves, check in this order. First, is the site powered and reachable on its local network? Second, is the wide-area link up, and does the site still report to the fleet? Third, are the nodes healthy and is the control plane responding? Fourth, are the applications running and are their logs showing errors? Fifth, has anything changed recently in Git or in the cluster version? Sixth, compare the site with a healthy twin to see what differs. Following the same path each time turns panic into routine.

These typical situations show how organizations of many kinds use Google Distributed Cloud. They are illustrative patterns, not accounts of any one company’s private setup.

There are many ways to run software. Knowing the differences prevents using a heavy tool for a light job.

flowchart TD
  Q["Where must your workload run?"] --> A{"Can it run in a Google Cloud region?"}
  A -->|"Yes"| B["Use Google Cloud regions with GKE or Cloud Run"]
  A -->|"No"| C{"Must it be fully cut off from the internet?"}
  C -->|"Yes"| D["Google Distributed Cloud air-gapped"]
  C -->|"No"| E{"Do you want Google to supply and manage the hardware?"}
  E -->|"Yes"| F["Google Distributed Cloud connected"]
  E -->|"No"| G["Google Distributed Cloud software on your own hardware"]

GDC and GKE in Google Cloud

Google Kubernetes Engine, or GKE, is Google’s managed Kubernetes inside Google Cloud regions. GDC brings the same style of Kubernetes to other places. Teams that know GKE will find GDC familiar, and applications can often move between them with little change, which is a real strength.

GDC and the public cloud together

Most organizations do not choose one or the other. They use public cloud regions for the bulk of their work and GDC only where a specific constraint demands it. The same container images, the same Git repository and the same monitoring then serve both, and a workload can move when the constraint changes.

If you know other clouds

Readers who know other clouds may find a loose comparison useful. GDC plays a role similar to the on-premises and edge extensions offered by other major providers, and Kubernetes-based management tools from several vendors share some ideas. The match is not exact, so rely on Google Cloud’s documentation for details.

Let us put everything together by designing, on paper, a plan for a chain of two hundred grocery stores.

Step 1: Write the constraint in one sentence

“Each store must keep selling, checking prices and stock even when its internet line is down for a day, and customer payment data must not leave the country.” This sentence names the need for local operation and a rule about data.

Step 2: Choose the family member

The stores do not need full isolation, so air-gapped is too heavy. The chain has no spare servers in shops and little technical staff there, so it prefers Google-supplied hardware with Google handling most of the platform upkeep. GDC connected is a good fit. If the chain already had suitable servers and a skilled team, the software option could be considered instead.

Step 3: Decide what runs where

flowchart LR
  P["Point of Sale in Store"] --> S["Store Edge Cluster"]
  S --> R["Local Inventory and Price Service"]
  S -->|"batched sales when link is up"| H["Regional Hub in Google Cloud"]
  H --> A["Analytics in BigQuery"]
  G["Git Repository"] --> F["Fleet Config Sync"]
  F --> S

Step 4: Plan the management

All two hundred clusters join one fleet. Desired settings live in Git and are applied by Config Sync. Policy Controller blocks any change that breaks security rules. New software versions roll out first to two pilot stores, then to twenty, then to the rest, with automatic health checks between waves.

Step 5: Protect against the known traps

Step 6: Plan the watching

Dashboards show fleet health, versions and drift. Alerts fire when a store stops reporting, disks fill, certificates near expiry or a site falls behind in version. Each store has a named owner and a short runbook for staff.

The design checklist

Quick answers to the questions that come up most often.

Not exactly. Anthos was the earlier brand for Google’s hybrid Kubernetes software. Google Distributed Cloud is a wider family that includes the successor to those software offerings, plus connected and air-gapped options. Names and packaging have changed over time, so check the current documentation.

Connected links to Google Cloud for management and extra services, and Google operates much of the platform. Air-gapped has no link to the internet or Google Cloud, and is operated inside the customer’s isolated facility.

Yes. Kubernetes is the common foundation. Managed options reduce how much you must handle yourself, but your team still needs to understand it to deploy and troubleshoot applications.

Applications on the local clusters keep running. The management view may go stale and cloud services stop being reachable until the link returns, so design the site to work alone and catch up later.

With the software option, often yes, if they meet the supported hardware and operating system requirements. Connected and air-gapped use Google-supplied or approved hardware.

Usually not per unit of computing. You choose GDC for a constraint such as latency, law or connection, not to save money. Compare total cost over several years, including people, hardware, power and upgrades.

Yes. Kubernetes-based tools in the family can run virtual machines next to containers, helping you move older applications gradually. Supported options vary by member and version.

Through a controlled process. Updates are prepared and checked outside, then delivered through approved media or a strict transfer station and installed by authorized staff.

Google has announced ways to run AI models, including its Gemini family, on GDC, and you can also run your own models on suitable accelerator hardware. Availability and supported hardware change quickly, so confirm the current details.

Fleets are designed for large numbers of clusters, but limits exist and change with versions. Check the current quotas and limits pages when planning at scale.

Responsibility is shared, and the split depends on the family member. Generally you own your applications, data, settings and access control, while the platform owner handles lower layers according to the service documents and contracts.

No. Use public cloud regions by default, and use GDC only for workloads that have a real constraint of delay, law, connection or existing equipment.

Learn containers and Kubernetes first, then try GKE in a Google Cloud region, then read about fleets and GitOps. Once those feel natural, the hybrid and edge options are a small step, not a leap.

The whole guide in one place.