mirror of https://github.com/status-im/consul.git
docs: Update v2 Catalog API note to re-iterate beta and add downgrade from enterprise note (#20757)
* Update v1_18_x.mdx * Update traffic-split.mdx --------- Co-authored-by: Jeff Boruszak <104028618+boruszak@users.noreply.github.com>
This commit is contained in:
David Yu
GitHub
parent
6f48ce153c
commit
1323b7abf1
|
|
@ -4,6 +4,12 @@ page_title: Consul catalog v2 architecture
|
|||
description: Learn about version 2 of the Consul catalog, which uses GAMMA specified resources. Learn how the v2 catalog corresponds to the v1 catalog.
|
||||
---
|
||||
|
||||
<Warning>
|
||||
|
||||
The v2 catalog API and Traffic Permissions API are currently in beta. This documentation supports testing and development scenarios. Do not use these APIs in secure production environments.
|
||||
|
||||
</Warning>
|
||||
|
||||
# Consul catalog v2 architecture
|
||||
|
||||
This topic provides information about version 2 (v2) of the Consul catalog API. The catalog tracks registered services and their locations for both service discovery and service mesh use cases.
|
||||
|
|
@ -52,4 +58,4 @@ The following table describes resources in the v2 catalog, how they generally co
|
|||
| Health check | None | A resource for defining the health checks for a workload. | [Service instance health check](/consul/docs/services/usage/checks) | [Liveness, Readiness, and Startup Probes](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes) | Created by Kubernetes |
|
||||
| Proxy configuration | `mesh` | Represents a configuration for a sidecar or gateway proxy. | `Proxy` field in service definition | None | Created by Kubernetes or user CRD |
|
||||
| Destinations | `catalog` | Represents explicit service upstreams. When using the v1 catalog, these upstreams are configured in Helm chart as [Upstream Service annotations](/consul/docs/k8s/annotations-and-labels#consul-hashicorp-com-connect-service-upstreams) | [Proxy Configuration](/consul/docs/connect/proxies/envoy#envoy-proxy-configuration-for-service-mesh) | None | Created by Kubernetes |
|
||||
| Traffic permissions| `auth` | Enables L4 traffic authorization according to workload identity instead of service identity. | [Service intentions](/consul/docs/connect/intentions) | None | Created by user CRD |
|
||||
| Traffic permissions| `auth` | Enables L4 traffic authorization according to workload identity instead of service identity. | [Service intentions](/consul/docs/connect/intentions) | None | Created by user CRD |
|
||||
|
|
|
|||
|
|
@ -4,6 +4,12 @@ page_title: Consul resource groups
|
|||
description: Learn about resource groups in version 2 of Consul's internal architecture. The auth, catalog, and mesh groups structure Consul's ability to target individual workloads or an entire collection of workload endpoints.
|
||||
---
|
||||
|
||||
<Warning>
|
||||
|
||||
The v2 catalog API and Traffic Permissions API are currently in beta. This documentation supports testing and development scenarios. Do not use these APIs in secure production environments.
|
||||
|
||||
</Warning>
|
||||
|
||||
# Consul resource groups
|
||||
|
||||
This topic provides an overview of resource groups in Consul's v2 architecture.
|
||||
|
|
@ -42,4 +48,4 @@ The following table describes the Consul resources that belong to each resource
|
|||
| `mesh` | GRPCRoute | `mesh.v2beta1.GRPCRoute` |
|
||||
| `mesh` | HTTPRoute | `mesh.v2beta1.HTTPRoute` |
|
||||
| `mesh` | Proxy configuration | `mesh.v2beta1.ProxyConfiguration` |
|
||||
| `mesh` | TCPRoute | `mesh.v2beta1.TCPRoute` |
|
||||
| `mesh` | TCPRoute | `mesh.v2beta1.TCPRoute` |
|
||||
|
|
|
|||
|
|
@ -4,6 +4,12 @@ page_title: Consul v2 architecture
|
|||
description: Learn about version 2 of Consul's internal architecture, which replaces services and service instances with workloads and workload identies.
|
||||
---
|
||||
|
||||
<Warning>
|
||||
|
||||
The v2 catalog API and Traffic Permissions API are currently in beta. This documentation supports testing and development scenarios. Do not use these APIs in secure production environments.
|
||||
|
||||
</Warning>
|
||||
|
||||
# Consul v2 architecture
|
||||
|
||||
This topic provides an overview of Consul's v2 architecture changes and their impact on Consul operations.
|
||||
|
|
|
|||
|
|
@ -6,6 +6,12 @@ description: Learn how to enable the v2 catalog and configure services to suppor
|
|||
|
||||
# Configure multi-port services
|
||||
|
||||
<Warning>
|
||||
|
||||
The v2 catalog API and Traffic Permissions API are currently in beta. This documentation supports testing and development scenarios. Do not use these APIs in secure production environments.
|
||||
|
||||
</Warning>
|
||||
|
||||
<Note>
|
||||
|
||||
Multi-port services and selecting workloads using multiple services require enabling [Consul's v2 architecture](/consul/docs/architecture/v2).
|
||||
|
|
@ -482,4 +488,4 @@ Refer to the following pages for more information:
|
|||
- [Split traffic between services](/consul/docs/k8s/multiport/traffic-split)
|
||||
- [gRPC route example: route traffic by matching header](/consul/docs/k8s/multiport/reference/httproute#route-traffic-by-matching-header)
|
||||
- [HTTP route example: route traffic by matching header](/consul/docs/k8s/multiport/reference/httproute#route-traffic-by-matching-header)
|
||||
- [HTTP route example: route traffic by matching header and query parameter](/consul/docs/k8s/multiport/reference/httproute#route-traffic-by-matching-header-and-query-parameter)
|
||||
- [HTTP route example: route traffic by matching header and query parameter](/consul/docs/k8s/multiport/reference/httproute#route-traffic-by-matching-header-and-query-parameter)
|
||||
|
|
|
|||
|
|
@ -4,6 +4,12 @@ page_title: Use the v2 Catalog API
|
|||
description: Consul on Kubernetes supports the Catalog V2 API, which unlocks new service discovery and service mesh workflows. Learn how Consul’s Catalog V2 API supports workloads with multiple ports and selecting a workload using multiple services.
|
||||
---
|
||||
|
||||
<Warning>
|
||||
|
||||
The v2 catalog API and Traffic Permissions API are currently in beta. This documentation supports testing and development scenarios. Do not use these APIs in secure production environments.
|
||||
|
||||
</Warning>
|
||||
|
||||
# Use the v2 Catalog API
|
||||
|
||||
This topic describes the process to use the v2 catalog API to register a service with multiple ports or select a workload using multiple services on Kubernetes deployments. For information about the v2 catalog’s contents and structure, refer to [v2 catalog architecture](/consul/docs/architecture/v2/catalog).
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ description: Learn how to configure Consul to split TCP traffic between two port
|
|||
|
||||
<Warning>
|
||||
|
||||
Multi-port services are part of a beta release. This documentation supports testing and development scenarios. Do not use multi-port services or the v2 catalog API in secure production environments.
|
||||
The v2 catalog API is currently in beta. This documentation supports testing and development scenarios. Do not use the v2 catalog API in secure production environments.
|
||||
|
||||
</Warning>
|
||||
|
||||
|
|
@ -18,10 +18,10 @@ This page describes the process for splitting TCP, HTTP, and gRPC traffic betwee
|
|||
|
||||
Splitting traffic between two ports of a multi-port service requires the [v2 catalog API](/consul/docs/architecture/v2/catalog).
|
||||
|
||||
In addition, how you define a multi-port service affects how Services are addressed in Kubernetes. The instructions on this page offer examples for two configuration methods:
|
||||
In addition, they are two different workflows for registering Services in Kubernetes using the v2 catalog API. The instructions on this page offer examples for two configuration methods:
|
||||
|
||||
- **Method 1**: Define a single Kubernetes Service that exposes multiple ports
|
||||
- **Method 2**: Define multiple Kubernetes Services that expose individual ports
|
||||
- **Method 1**: Register a Kubernetes service that select workloads which expose multiple ports
|
||||
- **Method 2**: Register multiple Kubernetes Services that direct traffic to an explicit port on the same workload
|
||||
|
||||
For guidance on enabling the v2 catalog, deploying multi-port services using these methods, and applying traffic permissions to the services, refer to [configure multi-port services](/consul/docs/k8s/multiport/configure).
|
||||
|
||||
|
|
@ -110,4 +110,4 @@ $ kubectl exec -it ${WEB_POD} -c web -- curl api-admin:90
|
|||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
Half of the traffic should respond with the `hello world` response from port 80, instead of port 90's response of `hello world from 9090 admin`. Repeat the command several times to verify that you receive both responses.
|
||||
Half of the traffic should respond with the `hello world` response from port 80, instead of port 90's response of `hello world from 9090 admin`. Repeat the command several times to verify that you receive both responses.
|
||||
|
|
|
|||
|
|
@ -11,29 +11,33 @@ We are pleased to announce the following Consul updates.
|
|||
|
||||
## Release highlights
|
||||
|
||||
**Consul catalog v2 API updates:** Additional improvements were made to the v2 catalog API, which enables support for [multi-port services on Kubernetes](/consul/docs/k8s/multiport). End user facing changes include the ability to use a service's ports in xRoute configurations as opposed to the workload port for reference in the parentRef stanza of the xRoute configuration, and the change in Traffic Permissions to only allow `ACTION_DENY` for Consul Enterprise as it will enable future governance related workflows.
|
||||
- **Consul v2 Catalog API and Traffic Permission API updates:** Additional improvements were made to the v2 catalog API, which enables support for [multi-port services on Kubernetes](/consul/docs/k8s/multiport). End user facing changes include the ability to use a service's ports in xRoute configurations as opposed to the workload port for reference in the parentRef stanza of the xRoute configuration. In addition, the Traffic Permissions API was changed to only allow `ACTION_DENY` for Consul Enterprise as it will enable future governance related workflows.
|
||||
|
||||
The v2 catalog API is currently available for Consul on Kubernetes deployments only. Refer to [Consul v2 architecture](/consul/docs/architecture/v2) for more information.
|
||||
The v2 Catalog API is currently available for Consul on Kubernetes deployments only. Refer to [Consul v2 architecture](/consul/docs/architecture/v2) for more information.
|
||||
|
||||
**Consul Long Term Support (LTS) (Enterprise):** Consul Enterprise users can now receive Long Term Support for approximately 2 years on some Consul releases, starting with Consul Enterprise v1.15. During the LTS window, eligible fixes are provided through a new minor release on the affected LTS release branch.
|
||||
<Note> The v2 Catalog API and the Traffic Permssions API are in beta and under active development, so we do not recommend using them in production. </Note>
|
||||
|
||||
An LTS release is planned for every 3 releases, and it is maintained until it is 6 releases from the latest major release. For example, Consul Enterprise v1.15.x, v1.18x, and v1.21.x are the next three planned releases. The LTS period for Consul Enterprise v1.15.x ends when Consul Enterprise v1.21.0 releases.
|
||||
- **Consul Long Term Support (LTS) (Enterprise):** Consul Enterprise users can now receive Long Term Support for approximately 2 years on some Consul releases, starting with Consul Enterprise v1.15. During the LTS window, eligible fixes are provided through a new minor release on the affected LTS release branch.
|
||||
|
||||
For more information, refer to [Consul Enterprise Long Term Support](/consul/docs/enterprise/long-term-support).
|
||||
An LTS release is planned for every 3 releases, and it is maintained until it is 6 releases from the latest major release. For example, Consul Enterprise v1.15.x, v1.18x, and v1.21.x are the next three planned releases. The LTS period for Consul Enterprise v1.15.x ends when Consul Enterprise v1.21.0 releases.
|
||||
|
||||
**Fault injection (Enterprise):** For Enterprise users, Consul’s service mesh now supports managing traffic with fault injection behavior that is defined in an upstream service’s service defaults configuration entry or CRD. Supported fault injection behavior includes delaying, aborting, and rate limiting traffic between services. You can use fault injection to test your network’s resilience under different conditions.
|
||||
For more information, refer to [Consul Enterprise Long Term Support](/consul/docs/enterprise/long-term-support).
|
||||
|
||||
For more information, refer to [fault injection](/consul/docs/manage-traffic/fault-injection).
|
||||
- **Fault injection (Enterprise):** For Enterprise users, Consul’s service mesh now supports managing traffic with fault injection behavior that is defined in an upstream service’s service defaults configuration entry or CRD. Supported fault injection behavior includes delaying, aborting, and rate limiting traffic between services. You can use fault injection to test your network’s resilience under different conditions.
|
||||
|
||||
**Consul admin partition support for Nomad:** Nomad now supports configurations for a Consul datacenter’s admin partition when scheduling applications. Admin partitions are a Consul Enterprise feature that enable multi-tenancy for Consul servers so that several teams in your organization can use a single secure Consul datacenter. Admin partitions also enable cluster peering as a strategy for extending your service mesh east-west across regions in a single cloud provider or across multiple cloud providers.
|
||||
For more information, refer to [fault injection](/consul/docs/manage-traffic/fault-injection).
|
||||
|
||||
Refer to [admin partitions](/consul/docs/enterprise/admin-partitions) for more information.
|
||||
- **Consul admin partition support for Nomad:** Nomad now supports configurations for a Consul datacenter’s admin partition when scheduling applications. Admin partitions are a Consul Enterprise feature that enable multi-tenancy for Consul servers so that several teams in your organization can use a single secure Consul datacenter. Admin partitions also enable cluster peering as a strategy for extending your service mesh east-west across regions in a single cloud provider or across multiple cloud providers.
|
||||
|
||||
**Transparent proxy for EC2 on ECS:** Consul now supports transparent proxy mode for deployments running on EC2 instances in AWS Elastic Container Service (ECS). When service mesh proxies are in transparent proxy mode, Consul service mesh uses IPtables to direct all inbound and outbound traffic to the sidecar. Consul also uses information configured in service intentions to infer routes, which eliminates the need to explicitly configure upstreams.
|
||||
Refer to [admin partitions](/consul/docs/enterprise/admin-partitions) for more information.
|
||||
|
||||
Consul’s transparent proxy allows applications to communicate through Consul’s service mesh without modifying their underlying configurations to use Consul DNS. The transparent proxy also hardens application security by preventing direct inbound connections that bypass the mesh.
|
||||
- **Transparent proxy for EC2 on ECS:** Consul now supports transparent proxy mode for deployments running on EC2 instances in AWS Elastic Container Service (ECS). When service mesh proxies are in transparent proxy mode, Consul service mesh uses IPtables to direct all inbound and outbound traffic to the sidecar. Consul also uses information configured in service intentions to infer routes, which eliminates the need to explicitly configure upstreams.
|
||||
|
||||
Refer to [transparent proxy overview](/consul/docs/k8s/connect/transparent-proxy) and [Consul on ECS overview](/consul/docs/ecs) for more information.
|
||||
Consul’s transparent proxy allows applications to communicate through Consul’s service mesh without modifying their underlying configurations to use Consul DNS. The transparent proxy also hardens application security by preventing direct inbound connections that bypass the mesh.
|
||||
|
||||
Refer to [transparent proxy overview](/consul/docs/k8s/connect/transparent-proxy) and [Consul on ECS overview](/consul/docs/ecs) for more information.
|
||||
|
||||
- **Downgrade from Consul Enterprise to Consul Community Edition**: Consul now provides the ability for enterprise users to migrate their deployments to Community edition and disable enterprise features for business continuity. Refer to [Downgrade from Consul Enterprise to the community edition](/consul/docs/v1.18.x/enterprise/ent-to-ce-downgrades) for more information.
|
||||
|
||||
## Upgrading
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue