13518219792
本篇内容主要讲解“Rancher 2.5中的API和Dashboard有什么作用”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“Rancher 2.5中的API和Dashboard有什么作用”吧!
创新互联公司于2013年开始，先为钦北等服务建站，钦北等地企业，进行企业商务咨询服务。为钦北企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。
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生态中，可接入的扩展组件越来越多，往往我们会在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中可以继续使用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整体架构也更加灵活，将会非常方便用户进行模块化的扩展，这些内容我们在后续的文章中逐步交流。
到此，相信大家对“Rancher 2.5中的API和Dashboard有什么作用”有了更深的了解，不妨来实际操作一番吧！这里是创新互联网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
