容器 CPU 和 Memory 限制行为简述
这篇是给之前没啥容器经验的选手准备的一篇文章，主要是讲一下容器的 CPU 和 Memory 限制行为。 CPU 限制首先 Mac 或者是 Windows 选手在使用 Docker Desktop 的时候，会设置 Docker Desktop 的 CPU 限制，默认是 1，也就是说 Docker Desktop 只能使用 1 个 CPU。这是因为 Docker Desktop 裹了一层虚拟机（Windows 下应该是 WSL2/Hyper-V，Mac 下可能是 QEMU）。这相当于我们在一个特定 CPU 数量的宿主机中跑 Docker 首先提到 CPU 限制，本质上是限制进程的 CPU 使用的时间片，在 Linux 下，进程存在三种调度优先级 SCHED_NORMAL SCHED_FIFO SCHED_RR 1 用的是 Linux 中 CFS 调度器，而常见普通进程都是 SCHED_NORMAL 。OK 前提知识带过 说回容器中的 CPU 限制，目前主流语境下，容器特指以 Docker 为代表的一系列的基于 Linux 中 CGroup 和 Namespace...
Leetcode Weekly Contest 287 题解
好久没打周赛了，打了一次周赛，简单的写个题解 2224. Minimum Number of Operations to Convert Time题面： 1234567You are given two strings current and correct representing two 24-hour times.24-hour times are formatted as "HH:MM", where HH is between 00 and 23, and MM is between 00 and 59. The earliest 24-hour time is 00:00, and the latest is 23:59.In one operation you can increase the time current by 1, 5, 15, or 60 minutes. You can perform this operation any number of times.Return the minimum number of...
简单聊聊在 Linux 内核中的网络质量监控
这可能是2021年最后一篇文章（农历年），也可能是2022年第一篇文章，不过这完全取决于我什么时候写完。这次来简单聊聊 Linux 中的网络监控 开篇这篇文章，既是一篇水文，又不是一篇水文。不过还是新手向的一个文章。这篇文章实际上在我的草稿箱里呆了一年多的时间了，灵感最初源自我在阿里的一些工作（某种意义上算是国内领先的（但也是比较小众的工作（XD 随着技术的发展，大家对于服务的稳定性要求越来越高，而保证服务质量的前提就是有着合格的监控的覆盖面（阿里对于服务稳定性的要求叫做 “1-5-10” 即，一分钟发现，五分钟处理，十分钟自愈，而这样一个对于稳定性的要求没有足够的覆盖面的监控的话，那么一切等于圈圈）。而在这其中，网络质量的监控是重中之重 在讨论网络质量的监控之前，我们需要来明确网络质量这个定义的覆盖范围。 网络链路上的异常情况 服务端网络的处理能力 在明确这样的覆盖范围后，我们可以来思考什么样的指标代表着网络质量的降低。（注：本文主要分析 TCP 及 over TCP...
简单聊聊容器中的 UID 中的一点小坑
今天不太舒服，在家请假了一天。突然想起最近因为一些小问题，看了下关于容器中 UID 的东西。所以简单来聊聊这方面的东西。算个新手向的文章 开篇最近帮 FrostMing 把他的 tokei-pie-cooker 部署到我的 K8S 上做成一个 SaaS 服务。Frost 最开始给我了一个镜像地址。然后我啪的一下复制粘贴了一个 Deployment 出来 123456789101112131415161718192021222324252627282930313233apiVersion: apps/v1kind: Deploymentmetadata: name: tokei-pie namespace: tokei-pie labels: app: tokei-piespec: replicas: 12 selector: matchLabels: app: tokei-pie template: metadata: labels: app: tokei-pie spec: ...
聊聊 sk_buff 中一个冷门字段: nohdr
今天遇到一个很有意思的问题，“nohdr 字段到底有什么用”，在这里写个水文简单记录一下 正文前情提要首先来说，不管介绍再冷门的字段，既然涉及到 SKBUFF ，那么就得先来对 sk_buff 做个简单的介绍 简而言之，sk_buff 是 Linux 网络子系统的核心数据结构，从链路层到我们最终对数据包的操作，背后都离不开 sk_buff sk_buff 要完全讲解基本就相当于把 Linux 网络系统完全讲解了，所以讲完是不可能讲完的，这辈子都不可能的！ 简单聊几个关键，可能会帮助大家理解我们本文提到的冷门字段 nohdr 的关键字段吧 首先来讲，最重要的三个字段：data ，mac 和 nh ，分别代表着当前 sk_buff 的数据区的起始地址，L2 header 的起始地址，L3 Header 的起始地址。用一个图方便大家理解 看了图的同学可能会有点明白了，实际上在内核里，也是一层一层的通过指针偏移，不断的添加新的 header 来处理网络请求。和我们直觉相符。可能有同学会问，我既然知道 L3 Header 的起始地址，IP 之类的 L3 协议的 header...
关于 Node.js 中 execSync 的一点问题
很久没写水文了，昨天帮人查了一个 Node.js 中 execSync 这个函数特殊行为的问题，很有趣，所以大概记录下来水一篇文章 背景首先老哥给了一张截图 首先基本问题可以抽象为在 Node.js 中利用 execSync 这个函数执行 ps -Af | grep -q -E -c "\\-\\-user-data-dir=\\.+App" 这样一条命令的时候，Node.js 时不时会报错。具体堆栈大概为 12345678910Uncaught Error: Command failed: ps -Af | grep -q -E -c "\-\-user-data-dir=\.+App" at checkExecSyncError (child_process.js:616:11) at Object.execSync (child_process.js:652:15) { status: 1, signal: null, output: [ null, <Buffer >,...
关于我自己被性侵经历的访谈记录
这篇文章是我 2020 年 12 月接受华中师范大学关于儿童性侵的采访所产生采访稿。在这次采访中，我完整的复盘了在我12岁那年发生在我身上的强奸事件。在这次采访中，我完整回顾了当时我和我家庭的一些反应，也表达了我一些关于性侵这件事的看法。我希望每个人都能平安顺利的过完一生，但是如果有不好的事情发生的时候，我希望这篇文章能帮到你。Everything is gonna be...
利用动态 tracing 技术来 trace 内核中的网络请求
这周帮朋友用 eBPF/SystemTap 这样的动态 tracing 工具做了一些很有趣的功能。这篇文章算是一个总结 开篇实际上这周的一些想法，最开始是实际上来源于某天一个朋友问我的一个问题 我们能不能监控机器上哪些进程在发出 ICMP 请求？需要拿到 PID，ICMP 包出口地址，目标地址，进程启动命令 很有趣的问题。实际上首先拿到这个问题时候，我们第一反应肯定是 “让机器上的进程在发 ICMP 包的时候”直接往一个地方写日志不就好了，emmmm，用一个 meme 镇楼吧 嗯，可能大家都知道我想说什么了，我们这种场景实际上只能选择旁路，无侵入的方式去做。 那么涉及到包的旁路的 trace，大家第一反应肯定是 tcpdump 去抓包。但是在我们今天的问题下，tcpdump 只能拿到包信息， 但是拿不到具体的 PID，启动命令等信息。 所以我们可能需要用另外一些方式去实现我们的需求 在需求最开始之初，我们还可能的选择的方式有这样一些 走 /proc/net/tcp 去拿具体的 socket 的 inode 信息，然后反查 pid 关联 eBPF + kprobe...
当我们在聊 CI/CD 时，我们在聊什么？
本文实际上是在群内第二次分享的内容。这次其实想来聊聊，关于 CI/CD 的一些破事和演进过程中我们所需要遇到的一些问题，当然本文中是一个偏新手向的文章和一点点爆论，随便看看就好。 开宗明义，定义先行在我们谈论一个事物之前，我们需要对这个事物给出一个定义，那我们先来看一下我们今天要聊的 CI 与 CD 的定义。 首先，CI 指 Continuous Integration ，在中文语境中的表述是持续集成。而 CD 在常见语境下可能是两种意思：Continuous Delivery 或 Continuous Deployment，与之对应的表述是持续交付/持续部署。这里借用一下 Brent Laster 在 What is CI/CD?1 中给出的定义 Continuous integration (CI) is the process of automatically detecting, pulling, building, and (in most cases) doing unit testing as source code is changed for a...
继续爆论容器中的一号进程
上周的文章聊了关于容器中的一号进程的一些概况后，在我师父某川(可以去 GitHub 找他玩，jschwinger23) 的指导与配合下，我们一起对目前主流的被广泛使用的两个容器中一号进程的实现 dumb-init 和 tini 做了一番探究，继续写个水文来爆论一番。 正文我们为什么需要一个一号进程，我们希望的一号进程需要承担怎样的职责？在继续聊关于 dumb-init 和 tini 的相关爆论之前，我们需要来 review 一个问题。我们为什么需要一个一号进程？以及我们所选择的一号进程需要承担怎么样的职责 其实我们在容器场景下需要一号进程托管在前面实际上有两种主要的场景， 对于容器内 Graceful Upgrade 二进制这种场景，主流的一种做法之一是 fork 一个新的进程，exec 新的二进制文件，新进程处理新链接，老进程处理老链接。（Nginx 就采用这种方案） 没有正确的处理信号转发以及进程回收的情况 一些如同 calico-node...
