。

该文章指出#xff0c;Kine项目作为外部etcd端点#xff0c;可以将Kubernetes

受到这种方法的启发#xff0c;Magda决定进一步…DevRel领域专家Denis

Magda表示他偶然发现了一篇解释如何用PostgreSQL无缝替换etcd的文章。

该文章指出Kine项目作为外部etcd端点可以将Kubernetes

受到这种方法的启发Magda决定进一步探索Kine的潜力从etcd切换到YugabyteDB。

YugabyteDB是一个基于PostgreSQL构建的分布式SQL数据库。

etcd有什么问题?

在Kubernetes集群遇到可扩展性或高可用性HA问题之前它通常不会引起人们的注意。

以可扩展和高可用性HA的方式管理etcd对于大型Kubernetes部署来说尤其具有挑战性。

此外Kubernetes社区对etcd项目的未来开发也有越来越多的担忧。

它的社区规模正在缩小只有少数维护人员有兴趣和能力支持和推进这个项目。

API到SQL的转换层。

Kine正式支持SQLite、PostgreSQL和MySQL这些系统的使用量正在不断增长并且拥有强大的社区。

为什么选择分布式SQL数据库?

虽然PostgreSQL、SQLite和MySQL是Kubernetes的理想选择但它们是为单一服务器部署而设计和优化的。

这意味着它们可能会带来一些挑战特别是对于具有更严格的可扩展性和可用性要求的大型Kubernetes部署。

如果开发人员的Kubernetes集群要求RPO(恢复点目标)为零RTO(恢复时间目标)以秒为单位测量那么MySQL或PostgreSQL部署的架构和维护将是一个挑战。

如果人们有兴趣深入研究这个话题可以探索PostgreSQL的高可用性选项。

分布式SQL数据库作为一个相互连接的节点集群可以跨多个机架、可用区或区域部署。

通过设计它们具有高可用性和可扩展性因此可以为Kubernetes改进相同的特性。

在YugabyteDB上启动Kine

而决定使用YugabyteDB作为Kubernetes的分布式SQL数据库是受到PostgreSQL的影响。

YugabyteDB建立在PostgreSQL源代码的基础上在提供自己的分布式存储实现的同时重用了PostgreSQL的上半部分(查询引擎)。

YugabyteDB和PostgreSQL之间的紧密联系允许开发人员为YugabyteDB重新设计PostgreSQL的Kine实现。

然而需要继续关注这不会是一个简单的提升和转移的故事。

现在将这些想法转化为行动并在YugabyteDB上启动Kine。

为此使用了一个配备了8个CPU和32GB内存的Ubuntu22.04虚拟机。

首先在虚拟机上启动一个三个节点的YugabyteDB集群。

在进行分布式之前可以在单个服务器上对分布式SQL数据库进行试验。

有多种方法可以在本地启动YugabyteDB但作者更喜欢的方法是通过Docker

Shell

~/yb_docker_data/node1/home/yugabyte/yb_data

--restart

--tserver_flagsysql_sequence_cache_minval1

\--base_dir/home/yugabyte/yb_data

--daemonfalsedocker

~/yb_docker_data/node2/home/yugabyte/yb_data

--restart

--tserver_flagsysql_sequence_cache_minval1

\--base_dir/home/yugabyte/yb_data

--daemonfalsedocker

~/yb_docker_data/node3/home/yugabyte/yb_data

--restart

--tserver_flagsysql_sequence_cache_minval1

\--base_dir/home/yugabyte/yb_data

--daemonfalse

注在启动YugabyteDB节点时设置ysql_sequence_cache_minval1以确保数据库序列可以按顺序递增1。

如果没有这个选项一个Kine连接到YugabyteDB将缓存序列的下一个100个ID。

这可能导致在Kubernetes集群引导期间出现“版本不匹配”错误因为一个Kine连接可能插入ID范围从1到100的记录而另一个Kine连接可能插入ID范围从101到200的记录。

接下来使用PostgreSQL实现启动一个连接到YugabyteDB的Kine实例

1克隆Kine库

https//github.com/k3s-io/kine.git

kine

postgres//yugabyteyugabyte127.0.0.15433/yugabyte

SQL

Owner-----------------------------------------public

kine

很好第一次测试成功了。

Kine将YugabyteDB视为PostgreSQL并且启动时没有任何问题。

现在进入下一个阶段使用YugabyteDB在Kine之上启动Kubernetes。

Kine可以被各种Kubernetes引擎使用包括标准的Kubernetes部署、Rancher

Kubernetes引擎(RKE)或K3

(一种轻量级的Kubernetes引擎)。

为简单起见将使用后者。

2启动连接到相同本地YugabyteDB集群的K3sK3s可执行文件随Kine提供

Shell

--datastore-endpointpostgres//yugabyteyugabyte127.0.0.15433/yugabyte

3Kubernetes启动时应该没有问题可以通过运行以下命令来确认

Shell

Kubernetes在YugabyteDB上无缝运行。

这要归功于YugabyteDB很好的特性和与PostgreSQL的运行时兼容性。

这意味着可以重用为PostgreSQL创建的大多数库、驱动程序和框架。

