从入门到实践:创作一个自己的 Helm Chart

前言

我们平时在日常生活中会经常在不同的平台上与各种各样的应用打交道,比如从苹果的 App Store 里下载的淘宝、高德、支付宝等应用,或者是在 PC 端安装的 Word、Photoshop、Steam。这些各类平台上的应用程序,对用户而言,大多只需要点击安装就可使用。

file

然而,在云 (Kubernetes)上,部署一个应用往往却不是那么简单。如果想要部署一个应用程序到云上,首先要准备好它所需要的环境,打包成 Docker 镜像,进而把镜像放在部署文件 (Deployment) 中、配置服务 (Service)、应用所需的账户 (ServiceAccount) 及权限 (Role)、命名空间 (Namespace)、密钥信息 (Secret)、可持久化存储 (PersistentVolumes) 等资源。也就是编写一系列互相相关的 YAML 配置文件,将它们部署在 Kubernetes 集群上。

但是即便应用的开发者可以把这些 Docker 镜像存放在公共仓库中,并且将所需的 YAML 资源文件提供给用户,用户仍然需要自己去寻找这些资源文件,并把它们一一部署。倘若用户希望修改开发者提供的默认资源,比如使用更多的副本 (Replicas) 或是修改服务端口 (Port),他还需要自己去查需要在这些资源文件的哪些地方修改,更不用提版本变更与维护会给开发者和用户造成多少麻烦了。

可见最原始的 Kubernetes 应用形态并不便利。

Helm 与 Helm Chart

file

在这样的大环境下,有一系列基于 Kubernetes 的应用包管理工具横空出世。而我们今天的主角 Helm,就是这其中最受欢迎的选择之一。

file

开发者按照 Helm Chart 的格式,将应用所需的资源文件包装起来,通过模版化 (Templating) 的方式将一些可变字段(比如我们之前提到的暴露哪个端口、使用多少副本)暴露给用户,最后将封装好的应用包,也就是 Helm Chart,集中存放在统一的仓库中供用户浏览下载。

站在用户角度,用户只需要一行简单的命令就可以完成应用的安装、卸载与升级。对于安装之后状态,也可以通过 helm list 或者是原生的 kubectl 进行查询。

$ helm install redis stable/redis
$ kubectl get pods
NAME                  READY       STATUS     RESTARTS           AGE
redis-master-0        1/1         Running    0                  63s
redis-slave-0-0       1/1         Running    0                  63s
redis-slave-1-0       1/1         Running    0                  13s
$ helm delete redis

创作 Helm Chart

那么站在开发者的角度上,我们应该如何去创作一个 Helm 应用包呢?

file

准备工作

首先我们需要一个准备部署的镜像。这个镜像可以是一个 Java 程序、一个 Python 脚本、甚至是一个空的 linux 镜像跑几条命令。

file

这里我们使用一个简单的基于 golang 的 hello world HTTP 服务。该服务通过读取环境变量 USERNAME 获得用户自己定义的名称,然后监听 80 端口。对于任意 HTTP 请求,返回 Hello ${USERNAME}。比如如果设置 USERNAME=world(默认场景),该服务会返回 Hello world。

然后我们使用 Dockerfile 对镜像进行打包。先对 Golang 代码进行编译,然后将编译后的程序放在基于 alpine 的镜像中,以缩小镜像体积。file

在 Docker 构建好镜像之后,我们把镜像上传到仓库中,比如 Docker Hub 或是阿里云容器镜像仓库。准备工作做好之后,我们就可以开始创作 Helm Chart 了。

开始创作

运行 helm create my-hello-world,会得到一个 helm 自动生成的空 chart。这个 chart 里的名称是 my-hello-world。 需要注意的是,Chart 里面的 my-hello-world 名称需要和生成的 Chart 文件夹名称一致。如果修改 my-hello-world,则需要做一致的修改。 现在,我们看到 Chart 的文件夹目录如下:

my-hello-world
├── charts
├── Chart.yaml
├── templates
│   ├── deployment.yaml
│   ├── _helpers.tpl
│   ├── ingress.yaml
│   ├── NOTES.txt
│   └── service.yaml
└── values.yaml

