容器 · XB 现场笔记

网络命名空间隔离网络资源，名称并不拥有其中所有进程

Sat, 19 Feb 2028 00:00:00 +0000

Linux 网络命名空间分离接口、路由、邻居表、套接字端口和包过滤规则等网络资源。它与其他命名空间共享内核，不是独立操作系统。进程通常继承父进程的网络命名空间，工具也可以在另一个范围中执行进程。这种隔离针对网络资源，不会自动涵盖全部进程身份和文件系统访问，因此需要按实际机制说明边界。

坏掉的样子

运行 ip netns exec 不会自动获得完整容器隔离。PID、用户身份和主机名隔离属于其他机制。应用可能看到不同路由，却仍与父环境共享普通文件和主机名。如果把一个网络命名空间当成完整沙箱，就会赋予它从未配置过的保证。应区分实际改变了哪类资源，以及哪些属性仍然来自原有运行环境。

新命名空间也不会自动得到有用的外部连接。接口需要有意放置和配置，本地回环可能需要启用。移动接口会改变管理它的命名空间，原范围不再把该设备列为自己的接口。因此，从错误范围执行配置命令，可能报告接口不存在，尽管预期设备仍位于另一个命名空间。诊断前应先确认命令的执行上下文。

名称还有独立生命周期。ip netns 按约定在 /run/netns 暴露引用，通常也能通过 /var/run/netns 访问。删除名称会移除这项引用，但进程或其他引用仍可维持命名空间存活。如果清理流程把名称列表中消失，直接等同于所有服务终止，就可能留下网络资源和运行中的进程。名称只是管理入口，不是进程所有权的完整表达。

快速验证

本轮复核没有重新执行需要特权的命名空间、网络配置或监听操作，文中结果仍属于此前观察。

将脚本保存为 check-network-namespace.py，准备 Docker 后运行 python3 check-network-namespace.py。固定环境使用 Python 3.11.16 和 iproute2 6.1.0，通过 NET_ADMIN 与 SYS_ADMIN 在一次性容器内进行嵌套命名空间操作。临时 proc 挂载支持其中的网络参数设置，不移动宿主接口，也不发布宿主端口；实验资源随容器清理：

from pathlib import Path
from tempfile import TemporaryDirectory
import json,subprocess,uuid
recipe='FROM python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84\nRUN apt-get update && apt-get install -y --no-install-recommends iproute2=6.1.0-3 iputils-ping=3:20221126-1+deb12u1 nftables=1.0.6-2+deb12u2 tcpdump=4.99.3-1 traceroute=1:2.1.2-1 procps=2:4.0.2-3 && rm -rf /var/lib/apt/lists/*\nCMD ["python3"]\n'
program=r"""
from contextlib import ExitStack,contextmanager
from pathlib import Path
from tempfile import TemporaryDirectory
import json,os,select,signal,subprocess,time

def run(*args,check=True,input=None,timeout=8):
 result=subprocess.run(args,input=input,capture_output=True,text=True,timeout=timeout)
 if check:assert result.returncode==0,(args,result.returncode,result.stdout,result.stderr)
 return result
def ns(name,*args,**kwargs):return run('ip','netns','exec',name,*args,**kwargs)
def ip(name,*args,**kwargs):return ns(name,'ip',*args,**kwargs)
def stop(process):
 if process.poll() is None:
 process.terminate()
 try:process.wait(timeout=2)
 except subprocess.TimeoutExpired:process.kill();process.wait(timeout=2)
def line(process,timeout=3):
 assert select.select([process.stdout],[],[],timeout)[0],'child response deadline exceeded'
 value=process.stdout.readline();assert value,'child exited without a response'
 return value
def spawn(stack,command):
 process=subprocess.Popen(command,stdin=subprocess.PIPE,stdout=subprocess.PIPE,stderr=subprocess.PIPE,text=True)
 stack.callback(stop,process);return process
@contextmanager
def lab(names):
 with TemporaryDirectory(prefix='net-path-') as directory,ExitStack() as stack:
 root=Path(directory);proc=root/'proc';proc.mkdir();run('mount','-t','proc','proc',str(proc))
 stack.callback(run,'umount',str(proc))
 for name in names:
 run('ip','netns','add',name);stack.callback(run,'ip','netns','delete',name,check=False)
 ip(name,'link','set','lo','up')
 def setting(name,key,value):
 assert name in names
 path=proc/'sys'/key.replace('.','/')
 return ns(name,'python3','-c',f'from pathlib import Path; p=Path({str(path)!r}); p.write_text({str(value)!r}); print(p.read_text().strip())').stdout.strip()
 yield root,stack,setting
def wire(left,left_if,right,right_if,left_addresses,right_addresses):
 run('ip','link','add',left_if,'type','veth','peer','name',right_if)
 for name,interface,addresses in [(left,left_if,left_addresses),(right,right_if,right_addresses)]:
 run('ip','link','set',interface,'netns',name)
 for address in addresses:ip(name,'address','add',address,'dev',interface,*(['nodad'] if ':' in address else []))
 ip(name,'link','set',interface,'up')
def nft(name,script):return ns(name,'nft','-f','-',input=script)
def counters(name):
 data=json.loads(ns(name,'nft','-j','list','ruleset').stdout);found={}
 for entry in data['nftables']:
 rule=entry.get('rule',{})
 if 'comment' in rule:
 for expression in rule['expr']:
 if 'counter' in expression:found[rule['comment']]=expression['counter']['packets']
 return found

def server(stack,name,address,port=18080,label='server'):
 code=r'''
from http.server import BaseHTTPRequestHandler,ThreadingHTTPServer
import json,socket,sys
address,port,label=sys.argv[1],int(sys.argv[2]),sys.argv[3]
class Handler(BaseHTTPRequestHandler):
 def do_GET(self):
 body=json.dumps({'server':label,'peer':self.client_address,'path':self.path}).encode()
 self.send_response(200);self.send_header('Content-Length',str(len(body)));self.end_headers();self.wfile.write(body)
 def log_message(self,*args):pass
class Server(ThreadingHTTPServer):
 address_family=socket.AF_INET6 if ':' in address else socket.AF_INET
 def server_bind(self):
 if self.address_family==socket.AF_INET6:self.socket.setsockopt(socket.IPPROTO_IPV6,socket.IPV6_V6ONLY,1)
 super().server_bind()
service=Server((address,port),Handler);print('ready',flush=True);service.serve_forever()
'''
 process=spawn(stack,['ip','netns','exec',name,'python3','-u','-c',code,address,str(port),label])
 assert line(process).strip()=='ready';return process
def request(name,address,port=18080):
 code=r'''
import http.client,json,sys
client=http.client.HTTPConnection(sys.argv[1],int(sys.argv[2]),timeout=.7)
try:
 client.request('GET','/lab-visible-message');response=client.getresponse();body=json.loads(response.read())
 assert response.status==200;print(json.dumps({'ok':True,'status':response.status,'body':body}))
except OSError as error:print(json.dumps({'ok':False,'type':type(error).__name__,'errno':error.errno}))
finally:client.close()
'''
 return json.loads(ns(name,'python3','-c',code,address,str(port)).stdout)

with lab(['blue','green']) as (root,stack,setting):
 probe='import json,os,socket;print(json.dumps({"net":os.readlink("/proc/self/ns/net"),"pid":os.readlink("/proc/self/ns/pid"),"hostname":socket.gethostname()}))'
 parent=json.loads(run('python3','-c',probe).stdout)
 views={name:json.loads(ns(name,'python3','-c',probe).stdout) for name in ['blue','green']}
 assert len({parent['net'],views['blue']['net'],views['green']['net']})==3
 assert all(v['pid']==parent['pid'] and v['hostname']==parent['hostname'] for v in views.values())
 for name in ['blue','green']:
 ip(name,'link','add','dummy0','type','dummy');ip(name,'addr','add','192.0.2.10/24','dev','dummy0');ip(name,'link','set','dummy0','up')
 ip('blue','route','add','203.0.113.0/24','dev','dummy0')
 assert json.loads(ip('blue','-j','route','show','203.0.113.0/24').stdout)
 assert not json.loads(ip('green','-j','route','show','203.0.113.0/24').stdout)
 setting('blue','net.ipv4.ip_forward',0);setting('green','net.ipv4.ip_forward',1)
 forwarding={name:ns(name,'sysctl','-n','net.ipv4.ip_forward').stdout.strip() for name in ['blue','green']};assert forwarding=={'blue':'0','green':'1'}
 marker=root/'shared.txt';marker.write_text('shared filesystem')
 assert ns('blue','cat',str(marker)).stdout==ns('green','cat',str(marker)).stdout=='shared filesystem'
 daemon=server(stack,'blue','192.0.2.10',label='blue')
 named=request('blue','192.0.2.10');assert named['ok'] and named['body']['server']=='blue'
 run('ip','netns','delete','blue');assert not Path('/run/netns/blue').exists()
 assert daemon.poll() is None and os.readlink(f'/proc/{daemon.pid}/ns/net')==views['blue']['net']
 by_pid=run('nsenter','-t',str(daemon.pid),'-n','python3','-c',
 'import http.client,json; c=http.client.HTTPConnection("192.0.2.10",18080,timeout=1);c.request("GET","/");r=c.getresponse();print(json.dumps({"status":r.status,"body":json.loads(r.read())}));c.close()')
 surviving=json.loads(by_pid.stdout);assert surviving['status']==200 and surviving['body']['server']=='blue'
 print(json.dumps({'parent':parent,'namespace_views':views,'blue_only_route':True,'forwarding':forwarding,
 'same_file_visible':True,'before_name_deleted':named,'name_deleted_process_alive':True,'after_name_deleted':surviving}))
"""
name='xbcatm-netpath-'+uuid.uuid4().hex[:10]
def docker(*args,**kwargs):return subprocess.run(['docker',*args],capture_output=True,text=True,timeout=300,**kwargs)
try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);(root/'Dockerfile').write_text(recipe)
 build=docker('build','-t',name,str(root));assert build.returncode==0,build.stderr
 result=docker('run','--rm','-i','--name',name,'--network','none','--cap-add','NET_ADMIN','--cap-add','SYS_ADMIN',
 '--memory','256m','--pids-limit','128',name,'python3','-',input=program)
 assert result.returncode==0,result.stderr
 print(json.dumps(json.loads(result.stdout),sort_keys=True))
finally:
 docker('rm','-f',name);docker('image','rm',name)

父环境、blue 和 green 报告三个不同网络命名空间标识，但 PID 命名空间标识与主机名保持相同。父进程创建的标记文件，也能被两个子范围读取。这些正向观察明确了本例边界：网络范围改变了，而所检查的这些进程和文件系统属性仍然共享。不能由网络标识不同，推导其他所有隔离也已经建立。

两个子范围各自创建 dummy0，都使用 192.0.2.10/24。相同名称和地址能够共存，因为它们属于不同网络上下文。只有 blue 增加到 203.0.113.0/24 的路由，查询 green 确认没有对应条目。实验检查生效的独立路由表，不是只打印两个名称就宣布隔离成功，也没有要求地址文本必须跨所有命名空间唯一。

程序明确把 blue 的 IPv4 转发设为零、green 设为一，再分别读取确认。这验证参数作用范围，没有演示真实报文转发。dummy 接口没有物理对端，配置地址和路由也不表示能够访问外部服务。应保留“参数已经不同”和“某条通信路径实际可用”之间的区别，避免把管理状态当成应用交付结果。

真实 HTTP 服务器在 blue 的 192.0.2.10 启动。通过命名空间名称执行客户端，得到状态二百和身份 blue。脚本随后删除 blue 名称，确认引用路径消失，但服务器进程和它的网络命名空间标识仍存在。移除命名引用没有杀死进程，也没有令监听立即消失，这是清理和故障恢复中很重要的生命周期差异。

利用这个明确属于实验的服务器 PID，nsenter 在仍存活的网络命名空间执行另一个客户端，再次得到状态二百与身份 blue。这证明删除名称后应用仍在工作，而不只是 proc 中还有一个条目。最后，清理栈停止自己启动的进程并移除其他命名资源，容器生命周期负责收回实验整体范围，不涉及现有宿主服务。

分开管理名称、进程归属与通信配置

记录服务的进程归属，以及运维命令实际使用的网络范围。命名空间标识适合比较当前活跃上下文，不应把短暂标识当作永久资产身份。名称意外消失时，先检查相关自有进程，再判断网络状态是否已经释放。不能仅凭列表为空，就假定可以在没有旧状态和旧服务的前提下创建替代环境。

