xK8s

Kuadrant has been designed to work with any Kubernetes distribution that is capable of running one of the supported Gateway API implementations. In practice though, only minimal effort has been made in the sense of validating this claim, with major representation of either:
- Controlled, local, dev/testing environments (single-node Kubernetes clusters spawned with [Kind](https://kind.sigs.k8s.io)), or
- [OpenShift](https://www.redhat.com/en/technologies/cloud-computing/openshift).

Even though unofficial reports have shared experiences running Kuadrant on various environments, the project lacks documented use cases – via documentation, examples & user guides, and regular testing infrastructure – for other CNCF conformant distributions such as:
- [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/)
- [Azure Kubernetes Service (AKS)](https://azure.microsoft.com/en-us/products/kubernetes-service/)
- [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine)

**User Stories**

> _As an organization, I have multiple clusters. Some are running in cloud-managed Kubernetes environments, others on-prem. I would like to leverage Kuadrant to protect ingress on all of my production Kubernetes clusters._

> _As a prospective user, I am not invested nor interested in setting up another specific Kubernetes distribution that Kuadrant has been proven to work with. Nevertheless, I would like to try Kuadrant on my existing infrastructure with enough level of confidence it will work without caveats._

**Goals**

- **Testing Infrastructure**: Establish CI/CD testing pipelines for EKS, AKS, and GKE to validate Kuadrant functionality on each platform
- **Documentation**: Create installation guides, usage examples, and troubleshooting documentation specific to each supported distribution
- **Distribution Compatibility**: Identify and resolve any distribution-specific issues or incompatibilities
- **Gateway API Implementation Validation**: Verify Kuadrant works with supported Gateway API implementations (e.g., Istio, Envoy Gateway) on each platform
- **User Confidence**: Provide clear signals to users that Kuadrant is tested and validated on their chosen Kubernetes distribution

**Out of Scope (Non-Goals)**

- **Non-CNCF Conformant Distributions**: Support is limited to CNCF conformant Kubernetes distributions
- **Cloud-Provider Specific Features**: Deep integration with cloud-provider-specific annotations, controllers, or services beyond standard Kubernetes APIs
- **Alternative Installation Methods**: OLM-based installation for non-OpenShift platforms (Helm is the primary method)
- **Unsupported Gateway Implementations**: Gateway API implementations not officially supported by Kuadrant

**Assumptions**

- **Gateway API CRDs**: Users are responsible for installing Gateway API CRDs; Kuadrant can dictate a minimum required version
- **Gateway Provider**: Supported Gateway API implementations (e.g., Istio, Envoy Gateway) are compatible with the target Kubernetes distributions
- **Unified Codebase**: Maintain a consistent codebase and feature set across all supported platforms to minimize divergent code paths
- **Feature Compatibility**: All Kuadrant features must be compatible with standard Kubernetes APIs, not relying on OpenShift-specific APIs

Start by breaking the goals into validation, CI/CD, documentation, and compatibility work for EKS, AKS, and GKE. Review the supported Gateway API implementations and the stated assumptions about CRDs, Helm, and standard Kubernetes APIs. Done means documented use cases and installation guidance, platform testing signals, and any distribution-specific incompatibilities identified and resolved.

Written by the indexing model from the issue text.