Helm Chart 部署指南:在 Kubernetes 上以 CRD 方式创建与管理 Cassandra 集群)
【免费下载链接】charts⚠️(OBSOLETE) Curated applications for Kubernetes项目地址https://gitcode.com/gh_mirrors/chart/charts点击查看免费下载本文以 charts 仓库中 incubator/cassandra-operator 目录下的 Helm Chart 为对象系统讲解 CassKop——Orange 开源的 Cassandra Kubernetes Operator——的完整部署、配置、验证、卸载与故障排查流程。你将掌握该 Chart 的全部可配置参数及其默认值、在 Helm 2/3 环境下的安装与 CRD 处理方式并结合仓库内真实的 Deployment、RBAC、CRD 模板源码理解 Operator 在集群内的运行形态与权限模型从而在自己的 Kubernetes 命名空间中快速交付一个可管理 Cassandra 集群的 Operator 底座。一、认识 CassKop面向 Cassandra 的 Kubernetes OperatorCassKopCassandra Kubernetes Operator是由 Orange 开源维护的 Kubernetes Operator用于在某个 Kubernetes 命名空间内创建、配置并管理 Cassandra 集群。它并不像普通应用那样只跑一个 Pod而是通过 Operator 模式监听一类自定义资源把「Cassandra 集群」这个高层概念映射为 Kubernetes 原生资源并持续协调其状态。在本仓库中Chart.yaml 对该 Chart 的描述为DEPRECATED A Helm chart for CassKop - the Orange Cassandra Kubernetes operatorchart 版本0.3.5应用版本0.3.1-master该 Chart 已被标记deprecated: true。同时仓库根目录与 README 顶部的归档声明明确指出截至 2020 年 11 月 13 日charts 仓库中的 Chart 不再更新。因此本文内容适用于学习、参考与在兼容环境中复用部署前应结合自身 Kubernetes 版本与安全策略评估。1.1 核心机制自定义资源 CassandraClusterOperator 的运作依赖一个自定义资源定义CRDcassandraclusters.db.orange.com它实现了名为CassandraCluster的 Kubernetes 自定义资源。CRD 清单位于 crds/db_v1alpha1_cassandracluster_crd.yaml关键字段如下apiVersionapiextensions.k8s.io/v1beta1早期 CRD API 版本适用于当时的主流集群groupdb.orange.comkindCassandraCluster复数形式cassandraclustersscopeNamespaced即 Cassandra 集群资源是命名空间级别的Operator 也以命名空间为管理边界versionv1alpha1annotationhelm.sh/hook: crd-install声明该 CRD 通过 Helm hook 在安装阶段安装详见下文 CRD 安装机制。部署好 Operator 之后用户只需提交一个CassandraCluster类型的 YAML 资源Operator 就会据此协调出对应的 Cassandra 集群这也是整个方案「以声明式方式管理 Cassandra」的入口。二、Chart 配置参数全景README 中给出了该 Chart 的全部可配置参数与默认值是部署前必读的配置清单。下表完整继承原文档并补充了仓库中的默认值细节参数描述默认值image.repositoryOperator 镜像仓库orangeopensource/cassandra-k8s-operatorimage.tag镜像标签0.3.1-masterimage.pullPolicy镜像拉取策略Alwaysimage.imagePullSecrets.enabled是否启用私有仓库拉取 Secretfalseimage.imagePullSecrets.name连接 Docker 私有仓库的 Secret 名称-未设置rbacEnable是否创建并使用 RBAC 资源trueresourcesPod 的资源 requests 与 limits{}values.yaml 中实际给出了默认请求值metricService是否为 metrics 部署 Servicefalsedebug.enabled是否开启 DEBUG 日志级别falsecreateCustomResource是否创建自定义资源Helm v3 下无需false2.1 从 values.yaml 看默认值与资源预算仓库中的 values.yaml 给出了与 README 表格对应的完整默认配置其中resources一项在 README 表格中写作{}但 values.yaml 实际内置了一组保守的默认值resources: requests: cpu: 10m memory: 50Mi limits: cpu: 1 memory: 512Mi也就是说Operator Pod 默认申请 10m CPU / 50Mi 内存上限为 1 CPU / 512Mi 内存——适合作为常驻控制面组件运行资源开销很低。你可以在安装时通过--set覆盖例如$ helm install --name casskop incubator/cassandra-operator \ --set resources.requests.cpu100m \ --set resources.limits.memory1Gi2.2 镜像相关参数image.repository与image.tag组合成最终镜像orangeopensource/cassandra-k8s-operator:0.3.1-master对应 deployment.yaml 中的image: {{ .Values.image.repository }}:{{ .Values.image.tag }}image.pullPolicy默认Always保证每次调度都拉取最新镜像适合 operator 这类迭代频繁的控制组件如追求稳定可改为IfNotPresent当 Operator 镜像存放在私有仓库时设置image.imagePullSecrets.enabled: true并填写image.imagePullSecrets.name模板会为 Pod 注入imagePullSecrets见 deployment.yamlimage: repository: orangeopensource/cassandra-k8s-operator tag: 0.3.1-master pullPolicy: Always imagePullSecrets: enabled: true name: my-registry-secret2.3 权限与可观测性参数rbacEnable: true默认同时创建 ServiceAccount、Role 与 RoleBinding。由于 CRD 是Namespaced作用域Operator 所需权限被收敛在单个命名空间内详见第七章的权限清单metricService: false默认置为true时会额外创建一个名为chart-metrics的 Service用于暴露 Operator 的 metrics 端口模板见 service.yamlService 端口为9710debug.enabled: false默认置为true时deployment.yaml 会向容器注入环境变量LOG_LEVELDebug开启 DEBUG 级日志方便排查 Operator 内部行为createCustomResource: false默认README 注释明确指出该参数为false时不创建自定义资源Helm v3 环境下无需创建CRD 需要独立管理不能依赖 chart 反复安装置为true时templates/crds.yaml 会遍历crds/*.yaml目录并将 CRD 清单渲染进安装结果。三、安装 Cassandra Operator3.1 安装前试运行Dry Run在真正部署前可以先对 Chart 做一次空跑检查渲染出的清单是否符合预期同时验证调试参数是否生效$ helm install --dry-run --debug.enabled incubator/cassandra-operator --set debug.enabledtrue --name casskop注意--debug.enabled在这里实际上是传入了--set debug.enabledtrue的效果原文档的写法属于笔误/拼写习惯配合--dry-run可以在不落盘的情况下预览最终资源。3.2 正式安装以 release 名casskop安装默认命名空间$ helm install --name casskop incubator/cassandra-operator该命令为 Helm v2 的语法使用--name指定 release 名。在 Helm v3 中release 名改为位置参数helm install casskop incubator/cassandra-operator。3.3 使用--set覆盖默认参数README 给出的示例用于覆盖镜像 tag$ helm install --replace --set image.tagasyncronous --name casskop incubator/cassandra-operator--set image.tagasyncronous将 Operator 镜像替换为asyncronous标签如调试分支镜像--replace允许复用已存在的 release 名当同名 release 已被记录时例如上次删除未 purgeHelm 会直接复用现有 release 并替换其资源而不是报「release 已存在」的错误。3.4 使用 values 文件安装除--set外更推荐维护一份独立的 values 文件便于版本管理与评审$ helm install --name casskop incubator/cassandra-operator -f values.yaml你可以在该文件中完整地覆盖上文第二章中的任意参数例如开启 RBAC、metrics Service 与私有仓库拉取image: tag: 0.3.1-master imagePullSecrets: enabled: true name: docker-registry-secret rbacEnable: true metricService: true createCustomResource: false debug: enabled: false resources: requests: cpu: 10m memory: 50Mi limits: cpu: 1 memory: 512Mi四、验证部署与查看状态4.1 列出已部署的 Chart$ helm list该命令列出当前集群中所有已部署的 release确认casskop出现在列表中且状态为DEPLOYED。4.2 查看 Helm 部署状态$ helm status casskop输出中会包含 release 的元信息、渲染的清单摘要以及 NOTES.txt 中定义的提示信息。Chart 自带的 NOTES 给出了推荐的健康检查方式Congratulations. You have just deployed CassKop the Cassandra Operator. Check its status by running: kubectl --namespace namespace get pods -l releasecasskop即通过 release 标签定位 Operator Pod。也可以用更直观的方式确认 Operator 就绪$ kubectl get pods -l releasecasskop -n namespace $ kubectl logs -l releasecasskop -n namespace4.3 Operator 的就绪与运行特征源码依据从 deployment.yaml 可以看到 Operator Pod 的几个关键运行特征replicas 固定为 1单副本控制面避免多实例同时协调同一批资源容器命令为cassandra-k8s-operatormetrics 端口容器暴露60000端口名为metricsreadinessProbe通过执行/health命令做就绪探测initialDelaySeconds: 4、periodSeconds: 10、failureThreshold: 1即启动 4 秒后开始探测每 10 秒一次一次失败即视为未就绪securityContextrunAsUser: 1000以非 root 用户运行符合最小权限实践核心环境变量见 deployment.yaml环境变量取值来源作用WATCH_NAMESPACEmetadata.namespacefieldRef 自动注入限定 Operator 监听哪个命名空间的资源POD_NAMEmetadata.namefieldRef 自动注入供 Operator 识别自身 PodOPERATOR_NAMEcassandra-operator写死Operator 身份标识LOG_LEVEL由debug.enabled决定为Debug时开启调试日志由此可以推断CassKop 采用「单命名空间监听」模式WATCH_NAMESPACE决定了它管辖的范围这与其 CRD 的Namespaced作用域设计是一致的。五、卸载 Chart 与 CRD 清理5.1 删除 Operator要删除 Operator直接删除其 Helm release 即可$ helm delete casskop该命令会移除 Chart 创建的所有 Kubernetes 组件Deployment、ServiceAccount、Role、RoleBinding 等并删除 Helm release 记录。5.2 CRD 需要手动清理重要警告README 明确指出Chart 创建的 CRD 默认不会被自动删除如有需要必须手动清理$ kubectl delete crd cassandraclusters.db.orange.com注意原 README 中此命令写作cassandraclusters.dfy.orange.com这属于文档笔误。仓库内 crds/db_v1alpha1_cassandracluster_crd.yaml 定义的 CRD 名称为cassandraclusters.db.orange.com实际执行应以该清单为准。这是全文档中风险最高的操作README 用连续多个感叹号强调如果删除 CRD将删除所有使用该 CRD 创建的 Cassandra 集群因为 CRD 是集群级资源一旦删除依赖它的全部CassandraCluster实例及其关联数据也随之消失。删除前务必确认所有 Cassandra 集群都已备份或迁移切勿在没有十足把握的情况下执行。5.3 彻底清理与 release 记录管理Helm 会永久保留 release 的历史记录因此查看已删除的 releasehelm list --deleted查看全部 release含已删除、已部署、已失败的helm list --all由于删除记录被保留release 名默认不能复用如确需复用可使用--replace标志它会复用现有 release 记录并替换其资源得益于这种记录保留机制删除的资源仍然可以回滚并重新激活rollback若希望彻底移除 release 记录使用 purge$ helm delete --purge casskop六、故障排查CRD 已存在时的处理6.1 典型报错默认情况下Chart 会通过 Helm hook 安装 CassKop 的 CRD。由于 CRD 是集群级全局资源当集群中已存在同名 CRD 时再次安装会报错$ helm install --name casskop incubator/cassandra-operator Error: customresourcedefinitions.apiextensions.k8s.io cassandraclusters.db.orange.com already exists这一场景在以下情况很常见同一集群先在其他命名空间部署过该 Chart、或 CRD 已由别的安装流程提前创建。6.2 解决方案跳过 hooksREADME 给出的标准解法是安装时跳过 hooks不再重复安装 CRD$ helm install --name casskop incubator/cassandra-operator --no-hooks配合 values 参数createCustomResource: false默认值即如此即可做到「只部署 Operator 本体不触碰已有 CRD」——这正是 Helm v3 下的推荐用法。6.3 从源码理解 CRD 安装机制仓库中的 CRD 清单 crds/db_v1alpha1_cassandracluster_crd.yaml 携带注解helm.sh/hook: crd-install这是 Helm 2 时代通过 hook 在正式安装前安装 CRD 的标准做法而 templates/crds.yaml 中的条件渲染逻辑{{- if .Values.createCustomResource }} {{- range $path, $bytes : .Files.Glob crds/*.yaml }} {{ $.Files.Get $path }} --- {{- end }} {{- end }}表明只有createCustomResourcetrue时才会把crds/目录下的 CRD 清单渲染进安装结果。两套机制结合的结果是默认配置createCustomResourcefalse下 Chart 不重复渲染 CRD安装报「CRD already exists」时应优先考虑使用--no-hooks或提前确认 CRD 是否由其他途径创建。七、深入源码Operator 的部署形态与权限模型为了在定制或排障时做到心中有数以下结合仓库模板源码梳理 Operator 实际落地的资源形态。7.1 命名的生成规则templates/_functions.tpl 定义了统一的命名助手cassandra-operator.name默认取.Chart.Name即cassandra-operator可通过nameOverride覆盖并截断到 63 字符cassandra-operator.fullname若设置了fullnameOverride则直接采用否则当 release 名包含 chart 名时直接用 release 名否则拼接为release-chartcassandra-operator.apiVersion固定返回cassandraclusters.db.orange.com/v1alpha1供其他资源引用 CRD 版本。所有资源的 label 统一包含app、chart、heritage: helm与release便于通过 label 筛选与关联。7.2 RBAC 权限模型当rbacEnabletrue默认时Chart 创建三件套ServiceAccountservice_account.yaml名为cassandra-operatorRolerole.yaml命名空间级角色授权范围包括db.orange.com组下的全部资源即 CRDcassandraclusters的全部操作核心组资源pods、pods/exec、services、endpoints、persistentvolumeclaims、events、configmaps、secrets的全部操作namespaces的get权限apps组的deployments、daemonsets、replicasets、statefulsets的全部操作policy组的poddisruptionbudgets的全部操作monitoring.coreos.com组的servicemonitors的get/create便于创建 ServiceMonitor 接入 Prometheus OperatorRoleBindingrolebinding.yaml将上述 Role 绑定到 ServiceAccountroleRef使用rbac.authorization.k8s.io组。从授权范围可以推断Operator 不仅创建 StatefulSet 形态的 Cassandra 节点还会管理 PVC、执行 Pod 内命令pods/exec、创建 Service/ConfigMap/Secret并可能创建 PodDisruptionBudget 与 ServiceMonitor——覆盖了 Cassandra 集群生命周期管理的主要对象。7.3 网络与可观测性若metricServicetrue会额外创建名为cassandra-operator-metrics的 Service将流量导向appcassandra-operator标签的 Pod端口为9710/TCP见 service.yaml而 Deployment 中容器实际监听的 metrics 端口为60000容器端口名metrics两者配合即可把 Operator 自身指标暴露给 Prometheus 体系。八、部署路线图总结结合 README 与仓库源码一次完整的 CassKop 部署生命周期可以概括为规划确认 Kubernetes 版本与 Helm 版本Helm v3 下将createCustomResource保持falseCRD 独立管理确认是否启用 RBAC、metrics Service、私有仓库拉取试运行helm install --dry-run ... --name casskop预览清单安装helm install --name casskop incubator/cassandra-operator -f values.yaml若报 CRD 已存在改用--no-hooks验证helm list、helm status casskop、kubectl get pods -l releasecasskop使用提交CassandraClustercassandraclusters.db.orange.com/v1alpha1自定义资源由 Operator 协调创建并管理 Cassandra 集群卸载helm delete casskop如需彻底清理则helm delete --purge casskopCRD 需手动kubectl delete crd cassandraclusters.db.orange.com——仅在确认所有集群数据已妥善处理的情况下执行排障关注LOG_LEVELDebugdebug.enabledtrue与/health就绪探针通过kubectl logs观察 Operator 协调日志。需要再次提醒的是本 Chart 与整个 charts 仓库均已进入归档状态文中命令以 README 记载的 Helm 2 时代语法为主迁移到 Helm 3 时请同步调整 install/delete 的语法在关键生产环境部署前请以当时集群版本为基准重新验证 CRD API 版本apiextensions.k8s.io/v1beta1与 RBAC 资源版本rbac.authorization.k8s.io/v1beta1/v1的兼容性。赞分享【免费下载链接】charts⚠️(OBSOLETE) Curated applications for Kubernetes项目地址https://gitcode.com/gh_mirrors/chart/charts点击查看免费下载相关推荐AG-UI × CrewAI 集成 0.3.1 版本深度解读状态保留、端点增强与并发治理AG UI × CrewAI 集成 0.3.1 版本深度解读状态保留、端点增强与并发治理 导读 本文以 ag ui crewai 0.3.1 的 CHANGE云原生容器编排使用 Helm 在 Kubernetes 上部署 StarRocks 集群Operator 与 kube-starrocks Chart 实战指南使用 Helm 在 Kubernetes 上部署 StarRocks 集群Operator 与 kube starrocks Chart 实战指南 Helm数据库OLAP数据仓库大数据湖仓一体数据分析在 Meshery 中以 Design 方式部署 Eclipse Ditto OperatorHelm Chart 0.3.0架构解析与 CRD 配置指南在 Meshery 中以 Design 方式部署 Eclipse Ditto OperatorHelm Chart 0.3.0架构解析与 CRD 配置指南云原生微服务运维DevOps上一篇【亲测免费】 推荐开源项目CppRl - PyTorch C强化学习框架下一篇探秘赛马娘世界的神奇插件Trainers Legend G创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考