Metal3 + KubeVirtBMC：让 KubeVirt VM 像裸金属一样被 Metal3 管理

Metal3 通过 OpenStack Ironic 实现裸金属主机的全生命周期管理，KubeVirtBMC 则为 KubeVirt VM 提供虚拟 BMC 接口。把两者组合后，Metal3 可以把普通的 KubeVirt 虚拟机当作裸金属服务器来声明、开机、写入镜像，整个流程在同一个 Kubernetes 集群内完成，适用于需要在 CI 环境或测试集群中复现裸金属部署场景的团队。

实现步骤概览
- 前置条件：一套已启用嵌套虚拟化或裸金属的 K8s 集群，安装好 KubeVirt 与存储供给，准备好 kubectl、helm、kustomize。
- 安装 cert‑manager：Metal3 与 KubeVirtBMC 都依赖 webhook 证书。
- 部署 KubeVirtBMC：通过 Helm 安装后，可在 kubevirtbmc-system 命名空间看到 BMC 控制器。
- 创建带 BMC 的 VM：使用 runStrategy: Halted 保持 VM 关闭状态，手动指定 MAC 地址以匹配 BareMetalHost 的 bootMACAddress，并为 BMC 创建凭据 Secret。
- 部署 Metal3（Ironic + BMO）：使用 Ironic Standalone Operator 部署 Ironic，配合 cert‑manager 生成自签 TLS 证书并创建 API 凭据。随后通过 kustomize 部署 Bare Metal Operator。

关键细节

1. BMC 地址：创建好的 VirtualMachineBMC 会生成一个 ClusterIP Service（如 metal3-demo-vm-virtbmc.default.svc.cluster.local），Metal3 通过 IPMI/Redfish 与其通信，完全透明。
2. MAC 匹配：BareMetalHost 必须声明 bootMACAddress，而该 MAC 必须在 VM 的网络接口中显式设置，否则 Metal3 无法识别并会报错。
3. 镜像写入：Metal3 在 Ironic 中创建 Image 资源后，会通过 Redfish 将 ISO 挂载到 VM 的虚拟 CDROM，随后触发 VM 开机完成 OS 安装。
4. 全链路自动化：从创建 PVC、VM、BMC 到 BareMetalHost、Image、Provisioning，全部可写入 GitOps 代码库，实现一次提交全流程自动化。

完成上述配置后，Metal3 会把 KubeVirt VM 当作裸金属主机进行电源控制、镜像写入和状态上报，运维人员无需区分真实硬件与虚拟机，既能在本地集群快速验证裸金属部署脚本，又能在 CI 中复现生产环境的硬件交付流程。

GitHub

#DevOps #运维 #Metal3 #KubeVirtBMC #Ironic #BareMetalHost #Redfish #IPMI #Kubernetes @DevOps实战
@DevOpsTalkCN

在默认命名空间迁移关键服务：零停机的 ExternalName 方案

在集群中，常常会出现一些早期误放在默认命名空间的部署。它们被其他服务频繁调用，若要迁移到专属命名空间，传统做法会导致停机或复杂的多团队协调。
解决思路：先把目标服务（如 auth‑svc）部署到新命名空间，然后把旧 Service 对象改为 ExternalName，指向新地址。这样所有通过 auth‑svc.default.svc.cluster.local 访问的内部流量都会被无缝转发到新位置，外部流量仍通过旧 Ingress 继续工作，直到新 Ingress 验证无误后再删除旧 Ingress。

操作步骤

1. 部署新实例：在 authentication 命名空间创建 auth‑svc。
2. 创建 ExternalName：
```yaml
apiVersion: v1
kind: Service
metadata:
name: auth-svc
namespace: default
spec:
type: ExternalName
externalName: auth-svc.authentication.svc.cluster.local
```
旧 Service 现在仅是 DNS 前缀的转发器。
3. 监控流量：确认 auth‑svc.default.svc.cluster.local 的请求已落到新部署，检查日志、指标，确保无错误。
4. 缩容旧 Pod：先把旧 Pod 缩容到 0，保留为回滚保险。
5. 处理 Ingress：为新命名空间临时注解
```yaml
apiVersion: v1
kind: Namespace
metadata:
name: authentication
annotations:
policy.example.com/allow-duplicate-ingress: "true"
```
在短时间内同时运行旧与新 Ingress，验证流量后删除旧 Ingress。