这可能标志着这一旅程的结束可以回顾一下K3s日志。

在Kubernetes引导期间日志可能会报告缓慢的查询如下所示

SQL

rkv),(SELECTMAX(crkv.prev_revision)

crkvWHEREcrkv.name

10001在一台机器上运行YugabyteDB时这可能不是一个重要的问题但是一旦切换到分布式设置这样的查询就会成为热点并产生瓶颈。

因此克隆了Kine源代码并开始探索PostgreSQL实现寻找潜在的优化机会。

在这里Magda与Franck

Pachot合作Pachot是一位精通SQL层优化的数据库专家对应用程序逻辑没有或只有很少的更改。

ANALYZE用于某些查询之后Franck提出了对任何分布式SQL数据库都有利的基本优化。

幸运的是优化不需要对Kine应用程序逻辑进行任何更改。

所要做的就是引入一些SQL级别的增强。

因此创建了一个直接支持YugabyteDB的Kine

与此同时与PostgreSQL相比YugabyteDB的实现有三个优化

indexid更改为primary

asc。

在默认情况下YugabyteDB使用哈希分片在集群中均匀分布记录。

然而Kubernetes在id列上运行了许多范围查询这使得切换到范围分片是合理的。

2通过在索引定义中包括id列kine_name_prev_revision_uindex索引已被更新为覆盖索引

CREATE

YugabyteDB的索引分布类似于表记录。

因此索引条目可能引用存储在不同YugabyteDB节点上的id。

为了避免节点之间额外的网络往返可以将id包含在二级索引中。

3Kine在完成Kubernetes请求的同时执行许多连接。

如果查询规划器/优化器决定使用嵌套循环连接那么在默认情况下YugabyteDB查询层将每次读取和连接一条记录。

为了加快这个过程可以启用批处理嵌套循环连接。

YugabyteDB的Kine实现通过在启动时执行以下语句来实现

ALTER

首先停止之前的K3s服务并从YugabyteDB集群中删除Kine模式

1停止并删除K3s服务

/usr/local/bin/k3s-uninstall.shsudo

/etc/rancher

接下来启动一个为YugabyteDB提供优化版本的Kine实例

1克隆fork

https//github.com/dmagda/kine-yugabytedb.git

kine-yugabytedb

yugabytedb//yugabyteyugabyte127.0.0.15433/yugabyte

Kine的启动没有任何问题。

现在唯一的区别是不是在连接字符串中指定“postgres”而是指示“yugabytedb”以启用优化的YugabyteDB实现。

关于Kine和YugabyteDB之间的实际通信Kine继续使用Go的标准PostgreSQL驱动程序。

要做到这一点首先需要从资源中构建k3

https//github.com/k3s-io/k3s.git

k3s

3打开go.mod文件并在replace..部分的末尾添加以下行

github.com/dmagda/kine-yugabytedb

v0.2.0

这条指令告诉Go使用带有YugabyteDB实现的最新版本的Kinefork。

Shell

GOPRIVATEgithub.com/dmagda/kine-yugabytedb

5确保更改生效

\--datastore-endpointyugabytedb//yugabyteyugabyte127.0.0.15433/yugabyte

3确认Kubernetes启动成功

现在部署一个示例应用程序以确保Kubernetes集群不仅仅能够自我引导

Shell

https//github.com/digitalocean/kubernetes-sample-apps.git

2部署Emojivoto应用

./kubernetes-sample-apps/emojivoto-example/kustomize

3确保所有部署和服务成功启动

AGEpod/vote-bot-565bd6bcd8-rnb6x

1/1

AGEreplicaset.apps/vote-bot-565bd6bcd8

26sreplicaset.apps/web-75b9df87d6

25sreplicaset.apps/voting-f5ddc8ff6

26sreplicaset.apps/emoji-66658f4b4c

26s

srchttps//www.googletagmanager.com/gtag/js?idUA-60040560-4/scriptscriptwindow.dataLayer

window.dataLayer

gtag(){dataLayer.push(arguments);}gtag(js,

new

UA-60040560-4);/script/headbodydiv

idmain

完成工作Kubernetes现在可以使用YugabyteDB作为其所有数据的分布式和高可用性SQL数据库。

现在可以进入下一阶段在跨多个可用性区域和区域的真正云计算环境中部署Kubernetes和YugabyteDB并测试解决方案如何处理各种中断。

软件开发构建工具

JNPF快速开发平台是一款基于SpringBootVue3的全栈开发平台采用微服务、前后端分离架构基于可视化流程建模、表单建模、报表建模工具快速构建业务应用平台即可本地化部署也支持K8S部署。

应用体验地址https://www.jnpfsoft.com/?csdn操作一下试试吧

引擎式软件快速开发模式除了上述功能还配置了图表引擎、接口引擎、门户引擎、组织用户引擎等可视化功能引擎基本实现页面UI的可视化搭建。

内置有百种功能控件及使用模板使得在拖拉拽的简单操作下也能大限度满足用户个性化需求。

由于JNPF平台的功能比较完善本文选择这项工具进行展开使你更加直观看到低代码的优势。