Google Distributed Cloud

GDC = Google Distributed Cloud. Extensions of GCP.

https://cloud.google.com/distributed-cloud

• GDC Virtual: connected, software only, running on customer's infra. (Basically a rebranded Anthos on-prem + Anthos Bare Medel)
  • GDCV customers can bring Google Cloud’s software stack to their own data center servers. Moreover, with the service, they can operate various on-premises applications using the same Google Cloud APIs, control planes, hardware, and tooling as their cloud-hosted apps.
  • uses Google Cloud Console to provision Anthos clusters on vSphere or bare metal:
• GDC Connected: connected to GCP, Google managed hardware + software; for low latency, data residency hybrid workloads.
• GDC air-gapped: air-gapped=no external connections; pre-configured hardware + software, managed by Google or a trusted partner, for the most sensitive workloads.
  • does not require connectivity to Google Cloud at any time to manage infrastructure, services, APIs, or tooling, and uses a local control plane provided by Anthos for operations.
  • diff from ABM: airgapped from the Internet, i.e. no direct access to public cloud, so need special ops personnel to manage.

"Anthos" is deprecated:

• Anthos Service Mesh and Traffic Director => Cloud Service Mesh.
• Anthos on Bare Metal => GDC (software only) for bare metal.
• Anthos Identity Service => GKE Identity Service

GDC Virtual / Anthos

Control plane runs on GCP for upgrades, policy management, telemetry.

What is Anthos:

• Anthos = GKE (Kubernetes) + Service Mesh (Istio) + Cloud Run (Knative) + Management (UI/CLI, policy, configs, etc) + logging / monitoring

Components:

• Rebranded as GDC Virtual:
  • Anthos on VMware: run GKE in a vSphere environment.
    • OS->vSphere->Kubernetes
    • Anthos manages os and packages.
  • Anthos on Bare Metal: run GKE in on-prem data centers. WITHOUT VMware.
    • Customer manages os and packages.
    • KubeVirt: optional; enables Kubernetes orchestration of VMs running on KVM. For legacy virtualized workloads.
    • CLI:
      • bmctl: manages admin cluster
      • kubectl and Anthos K8s API: manage user clusters
• Anthos Service Mesh (ASM): a Google productionized version of OSS Istio.
• Anthos Config Management (ACM)
• Anthos Identity Service (AIS): just an auth proxy, not a full IdP. Implemented as a webhook authentication; AIS exchanges the Service Account token for STS token.
• Anthos obervability based on GCP: Stackdriver API, Cloud Monitoring API, Cloud Logging API

Anthos Bare-metal

Managing Kubernetes on customer managed Operating Systems. Uses Cilium, MetalLB, and Ansible for machine management.

ABM Kubevirt support: support for managing VMs on top of ABM (server nodes are often too beefy to be one node for customers) Customers bring and manage their nodes, while Google is responsible for installing / upgrading Anthos components (e.g., GKE, ACM, ASM, Cloud Run).

From the user’s point of view, Anthos Bare Metal has an API in the form of Kubernetes resource model. But under the hood, Anthos Bare Metal utilizes Ansible as the mechanism to manage nodes.

Why ansible:

• To reduce the cost of supporting different operating system distributions, since it provides some level of abstraction and framework.
• To avoid interfering with the customer’s existing management tools, since it does not require the installation of an agent.

bmctl upgrade

# Node is put in maintenance mode before upgrading
$ bmctl upgrade

$ bmctl upgrade cluster --kubeconfig=<admin_kubeconfig> -c cluster.

# upgrade the cluster without creating a temporary bootstrap clusters
$ bmctl upgrade cluster --kubeconfig=<admin_kubeconfig>:

In-place upgrades will leverage kubeadm upgrade to do the heavy-lifting.

The flow is to upgrade the master node pool first followed by worker node pools. Upgrade will be performed on one node at a time to minimize the capacity reduction.

Will bootstrap a temporary cluster to act as temporary parent of the cluster and this leaves the rest of upgrade process similar to upgrade cluster with parents.