first commit

docs/guide/diagonize/events.md

@@ -0,0 +1,46 @@
+# 集群事件
+
+通过观察 KUberetes 集群事件，可以快速诊断部署时发生的问题。
+
+Kuboard 建立了与 kubernetes apiserver 的长连接，可以在第一时间将集群中的事件更新以通知的形式显示在 dashboad 上。
+
+
+
+## 错误事件提示
+
+如果存在与某一个工作负载相关的错误事件，名称空间界面中，将以红色显示该工作负载，如下图所示：
+
+![image-20190721104153954](./events.assets/image-20190721104153954.png)
+
+
+
+## 全局事件
+
+### 查看全局事件
+
+在任何页面点击界面左上角的 ***事件*** 按钮，进入事件列表页：
+
+![image-20190721101812895](./events.assets/image-20190721101812895.png)
+
+
+
+### 删除事件
+
+* 点击全局事件列表中的 ***类型*** 标签，
+
+![image-20190721101954560](./events.assets/image-20190721101954560.png)
+
+* 点击 ***确定***
+
+该事件已删除。如果事件对应的错误原因没有被解决，该事件又会在下一次 kubernetes 调度系统资源的时候重新出现。
+
+
+
+## 微服务上下文相关的事件
+
+打开工作负载页面，如下图所示：
+
+容器组信息中包含了与该容器组相关的所有集群事件。
+
+![image-20190721103324863](./events.assets/image-20190721103324863.png)
+

docs/guide/diagonize/logs.md

@@ -0,0 +1,35 @@
+# 日志及终端
+
+
+
+# 日志
+
+通过 Kuboard 可以实时跟踪容器的日志信息。
+
+假设您已经进入 ***工作负载*** 详情页，如下图所示：
+
+![image-20190721104348908](./logs.assets/image-20190721104348908.png)
+
+* 点击容器信息中的 ***日志*** 按钮
+
+  可进入日志追踪界面，如下图所示：
+
+![image-20190721104415732](./logs.assets/image-20190721104415732.png)
+
+
+
+# 终端
+
+* 点击容器信息中的 ***终端*** 按钮
+
+  可进入终端界面，如下图所示：
+
+  > * 在终端中，可以执行的 shell 命令取决于该容器预装的命令。许多容器为了精简自身的大小，只保留了最基本的命令。
+  >
+  > * 通常会进入终端执行如下诊断操作：
+  >   * export 命令查看容器内的环境变量是否被正确设置
+  >   * ping, curl 命令检查容器内与集群内其他服务，集群外服务的网络连通性
+  >   * vi 命令，临时修改容器内应用程序的配置，并在容器内重启应用程序，以临时性的尝试修复问题，如果有效再将修改更新到应用程序代码或者 Dockerfile
+
+![image-20190721104522870](./logs.assets/image-20190721104522870.png)
+

docs/guide/diagonize/port-forward.md

@@ -0,0 +1,27 @@
+# 端口转发
+
+微服务环境中，各个服务都通过 TCP / UDP 端口的形式提供访问。按调用者所在位置、通信协议的形式来划分，大致有如下几种情况：
+
+| 调用者所在位置 | 通信协议     | 临时性 | 常见场景                                                     | 推荐配置方式                                                 |
+| -------------- | ------------ | ------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
+| VPC外          | http / https | 日常性 | 用户从互联网（亦可能是公司内网）<br />访问 web 页面，或者 restful 接口 | Kubernetes  Ingress<br />（可在Kuboard中直接配置***互联网入口*** ） |
+| VPC外          | tcp / udp    | 临时性 | 例如，开发者临时需要访问数据库端口、Redis端口等；            | 在客户端所在机器配置 kubectl，<br />并<span style="color: #F56C6C;">通过 kubectl port-forwad 进行端口转发</span> |
+| VPC外          | tcp / udp    | 日常性 | 暂不讨论                                                     |                                                              |
+| VPC内/集群外   | http / https | 日常性 | 通过接口网关为周边系统提供服务                               | Kubernetes Service NodePort<br />（可在Kuboard中直接配置***访问方式/VPC内访问*** ） |
+| VPC内/集群外   | tcp / udp    | 同上   | 同上                                                         |                                                              |
+| 集群内         | http / https | 日常性 | **场景1**：Web层访问微服务网关<br />**场景2**：微服务网关调用微服务，微服务之间的互相调用等。 | **场景1**：Kubernetes Service ClusterIP <br />（可在Kuboard中直接配置 ***访问方式/集群内访问*** ）<br />**场景2**：Spring Cloud中使用Eureka/Consul等服务发现<br />（Kuboard中 ***访问方式/不配置*** ） |
+| 集群内         | tcp / udp    | 日常性 | 微服务访问数据库、微服务访问Redis等                          | Kubernetes Service ClusterIP <br />（可在Kuboard中直接配置 ***访问方式/集群内访问*** ） |
+
+
+
+## Feature planned
+
+在作者使用 Kuboard 的运维实践中，有如下两个场景不能脱离 kubeadm / kubectl 命令行：
+
+* 初始化集群 / 向集群添加节点
+* 开发者临时需要访问数据库端口、Redis端口时，通过 kubectl  port-forward 进行端口转发
+
+
+
+Kuboard 计划实现类似 kubectl port-forward 的功能，提高问题诊断过程中的便利性。
+