在根目录下的 Chart.yaml 文件内,声明了当前 Chart 的名称、版本等基本信息,这些信息会在该 Chart 被放入仓库后,供用户浏览检索。比如我们可以把 Chart 的 Description 改成 "My first hello world helm chart"。在 Chart.yaml 里有两个跟版本相关的字段,其中 version 指明的是 Chart 的版本,也就是我们应用包的版本;而 appVersion 指明的是内部实际使用的应用版本。

在 templates 文件夹内存放了各类应用部署所需要使用的 YAML 文件,比如 Deployment 和 Service。在我们当前的应用内,我们只需要一个 deployment,而有的应用可能包含不同组件,需要多个 deployments,那么我们就可以在 templates 文件夹下放置 deploymentA、deploymentB 等。同样的,如果我们需要配置 serviceaccount, secret, volumes 等内容,也可以在里面添加相应的配置文件。

apiVersion: apps/v1beta2
kind: Deployment
metadata:
 name: {{ template "my-hello-world.fullname" . }}
 labels:
{{ include "my-hello-world.labels" . | indent 4 }}
spec:
 replicas: {{ .Values.replicaCount }}
 selector:
   matchLabels:
     app.kubernetes.io/name: {{ include "my-hello-world.name" . }}
     app.kubernetes.io/instance: {{ .Release.Name }}
 template:
   metadata:
     labels:
       app.kubernetes.io/name: {{ include "my-hello-world.name" . }}
       app.kubernetes.io/instance: {{ .Release.Name }}
   spec:
     containers:
       - name: {{ .Chart.Name }}
         image: "{{ .Values.image.repository }}:{{ .Chart.AppVersion }}"
         imagePullPolicy: {{ .Values.image.pullPolicy }}
         env:
           - name: USERNAME
             value: {{ .Values.Username }}
......

Helm Chart 对于应用的打包,不仅仅是将 Deployment 和 Service 以及其它资源整合在一起。我们看到 deployment.yaml 和 service.yaml 文件被放在 templates/ 文件夹下,相较于原生的 Kubernetes 配置,多了很多渲染所用的可注入字段。比如在 deployment.yaml 的 spec.replicas 中,使用的是 .Values.replicaCount 而不是 Kubernetes 本身的静态数值。这个用来控制应用在 Kubernetes 上应该有多少运行副本的字段,在不同的应用部署环境下可以有不同的数值,而这个数值便是由注入的 Values 提供。

replicaCount: 1
image:
 repository: somefive/hello-world
 pullPolicy: IfNotPresent
nameOverride: ""
fullnameOverride: ""
service:
 type: ClusterIP
 port: 80
......
Username: AppHub

在根目录下我们看到有一个 values.yaml 文件,这个文件提供了应用在安装时的默认参数。在默认的 Values 中,我们看到 replicaCount: 1,说明该应用在默认部署的状态下只有一个副本。

为了使用我们要部署应用的镜像,我们看到 deployment.yaml 中,在 spec.template.spec.containers 里, image 和 imagePullPolicy 都使用了 Values 中的值。其中 image 字段由 .Values.image.repository 和 .Chart.AppVersion 组成。

看到这里,同学们应该就知道需要变更的字段了:一个是位于 values.yaml 内的 image.repository,另一个是位于 Chart.yaml 里的 AppVersion。将它们与我们需要部署应用的 docker 镜像匹配起来,这里我们把 values.yaml 里的 image.repository 设置成 somefive/hello-world,把 Chart.yaml 里的 AppVersion 设置成 1.0.0 即可。

类似的,我们可以查看 service.yaml 内要部署的服务,其中的主要配置也在 values.yaml 中。默认生成的服务将 80 端口暴露在 Kubernetes 集群内部。我们暂时不需要对这一部分进行修改。

由于部署的 hello-world 服务会从环境变量中读取 USERNAME 环境变量,所以将这个配置加入 deployment.yaml。

- name: {{ .Chart.Name }}
  image: "{{ .Values.image.repository }}:{{ .Chart.AppVersion }}"
  imagePullPolicy: {{ .Values.image.pullPolicy }}
  env:
  - name: USERNAME
    value: {{ .Values.Username }}

