apache/pulsar-helm-chart
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Change Pulsar Proxy service load balancer type to ClusterIP (#588)

Browse Source
This commit is contained in:
Lari Hotari 2025-03-06 15:03:42 +02:00 committed by GitHub
parent 976ba92e3b
commit dd1325216f
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
5 changed files with 398 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
.ci/chart_test.sh
View File

@ -28,6 +28,7 @@ TLS=${TLS:-"false"}
SYMMETRIC=${SYMMETRIC:-"false"} SYMMETRIC=${SYMMETRIC:-"false"}
FUNCTION=${FUNCTION:-"false"} FUNCTION=${FUNCTION:-"false"}
MANAGER=${MANAGER:-"false"} MANAGER=${MANAGER:-"false"}
ALLOW_LOADBALANCERS=${ALLOW_LOADBALANCERS:-"false"}
source ${PULSAR_HOME}/.ci/helm.sh source ${PULSAR_HOME}/.ci/helm.sh
@ -56,6 +57,7 @@ fi
install_type="install" install_type="install"
test_action="produce-consume" test_action="produce-consume"
if [[ "$UPGRADE_FROM_VERSION" != "" ]]; then if [[ "$UPGRADE_FROM_VERSION" != "" ]]; then
ALLOW_LOADBALANCERS="true"
# install older version of pulsar chart # install older version of pulsar chart
PULSAR_CHART_VERSION="$UPGRADE_FROM_VERSION" PULSAR_CHART_VERSION="$UPGRADE_FROM_VERSION"
ci::install_pulsar_chart install ${PULSAR_HOME}/.ci/values-common.yaml ${PULSAR_HOME}/${VALUES_FILE} "${extra_opts[@]}" ci::install_pulsar_chart install ${PULSAR_HOME}/.ci/values-common.yaml ${PULSAR_HOME}/${VALUES_FILE} "${extra_opts[@]}"
@ -83,6 +85,11 @@ ci::install_pulsar_chart ${install_type} ${PULSAR_HOME}/.ci/values-common.yaml $
echo "Wait 10 seconds" echo "Wait 10 seconds"
sleep 10 sleep 10
# check that there aren't any loadbalancers if ALLOW_LOADBALANCERS is false
if [[ "${ALLOW_LOADBALANCERS}" == "false" ]]; then
ci::check_loadbalancers
fi
# check pulsar environment # check pulsar environment
ci::check_pulsar_environment ci::check_pulsar_environment

12
.ci/helm.sh
View File

@ -424,6 +424,18 @@ function ci::test_pulsar_manager() {
fi fi
} }
function ci::check_loadbalancers() {
(
set +e
${KUBECTL} get services -n ${NAMESPACE} | grep LoadBalancer
if [ $? -eq 0 ]; then
echo "Error: Found service with type LoadBalancer. This is not allowed because of security reasons."
exit 1
fi
exit 0
)
}
function ci::validate_kustomize_yaml() { function ci::validate_kustomize_yaml() {
# if kustomize is not installed, install kustomize to a temp directory # if kustomize is not installed, install kustomize to a temp directory
if ! command -v kustomize &> /dev/null; then if ! command -v kustomize &> /dev/null; then

156
README.md
View File

@ -27,27 +27,107 @@ Read [Deploying Pulsar on Kubernetes](http://pulsar.apache.org/docs/deploy-kuber
> :warning: This helm chart is updated outside of the regular Pulsar release cycle and might lag behind a bit. It only supports basic Kubernetes features now. Currently, it can be used as no more than a template and starting point for a Kubernetes deployment. In many cases, it would require some customizations. > :warning: This helm chart is updated outside of the regular Pulsar release cycle and might lag behind a bit. It only supports basic Kubernetes features now. Currently, it can be used as no more than a template and starting point for a Kubernetes deployment. In many cases, it would require some customizations.
## Important Security Disclaimer for Helm Chart Usage ## Important Security Advisory for Helm Chart Usage
### Notice of Default Configuration ### Notice of Default Configuration
This Helm chart is provided with a default configuration that does not meet the security requirements for production environments or sensitive data handling. Users are strongly advised to thoroughly review and customize the security settings to ensure a secure deployment that aligns with their specific operational and security policies.
This Helm chart's default configuration DOES NOT meet production security requirements.
Users MUST review and customize security settings for their specific environment.
IMPORTANT: This Helm chart provides a starting point for Pulsar deployments but requires
significant security customization before use in production environments. We strongly
recommend implementing:
1. Authentication and authorization for all components
2. TLS encryption for all communication channels
3. Proper network isolation and access controls
4. Regular security updates and vulnerability assessments
As an open source project, we welcome contributions to improve security features.
Please consider submitting pull requests to address security gaps or enhance
existing security implementations.
### Pulsar Proxy Security Considerations ### Pulsar Proxy Security Considerations
As per the [Pulsar Proxy documentation](https://pulsar.apache.org/docs/3.1.x/administration-proxy/), it is explicitly stated that the Pulsar proxy is not designed for exposure to the public internet. The design assumes that deployments will be protected by network perimeter security measures. It is crucial to understand that relying solely on the default configuration can expose your deployment to significant security vulnerabilities. As per the [Pulsar Proxy documentation](https://pulsar.apache.org/docs/3.1.x/administration-proxy/), it is explicitly stated that the Pulsar proxy is not designed for exposure to the public internet. The design assumes that deployments will be protected by network perimeter security measures. It is crucial to understand that relying solely on the default configuration can expose your deployment to significant security vulnerabilities.
#### Recommendations: ### Important Change in 4.0.0 version of the Apache Pulsar Helm chart
The default service type for the Pulsar proxy has changed from `LoadBalancer` to `ClusterIP` for security reasons. This limits access to within the Kubernetes environment by default.
### External Access Recommendations
If you need to expose the Pulsar Proxy outside the cluster:
1. **USE INTERNAL LOAD BALANCERS ONLY**
- Set type to LoadBalancer only in secured environments with proper network controls
- Add cloud provider-specific annotations for internal load balancers:
- Kubernetes documentation about internal load balancers:
- [Internal load balancer](https://kubernetes.io/docs/concepts/services-networking/service/#internal-load-balancer)
- See cloud provider documentation:
- AWS / EKS: [AWS Load Balancer Controller / Service Annotations](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/)
- Azure / AKS: [Use an internal load balancer with Azure Kubernetes Service (AKS)](https://learn.microsoft.com/en-us/azure/aks/internal-lb)
- GCP / GKE: [LoadBalancer service parameters](https://cloud.google.com/kubernetes-engine/docs/concepts/service-load-balancer-parameters)
- Examples (verify correctness for your environment):
- AWS / EKS: `service.beta.kubernetes.io/aws-load-balancer-internal: "true"`
- Azure / AKS: `service.beta.kubernetes.io/azure-load-balancer-internal: "true"`
- GCP / GKE: `networking.gke.io/load-balancer-type: "Internal"`
2. **IMPLEMENT AUTHENTICATION AND AUTHORIZATION**
- Configure all clients to authenticate properly
- Set up appropriate authorization policies
3. **USE TLS FOR ALL CONNECTIONS**
- Enable TLS for client-to-proxy connections
- Enable TLS for proxy-to-broker connections
- Enable TLS for all internal cluster communications
- Note: TLS alone is NOT sufficient as a security solution. Even with TLS enabled, clusters exposed to untrusted networks remain vulnerable to denial-of-service attacks, authentication bypass attempts, and protocol-level exploits.
4. **NETWORK SECURITY**
- Use private networks (VPCs)
- Configure firewalls, security groups, and IP restrictions
5. **CLIENT IP ADDRESS BASED ACCESS RESTRICTIONS**
- When using a LoadBalancer service type, restrict access to specific IP ranges by configuring `proxy.service.loadBalancerSourceRanges` in your values.yaml:
```yaml
proxy:
service:
loadBalancerSourceRanges:
- 10.0.0.0/8 # Private network range
- 172.16.0.0/12 # Private network range
- 192.168.0.0/16 # Private network range
```
- This feature:
- Provides an additional defense layer by filtering traffic at the load balancer level
- Only allows connections from specified CIDR blocks
- Works only with LoadBalancer service type and when your cloud provider supports the `loadBalancerSourceRanges` parameter
- Important: This should be implemented alongside other security measures (internal load balancer, authentication, TLS, network policies) as part of a defense-in-depth strategy,
not as a standalone security solution
### Alternative for External Access
As an alternative method for external access, Pulsar has support for [SNI proxy routing](https://pulsar.apache.org/docs/next/concepts-proxy-sni-routing/). SNI Proxy routing is supported with proxy servers such as Apache Traffic Server, HAProxy and Nginx.
Note: This option isn't currently implemented in the Apache Pulsar Helm chart.
**IMPORTANT**: Pulsar binary protocol cannot be exposed outside of the Kubernetes cluster using Kubernetes Ingress. Kubernetes Ingress works for the Admin REST API and topic lookups, but clients would be connecting to the advertised listener addresses returned by the brokers and it would only work when clients can connect directly to brokers. This is not a supported secure option for exposing Pulsar to untrusted networks.
### General Recommendations
- **Network Perimeter Security:** It is imperative to implement robust network perimeter security to safeguard your deployment. The absence of such security measures can lead to unauthorized access and potential data breaches. - **Network Perimeter Security:** It is imperative to implement robust network perimeter security to safeguard your deployment. The absence of such security measures can lead to unauthorized access and potential data breaches.
- **Restricted Access:** For environments where security is less critical, such as certain development or testing scenarios, the use of `loadBalancerSourceRanges` may be employed to restrict access to specified IP addresses or ranges. This, however, should not be considered a substitute for comprehensive security measures in production environments. - **Restricted Access:** For environments where security is less critical, such as certain development or testing scenarios, the use of `loadBalancerSourceRanges` may be employed to restrict access to specified IP addresses or ranges. This, however, should not be considered a substitute for comprehensive security measures in production environments.
### User Responsibility ### User Responsibility
The user assumes full responsibility for the security and integrity of their deployment. This includes, but is not limited to, the proper configuration of security features and adherence to best practices for securing network access. The providers of this Helm chart disclaim all warranties, whether express or implied, including any warranties of merchantability, fitness for a particular purpose, and non-infringement of third-party rights. The user assumes full responsibility for the security and integrity of their deployment. This includes, but is not limited to, the proper configuration of security features and adherence to best practices for securing network access. The providers of this Helm chart disclaim all warranties, whether express or implied, including any warranties of merchantability, fitness for a particular purpose, and non-infringement of third-party rights.
### No Security Guarantees ### No Security Guarantees
The providers of this Helm chart make no guarantees regarding the security of the chart under any circumstances. It is the user's responsibility to ensure that their deployment is secure and complies with all relevant security standards and regulations. The providers of this Helm chart make no guarantees regarding the security of the chart under any circumstances. It is the user's responsibility to ensure that their deployment is secure and complies with all relevant security standards and regulations.
By using this Helm chart, the user acknowledges the risks associated with its default configuration and the necessity for proper security customization. The user further agrees that the providers of the Helm chart shall not be liable for any security breaches or incidents resulting from the use of the chart. By using this Helm chart, the user acknowledges the risks associated with its default configuration and the necessity for proper security customization. The user further agrees that the providers of the Helm chart shall not be liable for any security breaches or incidents resulting from the use of the chart.
## Features ## Features
This Helm Chart includes all the components of Apache Pulsar for a complete experience. This Helm Chart includes all the components of Apache Pulsar for a complete experience.
@ -114,7 +194,8 @@ Before proceeding to deploying Pulsar, you need to prepare your environment.
To add this chart to your local Helm repository: To add this chart to your local Helm repository:
```bash ```bash
helm repo add apache https://pulsar.apache.org/charts helm repo add apachepulsar https://pulsar.apache.org/charts
helm repo update
``` ```
## Kubernetes cluster preparation ## Kubernetes cluster preparation
@ -126,14 +207,49 @@ We provide some instructions to guide you through the preparation: http://pulsar
## Deploy Pulsar to Kubernetes ## Deploy Pulsar to Kubernetes
1. Configure your values file. The best way to know which values are available is to read the [values.yaml](./charts/pulsar/values.yaml). 1. Configure your values file. The best way to know which values are available is to read the [values.yaml](./charts/pulsar/values.yaml).
A best practice is to start with an empty values file and only set the keys that differ from the default configuration.
Anti-affinity rules for Zookeeper and Bookie components require at least one node per replica. For Kubernetes clusters with less than 3 nodes,
you must disable this feature by adding this to your initial values.yaml file:
```yaml
affinity:
anti_affinity: false
```
2. Install the chart: 2. Install the chart:
```bash ```bash
helm install <release-name> -n <namespace> -f your-values.yaml apache/pulsar helm install -n <namespace> --create-namespace <release-name> -f your-values.yaml apachepulsar/pulsar
``` ```
3. Access the Pulsar cluster 3. Observe the deployment progress
Watching events to view progress of deployment:
```shell
kubectl get -n <namespace> events -o wide --watch
```
Watching state of deployed Kubernetes objects, updated every 2 seconds:
```shell
watch kubectl get -n <namespace> all
```
Waiting until Pulsar Proxy is available:
```shell
kubectl wait --timeout=600s --for=condition=ready pod -n <namespace> -l component=proxy
```
Watching state with k9s (https://k9scli.io/topics/install/):
```shell
k9s -n <namespace>
```
4. Access the Pulsar cluster
The default values will create a `ClusterIP` for the proxy you can use to interact with the cluster. To find the IP address of proxy use: The default values will create a `ClusterIP` for the proxy you can use to interact with the cluster. To find the IP address of proxy use:
@ -144,7 +260,7 @@ We provide some instructions to guide you through the preparation: http://pulsar
For more information, please follow our detailed For more information, please follow our detailed
[quick start guide](https://pulsar.apache.org/docs/getting-started-helm/). [quick start guide](https://pulsar.apache.org/docs/getting-started-helm/).
## Customize the deployment ## Customize the deployment
We provide a [detailed guideline](https://pulsar.apache.org/docs/helm-deploy/) for you to customize We provide a [detailed guideline](https://pulsar.apache.org/docs/helm-deploy/) for you to customize
the Helm Chart for a production-ready deployment. the Helm Chart for a production-ready deployment.
@ -236,20 +352,28 @@ Once your Pulsar Chart is installed, configuration changes and chart
updates should be done using `helm upgrade`. updates should be done using `helm upgrade`.
```bash ```bash
helm repo add apache https://pulsar.apache.org/charts helm repo add apachepulsar https://pulsar.apache.org/charts
helm repo update helm repo update
helm get values <pulsar-release-name> > pulsar.yaml # get the existing values.yaml used for the most recent deployment
helm upgrade -f pulsar.yaml \ helm get values -n <namespace> <pulsar-release-name> > values.yaml
<pulsar-release-name> apache/pulsar # upgrade the deployment
helm upgrade -n <namespace> -f values.yaml <pulsar-release-name> apachepulsar/pulsar
``` ```
For more detailed information, see our [Upgrading](http://pulsar.apache.org/docs/helm-upgrade/) guide. For more detailed information, see our [Upgrading](http://pulsar.apache.org/docs/helm-upgrade/) guide.
## Upgrading from Helm Chart version 3.x.x to 4.0.0 version and above ## Upgrading from Helm Chart version 3.x.x to 4.0.0 version and above
### Pulsar Proxy service's default type has been changed from `LoadBalancer` to `ClusterIP`
Please check the section "External Access Recommendations" for guidance and also check the security advisory section.
You will need to configure keys under `proxy.service` in your `values.yaml` to preserve existing functionality since the default has been changed.
### kube-prometheus-stack upgrade
The kube-prometheus-stack version has been upgraded to 69.x.x in Pulsar Helm Chart version 4.0.0 . The kube-prometheus-stack version has been upgraded to 69.x.x in Pulsar Helm Chart version 4.0.0 .
Before running "helm upgrade", you should first upgrade the Prometheus Operator CRDs as [instructed Before running "helm upgrade", you should first upgrade the Prometheus Operator CRDs as [instructed
in kube-prometheus-stack upgrade notes](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack#from-68x-to-69x). in kube-prometheus-stack upgrade notes](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack#from-68x-to-69x).
There's a script to run the required commands: There's a script to run the required commands:
@ -263,7 +387,7 @@ After, this you can proceed with `helm upgrade`.
The kube-prometheus-stack version has been upgraded to 65.x.x in Pulsar Helm Chart version 3.7.0 . The kube-prometheus-stack version has been upgraded to 65.x.x in Pulsar Helm Chart version 3.7.0 .
Before running "helm upgrade", you should first upgrade the Prometheus Operator CRDs as [instructed Before running "helm upgrade", you should first upgrade the Prometheus Operator CRDs as [instructed
in kube-prometheus-stack upgrade notes](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack#from-64x-to-65x). in kube-prometheus-stack upgrade notes](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack#from-64x-to-65x).
There's a script to run the required commands: There's a script to run the required commands:
@ -277,7 +401,7 @@ After, this you can proceed with `helm upgrade`.
The kube-prometheus-stack version has been upgraded to 59.x.x in Pulsar Helm Chart version 3.5.0 . The kube-prometheus-stack version has been upgraded to 59.x.x in Pulsar Helm Chart version 3.5.0 .
Before running "helm upgrade", you should first upgrade the Prometheus Operator CRDs as [instructed Before running "helm upgrade", you should first upgrade the Prometheus Operator CRDs as [instructed
in kube-prometheus-stack upgrade notes](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack#from-58x-to-59x). in kube-prometheus-stack upgrade notes](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack#from-58x-to-59x).
There's a script to run the required commands: There's a script to run the required commands:
@ -291,7 +415,7 @@ After, this you can proceed with `helm upgrade`.
The kube-prometheus-stack version has been upgraded to 56.x.x in Pulsar Helm Chart version 3.3.0 . The kube-prometheus-stack version has been upgraded to 56.x.x in Pulsar Helm Chart version 3.3.0 .
Before running "helm upgrade", you should first upgrade the Prometheus Operator CRDs as [instructed Before running "helm upgrade", you should first upgrade the Prometheus Operator CRDs as [instructed
in kube-prometheus-stack upgrade notes](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack#from-55x-to-56x). in kube-prometheus-stack upgrade notes](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack#from-55x-to-56x).
There's a script to run the required commands: There's a script to run the required commands:

191
charts/pulsar/templates/NOTES.txt
View File

@ -1,18 +1,185 @@
Thank you for installing Apache Pulsar Helm chart version {{ .Chart.Version }}. ======================================================================================
APACHE PULSAR HELM CHART
======================================================================================
!! WARNING !! ======================================================================================
SECURITY ADVISORY
======================================================================================
Important Security Disclaimer for Apache Pulsar Helm Chart Usage: This Helm chart's default configuration DOES NOT meet production security requirements.
Users MUST review and customize security settings for their specific environment.
This Helm chart is provided with a default configuration that does not IMPORTANT: This Helm chart provides a starting point for Pulsar deployments but requires
meet the security requirements for production environments or sensitive significant security customization before use in production environments. We strongly
data handling. Users are strongly advised to thoroughly review and recommend implementing:
customize the security settings to ensure a secure deployment that
aligns with their specific operational and security policies.
Go to https://github.com/apache/pulsar-helm-chart for more details. 1. Proper network isolation and access controls
2. Authentication and authorization for all components
3. TLS encryption for all communication channels
4. Regular security updates and vulnerability assessments
Ask usage questions at https://github.com/apache/pulsar/discussions/categories/q-a As an open source project, we welcome contributions to improve security features.
Report issues to https://github.com/apache/pulsar-helm-chart/issues Please consider submitting pull requests to address security gaps or enhance
Please contribute improvements to https://github.com/apache/pulsar-helm-chart existing security implementations.
---------------------------------------------------------------------------------------
SECURITY NOTICE: The Pulsar proxy is not designed for direct public internet exposure.
It lacks security features required for untrusted networks and should only be deployed
within secured environments with proper network controls.
IMPORTANT CHANGE IN v4.0.0: Default service type changed from LoadBalancer to ClusterIP
for security reasons. This limits access to within the Kubernetes environment by default.
---------------------------------------------------------------------------------------
IF YOU NEED EXTERNAL ACCESS FOR YOUR PULSAR CLUSTER:
---------------------------------------------------------------------------------------
Note: This information might be outdated. Please go to https://github.com/apache/pulsar-helm-chart for updated information.
If you need to expose the Pulsar Proxy outside the cluster using a LoadBalancer service type:
1. USE INTERNAL LOAD BALANCERS ONLY
- Set type to LoadBalancer only in secured environments with proper network controls
- Add cloud provider-specific annotations for internal load balancers
- See cloud provider documentation:
* AWS / EKS: https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/
* Azure / AKS: https://learn.microsoft.com/en-us/azure/aks/internal-lb
* GCP / GKE: https://cloud.google.com/kubernetes-engine/docs/concepts/service-load-balancer-parameters
- Examples (verify correctness for your environment):
* AWS / EKS: service.beta.kubernetes.io/aws-load-balancer-internal: "true"
* Azure / AKS: service.beta.kubernetes.io/azure-load-balancer-internal: "true"
* GCP / GKE: networking.gke.io/load-balancer-type: "Internal"
2. IMPLEMENT AUTHENTICATION AND AUTHORIZATION
- Configure all clients to authenticate properly
- Set up appropriate authorization policies
3. USE TLS FOR ALL CONNECTIONS
- Enable TLS for client-to-proxy connections
- Enable TLS for proxy-to-broker connections
- Enable TLS for all internal cluster communications (brokers, zookeepers, bookies)
- Note: TLS alone is NOT sufficient as a security solution in Pulsar. Even with TLS enabled,
clusters exposed to untrusted networks remain vulnerable to denial-of-service attacks,
authentication bypass attempts, and protocol-level exploits. Always implement defense-in-depth
security measures and limit exposure to trusted networks only.
4. NETWORK SECURITY
- Use private networks (VPCs)
- Configure firewalls, security groups, and IP restrictions appropriately
- In addition, consider using loadBalancerSourceRanges to limit access to specific IP ranges
5. CLIENT IP ADDRESS BASED ACCESS RESTRICTIONS
- When using a LoadBalancer service type, restrict access to specific IP ranges by configuring
`proxy.service.loadBalancerSourceRanges` in your values.yaml
- Important: This should be implemented alongside other security measures (internal load balancer,
authentication, TLS, network policies) as part of a defense-in-depth strategy,
not as a standalone security solution
---------------------------------------------------------------------------------------
ALTERNATIVE FOR EXTERNAL ACCESS
---------------------------------------------------------------------------------------
As an alternative method for external access, Pulsar has support for SNI proxy routing:
https://pulsar.apache.org/docs/next/concepts-proxy-sni-routing/
SNI Proxy routing is supported with proxy servers such as Apache Traffic Server, HAProxy and Nginx.
Note: This option isn't currently implemented in the Apache Pulsar Helm chart.
IMPORTANT: Pulsar binary protocol cannot be exposed outside of the Kubernetes cluster
using Kubernetes Ingress. Kubernetes Ingress works for the Admin REST API and topic lookups,
but clients would be connecting to the advertised listener addresses returned by the brokers and it
would only work when clients can connect directly to brokers. This is not a supported secure option
for exposing Pulsar to untrusted networks.
{{- if .Values.useReleaseStatus }}
======================================================================================
🚀 QUICK START 🚀
======================================================================================
Watching events to view progress of deployment:
kubectl get -n {{ .Values.namespace | default .Release.Namespace }} events -o wide --watch
Watching state of deployed Kubernetes objects, updated every 2 seconds:
watch kubectl get -n {{ .Values.namespace | default .Release.Namespace }} all
{{- if .Values.components.proxy }}
Waiting until Pulsar Proxy is available:
kubectl wait --timeout=600s --for=condition=ready pod -n {{ .Values.namespace | default .Release.Namespace }} -l component=proxy
{{- end }}
Watching state with k9s (https://k9scli.io/topics/install/):
k9s -n {{ .Values.namespace | default .Release.Namespace }}
{{- if and .Values.affinity.anti_affinity (or (gt (int .Values.bookkeeper.replicaCount) 1) (gt (int .Values.zookeeper.replicaCount) 1)) }}
======================================================================================
⚠️ NOTICE FOR DEV K8S CLUSTER USERS ⚠️
======================================================================================
Please note that anti-affinity rules for Zookeeper and Bookie components require at least
one node per replica. There are currently {{ .Values.bookkeeper.replicaCount }} bookies and {{ .Values.zookeeper.replicaCount }} zookeepers configured.
For Kubernetes clusters with fewer than 3 nodes, such as single-node Kubernetes clusters in
development environments like minikube, Docker Desktop, Rancher Desktop (k3s), or Podman
Desktop, you must disable the anti-affinity feature by either:
Adding to your values.yaml:
affinity:
anti_affinity: false
Or adding "--set affinity.anti_affinity=false" to the helm command line.
After making the changes to your values yaml file, redeploy with "helm upgrade":
helm upgrade -n {{ .Release.Namespace }} -f your_values_file.yaml {{ .Release.Name }} apachepulsar/pulsar
These configuration instructions can be omitted for Kubernetes clusters with 3 or more nodes.
{{- end }}
{{- end }}
{{- if and (eq .Values.proxy.service.type "LoadBalancer") (not .Values.proxy.service.annotations) }}
======================================================================================
⚠️ 🚨 INSECURE CONFIGURATION DETECTED 🚨 ⚠️
======================================================================================
WARNING: You are using a LoadBalancer service type without internal load balancer
annotations. This is potentially an insecure configuration. Please carefully review
the security recommendations above and visit https://github.com/apache/pulsar-helm-chart
for more information.
======================================================================================
{{- end }}
======================================================================================
DISCLAIMER
======================================================================================
The providers of this Helm chart make no guarantees regarding the security of the chart under
any circumstances. It is the user's responsibility to ensure that their deployment is secure
and complies with all relevant security standards and regulations.
By using this Helm chart, the user acknowledges the risks associated with its default
configuration and the necessity for proper security customization. The user further
agrees that the providers of the Helm chart shall not be liable for any security breaches
or incidents resulting from the use of the chart.
The user assumes full responsibility for the security and integrity of their deployment.
This includes, but is not limited to, the proper configuration of security features and
adherence to best practices for securing network access. The providers of this Helm chart
disclaim all warranties, whether express or implied, including any warranties of
merchantability, fitness for a particular purpose, and non-infringement of third-party rights.
======================================================================================
RESOURCES
======================================================================================
- 🖥️ Install k9s terminal interface for viewing and managing k8s clusters: https://k9scli.io/topics/install/
- ❓ Usage Questions: https://github.com/apache/pulsar/discussions/categories/q-a
- 🐛 Report Issues: https://github.com/apache/pulsar-helm-chart/issues
- 🔒 Security Issues: https://pulsar.apache.org/security/
- 📚 Documentation: https://github.com/apache/pulsar-helm-chart
🌟 Please contribute to improve the Apache Pulsar Helm chart and its documentation:
- 🤝 Contribute: https://github.com/apache/pulsar-helm-chart
Thank you for installing Apache Pulsar Helm chart version {{ .Chart.Version }}.

67
charts/pulsar/values.yaml
View File

@ -21,9 +21,14 @@
### K8S Settings ### K8S Settings
### ###
### Namespace to deploy pulsar ### Namespace to deploy Pulsar
# The namespace to use to deploy the pulsar components, if left empty ### Note: Prefer using helm's --namespace flag with --create-namespace instead
# will default to .Release.Namespace (aka helm --namespace). ## The namespace to use to deploy the Pulsar components. If left empty,
## it will default to .Release.Namespace (aka helm --namespace).
## Please note that kube-prometheus-stack will not be able to scrape Pulsar component metrics by default unless
## it is deployed in the same namespace as Pulsar. The kube-prometheus-stack namespace can be configured by setting
## the kube-prometheus-stack.namespaceOverride key to match Pulsar's namespace.
## More details are provided in the comments for the kube-prometheus-stack.namespaceOverride key later in this file.
namespace: "" namespace: ""
namespaceCreate: false namespaceCreate: false
@ -35,6 +40,7 @@ clusterDomain: cluster.local
### ###
## Set to true on install ## Set to true on install
## There's no need to set this value unless you're using a system that doesn't track .Release.IsInstall or .Release.IsUpgrade (like argocd)
initialize: false initialize: false
## Set useReleaseStatus to false if you're deploying this chart using a system that doesn't track .Release.IsInstall or .Release.IsUpgrade (like argocd) ## Set useReleaseStatus to false if you're deploying this chart using a system that doesn't track .Release.IsInstall or .Release.IsUpgrade (like argocd)
useReleaseStatus: true useReleaseStatus: true
@ -90,10 +96,9 @@ volumes:
rbac: rbac:
enabled: false enabled: false
psp: false psp: false # DEPRECATED: PodSecurityPolicy is not supported in Kubernetes 1.25+
limit_to_namespace: true limit_to_namespace: true
## AntiAffinity ## AntiAffinity
## ##
## Flag to enable and disable `AntiAffinity` for all components. ## Flag to enable and disable `AntiAffinity` for all components.
@ -101,6 +106,8 @@ rbac:
## If you need to disable AntiAffinity for a component, you can set ## If you need to disable AntiAffinity for a component, you can set
## the `affinity.anti_affinity` settings to `false` for that component. ## the `affinity.anti_affinity` settings to `false` for that component.
affinity: affinity:
## When set to true, the scheduler will try to spread pods across different nodes.
## It is necessary to set this to false if you're using a Kubernetes cluster with less than 3 nodes, such as local development environments.
anti_affinity: true anti_affinity: true
# Set the anti affinity type. Valid values: # Set the anti affinity type. Valid values:
# requiredDuringSchedulingIgnoredDuringExecution - rules must be met for pod to be scheduled (hard) requires at least one node per replica # requiredDuringSchedulingIgnoredDuringExecution - rules must be met for pod to be scheduled (hard) requires at least one node per replica
@ -1318,8 +1325,48 @@ proxy:
http: 8080 http: 8080
https: 8443 https: 8443
service: service:
annotations: {} # Service type defaults to ClusterIP for security reasons.
type: LoadBalancer #
# SECURITY NOTICE: The Pulsar proxy is not designed for direct public internet exposure
# (see https://pulsar.apache.org/docs/4.0.x/administration-proxy/).
#
# If you need to expose the proxy outside of the cluster using a LoadBalancer service type:
# 1. Set type to LoadBalancer only in secured environments with proper network controls.
# In cloud managed Kubernetes clusters, make sure to add annotations to the service to create an
# internal load balancer so that the load balancer is not exposed to the public internet.
# You must also ensure that the configuration is correct so that the load balancer is not exposed to the public internet.
# 2. Configure authentication and authorization
# 3. Use TLS for all connections
# 4. If you are exposing to unsecure networks, implement additional security measures like
# IP restrictions (loadBalancerSourceRanges)
#
# Please notice that the the Apache Pulsar project takes no responsibility for any security issues
# for your deployment. Exposing the cluster using Pulsar Proxy to unsecure networks is not supported.
#
# Previous chart versions defaulted to LoadBalancer which could create security risks.
type: ClusterIP
# When using a LoadBalancer service type, add internal load balancer annotations to the service to create an internal load balancer.
annotations: {
## Set internal load balancer annotations when using a LoadBalancer service type because of security reasons.
## You must also ensure that the configuration is correct so that the load balancer is not exposed to the public internet.
## This information below is for reference only and may not be applicable to your cloud provider.
## Please refer to the cloud provider's documentation for the correct annotations.
## Kubernetes documentation about internal load balancers
## https://kubernetes.io/docs/concepts/services-networking/service/#internal-load-balancer
## AWS / EKS
## Ensure that you have recent AWS Load Balancer Controller installed.
## Docs: https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/
# service.beta.kubernetes.io/aws-load-balancer-scheme: "internal"
## Azure / AKS
## Docs: https://learn.microsoft.com/en-us/azure/aks/internal-lb
# service.beta.kubernetes.io/azure-load-balancer-internal: "true"
## GCP / GKE
## Docs: https://cloud.google.com/kubernetes-engine/docs/concepts/service-load-balancer-parameters
# networking.gke.io/load-balancer-type: "Internal"
## Allow global access to the internal load balancer when needed.
# networking.gke.io/internal-load-balancer-allow-global-access: "true"
}
## Optional. Leave it blank to get next available random IP. ## Optional. Leave it blank to get next available random IP.
loadBalancerIP: "" loadBalancerIP: ""
## Set external traffic policy to: "Local" to preserve source IP on providers supporting it. ## Set external traffic policy to: "Local" to preserve source IP on providers supporting it.
@ -1419,6 +1466,12 @@ toolset:
kube-prometheus-stack: kube-prometheus-stack:
## Enable the kube-prometheus-stack chart ## Enable the kube-prometheus-stack chart
enabled: true enabled: true
## This applies to deployments which don't use helm's --namespace flag to set the namespace.
## If Pulsar's namespace is manually set using the `namespace` key, this setting should match the same namespace,
## otherwise Prometheus will not be able to scrape the Pulsar metrics due to RBAC restrictions.
## See https://prometheus-operator.dev/kube-prometheus/kube/monitoring-other-namespaces/ if you need to install
## kube-prometheus-stack in a different namespace than Pulsar.
# namespaceOverride: ""
## Manages Prometheus and Alertmanager components ## Manages Prometheus and Alertmanager components
prometheusOperator: prometheusOperator:
enabled: true enabled: true