对普通配置文件，ip netns exec 可以创建挂载命名空间，将按网络名称准备的文件绑定到惯常位置，例如使用独立解析器配置。这不等于复制了全部私有文件系统。重现客户端环境时，应记录这些额外选择，避免混淆 DNS 配置差异与路由隔离。某个共享标记文件可见，也不代表所有配置路径都必然使用相同视图。

需要通信时，应明确建立虚拟链路、路由、转发和过滤。网络命名空间提供资源边界，真正配置决定哪些数据能够通过。拆除时，应先停止服务拥有的进程并释放相关引用，再期待范围完全消失。删除名称是生命周期中的一项管理动作，不是通用的进程终止命令，也不能代替对残留服务和资源的实际检查。

来源

Linux network_namespaces(7)，网络命名空间隔离的资源，已核验 2026-09-12。
Linux ip-netns(8)，名称引用、命令执行及进程存活时的删除语义，已核验 2026-09-12。
Linux ip-link(8)，接口创建与命名空间归属，已核验 2026-09-12。

veth 对在两个端点之间搬运帧，路由决定这些帧承载的路径

Sun, 21 Nov 2027 00:00:00 +0000

veth 对由两个互联的虚拟以太网设备组成。从一端发送的帧到达另一端，再由接收网络栈或网桥处理。两端可以放在不同 Linux 网络命名空间，因此常用于容器网络。创建这一对设备只提供链路，地址、路由、桥接关系、转发和访问策略都需要另外配置。不能把接口已经出现，等同于完整网络已经准备好。

坏掉的样子

接口显示管理状态 UP，仍可能因为 veth 对端关闭而没有载波。只读取 UP 标志，会让尚未完成的配置看起来已经就绪。应检查两个端点，并区分管理状态与 LOWER_UP。路由也可能已经指向这个接口，但链路仍无法承载有效流量，所以路由列表本身不是连通性检查，更不能代替一次真实应用交换。

veth 对不会把 IP 载荷限制为对端接口自身地址。路由选择报文经过哪个链路，随后以太网转发或接收网络栈决定下一步处理。发往容器直接邻居之外的流量，也可以通过这一对设备到达路由器或网桥。声称“不发给对端的包都会留在本地”，混淆了链路交付与 IP 目的地选择，容易误导容器出口排障。

两端生命周期也相互关联。删除一个 veth 端点，会移除另一个端点，即使对端由另一个命名空间管理。因此宿主侧清理动作可能删除容器接口。影响活跃工作负载时，应有意识地安排停止流量、调整路由和删除设备的顺序。命名空间分离了管理视图，却没有让成对设备变成两项互不影响的资源。

快速验证

将脚本保存为 check-veth.py，准备 Docker 后执行 python3 check-veth.py。固定 Linux 容器使用 Python 3.11.16、iproute2 6.1.0，以及用于嵌套命名空间的 NET_ADMIN 和 SYS_ADMIN。它只创建一次性虚拟设备。左右命名空间各获得一个端点，分别配置 192.0.2.1/30 和 192.0.2.2/30，没有移动现有宿主网卡：

from pathlib import Path
from tempfile import TemporaryDirectory
import json,subprocess,uuid
recipe='FROM python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84\nRUN apt-get update && apt-get install -y --no-install-recommends iproute2=6.1.0-3 iputils-ping=3:20221126-1+deb12u1 nftables=1.0.6-2+deb12u2 tcpdump=4.99.3-1 traceroute=1:2.1.2-1 procps=2:4.0.2-3 && rm -rf /var/lib/apt/lists/*\nCMD ["python3"]\n'
program=r"""
from contextlib import ExitStack,contextmanager
from pathlib import Path
from tempfile import TemporaryDirectory
import json,os,select,signal,subprocess,time

def run(*args,check=True,input=None,timeout=8):
 result=subprocess.run(args,input=input,capture_output=True,text=True,timeout=timeout)
 if check:assert result.returncode==0,(args,result.returncode,result.stdout,result.stderr)
 return result
def ns(name,*args,**kwargs):return run('ip','netns','exec',name,*args,**kwargs)
def ip(name,*args,**kwargs):return ns(name,'ip',*args,**kwargs)
def stop(process):
 if process.poll() is None:
 process.terminate()
 try:process.wait(timeout=2)
 except subprocess.TimeoutExpired:process.kill();process.wait(timeout=2)
def line(process,timeout=3):
 assert select.select([process.stdout],[],[],timeout)[0],'child response deadline exceeded'
 value=process.stdout.readline();assert value,'child exited without a response'
 return value
def spawn(stack,command):
 process=subprocess.Popen(command,stdin=subprocess.PIPE,stdout=subprocess.PIPE,stderr=subprocess.PIPE,text=True)
 stack.callback(stop,process);return process
@contextmanager
def lab(names):
 with TemporaryDirectory(prefix='net-path-') as directory,ExitStack() as stack:
 root=Path(directory);proc=root/'proc';proc.mkdir();run('mount','-t','proc','proc',str(proc))
 stack.callback(run,'umount',str(proc))
 for name in names:
 run('ip','netns','add',name);stack.callback(run,'ip','netns','delete',name,check=False)
 ip(name,'link','set','lo','up')
 def setting(name,key,value):
 assert name in names
 path=proc/'sys'/key.replace('.','/')
 return ns(name,'python3','-c',f'from pathlib import Path; p=Path({str(path)!r}); p.write_text({str(value)!r}); print(p.read_text().strip())').stdout.strip()
 yield root,stack,setting
def wire(left,left_if,right,right_if,left_addresses,right_addresses):
 run('ip','link','add',left_if,'type','veth','peer','name',right_if)
 for name,interface,addresses in [(left,left_if,left_addresses),(right,right_if,right_addresses)]:
 run('ip','link','set',interface,'netns',name)
 for address in addresses:ip(name,'address','add',address,'dev',interface,*(['nodad'] if ':' in address else []))
 ip(name,'link','set',interface,'up')
def nft(name,script):return ns(name,'nft','-f','-',input=script)
def counters(name):
 data=json.loads(ns(name,'nft','-j','list','ruleset').stdout);found={}
 for entry in data['nftables']:
 rule=entry.get('rule',{})
 if 'comment' in rule:
 for expression in rule['expr']:
 if 'counter' in expression:found[rule['comment']]=expression['counter']['packets']
 return found

def server(stack,name,address,port=18080,label='server'):
 code=r'''
from http.server import BaseHTTPRequestHandler,ThreadingHTTPServer
import json,socket,sys
address,port,label=sys.argv[1],int(sys.argv[2]),sys.argv[3]
class Handler(BaseHTTPRequestHandler):
 def do_GET(self):
 body=json.dumps({'server':label,'peer':self.client_address,'path':self.path}).encode()
 self.send_response(200);self.send_header('Content-Length',str(len(body)));self.end_headers();self.wfile.write(body)
 def log_message(self,*args):pass
class Server(ThreadingHTTPServer):
 address_family=socket.AF_INET6 if ':' in address else socket.AF_INET
 def server_bind(self):
 if self.address_family==socket.AF_INET6:self.socket.setsockopt(socket.IPPROTO_IPV6,socket.IPV6_V6ONLY,1)
 super().server_bind()
service=Server((address,port),Handler);print('ready',flush=True);service.serve_forever()
'''
 process=spawn(stack,['ip','netns','exec',name,'python3','-u','-c',code,address,str(port),label])
 assert line(process).strip()=='ready';return process
def request(name,address,port=18080):
 code=r'''
import http.client,json,sys
client=http.client.HTTPConnection(sys.argv[1],int(sys.argv[2]),timeout=.7)
try:
 client.request('GET','/lab-visible-message');response=client.getresponse();body=json.loads(response.read())
 assert response.status==200;print(json.dumps({'ok':True,'status':response.status,'body':body}))
except OSError as error:print(json.dumps({'ok':False,'type':type(error).__name__,'errno':error.errno}))
finally:client.close()
'''
 return json.loads(ns(name,'python3','-c',code,address,str(port)).stdout)

with lab(['left','right']) as (root,stack,setting):
 run('ip','link','add','left0','type','veth','peer','name','right0')
 run('ip','link','set','left0','netns','left');run('ip','link','set','right0','netns','right')
 ip('left','addr','add','192.0.2.1/30','dev','left0');ip('right','addr','add','192.0.2.2/30','dev','right0')
 ip('left','link','set','left0','up')
 before=json.loads(ip('left','-j','link','show','left0').stdout)[0]
 assert 'LOWER_UP' not in before['flags']
 failed=ns('left','ping','-n','-c','1','-W','1','192.0.2.2',check=False);assert failed.returncode!=0
 ip('right','link','set','right0','up')
 after={name:json.loads(ip(name,'-j','link','show',interface).stdout)[0] for name,interface in [('left','left0'),('right','right0')]}
 assert all('LOWER_UP' in v['flags'] for v in after.values())
 ip('left','neigh','flush','dev','left0');ip('right','neigh','flush','dev','right0')
 successful=ns('left','ping','-n','-c','1','-W','1','192.0.2.2');assert successful.returncode==0
 daemon=server(stack,'right','192.0.2.2',label='right');response=request('left','192.0.2.2');assert response['ok']
 ip('right','addr','add','203.0.113.9/32','dev','lo');ip('left','route','add','203.0.113.9/32','via','192.0.2.2')
 server(stack,'right','203.0.113.9',label='beyond-link-address');routed_response=request('left','203.0.113.9');assert routed_response['ok']
 ip('left','link','delete','left0');gone=ip('right','link','show','right0',check=False);assert gone.returncode!=0 and 'does not exist' in gone.stderr
 print(json.dumps({'one_end_up_flags':before['flags'],'one_end_up_ping_exit':failed.returncode,
 'both_up_flags':{n:v['flags'] for n,v in after.items()},'both_up_ping_exit':successful.returncode,'http':response,'other_ip_destination':routed_response,
 'deleting_one_removes_peer':True,'peer_absent_diagnostic':gone.stderr.strip()}))
"""
name='xbcatm-netpath-'+uuid.uuid4().hex[:10]
def docker(*args,**kwargs):return subprocess.run(['docker',*args],capture_output=True,text=True,timeout=300,**kwargs)
try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);(root/'Dockerfile').write_text(recipe)
 build=docker('build','-t',name,str(root));assert build.returncode==0,build.stderr
 result=docker('run','--rm','-i','--name',name,'--network','none','--cap-add','NET_ADMIN','--cap-add','SYS_ADMIN',
 '--memory','256m','--pids-limit','128',name,'python3','-',input=program)
 assert result.returncode==0,result.stderr
 print(json.dumps(json.loads(result.stdout),sort_keys=True))
finally:
 docker('rm','-f',name);docker('image','rm',name)

起初只启用 left0，它的标志包含 UP 和 NO-CARRIER，没有 LOWER_UP，因为 right0 仍关闭。单次 ping 失败。这里同时提供链路状态和实际失败交换，没有用“接口创建成功”来替代对端已经配置正确的证据。管理状态说明操作者希望设备工作，载波状态则反映配对链路当前能否成立。

启用 right0 后，两端都报告 LOWER_UP。脚本清理失败尝试留下的邻居条目，再进行正常状态比较，避免残留解析计时影响结果。新的 ping 成功，从左侧访问 192.0.2.2 的真实 HTTP 请求也收到右侧服务身份。清理动作明确可见，实验没有承诺所有已经等待中的应用请求都会在启用链路后瞬间恢复。

随后右侧在回环接口配置 203.0.113.9/32，左侧添加经 192.0.2.2 到该地址的主机路由。第二个绑定 203.0.113.9 的 HTTP 监听，仍通过同一 veth 对成功响应。报文的 IP 目的地不同于对端链路地址，但所选路径依然使用这条虚拟以太网链路。这个对照直接检验地址与传输路径的区别。

第二个目的地属于右侧命名空间本地，因此本例没有声称继续经过另一个路由器转发。它只隔离链路邻居地址与最终 IP 目的地之间的差异。更大拓扑可以把接收端接入网桥或路由网络，但这些额外组件需要独立配置和验证。不能由这次成功，就推导容器已经自动获得公网出口或任意跨网段访问能力。

最后删除 left0，右侧执行 ip link show right0 得到设备不存在的诊断。对端是被移除了，而不只是进入管理关闭状态；两个命名空间本身在清理之前仍存在。这个结果区分成对设备生命周期与容纳某一端的命名空间生命周期。清理日志需要反映真正被删除的资源，不能把所有变化都写成同一种“断网”。

按层次检查实际路径

先确认两端归属的命名空间及运行时赋予的名称，再查看管理状态、载波、地址、邻居解析和失败目的地的路由。链路变化后，旧邻居状态可能延迟恢复；缺失路由则可能让报文根本没有发上链路。即使高层客户端都只显示超时，这些原因也需要不同修复。应保留各层直接证据，而不是只围绕一个接口标志反复修改。

