丰年留客的专栏

问题的解决过程中尝试了多种方案，最终最适合的方案巧妙运用了命名空间隔离机制，这也是了解容器底层原理的好处。容器内不希望被宿主机影响。容器内不期望影响宿主机（本文中的场景），可随意设置/etc/resolv.conf。

是控制协程行为的利器，既然是利器，那么用得好可以取得非常好的效果，用的不好，反手就可能伤了自己。最近遇到的一个问题，HTTP请求发给Server后，对应的context取消掉之后，请求被Server正常处理了，但客户端因为Context被取消，认为请求失败了。当Request中的Context有设置时，这个Context会影响到HTTP的结果，如果你不期望Context取消时影响到具体的HTTP请求，那么就不应该设置这个参数。默认不设置时，Context的取消不会终止掉具体的HTTP请求。

作为开发人员，直觉很重要，有时可以省掉很多麻烦。想起来多年前使用某一个打车软件时，在午夜时，好像是看到估算的行程时间有点错乱，直觉告诉我，这是个corner case就是边界场景，很容易出问题。同样的，这次遇到的小问题，属于很少有人直接这样的用场景，既然很少有人用，它的顺畅性没经过验证，出问题的可能性就大了。

经过插件的请求的各拦截点见官方文档：https://apisix.apache.org/docs/apisix/architecture-design/apisix/需要重启apisix容器，但脚本都是在容器镜像里的。一开始未理解check_schema的作用，未实现它，结果发现在schema中定义的默认参数并没有生效。apisix的默认日志等级是warn级别，也就是说你在lua中加的info级别是在apisix日志中看不到。可以这样：把脚本的目录挂载到Pod里，然后修改脚本后，重启Pod就行了。

0x01 背景之前有关注bazel相关的技术动态，自己也做了一些研究。最新看k8s源码时，突然发现没有了bazel相关的配置，猜测是把bazel移除了，去github上搜索了下。确认确实是移除了。最初的提案链接为：https://github.com/kubernetes/kubernetes/issues/88553，感兴趣的可以直接去看，讨论很热烈。主要是想看下顶级项目面对这种取舍（trade-off）问题时是如何决策的。0x02 移除的理由提案作者的理由：go tool chain本身支

0x01 member成员管理用来动态调整Etcd集群中的成员。支持如下操作：add 添加list 列举promote 提升remove 移除update 更新member add--learner 允许以Raft Learner角色加入Etcd集群，该节点不参与Raft选举投票，只同步Leader的数据。--peer-urls 要加入的新节点的URL列表。member list无选项，查看集群的成员列表。member promote将指定的非投票member提升为

apiserver设计比较复杂，直接去看源码效果较差。尝试从特性角度梳理其设计背后的考量。了解一个服务最好的入口就是看它的选项。选的版本是v1.21.5。0x01 选项选项分为如下几类：*通用标志(Generic flags)*与Etcd相关的配置安全配置审计配置特性配置认证配置授权配置云提供商配置API开关配置网络出口配置准入配置metrics配置，用于监控*日志配置*其他杂项配置加*的为影响性能的参数。为重点学习项。0x02 详细各部分配置2.1 通用配置看

0x01 功能分类Etcd作为一个分布式一致性的KV存储组件，现在的功能远不止于KV存储了。详细了解下其功能特点有利用在使用它时，做出最合适的选择。通过etcdctl -h命令可以看到有如下的特性。基本的KV操作 get put txn del watch数据操作 分片defrag 压缩事件 compaction端点管理 endpoint租期管理 lease锁 lock选举 elec成员管理 member转移leader move-leader角色管理 role快照管理 snaps

云原生模式书名《云原生模式》，副标题：设计拥抱变化的软件。如下格式为文中原文。这是书中的原文云原生，英文为Cloud Native。直译为，云原住居民。天空中云距离我们很远，不停的变化。用“云原生”可以形象化地领会其特点。感觉这本书是“事后诸葛亮”，已经有了k8s的前提下，对k8s中设计考虑的点进行汇总拔高，形成了云原生的概念。当然还是能帮助大家理解云原生的一些理念，还是值得学习的。第一章 什么是“云原生”换一种角度去理解应用的生命周期。传统的大型服务可以长时间运行，不需要（不敢）变更。传