Repository: Kong/kubernetes-ingress-controller
Pull request #2267 (2022-02-15 22:21:13)

docs: cleanup gateway apis kep
**What this PR does / why we need it**:

The `Gateway` support KEP was getting dated in several ways, this patch performs some cleanup:

- simplifies wording in several sections
- removes no longer relevant managed gateway support
- re-defines the graduation criteria milestones
- fix broken links and add new relevant links
- expands on alternatives

Ultimately the new KEP better resembles the "unmanaged" `Gateway` support that we're actively implementing.


Patch:
diff --git a/.github/workflows/license.yaml b/.github/workflows/license.yaml
index 830cbae91..2f6a64475 100644
--- a/.github/workflows/license.yaml
+++ b/.github/workflows/license.yaml
@@ -5,8 +5,37 @@ on:
   pull_request: {}
 
 jobs:
+  runnable:
+    runs-on: ubuntu-latest
+    outputs:
+      runnable: ${{ steps.check.outputs.result }}
+    steps:
+    - name: Check repo access
+      id: check
+      uses: actions/github-script@v6
+      with:
+        github-token: ${{ secrets.GITHUB_TOKEN }}
+        script: |
+            github.hook.error("request", async (error, options) => {
+              // 403 is no access to check, 404 is access to check but not a collaborator
+              if (error.status === 403 || error.status === 404 ) {
+                return false;
+              } else {
+                throw error;
+              }
+            });
+            var result = await github.rest.repos.checkCollaborator({
+              owner: "Kong",
+              repo: "kubernetes-ingress-controller",
+              username: "${{ github.event.pull_request.user.login }}"
+            });
+            if (result.status === 204) {
+              return true
+            }
+
   licenses:
-    if: "!contains(github.event.pull_request.labels.*.name, 'ci/license/changed')"
+    needs: runnable
+    if: "!contains(github.event.pull_request.labels.*.name, 'ci/license/changed') && needs.runnable.outputs.runnable == 'true'"
     env:
       GOPATH: ${{ github.workspace }}
       GOBIN: ${{ github.workspace }}/bin
