The Consul API Gateway is a dedicated ingress solution for intelligently routing traffic to applications running on a Consul Service Mesh.

Consul API Gateway CI Status Discuss

Overview

The Consul API Gateway is a dedicated ingress solution for intelligently routing traffic to applications running on a Consul Service Mesh. Currently it only runs on Kubernetes and is implemented as a Kubernetes Gateway Controller but, in future releases, it will work across multiple scheduler and runtime ecosystems.

Usage

Prerequisites

The Consul API Gateway must be installed on a Kubernetes cluster with the Consul K8s service mesh deployed on it. The installed version of Consul must be v1.11-beta2 or greater.

The Consul Helm chart must be used, with specific settings, to install Consul on the Kubernetes cluster. This can be done with the following commands:

helm repo add hashicorp https://helm.releases.hashicorp.com
cat <<EOF | helm install consul hashicorp/consul --version 0.36.0 -f -
global:
  name: consul
  image: "hashicorp/consul:1.11.0-beta2"
  tls:
    enabled: true
connectInject:
  enabled: true
controller:
  enabled: true
EOF

Install the Tech Preview

To install the Consul API Gateway controller and a base Kubernetes GatewayClass that leverages the API Gateway, run the following commands:

kubectl apply -k "github.com/hashicorp/consul-api-gateway/config/crd?ref=v0.1.0-techpreview"
kubectl apply -k "github.com/hashicorp/consul-api-gateway/config?ref=v0.1.0-techpreview"

You should now be able to deploy a Gateway by referencing the gateway class default-consul-gateway-class in a Kubernetes Gateway manifest.

Configuring and Deploying API Gateways

Consul API Gateways are configured and deployed via the Kubernetes Gateway API standard. The Kubernetes Gateway API webite explains the design of the standard, examples of how to use it and the complete specification of the API.

The Consul API Gateway Tech Preview supports current version (v1alpha2) of the Gateway API.

Supported Features: Please see Supported Features for a list of K8s Gateway API features supported by the current release of Consul API Gateway.

Tutorial

For an example of how to deploy a Consul API Gateway and use it alongside CertManager and External DNS, see the Example Setup.

Contributing

Thank you for your interest in contributing! Please refer to CONTRIBUTING.md for guidance.

For development, please see our Quick Start guide. Other documentation can be found inside our in-repo developer documentation.

