Hi, I'm Vimiix

Kubernetes APIServer 鉴权机制

Thu, 16 Oct 2025 07:54:28 +0000

1. 引言

在 Kubernetes 集群中，认证（Authentication）解决了“你是谁”的问题，而鉴权（Authorization）则解决了“你能做什么”的问题。鉴权是 Kubernetes 安全框架的核心支柱之一，它位于认证之后，用于确定一个已经通过身份认证的用户或服务账户（ServiceAccount）是否拥有对特定资源执行特定操作的权限。Kubernetes 采用了一种声明式的、基于属性的访问控制（ABAC）和基于角色的访问控制（RBAC）等模型来实现精细化的权限管理。本文将简单介绍 Kubernetes 的鉴权机制，包括其架构、工作流程、核心模型及详细实现原理。

2. 鉴权架构

Kubernetes API Server 是集群所有操作的唯一入口，它也是鉴权决策的中心。当一个请求通过认证后，API Server 会将该请求传递给鉴权模块进行处理。

Kubernetes 支持多种鉴权模块，例如：

Node：用于授权 kubelet 对节点和 Pod 等资源的访问。
ABAC（Attribute-Based Access Control）：基于属性的访问控制，策略存储在静态文件中。
RBAC（Role-Based Access Control）：基于角色的访问控制，是当前最主流和推荐的方式。
Webhook：通过调用外部 RESTful 服务来做出鉴权决策。

这些模块可以同时配置多个。如果配置了多个模块，请求必须被至少一个模块允许，且不能被任何模块拒绝，整个请求才会被授权。API Server 默认允许一个匿名请求，除非被认证层或鉴权层拒绝。

下图是请求经过认证与鉴权的核心流程：

flowchart TD A[客户端请求
（User/ServiceAccount）] --> B[API Server] B --> C{认证} C -- 携带合法令牌/证书 --> D[认证成功
获取请求者身份信息] C -- 令牌/证书无效 --> E[认证失败
返回401 Unauthorized] D --> F[鉴权模块链] subgraph F [鉴权模块链] direction LR F1[Node Authorizer] --> F2[ABAC Authorizer] --> F3[RBAC Authorizer] --> F4[Webhook Authorizer] end F -- 任一模块显式拒绝 --> G[鉴权拒绝
返回403 Forbidden] F -- 所有模块未通过
（包括默认匿名允许） --> H[鉴权拒绝
返回403 Forbidden] F -- 任一模块允许
且无模块拒绝 --> I[鉴权通过] I --> J[准入控制
（Mutating/Validating）] J --> K[持久化存储
（etcd）]

3. 鉴权核心流程

一个请求的鉴权过程涉及以下几个关键步骤和对象：

3.1. 请求上下文的构建

在认证成功后，API Server 会构建一个包含请求者身份和请求详细信息的上下文对象，该对象将作为输入传递给鉴权模块。这个上下文主要包括：

用户（User）：认证后得到的用户名。
用户组（Groups）：用户所属的组。例如，system:authenticated 组包含所有已认证用户。
额外信息（Extra）：包含一些额外的键值对信息，通常由认证器提供。
API 请求信息：
- API Verb：请求的操作类型，如 get, list, create, update, delete, patch, watch。
- Resource：请求的 Kubernetes 资源，如 pods, services, deployments。
- Namespace：如果资源是命名空间范围的，则包含其命名空间。
- API Group：资源所属的 API 组，如 apps（对应 deployments）、”（核心组，对应 pods, services）。
- 子资源（Subresource）：如 pods/exec, pods/log, pods/status。
- 请求路径（Request Path）：对于非资源请求（如 /api, /healthz），使用完整路径进行鉴权。
- 资源名称（Resource Name）：某些鉴权模式（如 ABAC）可以支持基于特定资源实例名称的授权。

3.2. 多模块决策机制

API Server 会按照配置顺序，依次将请求上下文传递给每个已启用的鉴权模块。每个模块独立做出决策，决策结果有三种：

const (
	// DecisionDeny means that an authorizer decided to deny the action.
	DecisionDeny Decision = iota
	// DecisionAllow means that an authorizer decided to allow the action.
	DecisionAllow
	// DecisionNoOpinion means that an authorizer has no opinion on whether
	// to allow or deny an action.
	DecisionNoOpinion
)

拒绝（Deny）：该模块明确拒绝此请求。
允许（Allow）：该模块允许此请求。
无意见（No Opinion）：该模块对此请求没有匹配的策略，不作决定。

最终的鉴权结果遵循以下规则：

如果任何一个模块的决策是 “拒绝”，则整个请求被拒绝，API Server 返回 403 Forbidden。
如果至少一个模块的决策是 “允许”，并且没有任何模块的决策是 “拒绝”，则整个请求被允许。
如果所有模块的决策都是 “无意见”，则请求被拒绝。这是一种“默认拒绝”的安全策略。

4. 鉴权模型

4.1. RBAC（基于角色的访问控制）

RBAC 是 Kubernetes 中事实上的标准鉴权模型，它使用 Role / ClusterRole 和 RoleBinding / ClusterRoleBinding 这四种资源来定义和分配权限。

4.1.1. 核心资源对象

Role 与 ClusterRole

Role：定义在特定命名空间内的一组权限规则。它指定了可以对哪些资源（如 pods）执行哪些操作（如 get, list, create）。
ClusterRole：定义在集群范围内的一组权限规则。用于定义：
- 集群级别的资源权限（如 nodes, persistentvolumes）。
- 非资源端点权限（如 /healthz）。
- 跨所有命名空间的命名空间资源权限（需要与 ClusterRoleBinding 配合）。

Role 示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 namespace: default
 name: pod-reader
rules:
- apiGroups: [""] # 核心 API 组
 resources: ["pods"]
 verbs: ["get", "list", "watch"]

ClusterRole 示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 # 不需要 "namespace"，因为 ClusterRole 是集群范围的
 name: cluster-node-viewer
rules:
- apiGroups: [""]
 resources: ["nodes"]
 verbs: ["get", "list", "watch"]

RoleBinding 与 ClusterRoleBinding

RoleBinding：将 Role 或 ClusterRole 中定义的权限授予一个或多个用户或服务账户。RoleBinding 在特定命名空间中生效。如果它引用的是一个 ClusterRole，那么被授权者只能在 RoleBinding 所在的命名空间内行使该 ClusterRole 的权限。
ClusterRoleBinding：将 ClusterRole 中定义的权限授予一个或多个用户或服务账户，授权范围是整个集群。

RoleBinding 示例（将 pod-reader Role 授予用户 vimiix）：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 name: read-pods
 namespace: default
subjects:
- kind: User
 name: vimiix
 apiGroup: rbac.authorization.k8s.io
roleRef:
 kind: Role
 name: pod-reader
 apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding 示例（将 cluster-node-viewer ClusterRole 授予组 system:authenticated）：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: read-nodes-global
subjects:
- kind: Group
 name: system:authenticated
 apiGroup: rbac.authorization.k8s.io
roleRef:
 kind: ClusterRole
 name: cluster-node-viewer
 apiGroup: rbac.authorization.k8s.io

4.1.2. RBAC 鉴权器工作流程

RBAC 鉴权器接收到请求上下文后，会执行以下逻辑：

识别主体（Subject）：从上下文中提取用户和用户组。
查找绑定关系：
- 列出所有与当前用户及所属用户组匹配的 RoleBinding 和 ClusterRoleBinding。
获取角色规则：
- 对于找到的每个 RoleBinding，获取其引用的 Role 或 ClusterRole 中定义的规则。
- 对于找到的每个 ClusterRoleBinding，获取其引用的 ClusterRole 中定义的规则。
规则匹配：
- 遍历所有收集到的规则，检查是否有任何一条规则与当前请求的 Verb、API Group、Resource、Namespace 和 Resource Name（如果指定）相匹配。
做出决策：
- 如果找到匹配的规则，则返回**“允许”**。
- 如果未找到任何匹配的规则，则返回**“无意见”**。

4.2. ABAC（基于属性的访问控制）

ABAC 允许基于资源、用户或请求环境的任意属性组合来定义复杂的策略。策略以每行一个 JSON 对象的形式存储在策略文件（如 --authorization-policy-file=/etc/kubernetes/abac.json）中。API Server 需要重启才能加载策略文件的变更，这在动态性上不如 RBAC。

ABAC 策略文件示例：

{
 "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
 "kind": "Policy",
 "spec": {
 "user": "alice",
 "namespace": "project1",
 "resource": "pods",
 "readonly": true
 }
}
{
 "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
 "kind": "Policy",
 "spec": {
 "user": "kubelet",
 "resource": "pods",
 "readonly": false
 }
}
{
 "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
 "kind": "Policy",
 "spec": {
 "group": "system:authenticated",
 "readonly": true,
 "nonResourcePath": "*"
 }
}

