Backport of Propose new changes to APIgw upgrade instructions into release/1.16.x (#17909)

* no-op commit due to failed cherry-picking

* address merge conflict

---------

Co-authored-by: temp <temp@hashicorp.com>
Co-authored-by: Tu Nguyen <im2nguyen@users.noreply.github.com>
This commit is contained in:
hc-github-team-consul-core 2023-06-29 23:44:24 -05:00 committed by GitHub
parent aa6b431226
commit 5be3ee444e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 81 additions and 31 deletions

View File

@ -7,7 +7,7 @@ description: >-
# Upgrade Consul API gateway for Kubernetes
Since Consul v1.15, the Consul API gateway is a native feature within the Consul binary and is installed during the normal Consul installation process. Since Consul v1.16, the CRDs necessary for using the Consul API gateway for Kubernetes are also included. You can install Consul v1.16 using the Consul Helm chart v1.2 and later. Refer to [Install API gateway for Kubernetes](/consul/docs/api-gateway/install) for additional information.
Since Consul v1.15, the Consul API gateway is a native feature within the Consul binary and is installed during the normal Consul installation process. Since Consul on Kubernetes v1.2 (Consul v1.16), the CRDs necessary for using the Consul API gateway for Kubernetes are also included. You can install Consul v1.16 using the Consul Helm chart v1.2 and later. Refer to [Install API gateway for Kubernetes](/consul/docs/api-gateway/install) for additional information.
## Introduction
@ -47,64 +47,114 @@ To begin using the native API gateway, complete one of the following upgrade pat
## Upgrade to native Consul API gateway
You must begin the upgrade procedure with Consul API gateway v1.1 installed. If you are currently using a version of Consul API gateway older than v1.1, complete the necessary stages of the upgrade path to v1.1 before you begin upgrading to the native API gateway. Refer to the [Introduction](#introduction) for an overview of the upgrade paths.
You must begin the upgrade procedure with API gateway with Consul on Kubernetes v1.1 installed. If you are currently using a version of Consul on Kubernetes older than v1.1, complete the necessary stages of the upgrade path to v1.1 before you begin upgrading to the native API gateway. Refer to the [Introduction](#introduction) for an overview of the upgrade paths.
### Consul-managed CRDs
If you are able to tolerate downtime for your applications, you should delete previously installed CRDs and allow Consul to install and manage them for future updates. The amount of downtime depends on how quickly you are able to install the new version of Consul. If you are unable to tolerate any downtime, refer to [Self-managed CRDs](#self-managed-crds) for instructions on how to upgrade without downtime.
1. Run the `kubectl delete` command and reference the kustomize directory to delete the existing CRDs. The following example deletes the CRDs that were installed with API gateway v0.5.1:
1. Run the `kubectl delete` command and reference the `kustomize` directory to delete the existing CRDs. The following example deletes the CRDs that were installed with API gateway `v0.5.1`:
```shell-session
$ kubectl delete --kustomize="github.com/hashicorp/consul-api-gateway/config/crd?ref=v0.5.1"
```
1. Issue the following command to apply the configuration and complete the installation:
1. Issue the following command to use the API gateway packaged in Consul. Since Consul will not detected an external CRD, it will try to install the API gateway packaged with Consul.
```shell-session
$ kubectl apply -f apigw-installation.yaml
$ consul-k8s install -config-file values.yaml
```
1. Create `ServiceIntentions` allowing `Gateways` to communicate with any backend services that they route to. Refer to [Service intentions configuration entry reference](/consul/docs/connect/config-entries/service-intentions) for additional information.
1. Change any existing `Gateways` to reference the new `GatewayClass` `consul`. Refer to [gatewayClass](/consul/docs/api-gateway/configuration/gateway#gatewayclassname) for additional information.
1. After updating all of your `gateway` configurations to use the new controller, you can complete the upgrade again and completely remove the `apiGateway` block to remove the old controller.
1. After updating all of your `gateway` configurations to use the new controller, you can remove the `apiGateway` block from the Helm chart and upgrade your Consul cluster. This completely removes the old gateway controller.
<CodeBlockConfig filename="values.yaml">
```diff
global:
image: hashicorp/consul:1.15
imageK8S: hashicorp/consul-k8s-control-plane:1.1
- apiGateway:
- enabled: true
- image: hashicorp/consul-api-gateway:0.5.4
- managedGatewayClass:
- enabled: true
```
</CodeBlockConfig>
```shell-session
$ consul-k8s install -config-file values.yaml
```
### Self-managed CRDs
<Note>
This upgrade method uses `connectInject.apiGateway.manageExternalCRDs`, which was introduced in Consul on Kubernetes v1.2. As a result, you must be on at least Consul on Kubernetes v1.2 for this upgrade method.
</Note>
If you are unable to tolerate any downtime, you can complete the following steps to upgrade to the native Consul API gateway. If you choose this upgrade option, you must continue to manually install the CRDs necessary for operating the API gateway.
1. Create a values file that installs the version of Consul API gateway that ships with Consul and disables externally-managed CRDs:
1. Create a Helm chart that installs the version of Consul API gateway that ships with Consul and disables externally-managed CRDs:
<CodeBlock heading="apigw-installation.yaml">
<CodeBlockConfig filename="values.yaml" highlight="2-3,5-6">
```yaml
global:
image: hashicorp/consul:1.16
imageK8S: hashicorp/consul-k8s-control-plane
connectInject:
```yaml
global:
image: hashicorp/consul:1.16
imageK8S: hashicorp/consul-k8s-control-plane:1.2
connectInject:
apiGateway:
manageExternalCRDs: false
apiGateway:
manageExternalCRDs: false
apiGateway:
enabled: true
image: hashicorp/consul-api-gateway:0.5.4
managedGatewayClass:
enabled: true
```
image: hashicorp/consul-api-gateway:0.5.4
managedGatewayClass:
enabled: true
```
</CodeBlock>
</CodeBlockConfig>
You must set `connectInject.apiGateway.manageExternalCRDs` to `false`. If you have external CRDs with legacy installation and you do not set this, you will get an error when you try to upgrade because Helm will try to install CRDs that already exist.
1. Issue the following command to apply the configuration and complete the installation:
1. Issue the following command to install the new version of API gateway and disables externally-managed CRDs:
```shell-session
$ kubectl apply -f apigw-installation.yaml
$ consul-k8s install -config-file values.yaml
```
1. Create `ServiceIntentions` allowing `Gateways` to communicate with any backend services that they route to. Refer to [Service intentions configuration entry reference](/consul/docs/connect/config-entries/service-intentions) for additional information.
1. Change any existing `Gateways` to reference the new `GatewayClass` `consul`. Refer to [gatewayClass](/consul/docs/api-gateway/configuration/gateway#gatewayclassname) for additional information.
1. After updating all of your `gateway` configurations to use the new controller, you can remove the `apiGateway` block from the Helm chart and upgrade your Consul cluster. This completely removes the old gateway controller.
<CodeBlockConfig filename="values.yaml">
```diff
global:
image: hashicorp/consul:1.16
imageK8S: hashicorp/consul-k8s-control-plane:1.2
connectInject:
apiGateway:
manageExternalCRDs: false
- apiGateway:
- enabled: true
- image: hashicorp/consul-api-gateway:0.5.4
- managedGatewayClass:
- enabled: true
```
</CodeBlockConfig>
```shell-session
$ consul-k8s install -config-file values.yaml
```
## Upgrade to v0.4.0
@ -155,7 +205,7 @@ Complete the following steps after performing standard upgrade procedure.
You should receive a response similar to the following:
```log
```log hideClipboard
"hashicorp/consul-api-gateway:0.4.0"
```
@ -168,7 +218,7 @@ Complete the following steps after performing standard upgrade procedure.
```
If you have any active `ReferencePolicy` resources, you will receive output similar to the response below.
```log
```log hideClipboard
Warning: ReferencePolicy has been renamed to ReferenceGrant. ReferencePolicy will be removed in v0.6.0 in favor of the identical ReferenceGrant resource.
NAMESPACE NAME
default example-reference-policy
@ -293,7 +343,7 @@ Ensure that the following requirements are met prior to upgrading:
You should receive a response similar to the following:
```log
```log hideClipboard
"hashicorp/consul-api-gateway:0.2.1"
```
@ -447,7 +497,7 @@ Ensure that the following requirements are met prior to upgrading:
You should receive the following response:
```log
```log hideClipboard
"hashicorp/consul-api-gateway:0.1.0"
```

View File

@ -121,7 +121,7 @@ Follow the instructions described in [Create a task definition](/consul/docs/ecs
The secret stores the gossip encryption key that the Consul clients use.
<CodeBlock>
<CodeBlockConfig>
```hcl
resource "aws_secretsmanager_secret" "gossip_key" {
@ -134,7 +134,7 @@ resource "aws_secretsmanager_secret_version" "gossip_key" {
}
```
</CodeBlock>
</CodeBlockConfig>
### Enable secure deployment

View File

@ -87,13 +87,13 @@ Consul's FIPS 140-2 products on Windows use the CNGCrypto integration in Microso
To ensure your build of Consul Enterprise includes FIPS support, confirm that a line with `FIPS: Enabled` appears when you run a `version` command. For example, the following message appears for Linux users:
```shell-session hideClipboard
```log hideClipboard
FIPS: FIPS 140-2 Enabled, crypto module boringcrypto
```
The following message appears for Windows users:
```shell-session hideClipboard
```log hideClipboard
FIPS: FIPS 140-2 Enabled, crypto module cngcrypto
```
@ -121,7 +121,7 @@ Similarly, on a FIPS Windows binary, run `go tool nm` on the binary to get a sym
On both Linux and Windows non-FIPS builds, the search output yields no results.
### Compliance Validation
### Compliance validation
A Lab, authorized by the U.S. Government to certify FIPS 140-2 compliance, is in the process of verifying that Consul Enterprise and its related packages are compliant with the requirements of FIPS 140-2 Level 1.