【问题标题】:Spring Cloud Data Flow stream cannot be deployed in KubernetesSpring Cloud Data Flow 流无法在 Kubernetes 中部署
【发布时间】:2019-12-19 21:37:36
【问题描述】:

我按照 Spring Cloud Data Flow 的 how to install 指南使用 kubectl 在 Azure Kubernetes 集群上安装应用程序。我使用 Kafka 作为消息代理,并创建了一个简单的流 time | log

无法部署流,附上我无法完全理解的日志。

PS kubectl get pods
NAME                                   READY   STATUS    RESTARTS   AGE
grafana-7d7d77d54-m59dx                1/1     Running   0          5h36m
kafka-broker-64bfd5d6b5-9c7ld          1/1     Running   0          25m
kafka-zk-768b548468-mhrrn              1/1     Running   0          145m
mysql-9dbdc88c6-xz4hh                  1/1     Running   0          21h
prometheus-64b45b746-zs7z4             1/1     Running   0          5h37m
prometheus-proxy-6764bf4968-4xjz5      1/1     Running   0          28m
scdf-server-7f864c96b7-s8cmm           1/1     Running   0          62m
skipper-7fbd7f47cd-b92v4               1/1     Running   0          6h13m
test-stream-log-v9-ffcd9d55f-8p96j     0/1     Running   13         68m
test-stream-time-v9-6c47699d94-pfzkr   0/1     Running   13         68m

时间应用日志。 https://pastebin.com/JyS8azVk

记录应用日志。 https://pastebin.com/pCe1NqSn

卡夫卡日志。 https://pastebin.com/Dj5KfVsQ

【问题讨论】:

    标签: spring azure kubernetes apache-kafka spring-cloud-dataflow


    【解决方案1】:

    来自time-source中的附加日志;具体来说,这个:

    2019-12-19 21:15:23.963 ERROR 1 --- [           main] o.s.cloud.stream.binding.BindingService  : Failed to create producer binding; retrying in 30 seconds
    org.springframework.cloud.stream.provisioning.ProvisioningException: Provisioning exception; nested exception is java.util.concurrent.TimeoutException
            at org.springframework.cloud.stream.binder.kafka.provisioning.KafkaTopicProvisioner.createTopic(KafkaTopicProvisioner.java:290) ~[spring-cloud-stream-binder-kafka-core-2.1.4.RELEASE
    

    这表明 Spring Cloud Stream binder 供应商无法为生产者创建所需的主题(即time-source)。

    但是,根据您的 kubectl get pods 输出,您的 Kafka 和 ZK 似乎是在最近部署的,而不是在 6 小时前部署的 Skipper。

    您可能以错误的顺序部署了组件,或者您可能重新配置了 Kafka,但 IP/主机/端口更改尚未反映在 Skipper 的部署中。原因是,Skipper 会跟踪 Kafka credentials in its config-map,因此它部署的所有流应用程序(通过 SCDF)将在部署时自动接收凭据。

    我猜想,当您重新配置 Kafka/ZK 时,应用程序收到的凭据可能发生了变化——您可以比较一下。我建议弹跳 Skipper 部署,以便它可以接收最新的 configmap 或全部清理,并从头开始遵循文档中描述的部署顺序。

    【讨论】:

    • 错误的部署顺序是根本原因,非常感谢。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2019-01-18
    • 1970-01-01
    • 2018-07-17
    • 1970-01-01
    • 2019-06-03
    • 2018-04-06
    • 1970-01-01
    相关资源
    最近更新 更多