ABAC 鉴权器将请求的属性与策略文件中的每条策略进行匹配，如果请求属性是某条策略属性的超集，则该策略匹配，请求被允许。

4.3. Node 鉴权

Node 鉴权是专门授权给 kubelet 访问 Node、Pod、Service、Endpoints 等资源的模块。它自动将 system:nodes 组中的用户（由 kubelet 的客户端证书中的 CN=system:node:<nodeName> 标识）与名为 system:node 的 ClusterRole 的权限关联起来，该 ClusterRole 预定义了 kubelet 运行所需的最小权限集。

4.4. Webhook 鉴权

Webhook 鉴权将鉴权决策外包给外部 HTTP(S) 服务。当配置了 Webhook 模式（--authorization-webhook-config-file）后，API Server 会向指定的外部服务发送一个 SubjectAccessReview 对象，该对象包含了完整的请求上下文。外部服务返回的响应指示是否允许该请求。

这种方式允许集成企业现有的权限管理系统，例如 Open Policy Agent (OPA)。

5. 最佳实践

遵循最小权限原则：只授予执行任务所必需的最小权限。
优先使用 RBAC： RBAC 资源是声明式的，可以通过 kubectl 和 YAML 文件轻松管理，无需重启 API Server，是当前的最佳实践。
定期审计权限：使用 kubectl auth can-i 命令或进行定期 RBAC 评审，确保权限分配符合预期。
谨慎使用 cluster-admin： cluster-admin ClusterRole 拥有集群最高权限，应严格控制其分配。
利用命名空间进行隔离：为不同的团队或项目创建独立的命名空间，并结合 RBAC 实现逻辑隔离。
为服务账户分配明确的权限：运行在 Pod 中的应用程序通过服务账户进行身份认证，务必为其绑定精确的 Role 或 ClusterRole，避免使用默认的 default 服务账户或过宽的权限。

Kubernetes APIServer 认证机制

Tue, 30 Sep 2025 08:55:48 +0000

Kubernetes 作为一个分布式系统，其 API Server 是所有组件交互的核心枢纽。为了保证集群的安全，所有访问 API Server 的请求都必须经过认证（Authentication）、鉴权（Authorization）和准入控制（Admission Control）等步骤。其中，认证是安全的第一道大门，它负责确认请求者的身份。

Kubernetes 支持多种认证机制（称为 Authenticator），以适应不同的部署环境和安全需求。这些机制可以同时启用，API Server 会逐一尝试，直到有一个机制成功认证该请求。

一、认证流程总览

任何访问 API Server 的请求（来自 kubectl、 Dashboard、节点上的 kubelet 或其他控制器）都需要携带认证信息。API Server 接收到请求后，会依次尝试配置的认证策略。如果认证成功，请求者的用户名（username）和用户组（groups）信息会被嵌入到请求的上下文中，传递给后续的鉴权阶段。如果所有认证策略都失败，则请求以 401 Unauthorized 错误被拒绝。

下图描绘了这个通用的认证决策流程：

flowchart TD A[客户端请求
携带认证信息] --> B[API Server] subgraph B [API Server 认证环节] direction LR C[尝试认证策略 1
（如: X509证书）] -->|失败| D[尝试认证策略 2
（如: Bearer Token）] D -->|失败| E[尝试认证策略 N...
（如: ServiceAccount Token）] E -->|失败| F[认证失败] C -->|成功| G[认证成功] D -->|成功| G E -->|成功| G end F --> H[返回 401 Unauthorized] G --> I[将身份信息嵌入请求上下文
（username, groups, uid等）] I --> J[进入鉴权 Authorization 阶段]

二、各种认证机制

1. X509 客户端证书认证 (TLS)

这是集群间组件通信最常用和最安全的机制之一，尤其适用于集群内部组件（如 kubelet、scheduler、controller-manager）与 API Server 的通信。

原理：

API Server 启动时需要配置一个 Certificate Authority (CA) 根证书（通常由 --client-ca-file=SOMEFILE 参数指定）。客户端需要持有一张由该 CA 签名的客户端证书。在建立 TLS 连接时，客户端会出示此证书。API Server 会验证证书的有效性（是否由信任的 CA 签发、是否在有效期内、CN 和 O 字段等）。

适用于集群组件身份认证、为外部用户或系统签发长期有效的证书。

身份信息提取：

用户名 (username)：取自证书的 CN (Common Name) 字段。
用户组 (group)：取自证书的 O (Organization) 字段。

时序图：

sequenceDiagram participant C as Client (持有客户端证书) participant A as API Server
(持有CA根证书) C->>A: 1. HTTPS Request (Client Hello + 客户端证书) Note right of C: 证书由集群CA签发 A->>A: 2. 使用 --client-ca-file 验证证书 Note right of A: a. 验证CA签名
b. 验证有效期/吊销状态等
c. 提取 CN 和 O 字段 alt 验证成功 A-->>C: 3. TLS连接建立成功 A->>A: 4. 认证身份: username=CN, groups=O A->>A: 5. 进入鉴权阶段 else 验证失败 A-->>C: 3. TLS握手失败 (证书无效) end

2. 静态令牌文件 (Static Token File)

一种简单的认证方式，通过一个静态文件来管理令牌（Token）。

原理：

API Server 通过 --token-auth-file=SOMEFILE 参数指定一个包含预定义令牌的 CSV 文件。文件格式为：token,username,uid,"group1,group2,group3"。客户端在请求头中携带 Authorization: Bearer <TOKEN>。API Server 会在文件中查找匹配的令牌。

这种认证方式的缺点是，令牌是静态的，修改需要重启 API Server，非常不灵活且不安全。一般用于临时测试或学习，不推荐在生产环境中使用。

时序图：

sequenceDiagram participant C as Client participant A as API Server
(--token-auth-file=tokens.csv) C->>A: 1. HTTP Request
Authorization: Bearer abc123 A->>A: 2. 在 tokens.csv 中查找令牌 'abc123' alt 找到匹配项 A->>A: 3. 认证身份: 提取文件中对应用户名和组 A->>A: 4. 进入鉴权阶段 else 未找到 A-->>C: 5. 返回 401 Unauthorized end

3. ServiceAccount 令牌 (Bearer Tokens)

这是 Kubernetes Pod 内部应用访问 API Server 最主要和推荐的方式。

原理：

ServiceAccount (SA)：一个命名空间内的资源，代表一个应用身份。
Secret：当创建 SA（或由控制器自动创建）时，Kubernetes 会自动生成一个对应的 Secret。该 Secret 包含三个关键信息：ca.crt (API Server 的 CA)、namespace (当前命名空间)、token (一个签名的 JWT 令牌)。
令牌挂载： Pod 通过 spec.serviceAccountName 指定 SA，对应的 Secret 会自动挂载到 Pod 内的 /var/run/secrets/kubernetes.io/serviceaccount/。
JWT 验证：客户端（Pod 内的进程）使用此令牌在请求头中设置 Authorization: Bearer <JWT_TOKEN>。API Server 使用其持有的密钥（通过 --service-account-key-file 指定，默认为自身 TLS 私钥）来验证 JWT 的签名。

时序图：

sequenceDiagram participant P as Pod中的应用程序 participant A as API Server participant S as Secret Note over P, S: Pod 启动前 A->>S: 1. 为 default SA 创建 Secret
(包含 token JWT, ca.crt) Note over P, A: Pod 运行时 P->>P: 2. 从挂载卷读取 token 和 ca.crt P->>A: 3. HTTPS Request
Authorization: Bearer {JWT} A->>A: 4. 使用自身密钥验证JWT签名
并解析载荷（payload） alt JWT有效 A->>A: 5. 认证身份: system:serviceaccount:{ns}:{sa-name}
用户组: system:serviceaccounts A->>A: 6. 进入鉴权阶段 else JWT无效 A-->>P: 7. 返回 401 Unauthorized end

4. Bootstrap 令牌 (Bootstrap Tokens)

这是一种为了简化节点加入集群流程而设计的短期令牌机制，是静态令牌的“动态”方案，推荐 worker 节点首次加入集群时使用。

原理：

令牌格式：格式为 [a-z0-9]{6}.[a-z0-9]{16} (例如 abcdef.0123456789abcdef)。
Secret 资源： Bootstrap 令牌实际上对应着 kube-system 命名空间中的一个特定 Secret，其类型为 bootstrap.kubernetes.io/token。这使得令牌可以通过 API 动态管理，无需重启 API Server。
用途：新节点使用此令牌发起 TLS 引导请求，API Server 的 Bootstrap Token Authenticator 会验证 Secret 是否存在且未过期。认证成功后，节点随后会申请正式的证书用于长期通信。

