[GitHub] [pulsar-helm-chart] michaeljmarshall commented on issue #110: Pulsar proxy fails to start with pulsar Docker image that uses non-root user

[GitBox <gi...@apache.org>]

michaeljmarshall commented on issue #110:
URL: https://github.com/apache/pulsar-helm-chart/issues/110#issuecomment-845501809


   @sijie and @lhotari - what are your thoughts here? It'd be good to solve this soon so that it doesn't affect end users when we release 2.8.0 soon.
   
   I see a couple options.
   
   1. We could add a value for the `targetPort` on the pulsar proxy service where the `targetPort` defaults to `8080`. In this case, we could update the template for the proxy service with a block like this:
       ```yaml
       spec:
         type: {{ .Values.proxy.service.type }}
         ports:
           {{- if or (not .Values.tls.enabled) (not .Values.tls.proxy.enabled) }}
           - name: http
             port: {{ .Values.proxy.ports.http }}
             targetPort: {{ .Values.proxy.ports.targetHttp }}
             protocol: TCP
       ```
       Then, we would open up the `targetHttp` port on the proxy container and pod definition. This would be helpful because it'd be a seamless transition for end users targeting the service. Technically, any users hitting the pods directly would be affected by this breaking change. Although, I believe that kind of direct interations is an anti-pattern within kubernetes, so I think we could safely ignore that case. Further, the proxy's `PodMonitor` config is set to hit the named port `http`, which would mean that it'd make the transition to an arbitrary `targetPort` seamlessly. (I technically still need to double check that this whole solution works. I'm pretty confident it will, but I'll need to test before pushing up the PR.)
       A major benefit to this solution is that it lets us support rootless containers by default for our end users.
   1. As I suggested in my earlier comment, we could default the Pulsar Proxy container to run as the root user, and then let end users manage the upgrade themselves. This solution seems more complicated to me, and it doesn't result in a great experience for end users.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org