容器 = 一个普通进程 + namespace（视图隔离）+ cgroup（资源限制）+ 文件系统隔离
                        ^ 你能看到什么      ^ 你能用多少      ^ 你的根目录在哪

对比虚拟机：
  虚拟机  -> 完整的内核 + 硬件模拟，隔离彻底但开销大（几百 MB 内存，秒级启动）
  容器    -> 【共享宿主机内核】，隔离靠内核特性，开销近零（几 MB，毫秒级启动）

# 验证：容器里的进程在宿主机上就是普通进程
docker run -d --name test nginx
docker inspect -f '{{.State.Pid}}' test
# 12345

# 宿主机上直接能看到
ps -ef | grep 12345
# root  12345  12300  0 14:00 ?  00:00:00 nginx: master process nginx -g daemon off;
#       ^^^^^ 就是一个普通进程，没有任何特殊之处

# 看它的 namespace
ls -l /proc/12345/ns/
# lrwxrwxrwx 1 root root 0 Aug 6 14:00 cgroup -> 'cgroup:[4026531835]'
# lrwxrwxrwx 1 root root 0 Aug 6 14:00 ipc -> 'ipc:[4026532467]'
# lrwxrwxrwx 1 root root 0 Aug 6 14:00 mnt -> 'mnt:[4026532465]'
# lrwxrwxrwx 1 root root 0 Aug 6 14:00 net -> 'net:[4026532470]'
# lrwxrwxrwx 1 root root 0 Aug 6 14:00 pid -> 'pid:[4026532468]'
# lrwxrwxrwx 1 root root 0 Aug 6 14:00 user -> 'user:[4026531837]'
# lrwxrwxrwx 1 root root 0 Aug 6 14:00 uts -> 'uts:[4026532466]'
#                                              ^^^^^^^^^^^^^^^^^^ inode 号

# 对比容器和宿主机的 namespace
readlink /proc/1/ns/net           # 宿主机 init
# net:[4026531840]
readlink /proc/12345/ns/net       # 容器
# net:[4026532470]                <- 不同，说明网络被隔离了

readlink /proc/1/ns/user
readlink /proc/12345/ns/user
# 两个都是 user:[4026531837]      <- 相同！说明【没有】开 user namespace
#                                   这就是第 3 篇讲的「容器里的 uid 就是宿主机的 uid」

// ① clone：创建新进程并同时进入新的 namespace
pid_t pid = clone(child_func, stack, CLONE_NEWPID | CLONE_NEWNET | SIGCHLD, arg);

// ② unshare：让【当前进程】脱离原 namespace，进入新的
unshare(CLONE_NEWNS | CLONE_NEWUTS);

// ③ setns：加入一个【已存在】的 namespace（通过 /proc/<pid>/ns/xxx 的 fd）
int fd = open("/proc/12345/ns/net", O_RDONLY);
setns(fd, CLONE_NEWNET);

unshare    # 对应 unshare()，创建新 namespace 并执行命令
nsenter    # 对应 setns()，进入已有进程的 namespace
lsns       # 列出系统上所有 namespace

# 在新的 UTS namespace 里改主机名
sudo unshare --uts bash
hostname
# myhost
hostname container-test          # 改主机名
hostname
# container-test

exit                             # 退出
hostname
# myhost                         <- 宿主机完全不受影响

sudo unshare --pid --fork --mount-proc bash
#                    ^^^^^^ 必须加：否则 ps 仍读宿主机的 /proc

ps -ef
# UID    PID  PPID  C STIME TTY  TIME     CMD
# root     1     0  0 14:10 pts/0 00:00:00 bash      <- bash 成了 PID 1
# root     9     1  0 14:10 pts/0 00:00:00 ps
#          ^ 只能看到自己 namespace 里的进程

echo $$
# 1

① 层级性：父 namespace 能看到子 namespace 的所有进程（但 PID 不同），
          子 namespace 看不到父的
          -> 所以宿主机能看到并管理所有容器进程