为什么有效
- 零停机：内部 DNS 解析与外部 Ingress 分离，迁移期间无服务中断。
- 无代码改动：消费者不需要更新任何调用地址。
- 安全回滚：旧 Pod 先缩容到 0，若新部署出现问题可立即恢复。
- 可复用模式：任何通过 DNS 访问的服务都可采用此方案，适用于多团队环境。

适用场景
- 需要迁移已被多服务依赖的关键部署。
- 受限于命名空间策略或 Ingress 规则冲突。
- 需要在生产环境保持高可用性。

资源
GitHub: GitHub

#DevOps #运维 #Kubernetes #ExternalName #Ingress #NamespaceMigration #ZeroDowntime #OPA #Prometheus #Grafana
@DevOpsTalkCN

RapidFort 与 CrowdStrike 合作 自动化容器硬化

RapidFort 已将其容器漏洞修复平台与 CrowdStrike Falcon Cloud Security 集成。通过该集成，RapidFort 能够直接从 Falcon 读取漏洞信息和 SBOM（软件物料清单），并基于这些数据自动重建容器镜像。重建后的镜像不需要修改应用代码，即可在现有 Kubernetes 环境中替换使用，适用于无法升级集群版本的场景。

RapidFort Runtime 进一步监控容器内的开源软件，检测未授权或意外变更，并评估新披露 CVE 的影响。这样，DevSecOps 团队可以在发现漏洞后快速得到可验证的修复镜像，缩短从扫描到修复的周期。

关键点

1. 直接从 CrowdStrike Falcon 读取漏洞与 SBOM
2. 自动重建镜像，无需改动应用代码
3. 支持旧版 Kubernetes 运行
4. Runtime 监控实时变更与 CVE 影响
5. 适合频繁替换容器的 DevSecOps 场景

#DevOps #运维 #RapidFort #CrowdStrike #FalconCloudSecurity #容器安全 #SBOM #漏洞修复 #Kubernetes #Runtime监控
@DevOpsTalkCN

Kubernetes 1.37 让节点组件跑非 root，提升安全性

KubeletInUserNamespace（Rootless 模式）已在 1.37 进入 Beta。开启后，kubelet、CRI/OCI 运行时、CNI 插件和 kube‑proxy 等节点组件可以在 Linux 用户命名空间中以非 root 身份运行。这样即使节点组件被利用，攻击者也只能在该用户账户内执行，无法修改内核、启动加载器或固件。

为什么要跑非 root？

节点组件过去存在多起容器突破漏洞（如 CVE‑2022‑0811、CVE‑2023‑27561、CVE‑2024‑10220 等），攻击者可通过这些漏洞获得宿主机 root 权限。将组件放入用户命名空间后，root 权限被限制在命名空间内部，攻击面大幅缩小。

使用场景
- 生产集群：降低容器突破导致宿主机被攻陷的风险。
- 共享机器：用户可在不请求管理员 root 权限的情况下部署 Kubernetes。
- 笔记本：防止本地集群破坏宿主机网络或防火墙规则。
- AI 沙箱：为 AI 代码代理创建独立用户，避免恶意信息导致宿主机被破坏。
- K8s‑in‑K8s：与 hostUsers:false 的用户命名空间 pod 结合，可在父集群内安全运行子集群。
- 引导集群：临时无特权集群可用于 Cluster API 等工具的 bootstrap。

如何启用
1. 在 kubelet 配置中开启 KubeletInUserNamespace。
2. 通过 kubectl get nodes -o yaml 查看 runningInUserNamespace。
3. 若需避免调度需要 root 的工作负载，可基于该属性设置节点标签或 taint。
4. 需要在宿主机上预先创建用户命名空间（如使用 rootless Docker、nerdctl 或 Podman）。

工具支持
- kind：dockerd-rootless-setuptool.sh install && kind create cluster
- minikube：dockerd-rootless-setuptool.sh install && minikube start --driver=docker
- Usernetes：支持多节点 rootless 集群与 VXLAN。
- k3s：内置 rootless 模式，无需外部运行时。

后续
- 未来可能升级为 GA。
- 与 UserNamespacesSupport（GA 1.36）结合，可实现更细粒度的隔离。
- 关注 KEP‑5474、KEP‑5714 等提案，进一步简化 K8s‑in‑K8s。

资源
GitHub

#DevOps #运维 #Kubernetes #Rootless #安全 #KubeletInUserNamespace #用户命名空间 #容器安全 #K8sInK8s @DevOps实战
@DevOpsTalkCN

