Ask Sendai

Today we announced that Solo.io is a launch partner of the Service Mesh Interface (SMI) specification in collaboration with Microsoft, Bouyant and Hashicorp with support across the cloud-native ecosystem. As part of today’s announcement, the SuperGloo project and The Service Mesh Hub are the first reference implementations of SMI available today. The Service Mesh Interface (SMI) is a specification for service meshes that run on Kubernetes and defines a common standard that can be implemented by a variety of providers.

Once you’ve built and designed your control plane and its various supporting components, you’ll want to decide exactly how its components get deployed. You’ll want to weight various security, scalability, and usability concerns when settling into what’s best for your implementation. The options vary from co-deploying control plane components with the data plane to completely separating the control plane from the data plane. There is also a middle ground here as well: deploy some components co-located with the control plane and keep some centralized.

This post was inspired by listening to the February 19, 2019, Kubernetes Podcast, “Ingress, with Tim Hockin.” The Kubernetes Podcast is turning out to be a very well done podcast overall, and well worth the listen. In the Ingress episode, the podcasters interview Tim Hockin who’s one of the original Kubernetes co-founders, a team lead on the Kubernetes predecessor Borg/Omega, and is still very active within the Kubernetes community such as chairing the Kubernetes Network Special Interest Group that currently own the Ingress resource specification.

Istio is a popular open-source service mesh with powerful service-to-service capabilities such as request-routing control, metric collection, distributed tracing, security, et. al. Istio also ships with an ingress-gateway component that makes it easy to get traffic into your service mesh. The Istio ingress gateway allows you to control what protocols, security requirements, and ports get exposed to the outside world, and then use Istio-native routing capabilities to route traffic to services.

Knative is talked about a great deal, especially around how its capabilities can help provide more standard building blocks on top of Kubernetes for building microservices and serverless like services, e.g., scale to zero, and scale on demand. Knative high level has three capability areas: building, serving, and eventing. This post will provide some examples around Knative Build and Knative Serving with Solo.io Gloo. Knative Serving initially included all of Istio only to use a small fraction of its capabilities around Kubernetes cluster ingress.

So you’ve decided to run your Kubernetes workloads in AWS. As we’ve seen before setting up AWS EKS requires a lot of patience and headache. You may be able to get it working. For others, you should check out the eksctl tool from Weaveworks. Now that you’ve got a Kubernetes cluster, you want to start deploying your microservices to it and start exposing and integrating APIs and services to your clients and other parts of your organization.