② PID 1 的特殊性（第 8 篇 §2.2 讲过）：
   - 不执行信号的默认动作 -> 没注册 handler 时 SIGTERM 被丢弃
   - 负责收养孤儿进程并 wait -> 应用通常不实现，导致僵尸堆积
   - PID 1 退出 -> 整个 namespace 里的所有进程被 SIGKILL

# 同一个进程在不同 namespace 里有不同的 PID
# 容器内
docker exec test ps -ef | head -2
# UID  PID  PPID  CMD
# root   1     0  nginx: master process

# 宿主机上
docker inspect -f '{{.State.Pid}}' test
# 12345                        <- 同一个进程，宿主机视角是 12345，容器内是 1

# 创建一个网络 namespace
sudo ip netns add myns
sudo ip netns list
# myns

# 在里面执行命令
sudo ip netns exec myns ip addr
# 1: lo: <LOOPBACK> mtu 65536 state DOWN
#    ^ 只有一个 lo，而且还是 DOWN 状态 —— 完全干净的网络栈

sudo ip netns exec myns ip link set lo up

# ① 创建一对虚拟网卡（像一根虚拟网线的两端）
sudo ip link add veth-host type veth peer name veth-ns

# ② 把一端放进 namespace
sudo ip link set veth-ns netns myns

# ③ 配置宿主机这一端
sudo ip addr add 10.200.1.1/24 dev veth-host
sudo ip link set veth-host up

# ④ 配置 namespace 那一端
sudo ip netns exec myns ip addr add 10.200.1.2/24 dev veth-ns
sudo ip netns exec myns ip link set veth-ns up
sudo ip netns exec myns ip route add default via 10.200.1.1

# ⑤ 测试连通
ping -c 2 10.200.1.2
sudo ip netns exec myns ping -c 2 10.200.1.1

# ⑥ 让 namespace 能访问外网（NAT，第 13 篇讲的 iptables）
sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A POSTROUTING -s 10.200.1.0/24 -o eth0 -j MASQUERADE
sudo ip netns exec myns ping -c 2 8.8.8.8

# 在宿主机上看容器的 veth
ip link | grep veth
# 5: veth1a2b3c4@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> ... master docker0
#                                                            ^^^^^^^^^^^^^ 挂在 docker0 网桥上

# 清理
sudo ip netns del myns

sudo unshare --mount bash

# 在这里挂载，宿主机看不到
mount -t tmpfs tmpfs /mnt
df -h /mnt
# tmpfs  7.8G  0  7.8G  0% /mnt

exit
df -h /mnt
# 宿主机的 /mnt 没有这个挂载    ✅

# 简化演示：用 chroot（真实容器用 pivot_root，更安全）
sudo unshare --mount --pid --fork chroot /path/to/rootfs /bin/bash

# 拿到容器的 PID
PID=$(docker inspect -f '{{.State.Pid}}' mycontainer)

# 进入容器的【网络】namespace，用【宿主机的】ss 命令
sudo nsenter -t $PID -n ss -tlnp
#                    ^^ 只进 net namespace
# State  Recv-Q Send-Q Local Address:Port
# LISTEN 0      511          0.0.0.0:80

# 在容器的网络里抓包（容器里没有 tcpdump 也没关系）
sudo nsenter -t $PID -n tcpdump -i eth0 -nn port 80

# 进入容器的网络里 curl
sudo nsenter -t $PID -n curl -s localhost/health

# 全部 namespace 都进（等效 docker exec，但用宿主机的 shell）
sudo nsenter -t $PID -a /bin/bash

# K8s 里的用法
POD_PID=$(crictl inspect $(crictl ps -q --name myapp) | jq -r '.info.pid')
sudo nsenter -t $POD_PID -n ss -tanp

# 或者用调试容器（K8s 1.23+，更方便）
kubectl debug -it mypod --image=nicolaka/netshoot --target=myapp

不开 user namespace（默认）：
  容器内 uid 0  ==  宿主机 uid 0（真正的 root）
  -> 容器逃逸后直接是宿主机 root

