Leosocy's Blog

k3sCNCF Landspace Why k3s production-ready，完全通过CNCF认证的Kubernetes产品 完全实现了k8s的接口，意味着仍旧可以使用kubectl控制集群，学习成本低 移除了k8s中一些只有在大型集群才用得到的组件，比如默认使用SQLite替代ETCD，同时将这些driver做成可配置的 安装包只有40mb，并且包含所有需要的底层组件，例如containerd、runc等 CPU/Mem资源占用低，适合边缘设备（例如IOT/RPI等）运行 k3s的名字怎么来的：We wanted an installation of Kubernetes that was half the size in terms of memory footprint. Kubernetes is a 10-letter word stylized as K8s. So something half as big as Kubernetes would be a 5-letter word stylized as K3s. There is no long for ...

烧录系统镜像下载镜像由于笔者用的是4B 8G版，所以镜像选择arm64（2021-05-07-raspios-buster-arm64.img）。 官网下载速度太慢，所以我们选择了清华源。 使用命令行烧录在MacOS上烧录镜像有两种方式 使用Raspberry Pi Imager，优点是使用简单 命令行模式，使用dd命令 作为爱折腾的程序员，当然是选择命令行模式了，还可以顺便研究下启动镜像的原理 diskutil list找到SD Card所在磁盘号 N diskutil unmountDisk /dev/diskN，只有当成功卸载后，才可以使用dd将镜像文件写入SD Card，否则会报Resource busy错误 sudo dd bs=1m if=/Users/leosocy/Downloads/2021-05-07-raspios-buster-arm64.img of=/dev/rdiskN; sync 将上面的N替换为SD Card对应的序号 稍等几分钟之后，镜像烧录完成， 3564+0 records in3564+0 records out373712486 ...

把知识看作是一颗语义树，在进入叶子（细节）之前，先确保自己理解了基本原理，也就是这颗树的树干和大的树枝，然后再深入到树叶，否则的话那些树叶和细节将会无处栖身，导致很快凋落（遗忘）。随着工作经验的增长，愈发觉得很多技术背后的基本原理都是相通的，所以基于这些原理构建自己的知识体系是尤为重要的，这样才能更好地做到接（学习）、化（理解）、发（创造）。

为了节约物理内存，减少进程创建时资源和时间的消耗，父进程在调用fork()生成子进程时，子进程与父进程会共享同一内存区。只有当其中一进程进行写操作时，系统才会为其另外分配内存页面。这就是写时复制机制(copy on write)的意思。那么Linux内核是如何实现这种机制的呢，今天我们来简要的分析一下。 fork系统调用流程sys_fork -> _do_fork(SIGCHLD, 0, 0, NULL, NULL, 0) -> copy_process() -> copy_mm(clone_flags, p) static int copy_mm(unsigned long clone_flags, struct task_struct *tsk){ struct mm_struct *mm, *oldmm; ... if (clone_flags & CLONE_VM) { mmget(oldmm); mm = oldmm; goto good_mm; } ...

最近线上的一个张表频繁的报慢查询告警，看了下日志发现一条语句执行要几秒钟，这还是在用了LIMIT的前提下，导致相关接口超时，一个功能对数据量大的用户完全不可用。COUNT了下这张表，一共有400多万的数据，EXPLAIN了慢日志SQL，发现走的索引并不是按照预期的更快的那一个，并且由于分段查询产生了filesort。那么MySQL选错索引的原因是什么呢？这个SQL有没有优化的空间呢？优化的效果如何呢？ 问题重现为了脱敏，我们先建一张与线上数据结构相同的表t，这张表有两个联合索引，其中一个为唯一索引，另一个为普通索引。 CREATE TABLE `t` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` bigint(20) NOT NULL, `group_id` int(11) NOT NULL, `a` int(11) NOT NULL, `b` int(11) NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_t_user_id_group_id_a` (`user_i ...

当产品用户量、日活与日俱增，后端数据库的负载通常也会越来越大，此时单纯的增加索引已经无法解决亿级数据的CRUD操作了。通常我们会选择分库+分表来解决数据库的瓶颈。使用proxy可以做到对业务层透明，业务无需关心数据库如何shard，SQL如何分发数据如何聚合。我们自己的业务使用的是kingshard这个用Go实现的开源数据库代理，然后ORM一直使用的是peewee。在使用的过程中遇到了一些稀奇古怪的问题，这里记录一下排查的过程，以及其中的具体原因，最后给出可行的解决方案。 准备根据kingshard官方文档，在本地搭建具有两个Node的数据库‘集群’。同时创建好test_shard_hash分表，这里我们以user_id作为shard_key。 mysql root@localhost:ks1> show create table test_shard_hash_0001;+----------------------+-------------------------------------------+| Table | Create Table ...

图片转自这里** 以前就一直听说事件模型中，epoll比select的效率高出一个量级，epoll的一些优点网上也有很多的文章阐述解释。但是至于为什么epoll如此高效？内核是怎么实现的？我并没有深入研究，所以为了更加深入的了解epoll，近期一直在研究epoll的内核源码（头一次读内核源码还是有些吃力）。大致弄懂了实现原理后才发现，网上的一些解释有的并不是很准确。本篇文章概括了epoll的实现机制，并引出epoll中的惊群问题以及一些解决方法。 Linux epoll实现机制对于具体实现分析网上已经有很多文章阐述了，我就不再这里赘述。这里贴一篇文章，我觉得说的很清楚并且是按照源码分析的。 简单来说epoll的实现主要有以下几个逻辑 epoll_create: 创建epollevent结构体并初始化相关数据结构。创建fd并绑定到epoll对象上。 epoll_ctl: 从用户空间拷贝event到内核空间，创建epitem并初始化，将要监听的fd绑定到epitem 通过监听fd的poll回调，设置等待队列的entry调用函数为ep_poll_callback，并将entry插 ...

最近在查证一个生产环境上Pod数据打点没有被记录到ES的问题，起初怀疑是Docker容器的输出缓冲区问题导致打点输出还没有写入日志文件上，所以查了很多关于python输出缓冲、标准输入输出缓冲、容器日志缓冲相关的知识。尽管最后问题定位到了并不是因为输出缓冲引起的，但是还是在此记录下经过一些测试以及资料阅读了解到的Linux下I/O的buffer机制。不想看验证过程的老铁们可以查看结论。 Linux下的三种缓冲模式 unbuffered: 顾名思义，不缓冲输入输出，有多少读写多少 fully-buffered: 当缓冲区被填满时，发生一次flush line-buffered: 遇到换行(一般就是’\n’)或者当缓冲区满时，发生一次flush 那每种模式对应哪些场景呢？接下来我们用python程序做一些验证。 不同缓冲模式下的一些测试与终端相关联的stdin/stdout什么是终端？。简单来说可以是本地打开terminal/xTerm，或者ssh连接远程主机。 有下面一小段代码，执行后会发生什么呢？ import sysimport timewhile True: sys.s ...

上一节，笔者介绍了如何通过frp暴露内网的k8s集群，并在公网操作集群。通过frp我们可以将来自公网的请求路由到内网的指定端口，这种方法可以结合service的NodePort部署方式来简单的暴露集群中的服务，甚至可以基于frp的location路由功能，将请求根据不同路径路由到不同的svc上。想想目前的功能可以cover住基本的需求，但是如果仅仅这样我们就无法利用k8s的强大特性了(服务发现/负载均衡/限流等等)。 本篇文章会将Istio引入集群，并通过示例展示如何将https请求路由到内部的服务中去。