We want to support Gateway API because it is documented as the defacto standard for Kubernetes. However it has a lot of portability problems: it was never shipped as a core API, and as a CRD you get a lot of variance on how the API is handled, and what version it is platform-to-platform. You can't be sure whether the platform will let you modify or update it, and in general it's basically in an unpredictable state for any project that wants to be cross-platform. The project went to GA without realizing any plans to resolve these issues. As such, it is not wise for a project like this to support only Gateway API, as it's unpredictable what version or management problems one will find from platform to platform. The purpose of this task is to spike a custom API solution that would be the first tier solution, with Gateway API as a supported, but optional alternative.
We want to support Gateway API because it is documented as the defacto standard for Kubernetes. However it has a lot of portability problems: it was never shipped as a core API, and as a CRD you get a lot of variance on how the API is handled, and what version it is platform-to-platform. You can't be sure whether the platform will let you modify or update it, and in general it's basically in an unpredictable state for any project that wants to be cross-platform. The project went to GA without realizing any plans to resolve these issues. As such, it is not wise for a project like this to support only Gateway API, as it's unpredictable what version or management problems one will find from platform to platform. The purpose of this task is to spike a custom API solution that would be the first tier solution, with Gateway API as a supported, but optional alternative.