[ 
https://issues.apache.org/jira/browse/FLINK-32041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Otto updated FLINK-32041:
--------------------------------
    Description: 
When enabling [HA for 
flink-kubernetes-operator|https://nightlies.apache.org/flink/flink-kubernetes-operator-docs-main/docs/operations/configuration/#leader-election-and-high-availability]
 RBAC rules must be created to allow the flink-operator to manage k8s Lease 
resources.  When not using {{{}watchNamespaces{}}}, the RBAC rules are created 
at the k8s cluster level scope, giving the flink-operator ServiceAccount the 
ability to manage all needed k8s resources for all namespaces.

However, when using {{{}watchNamespaces{}}}, RBAC rules are only created in the 
{{{}watchNamepaces{}}}.  For most rules, this is correct, as the operator needs 
to manage resources like Flink pods and deployments in the 
{{{}watchNamespaces{}}}.  

However, For flink-kubernetes-operator HA, the Lease resource is managed in the 
same namespace in which the operator is deployed.  

The Helm chart should be fixed so that the proper RBAC rules for Leases are 
created to allow the operator's ServiceAccount in the operator's namespace.

Mailing list discussion 
[here.|https://lists.apache.org/thread/yq89jm0szkcodfocm5x7vqnqdmh0h1l0]

  was:
When enabling [HA for 
flink-kubernetes-operator|https://nightlies.apache.org/flink/flink-kubernetes-operator-docs-main/docs/operations/configuration/#leader-election-and-high-availability]
 a RBAC rules must be created to allow the flink-operator to manage k8s Lease 
resources.  When not using watchNamespaces, the RBAC rules are created at the 
k8s cluster level scope, giving the flink-operator ServiceAccount the ability 
to manage all needed k8s resources for all namespaces.

However, when using watchNamespaces, RBAC rules are only created in the 
watchNamepaces.  For most rules, this is correct, as the operator needs to 
manage resources like Flink pods and deployments in the watchNamespaces.  

However, For flink-kubernetes-operator HA, the Lease resource is managed in the 
same namespace in which the operator is deployed.  

The Helm chart should be fixed so that the proper RBAC rules for Leases are 
created to allow the operator's ServiceAccount in the operator's namespace.

Mailing list discussion 
[here.|https://lists.apache.org/thread/yq89jm0szkcodfocm5x7vqnqdmh0h1l0]


> flink-kubernetes-operator RoleBinding for Leases not created in correct 
> namespace when using watchNamespaces
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: FLINK-32041
>                 URL: https://issues.apache.org/jira/browse/FLINK-32041
>             Project: Flink
>          Issue Type: Bug
>          Components: Kubernetes Operator
>    Affects Versions: kubernetes-operator-1.4.0
>            Reporter: Andrew Otto
>            Priority: Major
>
> When enabling [HA for 
> flink-kubernetes-operator|https://nightlies.apache.org/flink/flink-kubernetes-operator-docs-main/docs/operations/configuration/#leader-election-and-high-availability]
>  RBAC rules must be created to allow the flink-operator to manage k8s Lease 
> resources.  When not using {{{}watchNamespaces{}}}, the RBAC rules are 
> created at the k8s cluster level scope, giving the flink-operator 
> ServiceAccount the ability to manage all needed k8s resources for all 
> namespaces.
> However, when using {{{}watchNamespaces{}}}, RBAC rules are only created in 
> the {{{}watchNamepaces{}}}.  For most rules, this is correct, as the operator 
> needs to manage resources like Flink pods and deployments in the 
> {{{}watchNamespaces{}}}.  
> However, For flink-kubernetes-operator HA, the Lease resource is managed in 
> the same namespace in which the operator is deployed.  
> The Helm chart should be fixed so that the proper RBAC rules for Leases are 
> created to allow the operator's ServiceAccount in the operator's namespace.
> Mailing list discussion 
> [here.|https://lists.apache.org/thread/yq89jm0szkcodfocm5x7vqnqdmh0h1l0]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to