补充一个,如果需要加入一个新的控制平面
节点,则需要为控制平面加入命令重新创建一个新密钥。只需三个简单步骤即可完成:
使用 kubeadm init phase upload-certs --upload-certs
在已运行的主节点中重新上传证书。这将生成一个新的证书密钥。
使用 kubeadm token create --print-join-command
在已运行的主节点中打印 join
命令。
加入新的控制平面节点:$JOIN_COMMAND_FROM_STEP2 --control-plane --certificate-key $KEY_FROM_STEP1
.
这对旧版本的 Kubernetes 可能不起作用,但我用新版本试了一下,确实有效。
可能是之前改过什么目录权限,文件被占用、或者修改过topic的配置,重启过kafka什么的,导致这个topic的管理泄露了。
感谢,我查看了上述内容都是正常的,该集群节点的其他topic也是可以正常老化的,只有这个比较特殊。我不明白为什么这个没有自动老化,在我使用delete-record脚本清理之后这个topic的消息可以自动老化了
1、检查下系统的时间是否正常
2、查看kafka日志是否正常
3、重启kafka节点
4、查看log.cleaner.enable
是否启用,更多清理策略配置可查看 Kafka Broker配置 搜索关键字clean
。
netstat显示实时信息,没有历史信息。
Conntrack会在最近的连接过期前记住X秒。据我理解,这是因为iptable还有其他几个模块可以利用这些信息:例如,如果想禁止某个IP地址,如果它在某个时间框架内建立了X个新连接的话。
可以调整记录的最大数:
sysctl net.ipv4.netfilter.ip_conntrack_max
老内核的调整方式:
sysctl net.ipv4.ip_conntrack_max
可以通过/etc/sysctl.conf
或临时sysctl -w net.ipv4.ip_conntrack_max
提高该值。
一般是docker的原因导致的。
一个可行的解决方案是重新启动 Docker 服务,然后重新运行 kubeadm reset
:
sudo systemctl restart docker.service
sudo kubeadm reset
检查 docker 的日志:
journalctl -ul docker
你看下kafka集群的配置文件,是否设置了auto.create.topics.enable=false
。
如果有,就设置为ture,当topic不存在,导致的,允许它自动创建。
或者你也可以手动创建topic:
bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 2 --partitions 4 --topic test
$ kubectl wait --for=condition=complete --timeout=600s job/myjob
Kafka有5个核心API:
Producer API
允许应用程序发送数据流到kafka集群中的topic。Consumer API
允许应用程序从kafka集群的topic中读取数据流。Streams API
允许从输入topic转换数据流到输出topic。Connect API
通过实现连接器(connector),不断地从一些源系统或应用程序中拉取数据到kafka,或从kafka提交数据到宿系统(sink system)或应用程序。Admin API
用于管理和检查topic,broker和其他Kafka对象。具体可参考:kafka接口API
导致kubernetes node状态为NotReady的原因有很多,常见的错误如下:
RPC 调用过程中容器运行时响应超时(有可能是性能下降,死锁或者出现了 bug)。
节点上的 Pod 数量太多,导致 relist操作无法在 3 分钟内完成。事件数量和延时与 Pod 数量成正比,与节点资源无关。
relist 出现了死锁,该 bug 已在 Kubernetes 1.14 中修复。
获取 Pod 的网络堆栈信息时CNI插件出现了bug(简而言之即容器管理系统和网络插件之间通过 JSON 格式的文件进行通信,实现容器的网络功能)。
1、NotReady的node上的容器依然提供服务,但已脱离了kubernetes的调度,不会做任何变动。
2、kubernetes将NotReady的node节点上的容器调度正常的node上。