Sample microservices for the web and api deployments are maintained at https://github.com/servicemeshbook/hello-echo the main.go is the web microservice, that calls the upstream API microservice through the use of the UPSTREAM_SERVICE environment variable.

Review the pod and service definition in the 11-web-deployment.yaml script:

...
  template:
    metadata:
      labels:
        app: web
      annotations:
        "consul.hashicorp.com/connect-inject": "true"
        "consul.hashicorp.com/connect-service-upstreams": "api:8081"
...
        env:
...
        - name: UPSTREAM_SERVICE
          value: "http://localhost:8081"

Note the consul.hashicorp.com/connect-service-upstreams annotation in the preceding definition, which points to the Consul service-defaults primitive api with the http protocol using port 8081, which we created previously. The web microservice calls an upstream microservice through the use of the UPSTREAM_SERVICE environment variable, which we point to the same 8081 port on the localhost. The Consul agent is responsible for connecting the web microservice at port 8081 to the Consul service-defaults API, which in turn will connect to a subset defined through the Consul service-resolver primitive we created in the previous steps. We will see how a subset connects to a proper API pod when we define the api deployment later. 

First, we deploy a web microservice. Perform the following steps to do so:

1. Create a Kubernetes deployment and the service for the web:

$ kubectl -n consul apply -f 11-web-deployment.yaml 
service/web created
deployment.apps/web created

The Kubernetes service web endpoint is a web pod.

2. Now, check the web pod and web service:

$ kubectl -n consul get pods -l app=web
NAME                  READY  STATUS    RESTARTS  AGE
web-7dc47f6678-fcnzv  2/2    Running   0         40s

$ kubectl -n consul get svc web
NAME  TYPE      CLUSTER-IP     EXTERNAL-IP PORT(S)         AGE
web   NodePort  10.111.32.161  <none>      8080:30145/TCP  43s

Note that the Kubernetes principle as followed, links the web service to the web pod. For the api deployment, which is the upstream service for the web, the Consul agent calls the api service through the use of the UPSTREAM_SERVICE environment variable.

Next, we'll deploy two versions of the api microservice. Note that both versions are identical. The purpose here is to illustrate Consul's traffic shifting concepts. 

3. Review the 12-api-v1-deployment.yaml script for the annotation description that links the Consul api service to the Kubernetes api-deployment:

# Script: 12-api-v1-deployment.yaml

... 
template:
    metadata:
      labels:
        app: api-v1
      annotations:
        "consul.hashicorp.com/connect-inject": "true"
        "consul.hashicorp.com/service-meta-version": "1"
        "consul.hashicorp.com/service-tags": "v1"
...

4. Review the 13-api-v2-deployment.yaml script to link the Consul api service to the Kubernetes api-deployment:

# Script: 13-api-v2-deployment.yaml

...
template:
    metadata:
      labels:
        app: api-v1
      annotations:
        "consul.hashicorp.com/connect-inject": "true"
        "consul.hashicorp.com/service-meta-version": "2"
        "consul.hashicorp.com/service-tags": "v2"
...

5. Compare the scripts in step 3 and step 4.

Note that the consul.hashicorp.com/service-meta-version annotation is set to 1 and 2, while consul.hashicorp.com/service-tags is set to v1 and v2, respectively. Refer to the Consul primitive service-resolver API we created in the previous step (10-service-resolver-api.hcl):

subsets = {
  v1 = {
    filter = "Service.Meta.version == 1"
  }
  v2 = {
    filter = "Service.Meta.version == 2"
  }
}

We can see that the v1 subset is linked to the consul.hashicorp.com/service-tags annotation we defined in the API deployment. Service-Meta-version is linked to the consul.hashicorp.com/service-meta-version annotation.

6. Create the api-v1 and api-v2 services and deployments:

$ kubectl -n consul apply -f 12-api-v1-deployment.yaml 
service/api-v1 created
deployment.apps/api-v1 created

$ kubectl -n consul apply -f 13-api-v2-deployment.yaml 
service/api-v2 created
deployment.apps/api-v2 created

With this, we have created the api-v1 and api-v2 Kubernetes deployments.

7. Check the api-v1 service at node port 30146:

$ curl http://localhost:30146
===============================================
Request time : 2019-09-23 14:33:12.92445239 +0000 UTC
Requested path : /
Host IP : 192.168.142.101
Pod IP : 192.168.230.246
Pod Name : api-v1-7fcf5d98d4-tgqrk
Pod Namespace : consul
Host : localhost:30146
RemoteAddr : 192.168.142.101:44900
===============================================

8. Similarly, check the api-v2 service at node port 30147:

$ curl http://localhost:30147
===============================================
Request time : 2019-09-23 14:33:15.979164994 +0000 UTC
Requested path : /
Host IP : 192.168.142.101
Pod IP : 192.168.230.205
Pod Name : api-v2-5d64d5f8ff-zlcp6
Pod Namespace : consul
Host : localhost:30147
RemoteAddr : 192.168.142.101:40690
===============================================

Note that the api-v1 and api-v2 Kubernetes services are not used by Consul for traffic management.  Actually, the Consul service api is used for that purpose – please refer to the consul.hashicorp.com/connect-service-upstreams annotation defined in 11-web-deployment.yaml for more information.

The sample microservice that we have just deployed will help us understand the various traffic management features of Consul. We will explore these features one by one in the next section.