Version 1.11

Configure managed Anthos Service Mesh with asmcli x

Overview

Managed Anthos Service Mesh is a Google-managed control plane and an optional data plane that you simply configure. Google handles their reliability, upgrades, scaling and security for you in a backward-compatible manner.

This guide explains how to set up managed Anthos Service Mesh using the experimental command asmcli x. This command uses a custom resource in a Kubernetes cluster to install a managed control plane. This allows Google to manage the lifecycle of the managed control plane, ensuring updates are maintained over time.

The non-experimental command directly creates the managed control plane at run time and may require manual work to upgrade and maintain. To learn how to use asmcli to install managed Anthos Service Mesh, see Configure managed Anthos Service Mesh.

To learn about the supported features and limitations of managed Anthos Service Mesh, see Managed Anthos Service Mesh supported features.

Before you begin

Before starting this guide, you must:

  1. Check the requirements and limitations for Managed Anthos Service Mesh.
  2. Download the installation tool.

Get cluster credentials

Retrieve the appropriate credentials. The following command will also point the kubectl context to the target cluster.

gcloud container clusters get-credentials  CLUSTER_NAME \
    --zone LOCATION \
    --project PROJECT_ID

Apply the Google-managed control plane with asmcli experimental

asmcli x (experimental) uses a Google Cloud service currently in preview to provision and set up the control plane by applying a custom resource to the Kubernetes cluster.

GKE

./asmcli x install \
    -p PROJECT_ID \
    -l LOCATION \
    -n CLUSTER_NAME \
    --managed \
    --verbose \
    --output_dir CLUSTER_NAME \
    --enable-all

GKE Autopilot

Currently GKE Autopilot is only supported with Anthos Service Mesh rapid channel. The cluster needs to be in GKE rapid channel with version 1.21.3+. In order to adapt to the GKE Autopilot resource limit, the default proxy resource requests and limits are set to 500m CPU and 512 Mb memory.

./asmcli x install \
    -p PROJECT_ID \
    -l LOCATION \
    -n CLUSTER_NAME \
    --managed \
    --verbose \
    --output_dir CLUSTER_NAME \
    --use_managed_cni \
    --channel rapid \
    --enable-all

Verify the control plane has been provisioned

The asmcli tool creates a ControlPlaneRevision custom resource in the cluster. This resource's status is updated when the managed control plane is provisioned or fails provisioning. Inspect the status of the resource with the following command:

kubectl describe controlplanerevision asm-managed -n istio-system

The output is similar to:

  Name:         asm-managed

  …

  Status:
    Conditions:
      Last Transition Time:  2021-08-05T18:56:32Z
      Message:               The provisioning process has completed successfully
      Reason:                Provisioned
      Status:                True
      Type:                  Reconciled
      Last Transition Time:  2021-08-05T18:56:32Z
      Message:               Provisioning has finished
      Reason:                ProvisioningFinished
      Status:                True
      Type:                  ProvisioningFinished
      Last Transition Time:  2021-08-05T18:56:32Z
      Message:               Provisioning has not stalled
      Reason:                NotStalled
      Status:                False
      Type:                  Stalled

The Reconciled condition determines whether the managed control plane is running correctly. If true, the control plane is running successfully. Stalled determines whether the managed control plane provisioning process has encountered an error. If Stalled, the Message field contains more information about the specific error.

If you are installing Anthos Service Mesh for a GKE Autopilot cluster, the ASM CNI DaemomnSet will also be provisioned in your cluster. Inspect the status of the CNI Daemonset and check if ready instances matches desired instances with the following command:

kubectl get daemonset istio-cni-node -n kube-system

The output is similar to:

  NAME             DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
  istio-cni-node   13        13        13      13           13          kubernetes.io/os=linux   34m

ControlPlaneRevision Stalled Codes

There are multiple reasons the Stalled condition could become true in the ControlPlaneRevisions status.

Reason Message Description
PreconditionFailed Only GKE memberships are supported but ${CLUSTER_NAME} is not a GKE cluster. The current cluster does not appear to be a GKE cluster. Managed control plane only works on GKE clusters.
Unsupported ControlPlaneRevision name: ${NAME} The name of the ControlPlaneRevision must be one of the following:
  • asm-managed
  • asm-managed-rapid
  • asm-managed-stable
Unsupported ControlPlaneRevision namespace: ${NAMESPACE} The namespace of the ControlPlaneRevision must be istio-system.
Unsupported channel ${CHANNEL} for ControlPlaneRevision with name${NAME}. Expected ${OTHER_CHANNEL} The name of the ControlPlaneRevision must match the channel of the ControlPlaneRevision with the following:
  • asm-managed -> regular
  • asm-managed-rapid -> rapid
  • asm-managed-stable -> stable
Channel must not be omitted or blank Channel is a required field on the ControlPlaneRevision. It is missing or blank on the custom resource.
Unsupported control plane revision type: ${TYPE} managed_service is the only allow field for the ControlPlaneRevisionType field.
Unsupported Kubernetes version: ${VERSION} Kubernetes versions 1.15+ are supported.
Workload identity is not enabled Please enable workload identity on your cluster.
Unsupported workload pool: ${POOL} The workload pool must be of the form ${PROJECT_ID}.svc.id.goog.
Cluster project and environ project do not match Clusters must be part of the same project in which they are registered to the fleet.
ProvisioningFailed An error occurred updating cluster resources Google was unable to update your in-cluster resources such as CRDs and webhooks.
MutatingWebhookConfiguration "istiod-asm-managed" contains a webhook with URL of ${EXISTING_URL} but expected ${EXPECTED_URL} Google will not overwrite existing webhooks to avoid breaking your installation. Update this manually if it is desired behavior.
ValidatingWebhookConfiguration ${NAME} contains a webhook with URL of ${EXISTING_URL} but expected ${EXPECTED_URL} Google will not overwrite existing webhooks to avoid breaking your installation. Update this manually if it is desired behavior.

What's next?