Breaking changes

Envoy v3 config API is now the default #112. If you are using v2 configurations you must either upgrade them to v3 before upgrading the operator or explicitly set v2 in both your EnvoyConfigs and Pod annotations to continue using v2.
Envoy 1.18.3 is now the default #105. You must explicitly set the Envoy version if you want to avoid upgrading or use a different version. Note that the last Envoy release supporting the v2 config API is v1.16.

New features

Added new resource EnvoyDeployment to deploy Envoy as a kubernetes Deployment #89 #92.
Added validation of EnvoyConfig resources #79.
Added the shutdown manager to handle connection draining upon termination of Envoy containers #95 #111 #113.
The Envoy static configuration required to provide the initial configuration for Envoy to talk to the discovery service is now generated in an init container. This init container also adds Pod metadata that can then be interpreted by the discovery service. The usage of a shared ConfigMap to do this has been deprecated. This change is transparent to the user and no changes are required. #100 #110 .
Each Envoy resource type is now internally versioned separately by the discovery service. This improves performance as reduces the number of resource changes that the discovery service sends to the Envoy clients. #101 .
Refactored the self-healing capabilities using Pod metadata that is now available to the controllers to make the self-healing much more robust #102.

Field spec.envoyResources.secrets.[*].ref is now optional in EnvoyConfig resources #61.
Fix some panics coming from operator-utils library #93 #108 operator-utils#69 operator-utils#68.
Move subcommands into a different package #97.
Fix webhook in multi-namespaced install mode #103.
Fix the file-based SDS tls secret response used in Envoy's static configuration in Envoy v1.17+ #104 (thanks @acnodal-tc ).