Rancher 2.5特性解读丨更简单友好的API和Dashboard
本文来自Rancher Labs
关注我们,看K8S干货教程
作者简介
张智博,Rancher中国研发与产品总监。7年云计算领域经验,一直活跃在研发一线,经历了OpenStack到Kubernetes的技术变革,无论底层操作系统Linux,还是虚拟化KVM或是Docker容器技术都有丰富的研发和实践经验。
自Rancher 2.0系列版本问世,以其简单务实的UI风格和成熟稳健的后端架构赢得了市场的普遍青睐。Kubernetes本身架构和功能逐渐稳定,同时拥有丰富经验的Kubernetes技术人员也在不断增加,根据市场出现的这些新变化,我们近期发布的Rancher 2.5对此做出了诸多改变。本文将从API和Dashboard两个角度来探讨Rancher 2.5的变化。
Kubernetes Native API
Rancher 2.5之前的版本中,我们对原生的Kubernetes API做了一些封装,以便适应我们的UI展示需求。这些封装的好处就是,我们可以定义适用自身的数据结构,并且提供了一套可以单独交互的API-UI,用户可以使用它来模拟调用API。通常在Rancher UI的很多入口中,点击“View API”或者在浏览器中访问“https://
https://github.com/rancher/api-spec
当然,这种做法的劣势显而易见,从Rancher工程师和社区用户的使用经验看,主要有以下几点:
-
扩展Rancher API非常复杂,只有深入阅读Rancher代码或者接受了一定培训的开发人员才能做到。
-
Kubernetes API在不断演变,Rancher API去兼容多个版本的Kubernetes API变得越来越困难。
-
Rancher API屏蔽了一些高级API参数,对于一些高级用户,这非常不友好。
对于这些问题,我们在Rancher 2.4已经开始尝试做一些改变,细心的小伙伴可能发现了Rancher 2.4的新型Dashboard,它背后使用的就是新风格的Rancher API。这套API的实现依靠一个相对独立的组件steve,为了解决之前的API问题,steve做了以下改善工作:
-
完全沿用Rancher的API-UI模式,不破坏用户的使用习惯。
-
兼容Kubernetes Native API,包括原生对象和CRD,最大程度保留其数据字段。
-
扩展API非常简单,只要向Kubernetes注册了CRD,steve通过内置controller来watch CRD资源变化,将其热装载加入steve API中。
Steve是一个较为独立的组件,即使离开Rancher也依然能够独立运行。如果想要在二次开发Kubernetes,但是觉得原生API不友善,完全可以在上面启用Steve风格的API。笔者做了一个小实验,部署k3s并独立安装steve,可以非常方便得到一个友好的API。
k3s安装过程较为简单直接略过,steve的编译直接参考Makefile/Dockerfile即可。成功编译后,会在本地生成一个steve:latest
的镜像,然后使用docker run -itd --net=host -v ${HOME}/.kube:/root/.kube steve:latest
启动steve,我们就能够获得一个Kubernetes Native的Rancher API。访问“https://
Kubernetes Native Dashboard
如今Kubernetes生态中,可接入的扩展组件越来越多,往往我们会在Kubernetes中安装Prometheus、Istio、ArgoCD等各种程序,这些程序基本都会通过CRD来增强自己的服务能力。这就导致了集群中存在大量的CRD,并且越来越难以管理,于是很多经验丰富的高级技术人员开始期望CRD的可视化管理,以避免Kubectl CLI操作的繁琐。从这个需求出发,Rancher 2.5中集成的新Dashboard也更加Kubernetes Native化。
这一切都源于Steve API的能力,可以让我们非常方便地间接使用Kubernetes API。在Rancher 2.4中,我们已经提供了这个功能的实验版,相信很多用户都已经试用。在Rancher 2.5中,这部分功能将会正式提供,这对于管理单个Kubernetes集群的高级技术人员将会非常友好。
新的Dashboard可以对Kubernetes原生资源和CRD扩展资源都进行可视化管理,在诸如Kubernetes原生资源的创建等表单上也会提供全面的参数设置,比Rancher 2.4时代的实验性Dashboard更加成熟。整体的页面风格也更加倾向简洁,对于熟练使用Kubernetes的开发的人员会非常方便,同时也采用了Vue框架编写,这对于国内用户做二次开发也是一个大利好。
上手体验Rancher 2.5
在Rancher 2.5中可以继续使用docker run
方式试用体验,与先前不同的是需要增加privileged参数:
$ sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 --privileged rancher/rancher:v2.5.1
启动完成后,首次进入登录页,除了配置初始化密码外,还要设置默认视图。两个视图分别是:多集群管理和单集群管理,前者沿用Rancher2.4 UI并做增强,后者就是前文介绍的Kubernetes Native Dashboard。对于Native Dashboard,由于启动时增加了privileged提权参数
,所以可以在容器中启动一个完整的local集群,原先docker run
方式只能启动的是kube-api,并非一个完整集群,现在通过新的Dashboard则可以完整管理它,在local集群上新建workload,当然我们相信你只会在开发测试时如此使用。
总的来说,期望单一集群管理的用户,相比之前会节省很多部署资源。而期望使用多集群管理的用户,Rancher 2.5依然会保留访问入口,同时多集群管理的核心功能也将会有重大的提升,Rancher 2.5整体架构也更加灵活,将会非常方便用户进行模块化的扩展,这些内容我们在后续的文章中逐步交流。