Owner
HashiCorp
Consistent workflows to provision, secure, connect, and run any infrastructure for any application.
HashiCorp
Comments
  • There doesn't appear to be a way to create an API Gateway, or Gateway per cluster in a federated WAN

    There doesn't appear to be a way to create an API Gateway, or Gateway per cluster in a federated WAN

    Overview of the Issue

    I don't seem to be able to set up API gateway in such a way that I can either have access to all mesh services from a single API Gateway, or using and API Gateway per cluster.

    Reproduction Steps

    1. Set up an initial cluster using HELM charts and creating an API Gateway (this all works as expected)
    2. Set up a second federated cluster following the instructions here: https://www.consul.io/docs/k8s/installation/multi-cluster/kubernetes
    3. Services in the second datacenter are not accessible to the API Gateway created in the first datacenter cluster.
    4. Using the federated setup, creating a new API Gateway to access services in the second datacenter fail with SSL connection issues.

    Logs

    Error when trying to add mesh service from second cluster to API Gateway in first cluster

    k get httproute/test-service-route -n test -o jsonpath='{.status}' | jq
    {
      "parents": [
        {
          "conditions": [
            {
              "lastTransitionTime": "2022-08-08T07:38:16Z",
              "message": "1 error occurred:\n\t* route is in an invalid state and cannot bind\n\n",
              "observedGeneration": 2,
              "reason": "BindError",
              "status": "False",
              "type": "Accepted"
            },
            {
              "lastTransitionTime": "2022-08-08T07:38:16Z",
              "message": "k8s: service test/test-service not found",
              "observedGeneration": 2,
              "reason": "ServiceNotFound",
              "status": "False",
              "type": "ResolvedRefs"
            }
          ],
          "controllerName": "hashicorp.com/consul-api-gateway-controller",
          "parentRef": {
            "group": "gateway.networking.k8s.io",
            "kind": "Gateway",
            "name": "api-gateway",
            "namespace": "consul"
          }
        }
      ]
    }
    

    Error when trying to connect to a second API Gateway in the second datacenter cluster.

    curl -vvi -k --header "Host: test-service.api.gateway" "https://${API}:8443/
    * TCP_NODELAY set
    * Connected to X.X.X.X (X.X.X.X) port 8443 (#0)
    * ALPN, offering h2
    * ALPN, offering http/1.1
    * successfully set certificate verify locations:
    *   CAfile: /etc/pki/tls/certs/ca-bundle.crt
      CApath: none
    * TLSv1.3 (OUT), TLS handshake, Client hello (1):
    * OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to X.X.X.X:8445
    * Closing connection 0
    curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to X.X.X.X:8445
    

    Expected behavior

    There is a documented solution for setting up API Gateways across federated clusters.

    Environment details

    Additional Context

    I suspect this is a simple case of me not seeing the specific documentation required to set this up correctly, but I'm having a lot of problems getting the API Gateway up and running across multiple clusters.

  • CRT Build workflows

    CRT Build workflows

    I'm sure we'll want someone to take a look to make sure I set the CRT stuff makes sense -- a few things:

    1. I'm not entirely sure what we need around EULA stuff/how this works with enterprise licensing
    2. Do we need the distro packaging components right now (do we actually want to make a deb/rpm for release)?
    3. I'd be inclined to introduce the testing job to the build workflow rather than its own separate workflow so that we don't actually attempt to build/deploy a release without it having gone through the testing pipeline (alternatively can we add the test workflow as a dependency in the .release/ci.yml file?) -- is that frowned upon with the CRT process or is it fine to add our own jobs in the workflow?
    4. Not entirely sure if I set up the .release/ci.yml file properly -- I'm assuming that the sign and verify steps are for GPG-signing the deb/rpm artifacts, do we need either of those steps if we're not shipping packages but only a Docker artifact?
    5. not entirely sure if release_branches = ["main"] in the .release/ci.yml is the way to go -- does that mean we'd be pushing a container to Docker Hub whenever there's a push to the main branch?

    Any suggestions as to who can review those components of the setup?

  • Gateway Status Update Stub

    Gateway Status Update Stub

    So this still needs to be hooked up to our reconciliation loop for the Gateway status, which I wanted to do in a separate PR.... but here's a basic tracker for gateway pods. Here's an example of the log output showing the generated conditions based on the pod status:

    ➜  consul-api-gateway git:(gateway-status) ✗ ./scripts/develop -s | grep -i "gateway deployment pod status"
    2021-09-21T14:50:52.569-0400 [INFO]  consul-api-gateway-server.k8s.controllers.Pod: gateway deployment pod status updated: pod=default/test-gateway-67cf6fff56-xmvc4 conditions=["{Scheduled False 0 2021-09-21 14:50:52.569222 -0400 EDT m=+20.402226267 NotReconciled }"]
    2021-09-21T14:50:52.580-0400 [INFO]  consul-api-gateway-server.k8s.controllers.Pod: gateway deployment pod status updated: pod=default/test-gateway-67cf6fff56-xmvc4 conditions=["{Scheduled True 0 2021-09-21 14:50:52.58065 -0400 EDT m=+20.413654163 Scheduled }"]
    2021-09-21T14:50:55.110-0400 [INFO]  consul-api-gateway-server.k8s.controllers.Pod: gateway deployment pod status updated: pod=default/test-gateway-67cf6fff56-xmvc4 conditions=["{Scheduled True 0 2021-09-21 14:50:55.110591 -0400 EDT m=+22.943518755 Scheduled }", "{Ready False 0 2021-09-21 14:50:55.110591 -0400 EDT m=+22.943518847 ListenersNotReady }"]
    2021-09-21T14:51:02.601-0400 [INFO]  consul-api-gateway-server.k8s.controllers.Pod: gateway deployment pod status updated: pod=default/test-gateway-67cf6fff56-xmvc4 conditions=["{Scheduled True 0 2021-09-21 14:51:02.601438 -0400 EDT m=+30.434140975 Scheduled }", "{Ready True 0 2021-09-21 14:51:02.601438 -0400 EDT m=+30.434141055 Ready }"]
    

    One thing to note is that this leverages readiness probes to figure out when the listeners for the gateway are actually ready. For now the probe just hits the same internal envoy endpoint used for Consul health checking, but we could also potentially leverage the bound listeners themselves if we can manage to bind a listener with no upstreams at provision time.

  • build(deps): bump google.golang.org/grpc from 1.49.0 to 1.50.0

    build(deps): bump google.golang.org/grpc from 1.49.0 to 1.50.0

    Bumps google.golang.org/grpc from 1.49.0 to 1.50.0.

    Release notes

    Sourced from google.golang.org/grpc's releases.

    Release 1.50.0

    Behavior Changes

    • client: use proper "@" semantics for connecting to abstract unix sockets. (#5678)
      • This is technically a bug fix; the result is that the address was including a trailing NULL byte, which it should not have. This may break users creating the socket in Go by prefixing a NULL instead of an "@", though, so calling it out as a behavior change.

    New Features

    • metadata: add experimental ValueFromIncomingContext to more efficiently retrieve a single value (#5596)
    • stats: provide peer information in HandleConn context (#5589)
    • xds: add support for Outlier Detection, enabled by default (#5435, #5673)

    Bug Fixes

    • client: fix deadlock in transport caused by GOAWAY racing with stream creation (#5652)
      • This should only occur with an HTTP/2 server that does not follow best practices of an advisory GOAWAY (not a grpc-go server).
    • xds/xdsclient: fix a bug which was causing routes with cluster_specifier_plugin set to be NACKed when GRPC_EXPERIMENTAL_XDS_RLS_LB was off (#5670)
    • xds/xdsclient: NACK cluster resource if config_source_specifier in lrs_server is not self (#5613)
    • xds/ringhash: fix a bug which sometimes prevents the LB policy from retrying connection attempts (#5601)
    • xds/ringhash: do nothing when asked to exit IDLE instead of falling back on the default channel behavior of connecting to all addresses (#5614)
    • xds/rls: fix a bug which was causing the channel to be stuck in IDLE (#5656)
    • alts: fix a bug which was setting WaitForReady on handshaker service RPCs, thereby delaying fallback when required (#5620)
    • gcp/observability: fix End() to cleanup global state correctly (#5623)
    Commits
    • c1d7d7a Change version to 1.50.0 (#5685)
    • 1451c62 internal/transport: optimize grpc-message encoding/decoding (#5654)
    • be4b63b test: minor test cleanup (#5679)
    • d83070e Changed Outlier Detection Env Var to default true (#5673)
    • 54521b2 client: remove trailing null from unix abstract socket address (#5678)
    • 36e4810 orca: cleanup old code, and get grpc package to use new code (#5627)
    • e8866a8 build: harden GitHub Workflow permissions (#5660)
    • 8458251 xdsclient: ignore routes with cluster_specifier_plugin when GRPC_EXPERIMENTAL...
    • a238ceb xDS: Outlier Detection Env Var not hardcoded to false (#5664)
    • b1d7f56 transport: Fix deadlock in transport caused by GOAWAY race with new stream cr...
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • Trigger CRT workflows for main branch

    Trigger CRT workflows for main branch

    Changes proposed in this PR:

    • Add main to the list of branches that trigger Common Release Tooling workflows. This will produce the dev_tags images of consul-api-gateway defined here onto hashicorppreview whenever we push commits to main. Matches what Consul is doing here.
    • Change CRT notification target to different Slack channel where the additional noise created by merges to main won't interrupt our daily conversations.
    • Publish mutable + immutable dev_tags so that we can always test with a specific image even after newer versions have been published. I used the naming patterns from Consul's hashicorppreview repo here.
    • Change version.go to reflect our next release, 0.3.0, so that dev tags reflect the in-progress work correctly

    How I've tested this PR:

    There's not a good way to test this change without having the modified actions file merged into main, but the stakes are very low since we're only modifying our own internal process.

    How I expect reviewers to test this PR:

    Checklist:

    • [ ] Tests added
    • [ ] CHANGELOG entry added

      Run make changelog-entry for guidance in authoring a changelog entry, and commit the resulting file, which should have a name matching your PR number. Entries should use imperative present tense (e.g. Add support for...)

  • Enable namespace mapping for gateway service registration and future mesh service lookup

    Enable namespace mapping for gateway service registration and future mesh service lookup

    This PR introduces namespace mapping similar to the options allowed in our consul-k8s helm chart:

    https://www.consul.io/docs/k8s/helm#v-synccatalog-consulnamespaces

    In order to simplify our proposed MeshService CRD to rely on the same namespace mapping security posture as consul-k8s we essentially need to support the same k8s --> consul namespace mappings that they do. This allows k8s namespace-based RBAC policies to control access to particular consul-namespace services.

    By doing this for the future MeshService CRD it essentially means we just need a consul service name and the consul namespace will be constructed based off of the k8s namespace that the CRD resource is created in.

    Prior to this all gateways were just created in the default namespace, this also fixes that.

  • Bump k8s.io/api from 0.22.1 to 0.24.2

    Bump k8s.io/api from 0.22.1 to 0.24.2

    Bumps k8s.io/api from 0.22.1 to 0.24.2.

    Commits
    • 7e99a1e Update dependencies to v0.24.2 tag
    • 0bf1867 Revert "Introduce APIs to support multiple ClusterCIDRs (#108290)"
    • 2de6996 Merge pull request #109241 from ravisantoshgudimetla/sts-ar-optional
    • 7734d26 [sts] api: Make available replicas optional
    • 38ec09a [sts] Generated: Make available replicas optional
    • ec84bcb Merge pull request #109178 from liggitt/openapi-master
    • e3797f2 Drop enum tag from certificate request condition
    • 02c2207 Merge pull request #109151 from Argh4k/r-101566
    • 1eb735b Revert "Field status.hostIPs added for Pod (#101566)"
    • 290a349 Introduce APIs to support multiple ClusterCIDRs (#108290)
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • URLRewrite support

    URLRewrite support

    Is your feature request related to a problem? Please describe.

    HTTPRoute URLRewrite filter support is a deal breaker for the company I work for. I have tried to use it following Gateway API spec, but had no success.

    The supported features doc does not confirm support as well.

    Is it actually supported or planned?

    Feature Description

    Use Case(s)

    Given that "/orders" redirect to order service When I reach "/orders/10" Then orders service request path must be "/10" And request path should not have "/orders" prefix

    apiVersion: gateway.networking.k8s.io/v1alpha2
    kind: HTTPRoute
    metadata:
      name: orders
      namespace: consul
    spec:
      parentRefs:
      - name: api-gateway
      rules:
        - matches:
            - path:
                type: PathPrefix
                value: /orders
          backendRefs:
            - kind: Service
              name: orders
              namespace: orders
              port: 80
              weight: 100
          filters:
            - type: URLRewrite
              urlRewrite:
                path:
                  type: replacePrefixMatch
                  value: /orders
    

    Contributions

  • store: remove route from listener when not able to bind

    store: remove route from listener when not able to bind

    Changes proposed in this PR:

    Removes a route from a listener if it fails to bind when reconciling. Fixes an issue where deleting a ReferencePolicy would update the route status, but the stale route would not be removed from the gateway listener.

    As an aside, the (bool, error) return of CanBind seems redundant and makes it prone to misuse - should it be changed to just one of those values instead of the tuple?

    How I've tested this PR:

    • [x] Add checks for gateway listener status attachedRoutes after deleting ReferencePolicy in e2e test
    • [x] Add checks for TCP and HTTP connection errors after deleting ReferencePolicy in e2e test
    • [x] Add e2e test for switching route binding from one gateway to another

    How I expect reviewers to test this PR:

    • Review the test additions/changes.
    • Confirm that a gateway removes a stale route and stops routing traffic after a route is invalidated by being modified or having a ReferencePolicy that affects it deleted.
    • The checkRouteError function and only looking for an empty string TCP response feel like quite crude checks, is there a better way to handle these?
    • TestRouteParentRefChange contains the checks/assertions that are currently working as expected - I believe there's a different bug here still preventing some functionality from working as expected, but punted further exploration of that out to https://github.com/hashicorp/consul-api-gateway/pull/200
    • The debug logging I added in the helper funcs was quite helpful and I'm leaning towards wanting to keep it somehow, should it be switched to something like t.Log instead though?

    Checklist:

    • [x] Tests added
    • [x] CHANGELOG entry added

      Run make changelog-entry for guidance in authoring a changelog entry, and commit the resulting file, which should have a name matching your PR number. Entries should use imperative present tense (e.g. Add support for...)

  • Simplify comparison of gateways to use only resource version

    Simplify comparison of gateways to use only resource version

    We currently wind up with a stale gateway in memory that can't be written to the store when we want to update it.

    2022-03-15T17:56:05.165Z [ERROR] memory/store.go:110: consul-api-gateway-server.state: error syncing gateways:
      error=
      | 1 error occurred:
      | 	* Operation cannot be fulfilled on gateways.gateway.networking.k8s.io "backend-namespaces": the object has been modified; please apply your changes to the latest version and try again
      | 
    

    Due to this, the new route that's being added is unable to bind and thus the conformance tests fail.

    After adding some code using go-test/diff, I was able to determine the diff between the gateway Listeners() during the sync process:

    slice[0].gateway.ObjectMeta.Annotations.map[api-gateway.consul.hashicorp.com/config]:
    
    -{\"serviceType\":\"LoadBalancer\",\"consul\":{\"authentication\":{},\"scheme\":\"https\",\"ports\":{\"http\":8501,\"grpc\":8502}},\"image\":{\"consulAPIGateway\":\"gcr.io/hc-9b66efef4c6f4f9a85bcdbe92a9/consul-api-gateway-oss:16\",\"envoy\":\"envoyproxy/envoy-alpine:v1.20.2\"},\"copyAnnotations\":{},\"logLevel\":\"info\"}
    +{\"serviceType\":\"LoadBalancer\",\"consul\":{\"authentication\":{},\"scheme\":\"https\",\"ports\":{\"http\":8501,\"grpc\":8502}},\"image\":{\"consulAPIGateway\":\"gcr.io/hc-9b66efef4c6f4f9a85bcdbe92a9/consul-api-gateway-oss:17\",\"envoy\":\"envoyproxy/envoy-alpine:v1.20.2\"},\"copyAnnotations\":{},\"logLevel\":\"info\"}
    
    slice[0].routeCount:
    -1
    +0
    

    When the sync fails, it retries a couple of times and then goes silent. The gateway then never has the route listed in attached routes. Andrew mentioned that he doesn't think we want to dirty-check the route count, and I think we want the annotation config to be a snapshot of creation time. I'm not sure which of these is preventing the sync; however, including gateway.Listeners() in the isEqual comparison dirty-checks both implicitly and fixes the issue in my testing.

    Changes proposed in this PR:

    When determining if two gateways are equal during the sync process, only compare the resource version. This will prevent the list of things to compare from continually growing and requiring tons of mental overhead to figure out any bugs.

    How I've tested this PR:

    Running the upstream conformance tests against main will trigger the issue above. The only fix I've found is to delete the controller pod so that the stale gateway is dumped.

    How I expect reviewers to test this PR:

    Checklist:

    • [ ] Tests added
    • [ ] CHANGELOG entry added

      HashiCorp engineers only, community PRs should not add a changelog entry. Entries should use imperative present tense (e.g. Add support for...)

  • build(deps): bump github.com/hashicorp/consul/api from 1.15.3 to 1.16.0

    build(deps): bump github.com/hashicorp/consul/api from 1.15.3 to 1.16.0

    Bumps github.com/hashicorp/consul/api from 1.15.3 to 1.16.0.

    Commits
    • 05b4282 Update api submodule gomod.
    • d9d0d92 Backport of auto-config: relax node name validation for JWT authorization int...
    • 5d10221 Peering Mesh Gateway Updates for GA (#15344) (#15363)
    • 6f82a5e docs(peering): remove beta references (#15340) (#15362)
    • 329d111 backport of commit 87038bb6723a3433cccbd8b5cab68e3585d1a92a (#15364)
    • 6ca306f Backport of Ensure that NodeDump imported nodes are filtered into release/1.1...
    • 4d36fd1 backport of commit 33d521d9cee89cfe8dcd639a2047295d45351314 (#15357)
    • 54f7a79 Backport of Fixup authz for data imported from peers into release/1.14.x (#15...
    • 904aaf7 Backport of connect: strip port from DNS SANs for ingress gateway leaf cert i...
    • a6f4893 backport of commit cf529cfdabc87ced74ac8ab1ec85173667850d7a (#15350)
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • k8s/controller: always map

    k8s/controller: always map "default" Consul namespace to empty string

    Changes proposed in this PR:

    Always map the "default" Consul namespace to the empty string in the memory backend store, for compatibility with Consul OSS and the logic to parse the namespace of a Gateway from the SPIFFE URI, used when reading a Gateway from a store backend.

    This Consul namespace mapper function is already called when reconciling a Gateway to a backend store, but the corresponding lookup fails with Consul Enterprise when --consul-destination-namespace is set to "default" because of the special case handling in the parseURI helper.

    No migration handling should be needed because this is all within the ephemeral memory store for now, but this does need an e2e test for a service in the "default" namespace on Consul Enterprise.

    As a temporary workaround, this edge case can be avoided by configuring consulNamespaces.mirroringK8S: true or specfiying "" or any value other than "default" for consulNamespaces.consulDestinationNamespace in the Helm chart.

    How I've tested this PR:

    How I expect reviewers to test this PR:

    Checklist:

    • [x] Tests added
    • [x] CHANGELOG entry added

      Run make changelog-entry for guidance in authoring a changelog entry, and commit the resulting file, which should have a name matching your PR number. Entries should use imperative present tense (e.g. Add support for...)

  • build(deps): bump sigs.k8s.io/gateway-api from 0.5.1 to 0.6.0

    build(deps): bump sigs.k8s.io/gateway-api from 0.5.1 to 0.6.0

    Bumps sigs.k8s.io/gateway-api from 0.5.1 to 0.6.0.

    Release notes

    Sourced from sigs.k8s.io/gateway-api's releases.

    v0.6.0

    API versions: v1beta1, v1alpha2

    Major Changes

    ReferenceGrant moves to v1beta1, ReferencePolicy removed

    With more implementations now supporting ReferenceGrant (and more conformance coverage of the resource), we've moved ReferenceGrant to v1beta1 in this release. Note that moving to beta also moves the object to the Standard channel (it was Experimental previously).

    We've also removed the already-deprecated ReferencePolicy resource, so please move over to the shiny new ReferenceGrant, which has all the same features.

    • Promotes ReferenceGrant to the v1beta1 API and the standard release channel (#1455, @​nathancoleman)
    • ReferencePolicy has been removed from the API in favor of ReferenceGrant. (#1406, @​robscott)

    Introduce GRPCRoute

    The GRPCRoute resource has been introduced in order to simplify the routing of GRPC requests. Its design is described in GEP-1016. As it is a new resource, it is introduced in the experimental channel.

    Thanks to @​gnossen for pushing this ahead.

    Status updates

    As described in GEP-1364, status conditions have been updated within the Gateway resource to make it more consistent with the rest of the API. These changes, along with some other status changes, are detailed below.

    Gateway:

    • New Accepted and Programmed conditions introduced.
    • Scheduled condition deprecated.
    • Core Conditions now Accepted and Programmed.
    • Moves to Extended: Ready.

    Gateway Listener:

    • New Accepted and Programmed conditions introduced.
    • Detached condition deprecated.
    • Core Conditions now Accepted, Programmed, ResolvedRefs, and Conflicted.
    • Moves to Extended: Ready.

    All Resources:

    • The Accepted Condition now has a Pending reason, which is the default until the condition is updated by a controller.

    Route resources:

    ... (truncated)

    Changelog

    Sourced from sigs.k8s.io/gateway-api's changelog.

    v0.6.0

    Major Changes

    ReferenceGrant moves to v1beta1, ReferencePolicy removed

    With more implementations now supporting ReferenceGrant (and more conformance coverage of the resource), we've moved ReferenceGrant to v1beta1 in this release. Note that moving to beta also moves the object to the Standard channel (it was Experimental previously).

    We've also removed the already-deprecated ReferencePolicy resource, so please move over to the shiny new ReferenceGrant, which has all the same features.

    • Promotes ReferenceGrant to the v1beta1 API and the standard release channel (#1455, @​nathancoleman)
    • ReferencePolicy has been removed from the API in favor of ReferenceGrant. (#1406, @​robscott)

    Introduce GRPCRoute

    The GRPCRoute resource has been introduced in order to simplify the routing of GRPC requests. Its design is described in GEP-1016. As it is a new resource, it is introduced in the experimental channel.

    Thanks to @​gnossen for pushing this ahead.

    Status updates

    As described in GEP-1364, status conditions have been updated within the Gateway resource to make it more consistent with the rest of the API. These changes, along with some other status changes, are detailed below.

    Gateway:

    • New Accepted and Programmed conditions introduced.
    • Scheduled condition deprecated.
    • Core Conditions now Accepted and Programmed.
    • Moves to Extended: Ready.

    Gateway Listener:

    • New Accepted and Programmed conditions introduced.
    • Detached condition deprecated.
    • Core Conditions now Accepted, Programmed, ResolvedRefs, and Conflicted.
    • Moves to Extended: Ready.

    All Resources:

    • The Accepted Condition now has a Pending reason, which is the default until the condition is updated by a controller.

    Route resources:

    ... (truncated)

    Commits
    • 6c222d3 chore: update default version to v0.6.0
    • ca470e2 Merge pull request #1614 from shaneutt/shaneutt/v0.6.0-changelog
    • 9522bd0 docs: add v0.6.0 changelog entry
    • 6a8738a Merge pull request #1594 from youngnick/973-fix
    • 05fa505 Update wording on ParentRef field to require AllowedRoutes or ReferenceGrant
    • dc314b1 Assert observedGeneration is incremented in Status.Conditions. (#1586)
    • 9c9429a Merge pull request #1609 from frankbu/impl/istio
    • 889b226 Merge pull request #1608 from shaneutt/shaneutt/release-v060-rc2
    • 91d868b chore: update webhook version in build hacks
    • 3c693e0 fix link target
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • build(deps): bump sigs.k8s.io/controller-runtime from 0.13.1 to 0.14.1

    build(deps): bump sigs.k8s.io/controller-runtime from 0.13.1 to 0.14.1

    Bumps sigs.k8s.io/controller-runtime from 0.13.1 to 0.14.1.

    Release notes

    Sourced from sigs.k8s.io/controller-runtime's releases.

    v0.14.1

    Changes since v0.14.0

    :bug: Bug Fixes

    Full Changelog: https://github.com/kubernetes-sigs/controller-runtime/compare/v0.14.0...v0.14.1

    v0.14.0

    Changes since v0.13.1

    :warning: Breaking Changes

    • Add Get functionality to SubResourceClient (#2094)
    • Allow configuring RecoverPanic for controllers globally (#2093)
    • Add client.SubResourceWriter (#2072)
    • Support registration and removal of event handler (#2046)
    • Update Kubernetes dependencies to v0.26 (#2043, #2087)
    • Zap log: Default to RFC3339 time encoding (#2029)
    • cache.BuilderWithOptions inherit options from caller (#1980)

    :sparkles: New Features

    • Builder: Do not require For (#2091)
    • support disable deepcopy on list funcion (#2076)
    • Add cluster.NewClientFunc with options (#2054)
    • Tidy up startup logging of kindWithCache source (#2057)
    • Add function to get reconcileID from context (#2056)
    • feat: add NOT predicate (#2031)
    • Allow to provide a custom lock interface to manager (#2027)
    • Add tls options to manager.Options (#2023)
    • Update Go version to 1.19 (#1986)

    :bug: Bug Fixes

    • Prevent manager from getting started a second time (#2090)
    • Missing error log for in-cluster config (#2051)
    • Skip custom mutation handler when delete a CR (#2049)
    • fix: improve semantics of combining cache selectorsByObject (#2039)
    • Conversion webhook should not panic when conversion request is nil (#1970)

    :seedling: Others

    • Prepare for release 0.14 (#2100)
    • Generate files and update modules (#2096)
    • Bump github.com/onsi/ginkgo/v2 from 2.5.1 to 2.6.0 (#2097)
    • Bump golang.org/x/time (#2089)
    • Update OWNERS: remove inactive members, promote fillzpp sbueringer (#2088, #2092)
    • Default ENVTEST version to a working one (1.24.2) (#2081)
    • Update golangci-lint to v1.50.1 (#2080)
    • Bump go.uber.org/zap from 1.23.0 to 1.24.0 (#2077)
    • Bump golang.org/x/sys from 0.2.0 to 0.3.0 (#2078)
    • Ignore Kubernetes Dependencies in Dependabot (#2071)

    ... (truncated)

    Commits
    • 84c5c9f 🐛 controllers without For() fail to start (#2108)
    • ddcb99d Merge pull request #2100 from vincepri/release-0.14
    • 69f0938 Merge pull request #2094 from alvaroaleman/subresoruce-get
    • 8738e91 Merge pull request #2091 from alvaroaleman/no-for
    • ca4b4de Merge pull request #2096 from lucacome/generate
    • 5673341 Merge pull request #2097 from kubernetes-sigs/dependabot/go_modules/github.co...
    • 7333aed :seedling: Bump github.com/onsi/ginkgo/v2 from 2.5.1 to 2.6.0
    • d4f1e82 Generate files and update modules
    • a387bf4 Merge pull request #2093 from alvaroaleman/recover-panic-globally
    • da7dd5d :warning: Allow configuring RecoverPanic for controllers globally
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • build(deps): bump github.com/docker/docker from 20.10.21+incompatible to 20.10.22+incompatible

    build(deps): bump github.com/docker/docker from 20.10.21+incompatible to 20.10.22+incompatible

    Bumps github.com/docker/docker from 20.10.21+incompatible to 20.10.22+incompatible.

    Commits
    • 42c8b31 Merge pull request #44656 from thaJeztah/20.10_containerd_binary_1.6.13
    • ff29c40 update containerd binary to v1.6.13
    • 0234322 Merge pull request #44488 from thaJeztah/20.10_backport_update_gotestsum
    • edca413 [20.10] update gotestsum to v1.8.2
    • 6112b23 Merge pull request #44476 from sbuckfelder/20.10_UPDATE
    • 194e73f Merge pull request #44607 from thaJeztah/20.10_containerd_binary_1.6.12
    • a9fdcd5 [20.10] update containerd binary to v1.6.12 (addresses CVE-2022-23471)
    • 48f955d Merge pull request #44597 from thaJeztah/20.10_containerd_1.6.11
    • 50d4d98 Merge pull request #44569 from thaJeztah/20.10_backport_relax_checkSupportedM...
    • 17451d2 Merge pull request #44593 from thaJeztah/20.10_update_go_1.18.9
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • build(deps): bump k8s.io/apiextensions-apiserver from 0.25.4 to 0.26.0

    build(deps): bump k8s.io/apiextensions-apiserver from 0.25.4 to 0.26.0

    Bumps k8s.io/apiextensions-apiserver from 0.25.4 to 0.26.0.

    Commits
    • ec9ebd7 Update dependencies to v0.26.0 tag
    • 6e13726 Merge remote-tracking branch 'origin/master' into release-1.26
    • c338f3e Update golang.org/x/net 1e63c2f
    • 9768bad sync: update go.mod
    • f9c2bba fix aggregated discovery version sorting
    • d2c9e18 Merge pull request #113171 from Jefftree/aggregated-discovery-generic
    • 470c040 Merge pull request #113577 from pacoxu/prometheus-client
    • 915a888 add crds to aggregated discovery
    • ac326ca upgrade prometheus-client to v1.14.0
    • 92430b6 Merge pull request #113314 from cici37/celIntegration
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • Parsing Resource Version Is Not Allowed

    Parsing Resource Version Is Not Allowed

    Overview of the Issue

    The Kubernetes API explicitly disallows parsing the metadata.resourceVersion field on an object as an integer. This project, however, does so as of this commit: https://github.com/hashicorp/consul-api-gateway/pull/26/commits/cb0486e386552b24f74a457df00680785d75a2b7

    During a review of code that would be affected by non-numerical resourceVersions, I came upon this code. I'm hoping to better understand what this codebase is using the parsing logic for and if there are other means to that end without using non-supported API behavior. I can see that uses of the parsing seem to all be in precondition functions passed to Upsert* methods on a store. This looks analogous to the resource version precondition provided by the Kubernetes API server, but the only implementation of the store I found was an in-memory one here - so I'm not entirely sure how the Kubernetes client and server get involved here.

Rpcx-framework - An RPC microservices framework based on rpcx, simple and easy to use, ultra fast and efficient, powerful, service discovery, service governance, service layering, version control, routing label registration.

RPCX Framework An RPC microservices framework based on rpcx. Features: simple and easy to use, ultra fast and efficient, powerful, service discovery,

Jan 5, 2022
Ruuvi-go-gateway - Software replica of the Ruuvi Gateway

ruuvi-go-gateway ruuvi-go-gateway is a software that tries to replicate Ruuvi Ga

Dec 21, 2022
Automatic Service Mesh and RPC generation for Go micro services, it's a humble alternative to gRPC with Istio.
Automatic Service Mesh and RPC generation for Go micro services, it's a humble alternative to gRPC with Istio.

Mesh RPC MeshRPC provides automatic Service Mesh and RPC generation for Go micro services, it's a humble alternative to gRPC with Istio. In a nutshell

Aug 22, 2022
EaseMesh is a service mesh that is compatible with the Spring Cloud ecosystem.
EaseMesh is a service mesh that is compatible with the Spring Cloud ecosystem.

A service mesh implementation for connecting, control, and observe services in spring-cloud.

Jan 4, 2023
Meshery, the service mesh management plane
Meshery, the service mesh management plane

Meshery is the multi-service mesh management plane offering lifecycle, configuration, and performance management of service meshes and their workloads.

Jan 5, 2023
Use eBPF to speed up your Service Mesh like crossing an Einstein-Rosen Bridge.

merbridge Use eBPF to speed up your Service Mesh like crossing an Einstein-Rosen Bridge. Usage Install You just only need to run the following command

Jan 1, 2023
A microservice gateway developed based on golang.With a variety of plug-ins which can be expanded by itself, plug and play. what's more,it can quickly help enterprises manage API services and improve the stability and security of API services.
A microservice gateway developed based on golang.With a variety of plug-ins which can be expanded by itself, plug and play. what's more,it can quickly help enterprises manage API services and improve the stability and security of API services.

Goku API gateway is a microservice gateway developed based on golang. It can achieve the purposes of high-performance HTTP API forwarding, multi tenant management, API access control, etc. it has a powerful custom plug-in system, which can be expanded by itself, and can quickly help enterprises manage API services and improve the stability and security of API services.

Dec 29, 2022
Search-gateway - Golang restfull Service

Search Gateway Specifications Gin framework Development PORT=3000 go run main.go

Jan 25, 2022
Wrapper to easily generate "X-Request-Auth" header for Mesh sites in golang.

hawk mesh go ?? ?? Description Wrapper to easily generate "X-Request-Auth" header for Mesh sites in golang. Based on hawk-go. Getting Started Import t

Dec 4, 2022
Golang 微服务框架,支持 grpc/http,支持多种注册中心 etcd,consul,mdns 等

一个用于构建分布式系统的工具集或者轻框架,支持 grpc 和 http ,支持多种注册中心 consul ,etcd , mdns 等。

Nov 30, 2022
HTTP API Gateway
HTTP API Gateway

Manba/简体中文 Manba is a restful API gateway based on HTTP, which can be used as a unified API access layer. Tutorial A very detailed tutorial for beginn

Dec 29, 2022
This is a shopping basket workshop that shows how to use KrakenD API Gateway.
This is a shopping basket workshop that shows how to use KrakenD API Gateway.

Go Restful Microservices and KrakenD API Gateway Workshop This is a shopping basket workshop that shows how to use KrakenD API Gateway. Consist of 5 m

Jan 3, 2023
Test your API gateway routed lambdas locally and in CI
Test your API gateway routed lambdas locally and in CI

Lambo Test API Gateway wrapped lambda functions locally. Lambo can also be used to test API GW lambdas in CI without needing docker-in-docker. It will

Jun 22, 2022
a simple api gateway

鉴权网关 根据登录接口返回UIN判断是否登录/退出成功 自动添加跨域处理 会话重启即失效 TLS鉴权 负载均衡 随机 Config # 开启验证 enable_verify: false # 验证证书 ca_path: "./conf/ca.pem" module_cert_pem: "./conf

Feb 10, 2022
A gateway to expose s3 standard API for any storage type.

s3-gateway this project is used to be compatible with any other storage type. there are tons of object storage services in the internat. However, many

Nov 28, 2021
A simple HTTP/HTTPS API Gateway in Golang.
A simple HTTP/HTTPS API Gateway in Golang.

mice A simple API Gateway in Golang. Installation: Using go install: First install Go, if not already there Set GOPATH and GOBIN if not already set as

May 19, 2022
Easegress (formerly known as EaseGateway)is an all-rounder traffic orchestration system
Easegress (formerly known as EaseGateway)is an all-rounder traffic orchestration system

Easegress (formerly known as EaseGateway)is an all-rounder traffic orchestration system

Dec 28, 2022
A controller(CES) for controlling container egress traffic. Working with F5 AFM.
A controller(CES) for controlling container egress traffic. Working with F5 AFM.

Container Egress Services (CES) Kubernetes is piloting projects transition to enterprise-wide application rollouts, companies must be able to extend t

Oct 18, 2022
TiDB Gateway

TiDB Gateway Building go build Running ./tidbgw Optionally set the address of PD and address to listen on via flags. Using Connect your MySQL client

Jul 15, 2022