Enable optional features on managed Anthos Service Mesh

This page describes how to enable optional features on a Google-managed Anthos Service Mesh control plane. For information on the in-cluster control plane, see Enabling optional features on the in-cluster control plane.

If you are using an IstioOperator based configuration today, the Migrate from IstioOperator tool can help convert to the configuration supported by the Google-managed control plane.

Envoy access logs

Run the following commands to enable Envoy access logging:

  1. Run the following command to add accessLogFile: /dev/stdout:

    cat <<EOF | kubectl apply -f -
    apiVersion: v1
    data:
      mesh: |-
        accessLogFile: /dev/stdout
    kind: ConfigMap
    metadata:
      name: istio-release-channel
      namespace: istio-system
    EOF
    

    where release-channel is your release channel (asm-managed, asm-managed-stable, or asm-managed-rapid).

  2. Run the following command to view the configmap:

    kubectl get configmap istio-release-channel -n istio-system -o yaml
    
  3. To verify that access logging is enabled, ensure sure the accessLogFile: /dev/stdout line appears in the mesh: section.

    ...
    apiVersion: v1
    data:
      mesh: |
        ....
        accessLogFile: /dev/stdout
    ...
    

Enable Cloud Tracing

Run the following commands to enable Cloud Trace:

  1. Run the following command:

    cat <<EOF | kubectl apply -f -
    apiVersion: v1
    data:
      mesh: |-
        defaultConfig:
          tracing:
            stackdriver: {}
    kind: ConfigMap
    metadata:
      name: istio-release-channel
      namespace: istio-system
    EOF
    

    where release-channel is your release channel (asm-managed, asm-managed-stable, or asm-managed-rapid).

  2. Run the following command to view the configmap:

    kubectl get configmap istio-release-channel -n istio-system -o yaml
    
  3. To verify that Cloud Trace is enabled, ensure sure the following lines appears in the mesh: section.

    ...
    apiVersion: v1
    data:
      mesh: |
        ....
        defaultConfig:
          tracing:
            stackdriver:{}
    ...
    
  4. Restart the proxies. Note that currently tracer configuration is part of the proxy bootstrap configuration, so each pod needs to restart and get re-injected to pick up the tracer update. For example, you can use the following command to restart pods that belong to a deployment:

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

For more information on supported trace headers please refer to Trace Context Propagation.

Distroless proxy image

As a best practice, you should restrict the contents of a container runtime to only the necessary packages. This approach improves security and the signal-to-noise ratio of Common Vulnerabilities and Exposures (CVE) scanners. Istio provides proxy images based on distroless base images.

The following configuration enables distroless images for the entire Anthos Service Mesh. An image type change requires each pod to restart and get re-injected to take effect.

     apiVersion: v1
     kind: ConfigMap
     metadata:
       name: istio-release-channel
       namespace: istio-system
     data:
       mesh: |-
         defaultConfig:
           image:
             imageType: distroless

The distroless proxy image does not contain any binaries other than the proxy. It is therefore not possible to exec a shell or use curl, ping, or other debug utilities inside the container. If you need access to these tools for a specific deployment, you may override the imageType by using the following pod annotation.

sidecar.istio.io/proxyImageType: debug

After changing the image type of a deployment via the annotation, the deployment should be restarted.

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

For most types of proxy debugging, istioctl proxy-cmd should be used which does not require a debug base image.