Rancher 2.5特性解读丨更简单友好的API和Dashboard
本文来自Rancher Labsgit
关注咱们，看K8S干货教程github
做者简介docker
张智博，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://<server-url>/v3”便可查看访问。这些API自己基于Kubernetes CRD实现，封装后造成了Rancher风格API。至于如何定义Rancher风格API，能够访问此连接查看：api
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作了如下改善工做：
less
-
彻底沿用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://<ip>:9443/v1”能够查看效果：
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总体架构也更加灵活，将会很是方便用户进行模块化的扩展，这些内容咱们在后续的文章中逐步交流。