first commit
|
After Width: | Height: | Size: 157 KiB |
|
After Width: | Height: | Size: 93 KiB |
|
After Width: | Height: | Size: 94 KiB |
|
After Width: | Height: | Size: 96 KiB |
|
After Width: | Height: | Size: 120 KiB |
|
After Width: | Height: | Size: 177 KiB |
|
After Width: | Height: | Size: 177 KiB |
|
After Width: | Height: | Size: 122 KiB |
|
After Width: | Height: | Size: 93 KiB |
|
After Width: | Height: | Size: 96 KiB |
|
After Width: | Height: | Size: 106 KiB |
|
After Width: | Height: | Size: 96 KiB |
|
After Width: | Height: | Size: 88 KiB |
|
After Width: | Height: | Size: 252 KiB |
120
docs/guide/namespace/adjustion.md
Normal file
@ -0,0 +1,120 @@
|
||||
# 日常调整
|
||||
|
||||
|
||||
|
||||
## 前提
|
||||
|
||||
必须具备如下条件:
|
||||
|
||||
* Kubernetes 集群
|
||||
|
||||
* 已在集群中安装 Kuboard
|
||||
|
||||
假设您一进入 ***example*** 名称空间页面,如下图所示:
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
## 批量删除容器组
|
||||
|
||||
批量删除容器组特别适用于 **开发测试环境的版本更新** 场景,描述如下:
|
||||
|
||||
* 开发/测试环境中,开发人员提交代码
|
||||
* DevOps环境自动构建出 docker 镜像,并将 docker 镜像推送到仓库;
|
||||
* 如果您的 devops 环境只在生成新的 branch 或者 tag 时,生成镜像的新 version,那么原镜像标签的实际镜像已发生改变。
|
||||
* 从 Kubernetes 中删除该镜像的 容器组
|
||||
* Kubernetes 创建新的 容器组,并且该容器组重新从镜像仓库拉取最新的镜像
|
||||
|
||||
|
||||
|
||||
在 Kuboard 中,***批量删除容器组*** 的操作步骤为:
|
||||
|
||||
* 在名称空间页面点击 ***容器组列表***
|
||||
|
||||
* 选择要筛选的应用分层,并点击刷新,
|
||||
|
||||
* 选择要删除的容器组
|
||||
|
||||
如下图所示:
|
||||
|
||||

|
||||
|
||||
* 点击 ***删除*** 按钮
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
* 点击 ***确定***
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
* 点击 ***应用***
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
* 点击 ***完成***
|
||||
|
||||
并等待,直到 kubernetes 完成对容器组的调整操作
|
||||
|
||||
> Kuboard 会自动监听 kubernetes 执行此调整操作时的变化,您无需刷新页面,只要等待结果即可。
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
## 批量调整镜像版本
|
||||
|
||||
批量调整镜像版本适用于如下场景:
|
||||
|
||||
* 需要更新容器所使用的镜像的版本号
|
||||
|
||||
通常是经过测试的版本,且 DevOps 环境在构建镜像时,为其生成了新的版本号
|
||||
|
||||
|
||||
|
||||
批量调整镜像版本的操作如下:
|
||||
|
||||
* 在名称空间页面点击 ***调整镜像版本***
|
||||
|
||||

|
||||
|
||||
* 在要调整的镜像上点击 ***修改***
|
||||
|
||||
并填写新的镜像版本号,如下图所示:
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
* 点击 ***执行变更***
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
* 点击 ***应用***
|
||||
|
||||

|
||||
|
||||
* 点击 ***完成***
|
||||
|
||||
此时会进入容器组列表界面,请等待 Kubernetes 完成对容器组的调整(无需刷新页面)
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
## 批量调整工作负载的副本数
|
||||
|
||||
|
||||
|
||||
***调整容器镜像版本*** 的功能界面中,也可以用来调整工作负载的副本数,如下图所示:
|
||||
|
||||

|
||||
|
||||
|
After Width: | Height: | Size: 144 KiB |
|
After Width: | Height: | Size: 192 KiB |
|
After Width: | Height: | Size: 148 KiB |
|
After Width: | Height: | Size: 186 KiB |
47
docs/guide/namespace/configMap.md
Normal file
@ -0,0 +1,47 @@
|
||||
# 配置
|
||||
|
||||
配置: Kubernetes ConfigMap
|
||||
|
||||
# 查看配置列表
|
||||
|
||||
假设您已进入名称空间界面,如下图所示:
|
||||
|
||||

