kubelet不断重启（kubelet-check initial timeout）



sealos简介sealos 特性与优势：
通过内核 ipvs 对 apiserver 进行负载均衡，并且带 apiserver 健康检测,并不依赖 haproxy 和 keepalived。
支持离线安装，工具与资源包(二进制程序 配置文件 镜像 yaml文件等)分离,这样不同版本替换不同离线包即可
证书延期
使用简单
支持自定义配置
内核负载，极其稳定，因为简单所以排查问题也极其简单
支持99年证书，不用担心生产集群证书过期，ipvs负载多master可用性与稳定性更高，已经有上千用户在生产环境中使用sealos, 有超过上千台服务器生产环境中使用sealos。

为什么不用 keepalived haproxy？
haproxy 用 static pod 跑没有太大问题，还算好管理，keepalived 现在大部分开源 ansible 脚本都用 yum 或者 apt 等装，这样非常的不可控，有如下劣势：

源不一致可能导致版本不一致，版本不一直连配置文件都不一样，我曾经检测脚本不生效一直找不到原因，后来才知道是版本原因。
系统原因安装不上，依赖库问题某些环境就直接装不上了。
看了网上很多安装脚本，很多检测脚本与权重调节方式都不对，直接去检测 haproxy 进程在不在，其实是应该去检测 apiserver 是不是 healthz 的，如果 apiserver 挂了，即使 haproxy 进程存在，集群也会不正常了，就是伪高可用了。
管理不方便，通过 prometheus 对集群进行监控，是能直接监控到 static pod 的但是用 systemd 跑又需要单独设置监控，且重启啥的还需要单独拉起。不如 kubelet 统一管理来的干净简洁。
我们还出现过 keepalived 把 CPU 占满的情况。
所以为了解决这个问题，我把 keepalived 跑在了容器中(社区提供的镜像基本是不可用的) 改造中间也是发生过很多问题，最终好在解决了。

总而言之，累觉不爱，所以在想能不能甩开 haproxy 和 keepalived 做出更简单更可靠的方案出来，还真找到了。。。

本地负载为什么不使用 envoy 或者 nginx？
我们通过本地负载解决高可用问题。

在架构实现上有个问题会让使用 envoy 等变得非常尴尬，就是 join 时如果负载均衡没有建立那是会卡住的，kubelet 就不会起来，所以为此你需要先启动 envoy，意味着你又不能用 static pod 去管理它，同上面 keepalived 宿主机部署一样的问题，用 static pod 就会相互依赖，逻辑死锁，鸡说要先有蛋，蛋说要先有鸡，最后谁都没有。

使用 ipvs 就不一样，我可以在 join 之前先把 ipvs 规则建立好，再去 join 就可以了，然后对规则进行守护即可。一旦 apiserver 不可访问了，会自动清理掉所有 node 上对应的 ipvs 规则， 等到 master 恢复正常时添加回来。

为什么要定制 kubeadm?
首先是由于 kubeadm 把证书过期时间写死了，所以需要定制把它改成 99 年，虽然大部分人可以自己去签个新证书，但是我们还是不想再依赖个别的工具，就直接改源码了。

其次就是做本地负载时修改 kubeadm 代码是最方便的，因为在 join 时我们需要做两个事，第一是 join 之前先创建好 ipvs 规则，第二是创建 static pod。如果这块不去定制 kubeadm 就把报静态 pod 目录已存在的错误，忽略这个错误很不优雅。 而且 kubeadm 中已经提供了一些很好用的 sdk 供我们去实现这个功能。

且这样做之后最核心的功能都集成到 kubeadm 中了，sealos 就单单变成分发和执行上层命令的轻量级工具了，增加节点时我们也就可以直接用 kubeadm 了。

sealos架构

3、设置所有节点 hostname 主机名

4、各节点配置 /etc/hosts

5、同步各节点时间

6、下载 k8s 安装包

7、部署多master多node集群，admin 是服务器密码(根据自己服务器密码填写)

8、部署单master多node集群

9、重置集群

10、增加或删除节点

11、查看所有节点状态

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/cjjbc/65528.html