时序图：

sequenceDiagram participant N as New Node (新节点) participant A as API Server participant C as Controller Manager
(TokenCleaner) N->>A: 1. 证书签名请求(CSR)
Authorization: Bearer bootstrap-token-abcdef A->>A: 2. 检查 kube-system 中是否存在
对应的 bootstrap-token Secret alt Secret 存在且有效 A->>A: 3. 认证成功 A->>A: 4. 批准CSR（可能需要手动） A-->>N: 5. 颁发正式客户端证书 N->>A: 6. 使用新证书进行后续通信 C->>C: 7. (稍后) 自动清理过期的bootstrap Secret else Secret 无效或不存在 A-->>N: 8. 返回 401，加入集群失败 end

5. OpenID Connect (OIDC) 令牌

这是一种连接企业现有身份系统（如 Google、Azure AD、Keycloak、Dex 等）的标准协议，用于集成外部用户认证系统。适用于开发者、管理员等人类用户通过企业单点登录（SSO）系统访问集群。

原理：

三方协作：涉及客户端（kubectl）、API Server 和外部身份提供商（IdP）。
用户登录：用户首先通过 kubectl 在外部 IdP 完成认证，获取一个 IdP 签名的 JWT 令牌（ID Token）。
传递令牌： kubectl 在请求 API Server 时，在 Authorization 头中携带此 ID Token。
API Server 验证： API Server 不直接与 IdP 通信，而是通过配置（--oidc-issuer-url, --oidc-client-id）获取 IdP 的公钥，来验证 JWT 令牌的签名。它还会验证令牌的受众（aud Claim）是否与 --oidc-client-id 匹配。

时序图：

sequenceDiagram participant U as User (kubectl) participant A as APIServer participant I as OIDC Identity Provider (IdP) U->>I: 1. 用户登录 (获取ID Token) I-->>U: 2. 返回签名的 JWT ID Token U->>A: 3. API Request
Authorization: Bearer {IDToken} A->>A: 4. 从配置的issuer-url获取JWKS公钥 A->>A: 5. 使用公钥验证JWT签名
并检查audience/issuer/有效期 alt 验证成功 A->>A: 6. 认证身份: 提取JWT中的preferred_username/groups等字段 A->>A: 7. 进入鉴权阶段 else 验证失败 A-->>U: 8. 返回 401 Unauthorized end

6. Webhook 令牌认证

这是一种扩展机制，当 Kubernetes 内置的认证方式都无法满足需求时，可以将认证决策委托给一个外部的 RESTful 服务，适用于集成自定义的认证系统、私有身份存储等。

原理：

配置： API Server 启动时配置 --authentication-token-webhook-config-file，该文件指向一个外部服务的配置（URL、CA 等）。
委托验证：当客户端携带 Bearer Token 请求时，API Server 会将一个 TokenReview 对象发送给外部 Webhook 服务。
外部决策： Webhook 服务验证令牌的有效性，并将结果（认证成功与否，以及用户信息）封装在 TokenReview 对象的 status 字段中返回。
API Server 决策： API Server 根据 Webhook 的响应决定是否认证通过。

时序图：

sequenceDiagram participant C as Client participant A as APIServer participant W as External Webhook Service C->>A: 1. API Request
Authorization: Bearer {TOKEN} A->>W: 2. 构造并发送 TokenReview Request
{apiVersion: authentication.k8s.io/v1, kind: TokenReview, spec: {token: "TOKEN"}} W->>W: 3. 根据自定义逻辑验证Token
（查数据库、调用其他API等） W-->>A: 4. 返回 TokenReview Response
{status: {authenticated: true, user: {username: "foo", groups: ["bar"]}}} alt authenticated: true A->>A: 5. 认证成功，使用返回的用户信息 A->>A: 6. 进入鉴权阶段 else authenticated: false A-->>C: 7. 返回 401 Unauthorized end

三、总结对比

认证机制	主要用途	管理方式	安全性	生产环境推荐
X509 证书	组件间通信，系统级访问	动态（CA签发）	非常高	推荐（用于组件）
ServiceAccount	Pod内应用访问API	动态（K8s自动管理）	高	必须使用（用于Pod）
Bootstrap Token	新节点加入集群	动态（Secret资源）	中（短期）	推荐（用于节点引导）
OIDC	人类用户单点登录	外部IdP管理	高	推荐（用于用户）
Webhook	集成自定义认证系统	外部服务管理	取决于实现	按需使用
静态Token文件	测试	静态文件，需重启	低	不推荐

理解这些认证机制的原理和适用场景，是构建和维护一个安全、可靠的 Kubernetes 集群的基石。

使用 kubeadm 搭建 kubernetes 集群

Mon, 16 Dec 2024 15:23:48 +0000

准备4台虚拟机，拓扑为一个 master, 3 个 node 节点，操作系统均为 CentOS 7.9，网络采用桥接模式，设置静态IP。

机器名	IP
master	192.168.3.200
node1	192.168.3.201
node2	192.168.3.202
node3	192.168.3.203

安装前环境准备

YUM 源修改

# 1. 修改 yum 源到国内
curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo

# 2. 安装部分依赖包
yum install -y yum-utils device-mapper-persistent-data lvm2

# 3. 增加 docker yum 源
yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo

# 4. 增加 kubernetes yum 源
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg
 https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
EOF

安装一些常用工具

yum install wget jq psmisc vim net-tools telnet git -y

关闭防火墙，SELinux，DNSmasq(配置DNS和DHCP的轻量级工具)，swap

systemctl disable --now firewalld
systemctl disable --now dnsmasq

swapoff -a && sysctl -w vm.swappiness=0
sed -ri '/^[^#]*swap/s@^@#@' /etc/fstab

# 修改 /etc/selinux/config 文件中的配置为 disabled，然后重启生效
sed -i 's#SELINUX=enforcing#SELINUX=disabled#g' /etc/selinux/config

安装 ntpdate，同步时钟 (如果已经配置了时钟同步服务器，则跳过)

rpm -ivh http://mirrors.wlnmp.com/centos/wlnmp-release-centos.noarch.rpm && \
 yum install ntpdate -y && \
 ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && \
 echo 'Asia/Shanghai' > /etc/timezone && \
 ntpdate time2.aliyun.com

# 设置定时任务每5分钟同步一下时钟
crontab -e
# 配置如下规则
*/5 * * * * /usr/sbin/ntpdate time2.aliyun.com

默认 limit 配置

ulimit -SHn 65535

vim /etc/security/limits.conf
# 末尾追加如下内容

* soft nofile 65536
* hard nofile 131072
* soft nproc 65535
* hard nproc 655350
* soft memlock unlimited
* hard memlock unlimited

在master 生成ssh秘钥，拷贝到其他节点，实现master免密登录其他节点

ssh-keygen -t rsa
for i in node1 node2 node3; do ssh-copy-id -i .ssh/id_rsa.pub $i; done

安装 k8s 集群

1.24版本以后默认使用containerd 作为runtime，所以安装 containerd

# 修改必要系统配置
modprobe br_netfilter
echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 1 > /proc/sys/net/ipv4/ip_forward

yum install -y containerd kubelet kubeadm kubectl --disableexcludes=kubernetes
# 启动 containerd
systemctl daemon-reload
systemctl enable containerd
systemctl enable kubelet

# 把 containerd 默认配置写到配置文件中
containerd config default > /etc/containerd/config.toml
# 编辑 /etc/containerd/config.toml 文件，
# 如果存在 disabled_plugins = ["cri"]，把列表中的cri 去掉，或者注释掉这一行
# 否则 kubeadm init 的时候会报错 "CRI v1 image API is not implemented for endpoint"

# 另外把 containerd 的 cgroup 驱动改为 systemd，找到如下行，把SystemdCgroup 改为true
 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
 SystemdCgroup = true

# 国内配置一下国内源，修改配置文件中 config_path 的值
 config_path = "/etc/containerd/certs.d"

# 保存配置文件退出，然后创建/etc/containerd/certs.d/目录，在这个目录下创建不同站点的代理
# hosts.toml中可以配置多个镜像仓库，containerd下载镜像时会根据配置的顺序使用镜像仓库，
# 只有当上一个仓库下载失败才会使用下一个镜像仓库。
# 因此，镜像仓库的配置原则就是镜像仓库下载速度越快，那么这个仓库就应该放在最前面。

# docker hub镜像加速
mkdir -p /etc/containerd/certs.d/docker.io
cat > /etc/containerd/certs.d/docker.io/hosts.toml << EOF
server = "https://docker.io"
[host."https://dockerproxy.com"]
 capabilities = ["pull", "resolve"]