|
||||
|
||||
配置列表位于图中左侧中部,点击 ***放大*** 按钮,可以将列表显示到更大的区域,如下图所示:
|
||||
|
||||
> 点击 **配置** 可以刷新该列表
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
# 创建配置
|
||||
|
||||
* 点击 ***配置 / 创建***
|
||||
|
||||
填写表单如下所示:
|
||||
|
||||
| 字段名称 | 填写内容 | 说明 |
|
||||
| --------------- | ------------------------------- | ---- |
|
||||
| 名称 | my-config-map | |
|
||||
| 配置标签 - 名称 | my-config-map | |
|
||||
| 配置标签 - 内容 | configmap | |
|
||||
| 配置数据 - 名称 | EUREKA_URL | |
|
||||
| 配置数据 - 内容 | http://cloud-eureka:9200/eureka | |
|
||||
|
||||

|
||||
|
||||
* 点击 ***保存***
|
||||
|
||||
配置信息创建成功
|
||||
|
||||

|
||||
|
||||
# 查看/编辑/删除 配置
|
||||
|
||||
* 点击列表中的 ***my-config-map***
|
||||
|
||||

|
||||
|
||||
编辑、删除操作可直接按照提示完成
|
||||
16
docs/guide/namespace/index.md
Normal file
@ -0,0 +1,16 @@
|
||||
# 应用管理
|
||||
|
||||
## 创建工作负载
|
||||
|
||||
## 删除工作负载
|
||||
|
||||
## 伸缩
|
||||
|
||||
## 升级工作负载版本
|
||||
|
||||
## 环境迁移
|
||||
|
||||
### 导出
|
||||
|
||||
### 导入
|
||||
|
||||
|
After Width: | Height: | Size: 378 KiB |
|
After Width: | Height: | Size: 246 KiB |
|
After Width: | Height: | Size: 170 KiB |
|
After Width: | Height: | Size: 145 KiB |
|
After Width: | Height: | Size: 157 KiB |
|
After Width: | Height: | Size: 182 KiB |
112
docs/guide/namespace/multi-env.md
Normal file
@ -0,0 +1,112 @@
|
||||
# 多环境
|
||||
|
||||
在实际开发项目的过程中,我们必然会碰到如下场景:
|
||||
|
||||
1. 创建一个开发环境,并在其中完成应用部署
|
||||
2. 创建一个测试环境,再次完成应用部署
|
||||
3. 创建一个准上线环境,再次完成应用部署
|
||||
4. 创建一个生产环境,再次完成应用部署
|
||||
|
||||
|
||||
|
||||
当我们的微服务系统较为复杂时,一个环境中可能需要部署许多(几十个甚至更多)的微服务部署单元,这个时候,重复在多套环境中执行部署任务就会变得容易出错。
|
||||
|
||||
|
||||
|
||||
Kuboard 针对这种场景,提供了导出配置、导入配置的功能,以便运维人员可以轻易的复制多套部署环境。
|
||||
|
||||
|
||||
|
||||
## 导出配置
|
||||
|
||||
### 前提
|
||||
|
||||
必须满足如下条件:
|
||||
|
||||
* 您已经通过 kuboard 的 [创建工作负载](/guide/namespace/workload) 功能完成了微服务的部署。
|
||||
|
||||
> 部署微服务过程中,您还可能用到 kuboard 的配置编辑功能、Secrets 编辑功能 等。
|
||||
|
||||
假设您已完成微服务部署,并已进入 namespace 界面,如下图所示:
|
||||
|
||||

|
||||
|
||||
### 操作步骤
|
||||
|
||||
* 点击 ***导出工作负载***
|
||||
* 选择要导出的分层
|
||||
* 点击 ***刷新***
|
||||
* 选择要导出的工作负载
|
||||
|
||||

|
||||
|
||||
* 点击 ***下一步***
|
||||
|
||||
选择要导出的配置(configMap)信息
|
||||
|
||||

|
||||
|
||||
* 点击 ***下一步***
|
||||
|
||||
选择要导出的 Secrets
|
||||
|
||||

