liveBook · Manning

Minimum-footprint mentality

As explained in Google Anthos in Action

A minimum-footprint mentality is an operational design approach that limits a management system to explicitly designated resources rather than taking control of an entire environment.

A minimum-footprint mentality limits Anthos Config Management (ACM) to objects explicitly defined in policy configuration instead of taking over an entire Kubernetes cluster. This lets other deployment mechanisms operate in parallel without automatically overwriting one another. section 11.2

Apply the approach with clear ownership boundaries:

  • Track which tool deployed each object; ACM adds annotations to objects it manages, although other tools may identify ownership differently. section 11.2
  • Use an unstructured policy repository when existing tools produce YAML or JSON and ACM should handle deployment and management. section 11.2
  • Account for the operational burden of coordinating multiple deployment tools and their object ownership. section 11.2
applySpecVersion: 1
spec:
clusterName: <name of cluster>
  enableMultiRepo: <true/false, enables multiple repository mode>
  enableLegacyFields: <true/false, used with multi repo, see below>
  policyController:
    enabled: <true/false>
    templateLibraryInstalled: <true/false, installs the Google-provided template library for policy controller>
  sourceFormat: <hierarchy or unstructured. Sets the type of policy organization>
  preventDrift: <if set to true, rejects changes to the cluster that conflict with managed resources>
  git:
    syncRepo: <url of the git repository>
    syncBranch: <branch of the git repository to sync from>
    policyDir: <relative path in the git repository to the policy directory>
    syncWait: <number of seconds between sync attempts>
    syncRev: <git revision to sync from. Used if a specific commit or tag should be used instead of a branch>
    secretType: <ssh, cookiefile, token, gcenode, gcpserviceaccount or none. Specifies the type of authentication to perform>
    gcpServiceAccountEmail: <email of the service account to use for git access. Only used when secretType is gcpserviceaccount>
    proxy:
      httpProxy: <proxy information for http connection, styled similarly to the HTTP_PROXY environment variable>
      httpsProxy: <proxy information for https connection, styled similarly to the HTTPS_PROXY environment variable>

Configure the managed scope, repository path, synchronization interval, source format, and drift behavior through the ACM specification. section 11.2

How Google Anthos in Action covers it

How deep it goes
Defines scoped object management, ownership annotations, integration modes, and coordination trade-offs without descending into controller internals.
Examples
Uses policy-defined objects, managed-object annotations, unstructured YAML or JSON, and parallel deployment tools as concrete examples.
What it assumes
Assumes familiarity with Kubernetes clusters, Git repositories, policy configuration, and deployment operators.
What you can do after
Operate/configure ACM with explicit resource boundaries while coordinating ownership across deployment tools.
How it connects
Connects Anthos Config Management with Kubernetes, Git repositories, policy configuration, YAML, JSON, and deployment ownership.
Cover of Google Anthos in Action
liveBookmanning.com
Read Google Anthos in Action on liveBook Get the book at manning.com

This explainer was generated by Manning's knowledge graph from the text of Google Anthos in Action. The section links point to the parts of the book it draws on.