Reading List

Scaling Kubernetes to Thousands of CRDs

Over the past few months Crossplane has pushed the boundaries of Kubernetes with the number of Custom Resources it supports. In this post we'll explore the limitations Upbound engineers have discovered and how we've helped to overcome them. Upbound founded Crossplane to help you build cloud control planes.

https://blog.upbound.io/scaling-kubernetes-to-thousands-of-crds/

Simplify Kubernetes Resource Access Control using RBAC Impersonation

Kubernetes, like any other secure system, supports the following concepts: Authentication: Verifying and proving identities for users and groups, and service accounts Authorization: Allowing users to perform specific actions with Kubernetes resources Accounting: Storing subjects actions, typically for auditing purposes Authorization - the process of handling users' access to resources - is always a challenge, especially when access is to be controlled by either team membership or project membership.

https://docs.bitnami.com/tutorials/simplify-kubernetes-resource-access-rbac-impersonation/

深入理解 netfilter 和 iptables

Netfilter （配合 iptables）使得用户空间应用程序可以注册内核网络栈在处理数据包时应用的处理规则，实现高效的网络转发和过滤。很多常见的主机防火墙程序以及 Kubernetes 的 Service 转发都是通过 iptables 来实现的。关于 netfilter 的介绍文章大部分只描述了抽象的概念，实际上其内核代码的基本实现不算复杂，本文主要参考 Linux 内核 2.6 版本代码（早期版本较为简单），与最新的 5.x 版本在实现上可能有较大差异，但基本设计变化不大，不影响理解其原理。本文假设读者已对 TCP/IP 协议有基本了解。 netfilter 的定义是一个工作在 Linux 内核的网络数据包处理框架，为了彻底理解 netfilter 的工作方式，我们首先需要对数据包在 Linux 内核中的处理路径建立基本认识。数据包在内核中的处理路径，也就是处理网络数据包的内核代码调用链，大体上也可按 TCP/IP 模型分为多个层级，以接收一个 IPv4 的 tcp 数据包为例：在物理-网络设备层，网卡通过 DMA 将接收到的数据包写入内存中的 ring buffer，经过一系列中断和调度后，操作系统内核调用 __skb_dequeue 将数据包加入对应设备的处理队列中，并转换成 sk_buffer 类型（即 socket buffer - 将在整个内核调用栈中持续作为参数传递的基础数据结构，下文指称的数据包都可以认为是 sk_buffer），最后调用

https://waynerv.com/posts/understanding-netfilter-and-iptables/

Articles

译] 流量控制（TC）五十年：从基于缓冲队列（Queue）到基于时间戳（EDT）的演进（Google, 2018）

https://arthurchiao.art/articles-zh/

the-art-of-command-line/README-zh.md at master · jlevy/the-art-of-command-line

