Today at KubeCon EU in Barcelona, Microsoft introduced a new specification, the Service Mesh Interface (SMI), for implementing service mesh providers into Kubernetes environments.
The Service Mesh Interface (SMI) is a specification for service meshes that run on Kubernetes. It defines a common standard that can be implemented by a variety of providers. This allows for both standardization for end-users and innovation by service mesh providers. SMI enables flexibility and interoperability.
We partnered with Microsoft to support the creation of this controller and this blog will explain how it can be used to set HashiCorp Consul Connect intentions within Kubernetes clusters.
What is SMI
Microsoft’s Service Mesh Interface is a series of Kubernetes controllers for implementing various service mesh capabilities. At launch, SMI will support four primary functions:
* Traffic Specs – define traffic routing on a per-protocol basis. These resources work in unison with access control and other types of policy to manage traffic at a protocol level.
* Traffic Access Control – configure access to specific pods and routes based on the identity of a client, to only allow specific users and services.
* Traffic Split – direct weighted traffic between services or versions of a service, enabling Canary Testing or Dark Launches.
* Traffic Metrics – expose common traffic metrics for use by tools such as dashboards and autoscalers.
At launch, HashiCorp Consul will support the Traffic Access Control specification, with possible integrations for the others in the future.
How Does Consul Support SMI
One of the custom resources defined by SMI is the TrafficTarget resource, developed by us in collaboration with the Microsoft team to assist with the challenge of securing service-to-service traffic. This resource enables the user to define Consul Connect intentions in a Kubernetes custom resource (CRD) and manage them through
Terraform, rather than having to configure them directly through Consul. This enables developers to ensure that newly deployed applications have a secure connection to resources through a single workflow. Here is an example of how to configure this controller:
Assuming you have two services running in Kubernetes: a dashboard that shows the current value and a counting service that increases the count with each request. Both are configured to communicate via the Envoy sidecar proxy.
By default, Consul Connect denies all traffic through the service mesh. In order for traffic from the dashboard to be able to reach the backend service, you need to define an intention that allows traffic from the dashboard to the backend service.
You can create this intention using the TrafficTarget CRD below, store it as
intention.yaml and apply it using
kubectl apply -f intention.yaml.
– kind: ServiceAccount
– kind: TCPRoute
This will create an intention in Consul that allows traffic from the dashboard service to the counting service.
With this intention created, the dashboard will be able to show the current value retrieved from the counting backend.
Information about Microsoft’s SMI can be found on their home page and Github repo. By leveraging this new resource, users will find it easier to utilize Consul Connect’s capabilities inside of their Kubernetes environments. Outside of Kubernetes environments, Consul’s service mesh capabilities can also be extended to hybrid or multi-cloud environments, for more complex application deployments.
If you would like to experiment with SMI and Consul, we have built an experimental Kubernetes controller which can be found in the following repository: https://github.com/hashicorp/consul-smi-controller
For more information about this and other features of HashiCorp Consul, please visit: https://www.consul.io.
Originally posted on Hashicorp Blog
Author: Nic Jackson