开启 user namespace：
  容器内 uid 0  ->  宿主机 uid 100000（无特权用户）
  -> 即使逃逸，也只是一个普通用户

# 验证当前是否开启
readlink /proc/1/ns/user /proc/$(docker inspect -f '{{.State.Pid}}' test)/ns/user
# user:[4026531837]
# user:[4026531837]            <- 相同 = 【没开】user namespace

# 手动体验
unshare --user --map-root-user bash
id
# uid=0(root) gid=0(root)      <- 容器内看是 root
# 但在宿主机上看这个进程仍是原来的普通用户

cat /proc/self/uid_map
#          0       1000          1
#          ^ ns内  ^ 宿主机   ^ 范围
#   含义：namespace 里的 uid 0 映射到宿主机的 uid 1000

① 挂载卷的权限会很麻烦 —— 宿主机上的文件属主需要是映射后的 uid
② 部分功能不兼容（某些 --privileged 场景、部分存储驱动）
③ 镜像层需要 chown，占用额外磁盘空间
④ 历史包袱：早期实现不成熟

# 开启（Docker）
# /etc/docker/daemon.json
{
  "userns-remap": "default"
}
systemctl restart docker

# 之后宿主机上会有映射用户
cat /etc/subuid
# dockremap:100000:65536       <- 容器 uid 0~65535 映射到宿主机 100000~165535

# K8s 的标准安全配置（第 3 篇提过）
securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  runAsGroup: 1000
  fsGroup: 1000
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

lsns
#         NS TYPE   NPROCS   PID USER   COMMAND
# 4026531835 cgroup    234     1 root   /sbin/init
# 4026531837 user      234     1 root   /sbin/init
# 4026532465 mnt         3 12345 root   nginx: master process
# 4026532470 net         3 12345 root   nginx: master process

lsns -t net              # 只看网络 namespace
lsns -p 12345            # 看某个进程属于哪些 namespace

cgroup 提供三件事：
  ① 限制（limit）    —— 最多能用多少
  ② 统计（accounting）—— 实际用了多少
  ③ 控制（control）  —— 冻结、恢复、批量杀死

# 判断当前系统用的是哪个版本
stat -fc %T /sys/fs/cgroup/
# cgroup2fs       <- v2（统一层级）
# tmpfs           <- v1（多层级）

mount | grep cgroup

cat /sys/fs/cgroup/cpu.pressure
# some avg10=12.34 avg60=8.21 avg300=3.45 total=892340123
# ^^^^ 至少【一个】任务因为等 CPU 而停滞的时间占比

cat /sys/fs/cgroup/memory.pressure
# some avg10=0.00 avg60=0.00 avg300=0.00 total=0
# full avg10=0.00 avg60=0.00 avg300=0.00 total=0
# ^^^^ 【所有】任务都在等的时间占比 —— full > 0 就是严重问题

ls /sys/fs/cgroup/
# cgroup.controllers      当前可用的控制器
# cgroup.procs            属于这个 cgroup 的进程 PID 列表
# cgroup.subtree_control  【授权给子 cgroup 的控制器】
# cpu.max                 CPU 限制
# cpu.stat                CPU 统计
# cpu.pressure            PSI
# memory.max              内存上限
# memory.current          当前使用
# memory.stat             详细统计
# memory.events           事件计数（含 oom_kill）
# io.max                  IO 限制
# io.stat                 IO 统计
# pids.max                进程数上限

cat /sys/fs/cgroup/cgroup.controllers
# cpuset cpu io memory hugetlb pids rdma misc

# ① 创建一个 cgroup（就是建目录，内核自动生成控制文件）
sudo mkdir /sys/fs/cgroup/mytest
ls /sys/fs/cgroup/mytest/
# 自动出现了一堆控制文件