OpenTelemetry 让 GenAI 调用可观测化

在 AI 代理每次调用 LLM 时，模型、工具、重试等链路会在后台悄悄执行。没有可观测性，性能瓶颈往往只能凭经验猜测。OpenTelemetry 的 Generative AI 语义约定（Semantic Conventions）统一记录模型名称、输入/输出 token 数量、完成原因，以及可选的完整提示、回复、工具调用和结果。这样你就能在任何 OTLP 兼容后端查看完整的调用链。

通过 VS Code Copilot 生成 Telemetry
1. 在 Settings 搜索 copilot otel
2. 开启 github.copilot.chat.otel.enabled、github.copilot.chat.otel.captureContent
3. 默认 OTLP 端点为 http://localhost:4318
4. 运行 Docker：
```bash
docker run --rm -p 18888:18888 -p 4317:18889 -p 4318:18890 -d --name aspire-dashboard \
-e ASPIRE_DASHBOARD_UNSECURED_ALLOW_ANONYMOUS=true \
mcr.microsoft.com/dotnet/aspire-dashboard:latest
```
5. 访问 http://localhost:18888 查看 Traces、Metrics、Logs。

在 Aspire Dashboard 的 Traces 页面，你会看到 invoke_agent 及其子 span：每一次 LLM 调用 (chat) 与工具执行 (execute_tool)。span 属性如 gen_ai.request.model、gen_ai.usage.input_tokens、gen_ai.usage.output_tokens 等，若开启内容捕获，还能看到 gen_ai.input.messages、gen_ai.output.messages 等完整对话。Metrics 页面提供 gen_ai.client.operation.duration（延迟直方图）和 gen_ai.client.token.usage（token 消耗），帮助你估算成本、发现高消耗提示、监控模型性能。

你可以把自己的 GenAI 应用同样注入 OpenTelemetry，直接把 Telemetry 送到任何 OTLP 接收器。
反馈和讨论请加入 GenAI Semantic Conventions SIG。

#DevOps #运维 #OpenTelemetry #GenAI #Kubernetes #Docker #Metrics #Tracing #Observability #AspireDashboard
@DevOpsTalkCN

Karmada 1.19 通过 CNCF 毕业，开启多集群 AI 训练新纪元

Karmada 已完成 CNCF 毕业，证明其在多集群、多云、多区域 Kubernetes 编排上的技术成熟。v1.19 版本新增多组件调度，支持分布式 AI 训练作业，并将优先级调度提升至 Beta，默认开启，保证关键任务优先调度。

企业如 Bloomberg、Trip.com、Alibaba Cloud 等已在生产环境使用 Karmada，实现跨集群弹性、灾备与统一资源池。通过扩展标准 Kubernetes API，Karmada 让应用无需改动即可在不同云与本地数据中心间迁移与扩容，显著降低运维复杂度。

Karmada 还集成了 Prometheus 指标、etcd 控制平面、Helm Chart，方便与现有 CNCF 生态协同。未来计划加入多集群排队、GPU 动态资源分配等功能，进一步提升资源感知与调度效率。

#DevOps #运维 #Karmada #CNCF #多集群 #AI训练 #Kubernetes #Prometheus #Helm #etcd @DevOps实战
@DevOpsTalkCN

KYAML：让 Kubernetes 配置更可预测

Kubernetes 通过 KYAML（Kubernetes YAML）推出了一个更严格的 YAML 子集，限制了常见的 YAML 误用（如缩进错误、可选引号导致的类型强制转换）。
- 缩进问题：错误的空格会导致结构被误解析，尤其在 Helm 模板中更易出现。
- 字符串引号：未加引号的值（如 NO）会被解析为布尔值，产生“Norway Bug”。
- 兼容性：KYAML 仍是标准 YAML，所有现有工具（kubectl、CI 流水线、Helm 等）无需改动即可使用。

适用场景

- 大型团队或多仓库项目：统一写法，减少审查成本。
- CI/CD 预检：在 kubectl apply 前加入 KYAML 校验，提前捕获缩进或类型错误。
- Helm 模板开发：避免外部缩进导致的结构变更。

是否迁移
- KYAML 不是强制要求；现有 YAML 仍可直接使用。
- 迁移成本低：只需在文件头加注释或使用 CI 任务检测。

总结
采用 KYAML 并非必须，但它提供了更一致、更安全的配置写法，尤其在多人协作和自动化部署中能显著降低错误率。

