My LFX mentorship journey with kgateway

Open source has been a defining part of my career for many years. As an engineer working in the cloud native ecosystem, I have spent the last five years building and contributing to technologies around Kubernetes,... Open source has been a defining part of my career for many years. As an engineer working in the cloud native ecosystem, I have spent the last five years building and contributing to technologies around Kubernetes, Envoy Proxy, API gateways, and service networking. These technologies power modern platforms at scale, and they are also at the heart of many CNCF projects that shape the future of cloud infrastructure. Earlier this year, I had the opportunity to participate in the Linux Foundation Mentorship Program (LFX) through the kgateway project. What started as a mentorship project quickly evolved into something much bigger: a path toward becoming a long-term contributor and future maintainer in a community I genuinely enjoy being part of. Why kgateway? At my day job, we recently started adopting kgateway in OpenChoreo , an open source internal developer platform for Kubernetes and a CNCF Sandbox project, and were impressed by its technical architecture, stability, and alignment with modern cloud native standards. Built on top of Envoy Proxy and Kubernetes Gateway API, kgateway provides a powerful and extensible foundation for managing traffic in Kubernetes environments. The project’s maturity, active development, and commitment to open standards made it particularly attractive as we evaluated solutions for our platform. While evaluating the project, I noticed an LFX mentorship opportunity that focused on an area directly related to my background. The timing felt perfect. Rather than simply consuming the project as a user, I wanted to contribute back and become an active member of the community. The mentorship program offered an ideal starting point. Why an LFX mentorship? There is a common misconception that the LFX Mentorship program is only for

Open source has been a defining part of my career for many years. As an engineer working in the cloud native ecosystem, I have spent the last five years building and contributing to technologies around Kubernetes,... Open source has been a defining part of my career for many years. As an engineer working in the cloud native ecosystem, I have spent the last five years building and contributing to technologies around Kubernetes, Envoy Proxy, API gateways, and service networking. These technologies power modern platforms at scale, and they are also at the heart of many CNCF projects that shape the future of cloud infrastructure. Earlier this year, I had the opportunity to participate in the Linux Foundation Mentorship Program (LFX) through the kgateway project. What started as a mentorship project quickly evolved into something much bigger: a path toward becoming a long-term contributor and future maintainer in a community I genuinely enjoy being part of. Why kgateway? At my day job, we recently started adopting kgateway in OpenChoreo , an open source internal developer platform for Kubernetes and a CNCF Sandbox project, and were impressed by its technical architecture, stability, and alignment with modern cloud native standards. Built on top of Envoy Proxy and Kubernetes Gateway API, kgateway provides a powerful and extensible foundation for managing traffic in Kubernetes environments. The project’s maturity, active development, and commitment to open standards made it particularly attractive as we evaluated solutions for our platform. While evaluating the project, I noticed an LFX mentorship opportunity that focused on an area directly related to my background. The timing felt perfect. Rather than simply consuming the project as a user, I wanted to contribute back and become an active member of the community. The mentorship program offered an ideal starting point. Why an LFX mentorship? There is a common misconception that the LFX Mentorship program is only for students or early-career engineers. With five years of experience in cloud native API gateways and networking, I was already comfortable working with Go, Kubernetes, and Envoy Proxy. However, joining a mature open source ecosystem as a newcomer can still be challenging. Every project has its own architecture, governance model, testing practices, and community norms that take time to understand. At the same time, balancing a full-time job and family commitments means open source contributions often lack consistency without structure. Without a clear scope and guidance, it’s easy for contributions to get delayed or lose momentum. I saw the LFX Mentorship for kgateway as the ideal starting point. It provided structured onboarding, a well-defined project scope, and direct weekly interaction with core maintainers. I applied, was accepted, and my journey began. The mentorship experience From day one, I was working closely with core maintainers, which made a huge difference in understanding the project. Instead of spending weeks trying to decode design decisions on my own, I was able to get direct context on architecture, trade-offs, and long term direction. The focus of my mentorship was adding chaos engineering support to kgateway through HTTP fault injection . The idea is to let platform teams deliberately inject failures, such as delays and aborts, into their traffic so they can validate how resilient their services are before those failures show up in production. My core deliverable was implementing fault injection support by extending TrafficPolicy , covering delay injection, abort injection with both HTTP and gRPC status codes, response rate limiting, and a per-route override to disable it. Under the hood it maps to the Envoy HTTP fault filter, which is added to the filter chain disabled by default and enabled selectively per route or virtual host. This keeps the feature completely inert unless a policy explicitly opts in. The learning curve was still real. kgateway sits at the intersection of Kubernetes, Envoy Proxy, and the Gateway API, so even small changes often required understanding multiple layers of the system. But having a structured path and regular syncs kept the progress steady and focused. Some of the key areas I gained a deep understanding of during the mentorship included: Understanding the internal architecture of the kgateway control plane Kubernetes Gateway API implementation within kgateway kgateway plugin architecture for extensible policy design Abstracting low-level Envoy Proxy configuration into developer facing policies kgateway policy merge implementation and merge strategies Community collaboration and open source development workflows What stood out most was how iterative and collaborative the process was. Every contribution went through thoughtful review, not just for correctness, but for long-term maintainability and alignment with the direction of the project. By the end of the mentorship, I had not only completed the assigned project work but also built enough context to contribute independently without needing step-by-step guidance. Beyond the mentorship For me, the mentorship was never intended to be a one-time contribution. My goal from the beginning was to use the program as a starting point for a deeper involvement in the project and community. After completing the mentorship project, I continued contributing to kgateway by working on new features, bug fixes, and community discussions. The transition from mentee to regular contributor felt natural because the mentorship had already provided the context, relationships, and confidence needed to contribute independently. Since completing the program, I have continued contributing to kgateway by: Contributing feature enhancements Fixing bugs and improving project stability Participating in technical discussions Reviewing and collaborating on community contributions Helping shape future improvements to the project A couple of contributions I am

