Version 1.9 of the Service Mesh Consul developed by HashiCorp is now available. With the new release, the developers have focused on providing what appears to be more granular control of service meshes, revising the monitoring of services within the service mesh, and tighter integrations with more runtime platforms in a Kubernetes-native manner.
An overview of the most important changes
Consul 1.9 includes the following functions, among others:
- The expansion of the intention model to include so-called application-aware (Layer 7) intentions should offer the possibility of creating guidelines that, in addition to service identity, also evaluate information at the application level.
- The Service Mesh Visualization offers a new topology tab in the Consul user interface with topology diagrams and service mesh metrics. These functions are intended to improve configuration and troubleshooting in the service mesh.
- With the new version, Consul can be configured using objects in the Kubernetes style. It is also possible to manage the service mesh configuration for services via CRDs (Custom Resource Definition).
- It is now possible to install Consul via Helm Charts in OpenShift.
- The Active Health Checks for Consul on Kubernetes integrates Kubernetes status checks into Consul. This is to ensure that the traffic is not forwarded to faulty pods.
- Consul can now handle streaming. This is seen as a major improvement in the way update notifications are delivered to block queries within the cluster. Streaming is intended to reduce the CPU and bandwidth usage of the network on Consul servers in large implementations.
If you want to get deeper into the innovations, is well advised with the blog announcement. The changelog lists the changes in detail.
Service … what?
The ability of a service mesh to simplify complex containers and improve network functions makes technology an important layer of infrastructure. In a service mesh, each service instance is linked to that of a reverse proxy server. The service instance and the sidecar proxy share a container, which in turn is managed by a container orchestration tool. The service proxies are responsible for communication with other service instances and can support functions such as service discovery, load balancing, authentication and authorization and secure communication.
Microservices are booming in the course of digital transformation strategies. But many companies find that not everything is going smoothly. Microservices can offer more flexibility and scalability, but they can also be more complex. This is where the service mesh comes into play. Read more about this in the article The Year of the Service Mesh.
In the service mesh, the service instances and their sidecar proxy form the data level, which also includes the processing and answering of inquiries. The service mesh also includes a level for controlling the interaction between the services, which is mediated by their sidecar proxies.
(ane)