基于 KubeSphere 快速部署 ByConity

GitHub |https://github.com/ByConity/ByConity

什么是ByConity

ByConity是一款基于Clickhouse核心设计的一款数仓系统,它采用了云原生架构设计,实现了读写资源的隔离、快速弹性扩缩容。推出了 CnchMergeTree 分布式存储引擎,完全兼容 Clickhouse 的SQL。

环境要求:

  • K8S /火山云 VKE   
  • 对象存储 TOS / OSS / Minio
  • kubectl
  • byconity >= 0.2.0 

这里需要大家已经有一个 k8s 环境,有了一个S3对象存储,调试通了 kubectl 工具。

部署ByConity

这里我们参考ByConity官方的K8S部署方案进行部署:Deploy ByConity in Kubernetes | ByConity

步骤:

1、下载 chart 包
git clone https://github.com/ByConity/byconity-deploy.git
cd byconity-deploy

2、修改 values.yaml 文件

需要修改 byconity-deploy/k8s/values.yaml 文件。

我们在 VSCode中打开 byconity-deploy 目录,红色圈住的部分就是我们要修改的文件

2.1 修改K8S的存储类名

这里 storageClassName 默认配置为 openebs-hostpath ,我们需要修改为自己的k8s 配置的存储类。

可以通过 kubectl get sc 命令 来查看自己的k8s集群配置的存储类

(base) root@localhost kube % kubectl get sc
NAME               PROVISIONER              RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
ebs-ssd            ebs.csi.volcengine.com   Delete          WaitForFirstConsumer   true                   93d
ebs-ssd-pl         ebs.csi.volcengine.com   Delete          Immediate              false                  18d

可以看到这里我的k8s集群支持 2个存储类 分别是 ebs-ssd、ebs-ssd-pl,我们就使用 ebs-ssd

我们可以通过查找关键字进行替换 或者 自己查找更改。

注意:这里一定按自己实际集群的存储类进行替换

替换前,我们看到有9个需要进行替换:

 替换后:

 2.2、修改存储配置为S3

这里我使用的是火山云的 TOS,使用兼容AWS S3的对象存储都是可以的,亲测 Minio, TOS, OSS 都是可以使用的。

需要准备好对象存储的 endpoint、bucket、access key、secret access key 等信息。

注意: 这里的 endpoint 一定要是 S3 兼容的接口,各家公有云厂商应该都有提供,使用公有云默认的 endpoint 链接地址 是不可以的。

目前阿里云OSS的 endpoint 是S3 兼容的可以直接使用

按照下图就行修改。

1、修改 cnch_default_policy 的默认值 cnch_default_hdfs 为 cnch_default_s3

2、S3 的配置信息取消注释,并更改为 自己的对象存储信息。

注意: 

1、path 目录没有提前创建也没有关系,可以自己定义。

2、is_virtual_hosted_style 用于设置是否使用 VirtualHostStyle 虚拟主机 的路径请求方式,is_virtual_hosted_style 取值为 true 表示为使用 VirtualHostStyle,取之为 false 则表示 使用 PathStyle (is_virtual_hosted_style 在 0.2.0 版本之前 叫 virtual_host_style,大家需要根据自己的版本进行选择)

目前公有云(TOS、OSS基本都只支持 VirtualHostStyle),

而 minio 默认支持的是 PathStyle 路径样式。

3、将 policies 下的注释取消掉

修改后是这样的

3、部署 fdb-operator

helm upgrade --install --create-namespace --namespace byconity -f ./examples/k8s/values.yaml byconity ./chart/byconity --set fdb.enabled=false --set hdfs.enabled=false
helm upgrade --install --create-namespace --namespace byconity -f ./examples/k8s/values.yaml byconity ./chart/byconity --set fdb.enabled=false --set hdfs.enabled=false

由于 ByConity 的 chart 包附带了HDFS的部署,而我们这里使用对象存储作为存储,所以需要配置 chart 不部署 HDFS (上面命令中设置了 --set hdfs.enabled=false)

执行命令后需要等待一段时间,等待 byconity-fdb-operator  部署完成。

这里可以通过  kubectl get pods -n byconity 命令来查看

可以看到上图, byconity-fdb-operator 并未完成(预计需要3到5分钟)

等待一会后,我们再次查看,已经处于运行状态了,可以开始下一步了。 

 4、部署ByConity

helm upgrade --install --create-namespace --namespace byconity -f ./examples/k8s/values.yaml byconity ./chart/byconity --set hdfs.enabled=false

helm upgrade --install --create-namespace --namespace byconity -f ./examples/k8s/values.yaml byconity ./chart/byconity --set hdfs.enabled=false

执行命令后需要等一段时间(3分~5分),可以通过 kubectl get pods -n byconity 命令来查看

可以看到都准备就绪了,那我们就验证一下安装成果

 验证ByConity

我们来尝试一下吧!

1、进入容器内部

% kubectl -n byconity exec -it sts/byconity-server -- bash

2、启动 clickhouse 客户端
clickhouse client

结果大概是这个样子的

 3、跑一些 SQL 

-- 创建一个库
CREATE DATABASE IF NOT EXISTS test;
USE test;
DROP TABLE IF EXISTS test.lc;
CREATE TABLE test.lc (b LowCardinality(String)) engine=CnchMergeTree ORDER BY b;
INSERT INTO test.lc SELECT '0123456789' FROM numbers(100);
SELECT count(), b FROM test.lc group by b;
DROP TABLE IF EXISTS test.lc;
DROP DATABASE test;

结果:

在K8S上部署 Byconity,并设置 存储为S3基本的流程已经完成。

可能会遇到的问题:

1、ByConity 和 fdb-operator 部署的时候很慢,可能要等好多分钟。

-  这个是由于ByConity 和 fdb-operator 镜像太大,所以下载镜像就很慢。

2、 fdb-operator 部署中可能会出现失败问题。

- 这个需要 结合  fdb-operator  和 k8s 的日志来分析具体原因。

未来的展望

我司现在已经将 ByConity 部署在K8S上,并借助ByConity的高性能优势提供了日志分析服务,后续我们将加大测试力度,将我们基于CK集群上的OLAP自主分析服务迁移到 ByConity。

写在最后

本文作为部署ByConity在K8S上的教程,如在使用 ByConity 过程中遇到问题,可以联系下方小助手加入技术交流群与社区沟通,也欢迎在 GitHub 上提 issue。

GitHub |https://github.com/ByConity/ByConity

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