一周热榜

今天有一个供应商要求我们提供来自Kubernetes集群的日志。我们没有运行任何日志聚合工具（没有使用fluentd/fluentbit），除了DataDog，所以我需要从三个命名空间中的30多个部署中提取日志。 为了避免手动为每个部署运行kubectl logs，我构建了这个Python命令行工具，可以一次性收集一个命名空间内的所有部署日志。它按日期和命名空间进行整理，支持并行收集，并处理常见的K8s边缘情况（例如每个部署多个Pod、失败的Pod等）。 使用非常简单：`klogger collect -n production` 这并不算什么突破性的东西，但它为我节省了数小时的手动工作，也可能帮助其他处于类似情况的人。它基本上是一个kubectl的包装工具，专注于一件事——在需要时进行批量日志收集。 GitHub链接： [https://github.com/christensen143/klogger](https://github.com/christensen143/klogger)

出于明显的原因，我决定匿名发帖。我刚开始了一份短期的开发合同，注意到前方有一些障碍，我担心这可能会影响我们交付产品的能力。 这个组织向一个非常小众的奢侈市场销售，并以高价分发本地应用程序。公司的高管们对软件在每次发布后出现的裂缝感到极为不安。问题在于，我们目前的架构作为本地应用程序意味着攻击者已经获得了根权限，我们无法保护任何关键数据。此外，还有一些特定领域的原因使得某些用户在某些时候总是需要远程访问。虽然我希望鼓励组织最终转向我们可以保护的客户端-服务器架构，但提供远程副本的需求意味着我们所能做的只是通过模糊安全来创建难题盒子，这对攻击者来说解锁的成本（从他们的时薪来看）比我们创建的成本要低。 我认为他们对这些裂缝的出现反应过度，推动开发团队在软件中引入更多检查，从而损害了生产力，甚至可能影响软件的稳定性，同时也未能解决问题。 举个例子来说明我的担忧：我最近和我们的一位开发人员谈论了一个依赖性问题，其中一些额外的许可证检查被嵌入到用户界面中，我鼓励将这些检查提取到特定层次。对方回复说：“如果我们把所有的许可证检查放在同一个地方，这不是更容易被破解吗？” 我意识到这可能是一个警示信号，我应该撤退，但我相信自己是一个有说服力的人，我想尝试一下。他们有点老派，所以我觉得需要采取温和的方式。大多数情况下，我希望将问题重新框定为“技术问题”变为“社会问题”，减少对模糊安全的关注，更多地关注追踪泄漏的来源，并通过许可证协议来执行后果。 因此，我向大家求助，希望能在这方面得到帮助。我想你们中的一些人可能曾经遇到过类似的情况，拥有我可以借鉴的经验，或者可能对我可以使用的各种资源有所了解。我想到的一个例子是大型在线游戏公司在面对瞄准机器人或其他作弊行为时所遇到的问题，这些市场中黑客的价值接近于零，而工程部门为防御所投入的资源却很高；这展示了这种方法的徒劳。然而，我有点担心，由于他们的老派思维，游戏可能不是他们会接受的例子。 相反，如果有人对简单的模糊处理和/或硬件加密狗之外的简单解决方案有任何建议，我也会非常感激，因为如果我能从他们的角度提出一些超出典型收益递减曲线的建议，这可能会有所帮助。

大家好， 我正在进行一项研究，有一个问题想请教大家。当语音人工智能代理的流量激增时，你们通常会怎么处理？据我所知，Kubernetes 的原生自动扩缩容（HPA）往往无法及时跟上，导致延迟过高。如果你们愿意分享经验，我将非常感激。 谢谢！