@defunct9 ssh 哥还是搞笑 虚拟机你也上

工作岗位: 基建小组，正常作息基本如下，忙的时候不好说
上午: 到公司食堂拿吃的，吃完玩会手机到 10 点，整理下今天要工作的事情，带薪炸翔，随便弄一会就是 11.30 了，吃午饭。
中午: 吃饭，午休到一点半
下午: 下午的事情比较多，写代码，帮业务排查问题，和同事对接，这里基本可以输出到下午五点半，刷半小时视频啥的到六点吃饭
晚饭: 吃完饭，园区散步差不多 7 点，上来看会电视到 7.20 ，晚上如果没特别急的事就是一天工作收尾，基本到 20.30 就走人

回复人数不少，看了下 vanblog 不错，就选择了它。谢谢帖子里推荐的各位大佬

一觉醒来几十条回复，谢谢各位热心大佬，回复帖子的人数有些多，就不一一 at ，等周末了折腾一波。

@xing393939 内网资料，也不好外传。可以用 skbtracer ，打印出 kfree_skb 的调用栈，看看丢包的函数调用链。我们的情况是丢包位于容器内的 eth0 ，调整 net.core.netdev_max_backlog 参数。具体可能不适用，先从函数调用链入手。

R.I.P

猜测是一些队列满了？ 最近我们的业务高并发压测遇到过丢包，同事排查过这些问题，好像总体原因就是链接队列放不下了。这会不在公司，看不到排查文档。

虽然大学经历的事情与楼主不同，楼主有责任心是很好的，乐于助人都是好事，我想大学是一个价值观塑造的过程，我说一个我自己的事情，我感觉楼主与我有些像，我来会“好为人师”。
我大学也当过学习委员，有个同学代码一点都不会写，理解不了计算机思维，面临挂科留级，我后面帮他补课起码能帮他过。这个同学家庭环境也不好，还在学校兼职送外卖，大二那年他确实没挂科。他又是一个十分内向，不愿意说话的人，后来一次下大雨我在外面一栋楼等雨走不了，他送外卖披着雨衣看到我，让我做他电瓶车回宿舍，这件事我挺有印象的。后来我还入了 party ，但是我发现很多学生、老师在 party 都是务虚不务实，反正我不喜欢那套氛围 哈哈。

总的来说，大学是存在各种各样的人，他们有着各种各样的方式去完成他们的目的。在他们看来可能你这样的责任心是傻子。我很喜欢当年明月的话，所谓成功就是以自己喜欢的方式过完一生。虽然楼主和我在这个年纪说过完一生尚早，我想说的是楼主不需要因为他人影响到自己的行为准则，坚持自己的路子就好。但是，别让责任心拖累了你自己的发展，你要保证自己能够获取到资源并且能为自己有利。

@LeeReamond 这个要确认下你的代理软件是否代理访问 steam 的流量？

开代理，不然即使能上社区也是用不了

@mengjisang 建议 minikube ，搭建环境快不少。问题就是 minikube 的镜像拉不到，挂 clash 把 tun 模式开上，直接接管了所有流量。

取决于你要装什么样的。如果只是一个基础版的，kubeadm 一把梭就完了，如果是学习性质的，建议使用 minikube 或者 kind

看帖子的动态，不少老哥收藏了帖子，@DAPTX4869 还期待后续，经过我的实验以后，@feedcode 的方案是可行，我简单说下步骤:
1. 用 ca.crt 生成 csr 再生成新的 ca, 这一步 openssl 需要制定证书生成 v3 证书，v1 的证书 kubeadm 会认为不是 ca
2. openssl 生成 csr 不包含扩展内容，需要加上选项 -x509toreq -copy_extensions copy all ，这个似乎需要 openssl v3 ，运维同事打包好的 debian 是 openssl 1.1.1n ，前面选项不可用。
3. 在主 master 生成 ca,并且用 kubeadm renew 所有二级证书，然后将 ca 复制到其他 master 节点，重启 master 节点的 kubelet ，确保 kubelet 的状态是 running 以后 再进行其他操作。
4. 重启集群的关键组件,etcd,apiserver,kube-scheduler,controller-manager ，更新 admin.conf ，此时确认下 这些组件的状态都是 ok
5. 更新 worker 节点的 kubelet.conf,这里需要在 master 为 worker 节点生成一份 kubelet.conf ，我不太清楚 worker 节点的 kbuelet 是否会自动拉取最新 ca ，至少从我实验来看是不会的。这部分参考[文档]( https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#kubelet-client-cert)。**注意**，生成的 kubelet.conf 确保它的 apisever 地址是正确的
6. 更新 calico ,coredns,kube-proxy ，最后确认下所有组件的状态。整个过程中，业务影响较小，我用 nginx 模拟的，证书业务没测试，替换 ca 前后 nginx 都可以正常工作。

**Note**: 只是大概描述下，如果大家有需要我后续写一篇 blog 贴出来

@feedcode 了解，大佬说的不错，你说的就是文档的流程，维持了一个新老 ca 的中间态。你说的这个方法确实可行，不过完整的验证我我还要搭一个生产集群的再来测一遍。谢谢大佬，救了燃眉之急。

@feedcode 那这个方法和文档相比有点在哪呢？ 我认为优点就是少了二级证书的签发，可以重新走 renew 的流程，其他的 secret 重建，kubeconfig 的重建，coredns 、kubeproxy 等系统组件等重启工作也是少不来的。

@feedcode @plko345 两位大佬，请教下 ca.crt 被重建，那旧的 secret 如何处理呢？ 旧 secret 内 ca.crt 字段还是老 ca ，难道要重建所有的 secret 吗？

@lixiang2017 这个也 kubeadm renew 效果差不多？ 只能续签二级证书的吧 我今天看下下

@idblife adm 只更新 ca.crt 签发的二级证书，我们现在的情况是 根 ca 都要过期了。

@feedcode 大佬实操过吗？ 看着文档流程属实不少，感觉很容易出错