曾经的我

记录下我的学习轨迹。

  • 研究使用 kubernetes/client-go 编写程序,监控 configmap 的变更
    • watch 接口不会处理网络问题,失败会直接断开连接,实践中不建议直接使用它!
    • 更建议使用 informer,这是一个带缓存的接口,底层是使用 watch 接口 + 队列实现,而且会自动处理网络问题(自动重连),也提供接口强制更新本地缓存。
  • The ANSI C Programming Language - 83/236
    • 快速过一遍语法
  • 研究云上网关及 Kubernetes 集群的网络架构优化方案
    • 从之前的「多云+多集群网络方案」,先简化为各集群互相独立的网络方案,之后再往多集群、多云等方向去迭代(迂回策略)。
      • 将遗留的 Nginx 网关直接移到 K8s 集群内,并注入 Sidecar 以接入 Istio 服务网格,由 Sidecar 帮助 Nginx 实现集群内的服务发现、流量切分、多集群支持等能力。好处是遗留的一堆 Nginx 配置基本不需要什么改动,改造难度低,收益明显(动态扩缩容的 Nginx、更短的网关链路、更简洁的配置)。后续还可以逐渐切换到新的 API 网关提升可维护性。
      • Nginx 可以通过云服务商提供的 L4 负载均衡(如 AWS NLB)暴露到公网,也可以自建 keepalived 高可用方案(自己整个 Pod 动态注册控制器,或者搞套静态的节点组都行),不过要注意跨区流量,网关最好是每个可用区单独部署一套,互相隔离。
      • 相当于暂时使用 Nginx+Sidecar 彻底取代掉 Istio 的 IngressGateway。讲道理 Istio 的 IngressGateway 功能还是有点弱
      • 等这个方案实施后,我们可能会考虑使用 APISIX/Traefik 或其他基于 Envoy 的网关来取代掉这个容器化后的 Nginx。目的是提供更简单的网关配置方法,当前写 Nginx 配置的方式还是不太友好。
  • Linux/Unix 系统编程手册(上册) - 进度 21/572
  • 感觉最近学东西有点随心所欲,东一榔头西一棒槌,感觉自己还在找方向吧。不过 Linux 跟 Kubernetes 开发这两件事应该能坚持下来。
  • 《语言学的邀请》- 进度 68/288
    • 感觉解答了一些我以前的对人类的一些疑惑
  • 《Intimate Relationship》 - 14/449
    • 读了文化对亲密关系的影响
  • 跟堂弟大谈如何怀揣理想,平实生活,一点点地进步。 谈我们这一代,我想不必悲观也不必绝望,我们的未来由我们自己创造。 有学术大佬们走在学术前沿,有技术高手们工作在工程一线,我们也完全有能力去做一些有价值的事情,赚更多的钱,也帮助更多的人。
  • 读完了《在生命的尽头拥抱你-临终关怀医生手记》
    • 读这本书时,我也在持续回忆我的爷爷奶奶。很难去说明我从这本书中读懂了啥,本质上我只是想从这本书中找到一些慰藉,顺便了解下「死亡」,大概确实部分达成了目标。
  • 买了一千多块钱的书,最近陆续到货了,现在还差一本《我的青春恋爱物语果然有问题——原画集》
    • 多买了一本罗翔老师的《圆圈正义》,打算送给堂弟
  • 阅读了《Intimate Replationships》的第一小节
    • 了解了人类社会性动物的本质,这可以用进化论解释——越社会性的个体存活率越高,基因也越容易传续。
    • 亲密关系的建立是很容易的,「你是我的唯一」更多的是一种浪漫的说法,只是「因为刚好遇到你」而已。
    • 一旦建立了亲密关系,我们就会抗拒这份亲密关系的解离。当亲密关系遭遇危机时,我们会茶不思饭不想。
    • 在 Youtube 上搜了下 Intimate Replationships,找了几个相关的 TED Talks 看了看。
    • 还找到 UCLA 一个比较老的课程:Intimate Relationships: Undergraduate Lectures at UCLA,可以跟书一起看看。
  • 折腾一晚上博客的 Hugo 跟 DoIt 主题
    • 发现本地生成出的站点,mermaid 跟 music 两个插件的问题莫名其妙修复了,怀疑跟今天跑了一波 brew upgrade 有关
    • 但是云上 github action 跟 vercel 都还有问题,同样的命令同样的 hugo 版本,本地生成的静态文件 mermaid 跟 aplay 正常加载,云上生成的就有问题,也是醉了…
  • 观看 KubeCon + CloudNativeCon 2022 中我比较感兴趣的部分
    • 主要关注与当前工作相关的点:多云管理、多集群(karmada)管理与应用部署、跨集群网络(Istio)、API 网关
    • 有一些收获,但是都是比较浅的,只能提供个别方向的一些思路,主要还是得靠自己探索。
  • 研究了一波 dapr,理念很先进,但是发现很多功能都还处于 alpha 阶段,不太适合向业务侧推广,继续观望吧。
  • 研究跨云应用部署方案,如 karmada/kubevela
    • 以 karmada 为代表的多集群 Deployment/Service 管理,需要一个控制面集群+多个子集群
      • 配置只往控制面集群部署,karmada 负责按配置在子集群中创建或更新对应的资源
  • 研究多云+多集群网络方案
    • 以 Istio 为代表的多集群服务网格,部署模型之一也是控制面集群+多个子集群
      • 配置只往控制面集群部署,istio 会将配置下发到数据面的 sidecar 与 gateway,完成相应的网络配置
    • 其他的如 karmada 等也集成了一些集群间的网络打通方案,但是感觉都还不太成熟
    • cilium 的 service mesh 也是一个潜在的多云 k8s 网络方案,但是还处于 beta 状态,有待观望
  • 研究云上 L4/L7 层网关的开源/商业方案
    • 如 L4 的 dpvs/katran 与 L7 的 APISIX/Traefik/Contour,以及 AWS Gateway LoadBalancer
    • 暂时认为云上 L4 还是直接使用云服务商的方案最合适,没必要自己搭
    • L7 为了支持多集群切量,同时尽量缩短链路,目前感觉使用 Istio 最合适
  • 研究各跨云网络方案(L7 负载均衡(ADC)、SD-WAN、WireGuard、服务网格等):
    • 一是多云之间相互隔离,但是长远看不太现实
    • 二是多云使用不冲突的 CIDRs 作为它们的 VPC 网段,然后使用 VPN 把多云网络直接串起来
    • 三是直接在多云上搭建一套 overlay 网络,完全屏蔽掉不同云之间的网络差异
      • 仅针对 k8s 的方案主要是 kilo,基于 wireguard 直接通过公网实现 overlay 网络,但是感觉时延很可能难以接受,还是得用 VPN 才行。
      • 整个云通用的方案目前只有部分供应商在做,而且不开源,有 vendor lock-in 的可能,而且不清楚封装出的具体效果如何
  • 动手学深度学习 - Pytorch 版 - 14.3%
    • 学习第二章:预备知识
      • 微积分:复习了单变量函数的微分(导数) => 多变量函数的偏微分,单变量函数的斜率 => 多变量函数的梯度(梯度,即函数 $f(x)$ 关于输入向量 $x$ 的所有偏微分组成的一个向量)
        • 深度学习模型的训练,即搜索出使损失函数的值最小的模型参数。而梯度下降是应用最广泛的一种损失函数优化方法。
        • 梯度下降,即始终朝着损失函数的梯度值下降的方向进行模型参数的搜索
        • 深度学习中的多元(变量)函数通常是复合的,而链式法则 $\frac{dy}{dx} = \frac{dy}{du} \frac{du}{dx}$ 使我们能够微分复合函数。
      • 自动微分:为了计算梯度我们必须要对函数进行求导,而手工求复杂函数的导数不仅容易出错,而且函数的更新也过于繁琐。深度学习框架通过提供自动微分能力解决这个问题。
        • 实际上,深度学习框架会构建一个计算图(computational graph)用于跟踪所有数值是由哪些操作生成的,有了这个计算图后,我们还可以通过数值反向去更新每个参数的偏导数,这被称为反向传播(backpropagate)。
        • 自动微分的另一个好处是,即使输入函数是一个由代码定义的黑箱,根本不清楚它的具体表达式,仍然可以通过反向传播自动计算出它的微分。
      • 概率论:
        • 采样
        • 随机变量的分析方法:联合分布、条件分布、Bayes 定理、边缘化、独立性假设
        • 概率分布的关键特征度量方式:期望、平方差/标准差
    • 学习第三章:线性神经网络
      • 线性回归模型是一个简单的单层神经网络,只有输入与输出两层
      • 学习了「从零开始实现线性回归」的一小部分
  • 动手学深度学习 - Pytorch 版 - 10.6%
    • 学习第二章:预备知识
      • 通过搜索 cheat sheet + 《Python for Data Analysis》学了下 Numpy/Pandas/Matplotlib 的使用方法
      • 复习线性代数
  • 动手学深度学习 - Pytorch 版 - 7.8%
    • 完成第一章前言,了解了深度学习是机器学习的一个分支,机器学习的用途、分类,深度学习的简单原理及优势,近十年此领域的爆炸式发展
    • 监督学习、无监督学习、强化学习
    • 音视频数据生成领域的重要方法:GAN
  • 分布式系统与区块链
    • 极客时间《分布式协议与算法实战》 - 40%
  • AI
    • 被 ACE 深度学习歌声合成激励到了,花了近两个小时简单学了点吴恩达的机器学习课程、微软的 ML for beginners,李沐的《动手深度学习》
    • 明确了目标是「快速学习,暂时只是为了玩一玩」,确定我应该通过《动手深度学习 - Pytorch》入门。
  • 极客时间《分布式协议与算法实战》 - 36%
  • 学习极客时间的《深入剖析 Kuberntes》 - 100%
    • 学完后第一次做测验,拿了 50 分,陷入自我怀疑 emmmm
    • 容器运行时
      • Kubelet 控制循环 SyncLoop 绝对不会阻塞,任何长时间任务都会创建新的 goroutine 来异步执行
      • CRI 的接口非常简单宽松,给予了底层容器运行时足够大的自定义空间
    • 云原生的发展方向
      • Kubernetes 的强大之处:声明式 API 和以此为基础的控制器模式将「政治」与「技术」拆分开的社区运作模式
      • Kubernetes 生态与传统 PaaS 的区别:Kubernetes 提供了基础设施层能力(编排、调度、资源管理等),使得其上的 PaaS 可以专注于应用服务和发布流程管理这两个最核心的功能,开始向更轻、更薄、更以应用为中心的方向进行演进。从而 Serverless 开始蓬勃发展
      • Serverless 的本质:高可扩展性、工作流驱动、按用量计费
      • 「云原生」是一个使用户能低心智负担的、敏捷的,以可扩展、可复制的方式,最大化利用“云”的能力、发挥“云”的价值的一条最佳路径。
  • 学习分布式系统的一致性问题与共识算法 并记录笔记
    • 一致性问题的核心是「ACID 理论中的事务一致性」,与「CAP 理论中的数据一致性」
      • 数据一致性又分为强一致性与弱一致性,而弱一致性的最低限度就是最终一致性:数据最终会一致(再低就永远不会一致了)
      • 最终一致性太模糊,具体实现上往往会最加上一些限定,得到许多一致性模型:读自己写一致性/写后读一致性、单调读一致性、前缀一致性、线性一致性、因果一致性
  • 学习极客时间的《深入剖析 Kuberntes》 - 87%
    • 简单学习了 CRD + Controller 的编写,包含 Informer 机制等。不过内容太老了,还是之后看 Programming Kubernetes 再详细学吧。
    • K8s API 资源的组织方式为 api/<apiGroup>/<GroupVersion>/<Resource>,yaml 中的 apiVersion<apiGroup>/<GroupVersion>,而 Kind 的值就是 <Resouce>
      • Pod/Node/configmap 等几个核心资源的 <apiGroup> 为空,因此可以直接省略掉
      • 其他核心资源都是以功能分类的,都有 <apiGroup> 属性
    • RBAC 是以 Role 为授权的基本单位,Role 的规则会指定用户对不同 apiGroups/Resources/resourceNames 可以执行哪些动作 verbs
      • apiGroups/Resources 属性跟前面介绍的 API 资源的组织方式是完全对应的,但是 Resources 需要使用复数形式,如 pods/configmaps/nodes
      • 如果是核心资源如 Pod/Node,则 apiGroups 应该设为空字符串 apiGroups: [""]
    • RoleBinding/ClusterRoleBinding 有两个部分:subjects 被作用者,以及 roleRef,用于声明这两者之间的绑定关系
      • subjects 被作用者可以是集群内的 ServiceAccount,也可以是外部定义的对象如 User
      • User 在集群中是一个不存在的对象,它的认证需要一台外部系统
    • RBAC 中还存在 Groups 用户组的概念
      • 比如任意名字空间中所有 serviceaccount 的用户组,名称为 system:serviceaccounts:<Namespace名字>
      • 每个 serviceAccount 的全名为 system:serviceaccount:<Namespace名字>:<ServiceAccount名字>
      • 我们可以在 subjects 中填写一个用户组,为整个用户组内所有的 ServiceAccount 授权
    • Kubernetes 中默认已经内置了多个 clusterrole,可通过 kubectl get clusterroles 查看
      • 开发测试时,我们可能会经常用的一个 clusterrole 就是 cluster-admin,这个 role 拥有整个集群的最高权限,相当于 root,非开发测试环境一定要谨慎使用它。
      • view/edit 这两个 clusterrole 分别拥有整个集群的查看/编辑权限
    • Kubernetes 存储
      • 存储的两个绑定阶段:
        • 第一阶段(AttachDetachController,运行在 kube-controller-manager 中),K8s 将 nodeName 传递给存储插件,插件将数据卷 attach 到该节点上
        • 第二阶段(VolumeManagerReconciler,运行在 kubelet 中),K8s 将 dir 传递给存储插件,插件将数据卷挂载到该目录下(如果是新数据卷还会提前格式化该卷)。
      • 云上 K8s 存储的一个缺陷:无法跨可用区调度。如果你通过 affinity 强制把一个 p8s 调度到别的可用区,因为它的数据卷不在目标可用区,这会导致它无法被调度,卡在 Pending 状态。
      • 学习了已被废弃的 FlexVolume 的实现方式,以及它的替代者 CSI
      • csi-digitalocean 为例,学习了一个 CSI 插件的实现原理
    • Kubernetes 调度
      • 根据容器的 requests/limits 参数,k8s 将 Pod 分为三种类型:BestEffort Burstable Guaranteed
      • 在因为资源不足而触发驱逐 Evection 时,会按 BestEffort => Burstable => Guaranteed 的顺序进行驱逐
      • 当 Pod 中所有容器的 requests/limits 都相等的时候,Pod 的 QoS 等级为 Guaranteed
        • 如果这时容器的 cpu requests 为整数值,K8s 会自动为容器进行绑核操作,这可以大幅提升容器性能,常用在在线应用场景下
        • 疑问:如果 istio sidecar requests/limits 不相等,但是应用容器是设的相等的,这种情况下是否会执行绑核操作呢?
      • Pod 的优先级与抢占机制
        • 首先创建不同优先级的 PriorityClass,然后为 Pod 指定 priorityClassName
        • 调度失败的 Pod 会被放到 unschedulableQ 中,这会触发调度器为这些调度失败的 Pod 寻找牺牲者的逻辑
        • 基于优先级与抢占机制,创建一些优先级为 -1 的占位 Pod,可以实现为整个集群预留一部分资源。这种方法被称为「Pod 空泡」资源预留法
      • Device Plugin: 负责管理集群中的所有硬件加速设备如 GPU/FPGA 等
        • Device Plugin 只能基于「数量」进行调度,无法进行更复杂的异构调度策略,比如「运行在算力最强的节点上」
      • 日志与监控:对我来讲,没什么新东西
      • 容器运行时
        • gVisor - 在用户态重新实现了一遍 Linux ABI 接口、网络协议栈,启动速度跟资源占用小。但是工程量大,维护难度大,对于系统调用密集的应用,性能会急剧下降。
        • kata containers: 据说是性能比较差,运行了一个真正的 Linux 内核与 QEMU 虚拟设备实现强隔离
        • aws firecrackers: 跟 kata containers 的思路一致,但是使用 rust 实现了自己的 vmm,性能更高
  • 了解到 2021 年是区块链投资大涨的一年,总投资涨了 7 倍多到了 252 亿美元,NFT 更离谱直接从 2020 年的 37m 涨到 4802m 美元,感觉确实非常有前景
  • 分两次从币安转了 0.01 ETH + 0.05 ETH 到 Ethereum,币安收了固定手续费 0.0016 ETH * 2
    • 购买 ENS 域名 thiscute.eth 10 年并设为我的主域名,花了约 0.027 ETH,算上 gas 费一共花了 0.0321 ETH 也就是 67 刀
  • 给自己再次整了一个 mirror.xyz 账号,有了 ENS 就是爽。
  • 但是发现我现有的几个域名如 thiscute.world,其实可以直接通过 DNSSEC 导入到 ENS,感觉血亏 0.027 ETH…
  • 阅读郭宇最近写的《Web3 DApp 最佳编程实践指南》
    • 晚上去测核酸的路上还参与了他开的一个 twitter space 聊 web3 开发,发言的很多大佬,很多干货。
    • 也明确了,目前区块链还处于战国时代,百家争鸣
  • 再次确认今年学习路线,精简与调整之前年度的计划(之前的计划太多了搞不定,而且当时没排区块链)
    • 先学好分布式原理与算法这块
    • 然后是 Kubernetes 编程,同时结合极客兔兔的几个教程深入学习 Go
    • 深入学下 Go 语言底层
    • 搞一搞区块链
    • 学习 C 语言
    • 通过 TLPR 学习 Linux 系统
    • 通过 CS144 系统学习计算机网络
  • 阅读 Web 3.0:穿越十年的讨论 - 知乎 系列内容,了解 Web 3.0
  • 阅读 dcbuild3r/blockchain-development-guide,了解如何进行区块链开发
    • 我把这个 guide 完整过了一遍(后面关于自我提升、社会影响力啥的仅走马观花看了看),真的好长的一篇文章啊。
    • 很多干货,现在我对搞区块链开发要学的东西,认知更清晰了。
  • 迭代博客内容《关于 NAT 网关、NAT 穿越以及虚拟网络》- 90%
    • 真的低估了 NAT 网关与 NAT 穿越技术的知识量,又折腾了一个晚上,文章还没完成…
    • 5/9 的时候我就觉得文章已经完成了 90%,结果今天又折腾了一晚上迭代了大量内容,现在感觉文章的进度还不到 90%…越学发现自己懂得越少
  • 学习极客时间的《深入剖析 Kuberntes》 - 53%
    • 学习了 NetoworkPolicy、kube-proxy 的实现原理,其实都是用 iptables 实现的,原理挺简单的。
    • 不过 kube-proxy 很早就支持了 ipvs 模式,它在大规模场景下比 iptables 性能更好一些。但是 AWS EKS 目前官方仍然并不支持 ipvs 模式,打开可能会有坑。
  • 极客时间《分布式协议与算法实战》 - 4%
    • 过了一遍常见共识算法的名字:两阶段提交、Try-Confirm-Cancel、Paxos、ZAB、Raft、Gossip、PBFT、PoW、PoS、dPoS
    • 过了一遍上述共识算法的特性:是否支持拜占庭容错、支持哪种程度的一致性、性能、高可用性
  • 了解了一些区块链相关公司的方向,区块链开发岗位的要求
  • 还研究了一波性能测试工具:grafana/k6
  • 学习极客时间的《深入剖析 Kuberntes》 - 48%
    • 复习了 Linux 虚拟网络接口以及容器网络原理、学习了 CNI 网络插件的原理
    • 学习了两个 underlay 网络实现:flannel 的 host-gw 模式实现原理、calico 基于 BGP 的实现原理
    • calico 在跨 vlan 时需要使用 IPIP,学习了相关原理
  • 完成博客《关于 NAT 网关、NAT 类型提升、NAT 穿透以及虚拟网络》- 90%
    • 简单研究了 Go 的 STUN/TURN/ICE 库,以及 coturn server
  • 简单学习了零知识证明的应用,zk-SNARKs,区块链混币服务,以及拜占庭将军问题
  • 完成博客《关于 NAT 网关、NAT 类型提升、NAT 穿透以及虚拟网络》
    • 已发布,但是还有些细节需要填充,另外还需要补些示意图
  • 学习极客时间专栏《深入浅出 Kubernetes》 - 37%
    • 主要学了下 Pod 的结构、名字空间共享等细节信息,这部分我以前只了解个大概
    • 集群安装、Deployment、StatefulSet、Service 这几个部分我都已经比较熟了,走马观花看了看。
    • 粗略过了下目录,其中对我而言最有价值的,应该就是容器网络、调度器、容器运行时
  • 学习极客时间专栏《深入浅出 Kubernetes》 - 20%
    • Kubernetes 与其他败北的编排工具比,最大的优势在于它的设计思想:
      • 从更宏观的角度,以统一的方式来定义任务之间的各种关系(最底层是 Pod 与 PV,之上是各种控制器、亲和反亲和、拓扑扩散、自定义控制器,网络侧有 service,底层网络插件等等),并为将来支持更多种类的关系留有余地(开放、强大的自定义能力催生出了丰富的生态)
      • 基于状态的声明式配置,由控制器负责自动达成期望的状态
  • 研究 FinOps 与 kubecost,总结工作上的经验,完成一篇 Kubernetes 成本分析的文章 - 100%
  • 研究 FinOps 与 kubecost,完成一篇 Kubernetes 成本分析的文章 - 50%
  • 学习极客时间专栏《深入浅出 Kubernetes》,复习容器技术(Namespace/Cgroups/rootfs)
    • Docker 最核心的创新:
      • 将 rootfs 打包到镜像中,使镜像的运行环境一致(仅与宿主机共享内核)
      • 使用 Dockerfile 描述镜像的打包流程,使构建出的镜像可预期、可重新生成
  • 2022-04-28 调薪结果出来了,突然觉得身心都有点累了,有点惆怅。总之还是继续努力吧,技术才是我的核心竞争力,少管他什么妖风邪雨。
  • 完成了 19 年创建的 go 项目:https://github.com/ryan4yin/video2ascii
  • 失眠,半夜随便翻了翻,把《Go 程序设计语言(英文版)》走马观花过了一遍
  • 阅读 Programming Kubernetes - Developing Cloud Native Applications - 进度 7%
    • 主要是通过案例讲解 CRD Operator Controller 等 Kubernetes 编程技术
  • 阅读《Go 程序设计语言(英文版)》 - 进度 90%
    • 目前还剩两章未读:反射 reflection 与底层编程 unsafe/uintptr
  • 阅读《Go 程序设计语言(英文版)》 - 进度 72%
    • 主要完成了 goroutines/channels 以及「并发与变量共享 sync」两个章节
  • 多抓鱼买的一批新书到手了,大致读了下几本书的前几页。
    • 目前比较感兴趣的有:《复杂》、《陈行甲人生笔记》、《原则 - 应对变化中的世界秩序》、《这才是心理学》
    • 打算首先读《复杂》
  • 使用 kubernetes/autoscaler 实现集群弹性扩缩容
    • 发现社区的这个工具(简称 CA),确实没 aws 出品的 karpenter 好用。
    • CA 自身的实现很简单,主要是依靠 AWS ASG 实现扩缩容。
    • 而 EKS 的 NodeGroup 说实话做得太垃圾了,底层 ASG 的很多功能它都不支持,一旦创建很多参数(VPC 参数、实例类型、等等)就无法通过 EKS NodeGroup 变更了。如果越过 EKS NodeGroup 直接修改底层的 ASG 配置,它还会提示「Degraded」说配置不一致,真的是无力吐槽。
  • 《在生命的尽头拥抱你-临终关怀医生手记》 - 进度 73%
  • 使用 aws/karpenter 实现集群弹性扩缩容
    • 已上线 prod 环境,目前给 EMR on EKS 集群专用。
  • 更新 /now 页面以及 knowledge 的内容
  • 研究使用 aws/karpenter 实现集群弹性扩缩容
  • 阅读《Go 程序设计语言(英文版)》 - 进度 53%
    • 第 7 章「接口」读了一半,大概 22 pages,预计明天能完成
  • Operating Systems - Three Easy Pieces
    • 读到 Introduction 一章,行文真的很有趣,看 projects 也有深度,决定了要把这本书看完,把习题做好。
    • OSTEP 后面的部分会涉及 vx6 源码,这要求比较深的 C 语言知识以及 x86 汇编知识,不过这些可以在学到的时候,再做补充。
    • 在需要用到的时候,学习 CSAPP 的 x86 汇编部分会是一个比较好的补充。
  • 阅读《Go 程序设计语言(英文版)》 - 进度 7/13
  • 《在生命的尽头拥抱你-临终关怀医生手记》 - 进度 61%
  • 重新整理书单,放到 /now 页面中
  • 学习 NAT 原理知识
  • 阅读《Go 程序设计语言(英文版)》 - 进度 5/13
  • 阅读《Go 程序设计语言(英文版)》 - 进度 4/13
  • 阅读《Go 程序设计语言(英文版)》 - 进度 3/13
  • 学习 3D 引擎的使用,简单试用了 unity3d 与 unreal engine 5.
    • 确定学习方向:先学学 UE5 蓝图入个门,然后试试把 MMD 模型导入到 UE5 做做动画,中间也会简单接触下 Blender.
    • 感受:UE5 挺不错的,尤其是它还提供 VR 编辑模式,手上的 Quest 2 又能派上用场了
    • 输出文档:3D 图形相关
  • 阅读《Go 程序设计语言(英文版)》 - 进度 2/13
    • 第一章「导览」大概过了下 Go 的关键特性:完善的工具链,丰富的标准库,goroutine, channel
    • 第二章主要讲程序结构,包含变量、类型声明、指针、结构体、作用域、包与文件结构等等
  • 阅读《在生命的尽头拥抱你-临终关怀医生手记》
  • 在 Manager 的帮助下申请职级晋升(初级 => 中级 SRE)
    • 再一次认识到我自己写的文字有多么随意… Manager 帮我提炼补充后,文字变得言简意赅,精确客观,瞬间高大上档次了。
  • 《写给开发人员的实用密码学》
    • 完成第七篇「非对称加密算法」的 ECC 部分,并为 RSA 部分补充了部分 Python 代码
    • 将去年写的文章《TLS 协议、TLS 证书、TLS 证书的配置方法、TLS 加密的破解手段》改写并补充内容,改名为《写给开发人员的实用密码学(八)—— 数字证书与 TLS 协议》
    • 为第五篇「密钥交换」补充了 DHKE/ECDH 的代码示例,另外还补充了 DHE/ECDHE 一节
    • 此系列文章的其他小修改与润色
  • 业务大佬在 gRPC 的基础上再添加了 gzip 压缩,TX 流量再次下降 80%+
    • 侧面说明以前业务侧对 HTTP 的用法是多么豪放 emmmm
    • 周末上 gzip 压缩功能,业务大佬太肝了啊…
  • 发布《写给开发人员的实用密码学》系列第七篇:非对称加密算法,但是暂时只完成了 RSA 部分
  • 跟推荐系统大佬一起将服务从 HTTP 切换到 gRPC,效果立竿见影,服务流量下降 50% ~ 60%,延迟下降 30% ~ 50%
    • 提升了服务性能,降低了 AWS 跨区流量成本
  • 发布《写给开发人员的实用密码学》系列的第六篇:对称加密算法
  • 深圳疫情形式严峻,开始居家办公
  • 整理润色后,发布《写给开发人员的实用密码学》前五篇的内容
  • 发现我们的 EKS 集群主使用的是 AWS Spot 实例,这类实例的 c6i/c6g 性能与价格差距并不高,做 ARM 化的 ROI 貌似并不高
  • 发现对 aws 的 RDS/EC2-Volume/Redis 等资源进行全面评估,删掉闲置资源、缩小实例/集群规格,可以轻易节省大量成本(说明以前申请资源时风格比较豪放 2333)
  • 继续迭代个人博客
  • 迭代我的独立博客 https://thiscute.world
    • 添加「阅读排行」页,定期从 Google Analytics 同步数据
    • 从博客园迁移部分有价值的文章到独立博客
  • 购入 Synthesizer V + 青溯 AI 声库,简单调了几首歌试试,效果非常棒。
  • 也调研了下歌声合成领域目前的进展,试用了免费的移动端软件 ACE 虚拟歌姬,渲染效果真的媲美 CNY 999 的 SynthV AI 套装,不得不感叹 AI 的效果真的强啊。
  • 了解 APISIX/Nginx/Envoy 中的各种负载均衡算法,及其适用场景、局限性。
  • 练习二个半小时轮滑,学会了压步转弯技术
  • 无聊,但是又啥都不想干,耽于网络小说…
  • 感觉有点现充了,感觉需要找个更明确的、能给人动力的目标
    • 做个三年的职业规划以及生活规划?
  • 轮滑:复习前双鱼、前剪、前蛇,尝试侧压步、倒滑
  • 将上次 EKS 升级过程中,有问题的服务迁移到 1.21 的 EKS 集群,直接切线上流量测试。
    • 复现了问题,通过 JFR + pods 数量监控,确认到是服务链路上的个别服务频繁扩缩容导致的,这些服务比较重,对扩缩容比较敏感。
    • 测试在 HPA 中添加 behavior 降低缩容速率,同时添加上 PodDisruptionBudget 以避免节点回收导致大量 Pod 被回收,经测试问题基本解决。
  • 遭遇 AWS EKS 托管的控制平面故障,controller-manager 挂了一整天。现象非常奇怪,又是第一次遇到,导致长时间未排查到问题。
    • 确认问题来自 HPA behavior 的 Bug
      1. 储存于 etcd 中的 object 仅会有一个版本,透过 apiserver 读取时会转换成请求的 autoscaling API 版本。
      2. autoscaling/v2beta2 scaleUp 及 scaleDown 对象不能为 null,并在其 Kubernetse 代码可以查看到相应的检查机制。
      3. 当使用 autoscaling/v1 时,v2beta2 版本中的相关对象字段将作为 annotation 保留,apiserver 不会检查 ScaleUp/ScaleDown 的 annotation是否为 non-null,而导致 kube-controller-manager panic 问题。
      4. 我们可以使用 v1 或 v2beta2 创建一个 HPA 对象,然后使用 v1 或 v2beta2 读取、更新或删除该对象。 etcd 中存储的对象只有一个版本,每当您使用 v1 或 v2beta2 获取 HPA 对象时,apiserver 从 etcd 读取它,然后将其转换为您请求的版本。
      5. 在使用 kubectl 时,客户端将默认使用 v1(kubectl get hpa),因此我们必须明确请求 v2beta2 才能使用这些功能(kubectl get hpa.v2beta2.autoscaling)
      6. 如果在更新 v1 版本的 HPA 时(kubectl 默认用 v1),手动修改了 v2beta2 功能相关的 annotation 将 scaleUp/scaleDown 设为 null,会导致 controller-manager 挂掉.
  • 跟公司冲浪小分队,第一次玩冲浪,最佳成绩是在板上站了大概 6s…
  • 将 EKS 集群从 1.17 升级到 1.21(新建集群切量的方式),但是遇到部分服务迁移后可用率抖动。
    • 未定位到原因,升级失败,回滚了流量。
  • 学习极客时间《10X程序员工作法》
    • 以终推始
    • 识别关键问题
    • ownership
  • EKS 集群升级
    • 了解 EKS 集群的原地升级的细节
    • 输出 EKS 集群原地升级的测试方案,以及生产环境的 EKS 集群升级方案
  • 学习使用 kubeadm+containerd 部署 k8s 测试集群
    • 涉及到的组件:Kuberntes 控制面、网络插件 Cilium、kube-proxy、coredns、containerd
  • 思考我在工作中遇到的一些非技术问题,寻找解法
    • 效率:如何在没人 push 的情况下(没有外部压力),维持住高效率的工作状态(早早干完活下班它不香么?)。
      • 建立有效的「自检」与「纠错」机制
        • 自检:
          • 列出目前已知的「异常」和「健康」两类工作状态,每日做一个对比。
          • 每日都列一下详细的工作计划,精确到小时(预留 1 小时 buffer 应对临时需求)。
    • 沟通:遇到问题(各种意义上的问题)时,及时沟通清楚再继续推进,是一件 ROI 非常高的事。否则几乎肯定会在后面的某个节点,被这个问题坑一把。
    • 目前的关键目标是啥?存在哪些关键问题(实现关键目标最大的阻碍)?我最近做的主要工作,是不是在为关键目标服务?
    • 如何把安排到手上的事情做好?
      • 思考这件事情真正的目标的什么?
        • 比如任务是排查下某服务状态码有无问题,真正的目的应该是想知道服务有没有异常
      • 达成真正的目标,需要做哪些事?
        • 不仅仅状态码需要排查,还有服务负载、内存、延迟的分位值,或许都可以看看。
      • 跟需求方沟通,询问是否真正需要做的,是前面分析得出的事情。

这些问题都是有解法的,关键是思路的转换。


  • 容器底层原理:
    • linux namespace 与 cgroups
    • linux 虚拟网络接口 macvlan/ipvlan、vlan、vxlan

  • 阅读 rust 语言的官方文档:the book
  • 边读文档边做 rustlings 的小习题
    • 目前完成了除 macros 之外的所有题
    • 遇到的最难的题:conversions/{try_from_into, from_str}
  • 使用 rust 重写了一版 video2chars

  • Linux 的虚拟网络接口
  • Linux 的 netfilter 网络处理框架,以及其子项目 iptables/conntrack

  • 学习 nginx - openresty - apisix
  • 工作中,在自己负责的领域,建立起 ownership
  • 学习新公司的工作模式:OKR 工作法
  • 学习新公司的思维模式(识别关键问题)
    • 如何从公司的角度去思考问题,找到我们目前最应该做的事情
    • 从以下角度去评价一件事情的重要性
      • 这件事情对我们目前的目标有多大帮助?
      • 需要投入多少资源和人力?
      • 在推进过程中,有哪些阶段性成果或者 check point?