一对设备不是多端口交换机。网桥可以在以太网层连接多个此类链路，路由器则在 IP 网络之间转发。启用端点不会自动建立这些行为，也不会自动添加互联网路由。文档应记录真实连接关系与过滤位置，尤其当容器运行时创建设备，而其他组件管理路由或防火墙时，不能假定其中一方已经完成了所有配置。

把删除视为同时影响两端的操作，并验证相关工作负载结果。如果吞吐量或延迟要求推动 MTU、队列或卸载配置调整，应测量相应路径，不能仅因链路是虚拟设备就推断性能。本实验验证成对交付、明确就绪、正确目的地路由以及关联删除，不代表完成了一整套容器网络，也不建立统一性能承诺。

来源

Linux veth(4)，成对传输、载波状态及命名空间使用，已核验 2026-09-12。
Linux ip-link(8)，veth 创建、状态、移动及删除，已核验 2026-09-12。
Linux network_namespaces(7)，网络边界与虚拟设备生命周期，已核验 2026-09-12。

安全上下文需要运行时证据来验证

Sat, 20 Nov 2027 00:00:00 +0000

Kubernetes 的 securityContext 配置进程身份及部分操作系统约束，可以缩小被攻陷应用允许执行的操作，但本身不会建立完整安全边界。应先确定应用实际需要什么操作，再配置对应字段，并在最终容器中同时测试允许与拒绝的行为。只有一份看起来严格的清单，还不能说明运行中的进程已经按预期受到限制，也不能代替应用本身的权限设计。

把设置放在正确层级

Pod 级配置可以提供用户和组身份、共享卷的组权限行为，以及 seccomp 配置。容器级字段可以覆盖适用的默认值，并设置 capabilities、权限提升和只读根文件系统。需要核对字段真实 API 范围，把熟悉的名称写在错误位置，并不会获得等价约束。相同的 securityContext 名称之下，不代表所有字段都能互换放置。

runAsUser 选择数值用户身份，runAsNonRoot 则要求容器符合非 root 策略。这些设置补充镜像元数据，不能仅凭一个用户名看起来普通，就信任实际权限。卷权限也必须允许所选身份完成必要工作。下面的 emptyDir 通过 fsGroup 提供组访问，使应用能够写入指定工作目录，而不必因此获得对整个根文件系统的写权限。

Linux capabilities 把传统上广泛关联于 root 的权限拆成不同能力。删除 ALL 会移除容器配置中的这些能力。普通容器默认并不继承全部 Linux 能力，而容器内以 root 运行，也不等于已经成功逃逸到宿主机。应审阅真实有效权限，避免用这两种过度简化替代证据。减少权限很有价值，但其效果需要准确描述。

坏掉的样子

allowPrivilegeEscalation false 会为进程设置 no_new_privs，限制通过执行程序获取新权限，例如 set-user-ID 或文件能力引起的身份与权限提升。它不会撤销进程已经拥有的全部权限，也不代替业务授权。应检查实际进程标志和有效能力，不能把每一次被拒绝的操作都归因于这个字段，否则可能误解其他身份或文件权限设置的作用。

readOnlyRootFilesystem 让容器根文件系统只读，其他挂载仍可能可写，包括明确提供的工作卷。这并不是全面禁止执行代码：解释器仍可以读取并运行可写卷中的程序。它也不会阻止网络请求，或撤销对已经挂载数据的读取。只读存储约束的是一类操作，不能直接证明攻击无法继续，更不能把“不能改根目录”扩写成“不能写入任何内容”。

Seccomp 过滤系统调用，但 RuntimeDefault 取决于运行时提供的默认配置。进程报告过滤模式，说明存在实际过滤机制，不证明所有不期望的调用和攻击路径都被阻断。普通 Linux 容器运行时也能执行这些字段，不是必须采用特殊沙箱它们才生效。更强隔离有独立设计要求，应按威胁模型讨论，不能把是否有效与某一个产品名称绑定。

互相冲突的身份设置可能通过 API 准入，却阻止容器启动。镜像也可能原本需要在根文件系统中写缓存或临时文件。应检查启动状态和被拒绝路径，只提供实际所需工作存储，不要用恢复 root、允许权限提升或打开整个根文件系统来处理所有权限报错。必要写入与过大权限需要通过真实调用区分。

快速验证

以下实验及观察结果沿用原文记录。本次审阅没有重新执行 Kubernetes 集成实验；文中的成功结果属于历史记录，不代表本轮取得了新的运行证据。

准备临时 Linux Kubernetes 集群、kubectl，以及节点可用的 python:3.11-slim-bookworm 镜像。保存为 security-context.py，执行 python3 security-context.py KUBECONFIG_PATH CONTEXT，明确指定测试集群。账号需要创建、删除命名空间。实测服务端为 Kubernetes 1.34.11，使用 kind 的标准运行时配置，所有对象均属于本次临时实验。

import json
import subprocess
import sys
import time
from uuid import uuid4

assert len(sys.argv) == 3, 'usage: python3 example.py DISPOSABLE_KUBECONFIG CONTEXT'
base = ['kubectl', '--kubeconfig', sys.argv[1], '--context', sys.argv[2], '--request-timeout=30s']
image = 'python:3.11-slim-bookworm'


def k(*args, payload=None, expected=0):
 result = subprocess.run(base + list(args), input=json.dumps(payload) if payload is not None else None,
 capture_output=True, text=True, timeout=150)
 if expected is not None:
 assert result.returncode == expected, result.stderr
 return result


def obj(namespace, kind, name=None, selector=None):
 args = ['get', kind, '-n', namespace, '-o', 'json']
 if name:
 args.append(name)
 if selector:
 args += ['-l', selector]
 return json.loads(k(*args).stdout)


def apply(namespace, data):
 return k('apply', '-n', namespace, '-f', '-', payload=data)


def wait_for(read, ready, seconds=120):
 until = time.monotonic() + seconds
 while time.monotonic() < until:
 value = read()
 if ready(value):
 return value
 time.sleep(0.5)
 raise AssertionError('expected Kubernetes condition did not arrive')


def pod_ready(pod):
 return any(c['type'] == 'Ready' and c['status'] == 'True'
 for c in pod.get('status', {}).get('conditions', []))


def spec(script='import time; time.sleep(600)'):
 return {'automountServiceAccountToken': False, 'terminationGracePeriodSeconds': 1,
 'containers': [{'name': 'app', 'image': image, 'imagePullPolicy': 'IfNotPresent',
 'command': ['python3', '-c', script],
 'resources': {'requests': {'cpu': '10m', 'memory': '24Mi'},
 'limits': {'cpu': '200m', 'memory': '96Mi'}}}]}

namespace = 'notes-security-' + uuid4().hex[:8]
k('create', 'namespace', namespace)
try:
 probe = '''from pathlib import Path
import errno,json,os,subprocess,time
status=dict(line.split(':',1) for line in Path('/proc/self/status').read_text().splitlines() if ':' in line)
try:
 Path('/tmp/forbidden-write').write_text('x')
 raise AssertionError('root filesystem unexpectedly writable')
except OSError as error:
 assert error.errno==errno.EROFS
try:
 os.setuid(0)
 raise AssertionError('unexpected UID escalation')
except OSError as error:
 assert error.errno==errno.EPERM
work=Path('/work'); (work/'data').write_text('writable')
(work/'example.py').write_text("print('interpreted from the writable volume')")
ran=subprocess.check_output(['python3',str(work/'example.py')],text=True).strip()
result={'uid':os.getuid(),'gid':os.getgid(),'cap_eff':int(status['CapEff'].strip(),16),
 'no_new_privs':int(status['NoNewPrivs']),'seccomp':int(status['Seccomp']),
 'root_write_errno':errno.EROFS,'uid_zero_denied':True,
 'volume_value':(work/'data').read_text(),'writable_volume_code':ran}
assert result['uid']==result['gid']==10001
assert result['cap_eff']==0 and result['no_new_privs']==1 and result['seccomp']==2
print(json.dumps(result),flush=True); time.sleep(600)
'''
 podspec = spec(probe)
 podspec['securityContext'] = {'runAsNonRoot': True, 'runAsUser': 10001,
 'runAsGroup': 10001, 'fsGroup': 10001, 'seccompProfile': {'type': 'RuntimeDefault'}}
 podspec['volumes'] = [{'name': 'work', 'emptyDir': {}}]
 c = podspec['containers'][0]
 c['securityContext'] = {'allowPrivilegeEscalation': False, 'readOnlyRootFilesystem': True,
 'capabilities': {'drop': ['ALL']}}
 c['volumeMounts'] = [{'name': 'work', 'mountPath': '/work'}]
 apply(namespace, {'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': 'restricted'}, 'spec': podspec})
 wait_for(lambda: obj(namespace, 'pod', 'restricted'), pod_ready)
 observed = json.loads(wait_for(lambda: k('logs', '-n', namespace, 'restricted').stdout.strip(), bool))
 conflicting = spec()
 conflicting['securityContext'] = {'runAsNonRoot': True, 'runAsUser': 0}
 apply(namespace, {'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': 'conflict'}, 'spec': conflicting})
 refused = wait_for(lambda: obj(namespace, 'pod', 'conflict'), lambda p:
 any(c.get('state', {}).get('waiting', {}).get('reason') == 'CreateContainerConfigError'
 for c in p.get('status', {}).get('containerStatuses', [])))
 waiting = refused['status']['containerStatuses'][0]
 assert 'runAsUser breaks non-root policy' in waiting['state']['waiting']['message']
 assert waiting['restartCount'] == 0
 print(json.dumps({'runtime_observation': observed,
 'conflicting_uid_accepted_by_api_but_container_start_refused': True,
 'container_escape_resistance_tested': False}))
finally:
 k('delete', 'namespace', namespace, '--wait=true', '--timeout=90s')

受约束 Pod 报告 UID 和 GID 均为 10001，有效能力为零，NoNewPrivs 为一，seccomp 模式为二。在根文件系统的 /tmp 下写入返回 EROFS，尝试切换到零号用户返回 EPERM。这些结果反映组合身份和权限设置的效果，不能单独归因为其中某个标志，也没有逐一隔离测量每个字段的独立贡献。

进程成功写入 /work 中的数值，并调用 Python 执行刚写在该卷里的文件。这个允许操作刻意展示工作卷仍然可用，以及只读根声明的边界。第二个 Pod 同时声明 runAsNonRoot 和 runAsUser 零，API 接受对象，但 kubelet 在容器启动前报告 CreateContainerConfigError，说明对象保存成功和进程成功启动是不同阶段。

原文报告全部断言通过，命名空间随后删除。实验验证这些具体运行时约束和启动失败，没有测试容器逃逸抵抗能力、每一条 seccomp 规则、敌对多租户隔离或应用授权模型。真实交付需要将这些设置与对应访问需求一起审阅，并保留允许与拒绝操作各自的实际证据。

来源

Kubernetes: Security Context，Pod 与容器安全字段及运行时效果，已核验 2026-10-15。
Linux: No New Privileges Flag，通过执行程序获取新权限的限制，已核验 2026-10-15。
Linux: capabilities(7)，独立能力权限与进程能力集合，已核验 2026-10-15。

签名镜像可以证来源

Thu, 21 Oct 2027 00:00:00 +0000

容器镜像的引用是一个可变指针，摘要则不可变。签名把摘要和一把密钥绑在一起，于是校验方能在运行之前先问：这些字节出自谁手。这正是 registry 与清单层回答不了的问题——它们只能告诉你字节从哪里来，不能告诉你谁做的。

张力在于：签名只有在被校验时才是一项控制，而校验只有在信任根被管理好时才有意义。签名只是流水线里的几行；决定哪些密钥算数、一把密钥退役之后怎么办，才是真正的工程。

摘要是身份，标签是指针

摘要是对精确清单字节的哈希，镜像一变摘要就变。对摘要签名，就是把签名绑在内容上而不是名字上。用 EC P-256 密钥对、真实的 SHA-256 摘要和一份 cosign 形状的载荷，openssl dgst -verify 返回成功；把产物翻转一个字节，摘要随之改变，同一次校验返回失败。

标签的行为不同。三个标签指向同一个已签名摘要，全都能通过校验，因为标签从来不在被签名的载荷里。这正是设计：标签是指向摘要的指针，改指向是常规的 registry 操作。把标签挪到一个从未被签名的摘要上，对解析后摘要的校验就会失败——但前提是校验方先去解析标签，而不是直接相信你手上那个可变的引用。

