Environ requirements and best practices

This guide provides best practices, practical considerations, and recommendations for implementing environs in your organization.

Before reading this guide, you should be familiar with the concepts in Introducing environs. We recommend reading this guide before looking at our examples.

Component requirements

There are some limitations to consider when implementing environs based on the environ-aware Anthos and Google Cloud components that your organization wants to use. For example, some components might not yet support working with clusters that aren't in the environ host project.

The following table shows each component's current requirements and limitations.

Component
Cluster types
Project requirements
VPC requirements
Anthos Config Management All Anthos and GKE supported clusters None None
Config Sync GKE on Google Cloud clusters None None
Anthos Service Mesh
on Google Cloud

Anthos clusters on Google Cloud

Note: Currently only single-cluster meshes are supported; multi-cluster mesh functionality is coming soon.

None N/A
Anthos Service Mesh
on-premises

GKE on-prem clusters

Note: Currently only single-cluster meshes are supported; multi-cluster mesh functionality is coming soon.

Cluster must be registered to an environ. N/A
Ingress for Anthos Anthos clusters running on Google Cloud Ingress resources, GKE clusters, and environ must share the same project. Ingress resources and GKE clusters must be in the same VPC network.
Workload identity pools Optimized for Anthos, GKE on Google Cloud, and GKE on-prem. With Anthos, other Kubernetes clusters are supported, but require manual setup work. None None

Organizing projects and VPC networks for environs

When architecting for environs, you need to consider two fundamental resources: Google Cloud projects and Virtual Private Cloud (VPC) networks.

As noted in Introducing environs, each environ is created within a single project. However (with the limitations noted in the previous table), environs are intended to work with environ-aware resources from the environ host project, another Google Cloud project, other cloud providers, or on-premises.

While not explicitly prevented, we also recommend that environ-aware resources in the same project be added to the same environ; they should not be split among different environs. Splitting resources in the same project across environs is considered an anti-pattern because the project boundary provides stronger protections for policy and governance purposes.

When deciding how to place environ-aware resources in multiple projects, we anticipate that many organizations will have different tenancy requirements. Consider the following two extremes:

  • Some organizations might choose to place all environ-resources in a handful of centrally-controlled projects, allocating namespaces to teams.
  • Other organizations might choose to give teams their own dedicated clusters or virtual machine (VM) resources within their teams' own projects.

In the first extreme, it is easier to maintain centralized governance over the resources, but it might require additional work to attain the desired isolation. In the second extreme, these tradeoffs are reversed. In some complex cases, your organization might have a mixture of both shared infrastructure resources and dedicated ones, isolated in separate projects. No matter where you end up, as we discuss in our High trust section, maintaining mutual trust over the resources registered to an environ is important to maintaining the integrity of the environ.

Closely related to project organization is network organization. Several environ components, as noted in the component requirements table, require specific connectivity between registered resources in the environ. Over time, some of these requirements might be relaxed; however, for example, today Ingress for Anthos requires that pods be in the same VPC network, with the clusters themselves being in the same project as the environ.

When components can loosen these initial project and VPC network requirements, we anticipate that adopting a Shared VPC model will become a best practice whenever you require multiple projects. In such a model, the environ can be instantiated in the VPC network's host project with resources registered from their respective service projects. If you require multiple environs with a Shared VPC, you can nominate projects to be the environ host project.

Adding/removing environ resources (clusters)

Existing environ-aware resources can be added to an environ, but special care must be taken to ensure that services are not disrupted as a result of being added. In particular, it is important to ensure that the sameness and trust properties are considered before adding the resource to the environ. The environ administrator should pay special attention to how active environ components use sameness. This might require migrating to consistent naming practices, establishing governance of the resource, or potentially performing other actions before adding the resource to the environ.

Removing resources from an environ also requires some additional attention. For example, resources that are actively part of a service mesh or targeted as part of a multi-cluster load balancer will be impacted. To prepare for removing the resource, we recommend reviewing each component that you have enabled on your environ, and taking any necessary steps to drain active service mesh traffic or external traffic.

As environs evolve, we will provide more in-band guidance when adding and removing environ resources.

Enabling or reconfiguring environ components

Enabling or reconfiguring Google Cloud or Anthos components that use environs also requires some special care. When enabling new components, pay attention to the potential side effects of enabling the component on all clusters. For example, before enabling Anthos Service Mesh, understand which service endpoints are merged across resources, and ensure that this is the desired result.

We will provide further in-band guidance when configuring environ-enabled components as we evolve the environ concept.

What's next?

  • For some hypothetical scenarios that illustrate the considerations described in this guide, see Environ examples.