在CentOS 7及以后的版本中，systemd-machined是一个核心系统服务，专门负责管理和注册系统中运行的容器和虚拟机。它通过D-Bus接口与systemd交互，自动发现并追踪本地容器的生命周期，将每个容器注册为一个"machine"对象。运维人员要做的核心工作就是理解它的注册机制、掌握常用管理命令、配置网络桥接以及处理常见故障。下面我直接把这套东西拆开讲透。
systemd-machined到底是什么，为什么要用它
systemd-machined是systemd体系中的一个子组件，它的职责非常明确：把系统上所有的容器（包括Docker容器、LXC容器、libvirt虚拟机等）统一注册到一个集中的管理框架中。你可以把它理解为一个"容器登记处"，每个容器启动时自动来报到，停止时自动注销。它不负责创建容器，只负责追踪和管理已有容器的状态。
在传统运维中，我们要管理容器往往需要分别对接Docker daemon、libvirtd等多个服务，信息分散、监控困难。systemd-machined把这些统一收口，通过machinectl命令就能看到系统上所有已注册的机器（包括物理机本身和各种容器）。对于需要统一监控、统一审计、统一资源管理的运维场景，这是非常实用的基础设施。
CentOS上systemd-machined的安装与启动
CentOS 7及CentOS Stream默认已经内置了systemd-machined，不需要额外安装。但如果你用的是最小化安装，可能需要确认一下。检查方法很简单：
systemctl status systemd-machined
如果显示inactive或者not found，执行以下命令启用：
systemctl enable systemd-machined systemctl start systemd-machined
启动后，用machinectl list命令查看当前已注册的所有machine，你会看到至少有一个".host"条目，那就是本机本身。之后每启动一个容器，这里就会多一条记录。
容器注册的核心机制
systemd-machined的注册机制依赖于容器运行时主动向它发送注册请求。不同的容器运行时有不同的对接方式：
第一种是libvirt管理的KVM/QEMU虚拟机。libvirt在创建虚拟机时会自动调用systemd-machined的注册接口，虚拟机在machinectl list中会以独立machine出现，名称通常是虚拟机名加后缀。
第二种是Docker容器。Docker本身并不直接与systemd-machined集成，但如果你使用systemd作为容器的init进程（即docker run时指定--init或者使用systemd-nspawn创建的容器），那么systemd-machined会自动识别并注册。
第三种是systemd-nspawn直接创建的容器。这是最原生的对接方式，nspawn启动时会自动完成注册，你在machinectl list中能直接看到容器名称和状态。
machinectl常用操作命令详解
作为运维人员，以下命令是日常必须熟练掌握的：
查看所有已注册的machine：
machinectl list
查看某个具体machine的详细信息：
machinectl status <machine-name>
进入某个容器的终端（类似docker exec）：
machinectl login <machine-name>
查看某个容器的资源使用情况：
machinectl show <machine-name>
关闭或终止一个容器：
machinectl poweroff <machine-name> machinectl terminate <machine-name>
poweroff是发送关机信号，terminate是强制杀死。对于生产环境，建议优先使用poweroff，给容器内的进程优雅退出的机会。
网络配置：容器如何获得独立网络
systemd-machined管理的容器默认共享宿主机网络，这在很多场景下不够用。要给容器分配独立网络，需要配置网络桥接。最常用的方式是使用systemd-networkd配合macvlan或veth pair。
创建一个macvlan接口绑定到容器：
[Match] Name=mv-container0 [Network] DHCP=yes
然后在容器的配置文件中（通常在/etc/systemd/nspawn/目录下的.nspawn文件）指定网络接口：
[Network] VirtualEthernet=yes Bridge=br0
这样容器启动后会自动获得一个独立的网络接口，可以分配独立IP，和宿主机网络隔离。对于需要对外提供服务的容器，这种方式比端口映射更干净、更易于管理。
容器资源限制与cgroup集成
systemd-machined天然与cgroup v2集成。每个注册的machine都会有自己独立的cgroup层级，你可以通过systemctl set-property或者直接编辑machine的slice配置来限制资源。
限制某个容器的CPU使用率：
systemctl set-property machine-<name>.slice CPUQuota=50%
限制内存：
systemctl set-property machine-<name>.slice MemoryMax=2G
这些限制是实时生效的，不需要重启容器。对于多租户环境或者需要防止某个容器吃光资源的场景，这是非常关键的运维手段。而且因为是通过systemd统一管理，比单独配置Docker的资源限制更底层、更可靠。
常见故障排查与解决方案
故障一：容器启动了但在machinectl list中看不到。这通常是因为容器运行时没有正确调用注册接口。如果是nspawn容器，检查是否加了--register=yes参数；如果是libvirt虚拟机，确认libvirt版本是否支持machined集成（需要libvirt 1.2.8以上）。
故障二：machinectl login进入容器后无响应。先检查容器内是否运行了getty服务或sshd服务，很多最小化容器镜像默认不启动这些服务。解决办法是在容器内执行：
systemctl enable getty@tty1.service systemctl start getty@tty1.service
故障三：容器网络不通。先用ip link确认veth或macvlan接口是否创建，再用ip addr确认IP是否分配。如果接口存在但没有IP，检查DHCP客户端是否启动，或者手动配置静态IP。
故障四：systemd-machined服务本身挂了。查看日志：
journalctl -u systemd-machined -f
常见原因是D-Bus权限问题或者/var/lib/machines目录权限异常，修复方法通常是重启服务并检查目录权限为755。
生产环境最佳实践建议
第一，不要把systemd-machined当作容器编排工具。它是管理和追踪层，不是调度层。真正的容器编排还是需要Kubernetes或者Docker Swarm。machined适合做底层基础设施的统一管理。
第二，定期清理已停止容器的注册记录。虽然machined会自动注销，但在某些异常情况下（比如容器被强制杀死），可能会残留僵尸记录。用machinectl list确认状态，发现异常及时处理。
第三，做好审计。systemd-machined的所有操作都会记录在journal中，包括谁在什么时候登录了哪个容器、执行了什么操作。这对于安全审计非常有价值，建议保留足够长的日志周期。
第四，配合systemd-journald的远程日志功能，把容器内的日志统一收集到中央日志服务器，避免日志分散在各个容器中难以排查问题。
第五，如果你的CentOS版本较老（比如CentOS 7早期版本），systemd-machined可能存在一些已知bug，建议升级到最新的CentOS 7.9或者迁移到CentOS Stream 8/9，获得更稳定的支持。
总结
systemd-machined是CentOS系统中一个容易被忽视但非常实用的组件。它把容器和虚拟机的管理统一到systemd框架下，提供了简洁的命令行接口、原生的cgroup集成、自动的生命周期追踪。对于运维人员来说，掌握machinectl的使用、理解容器注册机制、配置好网络和资源限制，就能在不引入额外复杂工具的情况下，实现对系统容器的高效管理。这不是什么高深技术，但把它用好，能让你的运维工作干净很多。