# ② 【关键】父 cgroup 必须先授权控制器给子级
echo "+cpu +memory +io +pids" | sudo tee /sys/fs/cgroup/cgroup.subtree_control
cat /sys/fs/cgroup/mytest/cgroup.controllers
# cpu io memory pids            <- 现在子 cgroup 才能用这些控制器

# ③ CPU 限制：每 100ms 周期内最多用 50ms = 0.5 核
echo "50000 100000" | sudo tee /sys/fs/cgroup/mytest/cpu.max
#      ^^^^^ quota  ^^^^^^ period（微秒）
# 写 "max 100000" 表示不限制

# ④ 内存限制：512MB
echo "536870912" | sudo tee /sys/fs/cgroup/mytest/memory.max
# 软限制（超过后积极回收但不 OOM）
echo "402653184" | sudo tee /sys/fs/cgroup/mytest/memory.high

# ⑤ 进程数限制（防 fork 炸弹）
echo "100" | sudo tee /sys/fs/cgroup/mytest/pids.max

# ⑥ IO 限制（需要设备号）
lsblk -d -o NAME,MAJ:MIN
# nvme0n1  259:0
echo "259:0 rbps=10485760 wbps=10485760" | sudo tee /sys/fs/cgroup/mytest/io.max
#              ^^^^ 读 10MB/s      ^^^^ 写 10MB/s

# ⑦ 把进程加进去
echo $$ | sudo tee /sys/fs/cgroup/mytest/cgroup.procs
# 之后这个 shell 及其所有子进程都受限制

# ⑧ 验证 CPU 限制
yes > /dev/null &
top -bn2 | grep yes | tail -1
# 12345 root  20 0 ... 50.0  0.0  0:05.23 yes
#                       ^^^^ 正好 50%，限制生效

cat /sys/fs/cgroup/mytest/cpu.stat
# usage_usec 5234012
# nr_periods 234
# nr_throttled 198          <- 被限流了 198 次
# throttled_usec 8923401    <- 累计限流时间

# ⑨ 验证内存限制
cat /sys/fs/cgroup/mytest/memory.current
cat /sys/fs/cgroup/mytest/memory.events
# low 0
# high 234
# max 12
# oom 3
# oom_kill 3                <- 发生过 3 次 OOM kill

# ⑩ 清理
sudo rmdir /sys/fs/cgroup/mytest       # 必须先把进程移出去

# 方式一：cpu.max —— 硬性配额（hard limit）
echo "200000 100000" > cpu.max        # 最多 2 核，【即使 CPU 空闲也不给更多】
# 对应 K8s 的 resources.limits.cpu: "2"

# 方式二：cpu.weight —— 相对权重（soft，仅在争抢时生效）
echo "200" > cpu.weight               # 默认 100，范围 1~10000
# 对应 K8s 的 resources.requests.cpu

设了 limits.cpu = 1 的容器，即使宿主机 CPU 空闲，也只能用 1 核
-> 突发流量时无法借用空闲 CPU，延迟飙升（nr_throttled 暴涨）

设了 requests.cpu = 1 但不设 limits
-> 平时保证 1 核，空闲时可以用更多，突发流量能扛住
-> 但可能影响同机的其他容器

# 临时启动一个受限的进程
systemd-run --scope -p CPUQuota=50% -p MemoryMax=512M -p IOReadBandwidthMax="/dev/nvme0n1 10M" \
    stress-ng --cpu 4 --timeout 30

# 给已有服务加限制（第 14 篇的 drop-in）
systemctl set-property myapp.service CPUQuota=200% MemoryMax=4G
# 立即生效并持久化到 /etc/systemd/system.control/

# unit 文件里配置（推荐）
[Service]
CPUQuota=400%                 # = 4 核
CPUWeight=200                 # 相对权重
MemoryMax=4G                  # 硬限制
MemoryHigh=3G                 # 软限制，超过后积极回收
IOWeight=100
IOReadBandwidthMax=/dev/nvme0n1 100M
TasksMax=4096                 # 进程/线程数上限

