背景

之前从8100的黑群晖，切换到了N100的，但是比较慢，然后忍不了了，就又新买了一套设备组装。趁机就升级下网卡。之所以选黑群晖就是只是因为界面友好点。配套软件比较给力。然后穷买不起白裙。

背景

业务反馈发布的时候会偶尔会有504，重新发布也不行。重建Pod也不行，但是等一段时间就会自动恢复。

上图是一个服务的504的一个情况。从历史的指标跟 Ingress 日志来看，我们能够得到一个清晰的结论。已经销毁了的 Pod 的 IP 并没有被 Ingress 摘掉。 Pod A 在17:35就已经销毁了，但是持续到 17:37 Ingress 还在向已经销毁了的 Pod A 发送流量。

背景

之前在生产队当驴的时候，觉得生产队拉的磨盘，性能太差，拉的不太顺手。斥巨资购入了一套私磨拉。最近生产队买了更高性能的磨，于是我又换回公磨了。把私磨带回家里了，家里的设备变得就非常多。然后之前为了省电费把我的 intel 8100 的 NAS降级成了 intel N100。跑的容器越来越多。性能也跟不太上了。最后想了一下也别回intel 8100了，打算把nas升级一波，借着机会就把 HomeLab 搞起来。

背景

最近在公司收到了一条告警，K8S 集群中的 GPU 的节点一台接一台的变成了 NotReady 状态了。过了半个小时，业务找我说他们的服务起不来了，同时服务的所有的实例全都异常了。因为我们线上没有关闭 controller manager Node 异常的驱逐，如果业务代码会把宿主机节点跑死,节点上的异常业务就会触发迁移，迁移完接着把下一台节点跑死。如同葫芦娃救爷爷一般，全军覆没。最后 GPU 节点全部跪了。

背景

群友发现了一个问题，为什么在容器里面创建的文件夹与文件的deviceId不相同。正常情况下应该是相同的，但是在他的环境中是不同的，具体情况如下图所示：

这个问题群里没有人复现，但是后来群友补充到在centos 7.4 中可以稳定复现。其他系统版本不会出现。到这里我基本上猜测是overlayfs本身的变动，或者说是其他版本的系统中已经默认使用overlay2作为默认的docker driver替换了overlayfs了。

简介

nginx-ingress-controller 是最常用的 ingress-controller 之一，也是当前公司生产在使用的ingress。这边会分析主流程。整个ingress-controller是怎么工作的。并不会详细的去解释所有的代码。找到关键节点即可。

0x00 序

抗击懒癌过程中节节败退，但是好歹是动手开始写了。反反复复看了几遍，网上的总结也都烂大街了，这篇当做流水账吧，简述了一下组件，然后剩下的看脑图吧。

本篇是mit6.824要读的第二篇文章，原文发表于2003年的SOSP上。GFS 是 Google使用的存储系统，由大量廉价计算机构成。主要用于大文件存储。工作主要负载为追加操作。通过面向异常的思维设计了整个系统，保障了系统的可靠性。中心化的master设计有效的简化了系统设计。

原文Ambry: LinkedIn’s Scalable Geo-Distributed Object Store 发表于 SIGMOD 16 项目目前已经开源托管在github

摘要

全世界社交网络之下的基础设施，需要为数十亿的大小可变的媒体对象提供不间断的服务，例如照片，视频和音频切片。这些对象必定被存储在一个低延时高吞吐的系统中。这个系统需要支持跨地区、可扩展，并提供负载均衡能力。当存储大文件的时候，现有的文件系统和对象存储面临着一些挑战。我们推出 Ambry，一个针对大规模不可变对象（称之为blob）的生产级系统。Ambry 设计为一个分布式的系统，并且使用了如下技术：逻辑 blob 组，异步复制，再均衡机制(译注:数据再均衡)，zero-cost 失败检测机制和系统缓存。Ambry 已经在 LinkedIn 生产环境中运行了 2 年，以高达 1万次/s 请求的质量，为超过 4 亿用户提供了服务。我们的实验显示，Ambry 提供了一个高效(使用了 88% 的带宽)，低延时(1MB 文件延时小于50ms)，负载均衡(相对于未进行负载均衡提高了 8-10 倍性能)的系统。

0x00 序

本来前年的这个时候就打算刷这个课了，但是在抗击懒癌的过程中节节败退。一直就拖到了现在，也不知道这次能坚持多久。总之争取每个月能出一篇文章吧。主要是为了克服自己对于知识的遗忘，如果同时能给你带来一些启发或者帮助那就更好了。考虑到自己吃了没文化的亏，为了能在某些时候能读到最新的一些技术文章或者论文。现在就必须克服读英语的障碍，我会强迫自己去理解并翻译原文，参考其他文章的理解，参考讲义，最后总结出来一篇文章。

序

haystack 是facebook 开发的对象存储系统,用来存储facebook的照片,面对海量的图片数据,从中取回一张图片确实很像大海捞针,文章的名字还是比较有有意思的,相关的设计发表在了osdi 原文链接 文章总体分为6大部分，主要总结了facebook遇到的问题,总结过去遇到的问题,回顾过去的解决方案，进而规避过去方案的不足从而设计了haystack来解决之前的问题,并在文章的最后进行了性能相关的分析。本博文主要摘取重要部分进行摘录，并进行进一步讨论和研究,同时回避了CDN相关的章节。