现在我们的 deployment.yaml 模版会从 values.yaml 中加载 Username 字段,因此相应的,我们也在 values.yaml 中添加 Username: AppHub。这样,我们的应用就会从 values.yaml 中读取 Username,把它放入镜像的环境变量中启动了。

校验打包

在准备好我们的应用后,我们可以使用 Helm lint 来粗略地检查一下制作的 Chart 有没有什么语法上的错误。如果没有问题的话,就可以使用 helm package 命令对我们的 Chart 文件夹进行打包,打包后我们可以得到一个 my-hello-world-0.1.0.tgz 的应用包。这个便是我们完成的应用了。

$ helm lint --strict my-hello-world
1 chart(s) linted, 0 chart(s) failed
    [INFO] Chart.yaml: icon is recommended
$ helm package my-hello-world

我们可以使用 helm install 命令尝试安装一下刚刚做好的应用包,然后用 kubectl 查看一下运行 pod 的状态。通过 port-forward 命令将该 pod 的端口映射到本地端口上,这个时候就可以通过访问 localhost 来访问部署好的应用了。

$ helm install my-hello-world-chart-test my-hello-world-0.1.0.tgz
$ kubectl get pods
NAME                                          READY    STATUS     RESTARTS    AGE
my-hello-world-chart-test-65d6c7b4b6-ptk4x-0  1/1      Running    0           4m3s
$ kubectl port-forward my-hello-world-chart-test-65d6c7b4b6-ptk4x 8080:80
$ curl localhost:8080
Hello AppHub

参数重载

有的同学可能会有疑惑,虽然我们应用开发者把可配置的信息暴露在 values.yaml 中,用户使用应用的时候想要修改该怎么办呢?答案很简单,用户只需要在 install 时使用 set 参数,设置想要覆盖的参数即可。

应用开发者在 Chart 的 values 配置中只是提供了默认的安装参数,用户也可以在安装时指定自己的配置。类似的,如果用户可以用 upgrade 命令替代 install,实现在原有部署好的应用的基础上变更配置。

$ helm install my-app my-hello-world-0.1.0.tgz --set Username="Cloud Native"
$ helm install my-super-app my-hello-world-0.1.0.tgz -f my-values.yaml
$ helm upgrade my-super-app my-hello-world-0.1.0.tgz -f my-new-values.yaml

修改提示信息

我们注意到在安装 Chart 指令运行后,屏幕的输出会出现:

NOTES:
1. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods -l "app=my-hello-world,release=my-hello-world-chart-test2" -o jsonpath="{.items[0].metadata.name}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl port-forward $POD_NAME 8080:80

这里的注释是由 Chart 中的 templates/NOTES.txt 提供的。

我们注意到原始的 NOTES 中,所写的 "app={{ template "my-hello-world.name" . }},release={{ .Release.Name }}" 和 deployment.yaml 中所写的配置不太一样,可以把它改成 "app.kubernetes.io/name={{ template "my-hello-world.name" . }},app.kubernetes.io/instance={{ .Release.Name }}",将 values.yaml 中的 version 更新成 0.1.1。然后重新打包 Chart(运行 helm package),得到新的 my-hello-world-0.1.1.tgz 之后,升级原有 Chart(运行 helm upgrade my-hello-world-chart-test2 my-hello-world-0.1.1.tgz --set Username="New Chart"),就能看到更新过后的 NOTES 了。

NOTES:
1. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods -l "app.kubernetes.io/name=my-hello-world,app.kubernetes.io/instance=my-hello-world-chart-test2" -o jsonpath="{.items[0].metadata.name}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl port-forward $POD_NAME 8080:80

应用分享

file那么制作完成的应用如何和其他人分享呢?Helm 官方推出的 ChartMuseum 提供了 Chart 仓库的构建方法,使用它可以创建自己的 Chart 仓库。然而自行维护一个仓库本身成本不小,而且对于用户而言如果每一个开发者都是自己的仓库,他就需要将所需应用对应的仓库都加入自己的检索列表中,很不利于应用的传播与分享。file我们团队近期推出了开放云原生应用中心,Cloud Native App Hub,同步了各类应用,同时还提供了开发者上传应用的渠道。