diff --git a/go.mod b/go.mod
index 5e89d18f5..fd23c99ce 100644
--- a/go.mod
+++ b/go.mod
@@ -12,7 +12,7 @@ require (
 	github.com/google/uuid v1.3.0
 	github.com/kong/deck v1.10.0
 	github.com/kong/go-kong v0.28.0
-	github.com/kong/kubernetes-testing-framework v0.12.1
+	github.com/kong/kubernetes-testing-framework v0.13.0
 	github.com/lithammer/dedent v1.1.0
 	github.com/miekg/dns v1.1.46
 	github.com/mitchellh/mapstructure v1.4.3
@@ -26,15 +26,15 @@ require (
 	github.com/tidwall/gjson v1.14.0
 	google.golang.org/api v0.69.0
 	google.golang.org/genproto v0.0.0-20220211171837-173942840c17
-	k8s.io/api v0.23.3
-	k8s.io/apiextensions-apiserver v0.23.3
-	k8s.io/apimachinery v0.23.3
-	k8s.io/client-go v0.23.3
-	k8s.io/component-base v0.23.3
+	k8s.io/api v0.23.4
+	k8s.io/apiextensions-apiserver v0.23.4
+	k8s.io/apimachinery v0.23.4
+	k8s.io/client-go v0.23.4
+	k8s.io/component-base v0.23.4
 	knative.dev/networking v0.0.0-20220120043934-ec785540a732
 	knative.dev/pkg v0.0.0-20220118160532-77555ea48cd4
-	knative.dev/serving v0.29.1
-	sigs.k8s.io/controller-runtime v0.11.0
+	knative.dev/serving v0.29.2
+	sigs.k8s.io/controller-runtime v0.11.1
 	sigs.k8s.io/gateway-api v0.4.1
 	sigs.k8s.io/kustomize/api v0.11.2
 	sigs.k8s.io/kustomize/kyaml v0.13.3
diff --git a/go.sum b/go.sum
index f5fd8b892..6727b865a 100644
--- a/go.sum
+++ b/go.sum
@@ -42,7 +42,6 @@ cloud.google.com/go/bigquery v1.8.0/go.mod h1:J5hqkt3O0uAFnINi6JXValWIb1v0goeZM7
 cloud.google.com/go/compute v0.1.0/go.mod h1:GAesmwr110a34z04OlxYkATPBEfVhkymfTBXtfbBFow=
 cloud.google.com/go/compute v1.2.0 h1:EKki8sSdvDU0OO9mAXGwPXOTOgPz2l08R0/IutDH11I=
 cloud.google.com/go/compute v1.2.0/go.mod h1:xlogom/6gr8RJGBe7nT2eGsQYAFUbbv8dbC29qE3Xmw=
-cloud.google.com/go/container v1.0.0/go.mod h1:EQLhTDFhzVXTX6TmjfNqa3/ikbCzjGlZcGY67exUnlY=
 cloud.google.com/go/container v1.1.0 h1:iSWANLBNSwLjJum69+FlA96vFBTSASCiS7+ZGeJu8K0=
 cloud.google.com/go/container v1.1.0/go.mod h1:+BsZKG08AmEAL+cJhSCZM5l3v6/HfktjrN2CXrxz6po=
 cloud.google.com/go/datastore v1.0.0/go.mod h1:LXYbyblFSglQ5pkeyhO+Qmw7ukd3C+pD7TKLgZqpHYE=
@@ -898,7 +897,7 @@ github.com/jcmturner/goidentity/v6 v6.0.1/go.mod h1:X1YW3bgtvwAXju7V3LCIMpY0Gbxy
 github.com/jcmturner/gokrb5/v8 v8.4.2/go.mod h1:sb+Xq/fTY5yktf/VxLsE3wlfPqQjp0aWNYyvBVK62bc=
 github.com/jcmturner/rpc/v2 v2.0.3/go.mod h1:VUJYCIDm3PVOEHw8sgt091/20OJjskO/YJki3ELg/Hc=
 github.com/jessevdk/go-flags v1.4.0/go.mod h1:4FA24M0QyGHXBuZZK/XkWh8h0e1EYbRYJSGM75WSRxI=
-github.com/jetstack/cert-manager v1.7.0/go.mod h1:xj0TPp31HE0Jub5mNOnF3Fp3XvhIsiP+tsPZVOmU/Qs=
+github.com/jetstack/cert-manager v1.7.1/go.mod h1:xj0TPp31HE0Jub5mNOnF3Fp3XvhIsiP+tsPZVOmU/Qs=
 github.com/jmespath/go-jmespath v0.0.0-20160202185014-0b12d6b521d8/go.mod h1:Nht3zPeWKUH0NzdCt2Blrr5ys8VGpn0CEB0cQHVjt7k=
 github.com/jmespath/go-jmespath v0.0.0-20160803190731-bd40a432e4c7/go.mod h1:Nht3zPeWKUH0NzdCt2Blrr5ys8VGpn0CEB0cQHVjt7k=
 github.com/jmespath/go-jmespath v0.0.0-20180206201540-c2b33e8439af/go.mod h1:Nht3zPeWKUH0NzdCt2Blrr5ys8VGpn0CEB0cQHVjt7k=
@@ -939,11 +938,10 @@ github.com/kong/deck v1.10.0 h1:lSGbl+B/mE75TYtI92qIsg0R9fKFC1moXL52bKmocjk=
 github.com/kong/deck v1.10.0/go.mod h1:bk8MZu2kQvNzYJeQ6uF+BaUXO5ECDP1S4nFE7pP5yt0=
 github.com/kong/go-kong v0.25.1/go.mod h1:8Dl/eA8SVH3aJNOkS91J8CPf5oUHZ2+XSYvacrF5PBc=
 github.com/kong/go-kong v0.25.1/go.mod h1:8Dl/eA8SVH3aJNOkS91J8CPf5oUHZ2+XSYvacrF5PBc=
-github.com/kong/go-kong v0.26.0/go.mod h1:W1rTawoOanrC1j4KO3p1X1Xuwm3mQXrKby5boBUQTso=
 github.com/kong/go-kong v0.28.0 h1:xmcuzi2N16VX1tAYP1rn4zQp4AQUmVPZvYP663xbAjc=
 github.com/kong/go-kong v0.28.0/go.mod h1:bbC56mBqvnYZmzAWujmUqONXhloPWLs8r4A07uT8EzE=
-github.com/kong/kubernetes-testing-framework v0.12.1 h1:j8HTQTP4nkKGkt2+YtpsAPinrOmT0uiNP8mASSzhSl0=
-github.com/kong/kubernetes-testing-framework v0.12.1/go.mod h1:fupa1x3EVLT+CwQNmbBaMPaEPrG7N3JlM1/4kgcxt+s=
+github.com/kong/kubernetes-testing-framework v0.13.0 h1:sJgE1u6Ixdz1RI8pkt+D7oHepH5OqSWQzVTglJxYT2I=
+github.com/kong/kubernetes-testing-framework v0.13.0/go.mod h1:72ywlPzfpsfIYOGFIzKIjFl55mB8VYwa7lgFHmesEPM=
 github.com/konsorten/go-windows-terminal-sequences v1.0.1/go.mod h1:T0+1ngSBFLxvqU3pZ+m/2kptfBszLMUkC4ZK/EgS/cQ=
 github.com/konsorten/go-windows-terminal-sequences v1.0.2/go.mod h1:T0+1ngSBFLxvqU3pZ+m/2kptfBszLMUkC4ZK/EgS/cQ=
 github.com/konsorten/go-windows-terminal-sequences v1.0.3/go.mod h1:T0+1ngSBFLxvqU3pZ+m/2kptfBszLMUkC4ZK/EgS/cQ=
@@ -1337,7 +1335,6 @@ github.com/syndtr/gocapability v0.0.0-20170704070218-db04d3cc01c8/go.mod h1:hkRG
 github.com/syndtr/gocapability v0.0.0-20180916011248-d98352740cb2/go.mod h1:hkRG7XYTFWNJGYcbNJQlaLq0fg1yr4J4t/NcTQtrfww=
 github.com/syndtr/gocapability v0.0.0-20200815063812-42c35b437635/go.mod h1:hkRG7XYTFWNJGYcbNJQlaLq0fg1yr4J4t/NcTQtrfww=
 github.com/tchap/go-patricia v2.2.6+incompatible/go.mod h1:bmLyhP68RS6kStMGxByiQ23RP/odRBOTVjwp2cDyi6I=
-github.com/tidwall/gjson v1.13.0/go.mod h1:/wbyibRr2FHMks5tjHJ5F8dMZh3AcwJEMf5vlfC0lxk=
 github.com/tidwall/gjson v1.14.0 h1:6aeJ0bzojgWLa82gDQHcx3S0Lr/O51I9bJ5nv6JFx5w=
 github.com/tidwall/gjson v1.14.0/go.mod h1:/wbyibRr2FHMks5tjHJ5F8dMZh3AcwJEMf5vlfC0lxk=
 github.com/tidwall/match v1.1.1 h1:+Ho715JplO36QYgwN9PGYNhgZvoUSc9X2c80KVTi+GA=
@@ -1632,7 +1629,6 @@ golang.org/x/net v0.0.0-20211015210444-4f30a5c0130f/go.mod h1:9nx3DQGgdP8bBQD5qx
 golang.org/x/net v0.0.0-20211112202133-69e39bad7dc2/go.mod h1:9nx3DQGgdP8bBQD5qxJ1jj9UTztislL4KSBs9R2vV5Y=
 golang.org/x/net v0.0.0-20211209124913-491a49abca63/go.mod h1:9nx3DQGgdP8bBQD5qxJ1jj9UTztislL4KSBs9R2vV5Y=
 golang.org/x/net v0.0.0-20211216030914-fe4d6282115f/go.mod h1:9nx3DQGgdP8bBQD5qxJ1jj9UTztislL4KSBs9R2vV5Y=
-golang.org/x/net v0.0.0-20220105145211-5b0dc2dfae98/go.mod h1:9nx3DQGgdP8bBQD5qxJ1jj9UTztislL4KSBs9R2vV5Y=
 golang.org/x/net v0.0.0-20220127200216-cd36cc0744dd h1:O7DYs+zxREGLKzKoMQrtrEacpb0ZVXA5rIwylE2Xchk=
 golang.org/x/net v0.0.0-20220127200216-cd36cc0744dd/go.mod h1:CfG3xpIq0wQ8r1q4Su4UZFWDARRcnwPjda9FqA0JpMk=
 golang.org/x/oauth2 v0.0.0-20180821212333-d2e6202438be/go.mod h1:N/0e6XlmueqKjAGxoOufVs8QHGRruUQn6yWY3a++T0U=
@@ -2037,7 +2033,6 @@ google.golang.org/genproto v0.0.0-20210903162649-d08c68adba83/go.mod h1:eFjDcFEc
 google.golang.org/genproto v0.0.0-20210909211513-a8c4777a87af/go.mod h1:eFjDcFEctNawg4eG61bRv87N7iHBWyVhJu7u1kqDUXY=
 google.golang.org/genproto v0.0.0-20210917145530-b395a37504d4/go.mod h1:eFjDcFEctNawg4eG61bRv87N7iHBWyVhJu7u1kqDUXY=
 google.golang.org/genproto v0.0.0-20210917145530-b395a37504d4/go.mod h1:eFjDcFEctNawg4eG61bRv87N7iHBWyVhJu7u1kqDUXY=
-google.golang.org/genproto v0.0.0-20210921142501-181ce0d877f6/go.mod h1:5CzLGKJ67TSI2B9POpiiyGha0AjJvZIUgRMt1dSmuhc=
 google.golang.org/genproto v0.0.0-20210924002016-3dee208752a0/go.mod h1:5CzLGKJ67TSI2B9POpiiyGha0AjJvZIUgRMt1dSmuhc=
 google.golang.org/genproto v0.0.0-20211008145708-270636b82663/go.mod h1:5CzLGKJ67TSI2B9POpiiyGha0AjJvZIUgRMt1dSmuhc=
 google.golang.org/genproto v0.0.0-20211016002631-37fc39342514/go.mod h1:5CzLGKJ67TSI2B9POpiiyGha0AjJvZIUgRMt1dSmuhc=
@@ -2176,8 +2171,9 @@ k8s.io/api v0.22.2/go.mod h1:y3ydYpLJAaDI+BbSe2xmGcqxiWHmWjkEeIbiwHvnPR8=
 k8s.io/api v0.22.5/go.mod h1:mEhXyLaSD1qTOf40rRiKXkc+2iCem09rWLlFwhCEiAs=
 k8s.io/api v0.23.0/go.mod h1:8wmDdLBHBNxtOIytwLstXt5E9PddnZb0GaMcqsvDBpg=
 k8s.io/api v0.23.1/go.mod h1:WfXnOnwSqNtG62Y1CdjoMxh7r7u9QXGCkA1u0na2jgo=
-k8s.io/api v0.23.3 h1:KNrME8KHGr12Ozjf8ytOewKzZh6hl/hHUZeHddT3a38=
 k8s.io/api v0.23.3/go.mod h1:w258XdGyvCmnBj/vGzQMj6kzdufJZVUwEM1U2fRJwSQ=
+k8s.io/api v0.23.4 h1:85gnfXQOWbJa1SiWGpE9EEtHs0UVvDyIsSMpEtl2D4E=
+k8s.io/api v0.23.4/go.mod h1:i77F4JfyNNrhOjZF7OwwNJS5Y1S9dpwvb9iYRYRczfI=
 k8s.io/apiextensions-apiserver v0.18.0/go.mod h1:18Cwn1Xws4xnWQNC00FLq1E350b9lUF+aOdIWDOZxgo=
 k8s.io/apiextensions-apiserver v0.20.1/go.mod h1:ntnrZV+6a3dB504qwC5PN/Yg9PBiDNt1EVqbW2kORVk=
 k8s.io/apiextensions-apiserver v0.20.2/go.mod h1:F6TXp389Xntt+LUq3vw6HFOLttPa0V8821ogLGwb6Zs=
@@ -2188,8 +2184,9 @@ k8s.io/apiextensions-apiserver v0.22.2/go.mod h1:2E0Ve/isxNl7tWLSUDgi6+cmwHi5fQR
 k8s.io/apiextensions-apiserver v0.22.5/go.mod h1:tIXeZ0BrDxUb1PoAz+tgOz43Zi1Bp4BEEqVtUccMJbE=
 k8s.io/apiextensions-apiserver v0.23.0/go.mod h1:xIFAEEDlAZgpVBl/1VSjGDmLoXAWRG40+GsWhKhAxY4=
 k8s.io/apiextensions-apiserver v0.23.1/go.mod h1:0qz4fPaHHsVhRApbtk3MGXNn2Q9M/cVWWhfHdY2SxiM=
-k8s.io/apiextensions-apiserver v0.23.3 h1:JvPJA7hSEAqMRteveq4aj9semilAZYcJv+9HHFWfUdM=
 k8s.io/apiextensions-apiserver v0.23.3/go.mod h1:/ZpRXdgKZA6DvIVPEmXDCZJN53YIQEUDF+hrpIQJL38=
+k8s.io/apiextensions-apiserver v0.23.4 h1:AFDUEu/yEf0YnuZhqhIFhPLPhhcQQVuR1u3WCh0rveU=
+k8s.io/apiextensions-apiserver v0.23.4/go.mod h1:TWYAKymJx7nLMxWCgWm2RYGXHrGlVZnxIlGnvtfYu+g=
 k8s.io/apimachinery v0.18.0/go.mod h1:9SnR/e11v5IbyPCGbvJViimtJ0SwHG4nfZFjU77ftcA=
 k8s.io/apimachinery v0.20.1/go.mod h1:WlLqWAHZGg07AeltaI0MV5uk1Omp8xaN0JGLY6gkRpU=
 k8s.io/apimachinery v0.20.2/go.mod h1:WlLqWAHZGg07AeltaI0MV5uk1Omp8xaN0JGLY6gkRpU=
@@ -2202,8 +2199,9 @@ k8s.io/apimachinery v0.22.2/go.mod h1:O3oNtNadZdeOMxHFVxOreoznohCpy0z6mocxbZr7oJ
 k8s.io/apimachinery v0.22.5/go.mod h1:xziclGKwuuJ2RM5/rSFQSYAj0zdbci3DH8kj+WvyN0U=
 k8s.io/apimachinery v0.23.0/go.mod h1:fFCTTBKvKcwTPFzjlcxp91uPFZr+JA0FubU4fLzzFYc=
 k8s.io/apimachinery v0.23.1/go.mod h1:SADt2Kl8/sttJ62RRsi9MIV4o8f5S3coArm0Iu3fBno=
-k8s.io/apimachinery v0.23.3 h1:7IW6jxNzrXTsP0c8yXz2E5Yx/WTzVPTsHIx/2Vm0cIk=
 k8s.io/apimachinery v0.23.3/go.mod h1:BEuFMMBaIbcOqVIJqNZJXGFTP4W6AycEpb5+m/97hrM=
+k8s.io/apimachinery v0.23.4 h1:fhnuMd/xUL3Cjfl64j5ULKZ1/J9n8NuQEgNL+WXWfdM=
+k8s.io/apimachinery v0.23.4/go.mod h1:BEuFMMBaIbcOqVIJqNZJXGFTP4W6AycEpb5+m/97hrM=
 k8s.io/apiserver v0.18.0/go.mod h1:3S2O6FeBBd6XTo0njUrLxiqk8GNy6wWOftjhJcXYnjw=
 k8s.io/apiserver v0.20.1/go.mod h1:ro5QHeQkgMS7ZGpvf4tSMx6bBOgPfE+f52KwvXfScaU=
 k8s.io/apiserver v0.20.2/go.mod h1:2nKd93WyMhZx4Hp3RfgH2K5PhwyTrprrkWYnI7id7jA=
@@ -2216,6 +2214,7 @@ k8s.io/apiserver v0.22.5/go.mod h1:s2WbtgZAkTKt679sYtSudEQrTGWUSQAPe6MupLnlmaQ=
 k8s.io/apiserver v0.23.0/go.mod h1:Cec35u/9zAepDPPFyT+UMrgqOCjgJ5qtfVJDxjZYmt4=
 k8s.io/apiserver v0.23.1/go.mod h1:Bqt0gWbeM2NefS8CjWswwd2VNAKN6lUKR85Ft4gippY=
 k8s.io/apiserver v0.23.3/go.mod h1:3HhsTmC+Pn+Jctw+Ow0LHA4dQ4oXrQ4XJDzrVDG64T4=
+k8s.io/apiserver v0.23.4/go.mod h1:A6l/ZcNtxGfPSqbFDoxxOjEjSKBaQmE+UTveOmMkpNc=
 k8s.io/cli-runtime v0.22.1/go.mod h1:YqwGrlXeEk15Yn3em2xzr435UGwbrCw5x+COQoTYfoo=
 k8s.io/cli-runtime v0.23.1/go.mod h1:r9r8H/qfXo9w+69vwUL7LokKlLRKW5D6A8vUKCx+YL0=
 k8s.io/client-go v0.18.0/go.mod h1:uQSYDYs4WhVZ9i6AIoEZuwUggLVEF64HOD37boKAtF8=
@@ -2230,8 +2229,9 @@ k8s.io/client-go v0.22.2/go.mod h1:sAlhrkVDf50ZHx6z4K0S40wISNTarf1r800F+RlCF6U=
 k8s.io/client-go v0.22.5/go.mod h1:cs6yf/61q2T1SdQL5Rdcjg9J1ElXSwbjSrW2vFImM4Y=
 k8s.io/client-go v0.23.0/go.mod h1:hrDnpnK1mSr65lHHcUuIZIXDgEbzc7/683c6hyG4jTA=
 k8s.io/client-go v0.23.1/go.mod h1:6QSI8fEuqD4zgFK0xbdwfB/PthBsIxCJMa3s17WlcO0=
-k8s.io/client-go v0.23.3 h1:23QYUmCQ/W6hW78xIwm3XqZrrKZM+LWDqW2zfo+szJs=
 k8s.io/client-go v0.23.3/go.mod h1:47oMd+YvAOqZM7pcQ6neJtBiFH7alOyfunYN48VsmwE=
+k8s.io/client-go v0.23.4 h1:YVWvPeerA2gpUudLelvsolzH7c2sFoXXR5wM/sWqNFU=
+k8s.io/client-go v0.23.4/go.mod h1:PKnIL4pqLuvYUK1WU7RLTMYKPiIh7MYShLshtRY9cj0=
 k8s.io/code-generator v0.18.0/go.mod h1:+UHX5rSbxmR8kzS+FAv7um6dtYrZokQvjHpDSYRVkTc=
 k8s.io/code-generator v0.19.7/go.mod h1:lwEq3YnLYb/7uVXLorOJfxg+cUu2oihFhHZ0n9NIla0=
 k8s.io/code-generator v0.20.1/go.mod h1:UsqdF+VX4PU2g46NC2JRs4gc+IfrctnwHb76RNbWHJg=
@@ -2246,6 +2246,7 @@ k8s.io/code-generator v0.22.5/go.mod h1:sbdWCOVob+KaQ5O7xs8PNNaCTpbWVqNgA6EPwLOm
 k8s.io/code-generator v0.23.0/go.mod h1:vQvOhDXhuzqiVfM/YHp+dmg10WDZCchJVObc9MvowsE=
 k8s.io/code-generator v0.23.1/go.mod h1:V7yn6VNTCWW8GqodYCESVo95fuiEg713S8B7WacWZDA=
 k8s.io/code-generator v0.23.3/go.mod h1:S0Q1JVA+kSzTI1oUvbKAxZY/DYbA/ZUb4Uknog12ETk=
+k8s.io/code-generator v0.23.4/go.mod h1:S0Q1JVA+kSzTI1oUvbKAxZY/DYbA/ZUb4Uknog12ETk=
 k8s.io/component-base v0.18.0/go.mod h1:u3BCg0z1uskkzrnAKFzulmYaEpZF7XC9Pf/uFyb1v2c=
 k8s.io/component-base v0.20.1/go.mod h1:guxkoJnNoh8LNrbtiQOlyp2Y2XFCZQmrcg2n/DeYNLk=
 k8s.io/component-base v0.20.2/go.mod h1:pzFtCiwe/ASD0iV7ySMu8SYVJjCapNM9bjvk7ptpKh0=
@@ -2257,8 +2258,9 @@ k8s.io/component-base v0.22.2/go.mod h1:5Br2QhI9OTe79p+TzPe9JKNQYvEKbq9rTJDWllun
 k8s.io/component-base v0.22.5/go.mod h1:VK3I+TjuF9eaa+Ln67dKxhGar5ynVbwnGrUiNF4MqCI=
 k8s.io/component-base v0.23.0/go.mod h1:DHH5uiFvLC1edCpvcTDV++NKULdYYU6pR9Tt3HIKMKI=
 k8s.io/component-base v0.23.1/go.mod h1:6llmap8QtJIXGDd4uIWJhAq0Op8AtQo6bDW2RrNMTeo=
-k8s.io/component-base v0.23.3 h1:q+epprVdylgecijVGVdf4MbizEL2feW4ssd7cdo6LVY=
 k8s.io/component-base v0.23.3/go.mod h1:1Smc4C60rWG7d3HjSYpIwEbySQ3YWg0uzH5a2AtaTLg=
+k8s.io/component-base v0.23.4 h1:SziYh48+QKxK+ykJ3Ejqd98XdZIseVBG7sBaNLPqy6M=
+k8s.io/component-base v0.23.4/go.mod h1:8o3Gg8i2vnUXGPOwciiYlkSaZT+p+7gA9Scoz8y4W4E=
 k8s.io/component-helpers v0.22.1/go.mod h1:QvBcDbX+qU5I2tMZABBF5fRwAlQwiv771IGBHK9WYh4=
 k8s.io/component-helpers v0.23.1/go.mod h1:ZK24U+2oXnBPcas2KolLigVVN9g5zOzaHLkHiQMFGr0=
 k8s.io/cri-api v0.17.3/go.mod h1:X1sbHmuXhwaHs9xxYffLqJogVsnI+f6cPRcgPel7ywM=
@@ -2321,8 +2323,8 @@ knative.dev/networking v0.0.0-20220120043934-ec785540a732 h1:fUUb5NWfYm8TQkhv1uF
 knative.dev/networking v0.0.0-20220120043934-ec785540a732/go.mod h1:6cKBV/h/vIQWCPOkds/RvzUmMR8Vz6Dks2NWb0+3xks=
 knative.dev/pkg v0.0.0-20220118160532-77555ea48cd4 h1:b9aXVrcfM/ajjHE/lGvlJOHZNAR5FF2TOTLWG7eMhzQ=
 knative.dev/pkg v0.0.0-20220118160532-77555ea48cd4/go.mod h1:etVT7Tm8pSDf4RKhGk4r7j/hj3dNBpvT7bO6a6wpahs=
-knative.dev/serving v0.29.1 h1:v6zYR/mSvVt/BpiX1AvSkDzm3uUWYqYSIoLj5pE70Xo=
-knative.dev/serving v0.29.1/go.mod h1:8Ay9QjyTcqoJE+2PietSmT5/VMdSQHe5aIBhsAFOCjM=
+knative.dev/serving v0.29.2 h1:QBEUJJR7qyBm/PLu3/Z+p673ZjbffyJvD8La5OO55UE=
+knative.dev/serving v0.29.2/go.mod h1:8Ay9QjyTcqoJE+2PietSmT5/VMdSQHe5aIBhsAFOCjM=
 oras.land/oras-go v0.4.0/go.mod h1:VJcU+VE4rkclUbum5C0O7deEZbBYnsnpbGSACwTjOcg=
 pgregory.net/rapid v0.3.3/go.mod h1:UYpPVyjFHzYBGHIxLFoupi8vwk6rXNzRY9OMvVxFIOU=
 rsc.io/binaryregexp v0.2.0/go.mod h1:qTv7/COck+e2FymRvadv62gMdZztPaShugOCi3I+8D8=
@@ -2338,8 +2340,9 @@ sigs.k8s.io/apiserver-network-proxy/konnectivity-client v0.0.25/go.mod h1:Mlj9PN
 sigs.k8s.io/apiserver-network-proxy/konnectivity-client v0.0.27/go.mod h1:tq2nT0Kx7W+/f2JVE+zxYtUhdjuELJkVpNz+x/QN5R4=
 sigs.k8s.io/controller-runtime v0.8.3/go.mod h1:U/l+DUopBc1ecfRZ5aviA9JDmGFQKvLf5YkZNx2e0sU=
 sigs.k8s.io/controller-runtime v0.9.6/go.mod h1:q6PpkM5vqQubEKUKOM6qr06oXGzOBcCby1DA9FbyZeA=
-sigs.k8s.io/controller-runtime v0.11.0 h1:DqO+c8mywcZLFJWILq4iktoECTyn30Bkj0CwgqMpZWQ=
 sigs.k8s.io/controller-runtime v0.11.0/go.mod h1:KKwLiTooNGu+JmLZGn9Sl3Gjmfj66eMbCQznLP5zcqA=
+sigs.k8s.io/controller-runtime v0.11.1 h1:7YIHT2QnHJArj/dk9aUkYhfqfK5cIxPOX5gPECfdZLU=
+sigs.k8s.io/controller-runtime v0.11.1/go.mod h1:KKwLiTooNGu+JmLZGn9Sl3Gjmfj66eMbCQznLP5zcqA=
 sigs.k8s.io/controller-tools v0.5.0/go.mod h1:JTsstrMpxs+9BUj6eGuAaEb6SDSPTeVtUyp0jmnAM/I=
 sigs.k8s.io/controller-tools v0.6.2/go.mod h1:oaeGpjXn6+ZSEIQkUe/+3I40PNiDYp9aeawbt3xTgJ8=
 sigs.k8s.io/controller-tools v0.7.0/go.mod h1:bpBAo0VcSDDLuWt47evLhMLPxRPxMDInTEH/YbdeMK0=
diff --git a/internal/dataplane/parser/translate_httproute.go b/internal/dataplane/parser/translate_httproute.go
index 4530d3bdb..5395eb3a4 100644
--- a/internal/dataplane/parser/translate_httproute.go
+++ b/internal/dataplane/parser/translate_httproute.go
@@ -122,11 +122,6 @@ func generateKongRoutesFromHTTPRouteRule(httproute *gatewayv1alpha2.HTTPRoute, r
 				return nil, fmt.Errorf("query param matches are not yet supported")
 			}
 
-			// TODO: implement regex path matches
-			if *match.Path.Type == gatewayv1alpha2.PathMatchRegularExpression {
-				return nil, fmt.Errorf("regular expression path matches are not yet supported")
-			}
-
 			// build the route object using the method and pathing information
 			r := kongstate.Route{
 				Ingress: objectInfo,
@@ -142,14 +137,17 @@ func generateKongRoutesFromHTTPRouteRule(httproute *gatewayv1alpha2.HTTPRoute, r
 				r.Hosts = hostnames
 			}
 
-			// configure path matching information about the route if paths
-			// matching was defined.
+			// configure path matching information about the route if paths matching was defined
+			// Kong automatically infers whether or not a path is a regular expression and uses a prefix match by
+			// default it it is not. For those types, we use the path value as-is and let Kong determine the type.
+			// For exact matches, we transform the path into a regular expression that terminates after the value
 			if match.Path != nil {
-				// determine the path match values
-				r.Route.Paths = []*string{match.Path.Value}
-
-				// determine whether path stripping needs to be enabled
-				r.Route.StripPath = kong.Bool(match.Path.Type == nil || *match.Path.Type == gatewayv1alpha2.PathMatchPathPrefix)
+				if *match.Path.Type == gatewayv1alpha2.PathMatchExact {
+					terminated := *match.Path.Value + "$"
+					r.Route.Paths = []*string{&terminated}
+				} else if *match.Path.Type == gatewayv1alpha2.PathMatchRegularExpression || *match.Path.Type == gatewayv1alpha2.PathMatchPathPrefix {
+					r.Route.Paths = []*string{match.Path.Value}
+				}
 			}
 
 			// configure method matching information about the route if method
diff --git a/keps/0002-kong-gateway-api.md b/keps/0002-kong-gateway-api.md
index d8ffe621d..027d3a85e 100644
--- a/keps/0002-kong-gateway-api.md
+++ b/keps/0002-kong-gateway-api.md
@@ -1,6 +1,6 @@
 ---
 title: Kong Gateway API
-status: milestone 1 implementable (see [graduation criteria](#graduation-criteria) for specifics)
+status: implementable
 ---
 
 # Kong Gateway API
@@ -24,169 +24,110 @@ status: milestone 1 implementable (see [graduation criteria](#graduation-criteri
 
 ## Summary
 
-[Gateway API][gateway] is the successor the the [Ingress][ingress] API upon which the [Kong Kubernetes Ingress Controller (KIC)][kic] was founded
-and includes a variety of improvements over its predecessor for feature richness, protocol support, lifecycle management, automation and more. We will
-implement Gateway APIs for the KIC in order to improve the operations, automation and integration characteristics of using the Kong Gateway on Kubernetes.
+[Gateway API][gateway] is the [successor][ingv2] the the [Ingress][ingress] API
+upon which the [Kong Kubernetes Ingress Controller (KIC)][kic] was founded and
+includes a variety of improvements over its predecessor for feature richness,
+protocol support, lifecycle management, automation and more. We will implement
+Gateway APIs for the KIC in order to improve the operations, automation and
+integration characteristics of using the Kong Gateway on Kubernetes.
 
 [gateway]:https://kubernetes-sigs.github.io/gateway-api
+[ingv2]:https://www.youtube.com/watch?v=Ne9UJL6irXY
+[ingress]:https://kubernetes.io/docs/concepts/services-networking/ingress/
 [kic]:https://github.com/kong/kubernetes-ingress-controller
 
 ## Motivation
 
-- enable multi-gateway single KIC deployments
-- enable lifecycle management of Kong Gateways on Kubernetes
 - adhere to upstream standards to create a low barrier to entry for end-users
 
 ### Goals
 
-- integrate our existing controller manager with `GatewayClass`
-- develop a `Gateway` controller which is responsible for multi-proxy deployments and Kong Gateway lifecycle management
-- expose as much Kong Gateway functionality as possible behind upstream standard APIs
+- support `GatewayClass` and `Gateway` APIs
+- support `HTTPRoute`, `TCPRoute`, `UDPRoute` and `TLSRoute` APIs
 
 ### Non-Goals
 
-- we wont retroactively support the `v0.1.x` Gateway API specification
+- we wont retroactively support the `v1alpha1` Gateway API specification
+- we wont support the full lifecycle of `Gateway` resources
 
 ## Proposal
 
-Similar to how the KIC has historically had support for the [Ingress][ingress] resource from `networking.k8s.io/v1` the intention is to start conforming to the new Gateway API resources including (but not limited to):
-
-- [Gateway][gateway] - the actual Gateway which routes traffic, in our case the [Kong Gateway][kong]
-- [GatewayClass][gateway-class] - the controller which is responsible for a `Gateway`
-- [HTTPRoute][httproute] - the quintessential HTTP traffic routing mechanism, with parallels to the `Ingress` API
+The KIC will include limited support for `Gateway` resources, and full
+"core" level support (as defined in upstream) for L7 and L4 routes.
 
-For the purposes of this KEP we will be focused on implementing the [v1alpha2][v1alpha2] specification of Gateway APIs as it is (at the time of writing) the latest release and current iteration.
+Defining "limited Gateway support": One notable connotation of `Gateway`
+resources is the idea that an end-user might create a `Gateway` and this
+results in an underlying `Deployment` and a gateway server (e.g. [Kong
+Gateway][kong]) being deployed and the lifecycle of that `Gateway` is managed
+by the controller. We'll call this "managed" mode and conversely when a gateway
+already exists on the cluster and the `Gateway` resource is more or less just
+metadata about that existing resource that will be referred to as "unmanaged"
+mode. We will only be supporting unmanaged mode in the KIC, see the
+alternatives section for more information about managed mode considerations.
 
-[ingress]:https://kubernetes.io/docs/concepts/services-networking/ingress/
-[gateway]:https://gateway-api.sigs.k8s.io/v1alpha2/api-types/gateway/
 [kong]:https://github.com/kong/kong
-[gateway-class]:https://gateway-api.sigs.k8s.io/v1alpha2/api-types/gatewayclass/
-[httproute]:https://gateway-api.sigs.k8s.io/v1alpha2/api-types/httproute/
 
 ### User Stories
 
 #### Story 1
 
-As a Kubernetes operator I want to use standard Kubernetes APIs to define ingress rules for communication with my services from outside the cluster.
+As a Kubernetes operator I want to use standard Kubernetes APIs to define
+ingress rules for communication with my services from outside the cluster.
 
 #### Story 2
 
-As a **developer** I want to use **standard Kubernetes APIs** so that my manifests and deployments don't require (at least minimize) domain specific comprehension of the underlying Gateway implementations I use for ingress traffic to my services.
-
-#### Story 3
-
-As **devops** providing **infrastructure** for other teams I want the ability to **spin up and tear down multiple Kong Gateways dynamically for separate teams** and projects within my organization, in a **Kubernetes native way**.
-
-#### Story 4
-
-As an **operator** of a Kubernetes cluster I want the **lifecycle management of Kong Gateways to be automated and managed for me**, and **not manually via Helm**.
+As a **developer** I want to use **standard Kubernetes APIs** so that my
+manifests and deployments don't require (at least minimize) domain specific
+APIs.
 
 ## Design Details
 
-Similar to all other APIs we've implemented previously (such as `Ingress`, `TCPRoute`, `UDPRoute`, e.t.c.) we will need to create controllers
-for the new resources:
-
-- `internal/controllers/gateway/gatewayclass_controller.go`
-- `internal/controllers/gateway/gateway_controller.go`
-- `internal/controllers/gateway/httproute_controller.go`
-
-These controllers will be responsible for their respective `GatewayClass`, `Gateway` and `HTTPRoute` types from `gateway.networking.k8s.io/v1alpha2`.
+The implementation of `Gateway` support in KIC will not require any new CRDs
+and will only require controllers which will configure routing APIs like
+`HTTPRoute` in the data-plane.
 
-Each of these types will need handlers in the backend `Proxy` implementation so that Kong `Services`, `Routes`, e.t.c. will be generated for them
-and posted to the Kong Admin API's `/config` endpoint, as is true of all other types currently.
-
-### Controller Implementations
-
-At the core we will need to support the following APIs:
+At the core we will support the following APIs:
 
 - `GatewayClass`
 - `Gateway`
 - `HTTPRoute`
+- `TCPRoute`
+- `UDPRoute`
+- `TLSRoute`
 
-These will give us a meaningful implementation, though we will need to add support for other types in time.
+We will add support for these resources and controllers to provision them.
 
-#### GatewayClass Controller
+### Validating Webhook
 
-The `GatewayClass` API is a reference to the controller that is managing Gateways of this class. Our controller
-will provide a tag (similar to what we currently call `ingress-class`) to indicate whether the controller is
-responsible for a `GatewayClass`:
+For the first iteration of our Gateway API support we will have some limits on
+functionality that will be codified in validation:
 
-```yaml
-kind: GatewayClass
-apiVersion: gateway.networking.k8s.io/v1alpha2
-metadata:
-  name: acme-lb
-spec:
-  controllerName: konghq.com/gateway-controller
-```
-
-This will be instrumented by the controller manager as a flag, though the above will be the default case when
-the flag isn't set:
+- `Gateway` limitations (e.g. disallowing managed mode gateways)
+- `HTTPRoute` limitations (e.g. query params matching)
 
-```shell
-manager --gateway-class konghq.com/gateway-controller
-```
+Otherwise the basic validation for these API types is to be provided by the
+[upstream validating webhook][gwhook].
 
-##### Additional Considerations
+[gwhook]:https://github.com/kubernetes-sigs/gateway-api/tree/master/cmd/admission
 
-- It's up to the operator whether they want a single or multiple controllers responsible for their `GatewayClasses`, for some high end deployments an entirely separate manager can be spun up but will need to have a distinct `--gateway-class`
-- If someone mutates the specification for a `GatewayClass` such as to drop the `controllerName: <tag>` which enables our support of it, the controller will stop managing related resources and will clean out the Kong Gateway's relevant configurations
-- TODO: Note that there's [some discussion][gateway-823] we've started upstream for some of the nuances with multi-tenancy, as there's currently limited documentation upstream on the matter. Before we consider this KEP `implementable` we need to make sure we get resolution there.
-
-[gateway-823]:https://github.com/kubernetes-sigs/gateway-api/discussions/823
-
-#### Validating Webhook
-
-**NOTE**: required for milestone 1 in [graduation criteria](#graduation-criteria)
-
-For the first iteration of our Gateway API support we will have some limits on functionality that would best be codified. For all Gateway related APIs, but particularly the `Gateway` API itself a custom webhook will be added to validate resources. The result of which is that end-users will receive an upfront error when they post configurations with options that are not yet supported (see the sections below for components and features that are still TODO).
+### Controllers
 
 #### Gateway Controller
 
-Where the `GatewayClass` API maps to our controller manager, the `Gateway` API maps to the Kong Gateway (Proxy Server).
-
-For each `Gateway` resource that is provided and configured for the relevant `GatewayClass` a separate proxy server will be initialized:
+In our implementation the `Gateway` resource will be a reflection of the
+Kubernetes `Service` object for the Kong Gateway, historically defined with:
 
-```yaml
-kind: GatewayClass
-apiVersion: gateway.networking.k8s.io/v1alpha2
-metadata:
-  name: default-match-example
-spec:
-  controllerName: acme.io/gateway-controller
----
-kind: Gateway
-apiVersion: gateway.networking.k8s.io/v1alpha2
-metadata:
-  name: project-1-ingress
-spec:
-  gatewayClassName: default-match-example
-  listeners:
-  - name: http
-    protocol: HTTP
-    port: 80
----
-kind: Gateway
-apiVersion: gateway.networking.k8s.io/v1alpha2
-metadata:
-  name: project-2-ingress
-spec:
-  gatewayClassName: default-match-example
-  listeners:
-  - name: http
-    protocol: HTTP
-    port: 80
+```console
+$ manager --publish-service namespace/name
 ```
 
-There will be two operational modes for this controller which indicate whether a `Gateway` object is to be provisioned and have its lifecycle managed (we will call this "managed" mode) or an existing gateway (we will call this "unmanaged" mode).
-
-##### Operational Mode 1: Unmanaged Gateways
+Rather than the end-user directly defining the `Addresses` and `Listeners` of
+the `Gateway` resource, they will be derived from the publish service and any
+updates to the `Service` will cause reconcilation to update the `Gateway`
+according to the `Service` spec and status.
 
-**NOTE**: required for milestone 1 in [graduation criteria](#graduation-criteria)
-
-Historically the KIC has relied on an existing Kong Gateway to already be deployed (commonly managed as a `Deployment` via the [Helm Chart][chart]) which the controller integrates with via the [Kong Admin API][kong-admin-api], and the connection and authorization information for that API was passed to the controller manager via command line flags. This operational mode follows the historical legacy of the KIC by allowing an existing Kong Gateway on the cluster to be used as the backend for a `Gateway` object in Gateway APIs parlance.
-
-We will support an "unmanaged" gateway mode, which will be defined via an annotation:
+This operational mode is called "unmanaged" mode and needs to be configured on
+`Gateway` resources with an annotation:
 
 ```yaml
 kind: Gateway
@@ -203,11 +144,6 @@ spec:
     port: 80
 ```
 
-In this mode the `Gateway` resource is simply a metadata reference to the
-Kubernetes `Service` which is used for the Kong Gateway traffic, as defined
-by the KIC command line flag `--publish-service` (and that flag is required
-for unmanaged Gateway mode to be enabled).
-
 The KIC Gateway controller will be responsible for watching the Kubernetes
 `Service` belonging to the Kong Gateway `Deployment` and derive the `Gateway`
 listeners, ports, and protocols (which routes like `HTTPRoute` need to attach
@@ -225,184 +161,108 @@ the `Service` object.
 [chart]:https://github.com/kong/charts
 [kong-admin-api]:https://docs.konghq.com/gateway-oss/latest/admin-api/
 
-##### Operational Mode 2: Managed Gateways
-
-**NOTE**: required for milestone 3 in [graduation criteria](#graduation-criteria)
-
-TODO: work on this operational mode has not been started yet. At the time of writing our [operator][kong-operator] was still unready to take on this functionality, and maintainers were not comfortable with adding this operator-style functionality to the KIC.
-
-[kong-operator]:https://github.com/kong/kong-operator
-
-###### Metrics
-
-**NOTE**: required for milestone 3 in [graduation criteria](#graduation-criteria)
-
-TODO
-
-###### Automatic Upgrades, HealthChecking and Rollbacks
-
-**NOTE**: required for milestone 3 in [graduation criteria](#graduation-criteria)
-
-TODO
-
-##### Additional Considerations
-
-- https://github.com/Kong/kubernetes-ingress-controller/issues/702 is related to our single controller multi-proxy lifecycle management concerns
-
-#### HTTPRoute Controller
-
-**NOTE**: required for milestone 1 in [graduation criteria](#graduation-criteria)
-
-The HTTPRoute controller is fairly straightforward, which backend proxy is responsible is based on which Gateway its attached to in the `parentRefs`, but then the resource otherwise gets parsed (by `parser.Build()`), converted into Kong types, and posted to Kong like any other API resource that currently exists, using the `KongState`, proxy and `sendconfig` abstractions as they are used today.
-
-#### TCPRoute Controller
-
-**NOTE**: required for milestone 2 in [graduation criteria](#graduation-criteria)
-
-TODO
+#### Routing Controller
 
-#### UDPRoute Controller
-
-**NOTE**: required for milestone 2 in [graduation criteria](#graduation-criteria)
-
-TODO
-
-#### TLSRoute Controller
-
-**NOTE**: required for milestone 2 in [graduation criteria](#graduation-criteria)
-
-TODO
-
-### Proxy Cache Implementation
-
-While the controllers will need to handle `GatewayClass` and `Gateway` to determine which `HTTPRoutes` we need to support, once we need to support them
-the backend caching, parsing, and Kong API updating logic will only need to be aware of `Gateway` and `HTTPRoute`.
-
-Updates between `Gateway` objects and the `HTTPRoutes` which are attached to them will be synchronized and are tightly coupled in terms of the backend
-Kong configurations they will produce as `Gateway` is responsible for the TLS configurations for listeners separately from the `HTTPRoute`, which with the
-historical `Ingress` API this was all managed within that single resource.
-
-We'll need to update `internal/store/store.go` to cache the objects that are provided from the aforementioned controllers via `proxy.UpdateObject(obj)`:
-
-```go
-type Storer interface {
-    // ... existing methods
-    ListGateways() ([]*gatewayv1alpha2.Gateway, error)
-    ListHTTPRoutes() ([]*gatewayv1alpha2.HTTPRoute, error)
-}
-
-type CacheStores struct {
-    // ... existing stores
-    Gateway      cache.Store
-    HTTPRoute    cache.Store
-}
-```
-
-We will need to ensure all the relevant plumbing to cache the Gateway API objects therein is in place so that they can be fed to `internal/parser/`:
-
-```go
-func parseAll(log logrus.FieldLogger, s store.Storer) ingressRules {
-    // ... existing parsing logic
-    gateways, err := s.ListGateways()
-    parsedGateways := fromGatewayAPIsV1alpha2Gateway(log, gateways)
-    httproutes, err := s.ListHTTPRoutes()
-    parsedHTTPRoutes := fromGatewayAPIsV1alpha2HTTPRoute(log, httproutes)
-
-    return mergeIngressRules(otherTypes..., parsedGateways, parsedHTTPRoutes)
-```
-
-The parsing logic above (e.g. `fromGatewayAPIsV1alpha2HTTPRoute()`) is the ultimate low-level logic we will need to compile `Gateways` and `HTTPRoutes`
-into `kong.Services` and `kong.Routes`. Practically speaking almost all the prior art needed to implement this is covered by the API types we already
-support, so the work should be predominantly integration work and little to no exploratory work needed.
+For the `HTTPRoute`, `TCPRoute`, `UDPRoute` and `TLSRoute` APIs the controller
+implementation will be very similar to the parallel `Ingress`, `TCPIngress` and
+`UDPIngress` which already exist and will simply be a matter of translating
+routing rules into Kong `Routes`, `Services` and `Upstreams`.
 
 ### Test Plan
 
-In order to consider this KEP `implemented` we must have the following present:
+Automated testing will be provided for the `main` branch and all PRs:
 
-- `examples/` includes manifests for (at least) a working HTTP ingress with `GatewayClass`, `Gateway`, and `HTTPRoute` using Kong
-- KIC [docs.konghq.com][docs] must include a `guide/` for Gateway APIs (flagged **experimental** until Gateway APIs are GA)
-- `test/integration/` includes integration tests which cover deployment and configuration options of `HTTPRoute`, including TLS configurations
-- our `.github/workflows/release.yaml` release CI must test our `HTTPRoute` implementation against a historical list of the Kubernetes versions we support
+- unit tests for all Go packages using [go tests][gotest]
+- integration tests using the [Kong Kubernetes Testing Framework (KTF)][ktf]
+- e2e tests using [KTF][ktf]
 
-[docs]:https://docs.konghq.com/kubernetes-ingress-controller/
+All tests should be able to run locally using `go test` and integration and e2e
+tests using a local system Kubernetes deployment like [Kubernetes in Docker
+(KIND)][kind].
+
+[gotest]:https://pkg.go.dev/testing
+[ktf]:https://github.com/kong/kubernetes-testing-framework
+[kind]:https://github.com/kubernetes-sigs/kind
 
 ### Graduation Criteria
 
 The following highlights milestones along the path of Gateway support maturity.
 
-Individual milestones will be marked `provisional` or `implementable` independently, in accordance with whether the design details have enough planning and specification available yet to support them, and complete milestones will be marked as `implemented`:
-
-- `provisional` - don't start work until the previous milestones have been completed **and** the [design details](#design-details) for related components and features have been completed.
-- `implementable` - this is supported by the [design details](#design-details) and is ready for work to start
-- `implemented` - the related components and functionality are already available now at the designated quality level
-
-The milestones may correlate directly with [Github Milestones][github-milestones] in the same repository.
+The milestones correlate directly with [Github Milestones][ms] in the same
+repository.
 
-[github-milestones]:https://github.com/Kong/kubernetes-ingress-controller/milestones
+[ms]:https://github.com/Kong/kubernetes-ingress-controller/milestones
 
-#### Milestone 1 - Alpha Quality - Initial HTTP Support (implementable)
+#### Milestone 1 - Initial L7 Support
 
-- [ ] our validating webhook for Gateway resources has been added and provides errors for unimplemented features
-- [ ] a `Gateway` controller implementation with basic support for "unmanaged" operational mode is introduced
-- [ ] an initial implementation of `HTTPRoute` is added which includes support for the majority of options
-- [ ] integration tests added which cover all the supported features of `HTTPRoute`
+- [x] our validating webhook for Gateway resources has been added and provides
+      errors for unimplemented features
+- [x] a `Gateway` controller implementation with basic support for "unmanaged"
+      operational mode is introduced
+- [x] an initial implementation of `HTTPRoute` is added which includes support
+      for the most important options for basic usage
 
-#### Milestone 2 - Alpha Quality - Extended API Support (provisional)
+#### Milestone 2 - Core L7 Support
 
-- [ ] an initial implementation of `TCPRoute` is added which includes support for the majority of features
-- [ ] integration tests added which cover all the features of `TCPRoute`
-- [ ] an initial implementation of `UDPRoute` is added which includes support for the majority of features
-- [ ] integration tests added which cover all the features of `UDPRoute`
-- [ ] an initial implementation of `TLSRoute` is added which includes support for the majority of features
-- [ ] integration tests added which cover all the features of `TLSRoute`
+- [ ] all `HTTPRoute` features marked as "core" support have been added
+- [ ] upstream [conformance tests][cft] have been added to our CI and pass
+- [ ] optional: add as many "extended" and "custom" features as can already be
+      supported by the [Kong Gateway][kong].
 
-#### Milestone 3 - Alpha Quality - Operator Support (provisional)
-
-- [ ] operator support for provisioning and managing the lifecycle of `Gateway` resources is added
-- [ ] operator has support for automatic upgrades of provisioned `Gateways`
-- [ ] operator has support for health checking and rollback mechanisms for provisioned `Gateways`
-- [ ] operator has prometheus metrics which capture information about `Gateway` operations, including error alerts for failures e.t.c.
-- [ ] integration tests added which cover all features of `Gateway`
+[cft]:https://github.com/kubernetes-sigs/gateway-api/tree/master/conformance
+[kong]:https://github.com/kong/kong
 
-#### Milestone 4 - Beta Quality (provisional)
+#### Milestone 3 - Core L4 Support
 
-TODO: after we get some traction with alpha level milestones that work should start informing the beta stage and we can start filling this out.
+- [ ] `TCPRoute` support is added with all "core" features supported
+- [ ] `UDPRoute` support is added with all "core" features supported
+- [ ] `TLSRoute` support is added with all "core" features supported
+- [ ] upstream conformance tests are passing for all three APIs
+- [ ] optional: add as many "extended" and "custom" features as can already be
+      supported by the [Kong Gateway][kong].
 
 ## Production Readiness
 
 Production readiness of this feature is marked by the following requirements:
 
 - All milestones of the above `Graduation Criteria` have been completed
-- We have support for all of the [entire Gateway APIs spec][gateway-spec]
-- Our integration and E2E testing provides feature cover and strong regression protections
 - Gateway APIs themselves have reached a GA status in upstream Kubernetes
 - A version of Kubernetes which includes the Gateway APIs standard becomes GA
-- Gateway API documentation is added to [our documentation][kong-docs]
+- Gateway API documentation is added to [our documentation][kongdocs]
 
 [gateway-spec]:https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/
-[kong-docs]:https://docs.konghq.com
+[kongdocs]:https://docs.konghq.com
 
 ### Feature Enablement and Rollback
 
-The Gateway API support will be disabled by default prior to GA and enabled by using `--feature-gates=Gateway=true`.
+The Gateway API support will be disabled by default prior to GA and enabled by
+using `--feature-gates=Gateway=true`.
 
 ## Drawbacks
 
-Given the direction of the upstream Kubernetes community which appears to be conforming around Gateway,
-the only drawback we've seen is the time cost we will need to pay in order to implement the API during
-a time when the API isn't GA. As such for the initial iteration we've decided to hold back on some of
-the provisioning and lifecycle management features inherent to the Gateway APIs project (e.g. provisioning
-`Gateway` resources by deploying and maintaining new proxy `Deployments` for them) in order to spread
-time costs out.
+Given the direction of the upstream Kubernetes community which appears to be
+conforming around Gateway, the only drawback we've seen is the time cost we
+will need to pay in order to implement the API during a time when the API isn't
+GA. As such for the initial iteration we've decided to hold back on some of the
+provisioning and lifecycle management features inherent to the Gateway APIs
+project (e.g. provisioning `Gateway` resources by deploying and maintaining new
+proxy `Deployments` for them) in order to spread time costs out.
 
 ## Alternatives
 
-The primary alternative we've considered is that we could continue to support the featuresets which Gateway APIs is bound for using our custom APIs,
-however this will make us an outlier and less attractive an option to operators as many competing implementations already have and are planning long-term support of Gateway APIs.
+### Not Supporting Gateway
 
-Separating the Gateway implementation for Kong into its own repository instead of adding it to the KIC was considered, but ultimately decided against. The main factors in this decision were to make it easy to integrate some existing types which Gateway APIs does not have an answer for (e.g. `KongPlugin`), and to re-use the existing backend libraries for updating the Kong Admin API without having to make them more portable or make significant changes in a time shortly after KIC 2.0 release wherein we had just finished several large maintenance investments.
+The main alternative we've considered is that we could continue to support
+the featuresets which Gateway APIs is bound for using our custom APIs (e.g.
+`TCPIngress`, `UDPIngress`, e.t.c.), however this will make us an outlier and
+less attractive an option to operators as many competing implementations
+already have and are planning long-term support of Gateway APIs.
 
-## Infrastructure Needed
+### Managed Gateways
 
-We can rely on the existing infrastructure available currently which tests `Ingress` and our CRD based APIs, no new infrastructure will be required.
+We considered supporting managed `Gateways` as a part of the KIC but this
+lends itself better to an operator which works at a higher level: for now
+we're going to assess managed gateway support separately possibly as part
+of our [operator][kongop] project instead.
 
+[kongop]:https://github.com/kong/kong-operator


Test patch:
diff --git a/.github/workflows/test.yaml b/.github/workflows/test.yaml
index 699e3a422..1e0c4177a 100644
--- a/.github/workflows/test.yaml
+++ b/.github/workflows/test.yaml
@@ -109,9 +109,21 @@ jobs:
         name: coverage.unit.out
         path: coverage.unit.out
 
+  runnable:
+    runs-on: ubuntu-latest
+    environment: "Configure ci"
+    outputs:
+      runnable: ${{ steps.check.outputs.result }}
+    steps:
+    - name: Check secret availability
+      id: check
+      run: echo ::set-output name=result::${{ secrets.KONG_LICENSE_DATA != ''}}
+
   integration-tests-enterprise-postgres:
     environment: "Configure ci"
     runs-on: ubuntu-latest
+    needs: runnable
+    if: "needs.runnable.outputs.runnable == 'true'"
     steps:
 
     - name: setup golang
diff --git a/internal/dataplane/parser/translate_httproute_test.go b/internal/dataplane/parser/translate_httproute_test.go
index 34d39a299..5405a56a5 100644
--- a/internal/dataplane/parser/translate_httproute_test.go
+++ b/internal/dataplane/parser/translate_httproute_test.go
@@ -18,6 +18,7 @@ func Test_ingressRulesFromHTTPRoutes(t *testing.T) {
 	httpPort := gatewayv1alpha2.PortNumber(80)
 	pathMatchPrefix := gatewayv1alpha2.PathMatchPathPrefix
 	pathMatchRegex := gatewayv1alpha2.PathMatchRegularExpression
+	pathMatchExact := gatewayv1alpha2.PathMatchExact
 	queryMatchExact := gatewayv1alpha2.QueryParamMatchExact
 
 	for _, tt := range []struct {
@@ -209,7 +210,6 @@ func Test_ingressRulesFromHTTPRoutes(t *testing.T) {
 									kong.String("http"),
 									kong.String("https"),
 								},
-								StripPath: kong.Bool(true),
 							},
 							Ingress: util.K8sObjectInfo{
 								Name:        "basic-httproute",
@@ -286,7 +286,7 @@ func Test_ingressRulesFromHTTPRoutes(t *testing.T) {
 			},
 		},
 		{
-			msg: "an HTTPRoute with regex path matches is not yet supported",
+			msg: "an HTTPRoute with regex path matches is supported",
 			routes: []*gatewayv1alpha2.HTTPRoute{{
 				ObjectMeta: metav1.ObjectMeta{
 					Name:      "basic-httproute",
@@ -302,7 +302,7 @@ func Test_ingressRulesFromHTTPRoutes(t *testing.T) {
 						Matches: []gatewayv1alpha2.HTTPRouteMatch{{
 							Path: &gatewayv1alpha2.HTTPPathMatch{
 								Type:  &pathMatchRegex,
-								Value: kong.String("httpbin$"),
+								Value: kong.String("/httpbin$"),
 							},
 						}},
 						BackendRefs: []gatewayv1alpha2.HTTPBackendRef{{
@@ -317,15 +317,53 @@ func Test_ingressRulesFromHTTPRoutes(t *testing.T) {
 				},
 			}},
 			expected: ingressRules{
-				SecretNameToSNIs:      SecretNameToSNIs{},
-				ServiceNameToServices: make(map[string]kongstate.Service),
-			},
-			errs: []error{
-				fmt.Errorf("HTTPRoute default/basic-httproute can't be routed: %w", fmt.Errorf("regular expression path matches are not yet supported")),
+				SecretNameToSNIs: SecretNameToSNIs{},
+				ServiceNameToServices: map[string]kongstate.Service{
+					"default.fake-service.80": {
+						Service: kong.Service{ // only 1 service should be created
+							ConnectTimeout: kong.Int(60000),
+							Host:           kong.String("fake-service.default.80.svc"),
+							Name:           kong.String("default.fake-service.80"),
+							Path:           kong.String("/"),
+							Port:           kong.Int(80),
+							Protocol:       kong.String("http"),
+							ReadTimeout:    kong.Int(60000),
+							Retries:        kong.Int(5),
+							WriteTimeout:   kong.Int(60000),
+						},
+						Backend: kongstate.ServiceBackend{
+							Name: "fake-service",
+							Port: kongstate.PortDef{
+								Mode:   kongstate.PortMode(1),
+								Number: 80,
+							},
+						},
+						Namespace: "default",
+						Routes: []kongstate.Route{{ // only 1 route should be created
+							Route: kong.Route{
+								Name: kong.String("httproute.default.basic-httproute.0"),
+								Paths: []*string{
+									kong.String("/httpbin$"),
+								},
+								PreserveHost: kong.Bool(true),
+								Protocols: []*string{
+									kong.String("http"),
+									kong.String("https"),
+								},
+							},
+							Ingress: util.K8sObjectInfo{
+								Name:        "basic-httproute",
+								Namespace:   corev1.NamespaceDefault,
+								Annotations: make(map[string]string),
+							},
+						}},
+						K8sService: corev1.Service{},
+					},
+				},
 			},
 		},
 		{
-			msg: "an HTTPRoute with a mixture of unsupported and supported match options can't be routed",
+			msg: "an HTTPRoute with exact path matches translates to a terminated Kong regex route",
 			routes: []*gatewayv1alpha2.HTTPRoute{{
 				ObjectMeta: metav1.ObjectMeta{
 					Name:      "basic-httproute",
@@ -338,20 +376,12 @@ func Test_ingressRulesFromHTTPRoutes(t *testing.T) {
 						}},
 					},
 					Rules: []gatewayv1alpha2.HTTPRouteRule{{
-						Matches: []gatewayv1alpha2.HTTPRouteMatch{
-							{
-								Path: &gatewayv1alpha2.HTTPPathMatch{
-									Type:  &pathMatchRegex,
-									Value: kong.String("httpbin$"),
-								},
-							},
-							{
-								Path: &gatewayv1alpha2.HTTPPathMatch{
-									Type:  &pathMatchPrefix,
-									Value: kong.String("/httpbin"),
-								},
+						Matches: []gatewayv1alpha2.HTTPRouteMatch{{
+							Path: &gatewayv1alpha2.HTTPPathMatch{
+								Type:  &pathMatchExact,
+								Value: kong.String("/httpbin"),
 							},
-						},
+						}},
 						BackendRefs: []gatewayv1alpha2.HTTPBackendRef{{
 							BackendRef: gatewayv1alpha2.BackendRef{
 								BackendObjectReference: gatewayv1alpha2.BackendObjectReference{
@@ -364,11 +394,49 @@ func Test_ingressRulesFromHTTPRoutes(t *testing.T) {
 				},
 			}},
 			expected: ingressRules{
-				SecretNameToSNIs:      SecretNameToSNIs{},
-				ServiceNameToServices: make(map[string]kongstate.Service),
-			},
-			errs: []error{
-				fmt.Errorf("HTTPRoute default/basic-httproute can't be routed: %w", fmt.Errorf("regular expression path matches are not yet supported")),
+				SecretNameToSNIs: SecretNameToSNIs{},
+				ServiceNameToServices: map[string]kongstate.Service{
+					"default.fake-service.80": {
+						Service: kong.Service{ // only 1 service should be created
+							ConnectTimeout: kong.Int(60000),
+							Host:           kong.String("fake-service.default.80.svc"),
+							Name:           kong.String("default.fake-service.80"),
+							Path:           kong.String("/"),
+							Port:           kong.Int(80),
+							Protocol:       kong.String("http"),
+							ReadTimeout:    kong.Int(60000),
+							Retries:        kong.Int(5),
+							WriteTimeout:   kong.Int(60000),
+						},
+						Backend: kongstate.ServiceBackend{
+							Name: "fake-service",
+							Port: kongstate.PortDef{
+								Mode:   kongstate.PortMode(1),
+								Number: 80,
+							},
+						},
+						Namespace: "default",
+						Routes: []kongstate.Route{{ // only 1 route should be created
+							Route: kong.Route{
+								Name: kong.String("httproute.default.basic-httproute.0"),
+								Paths: []*string{
+									kong.String("/httpbin$"),
+								},
+								PreserveHost: kong.Bool(true),
+								Protocols: []*string{
+									kong.String("http"),
+									kong.String("https"),
+								},
+							},
+							Ingress: util.K8sObjectInfo{
+								Name:        "basic-httproute",
+								Namespace:   corev1.NamespaceDefault,
+								Annotations: make(map[string]string),
+							},
+						}},
+						K8sService: corev1.Service{},
+					},
+				},
 			},
 		},
 	} {
diff --git a/keps/0004-kong-kubernetes-testing.md b/keps/0004-kong-kubernetes-testing.md
index dfbc644e7..09bf2dcfe 100644
--- a/keps/0004-kong-kubernetes-testing.md
+++ b/keps/0004-kong-kubernetes-testing.md
@@ -1,11 +1,8 @@
 ---
+title: Kong Kubernetes Testing Framework (KTF)
 status: implemented
 ---
 
-**NOTE**: this will be considered `implemented` once [Milestone 1][m1] is completed.
-
-[m1]:https://github.com/Kong/kubernetes-testing-framework/milestone/1
-
 # Kong Kubernetes Testing Framework (KTF)
 
 <!-- toc -->
@@ -27,15 +24,13 @@ status: implemented
 - [Alternatives](#alternatives)
 <!-- /toc -->
 
-## Release Signoff Checklist
-
-- [x] [v0.1.0 Milestone][ms1]
-
-[ms1]:https://github.com/Kong/kubernetes-testing-framework/milestone/1
-
 ## Summary
 
-Historically the [Kong Kubernetes Ingress Controller (KIC)][kic] used bash scripts and `curl` to perform integration tests. This KEP aims to provide a standard [Golang][go] testing framework for Kong Kubernetes integrations to make testing Kong [Kubernetes][k8s] controllers straightforward and prescriptive.
+Historically the [Kong Kubernetes Ingress Controller (KIC)][kic] used bash
+scripts and `curl` to perform integration tests. This KEP aims to provide a
+standard [Golang][go] testing framework for Kong Kubernetes integrations to
+make testing Kong [Kubernetes][k8s] controllers straightforward and
+prescriptive.
 
 [kic]:https://github.com/kong/kubernetes-ingress-controller
 [go]:https://golang.org
@@ -44,32 +39,39 @@ Historically the [Kong Kubernetes Ingress Controller (KIC)][kic] used bash scrip
 ## Motivation
 
 - we want to have strong documentation of our _testing process_
-- we want our integration tests to be in [Golang][go] to match our primary development language and provide high levels of expressibility for tests
-- we want to be prescriptive how to test Kong Kubernetes components across all [@kong/team-k8s repos][team-repos] to limit to promote code re-use and limit test maintenance
-- we want contributions of integration tests for Kong Kubernetes components to be a friendly experience
+- we want our integration tests to be in [Golang][go] to match our primary
+  development language and provide high levels of expressibility for tests
+- we want to be prescriptive how to test Kong Kubernetes components across
+  all [@kong/team-k8s repos][team-repos] to limit to promote code re-use
+  and limit test maintenance
+- we want contributions of integration tests for Kong Kubernetes components to
+  be a friendly experience
 
 [go]:https://golang.org
 [team-repos]:https://github.com/orgs/Kong/teams/team-k8s/repositories
 
 ### Goals
 
-- provide _provisioning functionality_ for testing clusters (e.g. `kind`, `minikube`, `GKE`, e.t.c.)
-- provide _deployment functionality_ for Kubernetes components to create complete testing environments (e.g. `helm`, `metallb`, e.t.c.)
-- provide _deployment functionality_ for Kong components (e.g. deploying Proxy only, deploying Proxy with KIC, version matrix, e.t.c.)
-- provide _generators_ to quickly generate default objects commonly used in testing (e.g. `Service`, `Deployment`, e.t.c.)
-- provide _mocking functionality_ for the Kong Admin API
+- provide _provisioning functionality_ for testing clusters (e.g. `kind`,
+  `minikube`, `GKE`, e.t.c.)
+- provide _deployment functionality_ for Kubernetes components (e.g. `helm`,
+  `metallb`, e.t.c.)
+- provide _deployment functionality_ for Kong components (e.g. deploying Proxy
+  only, deploying Proxy with KIC, version matrix, e.t.c.)
+- provide _generators_ to quickly generate default objects commonly used in
+  testing (e.g. `Service`, `Deployment`, e.t.c.)
 
 ### Non-Goals
 
-Due to incongruencies with one of our most prominent upstream tools ([Kind][kind]) we're going to need to skip on creating complete container images for testing environments in favor of writing setup logic aftermarket for existing default images. While being able to move runtime problems to build time would be helpful, we'll potentially need to look at migrating to new tools in some future iteration to follow up.
-
-For this iteration we're _not trying to solve the problem of automated cleanup of testing environments_, as this is expected to greatly increase scope. Instead tests are expected to use separate namespaces and cleanup after themselves for this iteration. There is a follow up item to take care of cleanup as a separate scope: https://github.com/Kong/kubernetes-testing-framework/issues/4.
+- provide _mocking functionality_ for the Kong Admin API
 
 ## Proposal
 
-The overall purpose of the [Kong Kubernetes Testing Framework (KTF)][ktf] is to provide environment provisioners for Kubernetes integration tests specific to Kong components with a minimal user interface.
-
-Contributors to tests should be able expect an existing Kubernetes cluster, and that they will have access to a functional Kubernetes client object to start using in their tests.
+The main purpose of the [Kong Kubernetes Testing Framework (KTF)][ktf] is to
+provision Kubernetes testing environments on a local system for `go test` to
+run integration/e2e tests against. Secondarily the testing framework will
+provide an assortment of helper functions for common functionality (e.g.
+deploying addons like Kong).
 
 [ktf]:https://github.com/kong/kubernetes-testing-framework
 
@@ -77,29 +79,24 @@ Contributors to tests should be able expect an existing Kubernetes cluster, and
 
 #### Story 1
 
-As a developer and contributor to any Kubernetes controller, I want my tests to require _no function calls for test environment setup_ so that I can effectively start writing my tests right away and consider the testing environment _somewhat opaque_.
-
-#### Story 2
-
-As a developer and contributor to any Kubernetes controller, when feasible I want the way I write tests for any single controller to be the same way I would write unit tests - by testing the controller on its Kubernetes API interface.
+As a developer I want the testing environment to already pre-populate a
+Kubernetes cluster and provide me the client object to use the cluster
+for my tests.
 
 ### Risks and Mitigations
 
-One of the main risks of this proposal is the increase in CI costs for the team. The main way in which we mitigate this is making sure our CI workflow scope is limited to the minimum necessary and keep our build triggers clean.
+One of the main risks of this proposal is the increase in CI costs for the
+team. The main way in which we mitigate this is making sure our CI workflow
+scope is limited to the minimum necessary and keep our build triggers clean.
 
 ## Design Details
 
 ### Test Plan
 
-All code which can feasibly be unit tested will be, the only code we expect will not be feasible to unit test will be code that makes shell calls to other programs.
-
-Higher level integration tests will exist to cover:
-
-- setup of a Kind Kubernetes cluster
-- basic usage of a Kind Kubernetes cluster's client-go client
-- teardown of a Kind Kubernetes cluster
-
-Integration tests written in the testing framework will also serve the purpose of being examples for callers using the library to write tests, as such `go doc` documentation and heavily commented tests is a must.
+The testing framework itself needs to be tested: all code which can feasibly
+be unit tested will be, and cluster and addon provisioning will have
+integration and e2e tests. These tests will also help to serve as examples for
+end-users of the testing framework.
 
 ### Graduation Criteria
 
@@ -109,12 +106,17 @@ Integration tests written in the testing framework will also serve the purpose o
 
 ## Implementation History
 
-- As part of [KEP 1][kep1] we created the [Kubernetes Testing Framework (KTF) Prototype][ktf]
-- In service of the [KTF][ktf] we added a prototype [Kind Image Builder][kind-images] which creates container images used by KTF to bootstrap test clusters.
-- The KTF was [updated to include Kubernetes API Object generators and cluster runbooks][ktf-pr3].
-- A minimum test [was added to KIC][kic-pr1102] using the new KTF functionality, `v0.0.1` tagged.
+- As part of [KEP 1][kep1] we created the [Kubernetes Testing Framework (KTF)
+  Prototype][ktf]
+- In service of the [KTF][ktf] we added a prototype [Kind Image
+  Builder][kind-images] which creates container images used by KTF to
+  bootstrap test clusters.
+- The KTF was [updated to include Kubernetes API Object generators and cluster
+  runbooks][ktf-pr3].
+- A minimum test [was added to KIC][kic-pr1102] using the new KTF functionality
 - The runbook concept was removed in favor of factory-style cluster provisioning
-- We remove the experimental image builder in favor of adding deployment tooling to the test framework, `v0.0.2` tagged.
+- We remove the experimental image builder in favor of adding deployment tooling
+  to the test framework.
 - Admin API mocking was added in `pkg/kong/fake_admin_api.go` and is now in use by KIC integration tests
 
 [kep1]:/keps/0001-single-kic-multi-gateway.md
@@ -125,6 +127,8 @@ Integration tests written in the testing framework will also serve the purpose o
 
 ## Alternatives
 
-Using the existing open source [Kuttl][kuttl] testing tool was considered, but it is very limited in expressivity and the project is not well aligned to wanting to express tests in Go at the time of writing.
+Using the existing open source [Kuttl][kuttl] testing tool was considered, but
+it is very limited in expressivity and the project is not well aligned to
+wanting to express tests in Go at the time of writing.
 
 [kuttl]:https://github.com/kudobuilder/kuttl
diff --git a/keps/0007-kic-performance-test.md b/keps/0007-kic-performance-test.md
index 1e6fb5e93..6bbde9638 100644
--- a/keps/0007-kic-performance-test.md
+++ b/keps/0007-kic-performance-test.md
@@ -1,566 +1,27 @@
 ---
-title: KIC Performance Test Solution
+title: Performance Testing
 status: provisional
 ---
 
-# Notes
-
-For references see the dependencies related to this proprosal to check the progress of related efforts:
-
-- solution
-- deployment and configuration
-- code/repo
-- configuration and execution
-- profiling (code profiler)
-- histogram execution time and calculates percentiles
-
-
 ## Summary
 
-We want a performance test solution that can be executed collecting metrics (cpu, memory, workqueue, business logic etc) per release, which also provides controller profiling helping evaluating bottleneck and scalabilities. The execution could be based on configuration, or code change trigger.
-Performance tests should be able to integrate with different kubernetes cluster and cloud provider, and scale according to controller scalability.
+We want a performance testing solution for the [Kong Kubernetes Ingress
+Controller (KIC)][kic] to collect CPU, Memory and I/O performance metrics from a
+running KIC deployment under a variety of scenarios. This testing framework will
+be used to evaluate the performance characteristics of KIC in specific
+environments and will help us identify bottlenecks.
 
 [kic]:https://github.com/kong/kubernetes-ingress-controller
-[ktf]:https://github.com/Kong/kubernetes-testing-framework
-[jenkins]: https://www.jenkins.io/
-[aws]: https://aws.amazon.com/
-[kind]: https://kind.sigs.k8s.io/
-[docker]: https://www.docker.com/ 
 
 ## Motivation
 
- - we currently have no data, documentation, or determined performance characteristics for the KIC in any Kubernetes or infrastructure environment
- - we want libraries and tooling that can be run against a Kubernetes cluster and its underlying infrastructure to analyze the performance characteristics of the KIC in that environment
- - we want our tooling to be open source so end-users can run a performance analysis themselves in their environment
+- we currently have no data, documentation, or determined performance
+  characteristics for the KIC in any environment
+- we want end-users and customers to be able to run a portable copy of our
+  performance tests in their own environments
 
 ### Goals
 
- - provide an isolated and reproducible environment for performance testing
- - continue integration and continue test
- - Visualize testing configuration and results.
- - System distribution
- - Able to run performance pipeline repeatedly in each release cycle
- - Able to collect following performance metrics
-    - controller profiling
-    - controller memory/cpu consumption
-    - ingress config, deck sync, parser cost
- - Provide helm charts [Helm Chart](https://helm.sh) for performance container image to easily deploy it to Kubernetes clusters (enhancement)
-
-### Non-Goals
-
-<!--
-What is out of scope for this KEP? Listing non-goals helps to focus discussion
-and make progress.
--->
-
-## Proposal
-
-<!--
-This is where we get down to the specifics of what the proposal actually is.
-This should have enough detail that reviewers can understand exactly what
-you're proposing, but should not include things like API designs or
-implementation. What is the desired outcome and how do we measure success?.
-The "Design Details" section below is for the real
-nitty-gritty.
--->
-
-### User Stories (Optional)
-
-<!--
-Detail the things that people will be able to do if this KEP is implemented.
-Include as much detail as possible so that people can understand the "how" of
-the system. The goal here is to make this feel real for users without getting
-bogged down.
--->
-
-#### Story 1
-
-#### Story 2
-
-### Notes/Constraints/Caveats (Optional)
-
-<!--
-What are the caveats to the proposal?
-What are some important details that didn't come across above?
-Go in to as much detail as necessary here.
-This might be a good place to talk about core concepts and how they relate.
--->
-
-### Risks and Mitigations
-
-<!--
-What are the risks of this proposal, and how do we mitigate? Think broadly.
-For example, consider both security and how this will impact the larger
-Kubernetes ecosystem.
-
-How will security be reviewed, and by whom?
-
-How will UX be reviewed, and by whom?
-
-Consider including folks who also work outside the SIG or subproject.
--->
-
-## Design Details
-
-<!--
-This section should contain enough information that the specifics of your
-change are understandable. This may include API specs (though not always
-required) or even code snippets. If there's any ambiguity about HOW your
-proposal will be implemented, this is the place to discuss them.
--->
-
-### Test Plan
-
-<!--
-**Note:** *Not required until targeted at a release.*
-
-Consider the following in developing a test plan for this enhancement:
-- Will there be e2e and integration tests, in addition to unit tests?
-- How will it be tested in isolation vs with other components?
-
-No need to outline all of the test cases, just the general strategy. Anything
-that would count as tricky in the implementation, and anything particularly
-challenging to test, should be called out.
-
-All code is expected to have adequate tests (eventually with coverage
-expectations). Please adhere to the [Kubernetes testing guidelines][testing-guidelines]
-when drafting this test plan.
-
-[testing-guidelines]: https://git.k8s.io/community/contributors/devel/sig-testing/testing.md
--->
-
-### Graduation Criteria
-
-<!--
-**Note:** *Not required until targeted at a release.*
-
-Define graduation milestones.
-
-These may be defined in terms of API maturity, or as something else. The KEP
-should keep this high-level with a focus on what signals will be looked at to
-determine graduation.
-
-Consider the following in developing the graduation criteria for this enhancement:
-- [Maturity levels (`alpha`, `beta`, `stable`)][maturity-levels]
-- [Deprecation policy][deprecation-policy]
-
-Clearly define what graduation means by either linking to the [API doc
-definition](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-versioning)
-or by redefining what graduation means.
-
-In general we try to use the same stages (alpha, beta, GA), regardless of how the
-functionality is accessed.
-
-[maturity-levels]: https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions
-[deprecation-policy]: https://kubernetes.io/docs/reference/using-api/deprecation-policy/
-
-Below are some examples to consider, in addition to the aforementioned [maturity levels][maturity-levels].
-
-#### Alpha
-
-- Feature implemented behind a feature flag
-- Initial e2e tests completed and enabled
-
-#### Beta
-
-- Gather feedback from developers and surveys
-- Complete features A, B, C
-- Additional tests are in Testgrid and linked in KEP
-
-#### GA
-
-- N examples of real-world usage
-- N installs
-- More rigorous forms of testing—e.g., downgrade tests and scalability tests
-- Allowing time for feedback
-
-**Note:** Generally we also wait at least two releases between beta and
-GA/stable, because there's no opportunity for user feedback, or even bug reports,
-in back-to-back releases.
-
-**For non-optional features moving to GA, the graduation criteria must include
-[conformance tests].**
-
-[conformance tests]: https://git.k8s.io/community/contributors/devel/sig-architecture/conformance-tests.md
-
-#### Deprecation
-
-- Announce deprecation and support policy of the existing flag
-- Two versions passed since introducing the functionality that deprecates the flag (to address version skew)
-- Address feedback on usage/changed behavior, provided on GitHub issues
-- Deprecate the flag
--->
-
-### Upgrade / Downgrade Strategy
-
-<!--
-If applicable, how will the component be upgraded and downgraded? Make sure
-this is in the test plan.
-
-Consider the following in developing an upgrade/downgrade strategy for this
-enhancement:
-- What changes (in invocations, configurations, API use, etc.) is an existing
-  cluster required to make on upgrade, in order to maintain previous behavior?
-- What changes (in invocations, configurations, API use, etc.) is an existing
-  cluster required to make on upgrade, in order to make use of the enhancement?
--->
-
-### Version Skew Strategy
-
-<!--
-If applicable, how will the component handle version skew with other
-components? What are the guarantees? Make sure this is in the test plan.
-
-Consider the following in developing a version skew strategy for this
-enhancement:
-- Does this enhancement involve coordinating behavior in the control plane and
-  in the kubelet? How does an n-2 kubelet without this feature available behave
-  when this feature is used?
-- Will any other components on the node change? For example, changes to CSI,
-  CRI or CNI may require updating that component before the kubelet.
--->
-
-## Production Readiness Review Questionnaire
-
-<!--
-
-Production readiness reviews are intended to ensure that features merging into
-Kubernetes are observable, scalable and supportable; can be safely operated in
-production environments, and can be disabled or rolled back in the event they
-cause increased failures in production. See more in the PRR KEP at
-https://git.k8s.io/enhancements/keps/sig-architecture/1194-prod-readiness.
-
-The production readiness review questionnaire must be completed and approved
-for the KEP to move to `implementable` status and be included in the release.
-
-In some cases, the questions below should also have answers in `kep.yaml`. This
-is to enable automation to verify the presence of the review, and to reduce review
-burden and latency.
-
-The KEP must have a approver from the
-[`prod-readiness-approvers`](http://git.k8s.io/enhancements/OWNERS_ALIASES)
-team. Please reach out on the
-[#prod-readiness](https://kubernetes.slack.com/archives/CPNHUMN74) channel if
-you need any help or guidance.
--->
-
-### Feature Enablement and Rollback
-
-<!--
-This section must be completed when targeting alpha to a release.
--->
-
-###### How can this feature be enabled / disabled in a live cluster?
-
-<!--
-Pick one of these and delete the rest.
--->
-
-- [ ] Feature gate (also fill in values in `kep.yaml`)
-  - Feature gate name:
-  - Components depending on the feature gate:
-- [ ] Other
-  - Describe the mechanism:
-  - Will enabling / disabling the feature require downtime of the control
-    plane?
-  - Will enabling / disabling the feature require downtime or reprovisioning
-    of a node? (Do not assume `Dynamic Kubelet Config` feature is enabled).
-
-###### Does enabling the feature change any default behavior?
-
-<!--
-Any change of default behavior may be surprising to users or break existing
-automations, so be extremely careful here.
--->
-
-###### Can the feature be disabled once it has been enabled (i.e. can we roll back the enablement)?
-
-<!--
-Describe the consequences on existing workloads (e.g., if this is a runtime
-feature, can it break the existing applications?).
-
-NOTE: Also set `disable-supported` to `true` or `false` in `kep.yaml`.
--->
-
-###### What happens if we reenable the feature if it was previously rolled back?
-
-###### Are there any tests for feature enablement/disablement?
-
-<!--
-The e2e framework does not currently support enabling or disabling feature
-gates. However, unit tests in each component dealing with managing data, created
-with and without the feature, are necessary. At the very least, think about
-conversion tests if API types are being modified.
--->
-
-### Rollout, Upgrade and Rollback Planning
-
-<!--
-This section must be completed when targeting beta to a release.
--->
-
-###### How can a rollout or rollback fail? Can it impact already running workloads?
-
-<!--
-Try to be as paranoid as possible - e.g., what if some components will restart
-mid-rollout?
-
-Be sure to consider highly-available clusters, where, for example,
-feature flags will be enabled on some API servers and not others during the
-rollout. Similarly, consider large clusters and how enablement/disablement
-will rollout across nodes.
--->
-
-###### What specific metrics should inform a rollback?
-
-<!--
-What signals should users be paying attention to when the feature is young
-that might indicate a serious problem?
--->
-
-###### Were upgrade and rollback tested? Was the upgrade->downgrade->upgrade path tested?
-
-<!--
-Describe manual testing that was done and the outcomes.
-Longer term, we may want to require automated upgrade/rollback tests, but we
-are missing a bunch of machinery and tooling and can't do that now.
--->
-
-###### Is the rollout accompanied by any deprecations and/or removals of features, APIs, fields of API types, flags, etc.?
-
-<!--
-Even if applying deprecation policies, they may still surprise some users.
--->
-
-### Monitoring Requirements
-
-<!--
-This section must be completed when targeting beta to a release.
--->
-
-###### How can an operator determine if the feature is in use by workloads?
-
-<!--
-Ideally, this should be a metric. Operations against the Kubernetes API (e.g.,
-checking if there are objects with field X set) may be a last resort. Avoid
-logs or events for this purpose.
--->
-
-###### How can someone using this feature know that it is working for their instance?
-
-<!--
-For instance, if this is a pod-related feature, it should be possible to determine if the feature is functioning properly
-for each individual pod.
-Pick one more of these and delete the rest.
-Please describe all items visible to end users below with sufficient detail so that they can verify correct enablement
-and operation of this feature.
-Recall that end users cannot usually observe component logs or access metrics.
--->
-
-- [ ] Events
-  - Event Reason: 
-- [ ] API .status
-  - Condition name: 
-  - Other field: 
-- [ ] Other (treat as last resort)
-  - Details:
-
-###### What are the reasonable SLOs (Service Level Objectives) for the enhancement?
-
-<!--
-This is your opportunity to define what "normal" quality of service looks like
-for a feature.
-
-It's impossible to provide comprehensive guidance, but at the very
-high level (needs more precise definitions) those may be things like:
-  - per-day percentage of API calls finishing with 5XX errors <= 1%
-  - 99% percentile over day of absolute value from (job creation time minus expected
-    job creation time) for cron job <= 10%
-  - 99.9% of /health requests per day finish with 200 code
-
-These goals will help you determine what you need to measure (SLIs) in the next
-question.
--->
-
-###### What are the SLIs (Service Level Indicators) an operator can use to determine the health of the service?
-
-<!--
-Pick one more of these and delete the rest.
--->
-
-- [ ] Metrics
-  - Metric name:
-  - [Optional] Aggregation method:
-  - Components exposing the metric:
-- [ ] Other (treat as last resort)
-  - Details:
-
-###### Are there any missing metrics that would be useful to have to improve observability of this feature?
-
-<!--
-Describe the metrics themselves and the reasons why they weren't added (e.g., cost,
-implementation difficulties, etc.).
--->
-
-### Dependencies
-
-<!--
-This section must be completed when targeting beta to a release.
--->
-
-###### Does this feature depend on any specific services running in the cluster?
-
-<!--
-Think about both cluster-level services (e.g. metrics-server) as well
-as node-level agents (e.g. specific version of CRI). Focus on external or
-optional services that are needed. For example, if this feature depends on
-a cloud provider API, or upon an external software-defined storage or network
-control plane.
-
-For each of these, fill in the following—thinking about running existing user workloads
-and creating new ones, as well as about cluster-level services (e.g. DNS):
-  - [Dependency name]
-    - Usage description:
-      - Impact of its outage on the feature:
-      - Impact of its degraded performance or high-error rates on the feature:
--->
-
-### Scalability
-
-<!--
-For alpha, this section is encouraged: reviewers should consider these questions
-and attempt to answer them.
-
-For beta, this section is required: reviewers must answer these questions.
-
-For GA, this section is required: approvers should be able to confirm the
-previous answers based on experience in the field.
--->
-
-###### Will enabling / using this feature result in any new API calls?
-
-<!--
-Describe them, providing:
-  - API call type (e.g. PATCH pods)
-  - estimated throughput
-  - originating component(s) (e.g. Kubelet, Feature-X-controller)
-Focusing mostly on:
-  - components listing and/or watching resources they didn't before
-  - API calls that may be triggered by changes of some Kubernetes resources
-    (e.g. update of object X triggers new updates of object Y)
-  - periodic API calls to reconcile state (e.g. periodic fetching state,
-    heartbeats, leader election, etc.)
--->
-
-###### Will enabling / using this feature result in introducing new API types?
-
-<!--
-Describe them, providing:
-  - API type
-  - Supported number of objects per cluster
-  - Supported number of objects per namespace (for namespace-scoped objects)
--->
-
-###### Will enabling / using this feature result in any new calls to the cloud provider?
-
-<!--
-Describe them, providing:
-  - Which API(s):
-  - Estimated increase:
--->
-
-###### Will enabling / using this feature result in increasing size or count of the existing API objects?
-
-<!--
-Describe them, providing:
-  - API type(s):
-  - Estimated increase in size: (e.g., new annotation of size 32B)
-  - Estimated amount of new objects: (e.g., new Object X for every existing Pod)
--->
-
-###### Will enabling / using this feature result in increasing time taken by any operations covered by existing SLIs/SLOs?
-
-<!--
-Look at the [existing SLIs/SLOs].
-
-Think about adding additional work or introducing new steps in between
-(e.g. need to do X to start a container), etc. Please describe the details.
-
-[existing SLIs/SLOs]: https://git.k8s.io/community/sig-scalability/slos/slos.md#kubernetes-slisslos
--->
-
-###### Will enabling / using this feature result in non-negligible increase of resource usage (CPU, RAM, disk, IO, ...) in any components?
-
-<!--
-Things to keep in mind include: additional in-memory state, additional
-non-trivial computations, excessive access to disks (including increased log
-volume), significant amount of data sent and/or received over network, etc.
-This through this both in small and large cases, again with respect to the
-[supported limits].
-
-[supported limits]: https://git.k8s.io/community//sig-scalability/configs-and-limits/thresholds.md
--->
-
-### Troubleshooting
-
-<!--
-This section must be completed when targeting beta to a release.
-
-The Troubleshooting section currently serves the `Playbook` role. We may consider
-splitting it into a dedicated `Playbook` document (potentially with some monitoring
-details). For now, we leave it here.
--->
-
-###### How does this feature react if the API server and/or etcd is unavailable?
-
-###### What are other known failure modes?
-
-<!--
-For each of them, fill in the following information by copying the below template:
-  - [Failure mode brief description]
-    - Detection: How can it be detected via metrics? Stated another way:
-      how can an operator troubleshoot without logging into a master or worker node?
-    - Mitigations: What can be done to stop the bleeding, especially for already
-      running user workloads?
-    - Diagnostics: What are the useful log messages and their required logging
-      levels that could help debug the issue?
-      Not required until feature graduated to beta.
-    - Testing: Are there any tests for failure mode? If not, describe why.
--->
-
-###### What steps should be taken if SLOs are not being met to determine the problem?
-
-## Implementation History
-
-<!--
-Major milestones in the lifecycle of a KEP should be tracked in this section.
-Major milestones might include:
-- the `Summary` and `Motivation` sections being merged, signaling SIG acceptance
-- the `Proposal` section being merged, signaling agreement on a proposed design
-- the date implementation started
-- the first Kubernetes release where an initial version of the KEP was available
-- the version of Kubernetes where the KEP graduated to general availability
-- when the KEP was retired or superseded
--->
-
-## Drawbacks
-
-<!--
-Why should this KEP _not_ be implemented?
--->
-
-## Alternatives
-
-<!--
-What other approaches did you consider, and why did you rule them out? These do
-not need to be as detailed as the proposal, but should include enough
-information to express the idea and why it was not acceptable.
--->
-
-## Infrastructure Needed (Optional)
-
-<!--
-Use this section if you need things from the project/SIG. Examples include a
-new subproject, repos requested, or GitHub details. Listing these here allows a
-SIG to get the process for these resources started right away.
--->
+- create Golang performance tests which can be easily run with `go test`
+- add a metrics report for performance test runs: CPU, Memory, I/O
+- make the tests portable, provide a container image for the test suite
diff --git a/test/integration/httproute_test.go b/test/integration/httproute_test.go
index 326213e09..cc1ffcefb 100644
--- a/test/integration/httproute_test.go
+++ b/test/integration/httproute_test.go
@@ -19,6 +19,7 @@ import (
 	gatewayv1alpha2 "sigs.k8s.io/gateway-api/apis/v1alpha2"
 	gatewayclient "sigs.k8s.io/gateway-api/pkg/client/clientset/gateway/versioned"
 
+	"github.com/kong/kubernetes-ingress-controller/v2/internal/annotations"
 	"github.com/kong/kubernetes-ingress-controller/v2/internal/controllers/gateway"
 )
 
@@ -110,9 +111,14 @@ func TestHTTPRouteEssentials(t *testing.T) {
 	t.Logf("creating an httproute to access deployment %s via kong", deployment.Name)
 	httpPort := gatewayv1alpha2.PortNumber(80)
 	pathMatchPrefix := gatewayv1alpha2.PathMatchPathPrefix
+	pathMatchRegularExpression := gatewayv1alpha2.PathMatchRegularExpression
+	pathMatchExact := gatewayv1alpha2.PathMatchExact
 	httproute := &gatewayv1alpha2.HTTPRoute{
 		ObjectMeta: metav1.ObjectMeta{
 			Name: uuid.NewString(),
+			Annotations: map[string]string{
+				annotations.AnnotationPrefix + annotations.StripPathKey: "true",
+			},
 		},
 		Spec: gatewayv1alpha2.HTTPRouteSpec{
 			CommonRouteSpec: gatewayv1alpha2.CommonRouteSpec{
@@ -121,12 +127,26 @@ func TestHTTPRouteEssentials(t *testing.T) {
 				}},
 			},
 			Rules: []gatewayv1alpha2.HTTPRouteRule{{
-				Matches: []gatewayv1alpha2.HTTPRouteMatch{{
-					Path: &gatewayv1alpha2.HTTPPathMatch{
-						Type:  &pathMatchPrefix,
-						Value: kong.String("/httpbin"),
+				Matches: []gatewayv1alpha2.HTTPRouteMatch{
+					{
+						Path: &gatewayv1alpha2.HTTPPathMatch{
+							Type:  &pathMatchPrefix,
+							Value: kong.String("/httpbin"),
+						},
 					},
-				}},
+					{
+						Path: &gatewayv1alpha2.HTTPPathMatch{
+							Type:  &pathMatchRegularExpression,
+							Value: kong.String(`/regex-\d{3}-httpbin`),
+						},
+					},
+					{
+						Path: &gatewayv1alpha2.HTTPPathMatch{
+							Type:  &pathMatchExact,
+							Value: kong.String(`/exact-httpbin`),
+						},
+					},
+				},
 				BackendRefs: []gatewayv1alpha2.HTTPBackendRef{{
 					BackendRef: gatewayv1alpha2.BackendRef{
 						BackendObjectReference: gatewayv1alpha2.BackendObjectReference{
@@ -155,6 +175,11 @@ func TestHTTPRouteEssentials(t *testing.T) {
 
 	t.Log("waiting for routes from HTTPRoute to become operational")
 	eventuallyGETPath(t, "httpbin", http.StatusOK, "<title>httpbin.org</title>")
+	eventuallyGETPath(t, "httpbin/base64/wqt5b8q7ccK7IGRhbiBib3NocWEgYmlyIGphdm9iaW1peiB5b8q7cWRpci4K",
+		http.StatusOK, "«yoʻq» dan boshqa bir javobimiz yoʻqdir.")
+	eventuallyGETPath(t, "regex-123-httpbin", http.StatusOK, "<title>httpbin.org</title>")
+	eventuallyGETPath(t, "exact-httpbin", http.StatusOK, "<title>httpbin.org</title>")
+	eventuallyGETPath(t, "exact-httpbina", http.StatusNotFound, "no Route matched")
 
 	t.Log("removing the parentrefs from the HTTPRoute")
 	oldParentRefs := httproute.Spec.ParentRefs