[
https://issues.apache.org/jira/browse/FLINK-29131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605379#comment-17605379
]
Dylan Meissner commented on FLINK-29131:
----------------------------------------
I've abandoned my original approach due to the invasiveness of host networking
on the operator pod. Referencing [the Helm chart for
cert-manager|[https://github.com/cert-manager/cert-manager/blob/release-1.9/deploy/charts/cert-manager/values.yaml#L342-L351]]
it seems a good approach is to separate the webhook container into its own
pod. I did successfully after specifying `webhook: \{create: false}` and
separately creating the webhook as its own deployment.
Applying this strategy to Helm chart is a large undertaking may warrant a FLIP.
> Kubernetes operator webhook can use hostPort
> --------------------------------------------
>
> Key: FLINK-29131
> URL: https://issues.apache.org/jira/browse/FLINK-29131
> Project: Flink
> Issue Type: Improvement
> Components: Kubernetes Operator
> Affects Versions: kubernetes-operator-1.1.0
> Reporter: Dylan Meissner
> Assignee: Dylan Meissner
> Priority: Major
> Fix For: kubernetes-operator-1.2.0
>
>
> When running Flink operator on EKS cluster with Calico networking the
> control-plane (managed by AWS) cannot reach the webhook. Requests to create
> Flink resources fail with {_}Address is not allowed{_}.
> When the webhook listens on hostPort the requests to create Flink resources
> are successful. However, a pod security policy is generally required to allow
> webhook to listen on such ports.
> To support this scenario with the Helm chart make changes so that we can
> * Specify a hostPort value for the webhook
> * Name the port that the webhook listens on
> * Use the named port in the webhook service
> * Add a "use" pod security policy verb to cluster role
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
