Blogs

• 1: Announcing Envoy Gateway’s 1.0 Release!
• 2: Welcome to new website!

1 - Announcing Envoy Gateway’s 1.0 Release!

Today we’re ecstatic to announce the 1.0 release of Envoy Gateway (EG) for Kubernetes. A mature version ready for widespread adoption in production that simplifies the use of Envoy for managing North-South traffic.

After nearly two years with contributions from over 90 engineers we are proud to say EG meets the goals that Matt outlined in the original post introducing the project, summarized here:

• Built around the (then emerging) Kubernetes Gateway API
• Addresses common needs with a solution that is simple to configure and understand
• Provides great docs for common use cases to enable ease of adoption
• Empowers the community and vendors to drive the project forward through an extensible API

Can’t wait to try it? Visit the EG tasks to get started with Envoy Gateway 1.0

Envoy Gateway 1.0

The 1.0 release brings a lot of functionality. In addition to implementing the full Kubernetes Gateway API – including the awesome Envoy L7 features you love like per-request policy, load balancing, and best-in-class observability – it also goes further, Envoy Gateway 1.0:

• Provides support for common features such as Rate Limiting and OAuth2.0
• Deploys and upgrades Envoy on your behalf, easing operations and lifecycle management
• Introduces extensions to the Kubernetes Gateway API to address Client, Backend, and Security settings and features
• Is easily extensible through the EnvoyPatchPolicy API to allow you to configure any Envoy behavior (including stuff you build yourself!)
• Has a CLI, egctl, for interacting with and debugging the system
• Comes with a large (and growing!) set of scenarios to make common use cases straightforward to implement

What Does 1.0 Mean for the Project?

We won’t be slowing down on feature velocity – if anything, we expect more features to ship as many users who have been following the project and waiting on the GA release get involved. For us, 1.0 means two big things:

• A commitment to ensuring stability with releases for CVE fixes. From 1.0 onwards you can have confidence that the configuration you write today will continue to work in the same way for the foreseeable future.
• That the community is confident in the system’s readiness for general use by everyone, not just Envoy experts.

How We Got Here

The project has moved so fast it feels like a whirlwind, but a high level recap is in order.

• 2022

  • In May, Matt Klein published the original post introducing the project
  • In November, Envoy Gateway passed the entire Kubernetes Gateway API conformance suite for the first time.

• 2023

  • We enabled early adopters to understand target use cases by providing configuration escape valves.
  • The number of project contributors and early adopters were growing and shaping the direction of Envoy Gateway
  • Extensions to Envoy Gateway and the Gateway API to tackle client, backend, and security challenges early adopters were facing, were introduced by the community

• 2024

  • Envoy Gateway 1.0 is ready for widespread adoption thanks to over 90 contributors and the engagement from early production adopters

What’s Next?

Following the 1.0 release, we’ll be focusing on:

• Ease of operation: Continuing to improve the Journey to Production and operability of the system
  • Better metrics dashboards for control plane and data plane observability
  • Exposing more knobs to fine tune more traffic shaping parameters
• Features: More API Gateway features such as authorization (IP Addresses, JWT Claims, API Key, etc.) and compression
• Scale: Building out a performance benchmarking tool into our CI
• Extensibility: We plan on providing a first-class API for data plane extensions such as Lua, Wasm, and Ext Proc to enable users to implement their custom use cases
• Outside of Kubernetes: Running Envoy Gateway in non-k8s environments - this has been an explicit goal and we’d like to focus on this in the coming months. Envoy Proxy already supports running on bare metal environments, with Envoy Gateway users getting the added advantage of a simpler API
• Debug: And a lot of capabilities with the egctl CLI

Get Started

If you’ve been looking to use Envoy as a Gateway, check out our quickstart guide and give it a try! If you’re interested in contributing, check out our guide for getting involved!

2 - Welcome to new website!

Introduction