在我们的开放云原生应用中心中,应用来自两个渠道:

  • 一方面,我们定期从一些国外的知名 Helm 仓库同步 Chart 资源,在同步的过程中,会对 Chart 内部使用的一部分 Docker 镜像进行同步替换(例如 gcr.io 或者 quay.io 的镜像),方便国内用户访问使用;
  • 另一方面,我们和 Helm 官方库一样在 Github 上接受开发者通过 Pull Request 的形式提交自己的应用。提交成功的应用会在短期内同步至云原生应用中心,和其他官方应用展示在一起供其他用户使用。

file

云原生应用开发大赛

参赛点击:https://developer.aliyun.com/special/apphubchallengefile

参考

  1. Helm Chart 创作指南 https://cloudnativeapp.gitbook.io/handbook/helm-chart-creation-tutorial
  2. 开放云原生应用中心 - Cloud Native App Hub https://developer.aliyun.com/hub
  3. 开放云原生应用中心 Github 仓库 https://github.com/cloudnativeapp/charts

相关推荐

推荐一款好用的刷题工具

为了帮助正在准备求职季的开发者提升备战效率,阿里云特别推出“通义灵码陪你备战求职季”活动,精心挑选百道历史校招技术面试/笔试题,借助通义灵码智能问答、代码智能生成、代码优化等核心功能,帮助开发者更加准确地了解程序员职业所需的核心技能,加强对问题解决思维和解题能力的练习。

阿里巴巴云原生的博客 1383

通义灵码 Visual Studio 下载安装指南(附安装包)

本安装步骤适用于 Windows 10 及以上操作系统中安装和使用通义灵码。

阿里巴巴云原生的博客 4436

生产更可信,订阅更耐用丨Higress 社区进展报告

阿里巴巴云原生的博客 115

让 Agent 成为企业生产力丨Alibaba Cloud AgentCore 企业智能体构建与治理沙龙·杭州站精彩回顾 & PPT 下载

近日,让 Agent 成为企业生产力丨Alibaba Cloud AgentCore 企业智能体构建与治理沙龙·杭州站圆满落幕。本场活动吸引了 100+ 名技术从业者深度参与,深度分享了企业 Agent 趋势、AgentCore 构建与治理、Agent 观测与优化、STAROps 智能运维及 AI 网关等相关议题,并设置了动手实操环节。

阿里巴巴云原生的博客 21

如何用 STAROps Elasticsearch 智能助手看穿“搜索变慢”

某电商平台的商品搜索服务使用一台 6 个数据节点的 Elasticsearch 实例。周五北京时间 20:00 起,业务陆续反馈搜索变慢。业务监控中的搜索接口 P99 从平时约 200 ms 升到 2s 以上,部分请求超时。值班工程师打开控制台:集群状态为 Green,没有未分配分片,集群平均 CPU 约 40%,乍看不像资源已经吃紧。

阿里巴巴云原生的博客 118

满帮基于阿里云 AgentCore 打造生产级 SRE 稳定性数字人

满帮基于阿里云 AgentCore 构建“稳定性数字人”:满帮提供业务知识、专业工具与处置流程,AgentCore 提供智能体运行、协作和治理支撑。数字人已在核心链路的巡检与根因分析中得到应用,受控处置能力也在持续建设,让满帮积累的稳定性能力能够在具体任务中得到复用。

阿里巴巴云原生的博客 112

稳定复现超 70% 的缺陷,报警到自动修复的 Agent 流水线实践

本文将分享我们在 PolarDB-X 团队做的一些工程实践:让 Agent 从一条报警或工单出发,自主完成排查、复现、修复和验证,再把结果交给研发评审。

阿里巴巴云原生的博客 294

从“自证清白”到“因果链条”:智能体如何重塑运维排障效率

STAROps 做全域关联分析,把范围从「五个团队依次自证清白」收拢到一条具体链路;证据指向对象存储后,OSS Agent 接手,基于真实配置、访问日志和用量数据往下挖,给出根因和支撑它的证据链。你面对的始终是一个对话框:路由归它管,说清现象、拍板方案归你。

阿里巴巴云原生的博客 125

