kubegres controller 结构图
数据库是典型的有状态应用, 所以至少要是用 StatefulSet 进行部署, Spec 的设定比较常规, kubegres 的主要特色在于 KubegresStatus 和 BlockingOperation 的定义, 提炼了 Reconcile Loop 中集群的中间状态, 并通过 BlockOperation 对 Kubernetes 的操作延迟(调用 kube-apiserver 成功并不代表状态立刻发生变化) 进行了合理抽象.
KubegresStatus
如前文所述, Status 定义了不同的 State 转换中的中间态, kubegres 定义了四个属性
type KubegresStatus struct { LastCreatedInstanceIndex int32 `json:"lastCreatedInstanceIndex,omitempty"` BlockingOperation KubegresBlockingOperation `json:"blockingOperation,omitempty"` PreviousBlockingOperation KubegresBlockingOperation `json:"previousBlockingOperation,omitempty"` EnforcedReplicas int32 `json:"enforcedReplicas,omitempty"` }
LastCreatedInstanceIndex 用于对新建的 Replica Postgres StatefulSet 进行编号, EnforcedRplicas 用于标记已部署的 Replicas 的数量, 同时, 也可以用于表明, Postgres 集群是否已经部署过. 最核心是 BlockingOperation 和 PreviousBlockingOperation.
KubegresBlockingOperation
通过 client-go 对 kube-apiserver 发起的 Create, Update, Delete 操作成功返回, 并不意味着 Kubernetes 对相应资源的调谐就立即成功, 与此同时, 某些操作应该是互斥的, 以保证 Kubernetes 调谐成功和集群运行在正确的状态上, kubegres 使用 BlockingOperation 来对该场景进行抽象.
type BlockingOperationConfig struct { OperationId string StepId string TimeOutInSeconds int64 CompletionChecker IsOperationCompleted // 默认为 false, 意味着一旦操作完成 (由 operationId + stepId 定义一次操作) 它就会被自动从 active operation 中删除 // 并加入 previous active operation. // // 如果该 flag 被设置为 flase 且操作超时, 该操作不会被删除而是保持作为 active operation 直到人工删除. // // 如果该 flag 被设置为 true, 在 stepId 的操作完成后, 我们会添加一个新的 stepId 且保持 operationId 不变. // 新的 stepId 会被设置为 "BlockingOperation.transition_step_id". // 这个逻辑允许直到当前的 active operation 要么被人工终止, 要么开启下一步 step 之前, 其他类型的 operations(比如 FailOver) 不会开始. AfterCompletionMoveToTransitionStep bool }
通过 TransitionStep, 就保证了一部分操作一定是互斥的, 不会交织执行.
BlockingOperation 将操作分为了 4 类, 分别是 BaseConfigCountSpecEnforcement, PrimaryDbCountSpecEnforcement, ReplicaDbCountSpecEnforcement 和 StatefulSetSpecEnforcing. 每一类操作都有自己的 StepId, OperationId + StepId 就定义了一次 Blocking Operation. 在发起特定操作前, 通过检查 active Operation 的相关字段, 就可以判定是否可以继续进行操作.
承载主要调谐功能的函数 enforceSpec 中就有大量的针对 BlockingOperation 的比较和判断, 以确定是否可以进行调谐. BlockingOperation 的抽象非常值得借鉴.
const ( TransitionOperationStepId = "Transition step: waiting either for the next step to start or for the operation to be removed ..." // enforcement 实施, 施行, 那这个项目里的 enforce 就不是强制的意味, 而可能是实施 OperationIdBaseConfigCountSpecEnforcement = "Base config count spec enforcement" OperationStepIdBaseConfigDeploying = "Base config is deploying" OperationIdPrimaryDbCountSpecEnforcement = "Primary DB count spec enforcement" OperationStepIdPrimaryDbDeploying = "Primary DB is deploying" OperationStepIdPrimaryDbWaitingBeforeFailingOver = "Waiting few seconds before failing over by promoting a Replica DB as a Primary DB" OperationStepIdPrimaryDbFailingOver = "Failing over by promoting a Replica DB as a Primary DB" OperationIdReplicaDbCountSpecEnforcement = "Replica DB count spec enforcement" OperationStepIdReplicaDbDeploying = "Replica DB is deploying" OperationStepIdReplicaDbUndeploying = "Replica DB is undeploying" OperationIdStatefulSetSpecEnforcing = "Enforcing StatefulSet's Spec" OperationStepIdStatefulSetSpecUpdating = "StatefulSet's spec is updating" OperationStepIdStatefulSetPodSpecUpdating = "StatefulSet Pod's spec is updating" OperationStepIdStatefulSetWaitingOnStuckPod = "Attempting to fix a stuck Pod by recreating it" )
主从复制
主从复制使用了 initContainer, 脚本 copy_primary_data_to_replica.sh 把数据复制到环境变量 PGDATA 指向的文件夹之后, initContainer 退出. container Replica Postgres 启动后, 直接加载来自 Primary 的数据.
在这里区分一个概念, initContainer 和 sidecar, sidecar 的 containers 一般与提供实际服务的 container 并排运行, 并为该 container 提供各种服务, initContainer 不是 sidecar.
initContainers: - name: setup-replica-data-directory image: postgres:latest imagePullPolicy: IfNotPresent env: - name: PRIMARY_HOST_NAME - name: PGPASSWORD - name: PGDATA command: - sh - -c - /tmp/copy_primary_data_to_replica.sh
进阶
使用 Kubebuilder 将 kubegres 的架构移植到 MySQL 5.7 和 8.0.