# 查看服务的实际资源占用（按 cgroup 聚合）
systemd-cgtop
# Control Group          Tasks   %CPU   Memory  Input/s Output/s
# /                        423   28.3     8.2G        -        -
# system.slice             198   22.1     6.1G     1.2M    45.3M
# system.slice/mysql       124   18.4     4.2G   890.0K    42.1M

systemd-cgls                          # cgroup 树
systemctl show myapp -p CPUQuotaPerSecUSec,MemoryMax

-.slice                      根
+-- system.slice             所有系统服务
|   +-- mysql.service
|   +-- nginx.service
+-- user.slice               所有用户会话
|   +-- user-1000.slice
+-- machine.slice            虚拟机和容器

# 创建自定义 slice，把批处理任务都放进去统一限制
cat > /etc/systemd/system/batch.slice <<'EOF'
[Unit]
Description=Batch jobs slice

[Slice]
CPUQuota=200%
CPUWeight=50                  # 权重低，争抢时让给在线服务
MemoryMax=8G
IOWeight=10                   # IO 优先级低
EOF

systemctl daemon-reload

# 让服务归属这个 slice
[Service]
Slice=batch.slice
Nice=19
IOSchedulingClass=idle

#!/usr/bin/env bash
# minicontainer.sh —— 用 unshare + cgroup 实现的极简容器
set -euo pipefail

ROOTFS="${ROOTFS:-/tmp/minicontainer-rootfs}"
CG="/sys/fs/cgroup/minicontainer"
NAME="mini-$$"

# ---------- ① 准备根文件系统 ----------
prepare_rootfs() {
    [[ -d "$ROOTFS/bin" ]] && return
    echo "准备 rootfs..."
    mkdir -p "$ROOTFS"
    # 用 docker 导出一个现成的最小 rootfs
    docker create --name "$NAME-export" alpine:latest >/dev/null
    docker export "$NAME-export" | tar -x -C "$ROOTFS"
    docker rm "$NAME-export" >/dev/null
}

# ---------- ② 创建 cgroup 限制 ----------
setup_cgroup() {
    echo "+cpu +memory +pids" > /sys/fs/cgroup/cgroup.subtree_control 2>/dev/null || true
    mkdir -p "$CG"
    echo "50000 100000" > "$CG/cpu.max"       # 0.5 核
    echo "268435456"    > "$CG/memory.max"    # 256MB
    echo "64"           > "$CG/pids.max"      # 最多 64 个进程
}

# ---------- ③ 在容器里执行的初始化 ----------
container_init() {
    # 把自己加进 cgroup（此时已经在新 namespace 里）
    echo $$ > "$CG/cgroup.procs"

    hostname minicontainer                   # UTS namespace 生效

    # 挂载必要的伪文件系统（MNT namespace 生效）
    mount -t proc  proc  "$ROOTFS/proc"
    mount -t sysfs sys   "$ROOTFS/sys"  2>/dev/null || true
    mount -t tmpfs tmpfs "$ROOTFS/tmp"

    # 切换根目录并执行 shell
    exec chroot "$ROOTFS" /bin/sh
}

# ---------- 主流程 ----------
main() {
    [[ $EUID -eq 0 ]] || { echo "需要 root"; exit 1; }

    prepare_rootfs
    setup_cgroup
    export ROOTFS CG
    export -f container_init

    echo "启动容器（CPU 0.5 核 / 内存 256MB / 最多 64 进程）"
    # unshare 创建 5 种 namespace，然后执行初始化
    unshare --pid --mount --uts --ipc --net --fork \
        bash -c 'container_init'

    # 清理
    umount "$ROOTFS/proc" "$ROOTFS/tmp" 2>/dev/null || true
    rmdir "$CG" 2>/dev/null || true
    echo "容器已退出"
}

main "$@"

sudo ROOTFS=/tmp/mini bash minicontainer.sh

# 容器里的验证
/ # hostname
minicontainer                    <- UTS 隔离 ✅

/ # ps -ef
# PID   USER  COMMAND
#   1   root  /bin/sh              <- PID 隔离，自己是 PID 1 ✅
#   8   root  ps -ef

