我目前正在研究一项监视服务，该服务将监视Kubernetes的部署及其Pod。我想在部署未运行预期数量的副本以及Pod的容器意外重启时通知用户。这可能不是正确的监视对象，对于我应该监视的内容，我将不胜感激。
无论如何，主要问题是所有广告连播状态之间的差异。当我说“ 状态 ”时，是指运行时的“状态”列kubectl get pods。有问题的状态是：
- ContainerCreating
- ImagePullBackOff
- Pending
- CrashLoopBackOff
- Error
- Running
是什么导致吊舱/容器进入这些状态？
对于前四个状态，这些状态是否可以在没有用户交互的情况下恢复？
阈值是CrashLoopBackOff多少？
是Running具有唯一身份Ready Condition真实的？
任何反馈将不胜感激！
另外，kubectl在自动化脚本中使用以进行监视是否会是不好的做法？例如，每分钟将结果记录kubectl get pods到Elasticsearch?。