Security Warning This tutorial is not for production use. By default, the chart will install an insecure configuration of Consul. Please refer to the to determine how you can secure Consul on Kubernetes in production. Additionally, it is highly recommended to use a properly secured Kubernetes cluster or make sure that you understand and enable the recommended security features.

To complete this tutorial successfully, you should have an Azure account with the ability to create a Kubernetes cluster.

All the tools you need are installed in the Azure Cloud Shell. Visit the to run this example.

NOTE: This example uses the latest version of Helm and kubectl, which are installed with the Azure Cloud Shell.

At least a three node AKS cluster is required to deploy Consul using the official Consul Helm chart or the Consul K8S CLI. Create a three node cluster on AKS by following the the AKS documentation.

Configure kubectl to talk to your cluster

Login to the Azure Shell on your console.

Verify you are connected to your Kubernetes cluster.

  1. $ kubectl cluster-info
  2. Kubernetes control plane is running at <your AKS ip(s)>
  3. CoreDNS is running at https://<your AKS ip(s)>/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
  4. Metrics-server is running at https://<your AKS ip(s)>/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy
  6. To further debug and diagnose cluster problems, use the command`kubectl cluster-info dump`.
  1. $ kubectl cluster-info
  2. Kubernetes control plane is running at <your AKS ip(s)>
  3. CoreDNS is running at https://<your AKS ip(s)>/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
  4. Metrics-server is running at https://<your AKS ip(s)>/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy
  6. To further debug and diagnose cluster problems, use the command`kubectl cluster-info dump`.

You can deploy a complete Consul datacenter using the official Consul Helm chart or the Consul K8S CLI. By default, these methods will install a total of three Consul servers as well as one client per Kubernetes node into your AKS cluster. You can review the Consul Kubernetes installation documentation to learn more about these installation options.

To customize your deployment, you can pass a yaml file to be used during the deployment; it will override the Helm chart’s defaults. The following values change your datacenter name and enable the Consul UI via a service.

  1. global:
  2.   name: consul
  3.   datacenter: hashidc1
  4. ui:
  5.   enabled: true
  6.   service:
  7.     type: LoadBalancer

helm-consul-values.yaml

  1. global:
  2.   name: consul
  3. ui:
  4.   enabled: true
  5.   service:
  6.     type: LoadBalancer

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.

AKS (Azure) - 图3

  1. $ helm repo add hashicorp https://helm.releases.hashicorp.com
  2. "hashicorp" has been added to your repositories
  1. $ helm repo add hashicorp https://helm.releases.hashicorp.com
  2. "hashicorp" has been added to your repositories

Note: You can review the official Helm chart values to learn more about the default settings.

Run the command kubectl get pods to verify the Consul resources were successfully created.

  1. $ kubectl get pods --namespace consul
  2. NAME                  READY   STATUS    RESTARTS   AGE
  3. consul-client-nc6mc   1/1     Running   0          63s
  4. consul-client-p6w4p   1/1     Running   0          63s
  5. consul-client-sbf59   1/1     Running   0          63s
  6. consul-server-0       1/1     Running   0          63s
  7. consul-server-1       1/1     Running   0          63s
  8. consul-server-2       1/1     Running   0          63s
  1. $ kubectl get pods --namespace consul
  2. NAME                  READY   STATUS    RESTARTS   AGE
  3. consul-client-nc6mc   1/1     Running   0          63s
  4. consul-client-p6w4p   1/1     Running   0          63s
  5. consul-client-sbf59   1/1     Running   0          63s
  6. consul-server-0       1/1     Running   0          63s
  7. consul-server-1       1/1     Running   0          63s
  8. consul-server-2       1/1     Running   0          63s

Since you enabled the Consul UI in your values file, you can run the command kubectl get services to find the load balancer DNS name or external IP of your UI service.

  1. $ kubectl get services --namespace consul
  2. NAME            TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)                                                                   AGE
  3. consul-dns      ClusterIP      10.0.123.243   <none>          53/TCP,53/UDP                                                             114s
  4. consul-server   ClusterIP      None           <none>          8500/TCP,8301/TCP,8301/UDP,8302/TCP,8302/UDP,8300/TCP,8600/TCP,8600/UDP   114s
  5. consul-ui       LoadBalancer   10.0.118.0     20.72.249.50   80:31759/TCP                                                              114s                                                              6m59s
  1. $ kubectl get services --namespace consul
  2. NAME            TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)                                                                   AGE
  3. consul-server   ClusterIP      None           <none>          8500/TCP,8301/TCP,8301/UDP,8302/TCP,8302/UDP,8300/TCP,8600/TCP,8600/UDP   114s
  4. consul-ui       LoadBalancer   10.0.118.0     20.72.249.50   80:31759/TCP                                                              114s                                                              6m59s

