You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by GitBox <gi...@apache.org> on 2019/11/02 14:42:03 UTC

[GitHub] [pulsar] youurayy edited a comment on issue #4687: Publish Pulsar Helm chart on the official Helm Charts repository

youurayy edited a comment on issue #4687: Publish Pulsar Helm chart on the official Helm Charts repository
URL: https://github.com/apache/pulsar/issues/4687#issuecomment-549026833
 
 
   Issues with the current Helm chart:
   
   - some insane default values, e.g. 4 GB RAM for the Proxy component (and there are 3 replicas)
   - a Helm redeploy which happens to restart the Broker (and possibly other) pods will render the cluster unusable
   - a Helm uninstall followed by a Helm (re)install with persistent volume claims will reattach the volumes, but Pulsar won't be able to use them and won't initialize properly, rendering it unusable
   - changing a `ConfigMap` value and redeploying does nothing, pulsar components will keep using the old values
   - the values.yaml config for Brokers doesn't allow exposing the broker service on NodePorts for direct (high performance) access thru the `pulsar://` protocol
   - the Brokers should probably be deployed using a `StatefulSet` (just like BookKeepers are), as the RAM allocation is usually prohibitive of running multiple Brokers on the same node
   - we should explain what Proxy really does (as Pulsar doesn't)
     - the `http://` protocol will only redirect your client to a direct/pod/ClusterIP `pulsar://` address, which will never work (unless you use EKS thru a VPC bridge -or- you have hardcoded your Broker URLs into the Proxy)
     - only the 'pulsar://` endpoint provides reverse proxying to the Brokers (but it needs a TCP load balancer, so e.g. you can't use Traefik 1.x to load balance multiple Proxies)
     - if your Brokers don't use SSL encryption, so can't your Proxy, because the the protocol type is carried thru Proxy, so you'll end up having to use unencrypted access thru public internet
     - due to these:
       - you'll really want to use only a small, single Proxy in your cluster for some external testing
       - for production use you'll want to expose the Pulsar Brokers on `NodePort`s, but since the Brokers do redirection for requests on topics they don't serve, you need to either:
         - set the `advertisedAddress` variable on the Broker to externally lookup-able hostname (in the context of your pulsar client) (the current Helm chart doesn't offer to do this, because you need to set a different one for each Broker)
         - somehow make the `hostname` on the Broker pod return externally lookup-able hostname (in the context of your pulsar client)
   
   

----------------------------------------------------------------
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


With regards,
Apache Git Services