After upgrading Envoy Gateway from v1.4.2 to v1.5.0, duplicate dataplane Deployments and Services are created

[lideheng6379-del]

I'm encountering a problem after upgrading Envoy Gateway in my Kubernetes cluster. Here’s the detailed scenario:

1. Installation and Initial State
I installed Envoy Gateway v1.4.2 with the following helm command:

helm install eg eqchen-test-test/gateway-helm
--version 1.4.2
-n envoy-gateway-system
--set deployment.replicas=2
--set config.envoyGateway.extensionApis.enableBackend=true
--set config.envoyGateway.provider.kubernetes.deploy.type=GatewayNamespace

I then deployed these resources (simplified):

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyProxy
metadata:
name: proxy-config
namespace: test
spec:
provider: ...

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyProxy
metadata:
name: proxy-config1
namespace: test
spec:
provider: ...

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
name: gwc
spec:
controllerName: gateway.envoyproxy.io/gatewayclass-controller
parametersRef:
group: gateway.envoyproxy.io
kind: EnvoyProxy
name: proxy-config
namespace: test

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
name: gwc1
spec:
controllerName: gateway.envoyproxy.io/gatewayclass-controller
parametersRef:
group: gateway.envoyproxy.io
kind: EnvoyProxy
name: proxy-config1
namespace: test

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: gw1
namespace: test
spec:
gatewayClassName: gwc

...

---

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: gw2
namespace: test
spec:
gatewayClassName: gwc1

...

After applying these, the deployments and services looked like this (outputs simplified):

kubectl get deploy -n test

envoy-test-gw1-xxxxx

envoy-test-gw2-yyyyy

kubectl get svc -n test

envoy-test-gw1-xxxxx (LoadBalancer)

gateway (ClusterIP)

kubectl get po -n test

envoy-test-gw1-a2ce1d2b-6c694c99bd-jpz82

envoy-test-gw2-5f960ea9-79c95f6c8-gkqwj

2. Upgrade Step
I then upgraded Envoy Gateway with:

helm upgrade eg eqchen-test-test/gateway-helm
--version 1.5.0
-n envoy-gateway-system
--set deployment.replicas=2
--set config.envoyGateway.extensionApis.enableBackend=true
--set config.envoyGateway.provider.kubernetes.deploy.type=GatewayNamespace

3. Unexpected Result
After the upgrade, I noticed two sets of dataplane Deployments and Services:

kubectl get deploy -n test

envoy-test-gw1-xxxxx

envoy-test-gw2-yyyyy

gw1

gw2

kubectl get svc -n test

envoy-test-gw1-xxxxx (LoadBalancer)

gateway (ClusterIP)

gw1 (LoadBalancer)

kubectl get pod -n test

envoy-test-gw1-a2ce1d2b-6c694c99bd-jpz82

envoy-test-gw2-5f960ea9-79c95f6c8-gkqwj

gw1-6d86f7774c-dn9qn

gw2-849c8f89f-6lwhh

Question
Why did the upgrade cause duplicate Deployments/Services (with both the old envoy-test-gw1-, envoy-test-gw2- and new gw1, gw2 resources), instead of reusing or updating the existing ones?

[arkodg]

the deployment name has changed to use the gateway name for gateway namespace mode
https://gateway.envoyproxy.io/news/releases/v1.5/#-breaking-changes

closing this as gateway namespace mode was in alpha in v1.4.2 and there are no plans to support seamless upgrades for gateway namespace mode from v1.4 to v1.5

[lideheng6379-del]

Hi, I have another question I would like to ask you:

I installed Envoy Gateway via Helm with the following command (version 1.4.0):

helm install eg eqchen-test-test/gateway-helm
--version 1.4.0
-n envoy-gateway-system
--set deployment.replicas=2
--set config.envoyGateway.extensionApis.enableBackend=true

Then I upgraded to version 1.5.0 with:

helm install eg eqchen-test-test/gateway-helm
--version 1.5.0
-n envoy-gateway-system
--set deployment.replicas=2
--set config.envoyGateway.extensionApis.enableBackend=true

After that, I rolled back to the previous 1.4.0 release with:

helm rollback eg -n envoy-gateway-system

My question:

After rolling back, will the custom values I set during the initial 1.4.0 install (like deployment.replicas=2 and config.envoyGateway.extensionApis.enableBackend=true) be retained? Or will they be reset to the chart’s default values?

What is the production best practice for rolling back a Helm release to a previous version, especially regarding the preservation of custom values?