Change Pulsar Proxy service load balancer type to ClusterIP (#588)
This commit is contained in:
Lari Hotari
GitHub
parent
976ba92e3b
commit
dd1325216f
@ -28,6 +28,7 @@ TLS=${TLS:-"false"}
|
||||
SYMMETRIC=${SYMMETRIC:-"false"}
|
||||
FUNCTION=${FUNCTION:-"false"}
|
||||
MANAGER=${MANAGER:-"false"}
|
||||
ALLOW_LOADBALANCERS=${ALLOW_LOADBALANCERS:-"false"}
|
||||
|
||||
source ${PULSAR_HOME}/.ci/helm.sh
|
||||
|
||||
@ -56,6 +57,7 @@ fi
|
||||
install_type="install"
|
||||
test_action="produce-consume"
|
||||
if [[ "$UPGRADE_FROM_VERSION" != "" ]]; then
|
||||
ALLOW_LOADBALANCERS="true"
|
||||
# install older version of pulsar chart
|
||||
PULSAR_CHART_VERSION="$UPGRADE_FROM_VERSION"
|
||||
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"
|
||||
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
|
||||
ci::check_pulsar_environment
|
||||
|
||||
|
||||
12
.ci/helm.sh
12
.ci/helm.sh
@ -424,6 +424,18 @@ function ci::test_pulsar_manager() {
|
||||
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() {
|
||||
# if kustomize is not installed, install kustomize to a temp directory
|
||||
if ! command -v kustomize &> /dev/null; then
|
||||
|
||||
156
README.md
156
README.md
@ -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.
|
||||
|
||||
## Important Security Disclaimer for Helm Chart Usage
|
||||
## Important Security Advisory for Helm Chart Usage
|
||||
|
||||
### 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
|
||||
|
||||
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.
|
||||
- **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
|
||||
|
||||
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
|
||||
|
||||
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.
|
||||
|
||||
|
||||
## Features
|
||||
|
||||
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:
|
||||
|
||||
```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
|
||||
@ -126,14 +207,49 @@ We provide some instructions to guide you through the preparation: http://pulsar
|
||||
## 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).
|
||||
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:
|
||||
|
||||
```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:
|
||||
|
||||
@ -144,7 +260,7 @@ We provide some instructions to guide you through the preparation: http://pulsar
|
||||
For more information, please follow our detailed
|
||||
[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
|
||||
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`.
|
||||
|
||||
```bash
|
||||
helm repo add apache https://pulsar.apache.org/charts
|
||||
helm repo add apachepulsar https://pulsar.apache.org/charts
|
||||
helm repo update
|
||||
helm get values <pulsar-release-name> > pulsar.yaml
|
||||
helm upgrade -f pulsar.yaml \
|
||||
<pulsar-release-name> apache/pulsar
|
||||
# get the existing values.yaml used for the most recent deployment
|
||||
helm get values -n <namespace> <pulsar-release-name> > values.yaml
|
||||
# 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.
|
||||
|
||||
## 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 .
|
||||
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:
|
||||
|
||||
@ -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 .
|
||||
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:
|
||||
|
||||
@ -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 .
|
||||
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:
|
||||
|
||||
@ -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 .
|
||||
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:
|
||||
|
||||
|
||||
@ -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
|
||||
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.
|
||||
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:
|
||||
|
||||
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
|
||||
Report issues to https://github.com/apache/pulsar-helm-chart/issues
|
||||
Please contribute improvements to https://github.com/apache/pulsar-helm-chart
|
||||
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.
|
||||
|
||||
---------------------------------------------------------------------------------------
|
||||
|
||||
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 }}.
|
||||
@ -21,9 +21,14 @@
|
||||
### K8S Settings
|
||||
###
|
||||
|
||||
### Namespace to deploy pulsar
|
||||
# The namespace to use to deploy the pulsar components, if left empty
|
||||
# will default to .Release.Namespace (aka helm --namespace).
|
||||
### Namespace to deploy Pulsar
|
||||
### Note: Prefer using helm's --namespace flag with --create-namespace instead
|
||||
## 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: ""
|
||||
namespaceCreate: false
|
||||
|
||||
@ -35,6 +40,7 @@ clusterDomain: cluster.local
|
||||
###
|
||||
|
||||
## 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
|
||||
## 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
|
||||
@ -90,10 +96,9 @@ volumes:
|
||||
|
||||
rbac:
|
||||
enabled: false
|
||||
psp: false
|
||||
psp: false # DEPRECATED: PodSecurityPolicy is not supported in Kubernetes 1.25+
|
||||
limit_to_namespace: true
|
||||
|
||||
|
||||
## AntiAffinity
|
||||
##
|
||||
## 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
|
||||
## the `affinity.anti_affinity` settings to `false` for that component.
|
||||
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
|
||||
# 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
|
||||
@ -1318,8 +1325,48 @@ proxy:
|
||||
http: 8080
|
||||
https: 8443
|
||||
service:
|
||||
annotations: {}
|
||||
type: LoadBalancer
|
||||
# Service type defaults to ClusterIP for security reasons.
|
||||
#
|
||||
# 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.
|
||||
loadBalancerIP: ""
|
||||
## Set external traffic policy to: "Local" to preserve source IP on providers supporting it.
|
||||
@ -1419,6 +1466,12 @@ toolset:
|
||||
kube-prometheus-stack:
|
||||
## Enable the kube-prometheus-stack chart
|
||||
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
|
||||
prometheusOperator:
|
||||
enabled: true
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user