KubeCon 2020: HashiCorp Consul Further Expands Kubernetes Support

KubeCon North America kicks off this week and with it, we’re pleased to announce a new release candidate for HashiCorp Consul 1.9. Consul 1.9 was announced at HashiConf US last month and contains a number of improvements aimed at improving observability in the UI, adding more granular controls for managing service to service connections, and expands Kubernetes support to create a more Kube-native experience for developers. In this blog, we’ll provide a quick overview of these features and explore some of the previously announced features from Consul 1.8 that make Consul a great fit for organizations implementing a service mesh on Kubernetes.

»Consul 1.8: Gateways Galore

Consul 1.8 announced three major enhancements to its gateway offerings: ingress gateways for managing inbound requests from non-mesh services, terminating gateways for facilitating traffic to external services, and WAN federation over mesh gateways to simplify connectivity between Consul datacenters. Gateways enable consistent communication across all services and can help organizations extend interaction between Kubernetes and non-Kubernetes environments. This is crucial because while service mesh is typically the desired end point for application focused organizations, there are still critical applications that cannot (or should not) be incorporated into the mesh, but ultimately still need to interact with mesh services. For more information about these features and to help users get started, we’ve recently published a number of blogs and learn guides on each.

»Consul 1.9 CRDs, OpenShift, and Health Checks

Where Consul 1.8 was about ensuring consistent connectivity between mesh and non-mesh services, Consul 1.9 put a lot of focus on the Kubernetes user experience. The features in this release address some gaps that our users have identified and create better onboarding and interaction for Kubernetes developers.

Kubernetes developers are very familiar with using Custom Resource Definitions (CRDs) to manage and make changes to resources within their environments. Previously, Consul did not support Kubernetes CRDs and as a result, Kubernetes operators would need to shift out of their typical operational mode and manage Consul in a non-Kubernetes way (either through the API, Terraform, or the Consul client binary). Consul 1.9 enables support of these CRDs by way of a controller deployed alongside Consul (using the Helm chart). Today these CRDs support intention configurations and managing traffic configurations. For more information about CRDs and how they work, read our docs.

Another challenge for Kubernetes users, solved in Consul 1.9, was the ability to easily install Consul on OpenShift environments. One of the main goals that we strive for with Consul is to provide a consistent experience for managing a service mesh regardless of what runtime that mesh is supporting. OpenShift is slightly different from other Kubernetes environments and previously it required more manual configuration to get Consul working on that platform. Consul 1.9 has simplified this process, making it easier to install Consul on OpenShift using the official Helm chart. For more information about our OpenShift support and other Helm configurations, read our docs.

Now that we've addressed installation and management of Consul on Kubernetes, there’s another key area that Consul 1.9 provides a new capability, observability. Consul 1.9 introduces a new service mesh visualization feature built directly into the Consul UI. As a part of this update, we’ve improved our integrations with both Prometheus and Grafana making it easier to aggregate, visualize, and export service performance metrics. Users don’t only expect a service mesh to automate and secure connection between services, they also expect to be able to see what is happening within the mesh so they can make improvements and identify potential breakage points early on. For more information about our new service mesh visualization capabilities, please read this blog.

Lastly, another great benefit of Consul is its ability to provide real time service health data to users. Knowing whether services are reachable or not can drastically cut down on downtime when diagnosing an issue or preventing an outage altogether. This is especially powerful when leveraging Consul for a service mesh because operators can use service resolvers to direct traffic in case a specific service is unreachable. The challenge though was that Consul health checks don’t work on Kubernetes and therefore operators could not take advantage of this resolver capability. To address that, Consul 1.9 GA will introduce support for Kubernetes Readiness probes to detect health statuses and enable resolvers to manage traffic based on that data. This feature will be available at the GA release, expected in the near future.

»Next Steps: HashiCorp at KubeCon

These features are heavily focused on Kubernetes, but as we have mentioned previously, Consul is a multi-platform service mesh. Consul 1.9 also introduced some features that are extremely helpful to users managing a service mesh not only on Kubernetes, but in any environment. Features like service mesh visualization and app-aware intentions provide operators with greater visibility into mesh performance and more granular control of services running anywhere. If you want to hear more about these features, we recommend that you come visit us at our Virtual Booth or find us on the CNCF Slack org. Service mesh continues to be an evolving and powerful path forward for organizations. Our goal is to provide that benefits consistently across any platform and we recognize that for many that journey starts with Kubernetes. Consul 1.9 ensures that users can continue to migrate workloads to their Kubernetes deployments and extend the mesh to existing or new environments as needed.