Lexus Lee 记一次 k8s apiserver watch hang 问题排查 问题背景 注📢: 本文中涉及 apiserver 地址和 ingressgateway 地址, 为脱敏处理, 将会做马赛克处理！！！ 传统的 kubernetes apiserver 请求访问链路为客户端直连 apiserver，为了做 apiserver 高可用，通常我们会给 apiserver 前端再套一层4层或7层代理做多个 apiserver 实例的负载均衡。 在我们的场景下，使用了 istio 的 ingressgateway 作为 client -> apiserver 这条链路中的7层代理。链路变成了 client -> ingressgateway -> apiserver ，gateway 暴露 80 端口供客户端访问, 同时通过 istio virtualService + destinationRule 规则配置 gateway 能通过域名访问到 apiserver 6443 端口，从而实现流量路由。 具体链路如下图所示， 在这样的链路下，我们遇到了如下问题， 在 k8s apiserver 1.18 版本的集群在滚动重启过出现部分组件无法 watch 到事件的情况，客户端 watch 请求偶发 503。需要重启组件，重建 watch 连接才能恢复。

LexusLee 豆瓣一年内被罚款了900万人民币，而新出的豆瓣电影日历是89元。 在聊聊豆瓣之前，先听我讲一个故事。(以下节选自当年明月《明朝那些事儿—-卷7》原文) 徐宏祖出生的时候，是万历十五年。 在这个特定的年龄出生，真是缘分，但外面的世界，跟徐宏祖并没有多大关系，他的老家在江阴，山清水秀，不用搞政治，也不怕被人砍，比较清净。 当然，清净归清净，在那年头，要想出人头地，青史留名，只有一条路——考试（似乎今天也是） 徐宏祖不想考试，不想出人头地，不想青史留名，他只想玩。 从俗世的角度，徐宏祖是个怪人，这人不考功名，不求做官，不成家立业，按很多人的说法，是毁了。 然而徐宏祖的父母没有打他，非但没有打他，还告诉他，你要想玩，就玩吧，做自己喜欢做的事情就行。 就这样，徐宏祖开始了他伟大的历程。 他二十岁离家，穿着布衣，没有政府支持，没有朋友帮助，独自一人，游历天下二十余年，他去过的地方，包括湖广、四川、辽东、西北，简单地说，全国十三省，全部走遍。 他爬过的山，包括泰山、华山、衡山、嵩山、终南山、峨眉山，简单地说，你听过的，他都去过，你没听过的，他也去过。 此外，黄河、长江、洞庭湖、鄱阳湖，金沙江、汉江，几乎所有江河湖泊，全部游历。 在游历的过程中，他曾三次遭遇强盗，被劫去财物，身负刀伤，还由于走进大山，无法找到出路，数次断粮，几乎饿死。最悬的一次，是在西南。 当时，他前往云贵一带，结果走到半路，突然发现交通中断，住处被当地土著围，过了几天，外面又来了明军，又开始围，围了几天，就开始打，打了几天，就开始乱。徐宏祖好歹是见过世面的，跑得快，总算顺利脱身。 在旅行的过程中，他还开始记笔记，每天的经历，他都详细记录下来，鉴于他本人除姓名外，还有个号，叫做霞客，所以后来，他的这本笔记，就被称为《徐霞客游记》。 作为前员工，我常很骄傲和朋友说，我是从豆瓣出来的。如果你逛过豆瓣D9放映室小站，会发现这个活动自打豆瓣成立不久后就有了，且一直延续到现在，至我离职时已放映了200期有余。每隔几个周四，一群人约定下班后在公司看场电影，看完在夜晚的将台路撸串，长街的路灯远远望去，洇成一团团黑影，映出一群从豆瓣回家的人。 高中时开始接触豆瓣，它对于我就是一个手账，记录我在短暂这一生的时间线上看的电影，听的歌。上大学后清闲时间多了，逐渐变成豆瓣重度用户，也成为了八组一只鹅，不时发起牢骚。那时候我像一只社交动物，渴望找到同类族群，豆瓣就是一座城。但真正开始对豆瓣产生巨大情愫，是看了阿北的那篇出名的日记《豆瓣电影评分八问》 有人问: “我可以做点什么让我的片子在豆瓣评分高一点？” 阿北答: “刷分上面说过了，越来越没用。所以我确实不知道除了拍好电影，能做什么。” 于是，我觉得这人行，能处。 也觉得这样的公司，高低不会太差。 后来我加入了豆瓣。在豆瓣鹅组正火热那年，我见过上级部门不少针对其中违规言论的防范措施，我知道其中"违规"的定义是相对模糊、难以琢磨的，这些措施执行下来往往带来了不少舆论压力。所以我越来越不喜欢鹅组，这儿带来的负面情绪常使人震怒，气得直对眼。这像是一群不加以限制的"自由"的人在瞎起哄，试图翻起腥风血雨。 从一个前员工的角度，我开始思考业务价值，希望公司发展得更好，挣大钱发大财。至少在900万罚金面前，我们可以是体面的。从书影音运营的角度，豆瓣掌握着一手的资源，很多商业上的变现途径，像房间里的大象，豆瓣的同事们一定比我要懂，不会看不明白。所以我也质疑过，在不沾染铜臭气这一点上，是不是走到头了，要不，咱们换条路走走？ 这个情绪在得知豆瓣被罚款后尤为高涨，直到我看到豆瓣同事群前辈说的一句话， 哎呀，成功不成功有那么重要么？活着死了有那么重要么？在当下尽可能的活成自己想要的样子就好了。 我突然明白，我在把豆瓣当成一家经营用户的企业，那变现手段不外乎挤破头从用户身上榨取价值。因为一旦当做一家商业企业，很容易想要横向和其他"成功"的案例进行对比。你今天走进电梯，左边是学而思，右边是投资理财，正面是花样的明星让你充钱。所有东西都在提醒你，你是一家公司，你要努力，努力让他们充钱，努力成为下一个xxxx。这像极了小时候要活成某些人希望的样子的长辈执念。 可是豆瓣是不同的呀，在整个互联网，豆瓣都是一个独一无二的存在。 如果把公司比作人，是社会中的一个个体，为其他个体创造价值，使得它可以延续发展。那豆瓣就像那个我们都会很敬佩的人，比如和菜头提过的《钻石唱针》里的那位豆友，他的公开身份是一名商场经理，他的业余爱好是黑胶唱片，他在自己生命结束前一共向豆瓣无偿添加了6108条唱片记录，没有任何物质回馈。我曾经想找一首原声《i am still standing》, 点开发现了他的编辑记录。 这个人让我明白，人生并不是用"收益"来判定的，收益只是添头，那是明知可能没有收益，也要使上一把野劲。 我实在不知道如何向那些已经躺在大象脚下的人，阐述这种听起来令人感到滑稽的理念。在我看来，人生追求的是"独一无二"的过程。 就像整个明史里，有大把的人喜欢张居正，也有大把的喜欢朱元璋，但我最爱的还是徐宏祖。 开头所讲的徐霞客的故事，当年明月当时说：“我之所以写徐霞客，是想告诉你：所谓百年功名、千秋霸业、万古流芳，与一件事情相比，其实算不了什么。这件事情就是——用你喜欢的方式度过一生。” 在看过了大多数人成功的活法之后，确实很难不心动。复制出来的路，会让我感觉活成了别人，追求跟别人一样的标配生活，追求跟别人一样的模板人生。 但徐霞客不，他不想“泯然于众”，他只想遵从内心真实的感受，用自己喜欢的方式度过一生。 这份对自然的钟爱，从他长大加冠到步入年迈都从未改变。有人问他为什么穷尽一生去追求这一切，是否曾后悔过？是的，在明朝那个重视科举追逐功名利禄的朝代，徐霞客便是人们眼中不务正业荒废仕途的浪荡子，可他凭着对世间景色以及游历山水的无限热爱，达人之所未达，探人之所未知，不求功名，不求富贵，不求权力，一生之中只为了取悦自己。 正如那一年隆冬，大雪封了黄山。徐霞客用一根铁棒在峭壁之上凿出一个个冰坑，一步一步爬上了黄山绝顶。于是便有了《徐霞客游记》中的一句：“初四日，兀坐听雪溜竟日”。 那一天，山下的人们匆匆忙忙，为了富贵功名交相奔走，而徐霞客却坐在黄山绝顶，听了一整天大雪融化声。 我一度以为，选择什么样的活法，以什么样的方式在当前互联网环境下生存，是自主的决定，但实际上，大多数公司的选择的活法，在这个物质包裹以及增长爆炸的时代，只是一种被动引诱的结果。当我把豆瓣当做一个具象的人来看时，他是和环境格格不入的，是一个全然的自由的人，他成了我敬佩的人。我很庆幸在迷茫的时候，仍然有这一口气一盏灯。我羡慕过旁人一些"成功"的选择，他们路上也有很美的风景。但豆瓣的活法让我相信，始终，我们能汲取一种自己路上独有的内力，这种内力一定能强于某些外力。而人生就是，从某种程度来看，内力和外力的抗衡，不管出了什么事，有内力就能坚持下去。 豆瓣，纷纷扰扰无关，天色已亮了大半。

