JupyterHub packaged by Bitnami¶

JupyterHub brings the power of notebooks to groups of users. It gives users access to computational environments and resources without burdening the users with installation and maintenance tasks.

Overview of JupyterHub

Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.

TL;DR¶

使用加速地址添加仓库:

helm repo add bitnami "https://helm-charts.itboon.top/bitnami" --force-update
helm update bitnami

helm install my-release bitnami/jupyterhub

Introduction¶

Bitnami charts for Helm are carefully engineered, actively maintained and are the quickest and easiest way to deploy containers on a Kubernetes cluster that are ready to handle production workloads.

This chart bootstraps a JupyterHub Deployment in a Kubernetes cluster using the Helm package manager.

Bitnami charts can be used with Kubeapps for deployment and management of Helm Charts in clusters.

Learn more about the default configuration of the chart.

Looking to use JupyterHub in production? Try VMware Application Catalog, the enterprise edition of Bitnami Application Catalog.

Prerequisites¶

• Kubernetes 1.19+
• Helm 3.2.0+
• PV provisioner support in the underlying infrastructure

Installing the Chart¶

To install the chart with the release name my-release:

helm install my-release bitnami/jupyterhub

These commands deploy JupyterHub on the Kubernetes cluster in the default configuration. The Parameters section lists the parameters that can be configured during installation.

Tip: List all releases using helm list

Uninstalling the Chart¶

To uninstall/delete the my-release helm release:

helm uninstall my-release

The command removes all the Kubernetes components associated with the chart and deletes the release.

Parameters¶

Global parameters¶

Common parameters¶

Hub deployment parameters¶

Hub RBAC parameters¶

Hub Traffic Exposure Parameters¶

Hub Metrics parameters¶

Proxy deployment parameters¶

Proxy RBAC Parameters¶

Proxy Traffic Exposure Parameters¶

Proxy Metrics parameters¶

Image puller deployment parameters¶

Singleuser deployment parameters¶

Single User RBAC parameters¶

Single User Persistence parameters¶

Traffic exposure parameters¶

Auxiliary image parameters¶

JupyterHub database parameters¶

Specify each parameter using the --set key=value[,key=value] argument to helm install. For example,

helm install my-release \
  --set proxy.livenessProbe.successThreshold=5 \
    bitnami/jupyterhub

The above command sets the proxy.livenessProbe.successThreshold to 5.

Alternatively, a YAML file that specifies the values for the parameters can be provided while installing the chart. For example,

helm install my-release -f values.yaml bitnami/jupyterhub

Configuration and installation details¶

Rolling vs Immutable tags¶

It is strongly recommended to use immutable tags in a production environment. This ensures your deployment does not change automatically if the same tag is updated with a different image.

Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.

Configure authentication¶

The chart configures the Hub DummyAuthenticator by default, with the password set in the hub.password (auto-generated if not set) chart parameter and user as the administrator user. In order to change the authentication mechanism, change the hub.config.JupyterHub section inside the hub.configuration value.

Refer to the chart documentation for a configuration example.

Configure the Single User instances¶

As explained in the documentation, the Hub is responsible for deploying the Single User instances. The configuration of these instances is passed to the Hub instance via the hub.configuration chart parameter. The chart's singleuser section can be used to generate the hub.configuration value.

For more information, including how to provide a secret or a custom ConfigMap, refer to the chart documentation on configuring Single User instances.

Restrict traffic using NetworkPolicies¶

The Bitnami JupyterHub chart enables NetworkPolicies by default. This restricts the communication between the three main components: the Proxy, the Hub and the Single User instances. There are two elements that were left open on purpose:

• Ingress access to the Proxy instance HTTP port: by default, it is open to any IP, as it is the entry point to the JupyterHub instance. This behavior can be changed by tweaking the proxy.networkPolicy.extraIngress value.
• Hub egress access: As the Hub requires access to the Kubernetes API, the Hub can access to any IP by default (depending on the Kubernetes platform, the Service IP ranges can vary and so there is no easy way to detect the Kubernetes API internal IP). This behavior can be changed by tweaking the hub.networkPolicy.extraEgress value.

Use sidecars and init containers¶

If additional containers are needed in the same pod (such as additional metrics or logging exporters), they can be defined using the proxy.sidecars, hub.sidecars or singleuser.sidecars config parameters. Similarly, extra init containers can be added using the hub.initContainers, proxy.initContainers and singleuser.initContainers parameters.

Refer to the chart documentation for more information on, and examples of, configuring and using sidecars and init containers.

Configure Ingress¶

This chart provides support for Ingress resources for the JupyterHub proxy component. If an Ingress controller, such as nginx-ingress or traefik, that Ingress controller can be used to serve WordPress.

To enable Ingress integration, set proxy.ingress.enabled to true. The proxy.ingress.hostname property can be used to set the host name. The proxy.ingress.tls parameter can be used to add the TLS configuration for this host. It is also possible to have more than one host, with a separate TLS configuration for each host.

Learn more about configuring and using Ingress in the chart documentation.

Configure TLS secrets¶

This chart facilitates the creation of TLS secrets for use with the Ingress controller (although this is not mandatory). There are four common use cases:

• Helm generates/manages certificate secrets based on the parameters.
• User generates/manages certificates separately.
• Helm creates self-signed certificates and generates/manages certificate secrets.
• An additional tool (like cert-manager) manages the secrets for the application.

Refer to the chart documentation for more information on working with TLS.

Set pod affinity¶

This chart allows you to set your custom affinity using the hub.affinity and proxy.affinity parameters. Refer to the chart documentation on pod affinity.

Deploy extra resources¶

There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the extraDeploy parameter.

Troubleshooting¶

Find more information about how to deal with common errors related to Bitnami's Helm charts in this troubleshooting guide.

Upgrading¶

To 3.0.0¶

This major updates the PostgreSQL subchart to its newest major, 12.0.0. Here you can find more information about the changes introduced in that version.

To any previous version¶

Refer to the chart documentation for more information about how to upgrade from previous releases.

License¶

Copyright © 2023 VMware, Inc.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.