云原生容器编排【免费下载链接】chartsBitnami Helm Charts项目地址https://gitcode.com/GitHub_Trending/charts30/charts点击查看免费下载JupyterHub 为多用户群体提供共享的 Notebook 计算环境让每个用户都能按需获得独立的 Jupyter Notebook 实例而无需自行安装维护任何组件。Bitnami 维护的 jupyterhub Helm Chart 将 JupyterHub 以标准化的 Kubernetes 原生方式打包部署本文基于本仓库bitnami/jupyterhub目录下的 CHANGELOG.md 与 README.md系统梳理该 Chart 从 0.1.0 到 10.x 的完整版本演进脉络、每一代 major 版本引入的破坏性变更与安全强化并结合 values.yaml 与templates/下的实现源码给出可直接落地的部署、认证、存储、监控与升级配置方案。读完本文你将能独立完成 JupyterHub 的 Helm 部署、理解各版本升级的迁移要点并针对生产环境定制单用户实例、网络策略与 Prometheus 监控。一、Chart 概览与架构当前仓库中的 jupyterhub ChartChart.yaml版本为10.0.6appVersion为5.3.0即内置的 JupyterHub 本体版本许可协议为 Apache-2.0。Chart 依赖postgresql16.x条件开关postgresql.enabled与common2.xBitnami 公共辅助库两个子图并声明了四类镜像jupyterhubHub 主进程、configurable-http-proxy代理、jupyter-base-notebook单用户镜像与os-shell辅助镜像。Chart 部署三个基本组件详见 README.mdJupyterHubHubChart 的中心组件负责认证管理并通过 KubeSpawner 调用 Kubernetes API 动态创建、管理单用户 Notebook 实例Single User因此 Hub 需要专门的 RBAC 权限对应 templates/hub/role.yaml、templates/hub/rolebinding.yaml 与 templates/hub/deployment.yaml。Proxy用户的外部入口基于 configurable-http-proxy 实现负责在 Hub 与各单用户实例之间路由通信部署见 templates/proxy/deployment.yaml。Image Puller一个 DaemonSet在集群每个节点上预拉取单用户运行所需的镜像从而显著缩短用户 Notebook 的启动时间实现见 templates/image-puller/daemonset.yaml。从源码看Image Puller 的每个 Pod 通过两个 initContainer 分别预拉取singleuser.image与auxiliaryImagedaemonset.yaml主容器则是一个sleep infinity的 pause 容器保证镜像在节点上常驻。用户登录并启动 Notebook 后流量路径为Proxy → Hub → Single User 实例。二、快速部署与访问最小化安装只需一行命令以 Bitnami 官方 OCI 仓库为例helm install my-release oci://registry-1.docker.io/bitnamicharts/jupyterhub也可以改用本仓库的本地 Chart 目录helm install my-release bitnami/jupyterhub环境前提Kubernetes 1.23、Helm 3.8.0且底层基础设施支持 PV 供给单用户持久化默认开启。部署后Chart 的 NOTES.txt 会给出访问方式默认proxy.service.public.type为LoadBalancer等待外部 IP 关联到release-proxy-public服务后即可访问http://$SERVICE_IP/若为NodePort使用kubectl get svc ... -o jsonpath{.spec.ports[0].nodePort}获取端口若为ClusterIP可通过kubectl port-forward svc/release-proxy-public 8080:port本地访问。三、认证机制演进从 DummyAuthenticator 到 SharedPasswordAuthenticator10.0.0 的破坏性变更10.0.02025-07-02是 Chart 近一年来最重要的 major 变更默认认证器由已废弃的 DummyAuthenticator 更换为 SharedPasswordAuthenticatorCHANGELOG.md 对应 PR #34649。这一决策在 README.md 的 Upgrading 章节有明确说明且强制要求密码长度至少 32 个字符。从 values.yaml 的hub.configuration默认模板可以看到实际落地方式hub: config: JupyterHub: admin_access: true authenticator_class: shared-password SharedPasswordAuthenticator: admin_users: - user # 取自 hub.adminUser默认 user admin_password: ... # 取自 hub.password未设置时由 randAlphaNum 32 随机生成 Authenticator: admin_users: - user allow_all: truehub.adminUser默认user与hub.password默认空自动生成 32 位随机密码是管理员入口登录密码可通过安装后执行 NOTES.txt 中给出的命令从release-hub这个 Secret 中解码读取kubectl get secret --namespace ns release-hub -o jsonpath{.data[values\.yaml]} | base64 -d | awk -F: /password/ {gsub(/[ \t]/, , $2);print $2}替换为其他认证器要更换认证机制改写hub.configuration中的hub.config.JupyterHub段即可。例如切换到 NativeAuthenticator 并配置管理员test示例来自 README.md 的 Configure authentication 章节hub: configuration: | hub: config: JupyterHub: admin_access: true authenticator_class: nativeauthenticator.NativeAuthenticator Authenticator: admin_users: - test部署后需先完成注册sign up来为test设置密码。这套配置由 Hub 的jupyterhub_config.py消费脚本本体位于 templates/hub/configmap.yaml该文件同时提供z2jh.py辅助模块get_config、get_secret_value、set_config_if_not_none等工具函数供hub.extraConfig动态注入的 Python 代码复用。升级时的凭据保留Chart 在升级时会复用先前渲染出的 Secret 或hub.existingSecret中指定的凭据因此升级后管理员密码不会丢失。若要更新凭据有两种方式见 README 的 Update credentials 章节在hub.configuration中修改认证段后执行helm upgrade或提供包含新配置的hub.existingSecret后执行helm upgrade。四、安全与合规能力的版本演进安全强化是近三个 major 版本的主线逐代梳理如下。7.0.0安全默认值全面收紧2024-04-03runAsGroup从0改为1001readOnlyRootFilesystem默认设为trueresourcesPreset从none提升到测试套件可运行的最小预设注意预设值仅用于快速启动生产环境应使用resources手工指定global.compatibility.openshift.adaptSecurityContext由disabled改为auto检测到 OpenShift 集群时自动移除runAsUser/runAsGroup/fsGroup以兼容 restricted-v2 SCCNetworkPolicy 各组件默认enabledtrue且整体归一化默认放行 EgressIngress 仅放行containerPorts中声明的端口。上述默认值在当前 values.yaml 中均有体现例如hub.containerSecurityContext的runAsUser: 1001、readOnlyRootFilesystem: true、capabilities.drop: [ALL]、seccompProfile.type: RuntimeDefault以及global.compatibility.openshift.adaptSecurityContext: auto。5.x 系列PSA restricted 与 OpenShift 兼容5.5.0新增对PSA restricted策略的兼容Pod Security Admission5.6.0将 ServiceAccount token 的自动挂载移到 Pod 声明层级automountServiceAccountToken默认false5.6.1为 OpenShift 兼容将seLinuxOptions置空5.6.4修复 OpenShift 集群下的 securityContext 渲染6.1.0自动适配 OpenShift restricted-v2 SecurityContext相关注释与渲染逻辑在 configmap.yaml 的uid/fsGid条件分支与common.compatibility.renderSecurityContext调用中5.9.0新增readOnlyRootFilesystem支持5.7.0引入resourcesPreset资源预设none/nano/micro/small/medium/large/xlarge/2xlarge5.8.0统一 bump 所有版本5.8.1修复全局镜像仓库在 jupyterhub 配置中不生效的问题。8.1.0镜像验证8.1.0引入安全镜像校验替换 Bitnami 原始镜像时会输出告警common.warnings.modifiedImages若确实需要跳过校验将global.security.allowInsecureImages设为true对应 NOTES.txt 中的common.errors.insecureImages校验。README 同时强调生产环境强烈建议使用不可变immutable镜像 tag避免同一 tag 被更新后导致部署内容漂移。五、单用户实例存储、资源与扩展配置配置传递链路单用户实例由 Hub 通过 KubeSpawner 动态创建其配置经由hub.configuration传给 Hub。Chart 为遵循 Bitnami 的 values 规范单独抽出singleuser段并在渲染hub.configuration时自动拼接configmap.yaml 的singleuser:子段。若提供了自定义hub.configuration或hub.existingSecret/hub.existingConfigmap则singleuser段将被忽略。存储配置singleuser.persistence默认enabledtrue创建动态供给的 PVCstorage.type: dynamic默认大小10Gi、访问模式ReadWriteOnce、storageClass留空以使用默认供给器如 AWS 的 gp2、GKE 的标准存储类。PVC 名称模板为fullname-claim-{username}{servername}挂载目录即singleuser.notebookDir默认/opt/bitnami/jupyterhub-singleuser。从 configmap.yaml 可看到动态存储的实际接线设置c.KubeSpawner.storage_pvc_ensure True并通过pvc_name_template、storage_capacity、storage_access_modes等属性映射到 KubeSpawner。资源与调度singleuser.resourcesPreset默认small生产环境建议用singleuser.resources显式指定 requests/limitssingleuser.tolerations、nodeSelector会注入singleuser.extraTolerations、nodeSelector通过singleuser.initContainers、sidecars可在用户 Pod 中加入自定义 init 容器与边车额外边车在配置中映射为extraContainerssingleuser.extraEnvVars为用户 Pod 注入环境变量映射为extraEnv。profileList多档计算资源配置5.2.0起支持在singleuser中定义profileList让用户在登录后自选 Notebook 镜像与资源配置。示例见 values.yaml 注释singleuser: profileList: - display_name: Profile 1 description: Longer description for profile 1. default: true - display_name: Profile 2 description: Longer description for profile 2. kubespawner_override: image: jupyter/datascience-notebook:latest该列表最终映射为c.KubeSpawner.profile_listconfigmap.yaml。六、数据库内嵌 PostgreSQL 与外部数据库JupyterHub 元数据用户、服务、服务器状态默认存于随 Chart 部署的 PostgreSQL。Chart 通过postgresql子图提供数据库默认账号bn_jupyterhub、库名bitnami_jupyterhub、架构standalone。hub.configuration中的db段使用ternary表达式在postgresql.enabled为 true 时拼接内嵌库的连接串否则取externalDatabase.*values.yaml。接入外部 PostgreSQL 时设置postgresql.enabledfalse与externalDatabase.host/port/user/password/database或用externalDatabase.existingSecret保存凭据对应模板 templates/hub/externaldb-secrets.yaml。9.0.8修复了使用外部 PostgreSQL 时 initContainer 的兼容问题——Hub Deployment 默认带一个wait-for-dbinitContainer 等待数据库就绪避免 Hub 因数据库未就绪而 CrashLoopback见 deployment.yaml。七、监控Prometheus 与 ServiceMonitor0.2.02021-10-05引入对 hub 与 proxy 的 Prometheus 监控。集成方式如下README.md 的 Prometheus metrics 章节设置hub.metrics.serviceMonitor.enabledtrue与proxy.metrics.serviceMonitor.enabledtrue以生成 ServiceMonitor 对象对应模板 templates/hub/servicemonitor.yaml 与 templates/proxy/servicemonitor.yamlHub 指标路径默认/hub/metricsProxy 指标路径默认/metrics抓取间隔默认30s若集群未安装 Prometheus Operator 的 CRD部署会报no matches for kind ServiceMonitor in version monitoring.coreos.com/v1此时应先在集群中安装 Prometheus Operator如 Bitnami 的 kube-prometheus Charthub.metrics.authenticatePrometheus控制 Prometheus 抓取是否需要认证。此外Proxy 容器固定监听8002metrics 端口对应proxy.containerPort.metrics与proxy.service.metrics.ports.http。八、网络策略与流量暴露Chart 默认开启三个组件的 NetworkPolicyhub/proxy/imagePuller/singleuser各networkPolicy.enabled: true限制 Proxy、Hub 与单用户实例之间的通信。README 特别指出两处有意放开Proxy HTTP 端口的 Ingress 默认对所有 IP 开放因为它就是 JupyterHub 的对外入口可通过proxy.networkPolicy.extraIngress收紧Hub 的 Egress 默认可访问任意 IP因为 Hub 需要访问 Kubernetes API 而各平台 API 地址段不可枚举可通过hub.networkPolicy.extraEgress限制。singleuser.networkPolicy.allowCloudMetadataAccess默认false且singleuser配置中的cloudMetadata.blockWithIptables默认false若将其置为truejupyterhub_config.py会在用户 Pod 中注入一个特权 initContainer 用 iptables 阻断到云元数据服务169.254.169.254:80的访问configmap.yaml。对外暴露方面proxy.service.public.type默认LoadBalancer端口 80若希望以域名访问开启proxy.ingress.enabledtrue并配置proxy.ingress.hostname默认jupyterhub.local、tls、ingressClassName等支持extraHosts/extraPaths/extraTls/extraRules多域名多路径场景。TLS 证书可按 README 的 Configure TLS secrets 章节以四种方式管理Chart 参数生成、外部预建 Secret命名ingress-hostname-tls、cert-manager 注解自动签发、或proxy.ingress.selfSignedtrue由 Helm 生成自签证书。九、其他重要功能变更汇总按时间线补充 CHANGELOG 中值得关注的其余变更版本时间核心变更9.0.02025-04-14JupyterHub 与 Jupyter Base Notebook 镜像升级到 5.x9.0.1 更新jupyterhub_config.py与z2jh.py9.0.62025-05-06更新 common 依赖并移除对 Kubernetes 1.23 的引用9.0.72025-05-07修复单用户镜像的 imagePullSecrets9.0.82025-05-12initContainer 支持外部 PostgreSQL8.0.02024-10-03PostgreSQL 子图升级到 17.x对应子图 16.0.07.2.02024-06-05新增 PodDisruptionBudgethub.pdb.create/proxy.pdb.create默认 true7.2.9 / 7.2.102024-07-16全局 StorageClass 作为默认值修复storage.classhelper7.2.172024-08-28修复单用户 extra volumes 与 mounts 的缩进7.2.152024-08-23修复禁用 PostgreSQL 时Flux/ArgoCD 场景postgres 镜像缺失问题7.1.12024-05-23Hub 使用不同的 liveness/readiness 探针tcpSocket 与 httpGet/hub/health分离见 deployment.yaml7.1.22024-05-24移除 sleep 探针5.3.02024-01-03为 hub 的 Secret 补齐 service API tokens5.6.2 / 5.6.32024-01-27/31修复外部数据库配置生成4.2.02023-08-23支持自定义标准标签commonLabels4.1.52023-06-26新增 proxy 的 serviceAccount 配置3.0.82023-01-31升级时不再重新生成自签证书3.0.62023-01-20为 Image Puller Job 的 initContainer 增加资源声明3.0.22022-11-21修复 NetworkPolicy 的 apiVersion 硬编码2.0.02022-09-28纳入 JupyterHub 3.x1.4.02022-08-22镜像支持按 digest而非仅 tag引用1.3.02022-05-27补充缺失的 service 参数1.1.02022-03-08Chart 全面标准化对齐 Bitnami common 模板1.0.02022-03-02PostgreSQL 子图升级主版本号从 0.x 进入 1.x0.4.02022-01-05模板格式统一0.3.02021-11-18新增ingressClassName支持新版 cert-manager 方式0.2.22021-10-17修复proxy.service.public.type0.2.02021-10-05引入 Prometheus ServiceMonitorhub 与 proxy0.1.x2021-04 ~ 08修复存储类、TKG 兼容、imagePullSecrets、extraIngress/extraEgress 默认值等早期问题0.1.02021-04-23Chart 首次发布十、升级指南关键 major 版本迁移升级到 10.0.0默认认证器切换为 SharedPasswordAuthenticator且强制密码不少于 32 字符。升级时只要设置了合规的密码hub.password或 Secret 中已有的密码一般不会出现其他问题。升级到 8.0.0 / 6.0.0 / 5.0.0 / 3.0.0 / 1.0.0PostgreSQL 子图大版本这五个 major 的共同点是升级捆绑的 PostgreSQL 子图主版本17.x、14.x、13.x、12.x、11.x。升级前请先查阅对应 PostgreSQL 版本的官方升级说明并在升级后确认数据库数据可正常访问。以历史版本 1.0.0 的官方升级流程为例源自 README.md 的 Upgrading Instructions这类升级需要复用旧 PVC 以保留数据核心步骤为导出当前凭据与 PVC 名称export JUPYTERHUB_PASSWORD$(kubectl get secret --namespace default jupyterhub-hub -o jsonpath{.data[values\.yaml]} | base64 --decode | awk -F: /password/ {gsub(/[ \t]/, , $2);print $2} | tr -d ) export POSTGRESQL_PASSWORD$(kubectl get secret --namespace default jupyterhub-postgresql -o jsonpath{.data.postgresql-password} | base64 --decode) export POSTGRESQL_PVC$(kubectl get pvc -l app.kubernetes.io/instancejupyterhub,app.kubernetes.io/namepostgresql,roleprimary -o jsonpath{.items[0].metadata.name})保留 PVC 删除 StatefulSet 与 Secretkubectl delete statefulsets.apps --cascadefalse jupyterhub-postgresql kubectl delete secret jupyterhub-postgresql --namespace default用原 PostgreSQL 版本参数执行升级后续升级可参照此模式改为对应目标版本CURRENT_PG_VERSION$(kubectl exec jupyterhub-postgresql-0 -- bash -c echo $BITNAMI_IMAGE_VERSION) helm upgrade jupyterhub bitnami/jupyterhub \ --set hub.password$JUPYTERHUB_PASSWORD \ --set postgresql.image.tag$CURRENT_PG_VERSION \ --set postgresql.auth.password$POSTGRESQL_PASSWORD \ --set postgresql.persistence.existingClaim$POSTGRESQL_PVC删除旧 Pod等待新 StatefulSet 重建并接管 PVCkubectl delete pod jupyterhub-postgresql-0升级到 7.0.0安全默认值变更runAsGroup、readOnlyRootFilesystem、resourcesPreset、OpenShift 适配、NetworkPolicy 归一化可能影响自定义或 init 脚本。若受影响可在升级时显式回退旧默认值。另外更新策略默认RollingUpdate若 Deployment 挂载了 RWO PV单副本滚动更新可能因旧 Pod 仍占用 PV 而卡住此时应将updateStrategy.type改为Recreatevalues.yaml 中 hub/proxy/imagePuller 三个组件均有对应注释说明。十一、生产落地建议结合以上演进脉络与当前默认配置给出面向生产环境的部署清单认证使用hub.password显式设置 ≥32 字符的管理员密码或接入企业认证器如 NativeAuthenticator、OAuthenticator替换默认的 SharedPasswordAuthenticator镜像固定不可变 tag不依赖滚动 tag如需私有镜像仓库统一使用global.imageRegistry/global.imagePullSecrets或为 hub/proxy/singleuser/auxiliaryImage 分别设置image.pullSecrets资源以hub.resources、proxy.resources、singleuser.resources显式声明 requests/limits替代默认的resourcesPresetREADME 明确提示预设不适用于生产存储确认底层 StorageClass 可动态供给为不同用户组规划singleuser.persistence.size或通过profileList提供多档配置网络按需收紧proxy.networkPolicy.extraIngress与hub.networkPolicy.extraEgress并评估singleuser.networkPolicy.allowCloudMetadataAccess监控部署 Prometheus Operator 后开启hub.metrics.serviceMonitor.enabled与proxy.metrics.serviceMonitor.enabled并利用 Hub 内置的 idle-culler默认开启timeout: 3600、every: 600回收空闲服务器资源备份恢复数据集中在 PostgreSQL PVC 与单用户 PVC 上可借助 Velero 对 PersistentVolume 做备份与迁移详见 README 的 Backup and restore 章节。以上配置与约束均来自当前仓库的 CHANGELOG.md、README.md、values.yaml 及templates/目录下的模板源码可对照文件继续深入研读。赞分享云原生容器编排【免费下载链接】chartsBitnami Helm Charts项目地址https://gitcode.com/GitHub_Trending/charts30/charts点击查看免费下载相关推荐Bitnami GitLab Runner Helm Chart 部署与配置实战从版本演进到 Kubernetes 执行器Bitnami GitLab Runner Helm Chart 部署与配置实战从版本演进到 Kubernetes 执行器 本篇文章围绕当前仓库中 Bitna云原生容器编排Bitnami Etcd Helm Chart 版本演进与运维实战全解析Bitnami Etcd Helm Chart 版本演进与运维实战全解析 etcd 是一个分布式键值存储系统以高可靠性、容错性和易用性著称广泛用于生产环境。云原生容器编排Android安全工具分类标准争议如何选择正确的安全分析工具Android安全工具分类标准争议如何选择正确的安全分析工具 在Android应用安全领域选择合适的工具是确保应用安全的关键第一步。Android安全工具云原生容器编排上一篇REST API版本控制策略Microsoft官方指南与实践案例下一篇rkt 性能基准测试与剖析指南用 rkt-monitor 量化 v1.4.0 容器资源开销创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考