@baeyer 部署的时候直接就用的是 n1 的主机名……最后发现 kubectl delete node 没什么问题，按着 kubelet 的报错修配置文件就完事了……

作死操作了一下猜想的前两条，把 configmap 里的配置改完以后集群没啥问题。
观察到另一台 master 里面的 /etc/kubernetes/manifests/etcd.yaml 配置上有点问题：initial-cluster 包含两台 etcd 配置。
但是另一台 master 里面的 apiserver.crt 、etcd/peer.crt 、etcd/server.crt 三本证书 CN 是对的。
这让我对于踢掉 n1 这台 master 具有了非常强大的信心。

@Ansen
1. 双 master
2. N1 炸过重启过一次，N1 失效期间应用 Pod 正常访问，但 kubectl 无法使用，修改.kube/config 到新 master 上无效。
3.想起来可能是因为 etcd 的 quorum 不可能成功。所以 N1 失效以后，猜测 kubelet 把 pod 全 restart 了一遍……

能猜到的几个改动点：
1. configmap 里 kubeadm-config 里有个 controlPlaneEndpoint 需要调整
2. configmap 里 kube-proxy 里有个 clusters[0].cluster.server 需要调整
2. /etc/kubernetes/pki 下的 apiserver.crt 、etcd/peer.crt 、etcd/server.crt 三本证书要改

@Cify 生产实践中一般 K8S 的 LB 会指定单独的两台机器打 Taint 避免调度，还会有一套 Keepalived+HAProxy 的 NGINX/F5 到这两台机器上

K8S 跑 Traefik
IngressRoute 里根据 Host 去 match 反代到 Service 上

第一时间想到的是 cglib 的 Enhancer 的写法……

Pod 里面多个 filebeat 容器，推到 ES 上

这个背后是社会形态问题。
历史上以宗族势力自治的场景，见义勇为是一种本能。这种对抗可以从个人利益上升到整个组织的利益。
现代社会并不关心这个，因为个人利益在各方面利益前被稀释开来。他们所关心的只是整个组织架构是否能运转。

@lithiumii 议题限缩在当前国内法律框架内

@Aixtuz 直接执行 tailscaled 看看能不能行？

brew services start tailscaled

首先得让 Father 去实现一个具有 name 方法的 interface ，然后是反射重写对象头把 Son 实例的 Class ptr 指向 Father 。

list.stream().anyMatch(Function.identity())

1. Javaagent
2. AspectJ LoadTimeWeaving

@u0x01 m1 不需要改驱动也可以用

AOC LV273HUPX
走 HP 洋垃圾扩展坞的 DP 接口
没有发生过闪屏的情况
有就是 TB3 接口接触问题

@lovejunjie1
那现阶段问题基本就是网络协议开销问题，至少本地 dd 性能没出问题。
一方面 iperf3 打一下带宽，是否需要修改 MTU ？
一方面猜你用的 SMB 协议，是否有其他协议可以使用？ NFS FTP WebDAV ？

@lovejunjie1
大致就是不考虑容灾，只考虑性能对吧。
双 16T 和 4 块 8T 甚至 8 块 4T 构筑 R0 阵列，对于吞吐量问题上会带来什么差异？
读写场景是读多还是写多？
读写场景是顺序读写还是随机读写多？
不妨看下硬阵列卡是否有缓存？是否有缓存配置优化空间？
软硬阵列在缓存层面的差异能带来什么样不同的优劣势？