luxolus
/
open-consul
2
0
Fork 0
Code Issues 1 Pull Requests Packages Releases Wiki Activity

Merge pull request #13427 from hashicorp/docs/capigw-0.3 

docs: Update docs for release of Consul API Gateway v0.3.0
This commit is contained in:
Jeff Apple 2022-06-22 00:00:42 -07:00 committed by GitHub
parent 4c0b4d026c 3dde875368
commit 4895c5f8b9
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
8 changed files with 336 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

83
website/content/docs/api-gateway/consul-api-gateway-install.mdx
View File

@ -15,7 +15,7 @@ Ensure that the environment you are deploying Consul API Gateway in meets the re
## Installation
-> **NOTE:** When you see `VERSION` in examples of commands or configuration settings, replace `VERSION` with the version number of the release you are installing, like `0.2.0`. If there is a lower case "v" in front of `VERSION` the version number needs to follow the "v" as is `v0.2.0`
-> **Version reference convention:** Replace `VERSION` in command and configuration examples with the Consul API Gateway version you are installing, such as `0.3.0`. In some instances, `VERSION` is prepended with a lowercase _v_. This indicates that you must include the `v` as is part of the version, for example `v0.3.0`.
1. Issue the following command to install the CRDs:
@ -44,7 +44,7 @@ Ensure that the environment you are deploying Consul API Gateway in meets the re
1. Install Consul API Gateway using the standard Consul Helm chart and specify the custom values file. Available versions of the [Consul Helm chart](https://github.com/hashicorp/consul-k8s/releases) can be found in GitHub releases.
```shell-session
$ helm install consul hashicorp/consul --version 0.43.0 --values values.yaml --create-namespace --namespace consul
$ helm install consul hashicorp/consul --version 0.45.0 --values values.yaml --create-namespace --namespace consul
```
## Usage
@ -168,9 +168,12 @@ The following table describes the allowed parameters for the `spec` array:
| `consul.ports.http` | Specifies the port for Consul's HTTP server. | Integer | `8500` |
| `consul.scheme` | Specifies the scheme to use for connecting to Consul. The supported values are `"http"` and `"https"`. | String | `"http"` |
| `copyAnnotations.service` | List of annotations to copy to the gateway service. | Array | `["external-dns.alpha.kubernetes.io/hostname"]` |
| `image.consulAPIGateway` | The image to use for consul-api-gateway. View available image tags on [DockerHub](https://hub.docker.com/r/hashicorp/consul-api-gateway/tags). | String | `"hashicorp/consul-api-gateway:RELEASE_VERSION"` |
| `image.envoy` | Specifies the container image to use for Envoy. View available image tags on [DockerHub](https://hub.docker.com/r/envoyproxy/envoy/tags). | String | `"envoyproxy/envoy:RELEASE_VERSION"` |
| `logLevel` | Specifies the error reporting level for logs. You can specify the following values: `error`, `warning`, `info`, `debug`, `trace`. | String | `"info"` |
| `deployment.defaultInstances` | Specifies the number of instances to deploy by default for each gateway. | Integer | 1 |
| `deployment.maxInstances` | Specifies the maximum allowed number of instances per gateway. | Integer | 8 |
| `deployment.minInstances` | Specifies the minimum allowed number of instances per gateway. | Integer | 1 |
| `image.consulAPIGateway` | The image to use for consul-api-gateway. View available image tags on [DockerHub](https://hub.docker.com/r/hashicorp/consul-api-gateway/tags). | String | `"hashicorp/consul-api-gateway:RELEASE_VERSION"` |
| `image.envoy` | Specifies the container image to use for Envoy. View available image tags on [DockerHub](https://hub.docker.com/r/envoyproxy/envoy/tags). | String | `"envoyproxy/envoy:RELEASE_VERSION"` |
| `logLevel` | Specifies the error reporting level for logs. You can specify the following values: `error`, `warning`, `info`, `debug`, `trace`. | String | `"info"` |
| `nodeSelector` | Specifies a set of parameters that constrain the nodes on which the pod can run. Defining nodes with the `nodeSelector` enables the pod to fit on a node. The selector must match a node's labels for the pod to be scheduled on that node. Refer to the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/) for additional information. | Object | N/A |
| `serviceType` | Specifies the ingress methods for a service. The following values are supported: <br/>`ClusterIP` <br/>`NodePort` <br/>`LoadBalancer`. | String | N/A |
| `useHostPorts` | If set to `true`, then the Envoy container ports are mapped to host ports. | Boolean | `false` |
@ -241,7 +244,56 @@ spec:
</CodeBlockConfig>
Refer to the [Kubernetes Gateway API documentation](https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.Gateway) for details about configuring gateways:
If you configure a listener's `certificateRefs` to reference a secret in a different namespace, you must also create a [ReferencePolicy](https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.ReferencePolicy) in the same namespace as the secret. The `ReferencePolicy` grants the listener the permission to read the secret.
The following example creates a `Gateway` named `example-gateway` in `gateway-namespace`. This `Gateway` has a `certificateRef` in `secret-namespace`.
The listener can use the certificate because `reference-policy` in `secret-namespace` is configured to allow `Gateways` in `gateway-namespace` to reference `Secrets` in `secret-namespace`.
<CodeBlockConfig filename="gateway_with_referencepolicy.yaml">
```yaml
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: Gateway
metadata:
name: example-gateway
namespace: gateway-namespace
annotations:
'external-dns.alpha.kubernetes.io/hostname': DNS_HOSTNAME
spec:
gatewayClassName: test-gateway-class
listeners:
- protocol: HTTPS
hostname: DNS_HOSTNAME
port: 443
name: https
allowedRoutes:
namespaces:
from: Same
tls:
certificateRefs:
- name: gateway-production-certificate
namespace: secret-namespace
---
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: ReferencePolicy
metadata:
name: reference-policy
namespace: secret-namespace
spec:
from:
- group: gateway.networking.k8s.io
kind: Gateway
namespace: gateway-namespace
to:
- group: ""
kind: Secret
name: gateway-production-certificate
```
</CodeBlockConfig>
Refer to the [Kubernetes Gateway API documentation](https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.Gateway) for further details about configuring gateways.
#### Listeners
@ -263,6 +315,25 @@ Add the `listener` object to the `gateway` configuration and specify the followi
Refer to the [Kubernetes Gateway API documentation](https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.Listener) for details about configuring listeners.
#### Scaling
You can scale a logical gateway object to multiple instances with the [`kubectl scale`](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#scaling-a-deployment) command. The object scales according to the bounds set in `GatewayClassConfig`.
```shell-session
$ kubectl get deployment --selector api-gateway.consul.hashicorp.com/name=example-gateway
NAME READY UP-TO-DATE AVAILABLE
example-gateway 1/1 1 1
```
```shell-session
$ kubectl scale deployment/example-gateway --replicas=3
deployment.apps/example-gateway scaled
```
```shell-session
$ kubectl get deployment --selector api-gateway.consul.hashicorp.com/name=example-gateway
NAME READY UP-TO-DATE AVAILABLE
example-gateway 3/3 3 3
```
### Route
Routes are independent configuration objects that are associated with specific listeners.

2
website/content/docs/api-gateway/index.mdx
View File

@ -38,7 +38,7 @@ are used, see the [documentation in our GitHub repo](https://github.com/hashicor
| [`Gateway`](https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.Gateway) | <ul><li>Supported protocols: `HTTP`, `HTTPS`, `TCP`</li><li>Header-based hostname matching (no SNI support)</li><li>Supported filters: header addition, removal, and setting</li><li>TLS modes supported: `terminate`</li><li>Certificate types supported: `core/v1/Secret`</li><li>Extended options: TLS version and cipher constraints</li></ul> |
| [`HTTPRoute`](https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.HTTPRoute) | <ul><li>Weight-based load balancing</li><li>Supported rules: path, header, query, and method-based matching</li><li>Supported filters: header addition, removal, and setting</li><li>Supported backend types: <ol><li>`core/v1/Service` (must map to a registered Consul service)</li><li>`api-gateway.consul.hashicorp.com/v1alpha1/MeshService`</li></ol></li></ul> |
| [`TCPRoute`](https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.TCPRoute) | <ul><li>Supported backend types: <ol><li>`core/v1/Service` (must map to a registered Consul service)</li><li>`api-gateway.consul.hashicorp.com/v1alpha1/MeshService`</li></ol></li></ul> |
| [`ReferencePolicy`](https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.ReferencePolicy) | <ul><li>Required to allow any reference from an `HTTPRoute` or `TCPRoute` to a Kubernetes `core/v1/Service` in a different namespace.</li><li>A route with an unpermitted BackendRef caused by the lack of a ReferencePolicy sets a `ResolvedRefs` status to `False` with the reason `RefNotPermitted`. The gateway listener rejects routes with an unpermitted BackendRef.</li><li>WARNING: If a route BackendRef becomes unpermitted, the entire route is removed from the gateway listener. <ul><li>A BackendRef can become unpermitted when you delete a Reference Policy or add a new unpermitted BackendRef to an existing route.</li></ul></li></ul> |
| [`ReferencePolicy`](https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.ReferencePolicy) | <ul><li>Required to allow any reference from a `Gateway` to a Kubernetes `core/v1/Secret` in a different namespace.</li><ul><li>A Gateway with an unpermitted `certificateRefs` caused by the lack of a` ReferencePolicy` sets a `ResolvedRefs` status to `False` with the reason `InvalidCertificateRef`. The Gateway will not become ready in this case.</li></ul><li>Required to allow any reference from an `HTTPRoute` or `TCPRoute` to a Kubernetes `core/v1/Service` in a different namespace.</li><ul><li>A route with an unpermitted `backendRefs` caused by the lack of a `ReferencePolicy` sets a `ResolvedRefs` status to `False` with the reason `RefNotPermitted`. The gateway listener rejects routes with an unpermitted `backendRefs`.</li><li>WARNING: If a route `backendRefs` becomes unpermitted, the entire route is removed from the gateway listener. <ul><li>A `backendRefs` can become unpermitted when you delete a `ReferencePolicy` or add a new unpermitted `backendRefs` to an existing route.</li></ul></li></ul></ul> |
## Additional Resources

5
website/content/docs/api-gateway/tech-specs.mdx
View File

@ -18,9 +18,10 @@ Verify that your environment meets the following requirements prior to using Con
Your datacenter must meet the following requirements prior to configuring the Consul API Gateway:
- Kubernetes 1.21+
- Kubernetes 1.24 is not supported at this time.
- `kubectl` 1.21+
- Consul 1.12.0+
- HashiCorp Consul Helm chart 0.43.0+
- Consul 1.11.2+
- HashiCorp Consul Helm chart 0.45.0+
- Consul Service Mesh must be deployed on the Kubernetes cluster that API Gateway is deployed on.
- Envoy: Envoy proxy support is determined by the Consul version deployed. Refer to [Envoy Integration](/docs/connect/proxies/envoy) for details.

199
website/content/docs/api-gateway/upgrade-specific-versions.mdx
View File

@ -9,11 +9,166 @@ description: >-
This topic describes how to upgrade Consul API Gateway.
## Breaking Changes
Consul API Gateway v0.2.0 introduces a breaking change for people upgrading from Consul API Gateway v0.1.0. Routes with a `backendRef` defined in a different namespace now require a [`ReferencePolicy`](https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.ReferencePolicy) that explicitly allows traffic from the route's namespace to the `backendRef`'s namespace.
## Upgrade to v0.3.0 from v0.2.0 or lower
## Requirements
Consul API Gateway v0.3.0 introduces a change for people upgrading from lower versions. Gateways with `listeners` with a `certificateRef` defined in a different namespace now require a [`ReferencePolicy`](https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.ReferencePolicy) that explicitly allows `Gateways` from the gateway's namesapce to use `certificateRef` in the `certificateRef`'s namespace.
### Requirements
Ensure that the following requirements are met prior to upgrading:
- Consul API Gateway should be running version v0.2.1 or lower.
- You should have the ability to run `kubectl` CLI commands.
- `kubectl` should be configured to point to the cluster containing the installation you are upgrading.
- You should have the following permission rights on your Kubernetes cluster:
- `Gateway.read`
- `ReferencePolicy.create`
- (Optional) The [jq](https://stedolan.github.io/jq/download/) command line processor for JSON can be installed, which will ease gateway retrieval during the upgrade process.
### Procedure
1. Verify the current version of the `consul-api-gateway-controller` `Deployment`:
```shell-session
$ kubectl get deployment --namespace consul consul-api-gateway-controller --output=jsonpath= "{@.spec.template.spec.containers[?(@.name=='api-gateway-controller')].image}"
```
You should receive a response similar to the following:
```log
"hashicorp/consul-api-gateway:0.2.1"
```
1. Retrieve all gateways that have a `certificateRefs` in a different namespace. If you have installed the [`jq`](https://stedolan.github.io/jq/) utility, you can skip to [step 4](#jq-command-secrets). Otherwise, issue the following command to get all `Gateways` across all namespaces:
```shell-session
$ kubectl get Gateway --output json --all-namespaces
```
If you have any active `Gateways`, you will receive output similar to the following response. The output has been truncated to show only relevant fields:
```yaml
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: Gateway
metadata:
name: example-gateway
namespace: gateway-namespace
spec:
gatewayClassName: "consul-api-gateway"
listeners:
- name: https
port: 443
protocol: HTTPS
allowedRoutes:
namespaces:
from: All
tls:
certificateRefs:
- group: ""
kind: Secret
name: example-certificate
namespace: certificate-namespace
```
1. Inspect the `certificateRefs` entries for each of the routes.
If a `namespace` field is not defined in the `certificateRefs` or if the namespace matches the namespace of the parent `Gateway`, then no additional action is required for the `certificateRefs`. Otherwise, note the `namespace` field values for `certificateRefs` configurations with a `namespace` field that do not match the namespace of the parent `Gateway`. You must also note the `namespace` of the parent gateway. You will need these to create a `ReferencePolicy` that explicitly allows each cross-namespace certificateRefs-to-gateway pair. (see [step 5](#create-secret-reference-policy)).
After completing this step, you will have a list of all secrets similar to the following:
<CodeBlockConfig hideClipboard>
```yaml hideClipboard
example-certificate:
- namespace: certificate-namespace
parentNamespace: gateway-namespace
```
</CodeBlockConfig>
Proceed with the [standard-upgrade](#standard-upgrade) if your list is empty.
<a name="jq-command-secrets"/>
1. If you have installed [`jq`](https://stedolan.github.io/jq/), issue the following command to get all `Gateways` and filter for secrets that require a `ReferencePolicy`.
```shell-session
$ kubectl get Gateway -o json -A | jq -r '.items[] | {gateway_name: .metadata.name, gateway_namespace: .metadata.namespace, kind: .kind, crossNamespaceSecrets: ( .metadata.namespace as $parentnamespace | .spec.listeners[] | select(has("tls")) | .tls.certificateRefs[] | select(.namespace != null and .namespace != $parentnamespace ) )} '
```
The output will resemble the following response if gateways that require a new `ReferencePolicy` are returned:
<CodeBlockConfig hideClipboard>
```log hideClipboard
{
"gateway_name": "example-gateway",
"gateway_namespace": "gateway-namespace",
"kind": "Gateway",
"crossNamespaceSecrets": {
"group": "",
"kind": "Secret",
"name": "cexample-certificate",
"namespace": "certificate-namespace"
}
}
```
</CodeBlockConfig>
If your output is empty, proceed with the [standard-upgrade](#standard-upgrade).
<a name="create-secret-reference-policy"/>
1. Using the list of secrets you created earlier as a guide, create a [`ReferencePolicy`](https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.ReferencePolicy) to allow each gateway cross namespace secret access.
The `ReferencePolicy` explicitly allows each cross-namespace gateway to secret pair. The `ReferencePolicy` must be created in the same `namespace` as the `certificateRefs`.
Skip to the next step if you've already created a `ReferencePolicy`.
<!---
TODO: add link to our docs on Cross Namespace Reference Policies, once we have written then, and tell the user to see them for more details on how to create these policies.
--->
The following example `ReferencePolicy` enables `example-gateway` in `gateway-namespace` to utilize `certificateRefs` in the `certificate-namespace` namespace:
<CodeBlockConfig filename="referencepolicy.yaml">
```yaml
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: ReferencePolicy
metadata:
name: reference-policy
namespace: certificate-namespace
spec:
from:
- group: gateway.networking.k8s.io
kind: Gateway
namespace: gateway-namespace
to:
- group: ""
kind: Secret
```
</CodeBlockConfig>
1. If you have already created a `ReferencePolicy`, modify it to allow your gateway to access your `certificateRef` and save it as `referencepolicy.yaml`. Note that each `ReferencePolicy` only supports one `to` field and one `from` field (refer the [`ReferencePolicy`](https://gateway-api.sigs.k8s.io/v1alpha2/api-types/referencepolicy/#api-design-decisions) documentation). As a result, you may need to create multiple `ReferencePolicy`s.
1. Issue the following command to apply it to your cluster:
```shell-session
$ kubectl apply --filename referencepolicy.yaml
```
Repeat this step as needed until each of your cross-namespace `certificateRefs` have a corresponding `ReferencePolicy`.
Proceed with the [standard-upgrade](#standard-upgrade).
## Upgrade to v0.2.0
Consul API Gateway v0.2.0 introduces a change for people upgrading from Consul API Gateway v0.1.0. Routes with a `backendRef` defined in a different namespace now require a [`ReferencePolicy`](https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.ReferencePolicy) that explicitly allows traffic from the route's namespace to the `backendRef`'s namespace.
### Requirements
Ensure that the following requirements are met prior to upgrading:
@ -26,9 +181,7 @@ Ensure that the following requirements are met prior to upgrading:
- `ReferencePolicy.create`
- (Optional) The [jq](https://stedolan.github.io/jq/download/) command line processor for JSON can be installed, which will ease route retrieval during the upgrade process.
## Procedure
-> **NOTE** When you see `VERSION` in examples of commands or configuration settings, replace `VERSION` with the version number of the release you are installing, like `0.2.0`. If there is a lower case "v" in front of `VERSION` the version number needs to follow the "v" as is `v0.2.0`
### Procedure
1. Verify the current version of the `consul-api-gateway-controller` `Deployment`:
@ -99,7 +252,7 @@ Ensure that the following requirements are met prior to upgrading:
1. Inspect the `backendRefs` entries for each of the routes.
If a `namespace` field is not defined in the `backendRef` or if the namespace matches the namespace of the route, then no additional action is required for the `backendRef`. Otherwise, note the `group`, `kind`, `name`, and `namespace` field values for `backendRef` configurations that have a `namespace` defined that do not match the namespace of the parent route. You must also note the `kind` and `namespace` of the parent route. You will need these to create a `ReferencePolicy` that explicitly allows each cross-namespace route-to-service pair to prevent the route from breaking (see [step 5](#create-reference-policy)).
If a `namespace` field is not defined in the `backendRef` or if the namespace matches the namespace of the route, then no additional action is required for the `backendRef`. Otherwise, note the `group`, `kind`, `name`, and `namespace` field values for `backendRef` configurations that have a `namespace` defined that do not match the namespace of the parent route. You must also note the `kind` and `namespace` of the parent route. You will need these to create a `ReferencePolicy` that explicitly allows each cross-namespace route-to-service pair (see [step 5](#create-reference-policy)).
After completing this step, you will have a list of all routes similar to the following:
@ -127,7 +280,7 @@ Ensure that the following requirements are met prior to upgrading:
</CodeBlockConfig>
Skip to [step 8](#step-8) if your list is empty.
Proceed with [standard-upgrade](#standard-upgrade) if your list is empty.
<a name="jq-command"/>
1. If you have installed [`jq`](https://stedolan.github.io/jq/), issue the following command to get all `HTTPRoutes` and `TCPRoutes` and filter for routes that require a `ReferencePolicy`.
@ -173,11 +326,11 @@ Ensure that the following requirements are met prior to upgrading:
</CodeBlockConfig>
If your output is empty, skip to [step 8](#step-8).
If your output is empty, proceed with the [standard-upgrade](#standard-upgrade).
<a name="create-reference-policy"/>
1. Using the list of routes you created earlier as a guide, create a [`ReferencePolicy`](https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.ReferencePolicy) to allow cross namespace traffic for each route service pair.
The `ReferencePolicy` explicitly allows each cross-namespace route to service pair to prevent the route from breaking. The `ReferencePolicy` must be created in the same `namespace` as the backend `Service`.
The `ReferencePolicy` explicitly allows each cross-namespace route to service pair. The `ReferencePolicy` must be created in the same `namespace` as the backend `Service`.
Skip to the next step if you've already created a `ReferencePolicy`.
<!---
@ -215,7 +368,27 @@ Ensure that the following requirements are met prior to upgrading:
```
Repeat this step as needed until each of your cross-namespace routes have a corresponding `ReferencePolicy`.
<a name="step-8"/>
Proceed with the [standard-upgrade](#standard-upgrade).
## Standard Upgrade
~> **Note:** When you see `VERSION` in examples of commands or configuration settings, replace `VERSION` with the version number of the release you are installing, like `0.2.0`. If there is a lower case "v" in front of `VERSION` the version number needs to follow the "v" as is `v0.2.0`
### Requirements
Ensure that the following requirements are met prior to upgrading:
- You should have the ability to run `kubectl` CLI commands.
- `kubectl` should be configured to point to the cluster containing the installation you are upgrading.
### Procedure
This is the upgrade path to use when there are no version specific steps to take.
<a name="standard-upgrade"/>
1. Issue the following command to install the new version of CRDs into your cluster:
@ -239,7 +412,7 @@ Ensure that the following requirements are met prior to upgrading:
1. Issue the following command to upgrade your Consul installation:
```shell-session
$ helm upgrade --values values.yaml --namespace consul --version <NEW_VERSION> hashicorp/consul <DEPLOYMENT_NAME>
$ helm upgrade --values values.yaml --namespace consul --version <NEW_VERSION> <DEPLOYMENT_NAME> hashicorp/consul
```
Note that the upgrade will cause the Consul API Gateway controller shut down and restart with the new version.
@ -261,6 +434,6 @@ Ensure that the following requirements are met prior to upgrading:
$ kubectl create --filename <path_to_route_config.yaml>
```
## Post-Upgrade Configuration Changes
### Post-Upgrade Configuration Changes
No additional configuration changes are required for this upgrade.

2
website/content/docs/release-notes/consul-api-gateway/v0_1_x.mdx
View File

@ -72,6 +72,6 @@ This release includes the following features and capabilities:
## Kubernetes Gateway API Specification
Supported version of the Gateway API spec: `v1alpha2`(v0.4.1)
Supported version of the [Gateway API](https://gateway-api.sigs.k8s.io/) spec: `v1alpha2`(v0.4.1)
For more detailed information, please refer to the [product documentation](/docs/api-gateway).

8
website/content/docs/release-notes/consul-api-gateway/v0_2_x.mdx
View File

@ -18,9 +18,9 @@ description: >-
was reachable, it didn’t allow users to set the more granular restrictions or
permissions that they may expect.
This version of API Gateway implements Cross Namespace Reference Policies
and requires them when routes are in a different namespace than the services
(as specified by the `backendRef`) they are routing traffic to.
This version of API Gateway implements Cross Namespace Reference Policies
and requires them when routes are in a different namespace than the services
(as specified by the `backendRefs`) they are routing traffic to.
## Supported Software
@ -33,7 +33,7 @@ description: >-
## Kubernetes Gateway API Specification
Supported version of the Gateway API spec: `v1alpha2`(v0.4.1)
Supported version of the [Gateway API](https://gateway-api.sigs.k8s.io/) spec: `v1alpha2`(v0.4.1)
## Upgrading

58
website/content/docs/release-notes/consul-api-gateway/v0_3_x.mdx Normal file
View File

@ -0,0 +1,58 @@
---
layout: docs
page_title: 0.3.x
description: >-
Consul API Gateway release notes for version 0.3.x
---
# Consul API Gateway 0.3.0
## Release Highlights
- **Improved High Availability and Scalability via Multiple Instances per Gateway:**
This release introduces support for deploying multiple instances of a logical
gateway (i.e. a K8s `gateway` config object). You can use an external load
balancing service to distribute incoming traffic across the instances of a
gateway. This provides higher availability of gateway services and also allows
a single logical gateway to handle a volume of network traffic that is much
greater than what a single instance of a gateway can.
Administrators can set the number of instances independently for each logical
gateway. Administrators can also set, in the `gatewayClassConfig`, the
minimum, maximum and default number of gateway instances. These are applied
per `gateway` to all `gateways` in that `gatewayClass`. The minimum and
maximum settings will override settings configured on any given `gateway`.
~> **Note:** There is a hard limit of eight (8) instances per `gateway` and it can
not be overridden. This hard limit will probably be increased in the future.
- **Cross Namespace Reference Policies for Certificates:**
Reference policies is a security feature introduced in the 0.2 release. In
this release, Reference Policies are now required for TLS certificates when a
`listener` has a `certificateRef` that is in a different `namespace`.
## Supported Software
- Consul 1.11.2+
- HashiCorp Consul Helm chart 0.45.0+
- Kubernetes 1.21+
- Kubernetes 1.24 is not supported at this time.
- Kubectl 1.21+
- Envoy proxy support is determined by the Consul version deployed. Refer to
[Envoy Integration](/docs/connect/proxies/envoy) for details.
## Kubernetes Gateway API Specification
Supported version of the [Gateway API](https://gateway-api.sigs.k8s.io/) spec: `v1alpha2`(v0.4.1)
## Upgrading
For detailed information on upgrading, please refer to the [upgrade details page](/docs/api-gateway/upgrade-specific-versions)
## Changelogs
The changelogs for this major release version and any maintenance versions are listed below.
~> **Note:** The following link will take you to the changelogs on the GitHub website.
- [0.3.0](https://github.com/hashicorp/consul-api-gateway/releases/tag/v0.3.0)

8
website/data/docs-nav-data.json
View File

@ -1253,12 +1253,16 @@
"title": "Consul API Gateway",
"routes": [
{
"title": "v0.1.x",
"path": "release-notes/consul-api-gateway/v0_1_x"
"title": "v0.3.x",
"path": "release-notes/consul-api-gateway/v0_3_x"
},
{
"title": "v0.2.x",
"path": "release-notes/consul-api-gateway/v0_2_x"
},
{
"title": "v0.1.x",
"path": "release-notes/consul-api-gateway/v0_1_x"
}
]
},