Merge pull request #792 from youngnick/api-overview-update

site: Index and Overview update

examples/v1alpha2/http-route-attachment/gateway-namespaces.yaml

@@ -0,0 +1,19 @@
+apiVersion: gateway.networking.k8s.io/v1alpha2
+kind: Gateway
+metadata:
+  name: prod-gateway
+  namespace: gateway-api-example-ns1
+spec:
+  gatewayClassName: foo-lb
+  listeners:
+  - name: prod-web
+    port: 80
+    protocol: HTTP    
+    allowedRoutes:
+      kinds: 
+        - kind: HTTPRoute
+      namespaces:
+        from: Selector
+        selector:
+          matchLabels:
+            expose-apps: "true"

examples/v1alpha2/http-route-attachment/gateway-strict.yaml

@@ -0,0 +1,21 @@
+apiVersion: gateway.networking.k8s.io/v1alpha2
+kind: Gateway
+metadata:
+  name: foo-gateway
+  namespace: gateway-api-example-ns1
+spec:
+  gatewayClassName: foo-lb
+  listeners:
+  - name: prod-web
+    port: 80
+    protocol: HTTP
+    allowedRoutes:
+      kinds: 
+        - kind: HTTPRoute
+      namespaces:
+        from: Selector
+        selector:
+          matchLabels:
+            # This label is added automatically as of K8s 1.22
+            # to all namespaces
+            kubernetes.io/metadata.name: gateway-api-example-ns2

examples/v1alpha2/http-route-attachment/httproute.yaml

@@ -0,0 +1,14 @@
+apiVersion: gateway.networking.k8s.io/v1alpha2
+kind: HTTPRoute
+metadata:
+  name: my-route
+  namespace: gateway-api-example-ns2
+spec:
+  parentRefs:
+  - kind: Gateway
+    name: foo-gateway
+    namespace: gateway-api-example-ns1
+  rules:
+  - backendRefs:
+    - name: foo-svc
+      port: 8080

requirements.txt

@@ -6,13 +6,13 @@ livereload==2.6.1
 Markdown==3.3.4
 MarkupSafe==1.1.1
 mkdocs==1.2.2
-mkdocs-material==7.2.3
-mkdocs-minify-plugin==0.2.1
+mkdocs-awesome-pages-plugin==2.5.0
+mkdocs-macros-plugin==0.5.12
+mkdocs-material==7.2.2
+mkdocs-material-extensions==1.0.1
 pep562==1.0
 Pygments==2.5.2
 pymdown-extensions==8.2
 PyYAML==5.3
 six==1.14.0
 tornado==6.0.3
-mkdocs-macros-plugin==0.4.18
-mkdocs-awesome-pages-plugin==2.5.0

site-src/index.md

@@ -12,16 +12,20 @@ many vendors and have broad industry support.
 
 ![Gateway API Model](./images/api-model.png)
 
+
+!!! warning
+    Gateway API is preparing to release v1alpha2, which is a large change, and
+    some documents on this site are out of date. Please pardon our dust for now.
 ## Getting started
 
 Whether you are a user interested in using the Gateway API or an implementer 
 interested in conforming to the API, the following resources will help give 
 you the necessary background:
 
 - [API overview](/concepts/api-overview)
-- [User guides](/v1alpha1/guides/getting-started)
+- [User guides](/v1alpha2/guides/getting-started)
 - [Gateway controller implementations](/implementations)
-- [API reference spec](/v1alpha1/references/spec)
+- [API reference spec](/v1alpha2/references/spec)
 - [Community links](/contributing/community) and [developer guide](/contributing/devguide)
 
 
@@ -51,7 +55,7 @@ implementations. These classes make it easy and explicit for users to
 understand what kind of capabilities are available via the Kubernetes resource 
 model.
 - **Shared Gateways and cross-Namespace support** - They allow the sharing of
-load balancers and VIPs by permitting independent Route resources to bind to
+load balancers and VIPs by permitting independent Route resources to attach to
 the same Gateway. This allows teams (even across Namespaces) to share
 infrastructure safely without direct coordination.
 - **Typed Routes and typed backends** - The Gateway API supports typed Route 
@@ -76,18 +80,19 @@ used by many different and non-coordinating teams, all bound by the policies
 and constraints set by cluster operators. The following example shows how this
 works in practice.
 
-A cluster operator creates a [Gateway](/v1alpha1/api-types/gateway) resource derived from a
-[GatewayClass](/v1alpha1/api-types/gatewayclass). This Gateway deploys or configures the
-underlying network resources that it represents. Through [Route binding
-policy](/concepts/api-overview#route-binding) set on the Gateway, the operator
-permits (or denies) specific teams to bind to this Gateway and expose their
-applications through it. Centralized policies [such as
-TLS](/guides/tls#downstream-tls) can be enforced on the Gateway by the cluster
-operator. Meanwhile, the store and site teams run [in their own
-Namespaces](/guides/multiple-ns), but bind their Routes against the same shared
-Gateway, allowing them to independently control their [routing
-logic](/guides/http-routing). This separation of concerns allows the store team to
-manage their own [traffic splitting rollout](/guides/traffic-splitting) while
+A cluster operator creates a [Gateway](/v1alpha2/api-types/gateway) resource derived from a
+[GatewayClass](/v1alpha2/api-types/gatewayclass). This Gateway deploys or configures the
+underlying network resources that it represents. Through the
+[Route Attachment Process](/concepts/api-overview#attaching-routes-to-gateways)
+between the Gateway and Routes, the cluster operator and specific teams must
+agree on what can attach to this Gateway and expose their applications through
+it. Centralized policies [such as TLS](/v1alpha2/guides/tls#downstream-tls) can
+be enforced on the Gateway by the cluster operator. Meanwhile, the store and site
+teams run [in their own Namespaces](/v1alpha2/guides/multiple-ns), but attach their
+Routes to the same shared Gateway, allowing them to independently control
+their [routing logic](/v1alpha2/guides/http-routing). This separation of concerns
+allows the store team to manage their own
+[traffic splitting rollout](/v1alpha2/guides/traffic-splitting) while
 leaving centralized policies and control to the cluster operators.
 
 ![Gateway API Roles](./images/gateway-roles.png)