[host."https://docker.m.daocloud.io"]
 capabilities = ["pull", "resolve"]

[host."https://reg-mirror.qiniu.com"]
 capabilities = ["pull", "resolve"]

[host."https://registry.docker-cn.com"]
 capabilities = ["pull", "resolve"]

[host."http://hub-mirror.c.163.com"]
 capabilities = ["pull", "resolve"]

EOF

# registry.k8s.io镜像加速
mkdir -p /etc/containerd/certs.d/registry.k8s.io
tee /etc/containerd/certs.d/registry.k8s.io/hosts.toml << 'EOF'
server = "https://registry.k8s.io"

[host."https://k8s.m.daocloud.io"]
 capabilities = ["pull", "resolve", "push"]
EOF

# docker.elastic.co镜像加速
mkdir -p /etc/containerd/certs.d/docker.elastic.co
tee /etc/containerd/certs.d/docker.elastic.co/hosts.toml << 'EOF'
server = "https://docker.elastic.co"

[host."https://elastic.m.daocloud.io"]
 capabilities = ["pull", "resolve", "push"]
EOF

# gcr.io镜像加速
mkdir -p /etc/containerd/certs.d/gcr.io
tee /etc/containerd/certs.d/gcr.io/hosts.toml << 'EOF'
server = "https://gcr.io"

[host."https://gcr.m.daocloud.io"]
 capabilities = ["pull", "resolve", "push"]
EOF

# ghcr.io镜像加速
mkdir -p /etc/containerd/certs.d/ghcr.io
tee /etc/containerd/certs.d/ghcr.io/hosts.toml << 'EOF'
server = "https://ghcr.io"

[host."https://ghcr.m.daocloud.io"]
 capabilities = ["pull", "resolve", "push"]
EOF

# k8s.gcr.io镜像加速
mkdir -p /etc/containerd/certs.d/k8s.gcr.io
tee /etc/containerd/certs.d/k8s.gcr.io/hosts.toml << 'EOF'
server = "https://k8s.gcr.io"

[host."https://k8s-gcr.m.daocloud.io"]
 capabilities = ["pull", "resolve", "push"]
EOF

# mcr.m.daocloud.io镜像加速
mkdir -p /etc/containerd/certs.d/mcr.microsoft.com
tee /etc/containerd/certs.d/mcr.microsoft.com/hosts.toml << 'EOF'
server = "https://mcr.microsoft.com"

[host."https://mcr.m.daocloud.io"]
 capabilities = ["pull", "resolve", "push"]
EOF

# nvcr.io镜像加速
mkdir -p /etc/containerd/certs.d/nvcr.io
tee /etc/containerd/certs.d/nvcr.io/hosts.toml << 'EOF'
server = "https://nvcr.io"

[host."https://nvcr.m.daocloud.io"]
 capabilities = ["pull", "resolve", "push"]
EOF

# quay.io镜像加速
mkdir -p /etc/containerd/certs.d/quay.io
tee /etc/containerd/certs.d/quay.io/hosts.toml << 'EOF'
server = "https://quay.io"

[host."https://quay.m.daocloud.io"]
 capabilities = ["pull", "resolve", "push"]
EOF

# registry.jujucharms.com镜像加速
mkdir -p /etc/containerd/certs.d/registry.jujucharms.com
tee /etc/containerd/certs.d/registry.jujucharms.com/hosts.toml << 'EOF'
server = "https://registry.jujucharms.com"

[host."https://jujucharms.m.daocloud.io"]
 capabilities = ["pull", "resolve", "push"]
EOF

# rocks.canonical.com镜像加速
mkdir -p /etc/containerd/certs.d/rocks.canonical.com
tee /etc/containerd/certs.d/rocks.canonical.com/hosts.toml << 'EOF'
server = "https://rocks.canonical.com"

[host."https://rocks-canonical.m.daocloud.io"]
 capabilities = ["pull", "resolve", "push"]
EOF


# 重启 containerd 服务
systemctl restart containerd

为了加快集群部署速度，预先下载kubeadm 所需的全部镜像

# （optional） 查看 kubeadm 所需的全部镜像
kubeadm config images list

# 拉去所需镜像
kubeadm config images pull

在master 上通过kubeadm一键安装 master节点

kubeadm init

在所有 node 节点上执行 kubeadm init 日志最后的 join 命令

# 这个命令根据实际的输出内容执行
kubeadm join 192.168.3.200:6443 --token 9unwvu.jogfdub8buf3y2os \
 --discovery-token-ca-cert-hash sha256:cad35b01dc5094aa82456e2d166393f5d790e4a452ebbd3df39801cd8997a241

设置kubectl 要加载的配置，可以通过把配置文件放到 ~/.kube/config 或者设置 KUBECONFIG 环境变量

这里我使用环境变量的方式，将设置环境变量的命令放到 ~/.bashrc 里

# master 节点
echo 'export KUBECONFIG=/etc/kubernetes/admin.conf' >> ~/.bashrc
# node 节点
echo 'export KUBECONFIG=/etc/kubernetes/kubelet.conf' >> ~/.bashrc
source ~/.bashrc