/ # ip addr
# 1: lo: <LOOPBACK> mtu 65536 state DOWN     <- NET 隔离，只有 lo ✅

/ # cat /proc/self/cgroup
# 0::/                             <- cgroup 视图

/ # ls /
# bin dev etc home lib proc root sys tmp usr var    <- 是 alpine 的 rootfs ✅

# 验证 CPU 限制
/ # yes > /dev/null &
/ # yes > /dev/null &
# 宿主机上看
top -bn2 | grep yes | tail -2
# 两个 yes 进程加起来只用 50% CPU        ✅

# 验证内存限制
/ # dd if=/dev/zero of=/tmp/big bs=1M count=300
# Killed                            <- 超过 256MB 被 OOM killed ✅

# 宿主机上确认
cat /sys/fs/cgroup/minicontainer/memory.events
# oom_kill 1

/proc 和 /sys 的绝大部分内容【没有被 namespace 隔离】
                    v
容器里读 /proc/cpuinfo、/proc/meminfo、/proc/loadavg
                    v
拿到的是【宿主机】的数据

# 实测
docker run --rm --cpus=1 --memory=512m alpine sh -c '
  echo "nproc:      $(nproc)"
  echo "MemTotal:   $(grep MemTotal /proc/meminfo)"
  echo "loadavg:    $(cat /proc/loadavg)"
'
# nproc:      16                        <- 宿主机 16 核，但只给了 1 核！
# MemTotal:   MemTotal: 16283492 kB     <- 宿主机 16GB，但只给了 512MB！
# loadavg:    12.34 8.21 4.11 ...       <- 宿主机负载

# ✅ CPU 限额（cgroup v2）
cat /sys/fs/cgroup/cpu.max
# 100000 100000        -> quota/period = 1 核

# ✅ 内存限额
cat /sys/fs/cgroup/memory.max
# 536870912            -> 512MB
cat /sys/fs/cgroup/memory.current
# 234881024            -> 当前用了 224MB

# ✅ CPU 使用与限流
cat /sys/fs/cgroup/cpu.stat
# usage_usec 8923401234
# nr_throttled 198
# throttled_usec 892340

# ✅ PSI —— 比 loadavg 有意义得多
cat /sys/fs/cgroup/cpu.pressure

# cgroup v1 的路径
cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us
cat /sys/fs/cgroup/cpu/cpu.cfs_period_us
cat /sys/fs/cgroup/memory/memory.limit_in_bytes

# Java：JDK 10+ 默认开启，JDK 8u191+ 需要显式加
java -XX:+UseContainerSupport -XX:MaxRAMPercentage=70 -jar app.jar
#      ^^^^^^^^^^^^^^^^^^^^^^ 让 JVM 读 cgroup 而不是 /proc/meminfo
#                             ^^^^^^^^^^^^^^^^^^^ 堆占容器限额的 70%，留 30% 给堆外

// Go：必须引入 automaxprocs，否则 GOMAXPROCS = 宿主机核数
import _ "go.uber.org/automaxprocs"

// 以及设置内存上限（Go 1.19+）
// GOMEMLIMIT=450MiB   （容器限 512MB，留余量）

# Python：multiprocessing 的默认进程数也是错的
import os
# ❌ os.cpu_count() 返回宿主机核数
# ✅ 读 cgroup
def container_cpus():
    try:
        with open('/sys/fs/cgroup/cpu.max') as f:
            quota, period = f.read().split()
            if quota != 'max':
                return max(1, int(int(quota) / int(period)))
    except FileNotFoundError:
        pass
    return os.cpu_count()

# lxcfs：把 cgroup 数据伪装成 /proc 的内容
apt install lxcfs
systemctl enable --now lxcfs

