envoyproxy / gateway Goto Github PK
View Code? Open in Web Editor NEWManages Envoy Proxy as a Standalone or Kubernetes-based Application Gateway
Home Page: https://gateway.envoyproxy.io
License: Apache License 2.0
Manages Envoy Proxy as a Standalone or Kubernetes-based Application Gateway
Home Page: https://gateway.envoyproxy.io
License: Apache License 2.0
#16 specifies the need for an xDS Translator (XT) to translate IR resources to an xDS config. The XT details should be captured in this issue or a linked doc.
Serverless is becoming a common app runtime for cloud native apps. Popular Serverless OSS projects such as Knative should use EG as the preferred ingress/egress networking solution.
As discussed, the repo can use additional labels to help organize PRs, issues, etc. After reviewing other projects in the envoyproxy org, the following are the labels that I propose:
area/ci
area/build
area/api
area/config (Config Manager, Config Sources, etc.)
area/data model
area/message service
area/translator
area/xds server
area/provisioner
@arkodg @LukeShu @alexgervais @youngnick @skriss PTAL at the above list, provide feedback, and any add'l labels that you feel are needed to kickoff the project.
During the 4/29/21 community meeting, support for L4 support, e.g. TCPRoute was discussed. The community should come to an agreement on if L4 should be supported and if so, how.
Port Gateway API code from Contour to provide a kubecon demo. The code should be ported to a demo branch and not main. The ported code should be as minimal as possible to demo Gateway API functionality.
#16 specifies the need to define APIs, e.g. bootstrap config. To begin developing these APIs, the community should agree on:
#16 specifies the need for an Intermediate Representation (IR) component to decouple the system from Gateway API. The IR details should be captured in this issue or a linked doc.
Create initial integration/e2e tests, framework, tooling etc. that exercises the EG codebase.
The following checklist must be completed for the project's public announcement, e.g. v0.0.1:
Should Envoy Gateway's documentation be separate from Envoy's official docs or integrate with https://github.com/envoyproxy/envoy-website
#16 specifies the need for a Message Service (MS) component to allow internal services to communicate while being loosely coupled. The MS details should be captured in this issue or a linked doc.
Envoy Gateway intends to support upstream services & endpoint running in all environments as highlighted here. This issue tracks how this can be
achieved using the Gateway API
A matrix is needed that describes component versions used in EG releases. For example, EG v0.1 = Envoy v1.x, Gateway API v1.y, etc.
Use Envoy contrib guide as a reference model.
High-level dev workflow:
--signoff
for each commit.fixes <issue_number>
.IMO "Gateway" does not accurately reflect the intended functionality of the project. The project will manage Envoy fleets that are represented as GatewayClasses and Gateways. Let's use comments in this issue to provide name suggestions and a thumbs-up emoji if you like the name. The name with the most thumbs-up's wins. If a tie exists, we'll have @mattklein123 be the final decision maker.
The readme should be updated to xref cncf/envoy public announcements.
#24 highlights the need for users to override xDS resources configured by
Envoy Gateway. Raising this issue to track how do you express this intent for the Envoy Proxy Bootstrap Config using the Gateway API
here's how popular OSS projects do it
Updated
The Config Manager is responsible for instantiating and managing the lifecycle of the various system components
in Envoy Gateway based on the Envoy Gateway Bootstrap spec
envoyproxy/envoy repo should be used as a reference for how docs are created for this repo.
A Config API is required for EG to consume config params through gatewayclass.spec.parameterRefs
. This config API is referred to as "Bootstrap Config" in #16.
To simplify the UX (especially for dev's), the project should support managing a default GatewayClass and Gateway. For example, when EG is started with an ENV var or CLI flag such as --default-gateway-class=true
and --default-gateway=true
it will create the default GatewayClass and default Gateway resources.
Open Questions:
default
namespace can be used? If the Gateway
is created in the EG system namespace, then the default Gateway needs to support cross-namespace routing as this ns is not meant for proxied apps, xref.The community has established Gateway API conformance as the target of the 0.0.2 release. This is a meta issue, in that issues, PRs, etc. that target this goal should be linked to this issue.
A GOVERNANCE.md is required to explain how to become a maintainer, maintainer responsibilities, etc.
xref: #3
A docker hub repo is needed to store EG images. The push will be triggered by a GH action.
Create a design document that provides details of system components, functionality, etc.
Istio Ingress Gateway is an Envoy-based edge proxy that is managed by Istiod and integrates with the Istio service mesh. Should EG be considered as a replacement? If so, why? What are the benefits of using EG for mesh ingress instead of Istio Ingress Gateway? Do other opportunities exist to integrate with Istio?
As a Kubernetes cluster administrator, I would like Gateway to support Kubernetes services that run in multiple clusters. Gateway should support multi-cluster service networking methods defined by sig-multicluster but not preclude other methods.
xref: #7
Create an initial CI environment where TBD tests are executed for PRs.
Users might want to directly configure xDS Resources in case Envoy Gateway's API doesn't support their use case.
They might want to add/merge/remove/replace xDS resources that are pushed by Envoy Gateway into Envoy Proxy.
Projects such as Istio provide APIs such as EnvoyFilter to fulfill these use cases.
Outlining work items
The initial governance doc is generalized. Update the doc to include more procedural information.
xref: #58
Consider defining a WASM ABI spec for Control Plane APIGateways similar to proxy-wasm so the components defined in #16 can be extended by users to define new control plane APIGateway functionality . wazero might be an apt runtime to use.
I added an "About" and topics to the repo homepage, PTAL. This issue captures the need for both. @arkodg @youngnick @skriss @LukeShu @alexgervais please comment in this issue with any "About" or topics suggestions.
#16 specifies the need for a Gateway API Translator (GAT) to decouple the user APIs from the internal system. The GAT details should be captured in this issue or a linked doc.
#16 specifies the need for a Service Resolver (SR) component that resolves IR services into platform-specific endpoints. The SR details should be captured in this issue or a linked doc.
Create a CHANGELOG.md file at the repository root to document changes and release notes.
#16 specifies the need for a Config Server (CS) component to allow EG to be configured from a remote endpoint. The CS details should be captured in this issue or a linked doc.
The project is currently targeting the edge reverse proxy use case. Should the project also support forward proxy, e.g. egress?
The file should list the maintainers of the project.
#16 specifies the need for a Path Watcher (PW) component to allow EG to be configured from file(s) in a directory path. The PW details should be captured in this issue or a linked doc.
#16 states that EG will merge config from multiple sources but does not provide the "how". This "how" should be detailed in this issue or a referenced design doc.
We need to make sure we have some sort of code of conduct markdown file in the root of the repo.
#16 specifies the need for a Provisioner to manage the infra needed to run Envoy. The Provisioner details should be captured in this issue or a linked doc.
Create a GOALS.md document that highlights the objectives, non-objectives and personas of the Gateway project.
Create a Readme that provides an intro to the project and references on how to communicate with the community, how to contribute, etc.
v0.4.2 is the latest Gateway AP release. Should this release be used or should the main branch be used until v0.5.0 is released which introduces release channels?
cc: @youngnick
A document about the project roadmap helps users understand
#16 specifies the need for an xDS server to configure managed Envoy instances. The xDS server details should be captured in this issue or a linked doc.
Enumerate the engineering decisions needed to prepare for implementing the design doc.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.