江苏龙网

  1. 首页 > 人文 > >

清澈如初|Spark Operator 问题的救火，一次( 二 )


猜测从现象和前面收集的信息来看 ， 最大的可能是Web-hook-init产生的密钥并没有更新到SparkApiServer 。 很大的可能性是升级是先升级了Spark-operator的APIServer ， 然后重新执行了web-hook-init 。 基于原理的猜想 ， 大概不那么玄学了吧 ， 有效驳斥了老程序定位问题的直觉说 。
验证既然是顺序问题 ， 那么我们重启Spark-operator服务 ， 功能正常 。 嗯 ， 对 ， 还是重启大法好啊 。 说的没错 ， 同时咱们是有理有据的重启 。
Deeper我起初怀疑是我们内部没有采用Helm部署导致的问题 ， 翻开Yaml却发现并没有关于InstallOrder的控制 ， Helm的默认控制顺序和预期的不一样 ， Deployment先部署 ， Secret后部署 。
#L61
思考为什么部署的时候没事 ， 反而update的时候有事呢？ 。 这里有关于如果pod创建时 ， Secret还没有创建是如何运作的介绍 。
这个纯粹和我们Update的方式相关 ， 操作人员在Update前执行了Delete操作 。 理论上K8S走的是Volidate-Diff-Apply的操作模式 ， 只会更新Diff的地方 。 单纯的Update是不会更新Secret的 。
所以 ， 包含这么多知识点的一个问题 ， 归根到底却是一个操作问题 。 又有什么关系呢？有收获就OK了 。
后记我是个经常救火 ， 又立志决不当Fireman的人 ， 所以保持借假修真的心态 ， 探究的更加深入 ， 找出知识点和乐趣 。
【清澈如初|Spark Operator 问题的救火，一次】提前祝各位Coder中秋快乐 。


推荐阅读


上一篇：微生物|又一坏消息传来，地球或迎来一位“不速之客”，人类该出手了！

下一篇：锋向科技|Ultra暴利,卖一台能赚一台小米10，三星Note20