TechTalk丨从能买奶茶到能进企业,Agent 绕不开同一组问题

史明伟所在的 Alibaba Cloud AgentCore 是企业级 Agent 构建和治理平台,为 Agent 在业务场景下的规模化落地提供基础设施,所以这场对话,他和 Datawhale 主持人从个人助理一路聊到企业 Agent:权限该怎么一步步放开?进了企业,账号打通、数据权限、沙箱隔离又会带来哪些新问题?没有强技术团队的企业,该从哪里起步?

阿里巴巴云原生的博客 208

AgentCore + Codex 构建生产级 Agent 的原理与实践

本文章演示 AgentCore[1]的自定义代码/镜像能力,目的是展示如何基于自定义的 Harness 框架(Codex) 结合 AgentCore 提供的身份、模型、工具、技能、凭证 、观测评估等能力实现一个端到端的 Agent 应用,内容包含两个部分,技术方案和实践教程,文末附相关源码和本次的测试数据,可以根据需要自行查阅。

阿里巴巴云原生的博客 187

让复杂任务由团队完成:阿里云 AgentCore 多 Agent 协作架构及实践

Alibaba Cloud AgentCore 以身份、通信、团队和任务为基础,让专业 Agent 与人类成员共同参与业务协作。企业可以按职责组合知识、工具、Skill 和模型,用任务系统持续追踪工作,再结合 AgentLoop 评估效果、优化配置。

阿里巴巴云原生的博客 334

易点天下:AI 驱动 IT 运维组织提效的实践

易点天下作为一家专注品牌全球化的营销科技公司,由智能营销、全域增长、智能变现三大引擎驱动。公司旗下拥有“整合营销服务”与“广告平台业务”两大业务线。

阿里巴巴云原生的博客 300

阿里云可观测 2026 年 10 月产品动态

阿里云可观测 2026 年 10 月产品动态

阿里巴巴云原生的博客 199

用 Nacos 3.3.0 ARD 让 Agent 按任务发现工具和 Skill

如今,工作中用 Agent 帮忙已经越来越常见。研发同学用 Coding Agent 写代码、补测试、排查问题,业务同学用 Work Agent 整理资料、分析表格、制作演示文稿。不少过去需要自己一步步操作的事情,现在可以把需求交给 Agent,让它协助完成。

阿里巴巴云原生的博客 314

HiRoute 新版本发布:结合自己的真实工作选择最佳模型

HiRoute[1]是一个开源、运行在本地的 Agent 智能路由引擎。你继续用 Codex、Claude Code、Qoder、Pi、OpenCode、Hermes、DeepSeek Harness 等熟悉的 Agent,由 HiRoute 判断每一步交给哪个模型。

阿里巴巴云原生的博客 388

用户说 App“下不了单”:用 Session Replay 看清流程卡在哪一步

Session Replay(会话回放)将采集到的页面变化重建为可回看的过程。研发可以沿着这次会话,查看操作前后的界面变化,先确认流程停在了哪里,再结合当时的事件、日志和代码检查原因。

阿里巴巴云原生的博客 55

欢迎报名丨Alibaba Cloud AgentCore 企业智能体构建与治理八城巡回沙龙 · 杭州站开启

欢迎报名丨Alibaba Cloud AgentCore 企业智能体构建与治理八城巡回沙龙 · 杭州站开启

阿里巴巴云原生的博客 144

运维走出控制台:阿里云 AgentCore AI Native 运维实践

UModel 让现场能够被关联,运维数字员工让经验能够被调用,AgentCore Team 让分析能够协作,AgentLoop 让质量能够被检验。这些建设共同服务于一件事:让团队对系统的理解,成为每个人处理问题时都能接上的能力。

阿里巴巴云原生的博客 301

从长程 Agent 到 Super-agent,解锁更多场景

Deepseek Harness 提升了架构的透明度,但也带来了工程上的复杂度。这次开源的dsh-superagent-prototype,是对 Agent “连续实体”能力的工程拆解。

阿里巴巴云原生的博客 237

排查提效 50%:淘大集新核心系统的观测护航之路

