Exploring the Service Discovery Features of Consul

One of the most powerful features of Consul is that you can build a service mesh using a heterogeneous environment spanning multiple data centers. In this chapter, we will cover Consul Connect and use this method to form a service registration process with sidecar proxy injection in a Kubernetes environment. Consul also allows us to perform this in a non-Kubernetes environment, such as a workload running in a VM. However, since we are only focusing on cloud-native workloads in a Kubernetes environment, it is outside the scope of this book to cover Consul's service mesh extension for legacy workloads.

First, we will install a demo application and then perform some hands-on exercises in order to explore the features of Consul Connect from a service discovery standpoint.

To understand Consul's service discovery features...

Technical requirements

In order to complete the exercises in this chapter, you need to install Consul on your VM and Kubernetes environment, as detailed in the previous chapter. Once you have installed Consul, you can follow the exercises in this chapter.

We are only focusing on running Consul in a Kubernetes environment. Refer to https://github.com/hashicorp/demo-consul-101 to get hands-on with Consul Connect while using non-Kubernetes workloads.

Installing a Consul demo application

To explore the service mesh capabilities of Consul through a Kubernetes environment, we will install a demo application that is available from Hashicorp. This demo uses two simple services: a counting service and a frontend web UI service (connects to the counting service to show the results). Let's get started:

1. Let's take a look at the counting pod definition, which shows counting and a counting-init container:

# Counting pod

apiVersion: v1
kind: Pod
metadata:
  name: counting
  annotations:
    "consul.hashicorp.com/connect-inject": "true"
spec:
  containers:
  - name: counting
    image: hashicorp/counting-service:0.0.2
    ports:
    - containerPort: 9001
      name: http
  initContainers:
  - name: counting-init
    image: hashicorp/counting-init:0.0.9
    env:
    - name: POD_IP
      valueFrom:
        fieldRef:
         ...

Service discovery

The service discovery process in Consul is integrated with health checks, DNS, and HTTP interfaces. The Consul agent registers the service by adding an entry to the key-value store. When service discovery information is available in the Consul key-value store, that service can be discovered by other services.

In Consul, the process of service discovery uses a registry to keep a real-time list of services, their health, and their location information. It has the ability to find the location of upstream services so that the connection to it is transparent without a need for an external load balancer. However, a load balancer may be required for Ingress traffic coming to the service mesh from outside.

Consul has two approaches to service discovery, as follows:

• Sidecar proxy: Consul connects services to each other by using sidecar proxies to form a service mesh...

Implementing mutual TLS

The communication between services is encrypted through sidecar proxies using mutual TLS. Each service is provided an identity through the SPIFFE X.509 certificate (please refer to Chapter 5, Service Mesh Interface and SPIFFE, for a discussion on SPIFFE). Since the services are not tied to fixed IP addresses, the SPIFFE-based identity can be used to connect and accept requests between SPIFFE-compliant services.

Consul has a built-in Certificate Authority, through which it assigns leaf certificates to sidecar proxies. These sidecar proxies can be configured for upstream configuration to specify alternate data centers that services can access for high availability. The CA federation can be enabled between multiple data centers. The CA federation helps the alternate data center to continue issuing leaf SPIFFE X509 certificates in the case of WAN disruptions...

Exploring intentions

Intentions are access controls in Consul that are used to define accessibility to various services. Intentions can be defined either through a UI, CLI, or through REST API calls. Once the intentions have been defined, they are enforced by the sidecar proxies to allow or disallow connections between services. For example, you may want to restrict access to the database backend services, but only for the services that have legitimate access requirements. This prevents unauthorized access to a service.

Intentions, once defined, can be replicated across data centers, and they are cached locally so that inbound connections can be allowed if there is a disruption in a service that stops reaching the Consul service.

Let's learn how to create an intention so that we can allow connections from the dashboard to the counting service:

1. Click Intentions on the top...

Exploring the Consul key-value store

Consul's key-value store is a persistent layer that allows users to store configuration parameters and the metadata of services within a data center. The Consul Replicate (https://github.com/hashicorp/consul-replicate) tool can be used to perform cross-data center K/V asynchronous replication.

Consul's kv command is used to interact with the Consul K/V store via the command line to insert, update, and delete operations. The K/V store is also accessible through the HTTP API. The key-value can be monitored through watches, which can invoke handlers to take a specific action.

Let's go through an example of how to store key-values:

