Consul Service Discovery and Mesh on Kubernetes in Docker (kind)
In this tutorial, you will create a local Kubernetes cluster with kind
, then deploy a Consul datacenter to your kind
cluster with HashiCorpβs official Helm chart or the Consul K8S CLI. After deploying Consul, you will interact with Consul using the CLI, UI, and/or API. You will then deploy two services that use Consul to discover and communicate with each other.
Prerequisites
For this tutorial, you will need:
Create a Kind cluster
With kind
you can quickly create a local Kubernetes cluster. By default, kind
names your cluster "kind", but you may name it anything you like by specifying the --name
option. This tutorial assumes the cluster is named dc1
. Refer to the kind documentation for information about how to specify additional parameters using a yaml configuration file.
The output will be similar to the following.
Deploy Consul
You can deploy a complete Consul datacenter using the official Consul Helm chart or the Consul K8S CLI. The chart comes with reasonable defaults, however, you will override a few values to integrate more easily with kind
and enable useful features. You can review the Consul Kubernetes installation documentation to learn more about these installation options.
Create a values file
To customize your deployment, create a values.yaml
file to customization your Consul deployment.
Install Consul in your cluster
You can now deploy a complete Consul datacenter in your Kubernetes cluster using the official Consul Helm chart or the Consul K8S CLI.
Confirm the installation details when prompted by the installer.
Note
You can review the official Consul K8S CLI documentation to learn more about additional settings.
Run the command kubectl get pods
to verify the Consul resources were successfully created.
Configure your CLI to interact with Consul cluster
In this section, you will set environment variables in your terminal so your Consul CLI can interact with your Consul cluster. The Consul CLI reads these environment variables for behavior defaults and will reference these values when you run consul
commands.
Tokens are artifacts in the ACL system used to authenticate users, services, and Consul agents. Since ACLs are enabled in this Consul datacenter, entities requesting access to a resource must include a token that is linked with a policy, service identity, or node identity that grants permission to the resource. The ACL system checks the token and grants or denies access to resources based on the associated permissions. A bootstrap token has unrestricted privileges to all resources and APIs.
Retrieve the ACL bootstrap token from the respective Kubernetes secret and set it as an environment variable.
Set the Consul destination address. By default, Consul runs on port 8500
for http
and 8501
for https
.
Remove SSL verification checks to simplify communication to your Consul cluster.
Note
In a production environment, we recommend keeping this SSL verification set to true
. Only remove this verification for if you have a Consul cluster without TLS configured in development environment and demonstration purposes.
View Consul services
In this section, you will view your Consul services with the CLI, UI, and/or API to explore the details of your service mesh.
Open a separate terminal window and expose the Consul server with kubectl port-forward
using the consul-ui
service name as the target.
In your original terminal, run the CLI command consul catalog services
to return the list of services registered in Consul. Notice this returns only the consul
service since it is the only running service in your Consul cluster.
Agents run in either server or client mode. Server agents store all state information, including service and node IP addresses, health checks, and configuration. Client agents are lightweight processes that make up the majority of the datacenter. They report service health status to the server agents. Clients must run on every pod where services are running.
Run the CLI command consul members
to return the list of Consul agents in your environment.
All services listed in your Consul catalog are empowered with Consul's service discovery capabilities that simplify scalability challenges and improve application resiliency. Review the Service Discovery overview page to learn more.
Deploy services into your service mesh
Now that you have a running Consul service mesh, you can deploy services to it.
Deploy two demo services
You will now deploy a two-tier application made of a backend data service that
returns a number (the counting
service), and a frontend dashboard
that pulls
from the counting
service over HTTP and displays the number.
Create a deployment definition, service, and service account for the counting
service named counting.yaml
.
Create a deployment definition, service, and service account for
the dashboard
service named dashboard.yaml
.
Use kubectl
to deploy the counting and dashboard services.
To verify the services were deployed, run kubectl get pods
until you see both services are ready or refresh the Consul UI until you observe that the counting
and dashboard
services are running.
Test the demo application
Open a separate terminal window and expose the dashboard
UI with kubectl port-forward
using the dashboard
service name as the target.
Open http://localhost:9002 in your browser. Notice that the service will display a message that the "Counting Service is Unreachable", and the count will display as "-1". This is expected behavior as dashboard
cannot reach the counting
backend since you have not defined any intentions yet.
Create intentions
To see how intentions affect communication between the services in your service mesh, you will create intentions following the "least-privilege" principle that allow communication between your services.
Create a file named intentions.yaml
to define intentions that allow the dashboard
service to communicate with the counting
service.
Deploy the service intentions to allow the HashiCups services to interact with each other..
Confirm applied intentions
Open a separate terminal window and expose the dashboard
UI with kubectl port-forward
using the dashboard
service name as the target.
Check out the dashboard
UI at http://localhost:9002. Refresh the page and notice that the application is now fully functional. It will display the dashboard
UI with a number retrieved from the counting
service using Consul service discovery and service mesh functionality.
Clean up
Run kind delete cluster
to clean up your local demo environment.
Next steps
In this tutorial, you deployed a Consul datacenter onto a kind
cluster. After deploying Consul, you interacted with Consul using the CLI, UI, and API. Finally, you deployed two services that use Consul to discover and communicate with each other.
Feel free to explore these tutorials and collections to learn more about Consul service mesh, microservices, and Kubernetes security.