#DevOps #运维 #Kubernetes #KYAML #CI_CD #Helm #配置管理 #容器 #云原生 #SIGCLI
@DevOpsTalkCN

Kubernetes 通过 OIDC 统一身份管理，彻底摆脱证书泄露风险

在自托管集群里，访问控制往往被忽略。默认使用静态客户端证书或长期令牌，证书一旦颁发就几乎不再更新，导致离职、角色变更或设备丢失后仍能访问。要撤销访问，需要在每台机器上手动删除证书，几乎不可能做到彻底。

解决方案是把 OIDC 身份提供者（如 Keycloak）放在前端，使用公开的 OIDC 客户端（PKCE）而非保密客户端。这样访问权限完全由身份提供者的组成员关系决定，权限变更只需在 IdP 里添加/移除用户组，无需在集群侧分发新 kubeconfig。

实现要点
- Keycloak 配置
- Client ID: kubernetes
- Client authentication: Off（公开客户端）
- Standard flow: On
- Require PKCE: On（S256）
- Redirect URIs / Web origins: http://127.0.0.1:*、http://localhost:*（仅回环）
- Client scopes: openid, profile, email, groups
- Mapper: Group Membership → claim groups

- kube-apiserver
```bash
--oidc-issuer-url=
--oidc-client-id=kubernetes
--oidc-username-claim=preferred_username
--oidc-groups-claim=groups
```
若 Keycloak 证书未受公认 CA 签名，追加 --oidc-ca-file=/etc/kubernetes/pki/oidc-ca.crt。

- kubectl
```yaml
users:
- name: oidc user
exec:
apiVersion: client.authentication.k8s.io/v1
command: kubectl
args:
- oidc-login
- get-token
- --oidc-issuer-url=
- --oidc-client-id=kubernetes
```

- RBAC 绑定
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: platform-viewers
subjects:
- kind: Group
name: platform-viewer
roleRef:
kind: ClusterRole
name: view
```

效果
- 访问权限随组成员变动即时生效，无需重新分发 kubeconfig。
- 审计日志记录真实用户与组，提升安全可追溯性。
- 仅需一次性配置，后续维护成本极低。

#DevOps #运维 #Kubernetes #OIDC #Keycloak #RBAC #PKCE #kubelogin #k8soperator
@DevOpsTalkCN

GitHub Actions 统一分布式追踪，零改动即可监控全组织 CI

GitHub Actions 的工作流运行会触发 workflow_run 与 workflow_job 事件，OpenTelemetry Collector 的 githubreceiver 可以直接把这些事件转成 OTLP spans。只需在组织级别挂一个 webhook，Collector 负责把每个工作流映射为一个父 span，内部作业和步骤分别为子 span，span 与 trace ID 通过运行 ID 与检查运行 ID 计算得到，保证同一执行链的所有步骤都在同一 trace 下。

为什么要这样做？
1. 零改动：不需要在每个仓库的 YAML 中插入追踪步骤，所有新建仓库立即可观测。
2. 统一视图：所有工作流、作业、步骤都在同一追踪后端（Tempo、Jaeger、Datadog 等）可查询，支持跨团队、跨工作流类型的切片与告警。
3. 成本可控：先测算活跃仓库数 × 平均运行次数 × 步骤数 × 负载大小，和现有应用追踪量对比，往往 CI 追踪量只是一个小数点。

部署要点
- Collector 需公网可达，建议 IP 允许列表或 WAF 过滤 GitHub webhook 源。
- 需要组织管理员权限创建 org‑level webhook。
- githubreceiver 仍处于 alpha，建议锁定 Collector 版本并关注 changelog。
- 若使用 GitHub Enterprise Server，先验证 webhook 交付行为。

示例配置
```yaml
receivers:
github:
webhook:
endpoint: 0.0.0.0:19418
path: /events
secret: ${env:GITHUB_WEBHOOK_SECRET}
scrapers:
- github_org: ${env:GITHUB_ORG}
exporters:
otlp:
endpoint: ${env:TRACE_BACKEND_ENDPOINT}
headers:
authorization: ${env:TRACE_BACKEND_API_KEY}
service:
pipelines:
traces:
receivers: [github]
exporters: [otlp]
```

只需把 webhook 指向 Collector，所有仓库自动覆盖。

#DevOps #运维 #GitHubActions #OpenTelemetry #CITracing #Observability #K8sOperator #CICD #Tempo #Jaeger
@DevOpsTalkCN