1. We need to use a command-line tool to store values in a key-value store. Note that the keys are stored by separating its path components with a forward slash. This represents a tree structure, which can...

Securing Consul services with ACL

By default, Access Controls Lists (ACLs) are disabled in the Kubernetes Helm chart, and they need to be enabled explicitly. Please refer to https://learn.hashicorp.com/consul/security-networking/production-acls to learn how to enable ACL.

ACLs are used to secure the servers, clients, services, DNS, Consul key-values, and UIs. ACLs operate by grouping rules into policies, then associating one or more policies with a token. To manage ACL, you can use the consul acl command. Alternatively, ACLs can be managed through HTTP APIs. Please refer to https://www.consul.io/api/acl/acl.html for more information.

Next, we'll learn how to monitor Consul and collect metrics.

Monitoring and metrics

Monitoring and collecting metrics play a very important role in keeping the system healthy and up and running. Consul can be monitored using the consul monitor command. Let's take a look:

1. Run the consul monitor command:

$ consul monitor
2019/08/27 02:24:12 [INFO] agent: Synced service "counting-counting-sidecar-proxy"
2019/08/27 02:24:12 [INFO] agent: Synced service "dashboard-dashboard-sidecar-proxy"
2019/08/27 02:25:24 [INFO] agent: Synced service "counting-counting-sidecar-proxy"
2019/08/27 02:25:24 [INFO] agent: Synced service "dashboard-dashboard-sidecar-proxy"
2019/08/27 02:26:29 [INFO] agent: Synced service "counting-counting-sidecar-proxy"
2019/08/27 02:26:29 [INFO] agent: Synced service "dashboard-dashboard-sidecar-proxy"

2. Press Ctrl + C to exit from the preceding consul monitor command...

Registering an external service

We can register an external service with a built-in /health REST endpoint. The Consul dashboard or the Consul monitor command can invoke the /health endpoint to monitor the health of the external service. This feature makes Consul useful for integration purposes.

Let's understand this through an example.

In this section, we will extract a go binary from the counting microservice and run it on the VM host as a systemd service. Copy the counting-service Go binary from the counting pod's /app directory to the host's home directory and then make it executable. Now, follow these steps:

1. Extract the counting service binary and copy it to the VM:

$ kubectl -n consul -c counting cp counting:counting-service ~/counting-service
$ chmod +x ~/counting-service
$ sudo cp ~/counting-service /bin

2. Define a systemd service in the local VM in order...

Summary

In this chapter, we covered Consul in a Kubernetes environment. We covered service discovery, intentions, mTLS, key-value stores, and external services registration. It is important to note that Consul works in heterogeneous environments spanning multiple data centers. This makes it a very good candidate for service discovery and for providing mTLS out of the box while covering both Kubernetes as well as non-Kubernetes environments.

You can use this service discovery knowledge process to build a catalog of enterprise services so that your cloud-native applications can discover and use them.

In the next chapter, we will go through the traffic management capabilities of Consul Connect in the Kubernetes environment. You will learn how easy it is to shift and route traffic between different versions of the same service.

Questions

1. Consul Connect is the service mesh for Kubernetes.

A) True
B) False)

2. Consul Connect uses sidecar proxies for services either through native app integration or automatic injection.

A) True
B) False

3. Consul intentions are authorizations for services.

A) True
B) False

4. Consul's K/V store is replicated across data centers automatically.

A) True
B) False

5. Consul mTLS from a sidecar proxy to another sidecar proxy is fully automatic.

A) True
B) False

6. Consul comes with its own Certificate Authority so that it can issue certificates to sidecar proxies.

A) True
B) False

7. Consul integration with Kubernetes for service discovery is done by defining a Consul DNS server as an upstream DNS in the Kubernetes CoreDNS configuration.

A) True
B) False

Further reading

• Hashicorp/Demo-Consul-101. GitHub, 2019: https://github.com/hashicorp/demo-consul-101/tree/master/k8s
• Introduction to HashiCorp Consul Connect with Kubernetes, Huysmans, C. (2019), available at https://medium.com/hashicorp-engineering/introduction-to-hashicorp-consul-connect-with-kubernetes-d7393f798e9d, accessed 12 May 2019
• Nicholasjackson/Demo-Consul-Service-Mesh, GitHub, 2019: https://github.com/nicholasjackson/demo-consul-service-mesh
• Hashicorp/Consul-Demo-Traffic-Splitting, GitHub, 2019: https://github.com/hashicorp/consul-demo-traffic-splitting