Apache Dubbo 有injvm方式的通信，能够避免网络带来的延迟，同时也不占用本地端口，对测试、本地验证而言，是一种比较方便的RPC通信方式。 最近看到 containerd 的代码，发现它也有类似的需求。但使用ip端口通信，有可能会有端口冲突；使用unix socket，可能会有路径冲突。考察了下gRPC有没有和injvm类似的，基于内存的通信方式。后来发现pipe非常好用，所以记录了下

当我们通过kubectl来查看、修改Kubernetes资源时，有没有想过后面的接口到底是怎样的？有没有办法探查这些交互数据呢？ Kuberenetes客户端和服务端交互的接口，是基于http协议的。所以只需要能够捕捉并解析https流量，我们就能看到kubernetes的API流量。 但是由于kubenetes使用了客户端私钥来实现对客户端的认证，所以抓包配置要复杂一点。具体是如下的结构： 如

重点：1.24版本的k8s将不会自带dockershim，即默认不支持docker作为容器运行时了。现在可以给Kubernetes反馈相关信息了：https://forms.gle/svCJmhvTv78jGdSx8。 Mirantis单独维护了dockershim组件，仍然可以使用：https://github.com/Mirantis/cri-dockerd 正文： 去年我们宣布Docker

最近在看containerd的代码，上手试的时候才发现它监听的是unix socket，没法从外部访问containerd。而我要验证的是从远端能不能访问containerd、管理containerd的容器，所以需要一个从远端访问unix socket的工具。 网上搜了一圈，没有现成的实现，就自己写了 sockfwd。 用法1234567Usage: sockfwd [flags]Flags:

2021年8月31日，Docker公司更改了收费策略，简而言之就是对个人和小公司不收费，对大公司收费。 那么，是时候开始试一下 containerd + lima这个开源、免费的Docker替代品。 什么是containerd？containerd是一个标准化的容器运行时，可以被其他系统很方便的集成。正是由于这个原因，containerd也成为了Kubernetes的默认容器运行时。 但是在con

最近升级Maven到3.8.1后，mvn编译的时候总是提示拉不到依赖，报错如下： Could not validate integrity of download from http://0.0.0.0/... 全部报错如下： 12345678910111213141516[WARNING] Could not validate integrity of download from http://

背景最近在写Go，有一个项目是多模块的，版本的发布都是在一起的，为了其他项目使用这些模块，所以需要在一个仓库中实现多个模块的发布。 仓库结构仓库结构如下： 12345678.├── README.md├── a│   ├── a.go│   └── go.mod└── b ├── b.go └── go.mod 其中a/go.mod使用如下命令生成： 1go mod init git

前言最近在排查一个eureka问题，发现客户设置了环境变量eureka.client.serviceUrl.defaultZone。于是在本地尝试复现这个现场，发现我设置不了这个环境变量，提示： 12# export eureka.client.serviceUrl.defaultZone=http://localhost:8761/sh: export: eureka.client.servic

Java的四大引用，大家都很熟悉吧： 强应用：正常代码中的引用。一个对象能通过强应用访问到，那它就永远不会被回收 软引用：比强引用弱一级的引用，内存不足时引用指向的对象会被回收 弱引用：比软引用弱一级的引用，下一次GC时指向对象会被回收 虚引用 最后一个虚应用是今天要讨论的。很多文章都是这么写的： 一个对象是否有虚引用存在，对其生存不会产生任何影响。 事实上，这个是错的。正确的表述是： 在

在从零开始使用Spring Cloud Config中，我们简单了解了下Spring Cloud Config，它提供了一套配置管理的解决方案。 但是Spring Cloud Config需要自己搭建config-server，还需要结合eureka来实现高可用；如果需要实时更新配置，还需要Spring Cloud Bus。实在是过于繁琐。 而阿里云ACM（应用配置管理）则提供了一整套完整的解决方