我们很高兴地宣布，面向DevOps专家（不仅限于
kubedog）的Flant公司将进行新的开源开发。 这是一个Go编写的库和基于它的CLI，用于跟踪Kubernetes资源事件并收集其日志。
该库当前支持跟踪以下资源：Pod（和容器），Job，Deployment，StatefulSet和DaemonSet。 事件和日志通过回调传输。
kubedog CLI有两种操作模式：
- 推出跟踪 -跟踪资源，直到到达“就绪”状态为止；如果出现错误，则退出以方便在CI / CD中使用；
- 跟随打印事件并记录到屏幕而没有退出，类似于
tail -f 。
问题
如果已经存在类似的项目，为什么为什么要开始编写新的库
（请参阅本评论中的 “使用日志”） ？ 我们的
DevOps dapp实用程序中使用
Kubedog来跟踪Helm图表
的推出 。 Helm本身不知道如何监视其添加的资源状态，并且在Helm和分till之间的GRPC交互级别未提供日志传输。 在这种情况下，存在
我们的问题3481 ，
我们在该
问题的框架内实施了对附加资源的跟踪...但是，由于所有工作都集中在新版本的
Helm 3上，因此Helm项目现在不愿为Helm 2添加新功能。 因此，我们决定将kubedog分离到一个单独的项目中。
资源跟踪库
需要什么？
- 获取属于资源（例如，部署）的Pod的日志。
- 响应属于该资源的Pod组成的更改：添加来自新Pod的接收日志，禁用来自旧ReplicaSets的Pod的日志。
- 跟踪事件 ，其中会解密各种错误。 例如，由于图像未知而无法创建Pod，或者创建了Pod，但是模板中指定的命令不在图像中。
- 另外一个需求是跟踪资源从
rollout到ready模式的过渡。 每个资源对此都有自己的条件。
您可能会猜到，在kubedog中，我们尝试
将上述所有因素都考虑在内 。
在开始一些新工作时，他们会很好地分析现有的解决方案。 但事实证明，尽管有许多CLI形式的解决方案，但根本没有Go库。 因此，我们只能对现有CLI实用程序的主要功能进行较小的比较，以跟踪Kubernetes资源。
现有解决方案
kubespy
→
GitHub- 能够仅监视部署和服务，并对新Pod做出反应。
- 有一个用于描述资源及其状态以及以json diff形式输出更改的跟踪模式。
- 更改以彩色表格形式显示，表示副本集和条件的状态。
- 不显示Pod日志。
- 它是用Go编写的，但不能用作库。
kubetail
→
GitHub- 一个bash脚本，调用kubectl。
- 能够显示现有Pod的日志。
- 它不会检测到新的Pod；如果发生回滚，则需要重新启动kubetail。
船尾
→
GitHub- 显示通过pod-query过滤的Pod日志。
- 发现新豆荚。
- 日志线带有颜色，可以更好地感知。
- 显示使用容器中的名称添加和删除Pod的事件。
- 它不遵循事件，因此不显示Pod错误的原因。
- 它是用Go编写的，但不能用作库。
凯尔
→
GitHub- 能够同时显示来自不同名称空间的不同资源的日志。
- 不监视事件，不显示错误原因，例如，对于Deployment。
- 不绘制Pod的原木。
- 它是用Go编写的，但不能用作库。
k8stail
→
GitHub- 通过名称空间和标签选择Pod。
- 跟踪新的，删除的。
- 不遵循事件，不会显示错误。
- 在Go中，但不在图书馆中。
酷狗
→
GitHub- CLI在两种模式下运行：无限跟踪和跟踪，直到资源变为READY状态为止。
- 跟踪一种资源。
- 对资源更改做出反应，订阅新Pod的日志。
- 能够监视Deployment，StatefulSet，DaemonSet，Job或单独的Pod。
- 用Go语言编写，您可以将其用作库来向程序添加资源，以监视资源状态并从容器接收日志。
如果仔细观察，您可以说每个实用程序都在某种程度上胜过其竞争对手，并且没有一个赢家可以胜任其他任何人所能做的事情。
太棒了！
kubedog工作的实质如下：对于指定的资源，在事件和属于该资源的Pod上运行Watchers，并在出现Pod时运行其记录器。 资源发生的所有事情都通过调用回调广播给客户端。
让我们看一下DaemonSet的示例，该示例可用于使用该库的代码。 Deployment，StatefulSet和DaemonSet的回调接口相同*-这是
ControllerFeed ：
type ControllerFeed interface { Added(ready bool) error Ready() error Failed(reason string) error EventMsg(msg string) error AddedReplicaSet(ReplicaSet) error AddedPod(ReplicaSetPod) error PodLogChunk(*ReplicaSetPodLogChunk) error PodError(ReplicaSetPodError) error }
*例外是
AddedReplicaSet ，它仅对部署有意义（您无法定义此方法来跟踪DaemonsSet）。
其他接口方法的说明：
Added对应于选定资源的观察者的watch.Added事件；- 资源进入
Ready状态时（例如，对于DaemonSet，这是更新的和可用的Pods的数量与“所需”的Pods的数量一致的时刻），将调用Ready 。 Failed -删除资源或接收到带有错误原因和错误说明的事件（例如FailedCreate ）时，将FailedCreate ；- 对于从资源或其
EventMsg接收到的每个事件，都会调用EventMsg ：这些事件是有关资源创建，图像上传等的事件。 包括错误信息； AddedPod一种方法，您可以通过它捕捉创建新AddedPod的时刻；- 当另一条日志来自Kubernetes API时，将调用PodLogChunk。
- 如果Pod失败，将
PodError 。
每个回调可能会返回
StopTrack类型
StopTrack并且跟踪将完成。 因此，例如，在推出跟踪器中完成-“
Ready StopTrack ，CLI完成其工作。
为了便于定义回调，在创建对象时，可以使用
ControllerFeedProto结构来确定所需的回调方法。
例如，这就是
DaemonSet日志无休止的输出的样子，其中没有有关事件和状态的其他信息：
最后一个调用是一个
阻塞的调用：它启动了一个无限循环，从Kubernetes接收事件并调用相应的回调。 您可以通过从回调返回
StopTrack来以编程方式中断此循环。
应用实例
可以在dapp实用程序中
看到将kubedog用作库。 在此运行现成的展示跟踪器，以检查Helm创建或更新的资源。
Kubedog CLI能够
帮助在CI / CD系统中进行部署 ，无论是否使用它：kubectl，Helm或其他。 毕竟，您可以运行
kubectl apply ，然后运行
kubectl apply kubedog rollout track ，并且如果资源有问题，则在
kubedog rollout track日志中将看到错误。 kubedog的这种使用将有助于减少诊断推出问题的时间。
接下来是什么？
我们计划在支持更多资源的方向上开发库-例如，我真的很想关注Service and Ingress。 另外，应该对Event'ah中的
reason分类进行工作，以便更准确地确定我们可以假定资源推出失败的时刻。 库开发的另一个载体是一次跟踪多个资源，例如通过
labelSelector或通过名称空间。 我还希望支持各种注释，这些注释可以更改跟踪的性质，例如，对于Helm挂钩，但这对于dapp仍然更为重要。
在不久的将来，重点将放在库上，但是还计划对CLI进行改进：更便捷的命令和标志，日志颜色，有关删除Pod的消息，如船尾一样。 我们也正在考虑创建一个交互模式的可能性，其中一个窗口中包含部署状态表和事件，而另一个窗口中包含日志。
怎么尝试？
Bintray上提供了用于Linux和macOS的kubedog CLI构建。
真的很期待您在
GitHub上的反馈和问题！
聚苯乙烯
另请参阅我们的博客：