What are advantages use consul in kubernetes (use cases without Service Mesh)

Consul
1

What are advantages use consul in kubernetes (use cases without Service Mesh and consul connect)?

We are looking only use case - Service Discovery and Health Checking + KV

Not included use cases:

  • Network Infrastructure Automation
  • Multi-Platform Service Mesh

I read official comparison kubernetes vs consul and I can’t understand what are advantages of using consul clients + servers. Let’s take a look of what we have with consul and kubernetes:

  1. Service discovery: Consul – Yes, Kubernetes – Yes

  2. Health Checking: Consul – Yes, Kubernetes – Yes

  3. Key/Value Storage: Consul – Yes. Kubernetes – Yes, but maybe little bit less flexible out of the box than in consul

If I’m correct install consul to kubernetes (no valt, no consul connect) make no sense if all application works in the k8s?

Maybe only if there are applications that works outside the k8s and connect them to consul into kuberenetes for 1-3 purposes that described above.

But now it’s little bit unclear to understand how applications outside k8s cluster (that register in k8s consul) will be communicate with outer app in k8s because ip pods network is private in k8s is private with no directly access outside by-default.
If it can be possible so we can achieve Service Discovery K8S Consul + Service Discovery outside K8S into one big connected SD or maybe more and included Health Checking and KV on both sides

2

Hi @1Const1,

That’s a great question, thanks for bringing this up!

You are right that Kubernetes has built-in service discovery and health checking. And you are also correct that Consul is mostly useful when you have a more complicated setup, either if your environment is heterogeneous, i.e. when you have some apps on Kubernetes and some on another platform (VMs or something else), or if you have a multi-cluster setup where you have apps that need to talk to each other across Kubernetes clusters. You could also do other interesting things with a multi-cluster setup, for example, you could set up Consul to do geo failover to a different Kube cluster.

One thing to note is that on Kubernetes we have the catalog sync feature that syncs Kubernetes services to Consul for you. You could read more about how we’re syncing Kubernetes services here.

With regards to you question about how to enable an app outside of k8s to communicate to an app inside k8s, I’d say it really depends on your network architecture. Under the hood, Consul service discovery still relies on having network connectivity between the two networks - one with the app outside of k8s and one of the k8s networks (either pod or node network). Depending on your network setup, you could choose the type of service that works best for your setup. There are a couple of scenarios I can think of:

  1. Many cloud providers by default use routable pod networks (for example, EKS by default uses AWS VPC CNI), and so you could enable this communication via firewall rules and VPC peering. You could then expose your app with a ClusterIP service, and catalog sync will automatically sync that service into consul pointing to Pod IPs. You could then use Consul service discovery to route to it from your app outside of k8s.
  2. If you don’t have a routable pod network, you could then open network communication between your Kubernetes nodes and your external app. Consul catalog sync will automatically sync services of type NodePort pointing to the Node IP where your pod is running. You use Consul service discovery to reach it from outside of the cluster.
  3. You could also have a load balancer in front of your service. Depending on the type of load balancer, you might not need to open any network connectivity. Sync catalog will create a service pointing to the load balancer IP or hostname. If all your services are load balancer services, then you probably don’t necessarily need Consul and could use something like Kubernetes external DNS.

Hope this makes sense!

1 Like