供应链运维,缺的不是更多机器,是“一条能把指标、日志、链路串起来的线”。阿里云 ARMS+SLS+云监控2.0+STAROps 重构观测底座。

阿里巴巴云原生的博客 148

概率、插座与 5000 个爱因斯坦:专访阿里云研发副总裁周琦

这次访谈发生在 2026 年云栖大会之后。大会期间,阿里云发布了智能体构建和治理平台 AgentCore,将企业级 Agent 基础设施进一步标准化和托管化。

阿里巴巴云原生的博客 154

Agent 数据飞轮平台的选型和实践

用统一标准判断修改效果,积累覆盖不同路径的测试样本,沿执行记录排查失败,并将典型问题纳入后续回归。而这也是宙斯接入 AgentLoop 要解决的问题。

阿里巴巴云原生的博客 29

Durable Agent 详解:如何让 Agent 在云端长期稳定运行

本文使用一个具体的用户任务示例“向五位客户发送通知邮件”,解释为什么保存聊天记录还不够,再以 AgentScope 构建的 Agent 为例,展开任务状态、持久提交和故障恢复的通用设计,最后结合 Alibaba Cloud AgentCore 已有的 Harness 托管与节点恢复能力,讨论共享状态、可靠调度及 Brain / Hands 分离如何支撑更完整的长期托管服务。

阿里巴巴云原生的博客 335

Qoder × AgentLoop:智能体规模化应用,敏感数据保护如何跟上?

智能体观测与优化平台 AgentLoop 持续分析已采集的 Qoder 审计日志,将发现的风险线索关联到具体会话、工具调用、成员和环境,帮助安全团队回查任务过程、明确需要整改的环节,并复查处理效果。

阿里巴巴云原生的博客 291

完整还原已经服务千家企业的 AIOps Agent 的评测和调优实践

阿里云 STAROps 是一个生产运维 Agent,通过连接多域数据、运维工具与专家经验,从被动响应走向智能自治,7×24 保障业务连续、稳定运行。本文将分享 STAROps 的评测和调优实践。

阿里巴巴云原生的博客 199

阿里云云原生四项 AI 应用工程化实荣获“鼎新杯”优秀案例

第五届“鼎新杯”由中国通信标准化协会主办、中国信息通信研究院承办,自2026年05月正式启动,历时近 5 个月,聚焦国内政企数智化转型领域的创新成果,旨在为行业提供可复制、可推广的实践参考。

阿里巴巴云原生的博客 323

交付周期从 51 天缩短到 14 天,多 Agent 协作产品⾃进化背后的组织重构

本⽂结合这段实践,介绍评测如何驱动产品持续进化、⼈机协作的边界如何设定,以及团队如何通过统⼀⽬标、结果标准和责任分⼯,减少跨岗位交接,降低沟通损耗,把技术能⼒转化为实际交付效果。

阿里巴巴云原生的博客 328

从部署上线到运维优化:STAROps 与 ROS Agent 的资源运维自动化实践

STAROps 数字员工提供统一的运维对话入口,结合日志、指标、告警等信息理解问题,并通过 alibabacloud-ros-agent 技能,将基础设施规划和变更任务委派给 ROS Agent。

阿里巴巴云原生的博客 130

车企数据隐私保护必修课:如何用 SLS mask 守住日志中的敏感信息

阿里云日志服务 SLS 的 mask 函数可在采集或写入阶段替换匹配的敏感值,同时保留业务状态与调用链,并结合访问控制和保留期限管理减少暴露。下文通过车辆与车主服务、海外联网订阅、智能座舱交互三类业务中的四组日志,介绍规则选择与脱敏效果。

阿里巴巴云原生的博客 113

切换模型会损失缓存,智能路由还省钱吗?

智能路由会把不同的工作交给不同的模型。很多人随之会问:模型一换,之前积累的缓存就用不上了,这笔损失会不会把省下的钱又花回去?

阿里巴巴云原生的博客 209
上一篇: Java 并发编程-不懂原理多吃亏(送书福利)
下一篇: 云原生生态周报 Vol. 17 | Helm 3 发布首个 beta 版本
阿里云云原生
阿里云云原生 企业官方账号 企业官方账号
博客等级 码龄8年 1万+粉丝 3151原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值