Comments (6)
@michaeljmarshall Helm has a built-in variable that can tell you whether it is doing an install or an upgrade. For example, you can do something like this:
{{- if .Release.IsInstall }}
do something
{{ end }}
Alternatively, you can use Helm Hooks.
from pulsar-helm-chart.
Setting the proxy port to 8080 can resolve this issue.
we can use --set proxy.ports.http=8080 during helm install to change the port to 8080
helm install
--values examples/values-minikube.yaml
--set initialize=true
--set proxy.ports.http=8080
--namespace pulsar
pulsar-mini apache/pulsar
from pulsar-helm-chart.
I proposed the following solution in apache/pulsar#8796 (comment). It's copied here:
I think the easiest way to prevent a breaking change in the helm chart is to default to using the
root
user in the helm chart's deployment for the pulsar proxy. We could then add a configuration that allows users to opt in to running that container as a non root user.Essentially, we need to default a pulsar proxy pod's security context to the following:
securityContext: runAsUser: 0 runAsGroup: 0I believe all other pulsar containers should still be able to run as the non root user.
(I am assuming that we want to prevent breaking changes here as the 2.8.0 release is only a minor version bump.)
I'm happy to discuss alternatives.
from pulsar-helm-chart.
@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.
- We could add a value for the
targetPort
on the pulsar proxy service where thetargetPort
defaults to8080
. In this case, we could update the template for the proxy service with a block like this:Then, we would open up thespec: 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
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'sPodMonitor
config is set to hit the named porthttp
, which would mean that it'd make the transition to an arbitrarytargetPort
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. - 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.
from pulsar-helm-chart.
In thinking more about this more, we have a problem for our users that upgrade to 2.8.0 from any previous version of pulsar. The persistent data written by prior bookie and zookeeper pods will be owned by the root user, not the new pulsar
user, and it's possible that directories like the data
directory in the bookie will not be writable for the pulsar
user. Given that zookeepers and bookies delete files, they will need more permission in order to function properly after upgrade.
Solution 1 (mentioned above) is not sufficient to prevent breaking clusters during upgrade. We need to either run bookie and zookeeper containers as the root user by default and have users opt in to running them as non-root containers, or we need to solve the upgrade problem in the chart. Perhaps we can solve this by providing an optional init container that properly changes file system ownership for the bookie/zookeeper pods. Given that our users have already been running the containers as the root user, I don't see any conflict in using a privileged init container just this once.
Whatever path we choose, I would like to try to give new users a rootless deployment by default. I am not familiar with how helm manages upgrades versus new deployments, but perhaps there is a way to have conditional logic that branches on upgrade vs new deployment?
from pulsar-helm-chart.
Fixed.
from pulsar-helm-chart.
Related Issues (20)
- [CI] ci::test_pulsar_manager environment check is flaky HOT 10
- Node does not exist HOT 4
- Requires AWS access/secret key when offload driver is set to aws-s3 HOT 2
- not able to login to pulsar UI HOT 7
- No data shown in Grafana Dashboards HOT 2
- Pulsar Manager v0.4.0 in kubernetes still can not persist any data HOT 1
- Argo CD unable to generate template with pulsar chart 3.3.0 HOT 5
- Deployment using JWT authentication + Function Worker is not working properly HOT 1
- [Bug] Broker startup could get into a long crash loop when Functions are enabled HOT 1
- Allow using a separate volume for the zookeeper transaction log
- Allow specifying an existing secret for pulsar-manager credentials
- Make it possible to optionally override .ReleaseIsInstall logic in init jobs
- Latest chart version: 3.4.0 missing in the Apache helm repo index HOT 3
- Plugins support HOT 1
- PKIX path building failed: unable to find valid certification path to request to requested target HOT 2
- HPA missing namespace HOT 1
- upgrade to pulsar helm chart version 3.3.1 from 2.9.4->3.0.0->3.3.1 with the pulsar-broker error HOT 2
- Pulsar manager service fails saying "2024-05-07 15:02:17,476 INFO exited: pulsar-manager-backend (terminated by SIGKILL; not expected)" HOT 2
- Allow broker's service clusterIP customisation: headless vs non-headless HOT 1
- pulsar-broker failed to start with both Liveness probe and Readiness probes failed: HTTP probe failed with statuscode: 404 HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pulsar-helm-chart.