熟练使用命令行是一种常常被忽视，或被认为难以掌握的技能，但实际上，它会提高你作为工程师的灵活性以及生产力。本文是一份我在 Linux 上工作时，发现的一些命令行使用技巧的摘要。有些技巧非常基础，而另一些则相当复杂，甚至晦涩难懂。这篇文章并不长，但当你能够熟练掌握这里列出的所有技巧时，你就学会了很多关于命令行的东西了。这篇文章是许多作者和译者共同的成果。这里的部分内容首次出现于 Quora，但已经迁移到了 Github，并由众多高手做出了许多改进。如果你在本文中发现了错误或者存在可以改善的地方，请贡献你的一份力量。涵盖范围：这篇文章不仅能帮助刚接触命令行的新手，而且对具有经验的人也大有裨益。本文致力于做到覆盖面广（涉及所有重要的内容），具体（给出具体的最常用的例子），以及简洁（避免冗余的内容，或是可以在其他地方轻松查到的细枝末节）。在特定应用场景下，本文的内容属于基本功或者能帮助您节约大量的时间。本文主要为 Linux 所写，但在仅限 OS X 系统章节和仅限 Windows 系统章节中也包含有对应操作系统的内容。除去这两个章节外，其它的内容大部分均可在其他类 Unix 系统或 OS X，甚至 Cygwin 中得到应用。本文主要关注于交互式 Bash，但也有很多技巧可以应用于其他 shell 和 Bash 脚本当中。除去"标准的"Unix 命令，本文还包括了一些依赖于特定软件包的命令（前提是它们具有足够的价值）。注意事项：为了能在一页内展示尽量多的东西，一些具体的信息可以在引用的页面中找到。我们相信机智的你知道如何使用 Google 或者其他搜索引擎来查阅到更多的详细信息。文中部分命令需要您使用 apt-get，yum，dnf，pacman，pip 或 brew（以及其它合适的包管理器）来安装依赖的程序。遇到问题的话，请尝试使用 Explainshell 去获取相关命令、参数、管道等内容的解释。在 Bash 中，可以通过按 Tab 键实现自动补全参数，使用 ctrl-r 搜索命令行历史记录（按下按键之后，输入关键字便可以搜索，重复按下 ctrl-r 会向后查找匹配项，按下 Enter 键会执行当前匹配的命令，而按下右方向键会将匹配项放入当前行中，不会直接执行，以便做出修改）。在 Bash 中，可以按下 ctrl-w 删除你键入的最后一个单词， ctrl-u 可以删除行内光标所在位置之前的内容， alt-b 和 alt-f 可以以单词为单位移动光标， ctrl-a 可以将光标移至行首， ctrl-e 可以将光标移至行尾， ctrl-k 可以删除光标至行尾的所有内容， ctrl-l 可以清屏。键入 man readline 可以查看 Bash 中的默认快捷键。内容有很多，例如 alt-.

https://github.com/jlevy/the-art-of-command-line/blob/master/README-zh.md

Git

git 工作原理与撤销操作图解

之所以这样，是因为你的需求并不能简单地描述为「撤销」某次提交，而可能是：我在本地修改了一些文件还未提交，但我想放弃某些文件的更改。我不小心 git add 了错误的文件，现在我不想把它和其他文件一起提交了。我刚刚执行的提交添加了不该提交的文件，我想取消这次提交，但保留（或不保留）对本地文件所作的修改。我不小心在一个提交中引入了 Bug 并且还推送到了远程分支，现在想回滚到原来的状态。对于各种复杂的情形，Git 都提供了对应的方案来解决，但由于命令很多且同一命令还有很多选项，想要记住它们不是一件容易的事情。以 reset 、 checkout 为例，在添加不同选项并对不同参数执行后，就能实现 6 种不同但又很常用的效果。对于复杂的问题，我们应该尝试去了解其背后的本质。带着这种想法，我们来看看执行这些操作时究竟发生了什么，希望你在阅读本文后，能够对 Git 的撤销操作运用自如，解决大部分与撤销相关的实际问题（实际上本文还非系统地介绍了 Git 的内部对象和工作原理）。首先需要明确的是，Git 中并没有真正意义上传统文本处理软件都会提供的 undo （撤销）功能，Git 本身也不是一个文本处理软件，它是一个内容寻址文件系统，你所提交的更改都会被保存到系统中。虽然不能 undo ，但它就像时光机一样，可以将保存的文件恢复到过去的某个状态。然而，Git 同时管理着三颗不同的「树」的状态，当我们讨论「撤销」这个操作时，除了选择需要恢复到的时间点，还需要明确想更改哪几颗树。这三棵树分别是：工作区（Working Directory）暂存区（Staging Index）提交历史（Commit History）虽然我们用树来形容它们，但需要先明确的一点是，树并不代表它们真实的数据结构。「树」在这里的实际意思是「文件的集合」，而不是指特定的数据结构。在文中我们不会去深入探究它们的底层实现，而是重点了解它们的概念及相互关系。工作区即存放当前操作文件的本地文件系统目录。我们可以把它当成一个沙盒，在其中随意地添加或编辑文件，然后再将修改后的文件添加到暂存区并记录到提交历史中。 Git 可以把工作区中的文件处理、压缩成一个提交对象（稍后会解释这一概念），也能将取得的提交对象解包成文件同步到工作区中。暂存区保存着下一次执行 git commit 时将加入到提交历史中的内容。 Git 把它作为工作区与提交历史之间的中间区域，方便我们对提交内容进行组织：我们可能会在工作区同时更改多个完全不相干的文件，这时可以将它们分别放入暂存区，并在不同的提交中加入提交历史。此外暂存区还用于合并冲突时存放文件的不同版本。

