envoy VS smi-spec

Apple also contributed[1] MPTCP support to Envoy Proxy.

[1]https://github.com/envoyproxy/envoy/pull/18780

After it finishes (it can take a few minutes), Docker-Compose automatically starts a cluster with two containers. One is an Envoy proxy (running on port 3000) that relays requests from outside the cluster to the other container (running on port 4000), which is our AR.IO gateway that will handle the requests.

Hi HN!

For the past few weeks we've been working on Proximal - a workflow engine that lets you quickly iterate on WebAssembly extensions for Envoy Proxy[0] (or other proxies) right on your local machine: https://github.com/apoxy-dev/proximal

This work is based on Proxy-WASM[1] extension ABI for Envoy (and other proxies like APISIX and Mosn[2]) which allows you to execute WebAssembly code on every API request a la Cloudflare Workers. As part of our wider effort at https://apoxy.dev to improve API glue code we built an experimentation / development platform and hope you will find it useful!

On the technical side this project packs Envoy itself, Envoy controller, REST API (for controlling the controller =)), React SPA, and Temporal server/worker (for orchestration) - all baked into a single Go binary. You can find more on architecture and limitations in the repository README[4].

This project is pretty early stage and we would appreciate community feedback!

Previous HN discussions on this topic:

* https://news.ycombinator.com/item?id=36113542

* https://news.ycombinator.com/item?id=22582276

---

[0] https://www.envoyproxy.io/

[1] https://github.com/proxy-wasm/spec/blob/master/docs/WebAssem...

[2] https://apisix.apache.org/ https://mosn.io/

[3] https://github.com/apoxy-dev/proximal/blob/main/README.md#ar...

Hey HN,

We made an Envoy Proxy[0] playground so we could test out our Envoy configs directly in the browser. This is based on Julia's work with Nginx Playround[1] (we forked[2] that repo and added more Envoy to it). Check it out!

[0] - Envoy is a popular programmable proxy similar to Nginx or HAProxy that is popular with cloud-native setups: https://www.envoyproxy.io

Envoy is the proxy that does the heavy lifting. Istio is just a glorified configuration system. Even if you choose to use Istio you're still using Envoy.

You're spot-on about using iptables rules. There is an example here with a yaml configuration and some iptables commands: https://github.com/envoyproxy/envoy/blob/main/configs/origin...

You might be able to re-use some of that. It should be pretty easy to get metrics for outbound/inbound http requests, but I don't remember the exact yaml incantation.

I'm using the default RaspiOS Lite 64bits and as highlighted in this issue, the RaspiOS kernel does not support CONFIG_ARM64_VA_BITS_48, which makes cilium-envoy to fail building. As solution, I was told to use either Ubuntu as base OS or Traefik Ingress Controller, which is not configured in K3s.

I know envoy (https://www.envoyproxy.io/, https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/jwt_authn_filter) can do this natively, I'm sure you could probably build something with nginx and its Lua scripting, not sure about traefik and caddy but I dont think they support that.

Envoy is a cloud native opensource proxy server. The Envoy proxy offers a variety of http filters to handle incoming requests.

Istio: By far the most popular service mesh. It is built on top of Envoy proxy, which many service meshes use.

The Service Mesh Interface (SMI) specification was created to solve this portability issue.

> I suspect if a Service Mesh is ultimately shown to have broad value, one will make it's way into the K8S core

I'm not so sure. I suspect it'll follow the same roadmap as Gateway API, which it already kind of is with the Service Mesh Interface (https://smi-spec.io/)

It is very common that a service mesh deploys a control plane and a data plane. The control plane does what you might expect; it controls the service mesh and gives you the ability to interact with it. Many service meshes implement the Service Mesh Interface (SMI) which is an API specification to standardize the way cluster operators interact with and implement features.

Before we start, let's review the SMI Access Control Specification. There are two forms of traffic policies in osm-edge: Permissive Mode and Traffic Policy Mode. The former allows services in the mesh to access each other, while the latter requires the provision of the appropriate traffic policy to be accessible.

osm-edge is a simple, complete, and standalone service mesh and ships out-of-the-box with all the necessary components to deploy a complete service mesh. As a lightweight and SMI-compatible Service Mesh, osm-edge is designed to be intuitive and scalable.

I started on Monday, attending ServiceMeshCon2019. My guesstimate is that about 1000 people attended it. I believe Service Mesh is playing such a crucial role in scaling cloud native technologies that large scale cloud-native deployments may not be possible without service mesh. Just like you cannot really succeed in deploying a microservices based application without a microservices orchestration engine, like Kubernetes, you cannot scale the size and capacity of a microservices-based application without service mesh. That’s what makes it so compelling to see all the service mesh creators — Istio, Linkerd, Consul, Kuma — and listen to them. There was also a lot of discussion of SMI (Service Mesh Interface) — a common interface among all services mesh. The panel at the end of the day included all the major service mesh players, and some very thought provoking questions were asked and answered by the panel.

Do you need a Service Mesh?

In the episode with Annie, she gave a great overview of the CNCF and a handful of projects that she's excited about. Those include Helm, Linkerd, Kudo, Keda and Artifact Hub. I gave a bonus example of the Service Mesh Interface project.

SMI official website: https://smi-spec.io