Open source has been a defining part of my career for many years. As an engineer working in the cloud native ecosystem, I have spent the last five years building and contributing to technologies around Kubernetes,... Open source has been a defining part of my career for many years. As an engineer working in the cloud native ecosystem, I have spent the last five years building and contributing to technologies around Kubernetes, Envoy Proxy, API gateways, and service networking. These technologies power modern platforms at scale, and they are also at the heart of many CNCF projects that shape the future of cloud infrastructure. Earlier this year, I had the opportunity to participate in the Linux Foundation Mentorship Program (LFX) through the kgateway project. What started as a mentorship project quickly evolved into something much bigger: a path toward becoming a long-term contributor and future maintainer in a community I genuinely enjoy being part of. Why kgateway? At my day job, we recently started adopting kgateway in OpenChoreo , an open source internal developer platform for Kubernetes and a CNCF Sandbox project, and were impressed by its technical architecture, stability, and alignment with modern cloud native standards. Built on top of Envoy Proxy and Kubernetes Gateway API, kgateway provides a powerful and extensible foundation for managing traffic in Kubernetes environments. The project’s maturity, active development, and commitment to open standards made it particularly attractive as we evaluated solutions for our platform. While evaluating the project, I noticed an LFX mentorship opportunity that focused on an area directly related to my background. The timing felt perfect. Rather than simply consuming the project as a user, I wanted to contribute back and become an active member of the community. The mentorship program offered an ideal starting point. Why an LFX mentorship? There is a common misconception that the LFX Mentorship program is only for students or early-career engineers. With five years of experience in cloud native API gateways and networking, I was already comfortable working with Go, Kubernetes, and Envoy Proxy. However, joining a mature open source ecosystem as a newcomer can still be challenging. Every project has its own architecture, governance model, testing practices, and community norms that take time to understand. At the same time, balancing a full-time job and family commitments means open source contributions often lack consistency without structure. Without a clear scope and guidance, it’s easy for contributions to get delayed or lose momentum. I saw the LFX Mentorship for kgateway as the ideal starting point. It provided structured onboarding, a well-defined project scope, and direct weekly interaction with core maintainers. I applied, was accepted, and my journey began. The mentorship experience From day one, I was working closely with core maintainers, which made a huge difference in understanding the project. Instead of spending weeks trying to decode design decisions on my own, I was able to get direct context on architecture, trade-offs, and long term direction. The focus of my mentorship was adding chaos engineering support to kgateway through HTTP fault injection . The idea is to let platform teams deliberately inject failures, such as delays and aborts, into their traffic so they can validate how resilient their services are before those failures show up in production. My core deliverable was implementing fault injection support by extending TrafficPolicy , covering delay injection, abort injection with both HTTP and gRPC status codes, response rate limiting, and a per-route override to disable it. Under the hood it maps to the Envoy HTTP fault filter, which is added to the filter chain disabled by default and enabled selectively per route or virtual host. This keeps the feature completely inert unless a policy explicitly opts in. The learning curve was still real. kgateway sits at the intersection of Kubernetes, Envoy Proxy, and the Gateway API, so even small changes often required understanding multiple layers of the system. But having a structured path and regular syncs kept the progress steady and focused. Some of the key areas I gained a deep understanding of during the mentorship included: Understanding the internal architecture of the kgateway control plane Kubernetes Gateway API implementation within kgateway kgateway plugin architecture for extensible policy design Abstracting low-level Envoy Proxy configuration into developer facing policies kgateway policy merge implementation and merge strategies Community collaboration and open source development workflows What stood out most was how iterative and collaborative the process was. Every contribution went through thoughtful review, not just for correctness, but for long-term maintainability and alignment with the direction of the project. By the end of the mentorship, I had not only completed the assigned project work but also built enough context to contribute independently without needing step-by-step guidance. Beyond the mentorship For me, the mentorship was never intended to be a one-time contribution. My goal from the beginning was to use the program as a starting point for a deeper involvement in the project and community. After completing the mentorship project, I continued contributing to kgateway by working on new features, bug fixes, and community discussions. The transition from mentee to regular contributor felt natural because the mentorship had already provided the context, relationships, and confidence needed to contribute independently. Since completing the program, I have continued contributing to kgateway by: Contributing feature enhancements Fixing bugs and improving project stability Participating in technical discussions Reviewing and collaborating on community contributions Helping shape future improvements to the project A couple of contributions I am