Rancher 2.5特性解读丨更简单友好的API和Dashboard

Posted 2020-12-20

本文来自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://<server-url>/v3”即可查看访问。这些API本身基于Kubernetes CRD实现，封装后形成了Rancher风格API。至于如何定义Rancher风格API，可以访问此链接查看：

https://github.com/rancher/api-spec

 

当然，这种做法的劣势显而易见，从Rancher工程师和社区用户的使用经验看，主要有以下几点：

 

1. 扩展Rancher API非常复杂，只有深入阅读Rancher代码或者接受了一定培训的开发人员才能做到。

2. Kubernetes API在不断演变，Rancher API去兼容多个版本的Kubernetes API变得越来越困难。

3. 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://<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整体架构也更加灵活，将会非常方便用户进行模块化的扩展，这些内容我们在后续的文章中逐步交流。