Git

什么是 Lease？ Lease 对象的核心作用是表示某个实体（通常是一个 Pod 或进程）对某项资源或角色的“持有权”，并且这种持有权是有时间限制的。通过定期续约（renew），持有者可以保持其控制权。如果持有者未能续约，租约到期后，其他实体可以接管。 常见的应用场景包括： 领导选举：在分布式系统中，确保只有一个实例（Leader）执行特定任务，其他实例作为 Follower。 资源协调：跟踪和管理资源的临时所有权。 心跳机制：通过续约时间（RenewTime）检测持有者是否仍然活跃。 Kubernetes 内部的一些组件（如 kube-controller-manager 和 kube-scheduler）就使用 Lease 来实现高可用性和领导选举。 Lease 的工作原理 创建租约： 一个进程（如你的代码）创建一个 Lease 对象，并声明自己为持有者（HolderIdentity）。 续约： 持有者需要定期更新 RenewTime，证明自己仍然活跃。通常通过客户端（如 kubectl 或 Go 客户端）调用 Kubernetes API 来更新。 失效与接管： 如果持有者未能及时续约（例如进程崩溃），其他进程可以通过检查 RenewTime 和 LeaseDurationSeconds 判断租约是否过期，并尝试接管。 领导选举： 多个实例竞争同一 Lease 对象时，只有成功创建或更新它的实例成为 Leader。 示例场景 假设你用这个 Lease 来实现领导选举： 你有一个分布式应用，有 3 个 Pod：pod-1、pod-2、pod-3。 它们都尝试创建或更新同一个 Lease 对象（例如 my-leader-lease）。 pod-1 成功创建，设置 HolderIdentity: “pod-1”，成为 Leader。 pod-1 每 10 秒更新 RenewTime，保持领导地位。 如果 pod-1 崩溃，RenewTime 未更新，pod-2 检测到租约过期，接管并更新 HolderIdentity: “pod-2”。 现有逻辑 // Copyright 2018 The Operator-SDK Authors // // Licensed under the Apache License, Version 2.0 (the "License"); // you may not use this file except in compliance with the License. // You may obtain a copy of the License at // // http://www.apache.org/licenses/LICENSE-2.0 // // Unless required by applicable law or agreed to in writing, software // distributed under the License is distributed on an "AS IS" BASIS, // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. // See the License for the specific language governing permissions and // limitations under the License. package main import ( "context" "time" "github.com/operator-framework/operator-sdk/pkg/k8sutil" // Operator-SDK 提供的...

用字符画描述git的合并方法 1. 合并（Merge） main 分支 A---B---C \ dev 分支 D---E---F 在 main 分支上执行 `git merge dev` 后： main 分支 A---B---C-----------G <- (G 是合并提交) \ / dev 分支 D---E---F 2. 变基（Rebase） main 分支 A---B---C \ dev 分支 D---E---F 在 dev 分支上执行 `git rebase main` 后，再在 main 分支上执行 `git merge dev`： main 分支 A---B---C---D'---E'---F' 3. 压缩合并（Squash and Merge） main 分支 A---B---C \ dev 分支 D---E---F 在 main 分支上执行 `git merge --squash dev` 后，再执行提交： main 分支 A---B---C-----------G' <- (G' 是一个新的提交，合并来自 D、E 和 F 的变更) 4. 拣选提交（Cherry-pick）（不是标准合并所有更改的方法） main 分支 A---B---C \ dev 分支 D---E---F 在 main 分支上对 dev 分支的每个提交执行 `git cherry-pick <提交哈希值>`： main 分支 A---B---C---D'---E'---F' <- (每个提交被逐一复制) 合并方法的对比表格 方法 特点 适用场景 结果 Merge 保留所有分支的历史 标准的合并操作，适用于大多数场景 创建一个新的合并提交 Rebase 使历史线性化 个人分支上的工作或清洁历史 不保留原始分支提交的顺序 Squash and Merge 将所有更改压缩为一个提交 当你想要简化复杂分支的历史时 一个新的单一提交 Cherry-pick 手动选择特定提交 只合并某些特定的更改 对选择的每个提交创建新的提交 请注意，这些方法中，Merge 和 Rebase 是最常用的策略来整合一个开发分支（如 dev）到主分支（如 main）。Squash and Merge 通常用于在合并之前压缩多个提交以保持清洁的历史。Cherry-pick 方法并不是一个真正的分支合并策略，它只是用于将选定的提交从一个分支复制到另一个分支，因此它不应用于将一个完整的功能分支合并到主分支的场景。