warning

install/faq/warning.md

@@ -0,0 +1,66 @@
+---
+vssueId: 150
+description: Kuboard界面上_时常会出现工作负载_Deployment_StatefulSet_DaemonSet_等为红色_且带一个红色E图标的情况_本文解释了该图标的含义以及如何清理
+meta:
+  - name: keywords
+    content: Kubernetes 管理界面, Kuboard, K8S管理界面
+---
+
+# 错误提示
+
+Kuboard中经常会出现如下情况，某一个工作负载（Deployment/StatefulSet/DaemonSet等）显示为红色，且有一个闪烁的红色 `E` 图标。
+
+![image-20191108220746427](./warning.assets/image-20191108220746427.png)
+
+此为 Kuboard 中设计的一个错误提示方式，其具体实现方式是：
+* 遍历当前的所有事件，对于每一个事件：
+  * 如果事件类型为 Normal，则跳过
+  * 如果事件类型为 Warining，则对比该事件源对象（产生该事件的Kubernetes 对象）的名字（假设为 event_source_name）与当前工作负载（假设为work_load_name）的名字：
+    * 如果 event_source_name.indexOf(work_load_name) === 0，则该工作负载显示错误提示
+    * 如果 event_source_name.indexOf(work_load_name) !== 0，则跳过
+
+使用此方式，我们可以快速查看到名称空间中存在问题的工作负载，并迅速对其进行诊断。
+
+但是这种告警方式并不是完美的，具体来说，会发生如下情况：
+
+## 实际正常，但提示错误
+
+实际上，您的工作负载（Deployment、StatefulSet、DaemonSet等）已经正常工作，但是仍然提示有错误信息。此种情况通常发生在类似如下的场景中：
+
+### 场景一：
+
+* 创建Deployment，但未创建所需要的PVC
+  * 此时该Deployment的Pod不能调度，并伴随着 PVC 未绑定的错误事件
+* 创建PVC，Pod成功调度，Deployment正常工作
+  * 此时，虽然Pod已经正常，但是该Pod原来的错误事件仍然存在，因此Kuboard仍然会显示此错误提示
+
+### 场景二：
+
+* 创建Deployment，但该Deployment依赖的数据库未启动
+  * 此时该Deployment的Pod将Crash
+* 启动数据库
+* 删除Deployment原有的Pod
+  * 此时Deployment创建新Pod以维持所需要的副本数
+  * 新的Pod正常工作
+  * 此时，虽然与错误事件关联的Pod已经删除，但是该Pod产生的错误事件仍然存在，且与Deployment的名称匹配，因此，Kuboard仍将显示错误标志
+
+### 修正办法
+
+* 在名称空间左上角点击 **事件** 按钮，将进入事件列表查看界面
+* 将已经失效的错误事件删除
+  > 点击事件的图标，可删除事件
+
+## 界面卡顿
+
+当名称空间中工作负载的数量，以及集群中错误事件的数量特别多时，在进入名称空间界面时可能出现卡顿，但是只要成功进入，一切工作都是正常的。
+
+卡顿的原因是，Kuboard在循环遍历事件与工作负载的匹配情况，通常只有在在工作负载数量和事件数量都特别多时，才会出现卡顿，在 1.0.4 版本中优化之后，速度已经得到了非常可观的提升。
+
+如果您仍然碰到了卡顿的现象，可以尝试：
+* 删除事件
+  
+  执行命令 `kubectl delete events --all-namespaces`。由于 Kubernetes 的控制器模式，Kubernetes会不断尝试失败的操作，因此，删除事件通常是安全的，过一阵子，原有的错误事件又会重复出现
+
+* 向Kuboard反馈此问题
+
+  本文页尾有Kuboard支持社群的入群方式，直接联系群主即可