Systems | Development | Analytics | API | Testing

Service Mesh

Getting Started With Kong Istio Gateway

Have you ever found yourself in a situation where all your service mesh services are running in Kubernetes, and now you need to expose them to the outside world securely and reliably? Ingress management is essential for your configuration and operations when exposing services outside of a cluster. You need to take care of the authentication, observability, encryption and integration with other third-party vendors alongside other policies.

How requests flow from the Edge to the Core and through our Service Mesh

Here at Koyeb, we're kind of crazy about providing the fastest way to deploy applications globally. As you might already know, we're building a serverless platform exactly for this purpose. We recently wrote about how the Koyeb Serverless Engine runs microVMs to host your Services but we skipped a big subject: Global Networking. Global Networking is a big way of saying "How are my requests processed?".

Building a Multi-Region Service Mesh with Kuma/Envoy, Anycast BGP, and mTLS

We're kind of crazy about providing the fastest way to deploy applications globally. As you might already know, we're building a serverless platform exactly for this purpose. We recently wrote about how the Koyeb Serverless Engine runs microVMs to host your Services but we skipped a big subject: Global Networking. Global Networking is a big way of saying "How are my requests processed?". A short answer is: requests go through our edge network before reaching your services hosted on our core locations.

ZeroLB in a Decentralized World

One of the things that’s quite interesting about service mesh is that it has not been a very well-defined category for a very long time. Service mesh is not a means to an end. By looking at its adoption, we’ve been seeing a refocus on the end use case that service mesh allows us to enable. Some are around observability while others are around security and trust – being able to provide that identity to all of our services.

Service Mesh 102: Envoy Configuration

In my Service Mesh 101 article, I talked about some of the basics behind a service mesh: what it is, what it does and where Envoy fits into a service mesh. Having now covered those basics, I’d like to dig into some more in-depth content focused on the basics of Envoy configuration in a service mesh. Recall from the previous article that several different service meshes use Envoy. Istio is an example of a service mesh that leverages Envoy for its data planes.

Service Mesh 101: The Role of Envoy

If you’ve done any reading about service meshes, you’ve probably come across mentions of an open source project named Envoy. And if you’ve done any reading about Envoy, you’ve probably seen references to service meshes. How are these two technologies related? How are they different? Do they work together? I’ll attempt to answer all those questions in this blog post’s first and second parts, plus possibly a few more.

Kuma 1.3 and Kong Mesh 1.4 Released With Service Map, CA Rotation, mTLS Permissive and 10+ features.

We are happy to announce a new major release of Kuma, and a new major release of Kong Mesh built on Kuma! Kuma 1.3 ships with 10+ new features and countless improvements. Kong Mesh ships we enterprise capabilities for large scale service mesh deployments. We strongly suggest to upgrade, in order to take advantage of the latest and greatest when it comes to service mesh.

Understanding the Basics of Envoy Configuration

Envoy is a key part of a number of service meshes currently on the market, including Istio and the Kuma CNCF Sandbox project. As such, it is often helpful to better understand how Envoy is configured to operate as a data plane in a service mesh. In this session, you’ll learn about the basics of Envoy configuration, like listeners, filters, clusters, and endpoints.