Question 1

当 macOS 用户名包含点号时，如何修复 Apple container 机器中的 'sudo: a terminal is required to read the password' 错误？

Accepted Answer

出现这种情况是因为 sudo 会静默忽略 `/etc/sudoers.d/` 中任何文件名包含 `.` 的文件,因此以你的 macOS 用户名命名的 NOPASSWD drop-in 文件(例如 `user.name`)永远不会被读取。解决方法:以 root 身份重命名该 drop-in 文件:`container machine run --name --root -- mv /etc/sudoers.d/user.name /etc/sudoers.d/user-name`(将两处名称都替换为你的实际用户名,并去掉文件名中的点号)。之后,`container machine run --name -- sudo apt-get update` 无需密码即可运行。永久修复(在清理 drop-in 文件名的同时在规则中保留真实用户名)已在 PR #2080 中合并,因此将 container CLI 升级到包含该修复的版本即可解决问题,无需手动操作。

Question 2

将 Apple Container CLI 更新到 0.9.0 后，运行 amd64 容器时出现 "rosetta error: unhandled auxillary vector type 29" 错误，如何修复？

Accepted Answer

此错误由 Rosetta 与 Apple Container CLI 0.9.0 默认附带的 Kata 3.25.0 内核（6.18.5-176）之间的兼容性问题引起。该问题影响运行 macOS Sequoia 15.x 的 Apple Silicon 设备；macOS Tahoe 25.x 不受影响，并且通过 Rosetta Updater.app 更新 Rosetta 无法解决该问题。

已验证的解决方法：
1. 运行以下命令切换到兼容的 Kata 3.24.0 内核（6.12.47-173）：
container system kernel set --tar https://github.com/kata-containers/kata-containers/releases/download/3.24.0/kata-static-3.24.0-arm64.tar.zst --binary opt/kata/share/kata-containers/vmlinux-6.12.47-173
2. 临时将 Apple Container CLI 降级至 v0.8.0，该版本使用可正常工作的默认内核。

官方维护人员正在调查根本原因，以便发布补丁版本。

Question 3

为什么 `container system status` 显示 apiserver 未在 macOS Seatbelt 沙盒中运行，尽管它实际上正在运行？

Accepted Answer

这是 `container` CLI 1.2.2 中的一个假阴性（false negative）问题。`container system status` 使用旧的 `launchctl list` 代码路径，而 macOS launchd 将该路径置于 Seatbelt `job-creation` 能力的管控之下。一个仅允许 `mach-lookup` 的 `(deny default)` 沙箱会阻止该调用，因此即使 `container list` 和 `container run` 等命令都能正常工作，CLI 仍会报告 apiserver 已停止。使用以下命令验证实际状态： ```sh launchctl print gui/$(id -u)/com.apple.container.apiserver ``` 退出码 `0` 表示该任务已注册；`113`（`ENOSERVICE`）表示未注册。不要将其他错误视为"apiserver 已停止"。变通方案： - 使用上述命令，或使用可正常工作的命令（如 `container list`）来确认 apiserver 运行正常。 - 如果可以接受，在受限沙箱之外运行该状态命令。 - 不要仅为了一次状态检查而授予 `job-creation`；它是一种任务提交/写入能力。该修复将状态探测改为先检查 apiserver 的健康状况，和/或使用 `launchctl print gui//` 替代 `launchctl list`。请升级到包含 issue #2317 修复的发布版本；如果该修复尚未包含在 Homebrew 发布版本中，则从 `main` 分支构建该项目。

Question 4

如何修复 `container k8s list` 中默认 control-plane 节点的 CLUSTER 值为空的问题？

Accepted Answer

默认的 `container k8s create` 流程会将节点标记为 `control-plane,worker`。旧代码仅在角色标签完全等于 `control-plane` 时才将节点识别为控制平面，因此错误地把该节点当作 worker，并推导出空的集群名称。

请升级到包含 issue #2314 修复的构建版本，或者在 `buildK8sRows(from:)` 中修补 `Sources/ContainerK8s/K8sHelper.swift`，以解析逗号分隔的角色标签：

```swift
let roles = role
    .split(separator: ",")
    .map { $0.trimmingCharacters(in: .whitespaces) }

if roles.contains("control-plane") {
    // Treat the row as a control-plane node.
}
```

重新构建并重新安装 CLI，例如：

```bash
swift build -c release
```

然后运行：

```bash
container k8s list
```

现在，默认节点应显示在集群 `k8s-dev` 下，worker 节点也应与其归为一组。无需重新创建集群，因为该 bug 出在列表行的渲染逻辑中。

Question 5

在 Swift 包中运行 `make all` 或 `swift build` 时，如何修复 "error: no such module 'Testing'" 错误？

Accepted Answer

当某个库 target（如 `ContainerTestSupport`）在测试 target 之外构建，却导入了 Swift 的 `Testing` 模块时，就会出现这种情况。请更新到包含该修复的最新 `main` 分支，或者手动应用修复：从 `Sources/ContainerTestSupport/BuildFixture.swift` 中移除 `import Testing`，并将断言辅助函数改为抛出带有现有失败消息的 `CommandError.executionFailed(...)`，而不再使用 Testing 断言。然后运行 `swift package clean && make all`。仅在实际的测试 target 中保留 `import Testing`。

container

核心功能

避坑指南

适用场景

标签

快速上手

相似推荐