背景 最近在接触《容器高手实战》这门课，作为有一定容器经验的工程师，从这个视角下，我会记录一些非基础的，但是不是需要回看一眼的课程笔记，用于分享。 课程相关源码及笔记我放在这个这个链接中, 欢迎 fork & comment~ 《容器高手实战课程》 源码及笔记, 共分为以下几个模块，下面将逐一介绍， Cpu 内存 文件系统 一号进程 容器网络 容器 debug 工具 容器安全 容器 load Load Average 等于单位时间内正在运行的进程加上可运行队列的进程 第一，不论计算机 CPU 是空闲还是满负载，Load Average 都是 Linux 进程调度器中可运行队列（Running Queue）里的一段时间的平均进程数目。 第二，计算机上的 CPU 还有空闲的情况下，CPU Usage 可以直接反映到"load average"上，什么是 CPU 还有空闲呢？具体来说就是可运行队列中的进程数目小于 CPU 个数，这种情况下，单位时间进程 CPU Usage 相加的平均值应该就是"load average"的值。 第三，计算机上的 CPU 满负载的情况下，计算机上的 CPU 已经是满负载了，同时还有更多的进程在排队需要 CPU 资源。这时"load average"就不能和 CPU Usage 等同了。 比如对于单个 CPU 的系统，CPU Usage 最大只是有 100%，也就 1 个 CPU；而"load average"的值可以远远大于 1，因为"load average"看的是操作系统中可运行队列中进程的个数。

