导入已有资源
本篇文档介绍了如何将集群中命名空间下的资源导入 Rainbond 。
- 治理模式默认为 k8s 原生 service 模式
- Rainbond 创建或导入过的命名空间以及 'kube-' 开头的命名空间不会被识别。
- 仅支持部分类型的转换,详细支持转换资源类型如下。
- 导入过程中,如果组件类型资源的 pod 模版内有多个容器, Rainbond 默认只会识别第一个容器,其他容器会丢失,如果想启动多个容器,可以了解一下 Rainbond 的插件制作。
导入转换策略
以下便是按照类型划分的详细的支持资源清单。
组件类型资源
该类型资源导入完成后会转换成 Rainbond 中的组件。
k8s资源 | Rainbond模型 |
---|---|
Deployment | 无状态组件 |
StatefulSet | 有状态组件 |
CronJob | 定时任务组件 |
Job | 任务组件 |
组件属性资源
组件类型资源自身携带的一些属性值,如Port、ConfigMap、volume等
组件属性 | Rainbond模型 |
---|---|
nodeSelector | 组件特殊属性 |
labels | 组件特殊属性 |
tolerations | 组件特殊属性 |
volumes | 组件特殊属性 |
serviceAccountName | 组件特殊属性 |
affinity | 组件特殊属性 |
volumeMount | 组件特殊属性/配置文件 |
privileged | 组件特殊属性 |
port | 组件端口 |
HorizontalPodAutoscalers | 组件伸缩策略 |
env | 环境变量/组件特殊属性 |
HealthyCheckManagement | 组件健康检测 |
如果组件的 volumeMount 挂载了 ConfigMap 类型的 volume ,则会转化为组件的配置文件。
如果 env 是引用类型,则不会被识别到 Rainbond 的环境变量。
k8s资源类型
供应用下的组件调用的资源(暂只支持导入以下几种资源)
k8s资源类型 |
---|
Service |
PersistentVolumeClaim |
Ingress |
NetworkPolicy |
ConfigMap |
Secret |
ServiceAccount |
RoleBinding |
HorizontalPodAutoscaler |
Role |
该类型资源导入完成后会存储到对应应用下的 k8s 资源中供组件特殊属性使用,特殊属性中volume可以绑定 ConfigMap 、 Secret |
开始导入
资源导入有两个入口:
- 平台管理 -> 集群 -> 导入。
- 团队视图内 -> 新增 -> Kubernetes YAML Helm -> 导入 Kubernetes 已有资源。
前提条件
- 已了解 Rainbond 的团队、应用、组件等所有模块的概念
- 存在一个不是 Rainbond 所管理的命名空间并且命名空间下有k8s资源。
- 把想要放在同一应用下的 k8s 资源添加上统一的label标签,格式为
app.kubernetes.io/name:xxx
或app:xxx
。 - 了解资源导入的入口(在集群视图下的操作栏里点击导入按钮)。
下面将会以 Linkerd 命名空间为例, 介绍在 Rainbond 上导入Linkerd命名空间及其内部的资源。
选择命名空间
-
从下拉框中选择你要导入的命名空间。
-
等待页面识别完毕后,你会看到页面会按照应用/资源类型/名称 逐级划分,应用是按照标签
app.kubernetes.io/name:xxx
或app:xxx
划分的请检查是否有遗漏或排列位置不对的资源,不含划分应用标签的资源会全部放到默认的未分组应用下。 -
在检测过程中如果有资源位置不对需要调整,或者不想导入了,可点击上一步后进去集群中去调整,调整完成后再重新进入识别页面,识别页面是可以反复查看的。
-
在查看资源类型及名称并选择命名空间后,确认无误点击下一步进入到高级识别。
高级资源识别
-
在这个页面你能看到你部署在集群中的资源对应到 Rainbond 各个模块后的体现。其中Deployment、Job、Cronjob、StatefulSet会识别为组件,其他Service、HPA等资源会对应解析为应用视图下的k8s资源中。
-
在确认无误后,点击确认导入。
资源导入
-
在经过前两轮的检查后,点击确认导入,Rainbond将开始导入并接管资源,过程需要经过拉取镜像、数据入库等一系列操作,所以需要等待一些时间,等待时间长短取决于命名空间下资源的数量。
-
导入完成后会跳转到团队视图下,便可以看到 Rainbond 接管后的资源。
-
unclassified应用则是上面所说的默认未分组应用。
Rainbond在接管后不会立刻重启用户在集群中的资源,当用户点击重启或更新等操作后,才会生产出一个完全由 Rainbond 接管的资源。