docker run -it \
  -v /var/lib/lxcfs/proc/cpuinfo:/proc/cpuinfo:ro \
  -v /var/lib/lxcfs/proc/meminfo:/proc/meminfo:ro \
  -v /var/lib/lxcfs/proc/stat:/proc/stat:ro \
  -v /var/lib/lxcfs/proc/diskstats:/proc/diskstats:ro \
  --cpus=1 --memory=512m alpine sh -c 'nproc; grep MemTotal /proc/meminfo'
# 1                              ✅ 现在对了
# MemTotal: 524288 kB            ✅

kubectl exec -it mypod -- cat /sys/fs/cgroup/cpu.stat
# usage_usec 892340123
# user_usec 723401234
# system_usec 168938889
# nr_periods 89234
# nr_throttled 42318         <- 47% 的周期被限流了！
# throttled_usec 8923401234  <- 累计限流 8923 秒

容器 limits.cpu = 2（即每 100ms 周期给 200ms 配额）
应用有 16 个 P（GOMAXPROCS 取了宿主机核数）
        v
16 个线程并行跑，在【前 12.5ms】就把 200ms 配额用完了
        v
剩下的 87.5ms 全部被强制暂停（throttled）
        v
平均下来 CPU 使用率 = 200ms/100ms/16核 ≈ 12.5%... 监控看着很低
但每个周期都有 87.5ms 的「完全停止服务」-> P99 尖刺

kubectl exec -it mypod -- sh -c 'cat /proc/1/environ | tr "\0" "\n" | grep -i gomaxprocs'
# （空）                       <- 没设置

kubectl exec -it mypod -- nproc
# 16                           <- 读到的是宿主机核数

kubectl get pod mypod -o jsonpath='{.spec.containers[0].resources}'
# {"limits":{"cpu":"2","memory":"2Gi"},"requests":{"cpu":"1","memory":"1Gi"}}
#                    ^^^ 只给 2 核，但 GOMAXPROCS=16

// ✅ 方案一（推荐）：引入 automaxprocs，自动读 cgroup 设置 GOMAXPROCS
import _ "go.uber.org/automaxprocs"
// 启动时会打印：maxprocs: Updating GOMAXPROCS=2: determined from CPU quota

# ✅ 方案二：用 Downward API 显式注入
env:
  - name: GOMAXPROCS
    valueFrom:
      resourceFieldRef:
        resource: limits.cpu        # 自动取 limits.cpu 的值
        divisor: "1"

# ✅ 方案三：放宽或去掉 CPU limits（延迟敏感服务推荐）
resources:
  requests:
    cpu: "2"          # 保证 2 核
    memory: 1Gi
  limits:
    # 不设 cpu limits，允许突发时借用空闲 CPU
    memory: 2Gi       # 内存必须设！

延迟敏感的在线服务：
  requests.cpu  设准（保证基础份额，影响调度）
  limits.cpu    设宽松或不设（允许突发，避免限流毛刺）
  limits.memory 必须设（防止一个容器吃掉整个节点）

批处理 / 离线任务：
  limits.cpu    要设（防止挤占在线服务）
  配合低 CPUWeight 和 IOWeight

kubectl rollout restart deploy/myapp
sleep 60

kubectl exec -it mypod -- sh -c 'cat /proc/1/environ | tr "\0" "\n" | grep -i gomaxprocs'
# GOMAXPROCS=2                 ✅

kubectl exec -it mypod -- cat /sys/fs/cgroup/cpu.stat | grep -E "nr_periods|nr_throttled"
# nr_periods 3421
# nr_throttled 12              <- 从 47% 降到 0.35%  ✅

# PSI 也确认压力下降
kubectl exec -it mypod -- cat /sys/fs/cgroup/cpu.pressure
# some avg10=0.42 avg60=0.38 avg300=0.41
#           ^^^^ 之前是 45+

PID=$(docker inspect -f '{{.State.Pid}}' mycontainer)
nsenter -t $PID -n ss -tlnp          # 用宿主机的 ss 看容器的端口
nsenter -t $PID -n tcpdump -i eth0   # 在容器网络里抓包
nsenter -t $PID -n curl localhost/health