Reconcile with Rob's edits on the K8s website

Signed-off-by: [email protected]

Author: kflynn

site-src/blog/2023/0829-welcome-gamma.md

@@ -5,49 +5,35 @@ description: >
   some new capabilities, conformance profiles are supported, and more!
 ---
 
-# Gateway API: Welcome, GAMMA!
+# Gateway API: Welcome, Service Mesh Users!
 
 <small style="position:relative; top:-30px;">
-  :octicons-calendar-24: August 09, 2023 ·
+  :octicons-calendar-24: August 29, 2023 ·
   :octicons-clock-24: 5 min read
 </small>
 
-We are thrilled to announce the v0.8.0 release of the Gateway API! With this
-release, the work the GAMMA initiative has been doing over the past year has
-reached [Experimental status][status], and the Gateway and HTTPRoute resources
-gain some new capabilities. We look forward to your feedback!
+We are thrilled to announce the v0.8.0 release of Gateway API! With this
+release, Gateway API support for service mesh has reached [Experimental
+status][status], and the Gateway and HTTPRoute resources gain some new
+capabilities. We look forward to your feedback!
 
-## What is the GAMMA initiative?
+## Why add Service Mesh support to Gateway API?
 
-Almost from the point where the Gateway API was itself implementable,
-questions have been raised about how it could be used for configuring service
-meshes. The [GAMMA initiative][gamma], started in 2022, is a dedicated
-vendor-neutral workstream within the Gateway API, working on examining how
-best to fit the service mesh into the framework of the Gateway API resources,
-without requiring users of the Gateway API to relearn everything they
-understand about the Gateway API itself.
+While the initial focus of Gateway API was always ingress (north-south)
+traffic, it was clear almost from the beginning that the same basic routing
+concepts should also be applicable to service mesh (east-west) traffic. In
+2022, the Gateway API subproject started the [GAMMA initiative][gamma], a
+dedicated vendor-neutral workstream, specifically to examine how best to fit
+service mesh support into the framework of the Gateway API resources, without
+requiring users of Gateway API to relearn everything they understand about the
+API.
 
 Over the last year, GAMMA has dug deeply into the challenges and possible
 solutions around using the Gateway API for service mesh. The end result is a
 small number of [enhancement
 proposals](https://gateway-api.sigs.k8s.io/v1beta1/contributing/gep/) that
 subsume many hours of thought and debate, and provide a minimum viable path to
-allow the Gateway API to be used for service mesh. Of particular note:
-
-- [GEP-1324](https://gateway-api.sigs.k8s.io/geps/gep-1324/) provides an
-  overview of the GAMMA goals and some important definitions. This GEP is well
-  worth a read for its discussion of the problem space.
-- [GEP-1426](https://gateway-api.sigs.k8s.io/geps/gep-1426/) defines how to
-  use Gateway API route resources, such as HTTPRoute, to manage traffic within
-  a service mesh.
-- [GEP-1686](https://gateway-api.sigs.k8s.io/geps/gep-1686/) builds on the
-  work of [GEP-1709](https://gateway-api.sigs.k8s.io/geps/gep-1709/) to define
-  a _conformance profile_ for service meshes to be declared conformant with
-  the Gateway API.
-
-Although these are [Experimental][status] APIs, note that they are available
-in the [`standard` release channel][ch], since the GAMMA initiative has not
-needed to introduce new resources or fields to date.
+allow the Gateway API to be used for service mesh.
 
 ### How will mesh routing work when using the Gateway API?
 
@@ -69,9 +55,10 @@ follows:
     name: bar-route
   spec:
     parentRefs:
-      - name: demo-app
-          port: 5000
-          kind: Service
+      - group: ""
+        kind: Service
+        name: demo-app
+        port: 5000
     rules:
     - matches:
       - headers:
@@ -92,59 +79,108 @@ will be routed to `demo-app-v2` -- and since this is being handled by the
 service mesh, not the ingress controller, the A/B test can happen anywhere in
 the application's call graph.
 
-### How does Gateway API conformance work for a service mesh?
+## How do I know this will be truly portable?
 
-One of the challenges that the GAMMA initiative ran into is that Gateway API
-conformance was strongly tied to the idea that a given implementation provides
-an ingress controller. Many service meshes don't, and requiring a
-GAMMA-conformant mesh to also implement an ingress controller seemed
-impractical at best. This resulted in work restarting on Gateway API
-_conformance profiles_, as discussed in
-[GEP-1709](https://gateway-api.sigs.k8s.io/geps/gep-1709/).
+Gateway API has been investing heavily in conformance tests across all
+features it supports, and mesh is no exception. One of the challenges that the
+GAMMA initiative ran into is that these tests strongly tied to the idea that a
+given implementation provides an ingress controller. Many service meshes
+don't, and requiring a GAMMA-conformant mesh to also implement an ingress
+controller seemed impractical at best. This resulted in work restarting on
+Gateway API _conformance profiles_, as discussed in [GEP-1709].
 
 The basic idea of conformance profiles is that we can define subsets of the
-Gateway API, and allow implementations to choose - and document! - which
-subsets they conform to. (SIG-Network-Policy is going to be using this concept
-as well.) GAMMA is adding a new profile, named `Mesh`, which checks only the
-mesh functionality as defined by GAMMA. At this point, Kuma 2.3+, Linkerd
+Gateway API, and allow implementations to choose (and document) which subsets
+they conform to. GAMMA is adding a new profile, named `Mesh`, which checks only
+the mesh functionality as defined by GAMMA. At this point, Kuma 2.3+, Linkerd
 2.14+, and Istio 1.16+ are all conformant with the `Mesh` profile.
 
 ## What else is in Gateway API v0.8.0?
 
-In addition to GAMMA becoming experimental, the most significant change in
-v0.8.0 is that we have (by necessity) taken a hard look at the process around
-[Experimental][status] GEPs. Some of these GEPs have been lingering long
-enough that projects have come to rely on them in production use, which is a
-bit of a breakdown of the GEP process. In order to prevent it happening in the
-future, we have changed the GEP process such that reaching
-[Experimental][status] _requires_ that a GEP include both the graduation
-criteria by which the GEP will become [Standard][status], and a probationary
-period after which the GEP will be dropped if does not meet its graduation
-criteria.
+This release is all about preparing Gateway API for the upcoming v1.0 release
+where HTTPRoute, Gateway, and GatewayClass will graduate to GA. There are two
+main changes related to this: CEL validation and GEP process changes.
+
+### CEL Validation
+
+The first major change is that Gateway API v0.8.0 is the start of a transition
+from webhook validation to CEL validation using information built into the
+CRDs. That will mean different things depending on the version of Kubernetes
+you're using:
+
+#### Kubernetes 1.25+
+
+CEL validation is fully supported, and almost all validation is implemented in
+CEL. (The sole exception is that header names in header modifier filters can
+only do case-insensitive validation. There is more information in [issue
+2277].)
+
+We recommend _not_ using the validating webhook on these Kubernetes versions.
+
+#### Kubernetes 1.23 and 1.24
+
+CEL validation is not supported, but Gateway API v0.8.0 CRDs can still be
+installed. When you upgrade to Kubernetes 1.25+, the validation included in
+these CRDs will automatically take effect.
+
+We recommend continuing to use the validating webhook on these Kubernetes
+versions.
+
+#### Kubernetes 1.22 and older
+
+Gateway API only commits to support for [5 most recent versions of
+Kubernetes][supported-versions]. As such, these versions are no longer
+supported by Gateway API, and unfortunately Gateway API v0.8.0 cannot be
+installed on them, since CRDs containing CEL validation will be rejected.
+
+### GEP Process Changes
+
+The second significant change in Gateway API v0.8.0 is that we have (by
+necessity) taken a hard look at the process around [Experimental][status]
+GEPs. Some of these GEPs have been lingering long enough that projects have
+come to rely on them in production use, which is a bit of a breakdown of the
+GEP process. In order to prevent it happening in the future, we have changed
+the GEP process such that reaching [Experimental][status] _requires_ that a
+GEP include both the graduation criteria by which the GEP will become
+[Standard][status], and a probationary period after which the GEP will be
+dropped if does not meet its graduation criteria.
 
 For an exhaustive list of changes included in the `v0.8.0` release, please see
-the [v0.8.0 release
-notes](https://github.com/kubernetes-sigs/gateway-api/releases/tag/v0.8.0).
-For more information on Gateway API versioning, refer to the [official
-documentation](https://gateway-api.sigs.k8s.io/concepts/versioning/).
+the [v0.8.0 release notes]. For more information on Gateway API versioning,
+refer to the [official documentation][versioning docs].
 
 ## How can I get started with the Gateway API?
 
-At this point, the Gateway API is supported by a number of
-[implementations][impl] of both ingress controllers and service meshes. To get
-started, take a look at the [API concepts documentation][concepts] and check
-out some of the [Guides][guides] to learn about the Gateway API, or check out
-the [implementations page][impl] and select an implementation that you're
-familiar with to try it out. Gateway API is a [Custom Resource Definition
-(CRD)][crd] based API so you'll need to [install the CRDs][install-crds] onto
-a cluster to use the API.
+Gateway API represents the future of load balancing, routing, and service mesh
+APIs in Kubernetes. There are already more than 20 [implementations][impl]
+available (including both ingress controllers and service meshes) and the list
+keeps growing.
+
+If you're interested in getting started with Gateway API, take a look at the
+[API concepts documentation][concepts] and check out some of the
+[Guides][guides] to try it out. Because this is a CRD-based API, you can
+install the latest version on any Kubernetes 1.23+ cluster.
 
 If you're specifically interested in helping to contribute to Gateway API, we
 would love to have you! Please feel free to [open a new issue][issue] on the
 repository, or join in the [discussions][disc]. Also check out the [community
 page][community] which includes links to the Slack channel and community
 meetings. We look forward to seeing you!!
 
+## Further Reading:
+
+- [GEP-1324] provides an overview of the GAMMA goals and some important
+  definitions. This GEP is well worth a read for its discussion of the problem
+  space.
+- [GEP-1426] defines how to use Gateway API route resources, such as
+  HTTPRoute, to manage traffic within a service mesh.
+- [GEP-1686] builds on the work of [GEP-1709] to define a _conformance
+  profile_ for service meshes to be declared conformant with the Gateway API.
+
+Although these are [Experimental][status] APIs, note that they are available
+in the [`standard` release channel][ch], since the GAMMA initiative has not
+needed to introduce new resources or fields to date.
+
 [gamma]:/concepts/gamma/
 [status]:/geps/overview/#status
 [ch]:/concepts/versioning/#release-channels-eg-experimental-standard
@@ -158,3 +194,10 @@ meetings. We look forward to seeing you!!
 [community]:/contributing/community/
 [mesh-routing]:/concepts/gamma/#how-the-gateway-api-works-for-service-mesh
 [GEP-1426]:/geps/gep-1426/
+[GEP-1324]:/geps/gep-1324/
+[GEP-1686]:/geps/gep-1686/
+[GEP-1709]:/geps/gep-1709/
+[issue 2277]:https://github.com/kubernetes-sigs/gateway-api/issues/2277
+[supported-versions]:https://gateway-api.sigs.k8s.io/concepts/versioning/#supported-versions
+[v0.8.0 release notes]:https://github.com/kubernetes-sigs/gateway-api/releases/tag/v0.8.0
+[versioning docs]:https://gateway-api.sigs.k8s.io/concepts/versioning/