|
||||
|
||||
* 点击 ***下一步***
|
||||
|
||||

|
||||
|
||||
* 点击 ***确定***
|
||||
|
||||

|
||||
|
||||
* 查看已导出文件
|
||||
|
||||
导出文件的命名格式为 kuboard_namespace_date_time.yaml,例如:
|
||||
|
||||
kuboard_example_2019_07_21_09_09_47.yaml
|
||||
|
||||
导出文件的内容如下所示:
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: StatefulSet
|
||||
metadata:
|
||||
namespace: example
|
||||
name: cloud-eureka
|
||||
annotations:
|
||||
k8s.eip.work/workload: cloud-eureka
|
||||
k8s.eip.work/displayName: 服务注册
|
||||
k8s.eip.work/service: ClusterIP
|
||||
k8s.eip.work/ingress: 'true'
|
||||
labels:
|
||||
k8s.eip.work/layer: cloud
|
||||
k8s.eip.work/name: cloud-eureka
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
k8s.eip.work/layer: cloud
|
||||
k8s.eip.work/name: cloud-eureka
|
||||
template:
|
||||
metadata:
|
||||
...
|
||||
```
|
||||
|
||||
> 该文件可以通过 kubectl apply -f 命令直接执行,但是建议使用 kuboard 进行导入,以便在导入时在线编辑在特定于新环境的配置信息。
|
||||
|
||||
|
||||
|
||||
## 导入配置
|
||||
|
||||
### 前提
|
||||
|
||||
您已经通过 kuboard 导出了配置文件,或者从别处获取到 kuboard 导出的配置文件
|
||||
|
||||
|
||||
|
||||
### 操作步骤
|
||||
|
||||
请参考 [导入 example 微服务](/guide/example/import)
|
||||
|
||||
|
||||
BIN
docs/guide/namespace/pvc.assets/image-20190721113708689.png
Normal file
|
After Width: | Height: | Size: 151 KiB |
BIN
docs/guide/namespace/pvc.assets/image-20190721113810235.png
Normal file
|
After Width: | Height: | Size: 203 KiB |
BIN
docs/guide/namespace/pvc.assets/image-20190721114112644.png
Normal file
|
After Width: | Height: | Size: 179 KiB |
BIN
docs/guide/namespace/pvc.assets/image-20190721114211751.png
Normal file
|
After Width: | Height: | Size: 216 KiB |
51
docs/guide/namespace/pvc.md
Normal file
@ -0,0 +1,51 @@
|
||||
# 存储卷声明
|
||||
|
||||
存储卷声明: Kubernetes Persistent Volume Claim
|
||||
|
||||
|
||||
|
||||
# 查看存储卷声明列表
|
||||
|
||||
假设您已进入名称空间界面,如下图所示:
|
||||
|
||||

|
||||
|
||||
存储卷声明列表位于图中左下角,点击 ***放大*** 按钮,可以将列表显示到更大的区域,如下图所示:
|
||||
|
||||
> 点击 **存储卷声明** 可以刷新该列表
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
# 创建存储卷声明
|
||||
|
||||
* 点击 ***存储卷声明 / 创建***
|
||||
|
||||
填写表单如下:
|
||||
|
||||
| 字段名称 | 填写内容 | 说明 |
|
||||
| ---------- | --------------- | ------------------------------------------------------------ |
|
||||
| 存储卷声明 | my-pvc | |
|
||||
| 存储类 | cluster-storage | 如果不存在,则需要提前 [创建存储类](./guide/cluster/storage?id=创建存储类) |
|
||||
| 分配模式 | 动态分配 | |
|
||||
| 读写模式 | 可被多节点读写 | |
|
||||
| 总量 | 2Gi | |
|
||||
|
||||

|
||||
|
||||
* 点击 ***保存***
|
||||
|
||||
存储卷声明创建成功
|
||||
|
||||

|
||||
|
||||
# 查看/编辑/删除 存储卷声明
|
||||
|
||||
* 点击 ***my-pvc***
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
编辑、删除操作可直接按照提示完成
|
||||
BIN
docs/guide/namespace/secrets.assets/image-20190721110355464.png
Normal file
|
After Width: | Height: | Size: 378 KiB |
BIN
docs/guide/namespace/secrets.assets/image-20190721110543437.png
Normal file
|
After Width: | Height: | Size: 144 KiB |
BIN
docs/guide/namespace/secrets.assets/image-20190721110815690.png
Normal file
|
After Width: | Height: | Size: 200 KiB |
BIN
docs/guide/namespace/secrets.assets/image-20190721111004189.png
Normal file
|
After Width: | Height: | Size: 202 KiB |
BIN
docs/guide/namespace/secrets.assets/image-20190721111011798.png
Normal file
|
After Width: | Height: | Size: 202 KiB |
BIN
docs/guide/namespace/secrets.assets/image-20190721111537218.png
Normal file
|
After Width: | Height: | Size: 155 KiB |
BIN
docs/guide/namespace/secrets.assets/image-20190721111540512.png
Normal file
|
After Width: | Height: | Size: 155 KiB |
BIN
docs/guide/namespace/secrets.assets/image-20190721111642221.png
Normal file
|
After Width: | Height: | Size: 206 KiB |
56
docs/guide/namespace/secrets.md
Normal file
@ -0,0 +1,56 @@
|
||||
# Secrets
|
||||
|
||||
|
||||
|
||||
# 查看 Secrets 列表
|
||||
|
||||
假设您已进入名称空间界面,如下图所示:
|
||||
|
||||

|
||||
|
||||
Secrets 列表位于图中左上角,点击 ***放大*** 按钮,可以将列表显示到更大的区域,如下图所示:
|
||||
|
||||
> 点击 **Secrets** 可以刷新该列表
|
||||
|
||||

|
||||
|
||||
# 创建 Secrets
|
||||
|
||||
* 点击 ***Secrets / 创建***
|
||||
|
||||
填写表单如下:
|
||||
|
||||
| 字段名称 | 填写内容 | 说明 |
|
||||
| --------------- | -------------------------------- | -------------------------- |
|
||||
| 名称 | my-docker-repository | Secrets的名称 |
|
||||
| 类型 | docker仓库密码 | |
|
||||
| docker server | https://my-docker-repository.com | 请填写 docker 仓库的全路径 |
|
||||
| docker username | my-docker-user | |
|
||||
| docker password | mypassword | |
|
||||
|
||||

|
||||
|
||||
>当前 Kuboard 支持如下类型 Secrets 的创建:
|
||||
>
|
||||
>* docker仓库密码
|
||||
> * 当您的镜像存储在私有仓库时,您在创建工作负载时可能需要配置 imagePullSecrets 用来访问镜像仓库
|
||||
>* Opaque
|
||||
> * 密码
|
||||
>* TLS
|
||||
> * 当您为 Ingress 启用 HTTPS 时,您需要将域名的的 TLS 证书存入 Secrets
|
||||
|
||||
* 点击保存
|
||||
|
||||
Secrets 创建成功,如下图所示:
|
||||
|
||||

|
||||
|
||||
# 查看/编辑/删除 Secrets
|
||||
|
||||
* 点击 my-docker-repository
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
编辑、删除操作可直接按照提示完成
|
||||
BIN
docs/guide/namespace/workload.assets/image-20190722223454676.png
Normal file
|
After Width: | Height: | Size: 114 KiB |
BIN
docs/guide/namespace/workload.assets/image-20190722223551308.png
Normal file
|
After Width: | Height: | Size: 103 KiB |
BIN
docs/guide/namespace/workload.assets/image-20190722223605920.png
Normal file
|
After Width: | Height: | Size: 131 KiB |
BIN
docs/guide/namespace/workload.assets/image-20190722224029397.png
Normal file
|
After Width: | Height: | Size: 148 KiB |
BIN
docs/guide/namespace/workload.assets/image-20190722225347491.png
Normal file
|
After Width: | Height: | Size: 112 KiB |
BIN
docs/guide/namespace/workload.assets/image-20190722225454029.png
Normal file
|
After Width: | Height: | Size: 227 KiB |
BIN
docs/guide/namespace/workload.assets/image-20190722230511430.png
Normal file
|
After Width: | Height: | Size: 68 KiB |
BIN
docs/guide/namespace/workload.assets/image-20190722231246540.png
Normal file
|
After Width: | Height: | Size: 113 KiB |
131
docs/guide/namespace/workload.md
Normal file
@ -0,0 +1,131 @@
|
||||
# 工作负载
|
||||
|
||||
|
||||
|
||||
## 创建/查看/编辑工作负载
|
||||
|
||||
|
||||
|
||||
请参考 [创建 busybox](/guide/example/busybox)
|
||||
|
||||
|
||||
|
||||
## 伸缩
|
||||
|
||||
伸缩操作,通过调整工作负载的 replicas 大小,来控制该工作负载运行容器组的数量。
|
||||
|
||||
|
||||
|
||||
* 假设您已进入工作负载查看界面,如下图所示:
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
* 点击 ***伸缩*** 按钮
|
||||
|
||||
填写表单
|
||||
|
||||
副本数: 目标容器组数量
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
* 点击 ***确定*** 按钮
|
||||
|
||||
等待,知道伸缩操作执行完毕。
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
## 删除容器组
|
||||
|
||||
* 点击 ***删除容器组*** 按钮
|
||||
|
||||
可删除该容器组。
|
||||
|
||||
* 容器组被删除之后,Kubernetes Workload Controller 将要重新创建一个容器组,用于替代被删除的容器组;被删除容器组原有的状态将丢失,新容器组重新从 镜像中加载启动;
|
||||
|
||||
* Kuboard 的工作负载编辑器,默认将容器组的 imagePullPolicy 设置为 Alwarys,因此,每次在容器组启动的时候,Kubenetes 都会尝试从镜像仓库中抓取最新镜像;
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
## 诊断问题
|
||||
|
||||
在诊断工作负载的问题时,Kuboard主要提供三种手段:
|
||||
|
||||
### 事件: Kubernetes 部署相关问题
|
||||
|
||||
如下图所示,图中提示
|
||||
|
||||
> 错误内容:Error: ErrImagePull 该容器组抓取镜像失败
|
||||
>
|
||||
> 失败原因:pull access denied for busy-box, repository does not exist or may require 'docker login'
|
||||
|
||||
对于这样的错误,需要技术人员检查:
|
||||
|
||||
* 容器所在节点与镜像仓库之间的网络连通性
|
||||
* 容器镜像拼写是否正确
|
||||
* 如果为私有仓库,是否在工作负载编辑器中正确配置了 docker 仓库用户名密码
|
||||
|
||||
!> Kuboard 监听了 Kubernetes 集群的事件变化,您无需刷新页面,即可在工作负载编辑器的容器组界面区域看到该容器相关的最新事件。
|
||||
|
||||
|
||||
|
||||
通过 Kubernetes 事件所指示出来的问题,通常是集群本身配置的问题,或者是创建工作负载时的参数填写问题,解决这样的问题需要的是 Kubernetes 集群相关的知识和背景,**通常运维人员可以独立解决此类问题**。
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
### 日志: 容器运行时产生的错误
|
||||
|
||||
如下图所示,假设您已进入工作负载查看界面:
|
||||
|
||||

|
||||
|
||||
* 点击其中的 ***日志*** 按钮
|
||||
|
||||
可查看该容器的运行时日志,如下图所示:
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
**容器运行时问题定位及解决**
|
||||
|
||||
日志所指示出来的错误,可能有两类原因:
|
||||
|
||||
* 将其容器部署到 Kubernetes 时,参数配置填写错误
|
||||
* 容器内应用程序自身的 BUG
|
||||
|
||||
无论是上述何种原因,运维人员如果请开发人员介入,一起排查这里问题,效果会好很多。
|
||||
|
||||
|
||||
|
||||
### 终端: 通过交互式命令,在容器内诊断问题
|
||||
|
||||
* 点击 ***终端*** 按钮
|
||||
|
||||
可进入该容器的交互式命令界面
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
**适用场景**
|
||||
|
||||
在交互式终端里,**运维人员**可以:
|
||||
|
||||
* 通过 ping / curl 等命令,测试网络连通性,测试 Kubernetes 的服务 DNS 解析是否正确
|
||||
* 通过 export 命令检查该容器的环境变量的设置是否正确
|
||||
|
||||
**开发人员** 可以:
|
||||
|
||||
* 通过 ls / cat / vi 等命令,查看该容器是否包含了最新的代码变更
|
||||
* 通过 vi 等命令,临时对容器中的配置文件进行修改,并在验证这种修改有效之后,才将其正式更新到代码库
|
||||
|
||||