在默认命名空间迁移关键服务：零停机的 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

产品经理（项目管理方向）｜20-25K

地点：前期远程 2-3 个月，后期入职新加坡，全职
职责：协助业务负责人推进产品及业务项目落地，负责需求梳理、任务拆解、优先级管理、排期与整体进度跟进；对接业务、产品、安卓研发及运营团队，把业务需求转化为可执行的产品需求与开发任务，并跟进至上线交付
要求：3 年以上互联网产品、项目管理或产品项目相关经验；具备较强项目推进能力，能同时协调业务、研发、运营等角色；能输出清晰的需求文档与产品方案；英文具备基本读写能力，可调研海外产品与竞品
福利：双休

岗位解读：这类岗位介于产品与项目管理之间，日常主要是把业务方的想法拆成可执行的开发任务，盯排期、盯进度、盯上线，同时处理过程中冒出来的各种问题。团队里通常充当业务与研发之间的连接点，既要写需求文档，也要推动落地。适合有几年互联网产品经验、执行力强、愿意深入项目细节的人投递。

#IT #技术 #招聘

Python / LLM 工程师（RAG 与 AI 智能体）｜М-ТЕХ 公司｜最高 20 万卢布

地点：莫斯科 / 圣彼得堡 / 萨马拉，可远程，兼职
职责：设计、开发并落地面向具体业务场景的 AI 智能体，配置对话、工具调用与知识库流程；搭建 RAG 管线，包括文档加载、分块、向量化、检索与重排，并将智能体对接 API、数据库、ERP/CRM 及即时通讯工具
要求：2–3 年以上 Python 商业开发经验；6 个月以上 LLM 应用、RAG 或 AI 助手实操经验；至少熟悉 LangChain、LangGraph 或同类框架之一
福利：支持远程办公

岗位解读：这类岗位主要把大模型能力落到实际业务里，一边搭检索增强生成管线让模型能查资料，一边做能调用工具、对接内部系统的智能体。日常在团队中偏应用层开发，需要同时懂 Python 工程和提示词、检索调优。适合有后端经验、想转向 LLM 应用方向的开发者。

#IT #技术 #招聘

高级运维工程师｜35K-50K

地点：越南胡志明市 / 驻场 / 全职
职责：负责 Linux 服务器日常运维，维护容器化与 K8S 集群的部署和运行，搭建并维护 CI/CD 自动化发布流水线与监控告警系统
要求：掌握 Shell 脚本，熟悉 Linux 常用命令与 Bash 操作；了解 Docker、Kubernetes、Jenkins 或 Gitlab runner 等 CI/CD 工具，以及 Prometheus、Zabbix 等监控系统；了解负载均衡、路由转发、VLAN、VPN、防火墙等网络原理；有 C# .NET 业务运维经验、AWS 或其他云平台经验者优先
福利：试用期 1-3 个月，每天 9 小时、月休 4 天

岗位解读：运维工程师负责保障线上服务器和业务系统的稳定运行，日常包括环境部署、发布上线、监控告警处理和故障排查。这个岗位偏容器化与自动化方向，需要同时懂 Linux 系统、K8S 集群和 CI/CD 流水线，适合有几年服务器运维经验、想往云原生和 DevOps 方向发展的工程师投递。

#IT #技术 #招聘

高级站点可靠性工程师（Senior Site Reliability Engineer）｜ShiftKey

地点：波兰 / 远程 / 全职
职责：负责线上服务的稳定性与可靠性，参与容量规划、监控告警体系建设和故障应急响应，推动系统可用性持续提升
要求：具备 SRE 或运维开发经验，熟悉云平台、容器化与自动化运维工具，能独立排查生产环境问题

岗位解读：SRE 是介于运维和开发之间的角色，日常围绕监控、告警、容量和故障处理展开，用工程手段减少人工救火。适合有后端或运维背景、愿意深入稳定性建设的人投递。

#IT #技术 #招聘

高级全栈开发工程师（Senior Fullstack Developer）｜Remoby｜$5,000-6,000

地点：远程 / GMT 时区（莫斯科时间）
职责：开发和维护基于 Go 的高负载服务，处理最高 150k RPS 的请求；搭建并优化 Web 界面，后端 Go、前端 Vue.js；编写 Python 脚本接入 Airflow，完成 ETL 数据处理
要求：5 年以上 Go 开发经验；熟悉 Aerospike、MySQL、PostgreSQL 等 KV 与关系型数据库，了解 Kafka；有 AdTech 经验优先
福利：远程办公，薪资 $5,000 起，具体可单独商议

岗位解读：全栈开发工程师同时负责服务端和前端，既要写高并发的后端接口，也要维护用户看到的页面，还要处理数据管道。这个岗位面向广告技术领域，系统请求量大、对性能要求高，适合有 Go 后端经验、愿意兼顾前端和数据流程的工程师投递。

#IT #技术 #招聘

Android 逆向工程师｜吉隆坡｜远程 / 驻场

地点：马来西亚吉隆坡，远程或驻场均可，全职
职责：负责 Android 应用的逆向分析工作，拆解目标 App 的通信协议与核心逻辑，配合团队完成安全评估与相关技术方案落地
要求：统招本科学历；具备 Android 逆向实战经验，熟悉常见逆向工具与分析方法；有银行相关项目经验者优先

岗位解读：Android 逆向工程师主要通过反编译、动态调试等手段，分析安卓应用的内部实现与接口协议，常用于安全评估、兼容适配和风控对抗等场景。日常和开发、安全团队配合，产出分析结论和可用的技术方案。适合有安卓开发或安全研究背景、熟悉逆向工具链的人投递。

#IT #技术 #招聘

高级 Go 后端工程师｜20K-35K

地点：国内远程，居家办公，全职
职责：负责核心业务系统的架构设计与开发，覆盖用户、订单、钱包、奖励发放等模块；设计高并发高可用后台服务及异步任务、消息队列架构，并做线上性能分析与故障排查
要求：5 年以上 Go 开发经验，有大型互联网后台经验；精通 Go 并发模型与内存管理，熟练使用 Gin、Fiber、gRPC；精通 MySQL 与 Redis，熟悉 Kafka、RabbitMQ 等消息队列；熟悉微服务、Docker、K8s 及限流熔断等治理方案。统招本科及以上学历
福利：双休，法定节假日与带薪年假，绩效奖金，节日福利与团队活动，薪资以 U 发放

岗位解读：Go 后端工程师主要负责服务端业务系统的设计与编码，日常围绕接口开发、并发处理、数据库与缓存优化、线上问题排查展开，是业务落地的核心执行角色。适合有扎实 Go 功底、熟悉分布式与中间件、能独立承担模块设计的中高级开发者投递。

#IT #技术 #招聘