Displaying 1 to 20 from 25 results

Istio - An open platform to connect, manage, and secure microservices

  •    Go

An open platform to connect, manage, and secure microservices. Istio is an open platform for providing a uniform way to integrate microservices, manage traffic flow across microservices, enforce policies and aggregate telemetry data. Istio's control plane provides an abstraction layer over the underlying cluster management platform, such as Kubernetes, Mesos, etc.

contour - Contour is a Kubernetes ingress controller for Lyft's Envoy proxy.

  •    Go

Contour is an Ingress controller for Kubernetes that works by deploying the Envoy proxy as a reverse proxy and load balancer. Unlike other Ingress controllers, Contour supports dynamic configuration updates out of the box while maintaining a lightweight profile. Contour also introduces a new ingress API (IngressRoute) which is implemented via a Custom Resource Definition (CRD). Its goal is to expand upon the functionality of the Ingress API to allow for a richer user experience as well as solve shortcomings in the original design.

ambassador - open source Kubernetes-native API gateway for microservices built on the Envoy Proxy

  •    Python

Ambassador is an open source Kubernetes-native API Gateway built on Envoy, designed for microservices. Ambassador essentially serves as an Envoy ingress controller, but with many more features. Ambassador deploys the Envoy Proxy for L7 traffic management. Configuration of Ambassador is via Kubernetes annotations. Ambassador relies on Kubernetes for scaling and resilience. For more on Ambassador's architecture and motivation, read this blog post.

Gloo - The Function Gateway built on top of Envoy

  •    Go

Gloo is a feature-rich, Kubernetes-native ingress controller, and next-generation API gateway. Gloo is exceptional in its function-level routing; its support for legacy apps, microservices and serverless; its discovery capabilities; its numerous features; and its tight integration with leading open-source projects. Gloo is uniquely designed to support hybrid applications, in which multiple technologies, architectures, protocols, and clouds can coexist.




kuma - The Universal Service Mesh

  •    Go

Kuma is a platform agnostic open-source control plane for Service Mesh and Microservices. It can run and be operated natively across both Kubernetes and VM environments, making it easy to adopt by every team in the organization. Bundling Envoy as a data-plane, Kuma can instrument any L4/L7 traffic to secure, observe, route and enhance connectivity between any service or database. It can be used natively in Kubernetes via CRDs or via a RESTful API across other environments like VMs and Bare Metal.

gimbal - Heptio Gimbal is an ingress load balancing platform capable of routing traffic to multiple Kubernetes and OpenStack clusters

  •    Go

Heptio Gimbal is a layer-7 load balancing platform built on Kubernetes, the Envoy proxy, and Heptio's Kubernetes Ingress controller, Contour. It provides a scalable, multi-team, and API-driven ingress tier capable of routing Internet traffic to multiple upstream Kubernetes clusters and to traditional infrastructure technologies such as OpenStack. Gimbal was developed out of a joint effort between Heptio and Yahoo Japan Corporation's subsidiary, Actapio, to modernize Yahoo Japan’s infrastructure with Kubernetes, without affecting legacy investments in OpenStack.

ratelimit - Go/gRPC service designed to enable generic rate limit scenarios from different types of applications

  •    Go

The rate limit service is a Go/gRPC service designed to enable generic rate limit scenarios from different types of applications. Applications request a rate limit decision based on a domain and a set of descriptors. The service reads the configuration from disk via runtime, composes a cache key, and talks to the Redis cache. A decision is then returned to the caller. Envoy's data-plane-api defines a ratelimit service proto rls.proto. Logically the data-plane-api rls is equivalent to the ratelimit.proto defined in this repo. However, due to the namespace differences and how gRPC routing works it is not possible to transparently route the legacy ratelimit (ones based in the ratelimit.proto defined in this repo) requests to the data-plane-api definitions. Therefore, the ratelimit service will upgrade the requests, process them internally as it would process a data-plane-api ratelimit request, and then downgrade the response to send back to the client. This means that, for a slight performance hit for clients using the legacy proto, ratelimit is backwards compatible with the legacy proto.

Meshery - The service mesh management plane

  •    Javascript

Meshery is the multi-service mesh management plane offering lifecycle, configuration and performance management of service meshes and their workloads. Meshery manages the provisioning, configuration and operation your service mesh. While supporting different types of service meshes, Meshery also offers a simple way to explore each service mesh and compare them using bundled sample applications. Interoperate multiple service meshes with service mesh adapters provision, configure, and manage their respective service meshes.


