Skip to content

Emissary Ingress 2.3.0
Compare
Choose a tag to compare
@d6e-automaton d6e-automaton released this 06 Jun 19:12
· 977 commits to master since this release
v2.3.0
c079729

🎉 Emissary Ingress 2.3.0 🎉

Emissary Ingress is an open source, Kubernetes-native microservices API gateway built on the Envoy Proxy.

Upgrade Emissary - https://www.getambassador.io/reference/upgrading.html
View changelog - https://github.com/emissary-ingress/emissary/blob/v2.3.0/CHANGELOG.md
Get started with Emissary on Kubernetes - https://www.getambassador.io/user-guide/getting-started

  • Security: Completely remove gdbm, pip, smtplib, and sqlite packages, as they are unused.

  • Feature: It is now possible to set propagation_modes in the TracingService config when using
    lightstep as the driver. (Thanks to Paul!) (#4179)

  • Feature: It is now possible to set crl_secret in Host and TLSContext resources to check peer
    certificates against a certificate revocation list. (#1743)

  • Feature: Previously, a LogService would always have Emissary-ingress communicate with the
    external log service using the envoy.service.accesslog.v2.AccessLogService API. It is now
    possible for the LogService to specify protocol_version: v3 to use the newer
    envoy.service.accesslog.v3.AccessLogService API instead. This functionality is not available if
    you set the AMBASSADOR_ENVOY_API_VERSION=V2 environment variable.

  • Bugfix: When CORS is specified (either in a Mapping or in the Ambassador Module), CORS
    processing will happen before authentication. This corrects a problem where XHR to authenticated
    endpoints would fail.

  • Bugfix: In 2.x releases of Emissary-ingress when there are multiple Mappings that have the same
    metadata.name across multiple namespaces, their old config would not properly be removed from
    the cache when their config was updated. This resulted in an inability to update configuration for
    groups of Mappings that share the same name until the Emissary-ingress pods restarted.

  • Bugfix: It is now possible for a TracingService to specify collector_endpoint_version: HTTP_JSON_V1 when using xDS v3 to configure Envoy (which has been the default since
    Emissary-ingress 1.14.0). The HTTP_JSON_V1 value configures Envoy to speak to Zipkin using
    Zipkin's old API-v1, while the HTTP_JSON value configures Envoy to speak to Zipkin using
    Zipkin's new API-v2. In previous versions of Emissary-ingress it was only possible to use
    HTTP_JSON_V1 when explicitly setting the AMBASSADOR_ENVOY_API_VERSION=V2 environment variable
    to force use of xDS v2 to configure Envoy.

Assets 2
Loading