Enumerate the list of apps that need to be installed on my migrated work computer at the moment. I’ll consider adding it to the sync tool later. Develop Vscode Sublime Sourcetree Github Desktop Iterm2 Postman Cyberduck Docker Command-line oh-my-zsh homebrew homebrew cask tmux ack ag bat autojump job fselect Prototype draw.io desktop XMind Sketch Database Sequel Pro (for MySql) Navicat (for PostgreSql) Redis Manager IM Wechat Qiye Wechat Slack 浏览器 Chrome Browser Typora Notion RSS Leaf Wallpaper Iruve System tools CleanMyMac Dozer Password 1Password Music NetEase Music Spotify Video Player IINA Util Tool Paste Yoink Beyond Compare Handshake Quicklook GTD Fantastical 2 

背景 最近需要给 k8s 集群升级 docker, 预期升到 19.03.x. 遇到一些问题, 记录下 调试期间遇到的问题: 集群中的 ingress 是以 daemonsets 方式部署, 通过 node-selector 选择节点定死. 而 kubectl drain node 并不 evict daemonset pods. 故在升级/重启 dockerd 期间会造成 ingress 短暂不可用. 而现有的 lb 的 health check 不能 cover 这一点, 仍会有流量打入.会导致升级期间 ingress 流量黑洞问题. 并且 dockerd 拉起来后, 有些 daemonsets 由于 ingress 自身 livenessProbe 等原因在 dockerd 升级期间持续 crashLoopbackoff 了, 一个原因是仍然 mount 一份旧的 docker overlay. 在 delete pod 重启后恢复. 故需要一个手段在升级后重启 ingress pods. Ref https://github.com/kubernetes/kubernetes/issues/75482#issuecomment-511476698

背景 最近在豆瓣做面向开发者的 op 报警系统, 最头疼的是下列几种情况 脉冲型报警 单个原因引起的报警发散 多个报警为同个诱因 由于目前现有的一些告警系统都强依赖后面的监控 agent/cmdb , 比如 open-falcon/prometheus 虽然都支持了告警收敛这一套, 但要从豆瓣的 statsd+icinga 迁移到 alertManager 需要折腾一阵。而我实际只想要一个中间轻量的 alert exporter 去做告警聚合/收敛. 所以我期望实现下列 feature: 对于告警可配置梯度, 比如 apperr > 50, 则立马报警不做 retry, 并且 notify_interval 为 1 分钟; 对于 50 > apperr > 20 则有3次 retry, retry 周期为 1 分钟, 报警周期为2分钟. 对于 apperr < 1 则 retry 5 次, retry 周期 3 分钟, 报警周期 5 分钟. 告警配置中可用 与|或|非 的方式进行组合告警,告警收敛. 如 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [rules] apperr - script: xxx - label: http, service, statsd, codeerr - warning_threshold: 0.

(译) eBPF Tracing 简明教程与示例 背景 原文链接 http://www.brendangregg.com/blog/2019-01-01/learn-ebpf-tracing.html 原文作者 Brendan Gregg 出版时间 01 Jan 2019 翻译时间 11 Jan 2020 之前开 2019 ShangHai KubeConf 听了几场 eBPF 的分享, 最近才开始深入研究, 故打算把研究 Linux performance 的大佬 Brendan Gregg 的文章《Learn eBPF Tracing: Tutorial and Examples》 作为 eBPF 入门翻译一遍, 希望对其他非英语母语的开发者有帮助。 译文 在 2019 年的 Linux Plumber’s 大会上至少有 24 场关于 eBPF 的讲座, eBPF 迅速地成为了炙手可热的技术。所以也许你也计划在新的一年里开始学习 eBPF!

这些日子隐隐觉得你并不开心, 我十分自责, 总觉得是那天妖精们藏起了星星。 北京的天总是阴沉沉的，有时候好像是要开启一场庭审，让我紧张得四肢发麻，不知道你会不会也因此闷闷不乐。这样的日子，可真叫人腻味，我沮丧得想睡觉。唯独那天看着你把脸藏在被子里沉沉地入睡，我欢喜得不行，这一天何其矜贵，希望你做个好梦。 所以我特别期望能有个间隙去看看被藏起来的东西，看星星也是我生活中为数不多的理想主义。 那时你说我喋喋不休，要知道我是个时刻沸腾的人，能滋滋作响一整天，总有一些莫名其妙的巨大能量，但我也要悄悄地藏起来，可要把我所有的能量分成一天天的给你。这样我就能沉静许多，不过其实一见到你，那些跳脱的念头总能平静下来。 就像一只海豚，终于跳进了阿芙罗狄忒的海湾，有海鸥有落日，不免沉浸其中。 这样的日子，我也想藏起来，担心有一天我不会记得，只期望有那么几个瞬间，偶然念及你的名字，心底像冒出海葵与青荇，世界变量明亮开朗起来。 所以，我还想看着你笑，看着你看电影时甜甜地睡着，你说，我哪能让你一个人生闷气呢。 你说未来会有多少无生趣的毫不起眼的夜晚，我就跋涉到灯塔上，威胁妖精们把藏起来的光，投射下来。 加油啊，阿芙罗狄忒。

背景 之前一段时间正好接触到 kubernetes cronjob, 在接入时遇上了在一定量级下 cronjob schedule delay 的问题, 故开始读了下代码, 发现了一些问题并试着调优了下 存在的问题 按生产环境实际测试来看约 250-375 个 */1 * * * * 每分钟 interval 的 cronjob 就会产生 delay, cronjob 和 controller manager 没有异常 event 但新产生的 job 出现了延迟, 由于我们设置了 startingDeadlineSeconds 故累加起来的 delay 最终导致了 cron 任务严重滞后 代码解读 出于分析上述问题的目的, 读了下 cronjob controller 的代码, 代码量不多, 可能由于没上 GA 的原因, 整个 controllor 代码的设计也比较过程式, 不会像其他组件用到一些比如 Informer, refractor之类的组件读起来相对晦涩 下面开始解读下 release1.17 分支的 k8s cronjob controller 代码 Controller struct 1 2 3 4 5 6 7 type Controller struct { kubeClient clientset.