对标签签名绑不住任何东西

如果签的是字符串 app:v2 而不是摘要，校验就会永远成功，因为这个字符串永远不变。把那个标签指向一个完全不同的镜像，签名照样通过：它对一个字符串说了真话，而这个字符串对字节什么都没说。所以签名必须签在摘要上，校验必须先解析标签再比对。

信任根是另一半。签名只证明「持有私钥的人产出了它」；公钥，或者一张由 Fulcio 签发、并配有一条 Rekor 日志条目的证书，才把它变成「这个身份构建了它」。分发和轮换这个锚点就是安全边界，而它完全在签名之外。

校验才是控制，签名不是

流水线签完名就直接部署、不做校验，买到的只是装饰。实测对比很直白：被篡改的产物在部署步骤做校验时被挡住；同一条产物在部署步骤只记录来源信息时顺利上线——而那份来源记录从此写着被篡改的摘要。强制点应该在准入，或者部署前的一道闸门，让未签名的镜像根本到不了节点。准入控制器在这里的价值，是它不依赖流水线的自觉：策略在对象进入集群的那一刻求值，跳过签名不是「忘了做」，而是直接失败。

撤销是签名内部完全没有答案的那部分。签名没有有效期、没有吊销列表：在它的密钥下永远有效。轮换密钥并不能撤销任何东西——旧签名在新密钥下被拒，在旧密钥下依旧被接受——所以任何持有已退役密钥的人都能继续产出可通过校验的产物。解法是配短时效证书和透明日志的信任根，再加上钉住身份的策略，而不只是检查「存在某个签名」。

坏掉的样子

最经典的是策略引擎从未检查过的未签名镜像。流水线签名，部署步骤按标签拉取并运行，而这个缺口在有人往同一标签推入不同字节之前一直不可见。审计记录从此为一份没人校验过的镜像声称来源，这比完全没有来源记录更糟。

第二种是签名能通过、但签名所用的密钥你已经不再信任。因为签名内部没有撤销机制，泄露或已退役的密钥会继续签出可接受的产物，而爆炸半径是那把密钥签过的每一个产物，且是回溯性的。在策略里钉住签名身份，让证书保持短时效，并把签名记进透明日志，这样一把意料之外的密钥会以一条日志条目出现，而不是一次无声通过。

快速验证

校验摘要，再确认标签仍然指向它：

cosign verify --key cosign.pub registry.example.com/app@sha256:9ab5a134...
cosign tree registry.example.com/app@sha256:9ab5a134...
skopeo inspect --format '{{.Digest}}' docker://registry.example.com/app:latest

cosign verify 必须打印出被校验的身份并以 0 退出，cosign tree 应列出挂在该摘要上的签名与证明。skopeo inspect 必须打印出你刚校验过的同一个摘要。错误的结果是：verify 报找不到匹配的签名，或者 verify 成功而 skopeo 报出另一个摘要——那意味着标签现在指向从未被签名的字节。

来源

Sigstore：用 cosign 校验签名，基于密钥与无密钥的摘要校验，已核验 2026-09-16。
SLSA v1.0 规范，来源信息、摘要，以及签名到底在证明什么，已核验 2026-09-16。
Sigstore policy-controller，在准入阶段强制签名与身份策略，已核验 2026-09-16。

ENTRYPOINT 和 CMD 定义可被运行者覆盖的启动默认值

Sun, 03 Oct 2027 00:00:00 +0000

镜像的 ENTRYPOINT 和 CMD 共同参与容器创建时的启动命令。使用 exec 形式 ENTRYPOINT 时，CMD 通常提供追加给入口的默认参数；没有入口时，CMD 可以提供可执行程序及其参数。这些是启动默认值，不是强制执行边界。有权限创建容器的运行者，可以替换入口或参数，因此不能把 ENTRYPOINT 描述成无论如何都不可改变的程序锁。

坏掉的样子

在 docker run image ... 中写到镜像名之后的参数，会替换 CMD，不是自动加到原 CMD 默认值之后。exec 形式入口仍然保留，除非显式覆盖。用户以为自己只是追加一个选项，却可能丢掉全部默认参数。因此，命令行工具需要说明哪些值可省略、哪些必须重新提供，以及自身参数解析器如何处理覆盖。

exec 形式使用 JSON 数组，不会隐式运行 shell。$DEMO 这样的字符串会原样传给程序，而不是自动展开环境变量。管道、重定向和通配符也需要真正的解释器，才会获得相应含义。shell 形式会改变参数和进程语义，所以两种形式之间的切换并不只是语法美化，不能只看命令表面似乎相同。

启动包装脚本还可能让服务藏在不转发停止信号的 shell 后面。Docker 通常向容器主进程发送停止信号，等待配置的超时，必要时强制终止。即使服务自身正确安装了 SIGTERM 处理函数，如果信号只到达另一个不会转发的进程，这个处理函数也无法发挥作用。排查优雅退出失败时，应先确认信号实际发给了谁。

快速验证

先取得固定基础镜像，再用宿主 Python 和 Docker 构建器运行脚本。实测为 Docker 29.3.1、Linux arm64，镜像内 Python 3.11.16。实验创建独立临时容器并关闭网络，等待每个服务打印就绪信息后测试停止，结束时删除自己的容器和镜像标签，不依赖启动后盲目等待固定时长来猜测服务已经准备好：

from pathlib import Path
from tempfile import TemporaryDirectory
import json,subprocess,time,uuid

BASE='python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84'
def docker(*args,check=True):
 result=subprocess.run(['docker',*args],capture_output=True,text=True,timeout=120)
 if check:assert result.returncode==0,result.stderr
 return result
def inspect(name):return json.loads(docker('inspect',name).stdout)[0]

name='xbcatm-entrypoint-'+uuid.uuid4().hex[:10];tag=name+':probe';containers=[name+'-exec',name+'-child']
try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory)
 (root/'args.py').write_text('import json,sys\nprint(json.dumps(sys.argv[1:]))\n')
 (root/'service.py').write_text('import json,os,signal\ndef stop(signum,frame):\n print("stopped",flush=True)\n raise SystemExit(0)\nsignal.signal(signal.SIGTERM,stop)\nprint(json.dumps({"pid":os.getpid()}),flush=True)\nwhile True:signal.pause()\n')
 (root/'exec.sh').write_text('#!/bin/sh\nexec python /service.py "$@"\n')
 (root/'child.sh').write_text('#!/bin/sh\npython /service.py "$@" &\nwait $!\n')
 (root/'Dockerfile').write_text(f'FROM {BASE}\nCOPY args.py service.py exec.sh child.sh /\nRUN chmod +x /exec.sh /child.sh\nENV DEMO=expanded\nENTRYPOINT ["python", "/args.py"]\nCMD ["default", "$DEMO"]\n')
 docker('build','--network','none','-t',tag,str(root))
 assert json.loads(docker('run','--rm','--network','none',tag).stdout)==['default','$DEMO']
 assert json.loads(docker('run','--rm','--network','none',tag,'changed').stdout)==['changed']
 assert docker('run','--rm','--network','none','--entrypoint','python',tag,'-c','print("override")').stdout.strip()=='override'
 assert docker('run','--rm','--network','none','--entrypoint','/bin/sh',tag,'-c','printf "%s" "$DEMO"').stdout=='expanded'
 print('CMD supplies literal default arguments; trailing arguments replace it; --entrypoint replaces the executable')
 for container,wrapper in zip(containers,['/exec.sh','/child.sh']):
 docker('run','-d','--name',container,'--network','none','--entrypoint',wrapper,tag)
 deadline=time.monotonic()+10
 while time.monotonic()<deadline:
 logs=docker('logs',container).stdout
 if logs.strip():break
 time.sleep(.05)
 else:raise AssertionError('service did not become ready')
 pid=json.loads(logs.splitlines()[0])['pid']
 assert (pid==1)==(wrapper=='/exec.sh')
 docker('stop','--time','1',container)
 state=inspect(container)['State'];logs=docker('logs',container).stdout
 if wrapper=='/exec.sh':assert state['ExitCode']==0 and 'stopped' in logs
 else:assert state['ExitCode']==137 and 'stopped' not in logs
 print('exec makes the handler PID 1 and stops cleanly; the non-forwarding shell wrapper leaves its child unnotified until forced termination')
finally:
 docker('rm','-f',*containers,check=False);docker('image','rm',tag,check=False)

第一部分让镜像命令打印收到的参数列表。不加覆盖时，它收到 default 和字面的 $DEMO，尽管镜像把 DEMO 定义为 expanded。在镜像名后提供 changed，会替换两个默认参数，程序最终只收到一个参数。这些断言检查实际参数向量，避免仅凭 Dockerfile 的外观推测启动结果。

使用 --entrypoint python 并提供明确的 Python 参数，可以运行另一条命令，输出 override。显式调用 /bin/sh -c 则会展开 $DEMO，输出 expanded。两组结果共同说明 ENTRYPOINT 可以被覆盖，也说明变量展开属于被调用的 shell，而不是 exec 形式内部隐藏的自动处理步骤。

第二部分比较两个启动同一服务的包装脚本。exec 版本用 Python 替换自身，服务报告容器内 PID 为一。Docker 停止容器时，已安装的 SIGTERM 处理函数打印 stopped，随后以零状态退出。实验同时核对日志消息和退出码，证明信号实际到达了服务，并走过被设计的结束路径。

另一个包装脚本把 Python 作为子进程启动，自己等待，却不转发信号。服务报告的 PID 不是一。使用一秒停止超时后，本次环境记录退出码 137，服务也没有打印 stopped。这里直接观察了强制终止结果，不是仅仅因为看到 shell 脚本存在，就断言服务一定无法优雅停止；具体包装方式和处理规则才决定行为。

Linux PID 命名空间中的 PID 一具有特殊的信号和子进程回收责任。exec 包装脚本可以让服务成为信号接收者，但不会自动实现应用清理、排空在途工作，或回收任意后代进程。服务仍需要合适的行为；如果其进程模型需要初始化或监督机制，应明确选择并测试，而不是认为写上 exec 就完成全部退出设计。

把启动和停止视为同一个接口

exec 形式应使用有效 JSON 数组和双引号字符串。明确可执行程序及稳定参数，并说明调用方如何替换默认值。如果初始化必须使用 shell 包装，而包装脚本最后要把控制权交给单个前台服务，就用适当的 exec 完成交接。转发参数时保留引号，避免原来的参数边界在脚本中再次被拆分。

测试真实部署入口，包括编排配置提供的覆盖。正确的镜像入口可能被配置替换成另一层 shell，覆盖命令也可能遗漏必要初始化。应检查实际进程树，并在具有代表性的活动工作下执行终止验证。只测试一个立即退出的打印命令，无法证明长时间运行服务的停止路径正确。

按照服务契约选择停止信号和宽限时间，分别记录就绪、清理成功和退出状态。容器经过 SIGKILL 最终消失，确实说明它已经停止，但单凭这个观察，不能证明请求完成或缓冲状态被安全处理。只有对应业务结束条件的证据，才能支持“优雅退出已经通过”的结论。

来源

Dockerfile ENTRYPOINT and CMD，exec 与 shell 形式、参数组合以及入口覆盖，已核验 2026-09-12。
Docker container stop，停止信号、等待超时与强制终止，已核验 2026-09-12。
pid_namespaces(7)，命名空间初始进程的信号规则及成员终止，已核验 2026-09-12。

后续镜像层删除文件，并不会擦除先前层的原始字节

Mon, 16 Aug 2027 00:00:00 +0000

容器镜像层描述按顺序应用的文件系统变化。一层可以新增或替换文件，也可以记录某个先前路径应从合并文件系统中消失。普通容器进程看到的是最终合并视图，但这个视图不等于随镜像分发的全部字节历史。因此，仅检查运行中的容器，可能遗漏早期层仍然保留的数据，尤其容易误判删除操作的实际效果。

坏掉的样子

把凭据复制进镜像，再通过后续 RUN 删除，不会从早期不可变层中移除凭据。能够取得相关层的人，仍可能恢复原始字节。同样，把很大的构建压缩包放进某层，再在下一条指令里删除，最终路径虽然不存在，分发内容仍可能包含整个压缩包。目录看起来干净，并不能证明镜像已经没有这份数据。

镜像层是文件系统变更集，不一定是紧凑的二进制差分。替换大文件，可能把替换后的完整内容放入另一层。删除通过 whiteout 标记，在应用层时屏蔽原有路径。OCI 还规定了隐藏下层目录内容的不透明目录规则，所以不能把正确应用镜像层简化成反复普通解压 tar；删除和覆盖语义需要被专门处理。