# 测试
[root@master ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
master NotReady control-plane 19m v1.28.2
node1 NotReady <none> 12m v1.28.2
node2 NotReady <none> 12m v1.28.2
node3 NotReady <none> 12m v1.28.2

安装 calico 网络插件

此时所以得节点还是处于 NotReady 状态，因为还没有安装 CNI 网络插件

kubectl apply -f "https://docs.projectcalico.org/manifests/calico.yaml"

(Optional) 安装 nerdctl 用于手动下载镜像

wget https://github.com/containerd/nerdctl/releases/download/v2.0.2/nerdctl-2.0.2-linux-amd64.tar.gz
mkdir -p /usr/local/containerd/bin/ && \
 tar -zxvf nerdctl-2.0.2-linux-amd64.tar.gz -C /usr/local/containerd/bin/ && \
 ln -s /usr/local/containerd/bin/nerdctl /usr/local/bin/nerdctl

如何做code review

Fri, 20 Sep 2024 08:54:48 +0000

为什么要做code review

从一个需求开发的完整生命周期来看，大约会包含以下过程:

需求分析，考虑人员情况、功能预期上线时间、技术难度等诸多因素，与 PM 讨论合理调整需求，分配资源；
整体设计，对设计进行 review；
代码开发；
开发自我 review，观察、思考与整体设计的出入，保证代码遵循团队规范（至少得通过静态代码检查）；
添加相应的单元测试，并保证已有的单元测试不受影响；
code review，请相关同事对代码进行 review，修复 review 中发现的问题；
提交代码给 QA 测试，QA 会进行功能测试、集成测试、性能测试、压力测试等；
修复测试发现的 bug 后功能上线。

从上属流程可以看出，代码写完了会有专业的测试同事来进行全方位的测试，那么为什么还要 code review 呢？其次，合格的程序员理论上都会 review 自己的代码，还有没有必要请同事来 review 呢？

一个 bug，可能在代码 review 的时候被发现；也可能在测试的时候被发现；最坏的情况下，被用户发现，当然，此时很可能给用户、产品带来损失。越早发现问题，受影响的人员越少，修复成本就越小。

开发人员有时也有一个误区，觉得自己完成 “代码开发” 这一步就万事大吉了，测试的事情就应交给 QA 去执行。但很多时候，QA 更多从功能角度去验证代码，有时候黑箱测试也很难覆盖到全部情况，比如异常、安全性问题、版本依赖。况且现在很多公司都逐渐去掉专门的 Test，开发得自己测试，但思维定势导致很难发现自己的问题，对自己代码的 review 也是如此。另外，知道自己的代码也被人“拿着放大镜仔细观察”，自然写代码的时候也认真一些。

另外，从上述流程可以看出：

其实应该有两次定位不同的 review：对整体设计的 review，主要目的是从大方向上保证设计确实能满足需求；其次是 code review，保证代码实现符合设计约束，且编码没有明显的缺陷。
用来 code review 的代码，应该既满足团队代码规范，又基本保证功能的正确。

在我们的实践中，对于复杂的系统，会要求现先设计 review。而对于简单的、或者开发比较有把握的功能，则是将设计 review 与代码 review 合并。本文讨论的 code review 其实就是后者：既关注设计，又关注核心代码。

code review 的目标和原则

code review 的首要目标是：找出代码中的缺陷，保证代码质量。其次，通过 review 也能相互学习，提高团队整体水平，而且特别有利于新人快速融入团队，保持与团队风格一致。最后，保证每个核心功能有多个同事了解，降低风险。

从其核心目标我们就可以看出 code review 的第一原则：对事不对人。这一点需要 reviewer、author 达成共识。code review 不是批斗大会，reviewer、author 并没有高低之分。

对于 reviewer 而言，参与的首要目的在于协助发现问题，因此：

尽量质疑自己而不是对方

✓：我没有看懂这段代码的逻辑 ×：你这段代码有问题吧

指出代码有问题而不是指责人

✓：这段代码是不是可能出问题 ×：你又写出 bug 来了

对于 author，应当把 review 当作一次学习成长的机会，毕竟平时又有谁来给你免费建议和指导呢？因此，不要一开始就是防御的姿态，即使 reviewer 有所误解也不用脸红脖子粗的去争论。

要真正让 author 放松，达到和谐 review 的效果，个人觉得还要注意以下几点：

review 不应该与任何 KPI 挂钩，review 发现的缺陷不应纳入绩效考核。
团队 Leader 应该少发言（否则就会变成 Leader 说啥就是啥），甚至要少参加无关的 review，毕竟任何人都不希望给 Leader 留下自己很菜的印象。
得需要有人充当仲裁者的角色，化解 reviewer 与 author 的冲突。而且，必要的时候维护 author。

code review 步骤以及注意事项

code review 并不简单是一堆人一起看代码，要让 code review 的效果最大化，整个流程是需要认真组织的：

review 前

author 得保证代码质量：代码满足团队规范且基本测试通过
author 至少提前一天通知参与 review 会议的同事，提供必要的需求、设计文档
reviewer 简单了解需求、设计、代码实现

这里需要注意的是，与会人员越少越好，无关的同事最好不要参加 review。如果与会者对相关的功能不感兴趣，那么就存粹是在浪费时间，这也是很多人不喜欢 code review 的原因。

review 中

review 的过程大约是：

author 大致讲解需求和整体设计，然后是核心代码
reviewer 提出问题，author 确认是否是问题
对发现的问题进行记录，分类处理

review 中需要注意：

控制 review 的时间，codereview 本身就是一个高强度的活动，时间过长大家都很疲惫，效率也会下降，经验值一个小时左右比较合适。
控制 review 的代码量，需要大家仔细阅读的代码最好也控制在 200 - 400 逻辑行（这个数值也是 the art of unix programming 中对模块代码量的建议值）
需要有支主持人控场，把控时间和进度。和任何高效会议一样，应该避免发散，尽量只发现问题，并不深入讨论如何解决问题。
记录发现的问题，以及相应的解决方案：
- 已有明确修复方案只待执行？
- 还是需要修复但解决方法尚需要进一步讨论？
- 还是在下一次迭代时再修复？

reviewer 内容依次是：

是否满足功能需求，有没有多做，有没有少做，有没有潜在的 bug，
是否满足非功能需求。性能（高频调用的函数、核心算法）？可用性（异常处理是否完善）？可读性？
代码质量、规范

上面也提到，code review 本身是个高强度的活动，因此容易漏掉一些关键点点，因此不妨做一个 review list，对照这个 list 去考察代码。list 保证了 code review 的质量下限，且不影响与会者发挥主观能动性，发现其他问题。

此外，也需要避免在没有明确规范的问题下过多争执。达到同样的效果，A 方法可以，B 方法也可以，如果团队没有约束用哪种方法，那么就不要在 code review 的时候讨论。

review 后

review 会议结束并不意味这个 review 这个活动结束，因为还有待解决的问题，因此应该借助工具跟踪 review 发现的问题，指明问题的修复者、问题的验收人、问题的验收时间。当一次 review 所关联的所有问题都得到修复之后，review 活动才算结束。

总结

如何才能 code review 有效且高效，总结以下几点：

会前充分准备，与会人员最少化
参考 review list，发现问题但不发散去讨论解决问题
会后跟进问题修复

最重要的事，是通过几次组织良好的实践让大家看到 code review 确实是有价值的，有所收获才愿意持续付出。

本文摘自: https://www.cnblogs.com/xybaby/p/12601471.html, 特此留存学习。

Python中的弱引用

Mon, 12 Aug 2024 08:35:48 +0000

前言

在理解弱引用之前，我们需要先了解 python 中的对象引用和垃圾回收的基本概念，这样更有助于对弱引用的理解。

对象引用

在 Python 中，一切皆为对象，包括变量、函数、类以及其实例化的对象。我们要是有对象就必须通过赋值语句来创建一个引用（可以理解为标签），比如 a = 1，这里 a 就是对象 1 的引用。每个引用的所指向的对象都可以通过 id() 函数来查看，两个引用是否相同可以通过 is 运算符来比较。

(==和 is 的区别：== 运算符比较对象的值（对象中保存的数据），而 is 比较引用的对象是否为同一个。)

如果想要查看一个对象的内引用次数，可以通过 sys.getrefcount(a) -1 查看（减1是因为调用 sys.getrefcount 函数传递参数时会增加一次引用）。

为了说明后面的弱引用，我们将计数的引用成为强引用。

垃圾回收

Python 中的对象在以下两种情况下会被视为垃圾，进而将其所占用的内存回收（GC）：

没有任何引用指向该对象；
存在循环引用；（循环引用解释器会判定为无法获取，所以都会被销毁，不在本文展开）

del 语法可以实现删除一个对象的引用，而不是对象本身，当我们将指向目标对象的所有引用都删除后，才会触发 Python 的解释器的垃圾回收机制，回收该对象的内存地址。（理解到这里就够，关于更详细的分代垃圾回收的算法等，请自行学习）

另外，除了使用 del 来删除引用外，重新绑定也可能会导致对象引用数量归零触发垃圾回收。比如：

a = [1]
a = [2] # 此时 [1] 这个对象就会被销毁，因为引用 a 被指向了 [2] 这个对象，[1] 的引用数就归零了

weakref 模块的原理

在 Python 中，内存管理是一个重要的话题。通过前言的铺垫，我们大概了解了 Python 是通过引用计数的方式实现内存管理机制来管理对象的生命周期的。然而，有些情况下，我们可能希望在不影响对象生命周期的前提下，引用某些对象，这时候就可以使用 Python 中的 weakref 模块。

weakref（弱引用）是一个用于跟踪对象的模块，它允许创建不会阻止对象被垃圾回收的引用。通常情况下，Python 中的强引用会增加对象的引用计数，当强引用计数变为零时，Python的垃圾回收器会自动回收该对象。然而，使用 weakref 创建的弱引用不会增加对象的引用计数，因此，当该对象的强引用计数降为零时，即使弱引用仍然存在，垃圾回收器也会回收该对象。

弱引用的存在使得我们可以创建对象的缓存、代理对象等场景，并且不会因不必要的引用而导致内存泄漏或对象无法及时回收。

weakref 的使用方法

创建弱引用

在 Python 中，weakref.ref 函数可以用于创建弱引用。例如：

import weakref

class A:
 def __init__(self, value):
 self.value = value

obj = A(10)
weak_ref = weakref.ref(obj)
print(weak_ref) # 输出：<weakref at 0x...; to 'A' at 0x...>

# 通过弱引用访问原对象
print(weak_ref()) # 输出：<__main__.A object at 0x...>

在上述代码中，我们创建了一个 A 对象并将其传递给 weakref.ref 以创建一个弱引用。通过 weak_ref() 可以访问到原始对象。需要注意的是，如果原对象被垃圾回收，weak_ref()将返回 None。

弱引用的回调

在某些情况下，我们可能希望在弱引用所指向的对象被回收时执行特定的操作。这时，我们可以为弱引用注册一个回调函数。例如：

import weakref

class A:
 def __del__(self):
 # 这里演示调用顺序，不建议自己在 __del__ 方法中自定义代码
 print("A object is being destroyed")

def on_finalize(reference):
 print(f"Object {reference} is being finalized.")

obj = A()
weak_ref = weakref.ref(obj, on_finalize)

# 删除强引用，触发垃圾回收
del obj
# 输出：A object is being destroyed
# 输出：Object <weakref at 0x...; dead> is being finalized.

在这里，我们为 weakref.ref 传递了一个回调函数 on_finalize。当对象被垃圾回收时，该回调函数会被触发。

weakref.WeakValueDictionary

weakref.WeakValueDictionary 是 weakref 模块中常用的一个类，它提供了一个类似于字典的对象，其中的值是通过弱引用进行存储的。使用 WeakValueDictionary 可以避免缓存中的对象被意外持久化，从而有效地防止内存泄漏。

import weakref

class A:
 def __init__(self, value):
 self.value = value

weak_dict = weakref.WeakValueDictionary()
obj1 = A(10)
obj2 = A(20)

weak_dict['a'] = obj1
weak_dict['b'] = obj2

print(weak_dict['a']) # 输出：<__main__.A object at 0x...>

del obj1
print(weak_dict('a')) # 输出：None

当 obj1 被删除时，对应的弱引用也会失效，因此在字典中查询 'a' 的值会返回None。

weakref.WeakKeyDictionary

weakref.WeakKeyDictionary 与 WeakValueDictionary 类似，只不过它使用弱引用来存储字典的键，而不是值。这在需要根据对象特性进行缓存或者存储临时数据的场景中非常有用。

import weakref

class A:
 def __init__(self, value):
 self.value = value

obj1 = A(10)
obj2 = A(20)

weak_dict = weakref.WeakKeyDictionary()
weak_dict[obj1] = 'First'
weak_dict[obj2] = 'Second'

print(weak_dict[obj1]) # 输出：First

del obj1
print(list(weak_dict.keys())) # 仅输出 [<__main__.A object at 0x...>]，obj1 对应的键已删除

weakref.ref() 和 weakref.proxy() 的区别

weakref.ref() 和 weakref.proxy() 都是用于创建对象的弱引用的工具，但它们在行为和应用场景上存在一些区别。

访问方式：

weakref.ref() 返回的是一个弱引用对象，你需要调用这个对象才能访问原始对象，并且需要手动处理可能返回None的情况。
weakref.proxy() 返回的是一个代理对象，直接使用它就可以像使用原始对象一样操作，但如果原始对象被回收，访问时会抛出异常。

举个实例便于理解：

import weakref
class A:
 def __init__(self, value):
 self.value = value

ref = weakref.ref(c_obj)
ref() # <__main__.C object at 0x...>
ref().value # 1

proxy = weakref.proxy(c_obj)
proxy # <weakproxy at 0x... to C at 0x...>
proxy.value # 1

weakref 的约束

并非所有对象都可以弱引用。支持弱引用的对象包括类实例、用 Python(但不是用C) 编写的函数、实例方法、set、frozensets、一些文件对象、生成器、类型对象、套接字、数组、deque、正则表达式模式对象和代码对象。

一些内置类型(如 str，list 和 dict )不直接支持弱引用，但可以通过子类化添加支持:

class Dict(dict):
 pass

obj = Dict(red=1, green=2, blue=3) # 该对象是可以被弱引用的

其他内置类型(如 tuple 和 int )即使在子类化时也不支持弱引用。

weakref 的应用场景

实现缓存机制

在实际应用中，我们经常需要缓存一些对象以提高性能，但又不希望这些对象永久占用内存。这时候可以利用 weakref 来实现一个弱引用的缓存机制，确保缓存中的对象在内存不足时可以被自动回收。

import weakref

class Cache:
 def __init__(self):
 self._cache = weakref.WeakValueDictionary()

 def get(self, key):
 return self._cache.get(key)

 def set(self, key, value):
 self._cache[key] = value

cache = Cache()
obj = A(10)
cache.set('item', obj)

print(cache.get('item')) # <__main__.A object at 0x...>
del obj
print(cache.get('item')) # None

这种机制在需要处理大量临时对象、避免内存泄漏的场景中非常有用。

使用弱引用集合

weakref 模块还提供了 WeakSet 类，用于实现一个弱引用的集合。它与普通集合类似，但其中的元素会以弱引用形式存在。

import weakref

class A:
 def __init__(self, value):
 self.value = value

obj1 = A(10)
obj2 = A(20)

my_set = weakref.WeakSet([obj1, obj2])
print(obj1 in my_set) # True
del obj1
print(my_set) # {<weakref at 0x...; to 'A' at 0x...>}

这种弱引用集合在需要跟踪大量对象但又不希望阻止其被回收时特别有用。

总结

weakref 模块提供了一种有效的内存管理手段，特别适合用于需要临时缓存对象、不希望持久占用内存的场景。通过对 weakref 的深入理解与合理应用，我们可以在复杂系统中更好地管理对象的生命周期，避免内存泄漏，提高程序的运行效率。

自定义 Django 中数据库的后端

Fri, 12 Jul 2024 11:35:48 +0000

Django 是一个全能的高级 Python Web 框架，它使得开发人员可以快速构建 Web 应用程序。Django 的一个关键特性就是它对多种数据库的支持。开发人员可以使用各种数据库后端来存储数据，如 SQLite、PostgreSQL、MySQL、Oracle 等等。但是，有时开发人员需要编写自定义数据库后端来支持一些 Django 默认不支持的特定数据库。在本文，我们将学习如何在 Django 中编写自定义数据库的后端。

步骤1：了解Django的数据库API

在开始编写自定义数据库后端之前，我们需要了解Django的数据库API是如何工作的。Django的数据库API是一组允许开发人员与数据库交互的类和方法。Django数据库API中的关键类是:

django.db.backends.BaseDatabaseWrapper
django.db.backends.DatabaseWrapper
django.db.backends.BaseDatabaseFeatures
django.db.backends.BaseDatabaseOperations
django.db.backends.BaseDatabaseClient
django.db.backends.BaseDatabaseIntrospection

BaseDatabaseWrapper 类是 Django 中所有数据库后端的基类。它为所有数据库后端提供了一个通用的接口。DatabaseWrapper 类扩展了 BaseDatabaseWrapper 类，并为最常见的数据库操作(如执行SQL查询、创建和删除表等)提供了实现。

BaseDatabaseFeatures、BaseDatabaseOperations、BaseDatabaseClient 和BaseDatabaseIntrospection 类分别提供了检查数据库特性、执行数据库操作、管理数据库客户端连接和自省数据库模式的方法。

步骤2：创建自定义数据库后端

要在 Django 中创建自定义数据库后端，我们需要创建一个 Python 模块，该模块定义一个类来扩展BaseDatabaseWrapper 类。类应该实现执行连接数据库和与数据库交互所需操作的方法。

下面是一个自定义数据库后端连接到一个假设的 NoSQL 数据库的例子:


from django.db.backends.base.base import BaseDatabaseWrapper

class NoSQLDatabaseWrapper(BaseDatabaseWrapper):
 vendor = 'NoSQL'
 def __init__(self, *args, **kwargs):
 super().__init__(*args, **kwargs)
 self.features = NoSQLDatabaseFeatures(self)
 self.ops = NoSQLDatabaseOperations(self)
 self.client = NoSQLDatabaseClient(self)
 self.introspection = NoSQLDatabaseIntrospection(self)

class NoSQLDatabaseFeatures:
 def __init__(self, wrapper):
 self.wrapper = wrapper

class NoSQLDatabaseOperations:
 def __init__(self, wrapper):
 self.wrapper = wrapper

class NoSQLDatabaseClient:
 def __init__(self, wrapper):
 self.wrapper = wrapper

class NoSQLDatabaseIntrospection:
 def __init__(self, wrapper):
 self.wrapper = wrapper

在本例中，我们定义了一个名为 NoSQLDatabaseWrapper 的自定义数据库后端。vendor 属性指定此后端支持的数据库供应商的名称。然后我们定义了四个类来扩展 Django 数据库 API 中的基类。每个类都提供了与 NoSQL 数据库交互所需的方法的实现。

步骤3：注册自定义数据库后端

要在 Django 项目中使用自定义数据库后端，我们需要在 Django 的设置中注册它。我们可以通过在 settings 文件中添加以下代码来实现:

DATABASES = {
 'default': {
 'ENGINE': 'path.to.custom.backend.NoSQLDatabaseWrapper',
 'NAME': 'database_name',
 'HOST': 'localhost',
 'PORT': '1234',
 }
}

在本例中，我们将自定义后端的名称指定为 ‘ENGINE’ 键的值。我们还提供必要的连接参数，如数据库的名称、主机名和端口号。

至此，你已经成功地在 Django 中创建了一个自定义数据库后端。现在，你就可以使用这个后端连接到 NoSQL 数据库并与之交互了。

MogDB 中 synchronous_standby_names 参数的工作机制

Wed, 05 Jun 2024 11:03:48 +0000

在 MogDB 中，参数 synchronous_standby_names 用于配置同步复制设置。特别是当这个参数设置为 '*' 时，表示可以使用任何一个可用的同步备库作为同步备库。这个配置允许任何一个当前连接的备库都可以被用作同步备库，而不需要明确指定备库的名称。

工作机制

当 synchronous_standby_names 被设置为 '*' MogDB 的同步复制机制会按照以下步骤选择同步备库：

初始连接: 当主服务器启动或参数被更改时，主服务器会接受所有连接的备库。
同步备库的确认:
- 主服务器会向所有连接的备库发送同步请求。
- 每个备库在接收到同步请求后，会进行确认并向主服务器报告其状态。
选择同步备库:
- 主服务器根据备库的响应情况，选择最早确认的一个或多个备库作为同步备库。
- 这个选择过程是动态的，也就是说，当有新的备库连接或当前的同步备库断开连接时，主服务器会重新选择同步备库。

优先级和行为

无优先级排序: 由于 '*' 表示任何备库，因此所有备库的优先级是相同的，主服务器只是选择最早响应的备库作为同步备库。
动态调整: 当一个同步备库断开连接时，主服务器会自动选择下一个响应的备库作为新的同步备库。这保证了同步复制的持续性和可靠性。
并发管理: 如果多个备库同时连接，主服务器可以处理这些并发连接，并根据同步请求的确认情况选择同步备库。

示例配置和使用

假设我们有一个主服务器和三个备库（standby1、standby2 和 standby3），在配置文件 postgresql.conf 中设置 synchronous_standby_names 为 '*'：

synchronous_standby_names = '*'

场景分析

启动时选择:
- 当主服务器启动时，所有连接的备库都会发送心跳信号并等待主服务器的同步请求。
- 主服务器会选择最早响应的备库作为同步备库。
运行时变化:
- 如果当前同步备库 standby1 断开连接，主服务器会自动选择下一个响应的备库 standby2 作为新的同步备库。
- 如果新的备库 standby3 连接到主服务器，且当前没有同步备库，主服务器会选择 standby3 作为同步备库。

动态调整

如果我们启动了主服务器和三个备库，并且设置了 synchronous_standby_names = '*'，以下是可能的状态转换示例：

初始状态: 所有备库（standby1、standby2 和 standby3）连接，主服务器选择最早响应的备库 standby1 作为同步备库。
standby1 断开连接: 主服务器自动选择下一个响应的备库 standby2 作为新的同步备库。
新备库连接: 新的备库 standby4 连接，主服务器不会改变当前的同步备库，除非 standby2 断开连接。

总结

当 synchronous_standby_names 设置为 '*' 时，PostgreSQL 会动态地选择任何一个当前可用的备库作为同步备库。这提供了一种灵活和高可用的同步复制机制，无需管理员手动指定备库的名称。选择过程基于备库的响应情况，并在运行时自动调整，以保证同步复制的持续性和可靠性。

[译]做一个拥有 Git 好习惯的开发者

Tue, 20 Feb 2024 00:50:48 +0000

如果你是一名开发人员，你可能每天都会使用 git 作为版本控制系统。这个工具的使用对于应用程序的开发过程是至关重要的，无论是在团队协作还是单独工作。但是，常常会遇到混乱的项目库，提交的 commit 信息不明确，不能传达有用的内容，以及滥用分支等问题。了解如何正确使用 git 并遵循良好的实践对于那些想要在就业市场中脱颖而出的人来说是必不可少的。

Git 分支的命名约定

当我们在处理代码版本控制时，我们应该遵循的一个好的习惯，就是为分支、提交、拉取请求等使用清晰和描述性的名称。确保所有团队成员都有一个简洁的工作流程是至关重要的。除了提高工作效率之外，记录项目的开发过程也简化了团队合作。通过遵循这些实践，你很快就会获益其中。

基于此，开发者社区创建了一些分支命名的约定，你可以在项目中遵循这些约定。虽然遵循下列规则不是硬性的要求，但它们可以帮助你提高开发技能。

使用小写字母：分支名称不要用大写字母，强制小写;
连字符分隔：如果分支名称包含多个单词，请使用连字符将它们分开，遵循短横线命名法。避免使用帕斯卡命名法、驼峰命名法或蛇形命名法;
(a-z, 0-9)：分支名称中只使用字母数字字符和连字符，避免使用其他字符;
不要使用连续的连字符(–)：这种做法可能令人困惑。例如，如果你有分支类型(如feature, bugfix, hotfix等)，使用斜杠(/)代替;
避免在分支名称的末尾使用连字符：这是没有意义的，因为连字符分隔单词，最后没有单词要分隔;
最重要的：使用描述性的、简洁的、清晰的名称来定义分支上做了什么;

不好的分支命名：

fixSidebar
feature-new-sidebar-
FeatureNewSidebar
feat_add_sidebar

好的分支名：

feature/new-sidebar
add-new-sidebar
hotfix/interval-query-param-on-get-historical-data

分支名称约定前缀

有时分支的目的并不明确。它可以是一个新特性、错误修复、文档更新或其他任何东西。为了解决这个问题，通常的做法是在分支名称上使用前缀来快速解释分支的目的。

feature：它表达了一个将被开发的新功能。例如：feature/add-filters;
release：用于准备新版本的发布。release/ 前缀通常用于在合并分支主版本的新更新以创建版本之前执行诸如最后修改和修订之类的任务。例如，release/v3.3.1-beta;
bugfix：它表达的信息是，你正在解决代码中的一个bug，而且它通常与一个问题有关。例如，bugfix/sign-in-flow;
hotfix：类似于 bugfix，但它与修复生产环境中存在的关键错误有关。例如，hotfix/cors-error;
docs：写一些文档。例如，docs/quick-start;

如果你在工作中使用任务管理相关的工具，如Jira, Trello, ClickUp，或任何类似的工具，可以考虑先创建用户故事卡，每张卡有一个数字相关联。所以，通常可以把这些卡的编号用在分支名称的前缀中。例如：

feature/T-531-add-sidebar
docs/T-789-update-readme
hotfix/T-142-security-path

提交信息 Commit message

接下来，我们来讨论一下提交消息。不幸的是，我们经常会看到这样的提交信息，如：“added a lot of things”或“Pikachu, I choose you”等（是的，我曾经发现一个项目的提交信息与poksammon战斗有关）。

提交信息在开发过程中非常重要，创造一段美好的历史会在你的人生旅途中给你带来很多帮助。和分支一样，社区也有对于提交信息的规范约定，你可以在下面了解到:

提交消息有三个重要部分:主题 Subject、描述 Description和页脚 Footer。提交的主题是必需的，并且定义了提交的目的。描述(主体)用于为提交的目的提供额外的上下文和解释。最后是页脚，通常用于元数据，如分配提交。虽然同时使用描述和页脚被认为是一种很好的做法，但这不是必需的。
在主题行中使用祈使句。例如：

Add README.md ✅; Added README.md ❌; Adding README.md ❌;

主题行的第一个字母大写。例如：

Add user authentication ✅; add user authentication ❌;

不要以句号结束主题行。例如

Update unit tests ✅; Update unit tests. ❌;

将主题行限制在50个字符以内，也就是说，要清晰简洁;
正文以72个字符进行换行，并将主题与空白行分开;
如果你的正文有多个段落，那么用空行分隔它们;
如有必要，使用要点而不是段落;

提交规范

“The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history.”

以下引用来自 Conventional Commit 的官方网站。该规范是社区中最常用的提交消息的约定。

结构

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

提交类型 Commit type

我们要学习的第一个结构是提交类型。它提供了一个清晰的上下文，说明在这个提交中做了什么。下面你可以看到提交类型的列表以及何时使用它们:

feat：引入新功能;
fix：修正软件错误;
refactor：用于代码重构，但保留其整体功能;
chore：不影响生产代码的更新，包括工具、配置或库调整;
docs：对文档文件的补充或修改;
perf：提高性能的代码更改;
style：与代码表现形式相关的调整，如格式和空白;
test：包含或修正测试;
build：影响构建系统或外部依赖的修改;
ci：更改 CI 配置文件和脚本;
env：调整或添加 CI 过程中的配置文件，例如容器配置参数。

作用域 Scope

作用域是一个可选的结构，添加到提交类型之后，以提供额外的上下文信息，例如:

fix(ui): resolve issue with button alignment
feat(auth): implement user authentication

主体 Body

主体提供了有关提交所引入的更改的详细解释，它通常添加在主题行后面的空白行之后。

示例：

Add new functionality to handle user authentication.

This commit introduces a new module to manage user authentication. It includes
functions for user login, registration, and password recovery.

页脚用于提供与提交相关的附加信息。这可以包括诸如谁审查或批准变更之类的细节。

示例：

Signed-off-by: John <john.doe@example.com>
Reviewed-by: Anthony <anthony@example.com>

破坏性变更 Breaking Change

表明提交包含可能导致兼容性问题或需要修改相关代码的重大更改。您可以在页脚添加 BREAKING CHANGE 或在类型/作用域之后包含 ! 。

使用提交规范的提交示例

chore: add commitlint and husky
chore(eslint): enforce the use of double quotes in JSX
refactor: type refactoring
feat: add axios and data handling
feat(page/home): create next routing
chore!: drop support for Node 18

包含主题、正文和页脚的示例

feat: add function to convert colors in hexadecimal to rgba

Lorem Ipsum is simply dummy text of the printing and typesetting industry.

Lorem Ipsum has been the industry's standard dummy text ever since the 1500s.

Reviewed-by: 2
Refs: #345

参考文章

翻译自：https://dev.to/anthonyvii/be-a-better-developer-with-these-git-good-practices-2dim

SSX，一个有记忆的 ssh 客户端

Fri, 15 Dec 2023 00:50:48 +0000

需求来源

对于一个后端程序员来说，在工作中免不了要和繁杂的服务器打交道，ssh 是不可或缺的开发工具。但每次登录都需要输入密码的行为，对于认为一切皆可自动化的程序员来说，肯定是有点繁琐的（如果您是使用图形化界面的用户可忽略）。

所以我在前段时间考虑，我应该自己实现一个 ssh 客户端，它不需要拥有许多复杂的功能，只需要满足我以下这几个需求即可满足日常使用：

和 ssh 保持差不多的使用习惯
仅在第一次登录时询问我密码，后续使用无需再提供密码
可以给服务器它任意的标签，这样我就可以自由地通过IP 或者标签来登录

于是乎，近期我在业余时间就设计并编写了 ssx 这个轻量级的具有记忆的 ssh 客户端。它完美的实现了上面我所需要的功能，也已经被我愉快的应用到了日常的开发中。

使用方式

下面就简单介绍一下 ssx 的使用方式。

ssx 是通过 golang 开发的一个独立的二进制文件，安装方式就是从 release 页面下载对应平台的软件包，解压后把 ssx 二进制放到系统的任意目录下，这里我习惯放到 /usr/local/bin 目录下，如果你选择其他目录下，需要确保存放的目录添加到 $PATH 环境变量中，这样后续使用我们就不用再添加路径前缀，直接通过 ssx 命令就可以运行了。

登录服务器

使用 ssx 登录服务器的时候，基本和 ssh 使用习惯一致，下面是基本命令模式：

ssx [-s] [USER@]HOST[:PORT] [-k IDENTITY_FILE]

在这个命令中，USER 是可以省略的，如果省略则是系统当前用户名；PORT 是可以省略的，默认是 22，-k IDENTITY_FILE 代表如果是使用私钥登录，则通过 -k 来指定私钥的路径，也是可以省略的，默认是 ~/.ssh/id_rsa，当然了，前提是这个文件存在。所以最精简的登录命令就是：ssx <ip>

当首次登录，不存在可用私钥时，会通过交互方式来让用户输入密码，一旦登录成功，这个密码就会被 ssx 保存到本地的数据文件中 (默认为 ~/.ssx/db，可通过环境变量 SSX_DB_PATH 进行自定义)，下次登录时，仍然执行 ssx <ip> 即可自动登录。

注意，登录过的服务器，再次登录时，我嫌输入全部 IP 比较麻烦，所以 ssx 支持输入 IP 中的部分字符，自动搜索匹配进行登录。

为服务器打标签

当我们成功登录过一次服务器后，就可以通过 ssx list 命令来查看目前 ssx 存储的所有服务器列表。下面是一个列表示例：

# output example
# Entries (stored in ssx)
# ID | Address | Tags
#-----+----------------------+--------------------------
# 1 | root@172.23.1.84:22 | centos

ssx 会给每个服务器分配一个唯一的 ID，我们在打标签时就需要通过 ID 来指定服务器条目。

当然，既然服务器有唯一 ID，ssx 也支持通过 ID 来进行登录：ssx -i <ID>

打标签需要通过 ssx 的子命令 tag 来完成，下面是 tag 命令的模式：

ssx tag -i <ENTRY_ID> [-t TAG1 [-t TAG2 ...]] [-d TAG3 [-d TAG4 ...]]

-i 指定 list 命令输出的要操作的服务器对应的 ID 字段
-t 指定要添加的标签名，可以多次指定就可以同时添加多个标签
-d 指定要删除的标签名，同样也可以多次指定

当我们完成对服务器的打标签后，比如上面示例中的服务器，我增加了一个 centos 的标签，那么我此时就可以通过标签来进行登录了：

// -t 可省略
ssx [-t] centos

删除服务器记录

ssx 也支持删除服务器记录，命令如下：

ssx delete -i <ID>

一旦删除，ssx 不会保留该服务器的任何信息，所以下次登录时会等同于新的服务器来对待，ID 也会重新生成。

目前支持的环境变量

除了上面提到的 SSX_DB_PATH 可以指定存储数据的文件外，ssx 还支持：

SSX_CONNECT_TIMEOUT：SSH连接超时时间，默认为 10s
SSX_IMPORT_SSH_CONFIG：是否引用用户 ssh 配置，默认为空

这里我解释一下 SSX_IMPORT_SSH_CONFIG 的作用，这个环境变量不设置时，ssx 默认是不会读取用户的 ~/.ssh/config 文件的，ssx 只使用自己存储文件进行检索。如果将这个环境变量设置为非空（任意字符串），ssx 就会在初始化的时候加载用户 ssh 配置文件中存在的服务器条目，但 ssx 仅读取用于检索和登录，并不会将这些条目持久化到 ssx 的存储文件中，所以，如果 ssx IP 登录时，这个 IP 是 ~/.ssh/config 文件中已经配置过登录验证方式的服务器，ssx 匹配到就直接登录了。但 ssx list 查看时，该服务器会被显示到 found in ssh config 的表格中，这个表格中的条目是不具有 ID 属性的，以下是一个示例：

export SSX_IMPORT_SSH_CONFIG=true
ssx list
# output example
# Entries (stored in ssx)
# ID | Address | Tags
#-----+----------------------+--------------------------
# 1 | root@172.23.1.84:22 | centos
#
# Entries (found in ssh config)
# Address | Tags
# -----------------------------------+----------------------------
# git@ssh.github.com:22 | github.com

操作演示

最后通过一个演示动画来感受一下这个小可爱的功能吧。

psycopg2基于openGauss中execPramasBatch和execPreparedBatch接口测试

Fri, 04 Aug 2023 21:50:48 +0000

如果要查看 Psycopg2 不同接口之间批量操作对比测试，请访问这篇笔记

测试环境

组件	说明
客户端操作系统	Rocky Linux 8
服务端配置	2C6G, 40G HDD
CPU	Intel Xeon Processor (Icelake)
数据库	MogDB 5.0
网络	300M宽带
Python	3.6.8
Psycopg2	vimiix/openGauss-connector-python-psycopg2

注意：

由于真正的性能和服务器的配置，网络情况相关性也比较大，本测试所有的测试用例环境条件一致，只有参数作为变量，所以请不要注重数值本身，重点关注不同情况下的性能比例

本测试只取了 100/1000/10000 这个page_size，具有一定的性能趋势，但不代表一味的增大 page_size 就可以提高性能，必然存在一个性能拐点的参数值，而且不同的场景存在不同的性能拐点，要找到性能拐点仍需根据实际情况进行更多的测试。

插入 INSERT

execute_values

rows\page_size	100(default)	1000	10000
10,000	2089	349	204
50,000	10842	1801	707
100,000	21445	3625	1257

execute_params_batch

rows\page_size	100(default)	1000	10000
10,000	2243	504	312
50,000	11574	2591	1539
100,000	22552	5511	2980

execute_prepared_batch

rows\page_size	100(default)	1000	10000
10,000	2328	506	339
50,000	11307	2836	1480
100,000	22976	5920	3425

相同行数时，不同 page_size 的接口性能对比

更新 UPDATE

execute_values

用法比较饶，需要把 values 的部分单独用一个 %s 占位

rows\page_size	100(default)	1000	10000
10,000	3884	562	393
50,000	15367	3429	2601
100,000	25882	11313	5356

execute_params_batch

rows\page_size	100(default)	1000	10000
10,000	2746	810	579
50,000	13359	4478	3026
100,000	28432	8529	5923

execute_prepared_batch

rows\page_size	100(default)	1000	10000
10,000	2747	896	635
50,000	12860	6153	3626
100,000	28445	10103	10828

相同行数时，不同 page_size 的接口性能对比

结论

任何接口，在对于大批量操作时，调大 page_size 均可以得到有效的性能提升
从数据来看， execute_values 的性能不管在INSERT还是UPDATE的表现，都稍稍好于 execute_params_batch 和 execute_prepared_batch（由于测试的局限性，可能也不一定）。execute_params_batch 和 execute_prepared_batch 两个接口性能差别不大，底层走的是一套接口。
从使用上来说，execute_values 使用比较饶，如果要使用这个接口更新，写SQL的复杂度大于其他两个，比如相同的更新操作：
- execute_values： UPDATE t3 as t SET j = data.j FROM (VALUES %s) AS data (j, i) WHERE t.i = data.i
- 其他两个：UPDATE t3 SET j=$1 WHERE t3.i=$2