摘要

K8S 生产集群的 worker 节点在 NPD（Node Problem Detector）Pod 被重建时，出现 CPU sys% 飙升、load 暴涨、同节点其他 Pod 延迟明显变大的现象。经过完整排查，根因定位为：NPD 的 memory limit 配置过小（200Mi），导致容器频繁触发 memcg OOM；OOM 后 containerd 通过 cleanupAfterDeadShim 路径调用 runc delete 清理容器，而 runc 1.1.12 中存在两处错误丢弃缺陷以及 RemovePaths 重试窗口过短的问题，致使每次容器退出后其 cgroup 目录均未被正确清理；经过约一个月的累积，单个 NPD Pod 下残留了 8147 个子 cgroup 目录；当该 Pod 被删除重建时，kubelet 的 PodContainerManager.Destroy 对全部残留子 cgroup 进行递归遍历和 rmdir 操作，在 cgroup v1 的全局锁 cgroup_mutex 上形成严重争抢，最终导致节点 sys% 飙高并波及同节点所有 Pod。本文完整记录从现象到根因的排查过程，并结合源码分析给出修复方案。

1. 引言

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

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

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

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

为什么要做code review

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

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

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

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

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

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

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

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

前言

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

对象引用

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

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

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

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

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

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

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

需求来源

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

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

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

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

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

测试环境

注意：

1. 由于真正的性能和服务器的配置，网络情况相关性也比较大，本测试所有的测试用例环境条件一致，只有参数作为变量，所以请不要注重数值本身，重点关注不同情况下的性能比例
2. 本测试只取了 100/1000/10000 这个page_size，具有一定的性能趋势，但不代表一味的增大 page_size 就可以提高性能，必然存在一个性能拐点的参数值，而且不同的场景存在不同的性能拐点，要找到性能拐点仍需根据实际情况进行更多的测试。

测试版本

本测试基于 openGauss 版本的 psycopg2 驱动

import psycopg2 as pg
>>> pg.__libpq_version__
90204
>>> pg.__version__
'2.8.6 (dt dec pq3 ext)'

测试环境

现有的工具方案

• gvm: https://github.com/moovweb/gvm
• g: https://github.com/voidint/g

我的方案

优点：

• 原生：基于 go 语言本身支持多版本的能力实现，可以下载任何官方发布的版本
• 简单：shell 函数实现，直接集成到 bashrc 或 zshrc 中即可使用，无需额外配置
• 可定制化：代码简单可根据自身需求定制

基础理论

CAP理论

一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。这被称为CAP理论，已经被证实。

• 一致性（Consistency） ：在分布式系统中所有的数据备份，在同一时刻都保持一致状态，如无法保证状态一致，直接返回错误。
• 可用性（Availability）：在集群中一部分节点故障，也能保证客户端访问系统并得到正确响应，允许一定时间内数据状态不一致。
• 分区容错性（Partition tolerance）：分布式系统在遇到任何网络分区故障时，仍然能保证对外提供满足一致性和可用性的服务，除非整个网络环境都发生故障。

假设服务器目前有多个盘，vdb1这块分区盘专门用于数据库程序的数据目录，我们就用 vdb1 这个盘来模拟只读故障场景。

1. 卸载指定盘

umount /dev/vdb1

想要如期卸载掉，需要确保该盘上没有被正在运行进程依赖，如果有运行中的进程依赖这个盘，会报如下报 target is busy 的错误：

umount: /opt: target is busy.

遇到该错误时，可以通过lsof [mountpoint] 命令来查看有哪些进程依赖这块盘，kill 掉相应的进程后重新卸载。

前置声明

由于 openGauss 数据库本身也开源不久，所以周边基础设施也正处于遍地开花的阶段，所以本文不保证长期的时效性，仅针对现阶段的问题，提出一种解决方案。

openGauss 介绍

按照官网的介绍，openGauss 是一款高性能，高安全，高可靠的开源关系型数据库管理系统，采用木兰宽松许可证v2发行。openGauss内核早期源自开源数据库PostgreSQL，融合了华为在数据库领域多年的内核经验，在架构、事务、存储引擎、优化器及ARM架构上进行了适配与优化。

openGauss 在2020年6月30日开放源代码，代码托管在 gitee 上。

目前我所在公司也主要是做数据库方面的事情，且也基于 openGauss 内核研发了一款商业版的数据库 MogDB，感兴趣的也可以去了解一下。

Goroutine

C#、Lua、Python 的用户可能会发现 Go 的 goroutine 和协程之间有很多相似之处，没错，从命名上也可以看出二者具有相似性。

但二者之间也有些区别：

• goroutine 隐含了并行的特性，一切交给 go 的 runtime 来实现调度，而协程需要应用自己来编写并行代码
• goroutine 通过信道（Channel）进行通信；协程通过 yield 和 next操作进行通信

一般来说，goroutine 比协程更强大。而且，我们可以很容易地将协程的逻辑移植到 goroutine 来获得更好的并行效果。

本质上是通过调用 windows 的一个 API —— LogonUserW ，来实现对于用户密码的校验。

仅适用于在本地校验，不支持远程连接校验

用一个示例代码来进行说明，下面是目录结构中，main.go 是程序入口文件，auth 包中，我们仅实现 windows 系统的校验代码，其他平台不属于本文介绍内容，就直接返回 nil 即可。

beanstalkd 是一个简单快速的分布式工作队列系统，协议基于 ASCII 编码运行在 tcp 上。其最初设计目的是通过后台异步执行耗时任务方式降低高容量 Web 应用的页面延时。而其简单、轻量、易用等特点，和对任务优先级、延时/超时重发等控制，以及众多语言版本的客户端的良好支持，使其可以很好的在各种需要队列系统的场景中应用。

Beanstalk 的应用场景主要有：

• 消息异步处理（消息队列的基本需求）
• 消息延迟处理，实现循环队列

原文链接：https://martinfowler.com/articles/richardsonMaturityModel.html

迈向 REST 的荣耀之巅

Leonard Richardson 提出的一个模型，将实现 REST 方法的主要元素分解为三个步骤，分别包括：资源（Resources）、HTTP 动词(HTTP Verbs，如GET、POST等)和超媒体控制（Hypermedia Controls）。

在Rest In Practice一书中，解释了如何使用 Restful Web Service 来处理企业面临的许多集成问题。本书的核心观点是，Web 就是一个大规模可扩展的分布式系统存在、并可以很好的工作的证明，而我们可以根据这一观点更容易地构建集成系统。