背景 上个月，Facebook 发生了一次由 BGP 引起的大型故障，从故障报告 中我确实看得云里雾里。所以近期阅读一些文章，期望深入学习。 这篇博文将会分享一些我如何学习 BGP 的过程及用来查询 BGP 信息的相关工具使用。因为我对 BGP 不是那么了解，故文章难免有不精确的部分，希望多多交流。 BGP 探索之路 如何发布BGP路由 之前我从没有开始接触 BGP 的原因之一是–我不知道如何在我的服务器上通过 BGP 发布路由。 对于大多数网络协议，如果你愿意，都可以折腾，自己实现协议。例如，你可以。 发行你自己的TLS证书 编写你自己的HTTP服务器 编写你自己的TCP实现 为你的域名编写你自己的权威DNS服务器 建立你自己的证书颁发机构 但对于BGP，我认为除非你拥有自己的 ASN，否则不能自己发布路由，尽管可能可以在你的家庭网络上实现BGP，但我希望它们运行在真正的互联网上。 于是我开始着手于如何在我的服务器上发布 BGP 路由。 首先我们来谈谈 BGP 的一些术语。这部分我会简单的介绍，因为我对工具更感兴趣，而且网上有很多关于 BGP 的高水平资料（比如 cloudflare 的这篇帖子）。 什么是 AS（autonomous system）？ 我们需要了解的第一件术语是 AS。每一个 AS 都是什么呢？ 参考这篇维基百科, 他们有以下特征， 由一个组织拥有的（通常是一个大型组织，如你的ISP，政府，大学，Facebook，等等） 他们能控制一组特定的 IP 地址（例如，我的 ISP 的 AS 包括 247,808 个IP地址）。

背景 今天主要分享下我在美团 Hulk 团队调度系统组期间学习到的 k8s scheduler 调度模型及美团对于调度器相关改造 Hulk 团队介绍 Hulk 是美团负责容器云平台的团队, 我所在的组是调度系统组下面的 k8s 小组. 主要负责所有 k8s 相关组件开发维护. Kube-scheduler 调度模型介绍 (本次介绍基于 k8s 1.16 版本) pod 是 k8s 工作负载的最小实体，也是 scheduler 调度的主要对象。 k8s 调度器所做的工作，即将 pod 绑定到指定节点上，为 pod 选择合适的节点。 Scheduler 会先 watch apiserver 获取其中待调度的 pod, 即 pod.spec.nodeName 字段为空的 pod 对象, 通过调用 pod informer 的 handler 并将该 pod 加入调度队列中。 默认情况下, k8s 调度队列是一个 PriorityQueue, 并且当某些集群信息发生改变时, 调度器会对调度队列的内容进行一些特殊操作. 在这儿不论述. 一次调度过程在判断一个 Node是否可作为目标机器时，主要分为三个阶段： Predicates 预选阶段：硬性条件，过滤掉不满足条件的节点，这个过程称为 Predicates。这是固定先后顺序的一系列过滤条件，任何一个 Predicate 不符合则放弃该 Node。 Prioritites 优选阶段：软性条件，对通过的节点按照优先级排序，称之为 Priorities。每一个 Priority 都是一个影响因素，都有一定的权重。 Select 选定阶段：从优选列表中选择优先级最高的节点，称为 Select。选择的 Node 即为最终部署 Pod 的机器。 预选阶段 Scheduler 起 n 个 goroutine 并发对整个集群的所有 nodes 进行 predicates 串行运算过滤规则，直到最终过滤出符合条件的 nodes 列表

背景

从过去几个月, 我的工作精力主要集中在企业级发布平台的建设上. 同时也聚焦在容器云 PaaS 层建设。

在当下云原生时代, 发布平台通常起到一个联结 PaaS 和 IaaS 的作用. 通过在 PaaS 层抽象，将 IaaS 层基建细节屏蔽，同时通过 api 和各个服务平台(CI/CD 服务, 监控告警服务, 网关服务, 工单系统, 服务治理系统等) 交互, 在云平台提供了一个统一的快捷入口，从逻辑上进行汇聚，便于开发者进行一站式应用发布、服务生命周期管理、服务治理、服务运维等操作.