不是每条 Dockerfile 指令都会创建文件系统层。ENV、LABEL 和 CMD 改变镜像配置，可以产生标记为 empty_layer 的历史条目。因此，Dockerfile 行数、构建历史条目数，都不能可靠地替代根文件系统层数。即使没有增加应用文件字节，这些配置变化仍然影响执行方式和产物身份，不应被当成无关信息。

快速验证

使用 Python、Docker 构建器和固定摘要的基础镜像运行脚本。实测为 Docker 29.3.1，采用 containerd 镜像存储，基础镜像内为 Linux arm64 的 Python 3.11.16。标记内容特意设为公开文本。脚本构建并保存一个临时镜像，直接读取归档成员，不把归档解压到宿主文件系统，结束时删除自己的标签：

from pathlib import Path
from tempfile import TemporaryDirectory
import json,subprocess,tarfile,uuid

BASE='python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84'
def docker(*args,check=True):
 result=subprocess.run(["docker",*args],capture_output=True,text=True,timeout=120)
 if check:assert result.returncode==0,result.stderr
 return result
def inspect(image):return json.loads(docker("image","inspect",image).stdout)[0]

name='xbcatm-whiteout-'+uuid.uuid4().hex[:10];tag=name+':probe';marker=b'PUBLIC_DEMONSTRATION_BYTES\n'
try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);(root/'original.txt').write_bytes(marker)
 (root/'Dockerfile').write_text(f'FROM {BASE}\nCOPY original.txt /demo/original.txt\nRUN rm /demo/original.txt\nENV EXAMPLE_MODE=demo\nLABEL example.purpose="public fixture"\nCMD ["python", "-c", "from pathlib import Path;assert not Path(\'/demo/original.txt\').exists();print(\'absent\')"]\n')
 docker('build','--network','none','-t',tag,str(root))
 assert docker('run','--rm','--network','none',tag).stdout.strip()=='absent'
 archive=root/'image.tar';docker('image','save','-o',str(archive),tag)
 with tarfile.open(archive) as outer:
 manifests=json.load(outer.extractfile('manifest.json'));assert len(manifests)==1
 manifest=manifests[0];config=json.load(outer.extractfile(manifest['Config']))
 assert len(manifest['Layers'])==len(config['rootfs']['diff_ids'])
 assert len(manifest['Layers'])==len(inspect(BASE)['RootFS']['Layers'])+2
 found_data=False;found_whiteout=False
 for layer in manifest['Layers'][-2:]:
 with tarfile.open(fileobj=outer.extractfile(layer),mode='r:*') as contents:
 for entry in contents:
 path=entry.name.removeprefix('./')
 if path=='demo/original.txt':found_data=contents.extractfile(entry).read()==marker
 if path=='demo/.wh.original.txt':found_whiteout=True
 assert found_data and found_whiteout
 assert all(item.get('empty_layer') for item in config['history'][-3:])
 print('the final container hides the removed file, but the older layer still contains the exact public marker')
 print('the deletion layer contains a whiteout; ENV, LABEL and CMD add metadata history without filesystem layers')
finally:docker('image','rm',tag,check=False)

Dockerfile 先把 original.txt 复制到 /demo，再在后续 RUN 删除。容器默认命令断言路径不存在，并输出 absent。这验证最终运行视图，却不能证明镜像归档里也没有对应字节，所以实验接下来单独检查保存后的表示。把两个观察拆开，是避免将“看不见”误判为“没有保存”的关键。

归档的 manifest.json 指明配置文件和有序层文件。脚本读取配置中的 rootfs.diff_ids，检查文件系统层数量与清单一致，再读取最后两个层归档。在这个特定构建中，它们分别对应 COPY 新增与后续删除。实验依赖的是保存产物的实际清单，而不是猜测某个长哈希文件名一定属于哪条指令。

新增层仍包含完全相同的 PUBLIC_DEMONSTRATION_BYTES 标记。删除层则包含 demo/.wh.original.txt，指示应用层时隐藏下层文件，而不是原地编辑那个旧层。这两个事实都有直接断言，因此不能把容器中文件缺失当作安全擦除证据。真实凭据若曾进入分发层，之后删除路径并不能撤销已经发生的暴露。

配置历史的最后三条分别对应 ENV、LABEL 和 CMD，并被标记为不产生文件系统层。相对于基础镜像，本次只增加两个文件系统层，而不是五个。这为“每条 Dockerfile 指令必然追加文件系统差分”的说法提供了明确反例，同时保留配置历史和文件系统内容之间的关系，便于解释 inspect 与 history 为什么计数不同。

归档表示和运行时存储是不同接口。这里检查的是实测 Docker 版本生成的 image-save 格式，以及 OCI 变更集语义。实验没有假定快照存储内部也必须用同样可见的 .wh. 文件名保存删除标记，也没有测量某台宿主实际分配了多少磁盘块。内部实现细节不能仅凭归档内容反推。

在字节进入镜像之前排除无用内容

选择合适的构建上下文和忽略规则，避免无关文件进入 COPY 输入。构建凭据通过构建器的密钥机制传递，并确保命令没有把凭据写入保留输出。如果真实凭据已经进入发布层，需要轮换并处理已有副本；补一个删除层不是完整修复，因为旧字节可能仍在仓库、缓存或此前下载者手里。

只在某次操作期间需要的软件包索引或临时归档，应在同一次构建操作中创建并删除。独立最终阶段可以只复制必要运行产物，而不继承构建阶段的文件系统层。不过，仍要检查导出的缓存和复制输出，因为早期构建材料可能留在构建器，或者经另一种导出路径传播。多阶段结构不会自动证明所有输入都已保密。

最终应根据真实产物和运行依赖判断结果。层数更少，本身不能保证下载更小、启动更快或内容更安全。真正需要回答的是：哪些字节随产物分发，哪些路径在运行时可见，以及每一份保留文件是否具有必要用途。这样才能把空间优化、运行正确性与敏感内容处理放在各自准确的证据上。

来源

OCI filesystem layer changesets 1.1.1，文件新增、修改、删除及 whiteout 应用规则，已核验 2026-09-12。
OCI image configuration 1.1.1，根文件系统 DiffID 与不产生文件层的历史条目，已核验 2026-09-12。
Dockerfile reference，COPY、RUN、ENV、LABEL 和 CMD 的行为，已核验 2026-09-12。

固定基础镜像只固定一个输入，完整发布还需要其他记录

Fri, 30 Apr 2027 00:00:00 +0000

按摘要固定容器基础镜像，可以选择确定的镜像对象，避免依赖会移动的标签。这消除了一类意外构建变化，但不会让所有派生镜像或运行实例都完全相同。应用源码、构建参数、下载依赖、目标平台、运行配置和持久数据，仍可能改变构建结果及其行为。因此，基础镜像不可变是一个明确的输入约束，不是完整发布已经可复现的证明。

坏掉的样子

两个 Dockerfile 可以使用相同 FROM 摘要，却生成不同应用。即使 Dockerfile 一样，构建参数变化或未固定的下载取得新内容，也可能改变输出。所以，仅声明基础镜像不可变，无法证明完整构建是确定性的。决定这个性质的是全部输入，以及施加在输入上的转换过程；遗漏任何真正影响结果的部分，都会留下解释缺口。

完全相同的应用镜像，在不同环境变量下运行，也可能选择不同端点、功能行为或存储。可写绑定挂载还能替换镜像内已经测试过的文件。把配置留在镜像外通常有价值，但只要配置参与定义发布行为，它仍然需要版本管理和审阅。外置不等于无须控制，更不意味着配置变化不会影响同一镜像的实际表现。

普通容器还拥有可写文件系统层。紧急编辑可以改变一个实例，而镜像和其他实例保持原样。之后从未修改的镜像替换实例，编辑就会消失。因此，不可变部署实践需要把产物替换与受控运行状态结合起来；只在 FROM 后写摘要，无法自动强制团队遵守这种操作方式，也无法阻止容器内手工修补。

快速验证

使用宿主 Python、Docker 构建器和已取得的固定基础镜像运行脚本。此前记录的实测环境为 Docker 29.3.1、Linux arm64，镜像内 Python 3.11.16；本轮没有重跑 Docker。容器网络与构建 RUN 网络被关闭，但镜像解析仍可能访问仓库；构建步骤没有下载软件包。实验结束删除自己的临时容器和标签，不修改任何既有服务，以便把观察限定在明确的受控输入上：

from pathlib import Path
from tempfile import TemporaryDirectory
import json,subprocess,uuid

BASE='python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84'
def docker(*args,check=True):
 result=subprocess.run(['docker',*args],capture_output=True,text=True,timeout=120)
 if check:assert result.returncode==0,result.stderr
 return result
def inspect(image):return json.loads(docker('image','inspect',image).stdout)[0]

name='xbcatm-pinning-'+uuid.uuid4().hex[:10];tags=[name+':one',name+':two'];container=name+'-running'
try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory)
 (root/'Dockerfile').write_text(f'FROM {BASE}\nARG MESSAGE\nRUN printf "%s" "$MESSAGE" > /built-message\nENV MODE=default\nCOPY app.py /app.py\nCMD ["python", "/app.py"]\n')
 (root/'app.py').write_text('from pathlib import Path\nimport os\nprint(Path("/built-message").read_text(),os.environ["MODE"])\n')
 layers=inspect(BASE)['RootFS']['Layers']
 for tag,message in zip(tags,['one','two']):
 docker('build','--network','none','--build-arg','MESSAGE='+message,'-t',tag,str(root))
 assert inspect(tag)['RootFS']['Layers'][:len(layers)]==layers
 assert inspect(tags[0])['Id']!=inspect(tags[1])['Id']
 assert docker('run','--rm','--network','none',tags[0]).stdout.strip()=='one default'
 assert docker('run','--rm','--network','none',tags[1]).stdout.strip()=='two default'
 assert docker('run','--rm','--network','none','-e','MODE=changed',tags[0]).stdout.strip()=='one changed'
 print('both builds use the same pinned base layers; different build arguments produce different artifacts')
 print('the identical application image behaves differently when runtime configuration changes')
 docker('run','-d','--name',container,'--network','none',tags[0],'python','-c','import time;time.sleep(60)')
 docker('exec',container,'python','-c','from pathlib import Path;Path("/built-message").write_text("edited")')
 assert docker('exec',container,'python','/app.py').stdout.strip()=='edited default'
 assert docker('run','--rm','--network','none',tags[0]).stdout.strip()=='one default'
 failed=docker('run','--rm','--network','none','--read-only',tags[0],'python','-c','from pathlib import Path;Path("/built-message").write_text("edited")',check=False)
 assert failed.returncode!=0 and 'Read-only file system' in failed.stderr
 print('a writable container can drift while its image stays unchanged; a read-only root rejects that particular write')
finally:
 docker('rm','-f',container,check=False);docker('image','rm',*tags,check=False)

两次构建使用相同基础引用和应用源码，选择的构建差异只有 MESSAGE；Dockerfile 把它写入 /built-message。第一份镜像输出 one default，第二份输出 two default。完整镜像身份不同，但检查确认它们有序的基础文件系统层前缀完全一致。这里同时对照了公共输入和最终行为，避免把基础相同误当成全部相同。

这组结果证明的范围很明确：基础没有变化，但另一项显式输入改变了派生产物。它没有试图证明所有输入固定时，多次构建必然逐字节相同。要验证后者，还需要控制时间戳、依赖获取、工具链行为，以及构建器生成的元数据。不能把一次相同基础层检查扩展成未经执行的完整可复现构建结论。

接着，第一份应用镜像覆盖 MODE 为 changed，没有重新构建，却输出 one changed。这把产物身份与发布配置分开。仓库摘要可以标识应用字节，但不能单独告诉事故调查者，当时用了哪些环境值、凭据、挂载配置或外部服务。对于影响行为的输入，发布记录必须补上相应身份和管理位置。

随后，脚本从第一份镜像启动一个长时间运行容器，并修改其中的消息文件。该容器内应用输出 edited default，从未改变的镜像新建容器则仍输出 one default。修补只存在于被编辑实例的可写状态，不会自动进入替换实例。这个差异解释了为什么只修线上容器、没有生成新产物，会让相同故障在重建后再次出现。

最后，启用只读根文件系统，尝试相同编辑，会得到只读文件系统错误。这证明该镜像路径受到一个实际有效的写入限制，而不是证明所有运行状态都已冻结。显式可写挂载、外部数据库、环境设置和宿主内核，仍是独立的执行环境组成部分，需要按各自契约控制，不能从一次写入失败推断全部不可变。

记录发布，再替换对应实例

