Describe the bug
When configuring Knative Serving with the structured format for local-gateways (the recommended approach), the operator ignores the namespace field and tries to create the knative-local-gateway service in the istio-system namespace by default, instead of the namespace specified (eg. aks-istio-ingress). Only the legacy local-gateway.* key works as expected. This results in errors like:
failed to apply non rbac manifest: namespaces "istio-system" not found
If the istio-system namespace is manually created, the service appears in the wrong namespace, not the user-specified one in local-gateways.
Expected behavior
The operator should respect the namespace value in the structured array local-gateways in the istio config and create the service in that namespace. The legacy and structured config should produce the same behavior.
To Reproduce
- Deploy a KnativeServing with this config:
apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
name: knative-serving
namespace: knative-serving
spec:
ingress:
istio:
enabled: true
knative-local-gateway:
selector:
app: aks-istio-ingressgateway-internal
config:
istio:
local-gateways: |
- name: knative-local-gateway
namespace: knative-serving
service: knative-local-gateway.aks-istio-ingress.svc.cluster.local
- Observe the event:
failed to apply non rbac manifest: namespaces "istio-system" not found
- Creating the
istio-system namespace causes the service to be created there (not in aks-istio-ingress).
Knative release version
v1.19
Additional context
- It appears to be caused by the operator's
UpdateNamespace function (pkg/reconciler/knativeserving/ingress/ingress_service.go), which only checks for the legacy key to set the namespace and ignores the array format.
- This breaks on platforms like AKS with Istio add-on, where gateways are deployed in their own namespaces (eg.
aks-istio-ingress).
- Using the legacy configuration:
local-gateway.knative-serving.knative-local-gateway: knative-local-gateway.aks-istio-ingress.svc.cluster.local the knative-local-gateway service gets created in aks-istio-ingress namespace as expected.
Describe the bug
When configuring Knative Serving with the structured format for
local-gateways(the recommended approach), the operator ignores thenamespacefield and tries to create theknative-local-gatewayservice in theistio-systemnamespace by default, instead of the namespace specified (eg.aks-istio-ingress). Only the legacylocal-gateway.*key works as expected. This results in errors like:If the
istio-systemnamespace is manually created, the service appears in the wrong namespace, not the user-specified one inlocal-gateways.Expected behavior
The operator should respect the
namespacevalue in the structured arraylocal-gatewaysin the istio config and create the service in that namespace. The legacy and structured config should produce the same behavior.To Reproduce
failed to apply non rbac manifest: namespaces "istio-system" not foundistio-systemnamespace causes the service to be created there (not inaks-istio-ingress).Knative release version
v1.19
Additional context
UpdateNamespacefunction (pkg/reconciler/knativeserving/ingress/ingress_service.go), which only checks for the legacy key to set the namespace and ignores the array format.aks-istio-ingress).local-gateway.knative-serving.knative-local-gateway:knative-local-gateway.aks-istio-ingress.svc.cluster.localtheknative-local-gatewayservice gets created inaks-istio-ingressnamespace as expected.