docs: Consul K8s 0.48.0 release notes (#14414)
Co-authored-by: Thomas Eckert <teckert@hashicorp.com>
This commit is contained in:
parent
1fe98bbe0b
commit
6b6b538607
|
@ -21,7 +21,7 @@ description: >-
|
|||
|
||||
- Consul 1.11.x, Consul 1.12.x and Consul 1.13.1+
|
||||
- Kubernetes 1.19-1.23
|
||||
- Kubectl 1.21+
|
||||
- Kubectl 1.19+
|
||||
- Envoy proxy support is determined by the Consul version deployed. Refer to
|
||||
[Envoy Integration](/docs/connect/proxies/envoy) for details.
|
||||
|
||||
|
|
|
@ -0,0 +1,66 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: 0.48.x
|
||||
description: >-
|
||||
Consul on Kubernetes release notes for version 0.48.x
|
||||
---
|
||||
|
||||
# Consul on Kubernetes 0.48.0
|
||||
|
||||
## Release Highlights
|
||||
|
||||
- **Consul CNI Plugin**: This release introduces the Consul CNI Plugin for Consul on Kubernetes, to allow for configuring traffic redirection rules without escalated container privileges such as `CAP_NET_ADMIN`. Refer to [Enable the Consul CNI Plugin](/docs/k8s/installation/install#enable-the-consul-cni-plugin) for more details. The Consul CNI Plugin is supported for Consul K8s 0.48.0+ and Consul 1.13.1+.
|
||||
|
||||
- **Kubernetes 1.24 Support**: Add support for Kubernetes 1.24 where ServiceAccounts no longer have long-term JWT tokens. [[GH-1431](https://github.com/hashicorp/consul-k8s/pull/1431)]
|
||||
|
||||
- **MaxInboundConnections in service-defaults CRD**: Add support for MaxInboundConnections on the Service Defaults CRD. [[GH-1437](https://github.com/hashicorp/consul-k8s/pull/1437)]
|
||||
|
||||
- **API Gateway: ACL auth when using WAN Federation**: Configure ACL auth for controller correctly when deployed in secondary datacenter with federation enabled [[GH-1462](https://github.com/hashicorp/consul-k8s/pull/1462)]
|
||||
|
||||
## What has Changed
|
||||
|
||||
- **Kubernetes 1.24 Support for multiport applications require Kubernetes secrets**: Users deploying multiple services to the same Pod (multiport) on Kubernetes 1.24+ must also deploy a Kubernetes secret for each ServiceAccount associated with the Consul service. The name of the Secret must match the ServiceAccount name and be of type `kubernetes.io/service-account-token`
|
||||
Example:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: svc1
|
||||
annotations:
|
||||
kubernetes.io/service-account.name: svc1
|
||||
type: kubernetes.io/service-account-token
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: svc2
|
||||
annotations:
|
||||
kubernetes.io/service-account.name: svc2
|
||||
type: kubernetes.io/service-account-token
|
||||
```
|
||||
|
||||
## Supported Software
|
||||
|
||||
- Consul 1.11.x, Consul 1.12.x and Consul 1.13.1+
|
||||
- Kubernetes 1.19-1.24
|
||||
- Kubectl 1.19+
|
||||
- Envoy proxy support is determined by the Consul version deployed. Refer to
|
||||
[Envoy Integration](/docs/connect/proxies/envoy) for details.
|
||||
|
||||
## Upgrading
|
||||
|
||||
For detailed information on upgrading, please refer to the [Upgrades page](/docs/k8s/upgrade)
|
||||
|
||||
## Known Issues
|
||||
The following issues are know to exist in the v0.48.0 release:
|
||||
|
||||
- Consul CNI Plugin currently does not support RedHat OpenShift as the CNI Plugin Daemonset requires additional SecurityContextConstraint objects to run on OpenShift. Support for OpenShift will be added in an upcoming release.
|
||||
|
||||
## Changelogs
|
||||
|
||||
The changelogs for this major release version and any maintenance versions are listed below.
|
||||
|
||||
~> **Note:** The following link takes you to the changelogs on the GitHub website.
|
||||
|
||||
- [0.48.0](https://github.com/hashicorp/consul-k8s/releases/tag/v0.48.0)
|
|
@ -9,15 +9,15 @@ description: >-
|
|||
|
||||
## Release Highlights
|
||||
|
||||
- **Admin Partitions (Enterprise):** Consul 1.11.0 Enterprise introduces a new entity for defining administrative and networking boundaries within a Consul deployment. This feature also enables servers to communicate with clients over a specific gossip segment created for each partition. This release also enables cross partition communication between services across partitions, using Mesh Gateways. For more information refer to the [Admin Partitions](/docs/enterprise/admin-partitions) documentation.
|
||||
- **Admin Partitions (Enterprise)**: Consul 1.11.0 Enterprise introduces a new entity for defining administrative and networking boundaries within a Consul deployment. This feature also enables servers to communicate with clients over a specific gossip segment created for each partition. This release also enables cross partition communication between services across partitions, using Mesh Gateways. For more information refer to the [Admin Partitions](/docs/enterprise/admin-partitions) documentation.
|
||||
|
||||
- **Virtual IPs for services deployed with Consul Service Mesh:** Consul will now generate a unique virtual IP for each service deployed within Consul Service Mesh, allowing transparent proxy to route to services within a data center that exist in different clusters or outside the service mesh.
|
||||
- **Virtual IPs for services deployed with Consul Service Mesh**: Consul will now generate a unique virtual IP for each service deployed within Consul Service Mesh, allowing transparent proxy to route to services within a data center that exist in different clusters or outside the service mesh.
|
||||
|
||||
- **Replace [boltdb](https://github.com/boltdb/bolt) with [etcd-io/bbolt](https://github.com/etcd-io/bbolt) for raft log store:** Consul now leverages `etcd-io/bbolt` as the default implementation of `boltdb` instead of `boltdb/bolt`. This change also exposes a configuration to allow for disabling boltdb freelist syncing. In addition, Consul now emits metrics for the raft boltdb store to provide insights into boltdb performance.
|
||||
- **Replace [boltdb](https://github.com/boltdb/bolt) with [etcd-io/bbolt](https://github.com/etcd-io/bbolt) for raft log store**: Consul now leverages `etcd-io/bbolt` as the default implementation of `boltdb` instead of `boltdb/bolt`. This change also exposes a configuration to allow for disabling boltdb freelist syncing. In addition, Consul now emits metrics for the raft boltdb store to provide insights into boltdb performance.
|
||||
|
||||
- **TLS Certificates for Ingress Gateways via an SDS source:**: Ingress Gateways can now be configured to retrieve TLS certificates from an external SDS Service and load the TLS certificates for Ingress listeners. This configuration is set using the `ingress-gateway` configuration entry via the [SDS](/docs/connect/config-entries/ingress-gateway#sds) stanza within the Ingress Gateway TLS configuration.
|
||||
- **TLS Certificates for Ingress Gateways via an SDS source**: Ingress Gateways can now be configured to retrieve TLS certificates from an external SDS Service and load the TLS certificates for Ingress listeners. This configuration is set using the `ingress-gateway` configuration entry via the [SDS](/docs/connect/config-entries/ingress-gateway#sds) stanza within the Ingress Gateway TLS configuration.
|
||||
|
||||
- **Vault Auth Method support for Connect CA Vault Provider:** Consul now supports configuring the Connect CA Vault provider to use auth methods for authentication to Vault. Consul supports using any non-deprecated auth method that is available in Vault v1.8.5, including AppRole, AliCloud, AWS, Azure, Cloud Foundry, GitHub, Google Cloud, JWT/OIDC, Kerberos, Kubernetes, LDAP, Oracle Cloud Infrastructure, Okta, Radius, TLS Certificates, and Username & Password. The Vault Auth Method for Connect CA Provider is utilized by default for the [Vault Secrets Backend](/docs/k8s/installation/vault) feature on Consul on Kubernetes. Utilizing a Vault Auth method would no longer require a Vault token to be managed or provisioned ahead of time to be used for authentication to Vault.
|
||||
- **Vault Auth Method support for Connect CA Vault Provider**: Consul now supports configuring the Connect CA Vault provider to use auth methods for authentication to Vault. Consul supports using any non-deprecated auth method that is available in Vault v1.8.5, including AppRole, AliCloud, AWS, Azure, Cloud Foundry, GitHub, Google Cloud, JWT/OIDC, Kerberos, Kubernetes, LDAP, Oracle Cloud Infrastructure, Okta, Radius, TLS Certificates, and Username & Password. The Vault Auth Method for Connect CA Provider is utilized by default for the [Vault Secrets Backend](/docs/k8s/installation/vault) feature on Consul on Kubernetes. Utilizing a Vault Auth method would no longer require a Vault token to be managed or provisioned ahead of time to be used for authentication to Vault.
|
||||
|
||||
## What's Changed
|
||||
|
||||
|
|
|
@ -15,7 +15,7 @@ description: >-
|
|||
|
||||
- **AWS Lambda**: Adds the ability to invoke AWS Lambdas through terminating gateways, which allows for cross-datacenter communication, transparent proxy, and intentions with Consul Service Mesh. Refer to [AWS Lambda](/docs]/lambda) and [Invoke Lambda Functions](/docs/lambda/invocation) for more details.
|
||||
|
||||
- **Mesh-wide TLS min/max versions and cipher suites:** Using the [Mesh](/docs/connect/config-entries/mesh#tls) Config Entry or CRD, it is now possible to set TLS min/max versions and cipher suites for both inbound and outbound mTLS connections.
|
||||
- **Mesh-wide TLS min/max versions and cipher suites**: Using the [Mesh](/docs/connect/config-entries/mesh#tls) Config Entry or CRD, it is now possible to set TLS min/max versions and cipher suites for both inbound and outbound mTLS connections.
|
||||
|
||||
- **Expanded details for ACL Permission Denied errors**: Details are now provided when a permission denied errors surface for RPC calls. Details include the accessor ID of the ACL token, the missing permission, and any namespace or partition that the error occurred on.
|
||||
|
||||
|
|
|
@ -31,7 +31,7 @@ For more detailed information, please refer to the [upgrade details page](/docs/
|
|||
The following issues are know to exist in the 1.13.0 release:
|
||||
|
||||
- Consul 1.13.1 fixes a compatibility issue when restoring snapshots from pre-1.13.0 versions of Consul. Refer to GitHub issue [[GH-14149](https://github.com/hashicorp/consul/issues/14149)] for more details.
|
||||
- Consul 1.13.0 and Consul 1.13.1 default to requiring TLS for gRPC communication with Envoy proxies when auto-encrypt and auto-config are enabled. In environments where Envoy proxies are not already configured to use TLS for gRPC, upgrading Consul 1.13 will cause Envoy proxies to disconnect from the control plane (Consul agents). A future patch release will default to disabling TLS by default for GRPC communication with Envoy proxies when using Service Mesh and auto-config or auto-encrypt. Refer to GitHub issue [GH-14253](https://github.com/hashicorp/consul/issues/14253) and [Service Mesh deployments using auto-config and auto-enrypt](https://www.consul.io/docs/upgrading/upgrade-specific#service-mesh-deployments-using-auto-encrypt-or-auto-config) for more details.
|
||||
- Consul 1.13.0 and Consul 1.13.1 default to requiring TLS for gRPC communication with Envoy proxies when auto-encrypt and auto-config are enabled. In environments where Envoy proxies are not already configured to use TLS for gRPC, upgrading Consul 1.13 will cause Envoy proxies to disconnect from the control plane (Consul agents). A future patch release will default to disabling TLS by default for GRPC communication with Envoy proxies when using Service Mesh and auto-config or auto-encrypt. Refer to GitHub issue [[GH-14253](https://github.com/hashicorp/consul/issues/14253)] and [Service Mesh deployments using auto-config and auto-enrypt](https://www.consul.io/docs/upgrading/upgrade-specific#service-mesh-deployments-using-auto-encrypt-or-auto-config) for more details.
|
||||
|
||||
|
||||
## Changelogs
|
||||
|
|
|
@ -1273,6 +1273,10 @@
|
|||
{
|
||||
"title": "Consul K8s",
|
||||
"routes": [
|
||||
{
|
||||
"title": "v0.48.x",
|
||||
"path": "release-notes/consul-k8s/v0_48_x"
|
||||
},
|
||||
{
|
||||
"title": "v0.47.x",
|
||||
"path": "release-notes/consul-k8s/v0_47_x"
|
||||
|
|
Loading…
Reference in New Issue