发布记录应连接经过测试的应用摘要、目标平台、配置修订和数据兼容要求。OCI 索引可以包含多个平台的清单，因此固定索引后，运行时仍会选择平台镜像。架构影响复现或诊断时，应记录实际选择，而不只记录一个跨平台索引摘要。这样，同一发布名字下的不同执行环境才有可追踪的解释。

需要的变更应进入新产物，经验证后通过部署机制替换实例。持久数据使用具有独立生命周期和恢复计划的存储，不要把容器可写层当成唯一持久副本，也不要在宣称属于同一固定发布的实例背后，悄悄修改共享配置。应用产物、数据和配置分别受控，才能让替换行为真正可预测。

固定摘要还意味着新的基础修复不会自动到来。需要持续跟踪更新、审阅新摘要、重建依赖应用，并在提升前测试。保留已知输入很有价值，但永远保留过期输入，不等于维护安全发布。固定与更新不是互相排斥，而是要求每次更新成为明确、可审阅的变更。

调查漂移时，分别比较产物、配置、挂载和运行时修改，因为它们有不同的负责人和证据来源。用可审阅发布替代随手修改实例，可以让差异变得可解释，同时承认相同镜像字节并不意味着外部状态相同，也不保证在所有负载下表现完全一样。这是控制边界，而不是夸大不可变镜像的能力。

来源

Docker build best practices，基础镜像摘要固定与主动更新流程，已核验 2026-10-15。
Docker container run，运行环境覆盖与可写或只读文件系统，已核验 2026-10-15。
The Twelve-Factor App: build, release, run，区分构建产物、发布配置与执行，已核验 2026-10-15。
OCI image index 1.1.1，镜像索引中的平台选择，已核验 2026-10-15。
Docker container run reference，只读根文件系统与单独可写卷，已核验 2026-10-15。
Docker build networking，–network 为 RUN 指令选择网络模式，已核验 2026-10-15。

普通初始化容器建立启动前置条件

Sun, 03 Jan 2027 00:00:00 +0000

普通 init container 在 Pod 的应用容器启动之前执行准备工作。它有自己的命令、镜像和文件系统视图，也可以挂载应用稍后读取的共享卷。这让前置步骤与主进程分开，但不意味着任意初始化操作都会自动安全，也不意味着重试默认存在固定次数上限。应根据真实重试方式及产物生命周期设计这个步骤，而不是把启动顺序当成完整容错机制。

顺序约束只属于一个 Pod

Kubelet 按声明顺序运行普通初始化容器。每一步必须成功结束，下一步才开始，应用容器则等待整个序列完成。检查 initContainerStatuses，才能区分正在等待的步骤、运行中的步骤和已经终止的某次尝试。仅查看 Pod 的阶段，无法说明哪条命令失败，也无法说明新的尝试是否正在进行；排查需要结合具体容器状态和日志。

共享存储需要显式挂载。emptyDir 可以在初始化容器与应用容器之间传递生成文件，并在同一 Pod 内的容器重启期间保留，但会随着 Pod 消失。不同容器不会自动共享镜像根文件系统，只写在初始化容器可写层中的文件，不会自然出现在应用容器里面。产物的写入位置和读取位置必须通过真实卷定义对应起来。

普通初始化容器需要运行到完成。Kubernetes 也支持在 initContainers 中通过容器级 restartPolicy Always 表示可重启边车，它们具有不同生命周期。因此，不能仅因为某个条目位于这个字段，就认定它必须退出后应用才能继续。本例只使用普通初始化容器，不把持续运行的边车混进顺序完成模型。

坏掉的样子

非零退出并不总会让整个 Pod 立即失败。在普通应用 Pod 采用 Always 策略时，失败的普通初始化容器会继续重试，直到成功；已经成功的初始化步骤则不会因为应用仍在运行就不断重启。退避会放慢连续尝试，却不是固定的重试次数限制。如果 Pod 的 restartPolicy 为 Never，初始化失败会使该 Pod 进入失败状态，恢复方式需要另行安排。

准备脚本应能够安全面对前一次留下的内容。中断的下载可能留下半个文件，emptyDir 中的标记也可能在失败进程退出后继续存在。应验证完整产物，再明确交付给消费者。下面用于记录次数的计数器只是诊断数据，不能作为生产逻辑，推断某个外部依赖在第二次尝试时就必然可用。真实条件必须由对应检查来判断。

一个 Pod 内的顺序并不会把整组副本串行化。把数据库迁移放进每个副本的初始化流程，仍可能让多份迁移同时执行。应遵循迁移系统真实的锁与兼容性契约。只等待一次数据库，也不能保证初始化之后数据库持续可达；应用后续请求处理和就绪判断仍需要独立设计，不能依靠先前某次成功永久推导健康。

初始化同样影响资源放置。对于普通初始化容器，调度需要比较初始化期间的峰值需求与应用容器的汇总需求，并按适用规则计入额外开销。即使长期运行的应用很小，短暂准备步骤提出过大的请求，也可能导致 Pod 无法调度。边车及 Pod 级资源功能还有自己的计算规则，不能把简化公式无条件套用到所有清单。

快速验证

准备可丢弃的 Kubernetes 集群，确保 kubectl 可访问，节点可以使用 python:3.11-slim-bookworm 镜像。保存为 init-order.py，执行 python3 init-order.py KUBECONFIG_PATH CONTEXT，明确传入测试配置路径与上下文。账号需要创建、删除命名空间的权限。原文记录的服务端为 Kubernetes 1.34.11，本轮没有重新执行集群实验；应为一次失败初始化及其重试预留时间。

import json
import subprocess
import sys
import time
from uuid import uuid4

assert len(sys.argv) == 3, 'usage: python3 example.py DISPOSABLE_KUBECONFIG CONTEXT'
base = ['kubectl', '--kubeconfig', sys.argv[1], '--context', sys.argv[2], '--request-timeout=30s']
image = 'python:3.11-slim-bookworm'


def k(*args, payload=None, expected=0):
 result = subprocess.run(base + list(args), input=json.dumps(payload) if payload is not None else None,
 capture_output=True, text=True, timeout=150)
 if expected is not None:
 assert result.returncode == expected, result.stderr
 return result


def obj(namespace, kind, name=None, selector=None):
 args = ['get', kind, '-n', namespace, '-o', 'json']
 if name:
 args.append(name)
 if selector:
 args += ['-l', selector]
 return json.loads(k(*args).stdout)


def apply(namespace, data):
 return k('apply', '-n', namespace, '-f', '-', payload=data)


def wait_for(read, ready, seconds=120):
 until = time.monotonic() + seconds
 while time.monotonic() < until:
 value = read()
 if ready(value):
 return value
 time.sleep(0.5)
 raise AssertionError('expected Kubernetes condition did not arrive')


def pod_ready(pod):
 return any(c['type'] == 'Ready' and c['status'] == 'True'
 for c in pod.get('status', {}).get('conditions', []))


def spec(script='import time; time.sleep(600)'):
 return {'automountServiceAccountToken': False, 'terminationGracePeriodSeconds': 1,
 'containers': [{'name': 'app', 'image': image, 'imagePullPolicy': 'IfNotPresent',
 'command': ['python3', '-c', script],
 'resources': {'requests': {'cpu': '10m', 'memory': '24Mi'},
 'limits': {'cpu': '200m', 'memory': '96Mi'}}}]}

namespace = 'notes-init-' + uuid4().hex[:8]
k('create', 'namespace', namespace)
try:
 prepare = r'''from pathlib import Path
import sys,time
root=Path('/work'); counter=root/'attempts'
attempt=int(counter.read_text())+1 if counter.exists() else 1
counter.write_text(str(attempt))
with (root/'order').open('a') as f: f.write('prepare'+str(attempt)+'\n')
if attempt == 1: sys.exit(7)
print('waiting for release',flush=True)
while not (root/'go').exists(): time.sleep(0.1)
(root/'input').write_text('ready')
'''
 transform = r'''from pathlib import Path
root=Path('/work'); assert (root/'input').read_text()=='ready'
(root/'output').write_text('READY')
with (root/'order').open('a') as f: f.write('transform\n')
'''
 main = r'''from pathlib import Path
import json,time
root=Path('/work'); assert (root/'output').read_text()=='READY'
with (root/'order').open('a') as f: f.write('app\n')
print(json.dumps({'order':(root/'order').read_text().splitlines(),
 'artifact':(root/'output').read_text()}),flush=True)
time.sleep(600)
'''
 podspec = spec(main)
 mount = [{'name': 'work', 'mountPath': '/work'}]
 podspec['volumes'] = [{'name': 'work', 'emptyDir': {}}]
 podspec['containers'][0]['volumeMounts'] = mount
 podspec['initContainers'] = []
 for name, script in [('prepare', prepare), ('transform', transform)]:
 container = spec(script)['containers'][0]
 container['name'] = name
 container['volumeMounts'] = mount
 podspec['initContainers'].append(container)
 apply(namespace, {'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': 'ordered'}, 'spec': podspec})
 def retry_running(p):
 statuses = p.get('status', {}).get('initContainerStatuses', [])
 return statuses and statuses[0]['restartCount'] >= 1 and 'running' in statuses[0]['state']
 waiting = wait_for(lambda: obj(namespace, 'pod', 'ordered'), retry_running)
 first = waiting['status']['initContainerStatuses'][0]
 assert first['lastState']['terminated']['exitCode'] == 7
 assert waiting['status']['phase'] == 'Pending'
 assert all('running' not in c['state'] for c in waiting['status'].get('containerStatuses', []))
 assert 'running' not in waiting['status']['initContainerStatuses'][1]['state']
 k('exec', '-n', namespace, 'ordered', '-c', 'prepare', '--', 'python3', '-c',
 'from pathlib import Path; Path("/work/go").touch()')
 ready = wait_for(lambda: obj(namespace, 'pod', 'ordered'), pod_ready)
 assert ready['metadata']['uid'] == waiting['metadata']['uid']
 output = wait_for(lambda: k('logs', '-n', namespace, 'ordered', '-c', 'app').stdout.strip(), bool)
 observed = json.loads(output)
 assert observed == {'order': ['prepare1', 'prepare2', 'transform', 'app'], 'artifact': 'READY'}
 assert ready['status']['initContainerStatuses'][0]['restartCount'] == 1
 assert all(c['state']['terminated']['exitCode'] == 0 for c in ready['status']['initContainerStatuses'])
 never = spec()
 never['restartPolicy'] = 'Never'
 failed_init = spec('raise SystemExit(7)')['containers'][0]
 failed_init['name'] = 'fails'
 never['initContainers'] = [failed_init]
 apply(namespace, {'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': 'never'}, 'spec': never})
 failed = wait_for(lambda: obj(namespace, 'pod', 'never'), lambda p: p.get('status', {}).get('phase') == 'Failed')
 status = failed['status']['initContainerStatuses'][0]
 assert status['restartCount'] == 0 and status['state']['terminated']['exitCode'] == 7
 assert not any('running' in c['state'] for c in failed['status'].get('containerStatuses', []))
 print(json.dumps({'ordered_artifact': observed, 'retried_init_count': 1,
 'app_waited_for_both_regular_init_containers': True,
 'never_policy_failed_pod_without_retry': True}))
finally:
 k('delete', 'namespace', namespace, '--wait=true', '--timeout=90s')

准备容器记录第一次尝试并以退出码七结束。第二次尝试等待一个放行文件，脚本在此时确认 Pod 仍为 Pending、上一次失败已记录，而且后续初始化步骤与应用都没有运行。然后通过这个容器的共享卷放行准备过程。这个暂停点提供直接状态证据，而不是根据最终日志猜测应用曾经等待。

第二个初始化容器把 ready 转成 READY，应用随后校验产物。日志中的顺序为 prepare1、prepare2、transform、app，第一个初始化容器的重启次数为一。另一个采用 Never 策略的 Pod 初始化失败后进入 Failed，没有重试。原文报告全部断言通过，命名空间清理了两个 Pod；这里保留历史执行归属，不表示本轮独立重现。实验验证的是本地顺序、共享产物及失败策略，没有证明分布式迁移安全，也没有提供持久化存储保障。

来源

Kubernetes: Init Containers，普通初始化容器的顺序、重试、资源计算与可重复执行，已核验 2026-10-15。
Kubernetes: Pod Lifecycle，Pod 阶段、容器状态与重启策略，已核验 2026-10-15。

容器把进程隔离机制与共享 Linux 内核结合起来

Mon, 07 Dec 2026 00:00:00 +0000

