Inject the Envoy proxy

The first step to work with the appmesh-injector component is to tag the appmesh-workshop-ns namespace so we will have the envoy sidecar being injected in the application pods:

kubectl label namespace appmesh-workshop-ns

Now, let’s restart the pods in order to add the Envoy proxy to them using the App Mesh injector component, which is already installed.

To do so, run the following command:

# Restart pods
kubectl delete pods -n appmesh-workshop-ns --all

This command will restart all the pods present in the appmesh-workshop-ns namespace. Note that this command should not be used in a production environment and we are only using it now because we just have one deployment running in this namespace.

After restarting all the pods, you can check if the envoy proxy was added to it with the following commands:

# Get a single pod name
NODEJS_POD=$(kubectl get pod --no-headers=true -o \
  name -n appmesh-workshop-ns | \
  awk -F "/" '{print $2}' | \
  head -n 1)

# Describe pod configuration
kubectl describe pod $NODEJS_POD -n appmesh-workshop-ns

Take a look in the output of this command. You should see the Envoy container image as part of your pod:

    Container ID:   docker://5a1e9b03d8c89e6db4797010b1970ee8f1ee930c565990960f7753a06a912970
    Image ID:       docker-pullable://
    Port:           9901/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Wed, 06 Nov 2019 02:20:56 +0000
    Ready:          True
    Restart Count:  0
      cpu:     10m
      memory:  32Mi
      APPMESH_VIRTUAL_NODE_NAME:  mesh/appmesh-workshop/virtualNode/nodejs-application-appmesh-workshop-ns
      APPMESH_PREVIEW:            0
      ENVOY_LOG_LEVEL:            info
      AWS_REGION:                 us-west-2
    Mounts:                       <none>

It means that the injector is working fine and the Envoy is already running inside your NodeJS pod.

Now, it’s time to test and see if the responses are being sent by the Envoy proxy. Let’s access one of the EC2 instances serving the frontend again:

AUTO_SCALING_GROUP=$(jq < cfn-output.json -r '.RubyAutoScalingGroupName');
TARGET_EC2=$(aws ec2 describe-instances \
    --filters Name=tag:aws:autoscaling:groupName,Values=$AUTO_SCALING_GROUP | \
  jq -r ' .Reservations | first | .Instances | first | .InstanceId')
aws ssm start-session --target $TARGET_EC2

And curl the NodeJS microservice:

curl -v http://nodejs.appmeshworkshop.hosted.local:3000/

You should see a response comming from the NodeJS microservice running in the EKS cluster. In this response, look for envoy in the server parameter:

*   Trying
* Connected to nodejs.appmeshworkshop.hosted.local ( port 3000 (#0)
> GET / HTTP/1.1
> Host: nodejs.appmeshworkshop.hosted.local:3000
> User-Agent: curl/7.61.1
> Accept: */*
< HTTP/1.1 200 OK
< x-powered-by: Express
< content-type: text/plain; charset=utf-8
< content-length: 65
< etag: W/"41-Cr+iGiCIiMfq96LyNt+F6PjOvZs"
< date: Fri, 08 Nov 2019 19:20:23 GMT
< x-envoy-upstream-service-time: 3
< server: envoy
Node.js backend: Hello! from in AZ-c commit 4252202
* Connection #0 to host nodejs.appmeshworkshop.hosted.local left intact

This means that the responses from the NodeJS application are passing in the Envoy proxy.

  • Terminate the session.