You can verify that, in this case, the UI is exposed at http://20.72.249.50 over port 80. Navigate to the external IP or load balancer DNS name in your browser to interact with the Consul UI.

Click the Nodes tab and you can observe several Consul servers and agents running.

In addition to accessing Consul with the UI, you can manage Consul by directly connecting to the pod with kubectl.

You can also use the Consul HTTP API by communicating to the local agent running on the Kubernetes node. Feel free to explore the if you are interested in learning more about using the Consul HTTP API with Kubernetes.

To access the pod and data directory you can remote execute into the pod with to start a shell session.

  1. $ kubectl exec --stdin --tty consul-server-0 --namespace consul -- /bin/sh
  1. $ kubectl exec --stdin --tty consul-server-0 --namespace consul -- /bin/sh

This will allow you to navigate the file system and run Consul CLI commands on the pod. For example you can view the Consul members with the consul members command.

  1. / $ consul members
  2. Node                               Address          Status  Type    Build   Protocol  DC        Partition  Segment
  3. consul-server-0                    10.244.2.5:8301  alive   server  1.11.4  2         hashidc1  default    <all>
  4. consul-server-1                    10.244.1.7:8301  alive   server  1.11.4  2         hashidc1  default    <all>
  5. consul-server-2                    10.244.0.9:8301  alive   server  1.11.4  2         hashidc1  default    <all>
  6. aks-agentpool-13677108-vmss000000  10.244.2.4:8301  alive   client  1.11.4  2         hashidc1  default    <default>
  7. aks-agentpool-13677108-vmss000001  10.244.1.6:8301  alive   client  1.11.4  2         hashidc1  default    <default>
  8. aks-agentpool-13677108-vmss000002  10.244.0.8:8301  alive   client  1.11.4  2         hashidc1  default    <default>

When you have finished interacting with the pod, exit the shell.

  1. $ exit
  1. $ exit

Using Consul environment variables

You can also access the Consul datacenter with your local Consul binary by enabling environment variables. You can read more about Consul environment variables documented .

In this case, since you are exposing HTTP via the load balancer/UI service, you can export the CONSUL_HTTP_ADDR variable to point to the load balancer DNS name (or external IP) of your Consul UI service:

  1. $ export CONSUL_HTTP_ADDR=http://20.72.249.50:80
  1. $ export CONSUL_HTTP_ADDR=http://20.72.249.50:80

You can now use your local installation of the Consul binary to run Consul commands:

  1. $ consul members
  2. Node                               Address          Status  Type    Build   Protocol  DC        Partition  Segment
  3. consul-server-0                    10.244.2.5:8301  alive   server  1.11.4  2         hashidc1  default    <all>
  4. consul-server-1                    10.244.1.7:8301  alive   server  1.11.4  2         hashidc1  default    <all>
  5. consul-server-2                    10.244.0.9:8301  alive   server  1.11.4  2         hashidc1  default    <all>
  6. aks-agentpool-13677108-vmss000000  10.244.2.4:8301  alive   client  1.11.4  2         hashidc1  default    <default>
  7. aks-agentpool-13677108-vmss000001  10.244.1.6:8301  alive   client  1.11.4  2         hashidc1  default    <default>
  8. aks-agentpool-13677108-vmss000002  10.244.0.8:8301  alive   client  1.11.4  2         hashidc1  default    <default>
  1. $ consul members
  2. Node                               Address          Status  Type    Build   Protocol  DC        Partition  Segment
  3. consul-server-0                    10.244.2.5:8301  alive   server  1.11.4  2         hashidc1  default    <all>
  4. consul-server-1                    10.244.1.7:8301  alive   server  1.11.4  2         hashidc1  default    <all>
  5. consul-server-2                    10.244.0.9:8301  alive   server  1.11.4  2         hashidc1  default    <all>
  6. aks-agentpool-13677108-vmss000000  10.244.2.4:8301  alive   client  1.11.4  2         hashidc1  default    <default>
  8. aks-agentpool-13677108-vmss000002  10.244.0.8:8301  alive   client  1.11.4  2         hashidc1  default    <default>

In this tutorial, you deployed a Consul datacenter to the Azure Kubernetes Service (AKS) using the official Helm chart or Consul K8S CLI. You also configured access to the Consul UI. To learn more about deployment best practices, review the Kubernetes Reference Architecture tutorial.