常规 Linux 容器通过守护进程所在宿主的 Linux 内核运行进程，并利用命名空间提供选定的隔离视图。镜像文件提供用户态环境，不会给每个容器单独启动一个内核。在 macOS 的 Docker Desktop 中，守护进程和 Linux 容器位于 Linux 虚拟机里，所以容器共享的是该虚拟机内核，而不是 macOS 内核。讨论“宿主”时必须说清楚这一层。

坏掉的样子

假定每个容器都有独立操作系统内核，会导致错误诊断。如果守护进程所在 Linux 环境缺少某个内核能力，仅换成包含另一发行版用户态文件的镜像，并不会让该能力出现。反过来，升级镜像内的软件包，也不会升级宿主内核。这个区别影响系统调用、内核模块、安全边界和资源统计，不能用容器里显示的发行版名字代替判断。

命名空间隔离可以配置，不是每次部署都完全相同的固定组合。容器可以加入其他网络命名空间、使用宿主网络、共享卷，或者采用不同的用户命名空间映射。看到容器内 UID 为零，也不能直接判断容器外权限；必须结合能力集合、用户映射、安全策略和暴露资源分析。一个数字或名称不足以描述完整安全边界。

localhost 也是常见误区。在独立网络命名空间下，127.0.0.1 指向调用容器自己的回环空间，不会自动到达兄弟服务或开发者电脑。同样，在一个普通容器的可写层创建文件，不会自动出现在使用同一镜像的另一个容器里。排查访问失败时，应先分清地址和文件究竟属于哪一个视图。

快速验证

取得固定的 Python 镜像后，使用宿主 Python 和 Docker 守护进程运行脚本。实测 Docker 为 29.3.1，Docker Desktop 虚拟机内 Linux 为 6.12.76，镜像内 Python 为 arm64 的 3.11.16。两个容器使用相同镜像、不同主机名，并设置无外部网络。结束时只删除这两个临时容器：

import json,subprocess,uuid

BASE='python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84'
def docker(*args,check=True):
 result=subprocess.run(['docker',*args],text=True,capture_output=True,timeout=120)
 if check:assert result.returncode==0,result.stderr
 return result
def inspect(name):return json.loads(docker('inspect',name).stdout)[0]
def execute(name,code):return docker('exec',name,'python','-c',code).stdout.strip()

name='xbcatm-isolation-'+uuid.uuid4().hex[:10];containers=[name+'-a',name+'-b']
try:
 listener='import socket,time;s=socket.socket();s.bind(("127.0.0.1",18080));s.listen();print("ready",flush=True);time.sleep(120)'
 for container,command in zip(containers,[listener,'import time;time.sleep(120)']):
 docker('run','-d','--name',container,'--hostname',container,'--network','none',BASE,'python','-c',command)
 probe='import json,os;print(json.dumps({"kernel":os.uname().release,"hostname":os.uname().nodename,"uid":os.getuid(),"namespaces":{name:os.readlink("/proc/self/ns/"+name) for name in ["pid","mnt","net","uts","ipc","user"]}}))'
 left,right=[json.loads(execute(container,probe)) for container in containers]
 assert left['kernel']==right['kernel']
 assert left['hostname']!=right['hostname']
 for namespace in ['pid','mnt','net','uts','ipc']:assert left['namespaces'][namespace]!=right['namespaces'][namespace]
 assert inspect(containers[0])['State']['Pid']!=inspect(containers[1])['State']['Pid']
 for container in containers:assert 'python' in execute(container,'from pathlib import Path;print(Path("/proc/1/cmdline").read_bytes())')
 execute(containers[0],'from pathlib import Path;Path("/private-marker").write_text("only-a")')
 assert execute(containers[1],'from pathlib import Path;print(Path("/private-marker").exists())')=='False'
 execute(containers[0],'import socket;s=socket.create_connection(("127.0.0.1",18080),timeout=1);s.close()')
 execute(containers[1],'import socket;s=socket.socket();assert s.connect_ex(("127.0.0.1",18080))!=0;s.close();s=socket.socket();s.bind(("127.0.0.1",18080));s.close()')
 print('same daemon-side Linux kernel:',left['kernel'],'with different PID, mount, network, UTS, and IPC namespace identities')
 print('each container sees its own PID 1, hostname, writable file state, and loopback port space')
 print('observed uid values:',left['uid'],right['uid'],'same user namespace:',left['namespaces']['user']==right['namespaces']['user'])
finally:docker('rm','-f',*containers,check=False)

两个容器报告相同 Linux 内核版本，PID、挂载、网络、UTS 和 IPC 命名空间标识却不同，并且各自都在 PID 一看到自己的 Python 进程。Docker 检查返回的守护进程侧进程号也不同。这些观察把容器内视图与同一个守护进程管理的独立进程连接起来；报告的宿主 PID 属于 Linux 环境，不是 macOS 进程编号。

分配的主机名也不同。UTS 命名空间控制这个视图，PID 命名空间控制进程编号可见性，挂载命名空间则控制挂载视图。它们承担不同职责。Linux 还有这里没有比较的命名空间类型，因此实验不能被解释成内核全部命名空间功能的完整清单，更不能把历史上的某个固定数量当成永远不变的事实。

第一个容器写入 /private-marker，第二个容器报告该路径不存在。实验没有挂载共享数据目录，因此差异体现普通容器各自的可写状态。如果给两个容器提供同一可写卷，通过该挂载看到什么，就由共享卷契约决定。隔离结论必须附带挂载条件，不能把有共享资源和没有共享资源的场景混在一起。

第一个容器的监听者接受自身回环端口 18080 上的连接。第二个容器无法连接同样的回环地址和端口，却可以在自己的网络命名空间绑定同一端口号。关闭外部网络没有删除回环网络，而是保留了各自独立的本地网络空间。这解释了为什么“容器内 localhost 能通”不能证明另一个容器也能访问服务。

本次两个进程都以 UID 零运行，并且用户命名空间标识相同。这是对当前守护进程默认配置的实际观察，不是声称 Docker 总会为每个容器创建独立用户命名空间。其他部署可能启用用户映射，或采用不同运行时模型，相关选择都会改变安全分析。正确做法是读取实际配置，而不是把一种安装默认值推广成通用规则。

检查真实配置的边界

诊断访问和隔离时，读取命名空间、挂载、网络、能力与用户设置，不要把容器名字当成某种边界已经成立的证明。资源上限是另一个维度：cgroup 可以限制合计 CPU、内存或任务数量，而命名空间决定视图。拥有隔离的进程空间，本身不会自动附带内存预算，也不会阻止应用消耗未设限的资源。

应用适合时，可以采用一个清晰的主要服务角色，但不要把这项惯例误当成内核强制每个容器只能有一个进程。服务可以启动工作进程，PID 一仍需要正确处理信号和回收子进程。监督方式应符合实际应用模型，而不是为了满足一句简化口号，忽略已有合理的多进程结构。

持久状态需要与数据寿命一致的存储；更强的租户隔离，则需要明确评估运行时和宿主信任模型。容器隔离确实存在，但保证来自真实配置的机制和受到维护的内核，而不是来自“每个镜像里面有一台独立小机器”的想象。明确边界，才能准确解释能力、故障与风险。

来源

namespaces(7)，命名空间类型、隔离视图与命名空间身份，已核验 2026-09-12。
Docker container run，进程、网络、用户与权限设置，已核验 2026-09-12。
pid_namespaces(7)，PID 编号及命名空间初始进程行为，已核验 2026-09-12。

cgroup v2 的不同资源预算有不同失败方式

Tue, 10 Nov 2026 00:00:00 +0000

cgroup v2 用统一层次组织资源控制。一个工作负载的多个进程可以共享合计预算，限制还会沿层次继承，而不是只对某个特定 PID 生效。CPU 带宽、内存用量和任务数量由不同控制器管理，执行方式也不同。读取真实 cgroup 文件和失败计数器，比把所有配置上限都当作同一种“到点就停”更能解释实际行为。

坏掉的样子

cpu.max 按周期限制 CPU 带宽。控制组用完配额后，可运行工作可能被节流，但这不会预留一颗专用处理器，也不保证某个请求延迟。多个线程可以很快消耗共享配额。CPU 权重则影响竞争情况下的相对分配；混淆权重、配额和 CPU 亲和性，会让容量规划建立在错误预期上。

内存上限不会统一把大分配变成可由应用干净处理的错误。到达 memory.max 时，内核可以回收内存；无法降低用量时，可能触发控制组 OOM 机制。某些分配路径还有其他失败方式。memory.high 施加回收压力和节流，本身不会调用 OOM，因此不能把这两个设置解释成同义的硬终止阈值。

任务上限也包括线程，不只是监控面板显示的应用进程数量。达到 pids.max 后，即使 CPU 和内存看似充足，fork 或 clone 仍可能失败。层次限制意味着子组配置更大，也不能简单覆盖祖先更紧的预算。解释可见文件时，需要确认对应路径与控制器委派关系，不能只读取一个数值就断定完整有效上限。

快速验证

先取得固定镜像，再用 Python 和采用 cgroup v2 的 Docker 守护进程运行脚本。实测为 Docker 29.3.1、Linux 6.12.76、Python 3.11.16。所有限制只施加到可丢弃实验容器。脚本执行受限的小规模内存耗尽测试，清理自己的容器，不改变宿主全局 cgroup 设置，也不修改其他服务的预算：

import json,subprocess,uuid

BASE='python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84'
def docker(*args,check=True):
 result=subprocess.run(['docker',*args],text=True,capture_output=True,timeout=120)
 if check:assert result.returncode==0,result.stderr
 return result
def inspect(name):return json.loads(docker('inspect',name).stdout)[0]

name='xbcatm-budgets-'+uuid.uuid4().hex[:10];containers=[name+'-limits',name+'-oom',name+'-killed']
limits_code='''from pathlib import Path
import errno,json,subprocess,time
root=Path('/sys/fs/cgroup')
assert (root/'cgroup.controllers').exists()
quota,period=(root/'cpu.max').read_text().split();assert int(quota)*2==int(period)
assert int((root/'memory.max').read_text())==64*1024*1024
assert int((root/'pids.max').read_text())==12
def stats():return dict(line.split() for line in (root/'cpu.stat').read_text().splitlines())
before=stats();end=time.monotonic()+2
while time.monotonic()<end:pass
after=stats();assert int(after['nr_throttled'])>int(before['nr_throttled'])
children=[]
try:
 while True:
 try:children.append(subprocess.Popen(['sleep','30']))
 except OSError as error:
 assert error.errno==errno.EAGAIN;break
 assert children and int((root/'pids.current').read_text())==12
 assert int(dict(line.split() for line in (root/'pids.events').read_text().splitlines())['max'])>0
 print(json.dumps({'cpu.max':[quota,period],'memory.max':(root/'memory.max').read_text().strip(),'pids.max':12,'children':len(children),'throttled_periods':int(after['nr_throttled'])-int(before['nr_throttled'])}),flush=True)
finally:
 for child in children:child.terminate()
 for child in children:child.wait()
'''
try:
 result=docker('run','--name',containers[0],'--network','none','--cpus','.5','--memory','64m','--memory-swap','64m','--pids-limit','12',BASE,'python','-c',limits_code)
 print(result.stdout.strip())
 oom=docker('run','--name',containers[1],'--network','none','--memory','64m','--memory-swap','64m',BASE,'python','-c','print("allocating",flush=True);data=bytearray(256*1024*1024)',check=False)
 state=inspect(containers[1])['State'];assert oom.returncode==137 and state['OOMKilled'] and state['ExitCode']==137
 docker('run','-d','--name',containers[2],'--network','none',BASE,'python','-c','import time;time.sleep(60)')
 docker('kill','--signal','KILL',containers[2]);docker('wait',containers[2])
 state=inspect(containers[2])['State'];assert state['ExitCode']==137 and not state['OOMKilled']
 print('a 64 MiB memory budget caused actual OOM termination; an explicit SIGKILL also returned 137 but OOMKilled was false')
finally:docker('rm','-f',*containers,check=False)

第一个容器读取到 cpu.max 为 50000 100000，memory.max 为 67,108,864 字节，pids.max 为十二。CPU 数值表示每一百毫秒周期可使用五十毫秒带宽。把 Docker 的内存加交换总上限设为等于内存上限，使实验不能通过交换空间扩大预算；内存测试规模也保持明确而有限。

两秒忙循环让 cpu.stat 中的 nr_throttled 增加。本次增加二十个周期，但断言只要求正增长。这证明实际发生过限制执行，不只是 Docker 接受了配置参数。它并不是基准测试，不能推出所有负载和调度环境都会出现完全相同的墙钟耗时或减速比例。计数器说明作用发生，不等于完整性能模型。