In the realm of static site generators, two names often come up: Sphinx and Hugo. While both are powerful tools, we recently made the decision to migrate our documentation from Sphinx to Hugo. This article aims to shed light on the reasons behind this move and the advantages we’ve discovered in using Hugo for static blogging.

Why Migrate?

Sphinx, originally created for Python documentation, has served us well over the years. It offers a robust and flexible solution for technical documentation. However, as our needs evolved, we found ourselves seeking a tool that could offer faster build times, ease of use, and a more dynamic community. This led us to Hugo.

Advantages of Hugo

• Speed: Hugo is renowned for its speed. It can build a site in a fraction of the time it takes other static site generators. This is a significant advantage when working with large sites or when quick updates are necessary.

• Ease of Use: Hugo’s simplicity is another strong point. It doesn’t require a runtime environment, and its installation process is straightforward. Moreover, Hugo’s content management is intuitive, making it easy for non-technical users to create and update content.

• Flexibility: Hugo supports a wide range of content types, from blog posts to documentation. It also allows for custom outputs, enabling us to tailor our site to our specific needs.

• Active Community: Hugo boasts a vibrant and active community. This means regular updates, a wealth of shared themes and plugins, and a responsive support network.

• Multilingual Support: Hugo’s built-in support for multiple languages is a boon for global teams. It allows us to create content in various languages without the need for additional plugins or tools.

• Markdown Support: Hugo’s native support for Markdown makes it easy to write and format content. This is particularly beneficial for technical writing, where code snippets and technical formatting are common.

Challenges Encountered During the Migration

While the migration from Sphinx to Hugo has brought numerous benefits, it was not without its challenges and it really took me a lot of time on it. Here are some of the difficulties we encountered during the process:

• Converting RST to Markdown: Our documentation contained a large number of reStructuredText (RST) files, which needed to be converted to Markdown, the format Hugo uses. This required a careful and meticulous conversion process to ensure no information was lost or incorrectly formatted.

• Adding Headings to tons of Markdown Files: Hugo requires headings in its Markdown files, which our old documents did not have. We had to write scripts to add these headings in bulk, a task that required a deep understanding of both our content and Hugo’s requirements.

• Handling Multiple Versions: Our documentation had already gone through five iterations, resulting in a large number of files to manage. We had to ensure that all versions were correctly migrated and that the versioning system in Hugo was correctly set up.

• Designing a New Page Structure and Presentation: To provide a better reading experience, we needed to design a new way to organize and present our pages. This involved understanding our readers’ needs and how best to structure our content to meet those needs.

• Updating Existing Toolchains: The migration also required us to update our existing toolchains, including Makefile, CI, release processes, and auto-generation tools. This was a complex task that required a deep understanding of both our old and new systems.

Despite these challenges, the benefits of migrating to Hugo have far outweighed the difficulties. The process, while complex, has provided us with a more efficient, user-friendly, and flexible system for managing our static blog. It’s a testament to the power of Hugo and the value of continuous improvement in the tech world.

Conclusion

While Sphinx has its strengths, our migration to Hugo has opened up new possibilities for our static blogging. The speed, ease of use, flexibility, and active community offered by Hugo have made it a powerful tool in our arsenal.

Some Words

From the inception of my involvement in the project, I have placed great emphasis on user experience, including both developer and end-user experiences. I have built a rich toolchain, automated pipelines, Helm Charts, command-line tools, and documentation to enhance the overall experience of interacting with the project.

My dedication to improving user experience was a driving force behind the decision to migrate from Sphinx to Hugo. I recognized the potential for Hugo to provide a more intuitive and efficient platform for managing the project’s static blog. Despite the challenges encountered during the migration, my commitment to enhancing user experience ensured a successful transition.

Through this migration, I have further demonstrated my commitment to continuous improvement and my ability to adapt to the evolving needs of the project. My work serves as a testament to the importance of user experience in software development and the value of embracing new tools and technologies to meet these needs.

Enjoy new Envoy Gateway Website! ❤️