您现在的位置是:主页 > 数据库技术 > 数据库技术

Rancher 2.5中的API和Dashboard有什么作用

IDCBT2021-12-29服务器技术人已围观

简介本篇内容主要讲解“Rancher 2.5中的API和Dashboard有什么作用”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“Rancher 2.5中的API和Dashbo

本篇内容主要讲解“Rancher 2.5中的API和Dashboard有什么作用”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“Rancher 2.5中的API和Dashboard有什么作用”吧!

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工程师和社区用户的使用经验看,主要有以下几点:

    扩展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://<ip>:9443/v1”可以查看效果:

    Kubernetes Native Dashboard

    如今Kubernetes生态中,可接入的扩展组件越来越多,往往我们会在Kubernetes中安装Prometheus、Istio、ArgoCD等各种程序,这些程序基本都会通过CRD来增强自己的服务能力。这就导致了集群中存在大量的CRD,并且越来越难以管理,于是很多经验丰富的高级技术人员开始期望CRD的可视化管理,以避免Kubectl CLI操作的繁琐。从这个需求出发,Rancher 2.5中集成的新Dashboard也更加Kubernetes Native化。

    标签:

    很赞哦! ()

本栏推荐