有侧边栏的网站,长沙优化官网推广,鞍山做网站团队,上海工商网官网登录在K8S上部署OceanBase的最佳实践
目录
1. 背景与选型 1.1 为什么选择OB1.2 为什么选择ob-operator实现OB on K8S 2. 部署实操 2.1 环境准备2.2 安装 ob-operator2.3 配置 OB 集群2.4 配置 OBProxy 集群2.5 Headless Service 和 CoreDNS 配置2.6 监控与运维 2.6.1 Promethues部…在K8S上部署OceanBase的最佳实践
目录
1. 背景与选型 1.1 为什么选择OB1.2 为什么选择ob-operator实现OB on K8S 2. 部署实操 2.1 环境准备2.2 安装 ob-operator2.3 配置 OB 集群2.4 配置 OBProxy 集群2.5 Headless Service 和 CoreDNS 配置2.6 监控与运维 2.6.1 Promethues部署2.6.2 Grafana接入 3. 部署中遇到的问题及解决方案 3.1 ob-operator 的调度器问题3.2 网络配置问题
1. 背景与选型
OB下称OB是一款分布式关系型数据库具有高性能、高可用性和弹性扩展等特点其企业版已经在公司内部的去Oracle项目中进行了落地并取得了不错的效果。此外考虑到我们仍有许多业务在关系型数据库上有着需求同时考虑到我们已经具备MySQL/MariaDB/MongoDB/PostgresSQL在公司内部的K8S集群上进行容器化部署经验因此我们决定将OceanBase也进行容器化部署。
1.1 为什么选择OB
在选择数据库时我们从以下几个维度进行了分析
高可用性OB是基于Paxos算法的强一致性数据库具备强大的容灾能力支持多数据中心部署同时单点故障并不影响业务连续性。弹性扩展OB的租户特性使得相比MySQL和TiDB等关系型数据库而言OB提供了更灵活的扩展能力能够根据业务需求动态调整资源。成本OB内核天然自带数据压缩能力相比MySQL/TiDB具备更低的存储成本特别是在大规模部署时能够有效降低硬件成本实测重复性文本数据下OB的存储成本仅为MySQL的1/4甚至更低。兼容性OB内核天然兼容MySQL协议方便现有应用的迁移和集成。
1.2 为什么选择ob-operator实现OB on K8S
在将OB部署到K8S的过程中我们选择了 ob-operator 作为核心组件。ob-operator 提供了自动化管理 OB集群的能力能够简化部署、扩展和运维的复杂性。其主要优势包括
自动化管理ob-operator 能够自动处理OB集群的生命周期管理包括创建、更新和删除。灵活性支持自定义OServer/OBTenant资源支持快速扩展集群规模, 支持通过CR文件快速修改参数。高可用性通过多实例部署和健康检查机制确保集群的稳定运行。支持静态IP和OVN网络确保POD重建后仍然使用原IP避免了POD重建后IP变化带来的问题。
2 部署实操
对于希望将 OB 接入 K8S 但不知如何下手的用户ob-operator 提供了一个方便快捷的起点。
2.1 环境准备
在开始之前请确保已满足以下条件
有可用的 Kubernetes 集群至少有 9 个可用 CPU33 GB 可用内存和 360 GB 的可用存储空间。ob-operator 依赖 cert-manager请确保已安装 cert-manager。cert-manager 的安装方法如下。连接 OceanBase 集群时需已安装 MySQL 客户端或 OBClient。Kubernetes集群需要安装网络插件例如OVN。2.3.1以上版本 ob-operator 支持OVN网络并且能够做到pod重建后IP不变进一步提高了 OB集群 的稳定性。
安装 cert-manager
# 检查是否已安装 cert-manager
kubectl get pod -n cert-manager# 若未安装则执行以下命令
wget https://github.com/jetstack/cert-manager/releases/download/v1.5.3/cert-manager.yaml# 拉取镜像需要科学上网
# 我们使用的K8S的网络插件为OVN节点需要调度到 OVN 网络的节点上否则可能无法通过 cert-manager 的 service 访问后端 POD
kubectl apply -f cert-manager.yaml2.2 安装 ob-operator
安装ob-operator的操作可参考ob-operator部署如果手动通过CRD部署可以自行从github仓库中下载CRD和Operator的yaml文件然后通过kubectl apply -f 命令进行安装。
2.3 配置 OB 集群
可参考官方文档进行集群创建
2.4 配置 OBProxy 集群
OBProxy即odpOceanBase Database Proxy 是 OB集群 的代理组件生产环境上建议使用 OBProxy 对OB集群进行访问。使用 OBProxy 的好处包括
连接管理OBProxy 负责管理客户端的连接维护与后端 OB集群 的会话减少客户端与数据库之间的连接开销。负载均衡OBProxy 能够智能地将客户端请求分发到不同的 OB 节点优化资源使用提升系统性能。高可用性在后端 OB 节点发生故障时OBProxy 能够自动剔除故障节点确保请求的高可用性。安全性通过 OBProxy可以集中管理访问控制和安全策略增强系统的安全性。
配置步骤
安装 OBProxy直接应用 YAML 文件进行安装。
obproxy YAML文件地址obproxy.yaml但在部署 OBProxy 前需要创建一个用于 OBProxy 与 OB集群 通信的 Secret。
# 创建用于 OBProxy 与 OB集群 通信的 Secret
kubectl create secret -n oceanbase generic proxyro-password --from-literalpasswordproxyro_password# 部署 OBProxy
kubectl apply -f obproxy.yaml基本内容如下
# 相比官方提供的 obproxy.yaml 文件增加了 odp-headless 的无头服务配置主要目的是用于 coreDNS 进行域名解析
apiVersion: v1
kind: Service
metadata:name: odp-headlessnamespace: oceanbase
spec:type: ClusterIPclusterIP: Noneselector:app: odpname: odpports:- name: sqlport: 2883targetPort: 2883---
apiVersion: v1
kind: Service
metadata:name: odpnamespace: oceanbase
spec:type: ClusterIPselector:app: odpname: odpports:- name: sqlport: 2883targetPort: 2883- name: prometheusport: 2884targetPort: 2884---
apiVersion: apps/v1
kind: Deployment
metadata:name: odp # 生产环境下不建议使用 odp 作为 Deployment 名称建议使用 odp-${obcluster_name} 作为 Deployment 名称namespace: oceanbase
spec:selector:matchLabels:app: odpname: odp # 生产环境下不建议使用 odp 作为 Deployment 名称建议使用 odp-${obcluster_name} 作为 Deployment 名称replicas: 3template:metadata:labels:app: odpname: odpspec:containers:- name: obproxyimage: oceanbase/obproxy-ce:4.2.1.0-11ports:- containerPort: 2883name: sql- containerPort: 2884name: prometheusenv:- name: APP_NAMEvalue: helloworld # 用于 OBProxy 的名称- name: OB_CLUSTERvalue: obcluster # 此处填写OB集群的名称其来源于 OB 部署YAML文件中的 clusterName 值- name: RS_LISTvalue: ****** # 格式为 ${OBServer1 POD_IP}:2881;${OBServer2 POD_IP}:2881;${OBServer3 POD_IP}:2881需要根据实际OBSevrer PODIP来进行替换。- name: PROXYRO_PASSWORDvalueFrom: secretKeyRef:name: proxyro-password # 用于 OBProxy 与 OB集群 通信的 Secretkey: passwordresources:limits:memory: 2Gicpu: 1requests: memory: 200Micpu: 200m部署完成后如下图所示 通过 OBProxy 访问OB集群
此时可以通过OBProxy的Service提供OB数据库的访问入口如下obmysql是我提前创建好的租户testdb是提前在obmysql下创建的用户 当然在实际的生产中我们采用的是域名访问的方式而不是通过IP地址访问因此需要进行域名重写可看下一小节。
2.5 Headless Service 和 CoreDNS 配置
在我们的实践中为了更好地管理 OBProxy 的访问我们采用了 Headless Service 配合 CoreDNS 的方案 为什么使用 Headless Service Headless Service无头服务通过将 clusterIP: None 设置使得 DNS 查询可以直接返回后端 Pod 的 IP 地址。这种方式避免了普通 Service 的 kube-proxy 转发减少了网络跳转提升了访问性能。 CoreDNS 域名重写配置 apiVersion: v1
kind: ConfigMap
metadata:name: corednsnamespace: kube-system
data:Corefile: |.:3053 {errorsloghealth {lameduck 10s}rewrite stop {name regex ob-(.*).rds.com odp-headless-ob-{1}.oceanbase.svc.cluster.localanswer name odp-headless-ob-(.*).oceanbase.svc.cluster.local ob-{1}.rds.com}kubernetes cluster.local in-addr.arpa ip6.arpa {pods insecurefallthrough in-addr.arpa ip6.arpa}prometheus :9153ready :8153loopreloadcache 10loadbalance}域名重写的优势 简化访问用户可以通过简单的域名格式如 ob-test.rds.com访问数据库无需关心内部复杂的 K8S 域名。统一管理通过规范的域名格式ob-*.rds.com便于管理和维护多个 OB 集群。透明代理CoreDNS 自动完成域名转换对应用层完全透明。灵活扩展可以根据需求轻松添加新的 OB 集群只需遵循命名规范即可。 访问流程 应用通过 ob-{clustername}.rds.com 访问数据库CoreDNS 将请求域名重写为 odp-headless-ob-{clustername}.oceanbase.svc.cluster.localHeadless Service 返回对应 OBProxy Pod 的 IPCoreDNS 在响应中将域名重写回 ob-{clustername}.rds.com应用获得 Pod IP 并建立连接 CoreDNS 主机模式部署 将 CoreDNS 部署在主机网络模式 即 hostNetwork: true使 CoreDNS POD与主机共享网络。这样用在其余K8S集群中的机器上将 /etc/resolv.conf 配置为 CoreDNS 服务器ip后即可通过 CoreDNS 进行域名解析。这种配置方式使得外部机器能够方便地通过 CoreDNS 进行域名解析适合需要跨集群访问的场景。 如图所示 直接通过域名即可访问而不用关心 obproxy 的service ip进一步加强了集群的高可用能力 2.6 监控与运维
2.6.1 Promethues部署
应用ob-operator中的promethues.yaml文件进行部署文件链接promethues.yaml
执行以下命令部署
kubectl apply -f prometheus.yaml执行以下命令检查是否部署完成
kubectl get pod -n oceanbase | grep prometheus执行以下命令获取SVC
kubectl get svc -n oceanbase | grep prometheus如下
root(datamars)mhpl74334-10.20.248.59 ~$ kubectl get svc -n oceanbase | grep pro
svc-prometheus NodePort 12.80.144.38 none 9090:30090/TCP 7d15h2.6.2 Grafana接入
可以应用ob-operator中的grafana.yaml文件进行部署文件链接grafana.yaml也可以通过grafana的配置页面添加prometheus数据源然后通过prometheus的SVC地址进行接入。
因为我们本地已经有grafana所以这里我们通过grafana的配置页面添加prometheus数据源然后通过prometheus的SVC地址进行接入。
2.6.2.1 配置Prometheus数据源
在Grafana左侧导航栏单击 Configuration 按钮然后单击 Add data source 按钮。在 Add data source 页面选择 Prometheus 作为数据源类型。在 Prometheus 页面填写 Name 为 ob-prometheusURL 为 http://12.80.144.38:9090(即上面的promethues对应的svc ip)然后单击 Save Test 按钮。 2.6.2.2 配置Grafana Dashboard
新建一个名为OceanBase的文件夹 进入该文件夹接着导入文件链接grafana.yaml 中的grafana-dashboards-ob部分的json配置 监控展示如图 3. 部署中遇到的问题及解决方案
3.1 ob-operator 的调度器默认为K8S原生的 default-scheduler而在我们环境中需要使用自定义的调度器
解决方案
在 OBCluster的CRD中新增了 schedulerName 字段用于指定调度器具体修改可以参考 MR: Support Custom SchedulerName, 用法如下:
apiVersion: oceanbase.oceanbase.com/v1alpha1
kind: OBCluster
metadata:name: testnamespace: oceanbase
spec:observer:image: oceanbase/oceanbase-cloud-native:4.2.3.1-101000032024061316podFields:schedulerName: custom-scheduler # 指定调度器为 custom-schedulerresource:cpu: 8memory: 16Gi...3.2 网络配置问题
问题描述在使用 OVN 网络插件时发现 Pod IP 在重启后发生变化导致OBProxy无法正常访问OB集群。
解决方案 1使用ob-operator的service模式即为每个OBServer Pod创建一个Service通过service来做静态IP的绑定从而解决IP变化的问题用法如下:
apiVersion: oceanbase.oceanbase.com/v1alpha1
kind: OBCluster
metadata:name: testnamespace: oceanbaseannotations:oceanbase.oceanbase.com/mode: service # 指定为service模式
spec:observer:image: oceanbase/oceanbase-cloud-native:4.2.3.1-101000032024061316podFields:schedulerName: custom-schedulerresource:cpu: 8memory: 16Gi...但是链路上多一节service做静态IP的绑定会增加网络的复杂度而从生产角度和高可用shang因此我们采用了下面的方案。
2ob-operator更新到2.3.1该版本支持OVN网络插件并且能够做到Pod重建后IP不变。
3但仍存在潜在的IP冲突问题即当一个 OB Pod 正在重建过程中时如果此时有其他新的 Pod 被创建这些新 Pod 可能会占用到正在重建的 OB Pod 原本使用的 IP 地址。这会导致该 OB Pod 重建完成后无法使用其原有的 IP 地址。
为了解决这个问题我们采用了 OVN 的子网隔离方案
创建专用子网为 OceanBase 的命名空间创建了一个专用的 subnet将其与其他业务的 Pod 网络进行隔离。配置方式apiVersion: kubeovn.io/v1
kind: Subnet
metadata:name: ob-subnet
spec:protocol: IPv4cidrBlock: 10.16.0.0/16 # 为 OB 集群预留足够大的网段namespaces:- oceanbase # 将子网与 oceanbase 命名空间绑定gateway: 10.16.0.1excludeIps:- 10.16.0.1..10.16.0.10 # 排除网关等保留地址这种配置的优势
网络隔离OB 集群的 Pod 使用独立的 IP 地址段避免与其他业务 Pod 发生 IP 冲突地址管理可以更好地规划和管理 IP 地址资源安全性通过网络隔离提升了系统安全性
