我正在使用Flink Kubernetes Operator 1.5.0使用Kubernetes设置测试Flink autoscaler。
在文档里说：
在当前状态下，autoscaler最适合Kafka源代码，因为它们公开了所有的标准化指标。在使用Kafka时，它还带来了一些额外的好处，例如自动检测并限制源最大并行度到Kafka分区的数量。
这有什么关系我的意思是，据我所知，它是基于每个顶点的%忙碌来缩放的。
这段话是否意味着Kafka以外的源不能报告%忙碌，或者它可以使用Kafka滞后度量来扩展？
理想情况下，我希望基于Kafka滞后进行扩展，但我不确定这个指标是否在Flink内部可用
1条答案
按热度按时间xiozqbni1#
我推荐阅读FLIP-271，它将自动缩放引入了Kubernetes Operator。参见https://cwiki.apache.org/confluence/display/FLINK/FLIP-271%3A+Autoscaling
autoscaler算法的目标是“在很少的扩展决策量中产生资源高效的无背压配置”。为了实现这一目标，它使用了多个指标，所有这些指标都可用于Flink Kafka连接器。
Kafka滞后本身与Flink无关。Flink只在快照期间提交其偏移量，以帮助监视Kafka中的结果，但它不需要它的容错。这也意味着Kafka的延迟会增加，直到Flink快照的那一刻，但Flink实际上继续从Kafka阅读消息。它只是还没有提交抵消。