https://waynerv.com/posts/git-undo-intro/

git rebase 用法详解与工作原理

以前对 git rebase -i 的用法一直是一知半解，一次在需要合并多个提交时刚好用到，一顿操作差点把提交都搞丢了，幸好后面顺利找回，因此记录一下学习 rebase 命令的过程。 git rebase 命令的文档描述是 Reapply commits on top of another base tip ，从字面上理解是「在另一个基端之上重新应用提交」，这个定义听起来有点抽象，换个角度可以理解为「将分支的基础从一个提交改成另一个提交，使其看起来就像是从另一个提交中创建了分支一样」，如下图：假设我们从 Master 的提交 A 创建了 Feature 分支进行新的功能开发，这时 A 就是 Feature 的基端。接着 Matser 新增了两个提交 B 和 C， Feature 新增了两个提交 D 和 E。现在我们出于某种原因，比如新功能的开发依赖 B、C 提交，需要将 Master 的两个新提交整合到 Feature 分支，为了保持提交历史的整洁，我们可以切换到 Feature 分支执行 rebase 操作：

https://waynerv.com/posts/git-rebase-intro/

深入理解 git cherry-pick 操作

在前面几篇讲解 Git 进阶用法的文章中，我们已经了解了 Git 的工作原理，以及 rebase， merge， checkout， reset 等多种操作的使用场景和用法，基本上在使用 Git 时你已经可以无所畏惧了，你可以自如的修改提交历史，并保证不会丢失任何更改。今天我们来补上最后一环，了解使用场景不多但却能达到奇效的 cherry-pick 命令。 Git 命令文档的描述不一定直观易懂，但绝对准确，文档对 git cherry-pick 描述是： Apply the changes introduced by some existing commits，即应用某些已有提交所引入的更改。通常我们会说 cherry-pick 是将某个（些）提交从一个分支移动到另一个分支，这种说法更加容易理解，但后面我们会解释为何文档的描述才是最准确的。假设我们有如下提交： cherry-pick 命令的用法简单明了，对需要移动的一个或多个提交执行 cherry-pick 即可，注意这里我们用字母指代实际的提交 SHA-1 ID：执行后的提交历史如下：从上面的命令解释来看， cherry-pick 实现的效果比较简单，而且和 merge、 rebase 看上去有所重合，下面我们来看看 cherry-pick 的实际使用场景。通常在一个产品的 Git 工作流中，会有至少一个发布分支和开发主分支。当发现一个 bug 时，我们需要尽快向已发布的产品提供修复补丁，同时也要将补丁整合到开发主分支中。

https://waynerv.com/posts/git-cherry-pick-intro/

Bash 脚本 set 命令教程

服务器的开发和管理离不开 Bash 脚本，掌握它需要学习大量的细节。 set 命令是 Bash 脚本的重要环节，却常常被忽视，导致脚本的安全性和可维护性出问题。本文介绍它的基本用法，让你可以更安心地使用 Bash 脚本。我们知道，Bash 执行脚本的时候，会创建一个新的 Shell。上面代码中， script.sh 是在一个新的 Shell 里面执行。这个 Shell 就是脚本的执行环境，Bash 默认给定了这个环境的各种参数。 set命令用来修改 Shell 环境的运行参数，也就是可以定制环境。一共有十几个参数可以定制，官方手册有完整清单，本文介绍其中最常用的四个。顺便提一下，如果命令行下不带任何参数，直接运行 set ，会显示所有的环境变量和 Shell 函数。执行脚本的时候，如果遇到不存在的变量，Bash 默认忽略它。 #!/usr/bin/env bash echo $a echo bar 上面代码中，$a 是一个不存在的变量。执行结果如下。可以看到， echo $a输出了一个空行，Bash 忽略了不存在的$a，然后继续执行 echo bar 。大多数情况下，这不是开发者想要的行为，遇到变量不存在，脚本应该报错，而不是一声不响地往下执行。 set -u 就用来改变这种行为。脚本在头部加上它，遇到不存在的变量就会报错，并停止执行。

http://www.ruanyifeng.com/blog/2017/11/bash-set.html

www.sobyte.net