随后，进程持续创建休眠子进程，直到任务创建返回 EAGAIN。本次十一个子进程加上控制 Python 进程达到十二，pids 控制器的拒绝计数也增加。实验会终止并回收子进程。虽然这些子进程大部分时间都不消耗 CPU，仍然占据任务预算，因此“进程都在睡眠”不能解释为什么还应允许继续创建。

另一个容器获得 64 MiB 内存上限，并尝试初始化 256 MiB bytearray。它以状态 137 退出，Docker 同时记录 OOMKilled 为真。这验证了该分配在实测条件下确实触发内存限制失败，但没有声称所有分配都必须产生同一种异常或终止方式。实际失败语义仍与内核路径和应用行为有关。

对照容器被显式发送 SIGKILL，同样以 137 退出，但 OOMKilled 为假。因此，仅凭退出码无法确定 OOM。调查生产事故时，需要把运行时状态、内存事件和系统证据放在一起，尤其当多个监督组件都有权限终止工作负载时。相同最终状态可能来自不同原因，不能用一个数字代替根因定位。

按整个工作负载设限并观测

预算应覆盖应用工作进程及相关计费内存，而不只是某个进程的堆大小估计。页缓存和其他被统计的内存，也可能参与压力。为启动、依赖变化和恢复操作留出合理空间，再以有代表性的并发进行测量。上限过紧，可能先改变延迟或失败率，之后才出现明显崩溃，不能只看有没有 OOM。

同时监控当前用量、压力指标、控制器事件和应用行为。压力信号有助于发现持续竞争，但突发分配可能快于周期告警。监控应帮助解释失败和调整容量，不能承诺每次触限都能提前预知。即使拥有完整面板，也仍需要合理的限制与业务错误处理。

通过拥有工作负载的管理器修改策略，例如 Docker 或 systemd，并在修改后核对实际控制器值。容器内 cgroup 路径可能是命名空间视图，而不是宿主完整层次。正确诊断需要把这个视图、继承约束和真正采取动作的执行机制连接起来，才能知道该改的是配额、应用并发，还是其他祖先限制。

来源

Linux 6.12 cgroup v2 documentation，分层 CPU、内存和任务控制器及其计数器，已核验 2026-09-12。
Docker resource constraints，Docker CPU、内存和交换空间配置，已核验 2026-09-12。
cgroups(7)，控制组成员关系与资源统计语义，已核验 2026-09-12。

多阶段构建需要经过测试的运行边界

Fri, 25 Sep 2026 00:00:00 +0000

多阶段 Dockerfile 可以在一个阶段编译软件，再把选定输出复制到另一个运行阶段。最终阶段继承自己的基础镜像和明确复制的文件，而不会自动继承构建器里的编译器、源码目录和软件包缓存。这建立了有用的边界，但作者仍必须识别程序真正执行时需要的一切。文件复制成功，只能证明文件已进入产物，不能证明运行环境已经完整。

坏掉的样子

即使 ELF 解释器和共享库缺失，COPY 仍可成功把动态链接程序放进 scratch 镜像。构建可能正常结束，因为复制不会执行程序，也不会验证全部运行依赖图。随后启动却可能报告 no such file or directory，尽管配置路径上的可执行文件确实存在。此时需要检查解释器和库，而不是只反复确认程序文件是否被复制。

脚本需要解释器，应用可能需要证书根或时区数据，还有程序只在特定请求路径上加载插件或资源。简单启动测试可能漏掉这些较晚发生的需求。选择小型运行基础镜像，只有在它满足应用真实契约时才有价值，包括受支持架构和必要文件路径。不能因为某个镜像最小，就默认它适合所有应用。

早期阶段不属于最终镜像的继承链，也不意味着它被安全擦除。构建缓存和明确导出的中间镜像，仍可能保留其内容。敏感构建输入需要正确的密钥传递方式，复制输出也必须检查是否意外包含不该分发的材料。多阶段结构控制最终文件系统组成，却不会自动保证整个构建过程的保密性。

快速验证

历史 Docker 示例保持原样；当前没有 Docker 运行环境，因此本次没有重跑。

使用 Python、Docker、固定的 Python 基础镜像，以及供构建阶段安装 Debian 软件包的网络运行脚本。运行容器关闭网络。实测是 Docker 29.3.1、Linux arm64，GCC 为 Debian 12.2.0-14+deb12u1 包提供的 12.2.0。软件仓库是实时仓库，因此实验验证运行组成，不承诺未来永远取得完全相同的编译器字节：

from pathlib import Path
from tempfile import TemporaryDirectory
import json,subprocess,tarfile,uuid

BASE='python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84'
def docker(*args,check=True):
 result=subprocess.run(['docker',*args],capture_output=True,text=True,timeout=360)
 if check:assert result.returncode==0,result.stderr
 return result
def inspect(image):return json.loads(docker('image','inspect',image).stdout)[0]

name='xbcatm-stages-'+uuid.uuid4().hex[:10];tags=[name+':builder',name+':good',name+':bad'];container=name+'-inspect'
try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory)
 (root/'square.c').write_text('#include <stdio.h>\n#include <stdlib.h>\n#include <errno.h>\nint main(int argc,char **argv){\n char *end;long value;\n if(argc!=2){fprintf(stderr,"one integer required\\n");return 2;}\n errno=0;value=strtol(argv[1],&end,10);\n if(errno||end==argv[1]||*end||value<0||value>100){fprintf(stderr,"range 0..100\\n");return 2;}\n printf("%ld\\n",value*value);return 0;\n}\n')
 (root/'Dockerfile').write_text(f'''FROM {BASE} AS builder
RUN apt-get update && apt-get install -y --no-install-recommends gcc libc6-dev && rm -rf /var/lib/apt/lists/*
WORKDIR /source
COPY square.c .
RUN gcc -O2 -Wall -Wextra -Werror -static -o /square-static square.c && gcc -O2 -Wall -Wextra -Werror -o /square-dynamic square.c
FROM scratch AS good
COPY --from=builder /square-static /square
USER 65532:65532
ENTRYPOINT ["/square"]
FROM scratch AS bad
COPY --from=builder /square-dynamic /square
USER 65532:65532
ENTRYPOINT ["/square"]
''')
 for tag,target in zip(tags,['builder','good','bad']):docker('build','--target',target,'-t',tag,str(root))
 print('compiler:',docker('run','--rm','--network','none',tags[0],'gcc','--version').stdout.splitlines()[0])
 for argument,expected in [('0','0'),('7','49'),('100','10000')]:
 assert docker('run','--rm','--network','none',tags[1],argument).stdout.strip()==expected
 for argument in ['7x','-1','101','','999999999999999999999999999']:
 invalid=docker('run','--rm','--network','none',tags[1],argument,check=False)
 assert invalid.returncode==2 and 'range 0..100' in invalid.stderr
 invalid=docker('run','--rm','--network','none',tags[1],check=False)
 assert invalid.returncode==2 and 'one integer required' in invalid.stderr
 invalid=docker('run','--rm','--network','none',tags[1],'7','8',check=False)
 assert invalid.returncode==2 and 'one integer required' in invalid.stderr
 good=inspect(tags[1]);builder=inspect(tags[0]);assert good['Size']<builder['Size'] and len(good['RootFS']['Layers'])==1
 assert good['Config']['User']=='65532:65532'
 docker('create','--name',container,tags[1],'7');archive=root/'rootfs.tar';docker('export','-o',str(archive),container)
 with tarfile.open(archive) as contents:
 names={entry.name.removeprefix('./') for entry in contents}
 assert 'square' in names and 'usr/bin/gcc' not in names and 'source/square.c' not in names
 bad=docker('run','--rm','--network','none',tags[2],'7',check=False)
 assert bad.returncode!=0 and 'no such file or directory' in bad.stderr
 print('the static final image runs valid input, rejects invalid input, and contains one application layer without compiler or source')
 print('recorded image sizes:',builder['Size'],'builder bytes;',good['Size'],'final bytes')
 print('the dynamic scratch image builds successfully but cannot start because its interpreter/runtime was not copied')
finally:
 docker('rm','-f',container,check=False);docker('image','rm',*tags,check=False)

构建阶段把同一个小型 C 程序分别静态链接和动态链接。程序接受一个零到一百范围内的整数，并输出平方。编译开启警告且把警告视为错误。两个有名字的最终目标各自只把对应可执行文件复制到 scratch，并选择数值用户和组 65532。这样，构建工具与运行产物的交接在 Dockerfile 中清楚可见。

静态最终镜像对输入零、七、一百分别输出 0、49、10000。尾随文本、负数、超范围值、空参数，以及超出 strtol 可表示范围的整数，都返回状态二；缺少参数或参数过多也返回状态二。这些检查直接在最终镜像中覆盖合法边界和拒绝路径，而不只测试构建阶段能够运行程序。

镜像检查确认最终产物只有一个文件系统层，并配置了预期的非 root 数值身份。导出一个已创建容器后，可以看到 /square，却没有构建阶段路径下的编译器和源码文件。实验直接读取归档，不把它解压覆盖宿主文件系统。这独立验证最终组成，而不是因为 Dockerfile 看起来简洁，就假定没有多余文件。

既有记录中 Docker 报告构建镜像为 109,490,331 字节，静态最终镜像为 312,508 字节。这些是引擎的镜像大小字段，不是独占物理磁盘分配量，也不是网络传输耗时测量。真正有意义的不变量，是最终镜像排除了工具链，并在相同统计口径下更小。不同存储实现或压缩方式下，不应直接照搬绝对数字。

动态最终目标也能成功构建，但启动时因为未复制解释器及运行库而出现缺失文件错误。这是关键反例，失败是预期且经过断言的结果。它推翻了“最终 COPY 成功后，构建器就会自动提示补齐运行库”的说法。构建系统无法仅根据文件复制，保证应用执行过程中需要的所有资源都已满足。

验证最后阶段真正执行的内容

应选择适合应用的运行镜像。静态链接适合这里的小计算程序，但不证明所有静态服务都不需要外部文件或运行时加载组件。动态应用需要兼容的运行库或合适的运行基础镜像，并在最终产物内执行有代表性的功能。不要只在工具齐全的构建阶段测试，然后把结果直接转移到环境不同的最终阶段。

使用命名阶段和窄范围 COPY，让审阅者清楚看到交接内容。避免复制整个构建目录，悄悄带入测试、凭据、缓存或无用工具。工作目录、可写路径、用户身份和启动参数，都应按真实运行需求设置。最小化文件与维持可诊断、可运行的服务契约，需要一起判断。

依赖或编译器更新后，应重新测试最终阶段，包括错误输入，以及会额外加载资源的不常见路径。把所选产物身份与结果一起保存。镜像变小只有在继续满足服务契约时才是有效结果；构建成功本身无法证明这个契约，更不能替代最终镜像的启动和功能验证。

来源

Docker multi-stage builds，命名阶段、目标选择与选择性复制产物，已核验 2026-09-12。
Dockerfile reference，COPY –from、scratch、USER 与 exec 形式入口，已核验 2026-09-12。
execve(2)，可执行文件解释器缺失及执行错误，已核验 2026-09-12。

容器 · XB 现场笔记

网络命名空间隔离网络资源，名称并不拥有其中所有进程

坏掉的样子

快速验证

分开管理名称、进程归属与通信配置

来源

veth 对在两个端点之间搬运帧，路由决定这些帧承载的路径

坏掉的样子

快速验证

按层次检查实际路径

来源

安全上下文需要运行时证据来验证

把设置放在正确层级

坏掉的样子

快速验证

延伸阅读

来源

签名镜像可以证来源

摘要是身份，标签是指针

对标签签名绑不住任何东西

校验才是控制，签名不是

坏掉的样子

快速验证

来源

ENTRYPOINT 和 CMD 定义可被运行者覆盖的启动默认值

坏掉的样子

快速验证

把启动和停止视为同一个接口

来源

后续镜像层删除文件，并不会擦除先前层的原始字节

坏掉的样子

快速验证

在字节进入镜像之前排除无用内容

来源

固定基础镜像只固定一个输入，完整发布还需要其他记录

坏掉的样子

快速验证

记录发布，再替换对应实例

延伸阅读

来源

普通初始化容器建立启动前置条件

顺序约束只属于一个 Pod

坏掉的样子

快速验证

来源

容器把进程隔离机制与共享 Linux 内核结合起来

坏掉的样子

快速验证

检查真实配置的边界

来源

cgroup v2 的不同资源预算有不同失败方式

坏掉的样子

快速验证

按整个工作负载设限并观测

延伸阅读

来源

多阶段构建需要经过测试的运行边界

坏掉的样子

快速验证

验证最后阶段真正执行的内容

延伸阅读

来源