TL;DR

当前版本后续可能会变

• 基本医疗保险: 职工/居民医保
• 长期医疗: 20年保证续保的百万医疗险/针对xxx人群的百万医疗，仔细阅读健康告知，能过健康告知的优先买百万医疗。年纪越大费用越贵
• 短期医疗险: <6年期的百万医疗险短期的百万医疗通常待遇都好于长期的不过也有傻逼产品。年纪越大费用越贵
• 普惠健康险：固定价格，是否患有既往症大部分都可以投保，只是既往症报销比例低，或者不报。

按治疗费用接受度及年龄划分

• 10万以内：
  • 中青年：基本医疗保险+[当地普惠健康险（买不了后两个的考虑） 或者 短期医疗险（癌症特药更好） 或者 长期医疗险（保障更长）]
  • 老人：基本医疗保险+当地普惠健康险
• 10~30万:
  • 年轻：基本医疗保险+长期医疗险
  • 年纪大：基本医疗保险+当地普惠健康险
• 30万以上: 基本本医疗保险+长期医疗险+(当地普惠健康险 或者 一年期健康险)主要是为了更全的覆盖院外药物。
  阅读全文 »

背景

之前从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 序

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