https://www.sobyte.net/post/2022-06/k8s-reliability-list-data/

一个socket数量的问题 - _备忘录 - 博客园

最近遇到一个问题，从业务上出现ftp异常： ftp 172.**.**.** ftp: connect: Cannot assign requested address 这台服务器上的socket统计如下：可以看到，closed的值很高，ports也很高，占用了12036个端口， ss -s执行的源代码是：可以看到，ss -s 关于ipv4的输出是通过读取/proc/net/sockstat 的内容，和前面数据有些相差是因为不是严格一个时间点取的，同时，alloc是比较接近closed的，（注意ss中关于closed的算法，要获取精确值，应该关注 /proc/net/sockstat 中的alloc的值）而正常的设备大概是：可以明显看到alloc的数量相比正常设备很高，而且不是属于inuse状态。所以这个被ss列入到close状态的大多数就是alloc状态，closed被展示为： s.tcp_total - (s.tcp4_hashed+s.tcp6_hashed-s.tcp_tws), 而s.tcp_total格式化为：其实就是： TCP: inuse 81 orphan 0 tw 6 alloc 41019 mem 286 中的alloc那列，tcp_total里面就是alloc的tcp socket总数，但是inuse的又远远低于alloc状态，这个是为啥？而对应的closed这项为： printf(" TCP: %d (estab %d, closed %d, orphaned

https://www.cnblogs.com/10087622blog/p/10723265.html

一次春节大促性能压测不达标的瓶颈推演

本文示范了教科书式的在分布式应用场景下如何通过一个节点的状态来推演分析瓶颈出在上下游的哪个环节上。某客户通过PTS（一个打压力工具）来压选号业务(HTTP服务在9108端口上），一个HTTP请求对应一次select seq-id 和一次insert PTS端看到RT900ms+，QPS大概5万（期望20万），数据库代理服务 rt 5ms，QPS 10万+ pts发起压力 -> 5个eip -> slb -> app(300个容器运行tomcat监听9108端口上） -> slb -> 数据库代理服务集群 -> RDS集群性能不达标，怀疑数据库代理服务或者RDS性能不行，作为数据库需要自证清白，所以从RDS和数据库代理服务开始分析问题在哪里。略过一系列在数据库代理服务、RDS上分析数据和监控图表都证明数据库代理服务和RDS没问题的过程。在明确给出证据数据库代理服务和RDS都没问题后还是要解决问题，所以只能进一步帮助前面的app来分析为什么性能不达标。数据库代理服务每个HTTP请求的响应时间都控制在15ms(一个前端HTTP请求对应一个select seq-id，一个 select readonly, 一个insert，这个响应时间符合预期）。一个连接每秒才收到20 tps（因为压力不够，压力加大的话这个单连接tps还可以增加）， 20*3000 = 6万，跟压测看到基本一致 300个容器，每个容器 10个连接到数据库代理服务如果300个容器上的并发压力不够的话就没法将3000个连接跑满，所以看到的QPS是5万。从300个容器可以计算得到这个集群能支持的tps： 300*10（10个连接）* 1000/15(每秒钟每个连接能处理的请求数）=20万个tps （关键分析能力）也就是说通过单QPS 15ms，我们计算可得整个后端的吞吐能力在20万QPS。所以目前问题不在后端，而是压力没有打到后端就出现瓶颈了。 9108服务的每个HTTP response差不多都是15ms（这个响应时间基本符合预期

https://plantegg.github.io/2020/11/23/%E4%B8%80%E6%AC%A1%E6%98%A5%E8%8A%82%E5%A4%A7%E4%BF%83%E6%80%A7%E8%83%BD%E5%8E%8B%E6%B5%8B%E4%B8%8D%E8%BE%BE%E6%A0%87%E7%9A%84%E7%93%B6%E9%A2%88%E6%8E%A8%E6%BC%94/

blog.cloudflare.com

https://blog.cloudflare.com/the-complete-guide-to-golang-net-http-timeouts/

Linux source code (v6.2.2) - Bootlin

Elixir Cross Referencer - Explore source code in your browser - Particularly useful for the Linux kernel and other low-level projects in C/C++ (bootloaders, C libraries...)

https://elixir.bootlin.com/linux/latest/source