無名

关闭访问日志真的好吗？

1. 避免跨网调用

2. 数据源侧：

   2.1 优化指标采样率

   2.2 删除非核心指标的采集

   top10的metrics数量，按metrcis名称区分：

   topk(10,count by (__name__) ({__name__=~'.+'}))
   

   2.3 业务侧拆分，采用集群联邦

3. prom数据生命周期管理（减少保存时间）或者远程写入nas/oss

4. 高可用方案thonas

--cluster-cidr / --pod-network-cidr 是提供给 kube-controller-manager 的配置。

你可以简单地做ps -ef | grep "cluster-cidr" 得到你想要的。

也可以通过文件获取，在/etc/kubernetes/manifests/kube-controller-manager.yaml中：

# sudo grep cidr /etc/kubernetes/manifests/kube-*
/etc/kubernetes/manifests/kube-controller-manager.yaml:    - --allocate-node-cidrs=true
/etc/kubernetes/manifests/kube-controller-manager.yaml:    - --cluster-cidr=192.168.0.0/16
/etc/kubernetes/manifests/kube-controller-manager.yaml:    - --node-cidr-mask-size=24

我是ok的

继续增加直接内存的大小，或者减少你调整的broker参数，如：

• socket.request.max.bytes
• message.max.bytes

首先，默认配置的情况下，kafka broker是不会oom的，如果量大，会变慢或者报超时异常，而不是oom。

但当你调整了类似以上的配置，也需要加大JVM。

一般是docker的原因导致的。

一个可行的解决方案是重新启动 Docker 服务，然后重新运行 kubeadm reset：

sudo systemctl restart docker.service
sudo kubeadm reset

检查 docker 的日志：

journalctl -ul docker

https://github.com/kubernetes/kubernetes/issues/53533

你看下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

Kubernetes(k8s)就是按照用户的期望的样子来运行部署应用程序。
赞！

大佬，非常高兴能看到你得文章

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

NotReady是什么导致的？

导致kubernetes node状态为NotReady的原因有很多，常见的错误如下：

1. kubelet启动节点失败（核心）
2. 网络附加组件cni，如：calico、flannel等故障
3. 节点OOM（NotReady和Ready状态反复切换，因为释放容器之后，又满了，轮询反复）

大部分情况是kubelet引起的：

• RPC 调用过程中容器运行时响应超时(有可能是性能下降，死锁或者出现了 bug)。

• 节点上的 Pod 数量太多，导致 relist操作无法在 3 分钟内完成。事件数量和延时与 Pod 数量成正比，与节点资源无关。

• relist 出现了死锁，该 bug 已在 Kubernetes 1.14 中修复。

• 获取 Pod 的网络堆栈信息时CNI插件出现了bug(简而言之即容器管理系统和网络插件之间通过 JSON 格式的文件进行通信，实现容器的网络功能)。

NotReady会发生什么？

1、NotReady的node上的容器依然提供服务，但已脱离了kubernetes的调度，不会做任何变动。
2、kubernetes将NotReady的node节点上的容器调度正常的node上。

QoS是怎么实现的

从容器的角度出发，限制容器使用的CPU和内存，是通过cgroup来实现的，目前kubernetes的QoS只能管理CPU和内存，所以kubernetes现在也是通过对cgroup的配置来实现QoS管理的。

QoS是什么

在kubernetes中，每个Pod都有个QoS标记，QoS的英文全称为 Quality of Service，中文名为服务质量，它取决于用户对服务质量的预期，也就是期望的服务质量。对于Pod来说，服务质量体现在两个指标上，一个指标是CPU，另一个指标是内存。在实际运行过程中，当NODE节点上内存资源紧张的时候，kubernetes根据Pod具有的不同QoS标记，采取不同调度和驱逐策略。

QoS 类

Kubernetes 创建 Pod 时就给它指定了下列一种 QoS 类：

• Guaranteed
• Burstable
• BestEffort

QoS 类为 Guaranteed 的 Pod

• Pod 中的每个容器必须指定内存请求和内存限制，并且两者要相等。
• Pod 中的每个容器必须指定 CPU 请求和 CPU 限制，并且两者要相等。

QoS 类为 Burstable 的 Pod

如果满足下面条件，将会指定 Pod 的 QoS 类为 Burstable：

• Pod 不符合 Guaranteed QoS 类的标准。
• Pod 中至少一个容器具有内存或 CPU 请求。

QoS 类为 BestEffort 的 Pod

• 对于 QoS 类为 BestEffort 的 Pod，Pod 中的容器必须没有设置内存和 CPU 限制或请求。

QoS级别决定了kubernetes处理这些Pod的方式，我们以内存资源为例：

1、当 NODE节点上内存资源不够的时候，QoS级别是BestEffort的Pod会最先被kill掉；当NODE节点上内存资源充足的时候，QoS级别是BestEffort的POD可以使用NODE节点上剩余的所有内存资源。

2、当NODE节点上内存资源不够的时候，如果QoS级别是BestEffort的Pod已经都被kill掉了，那么会查找QoS级别是Burstable的POD，并且这些POD使用的内存已经超出了requests设置的内存值，这些被找到的POD会被kill掉；当NODE节点上内存资源充足的时候，QoS级别是Burstable的POD会按照requests和limits的设置来使用。

3、当NODE节点上内存资源不够的时候，如果QoS级别是BestEffort和Burstable的Ppod都已经被kill掉了，那么会查找QoS级别是Guaranteed的POD，并且这些POD使用的内存已经超出了limits设置的内存值，这些被找到的POD会被kill掉；当NODE节点上内存资源充足的时候，QoS级别是Burstable的POD会按照requests和limits的设置来使用。

详细参考：配置Pod的服务质量（QoS）