envoy-perf - Envoy performance testing

  •    Python

You have to install matplotlib in your machine to generate graphs. Graphs depicting Envoy's performance can be generated by running the below command. The graph will compare between Envoy and direct connection, with respect to the field provided as argument, such as the deafault one total_req_per_sec. Multiple Envoy Hash ids and Run IDs can be provided for the comparison.The above command will generate two graphs: 1) A bar graph for Envoy proxy and direct connection with Envoy Hash xxxxxy. 2) Another bar for Envoy and direct connection with Run IDs 10, 11, 12, 13, 14, 15.

microservices-traffic-management-using-istio - Istio is an open platform that provides a uniform way to connect, manage, and secure microservices

  •    Java

Read this in other languages: 한국어. Microservices and containers changed application design and deployment patterns, but along with them brought challenges like service discovery, routing, failure handling, and visibility to microservices. "Service mesh" architecture was born to handle these features. Applications are getting decoupled internally as microservices, and the responsibility of maintaining coupling between these microservices is passed to the service mesh.

envoyproxy.github.io - Envoy Proxy website

  •    HTML

This is the repo for the Envoy Proxy website. This website uses Jekyll to generate static html files, and then deploys the files on Github pages. To run the website locally, first make sure you have Ruby 2.1.0 or higher installed.

layer5 - A Service Mesh Community - characterizing and contrasting service mesh projects and related technologies

  •    HTML

Layer5.io is a community-maintained repository of information pertaining to the technology ecosystem surrounding service meshes, API gateways, edge proxies, ingress and egress controllers - - microservice management in cloud native environments. See (https://layer5.io/landscape) - a collection of prominent projects and offerings laid out in contrast to one another.

sds - Envoy's v1 Service Discovery Service API and v2 Endpoint Discovery Service API

  •    Rust

Envoy's v1 Service Discovery Service API and v2 Endpoint Discovery Service API. In contrast of https://github.com/lyft/discovery, the sds allow users to serve multiple application instances of single service in single host instance (with single ip address). Accepts v2 DiscoveryRequest, then responses v2 DiscoveryResponse.

consul-envoy - Consul to Envoy API listener

  •    Go

This project aim to be a quick'n'dirty way to get Envoy and Consul talking nicely, so any Consul service URL can be routed through evnoy. Making using Envoy with Consul as easy as fabio and traefik, possible exposting additional configuration to envoy through Consul Service tags (similar to fabio urlprefix-* configuration).

kubernetes-envoy-example - Teaching myself about Envoy on Kubernetes

  •    Go

A sample application using Envoy running in Kubernetes. I wanted to learn more about Envoy, so I decided to do it "the hard way." I wrote the contrived example application and pieced together the Envoy configurations from the documentation and examples.

Envoy-Pilot - Envoy xDS Server with Consul

  •    Go

Envoy Pilot or Envoy xDS is a control plane implementation for Envoy written in Golang and uses Consul for persistence by default. It can also run without Consul by loading configuration from file.

kumonos - A "control plane" for Microservices "service mesh".

  •    Ruby

A "control plane" for Microservices "service mesh". Bug reports and pull requests are welcome on GitHub at https://github.com/taiki45/kumonos.

envoy-preflight - A wrapper for applications to help with running envoy as a sidecar

  •    Go

This application, if provided an ENVOY_ADMIN_API environment variable, will poll indefinitely with backoff, waiting for envoy to report itself as live, implying it has loaded cluster configuration (for example from an ADS server). Only then will it execute the command provided as an argument. All signals are passed to the underlying application. Be warned that SIGKILL cannot be passed, so this can leave behind a orphaned process.

envoy-consul-sds - Envoy Consul Service Discovery Service

  •    Go

This tutorial is based on Kelsey Hightower's kubernetes-envoy-sds tutorial but using Consul and Nomad. envoy-consul-sds service implements the Envoy SDS API on top of Consul Health Endpoint API. envoy-consul-sds service returns a list of healthy endpoints for Envoy to use as upstream backends for a cluster. Each Consul service can be referenced in the Envoy config file by its DNS name.





We have large collection of open source products. Follow the tags from Tag Cloud >>


Open source products are scattered around the web. Please provide information about the open source projects you own / you use. Add Projects.