OBProxy路由策略与使用运维-简介

Posted 2023-04-06 柯西极限存在准则

背景

OceanBase数据库是分布式数据库，每个表甚至每个表的不同分区都可能存放在不同的机器上。想要对表进行读写，必须 先要定位到数据所属的表或是分区的主副本位置，然后才能执行相应的SQL DML语句，这在应用层面而言是几乎不可能做到的

OBProxy作为OceanBase数据库专用的反向代理软件，其核 心功能就是路由以将客户端发起的数据访问请求转发到正确的OBServer上

客户端通过OBProxy访问OceanBase数据库的数据链路如 图所示，用户通过任意Client驱动发出请求，请求通过负载 均衡组件访问到任意一台无状态的 OBProxy上，然后OBProxy 再将用户请求转发到后端 OceanBase 集群中最佳的 OBServer 上去执行

                           

OBProxy核心功能（路由）

OBProxy作为OceanBase的高性能反向代理服务器，其核心功能就是路由转发

OBProxy路由的目标是将具体SQL转发到最恰当的Server上执行，路由的核心过程包括：

简单的SQL Parser，LDC路由，读写分离，备优先读，黑名单机制，下图为OBproxy的路由逻辑

 路由功能举例

OBProxy核心功能（连接管理）

在observer宕机/升级/重启时，客户端与OBProxy的连接不会断开，OBProx可以迅速切换到正常的server上，对应用透明

OBProxy支持用户通过同一个OBProxy访问多个OceanBase集群

Server session对于每个client session独占

同一个client session对应server session状态保持相同(session变量同步)

OBProxy核心功能(监控&&运维)

周期性汇报统计项到OCP，实现了语句级别，事务级别，session级别，Obproxy级别的各种统计

Xflush日志监控（包括慢查询监控、error包监控等）

SQL Audit功能

实现了大量内部命令来实现远程监控，查询和运维

 

 

Linux企业运维——Kubernetes（十四）PSP安全策略

Linux企业运维——Kubernetes（十四）PSP安全策略

文章目录

• • Linux企业运维——Kubernetes（十四）PSP安全策略
  • 1、PSP安全策略简介
  • 2、PSP安全策略配置

1、PSP安全策略简介

PodSecurityPolicy（简称PSP）是Kubernetes中Pod部署时重要的安全校验手段，能够有效地约束应用运行时行为安全。

默认情况下，Kubernetes 允许创建一个有特权容器的 Pod，这些容器很可能会危机系统安全，而 Pod 安全策略（PSP）则通过确保请求者有权限按配置来创建 Pod，从而来保护集群免受特权 Pod 的影响。

2、PSP安全策略配置

1、编辑API配置文件，在准入控制项中加入PSP模块（多个模块用，隔开）


2、变更该文件后k8s会自动重载，查看6443端口开放表明重载完毕

3、使用nginx镜像创建一个pod，查看pod可以看到该pod无法运行，状态为Error


4、查看创建的pod的日志，可以看到出现pod资源权限过大的报错，这是因为我们在为集群引入PSP后没有进行准入控制

5、新建psp目录，编辑yaml文件，设置一个psp策略示例


6、应用yaml文件，查看psp可以看到策略设置成功

7、新建yaml文件创建角色，对该角色应用创建的psp，创建RoleBinding将这一角色与默认命名空间中的默认SA账户default绑定（因为创建Pod时默认使用default账户进行认证）

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: psp-example
rules:
- apiGroups:
  - extensions
  resources:
  - podsecuritypolicies
  resourceNames:
  - example
  verbs:
  - use

---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: bind-psp-example
  namespace: default
roleRef:
  kind: Role
  name: psp-example
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: default
  namespace: default

8、删除之前创建的pod，重新创建一个pod，查看该pod成功运行就绪

9、但上面所设置的psp策略所开放的权限过大，这里我们删除创建的角色、绑定关系，删除创建的psp，新建子目录new，编辑yaml文件创建较为完善的psp策略

[root@server2 psp]# cat psp.yaml 
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restrictive
spec:
  privileged: false
  hostNetwork: false
  allowPrivilegeEscalation: false
  defaultAllowPrivilegeEscalation: false
  hostPID: false
  hostIPC: false
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  volumes:
  - 'configMap'
  - 'downwardAPI'
  - 'emptyDir'
  - 'persistentVolumeClaim'
  - 'secret'
  - 'projected'
  allowedCapabilities:
  - '*'

10、应用该yaml文件，查看psp可以看到策略设置成功，相较于之前创建的策略多了更多限制

11、编辑修改roles.yaml文件，创建集群角色，对该集群角色应用创建的psp，创建ClusterRoleBinding将这一ClusterRole与整个系统中的所有ServiceAccount
绑定

[root@server2 psp]# cat roles.yaml 
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: psp-restrictive
rules:
- apiGroups:
  - extensions
  resources:
  - podsecuritypolicies
  resourceNames:
  - restrictive
  verbs:
  - use

---

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: psp-default
subjects:
- kind: Group
  name: system:serviceaccounts
  namespace: kube-system
roleRef:
  kind: ClusterRole
  name: psp-restrictive
  apiGroup: rbac.authorization.k8s.io

12、此时使用控制器部署pod，查看所有pod都可以成功运行就绪

13、实验完成后清理实验环境，删除创建的集群角色、集群绑定关系，删除创建的psp，编辑API配置文件在准入控制项中删除PSP模块