Fetching the latest programs, projects, and workspace data.
Envoy Gateway translates Kubernetes-native Gateway API resources into xDS configuration consumed by Envoy Proxy. It also manages the lifecycle of the Envoy Proxy fleet by generating Kubernetes resources such as Deployments and Services. Currently, upgrades to Envoy Gateway (the control plane) result in immediate, in-place updates to the associated Envoy Proxy fleet (the data plane). While this operation is designed to be zero-downtime, some users prefer a staged upgrade process where the control plane is updated first, followed by a progressive rollout of the data plane. This project aims to design and implement support for progressive data plane upgrades, allowing users to decouple the control and data plane upgrade processes. This would provide enhanced control and safer rollout strategies (e.g., canary or blue-green deployments). Expected Outcome: 1. Design a two-step upgrade workflow that separates control plane and data plane updates. 2. Implement configuration or CRD support to control rollout strategy of the Envoy Proxy fleet. 3. Add documentation and example manifests for users to adopt the new workflow.
Showing 4 of 4 projects. Click any project card for scope, mentors, and proposal studio.
Envoy Gateway has become a crucial part of modern cloud-native infrastructures, providing a simplified way to deploy and manage Envoy Proxy. Ensuring the reliability and security of Envoy Gateway is paramount for its growing user base. Fuzzing, a widely-used technique for identifying software vulnerabilities and bugs, can significantly enhance the robustness of Envoy Gateway. By integrating the CNCF Fuzzing Framework, this project aims to improve the security posture of Envoy Gateway through comprehensive automated testing. Expected Outcome: Add a fuzz test that covers 80% of code paths for translating Gateway API input configuration into xDS output. Enable continuous fuzzing using OSS-Fuzz.
The Envoy Gateway project provides a simplified way to use Envoy Proxy as an API Gateway, and its documentation is critical to enabling adoption, onboarding new users, and improving developer experience. While the existing documentation covers core concepts and use cases, applying the CNCF Tech Docs Analysis Framework will help assess and systematically enhance its clarity, completeness, and usability. This project aims to evaluate and improve the Envoy Gateway website and documentation (https://gateway.envoyproxy.io/) by leveraging the structured analysis methodology from the CNCF Tech Docs Analysis Framework (https://github.com/cncf/techdocs/blob/main/docs/analysis/howto.md). The outcome will be a comprehensive documentation improvement plan, with targeted updates and best practices implemented. Expected Outcome: 1. Apply the CNCF Tech Docs Analysis Framework to assess Envoy Gateway docs 2. Identify gaps in content, structure, readability, and technical accuracy 3. Improve documentation organization, navigation, and developer onboarding 4. Optimize technical guides, examples, and API references 5. (Stretch Goal) Introduce best practices for continuous documentation improvement
Envoy Gateway is an open source project for managing Envoy Proxy as a standalone or Kubernetes-based application gateway. Gateway API resources are used to dynamically provision and configure the managed Envoy Proxies. Currently the implementation only supports Kubernetes clusters with IPv4 enabled, and not IPv6 Expected Outcome: The managed Envoy Proxy fleet can - Accept connections/listen on an interface that has an IPv6 address assigned to it - Can route to IPv6 pod endpoints/addresses
Envoy Gateway translates Kubernetes-native Gateway API resources into xDS configuration consumed by Envoy Proxy. It also manages the lifecycle of the Envoy Proxy fleet by generating Kubernetes resources such as Deployments and Services. Currently, upgrades to Envoy Gateway (the control plane) result in immediate, in-place updates to the associated Envoy Proxy fleet (the data plane). While this operation is designed to be zero-downtime, some users prefer a staged upgrade process where the control plane is updated first, followed by a progressive rollout of the data plane. This project aims to design and implement support for progressive data plane upgrades, allowing users to decouple the control and data plane upgrade processes. This would provide enhanced control and safer rollout strategies (e.g., canary or blue-green deployments). Expected Outcome: 1. Design a two-step upgrade workflow that separates control plane and data plane updates. 2. Implement configuration or CRD support to control rollout strategy of the Envoy Proxy fleet. 3. Add documentation and example manifests for users to adopt the new workflow.