代码拉取完成，页面将自动刷新
operator2.0是基于1.0，与之前的版本特性功能保持兼容，并在此基础上优化了部分功能：
1.优化了Pod健康查询超时机制，删除了liveness探针，readiness探针由执行脚本的方式改为tcp dbport方式
2.支持新的网络插件和存储插件，当前网络插件支持calico和kube-ovn，存储插件支持topolvm和华为分布式存储，支持混合插件部署，即支持在两个使用不同网络和存储插件的k8s环境上搭建openGauss集群
3.优化opengauss集群无主状态下选择的逻辑
4.修改了构建从库的方式，原逻辑通过gs_basebackup方式构建从库，当前通过build方式构建从库
5.优化了华为分布式存储插件下的pod创建流程，对于因Failmount方式导致Pod无法拉起的情况，将始终等待直至pvc可以成功挂载到pod上
6.kube-ovn环境下，支持pod设置多网卡，即支持pod设置两个ip，分别用于提供业务和其他服务（如备份）
7.新增日志输出，便于排查生产问题
8.修复特定场景下openGauss集群的实例格式发生变化后replconninfo配置更新问题
9.修改pod db容器的启动脚本，增加日志pvc和存储pvc使用率的输出
10.新增pod调度策略，支持部署到指定node；支持pod的liveness和readiness探针周期可配置
11.新增data pvc使用监控，data pvc存储使用达到阈值后设置为只读，即修改default_transaction_read_only为on，扩容后自动修改为off
openGauss operator 是一个基于Kubernetes管理的openGauss集群安装与维护的工具，其功能主要包括数据库集群的安装部署、维护、拓扑保持、资源升级、水平扩缩容、同城切换等全生命周期管理。
gs_basebackup全量备份以及日志输出
读写分离设计是基于servcie和pod 添加label实现的 operator会给openGauss集群下的主、备pod角色添加对应角色的label。其中角色为主的节点，Pod的label为primary；角色为备的节点，Pod的label为standby。然后通过读写servcie根据labels映射到不同的pod，其中读service会映射到所在k8s集群opengGauss集群下所有备节点所在的Pod，写service会映射到所在k8s集群opengGauss集群主节点所在的Pod，客户端通过访问k8s集群的任一Node的ip+service的Nodeport，从而实现读写分离。
openGauss operator 支持以下功能
hostpathwget https://gitee.com/opengauss/openGauss-operator/releases/download/2.0/opengauss-operatorv2.tar
docker load -i opengauss-operatorv2.tar
wget https://gitee.com/opengauss/openGauss-operator/releases/download/2.0/opengauss-5.0.2-docker.x86_64.tar
docker load -i opengauss-5.0.2-docker.x86_64.tar
make deploy IMG=opengauss-operator:v2.0.0
sample.yaml，并启动集群kubectl apply -f sample.yaml
sample.yaml
apiVersion: opengauss.sig/v1
kind: OpenGaussCluster
metadata:
name: ogtest01 #pod名，根据实际情况修改
spec:
cpu: '2'
storage: 10Gi
image: opengauss-5.0.2:latest
memory: 3G
readport: 31000
writeport: 31001
localrole: primary
dbport: 26000
hostpathroot: /docker/opengauss_operator/ogtest01 #本地存储根路径，使用本地存储时填写
#storageclass: topolvm-class #填写对应存储插件的storageclass即可
networkclass: calico #当前仅支持calico和kube-ovn两种
config:
advance_xlog_file_num: "10"
archive_command: '''cp %p /gaussarch/archive/%f'''
archive_dest: '''/gaussdata/archive/archive_xlog'''
archive_mode: "on"
bbox_dump_path: '''/gaussarch/corefile'''
log_directory: '''/gaussarch/log/omm/pg_log'''
max_connections: "2000"
iplist:
- nodename: node # 宿主机hostname名
ip: 192.170.0.110 # POD IP，根据实际情况修改
关于构建编译镜像步骤，参考部署详情
CRD主要属性见下表
| 属性名称 | 属性类型 | 属性说明 |
|---|---|---|
| ReadPort | Int | NodePort读端口 |
| WritePort | int | NodePort写端口 |
| DBPort | int | OpenGauss实例端口 |
| Image | string | OpenGauss镜像地址 |
| LocalRole | string | 集群角色 ：primary /standby |
| CPU | string | OpenGauss实例CPU限额 |
| Storage | string | OpenGauss实例存储限额 |
| Memory | string | OpenGauss实例内存限额 |
| BandWidth | string | 带宽 |
| IpList | IpNodeEntry | Opengauss实例的IP和工作节点名称 |
| RemoteIpList | []string | 同城集群的实例IP列表 |
| BackupPath | string | 本地备份路径 |
| ArchiveLogPath | string | 本地归档路径 |
| HostpathRoot | string | 本地存储路径(使用本地存储时填写) |
| StorageClass | string | 存储插件类型 |
| SidecarImage | string | Sidecar镜像地址 |
| SidecarCPU | string | Sidecar CPU限额 |
| SidecarMemory | string | Sidecar内存限额 |
| SidecarStorage | string | Sidecar存储限额 |
| Maintenance | bool | 集群维护模式 |
| ScriptConfig | string | 执行脚本的配置 |
| FilebeatConfig | string | Filebeat配置CM |
openGauss operator部署集群时，支持2个可配置的configmap，对应的cr属性分别为scriptconfig和filebeatconfig
关于配置configmap的具体细节，详见配置configmap详情
operator成功部署以后，就可以通过其部署OG应用。根据输入的配置文件不同，可以部署不同架构的OG应用，包括但不限于：
部署OG应用
kubectl apply -f cluster.yaml
查询应用的部署状态
kubectl get opengausscluster <name>
og部署验证通过后，通过容器内的client连接OG
kubectl exec -it -n <namespace> <pod name> -c og -- gsql -d <dbname> -p <port> -c "<command/sql>"
通过容器内的数据库服务控制工具gs_ctl查看og集群的详细信息:
kubectl exec -ti -n og <pod name> -c og -- gs_ctl query -D <directory of gauss instance>
部署详情见openGauss集群部署详情
og集群部署在两个k8s上，每个k8s各有一个节点，组成HA集群，前提需要保证两个k8s集群网络的连通性，其中：
分别在两个k8s上查询应用的部署状态，直到同城和本地集群STATE都为ready：
kubectl get opengaussclusters.opengauss.sig -n og
查询应用的部署Pod的主从角色：
kubectl get pod -n og --show-labels
验证部署，通过本地集群容器内的client去连接OG：
$ kubectl exec -ti -n <namespace> <pod name> -c og -- gsql -d <dbname> -p <port> -c "<command/sql>"
通过容器内的数据库服务控制工具gs_ctl查看og集群的详细信息：
$ kubectl exec -ti -n <namespace> <pod name> -c og -- gs_ctl query -D <directory of gauss instance>
同城部署详情请参考openGauss同城部署与切换详情
同城切换功能，只需要分别修改本地集群和同城集群CR的localrole即可：
验证灾备切换是否成功，通过容器内的数据库服务控制工具gs_ctl查看原同城集群的详细信息。
同城集群切换的详细信息请参考openGauss同城部署与切换详情
删除openGauss集群，只需要执行k8s命令删除cr即可。需要注意的是，删除openGauss集群后，该CR的pvc仍然存在
执行k8s删除命令，删除cr
kubectl delete opengaussclusters.opengauss.sig -n <namespace name> <cr name>
删除cr资源后，其PVC仍然保留，以防止需要恢复数据。当确定要删除PVC时，首先查看og集群的pvc
kubectl get pvc -n <namespace name> |grep <cr name>
确认数据不需要保存时，直接删除PVC资源即可，避免资源的浪费
kubectl delete pvc <pvc name> -n <namespace name>
删除集群的具体操作请参考删除openGauss集群详情
opengauss 集群的扩容是通过修改CR的iplist属性来实现的，即：
...
iplist:
- ip: 172.16.0.2
nodename: node1
...
扩容即新增iplist的一个元素，通过调整openGauss的iplist，例如：
...
iplist:
- ip: 172.16.0.2
nodename: node1
- ip: 172.16.0.5
nodename: node1
...
更新配置文件后对集群重新进行部署
kubectl apply -f cluster.yaml
查询应用的部署状态，直到pod的STATE由初始的ready变为updating，最终变为为ready：
kubectl get opengaussclusters.opengauss.sig -n og
查询应用的部署Pod的主从角色：
kubectl get pod -n og --show-labels
openGauss集群扩容具体细节请参考operator常见运维操作
缩容的操作与扩容相似，不同的地方在于已经部署的openGauss集群，减少iplist的配置信息。
opertor支持og集群的资源升级，即修改已有集群的内存，CPU,带宽，存储容量等大小。需要特别注意的是：
编辑CR的yaml文件，保存后重新部署
kubectl apply -f cluster.yaml
在CR重新部署后，等待pod的STATE恢复为ready，资源更新完成。 openGauss集群扩缩容详细信息请参考openGauss资源升级
当存在operator不能恢复需要人工干预情况，或者需要手工进入到og集群的库中进行一些运维操作，且人为维护期间不希望operator继续处理对应集群时，可以修改集群对应CR的maintenance属性。
···
readport: 30120
writeport: 30121
dbport: 26000
localrole: primary
maintenance: true
···
maintenance属性默认值为fasle，支持修改，当maintenance为true时，operator不会干预对应集群运行，无论此时集群状态正常/异常。
operator默认采用Deployments方式部署，默认部署在opengauss-operator-system命名空间下
查看operator的Deployments状态及其对应pod的状态
# 查看operator的Deployments状态
kubectl get deployments.apps -n <namaspacename>
# 查看operator的pod的状态
kubectl get pod -n <namaspacename>
查看operator日志
kubectl logs -f -n <namespacename> <podname>
查看operator pod信息
kubectl get pod -n opengauss-operator-system
查看operator的日志
kubectl logs -f -n opengauss-operator-system <operator pod name>
查看opengauss集群的状态
kubectl get opengaussclusters.opengauss.sig -n <namespacename> <crName>
查看opengauss集群的状态的详情
kubectl describe opengaussclusters.opengauss.sig -n <namespacename> <crName>
查看 og集群下pod的日志
kubectl logs -f -n <namespacename> <podName>
故障诊断详细信息请参考故障诊断手段
用户可以通过service连接数据库，部署的og集群，会有对应的写servcie和读service 写service可读可写；读service仅可以进行读操作
部署og集群时，会创建两个service：读service和写service service命名规则如下
kubectl get svc -n og |grep ogtest
og-ogtest-svc NodePort 10.102.11.89 <none> 5432:30002/TCP 6d1h
og-ogtest-svc-read NodePort 10.97.134.48 <none> 5432:30001/TCP 6d1h
示例 og命名空间下存在一主一从的og集群ogtest
$ kubectl get opengaussclusters.opengauss.sig -n og
NAME ROLE CPU MEMORY READ PORT WRITE PORT DB PORT STATE AGE
ogtest primary 500m 2Gi 30001 30002 5432 ready 6d2h
# 对应的读写service
$ kubectl get svc -n og |grep ogtest
og-ogtest-svc NodePort 10.102.11.89 <none> 5432:30002/TCP 6d2h
og-ogtest-svc-read NodePort 10.97.134.48 <none> 5432:30001/TCP 6d2h
客户端连接db时，使用k8s集群下任一node的ip 和写service的noteport就可以连接数据库
operator会监控集群中 og集群的pod，当监测到pod故障后，会尝试将其重新拉起。案例包括但不限于：
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
1. 开源生态
2. 协作、人、软件
3. 评估模型
马建仓 AI 助手