摘抄自 《SRE: Google运维解密》
字字珠玑。
继续阅读“琐事繁多是不是一定不好?”
什么是一流的技术文章？
这两天读Google的《SRE》时看到一段话
今天，我们能感受到整个行业都在鼓吹厚颜无耻的"代码拿来主义"(just show me the code)。开源社区内部正在形成一种"不要问我问题"的风气.............这本书中没有万能药，没有什么东西能解决一切问题，但是这恰恰是本书的宗旨：相比最后的软件结果，架构设计而言，真实的设计过程，作者本身的思考经历更有价值。实现细节永远只是短暂存在的，但是文档化的设计过程却是无价之宝。 -- 《Google SRE 运维解秘》
深以为然，不禁让我想到了过去学习张磊老师《深入剖析Kubernetes》时曾看到张磊老师回复课后留言时说过的一句话
直接讲源码是不负责任也是逃避困难的做法。（大意）
什么是一流的技术文章？绝不是一上来就开始贴源码画流程图深入到每一个函数。
相比具体的实现，掌握其思想，掌握其设计理念---为什么这样设计？架构为什么这样演进？更为重要。当然，要能将这些理念和演进历程传授给读者，更需要扎实的技术和文字功底。这远比上来就连篇累牍贴源码更困难也更有意义。
Talk is not cheap.
向每一个真诚分享的技术人致谢。
使用kubefwd对k8s中的service进行本地化调试
大家都知道,k8s中的服务(service)是对k8s中的deployment等对象的一个一致访问点.所以service会有一个vip(headless service没有).无论是普通service的vip或者headless service的pod ip其实都是k8s集群中的内部ip,在集群内访问它是非常容易的.比如有一个service叫nginx,我们在集群内的另一个pod里既可以对这个nginx service的vip进行get访问,也可以通过coredns对这个nginx service的域名如(nginx, nginx.default等)进行访问.但是在集群外呢?这就麻烦了.
常见的集群外访问service的方式大致分为 LoadBalance, NodePort, ExternalIp等方式, 再细致一点也可以通过Ingress在7层做一层分发再外接上述流量接入,甚至你可以直接将api server做proxy. 很显然的，这些方式如果在我们只是需要对服务进行调试或者随便用用的场景都是要么太复杂(Ingress), 要么花钱(LoadBanlence),要么不靠谱(NodePort).
这时候你会说,嗷,我们可以使用kubectl port-forward 功能,将service的端口port-forward到本地端口.对，没错，这确实是一个不错的解决方式，但这仍然存在非常多的问题。
比如,我们并不想要将nginx service的80端口port-forward到我的8080端口上，就想用80端口，那么如果有两个service分别叫nginx1和nginx2，这不就没法弄了吗？再比如，如果我们port-forward的svc的pod发生了变动,怎么办？再比如,我们就是想像在集群内一样，通过service的内部域名对其访问(nginx, nginx.default等)，怎么办？再比如，如果我们有100个服务，难道我们要手动对每个服务port-forward然后手动选择一个没用过的端口吗？甚至，当我们的服务创建,删除,我们又得手动操作,这是何等的麻烦？
基于上述问题,一个叫kubefwd的工具出现了。
继续阅读“使用kubefwd对k8s中的service进行本地化调试”