Kubernetes服务目录的设计
【3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站】本次培训围绕基于Docker的CI/CD实战展开,具体内容包括:持续集成与持续交付(CI/CD)概览;持续集成系统介绍;客户端与服务端的 CI/CD 实践;开发流程中引入 CI、CD;Gitlab 和 CI、CD 工具;Gitlab CI、Drone 的使用以及实践经验分享等。
服务目录是基于Kubernetes的Open Service Broker API实现。 它包括如下功能:
- 服务中介注册到Kubernetes上;
- 服务中介指定一组服务(或这些服务的变体),提供给Kubernetes用户;
- Kubernetes用户可以发现可用的服务;
- Kubernetes用户可以请求新的服务实例;
- Kubernetes用户可以链接服务实例到一组Pods上;
这种底层机制允许在Kubernetes中运行的应用程序与它们使用的服务之间松耦合。 服务中介是一个黑盒实体,可以运行在Kubernetes外。 服务中介允许应用专注于自己的业务逻辑,将服务的管理交给服务中介。
术语
- 应用(Application):服务目录中的服务与Kubernetes中的“服务”是不同的。为避免混淆,我们使用“应用”表示Kubernetes的服务实例;
- 绑定或服务绑定(Binding):服务实例和应用之间的链接。它表示应用引用和使用特定服务实例的意图;
- 中介或服务中介(Broker):一个实体,用于管理一组或多个服务,可以通过网络端点访问服务中介;
- 凭证(Credentials):应用与服务实例通信所需的信息;
- 实例或服务实例(Instance):服务的实现称为服务实例;
- 服务类或服务(Service Class):服务中介提供的一种服务类型;
- 计划或服务计划(Plan):服务类型的变体。例如,服务可以暴露一组计划,它们提供不同程度的服务质量(QoS);
Open Service Broker API
服务目录是 Open Service Broker API (OSB API)的兼容实现。 OSB API规范是 Cloud Foundry Service Broker API 的演进。
本文档不会详细介绍OSB API的工作原理,相关信息请参阅: Open Service Broker API 。 本文的其余部分假设读者熟悉OSB API规范的基本概念。
服务目录设计
服务目录的设计如下图所示:
![](http://dockerone.com/uploads/article/20170815/9e4cea09ae423f308589b07a2133a3aa.png)
请注意,该项目的当前状态并不完全支持设计中所述的所有内容,但我们从目标开始,然后指出当前项目状态,通过 [DIFF] 标记不同。
作为服务目录的核心,与Kubernetes核心一样,它是一个API服务器和一个控制器。 API服务器是用于存储组件HTTP(REST)RESTful的前端。系统的用户及系统的其他组件与API服务器进行交互,以便在服务目录资源模型上执行CRUD类型的操作。与Kubernetes本身一样,kubectl命令行工具可用于与服务目录资源模型进行交互。
服务目录API服务器后面的存储组件可以是 etcd 或 第三方资源 (TPRs)。 rest.storage接口抽象正在使用的特定持久存储设备。当使用etcd时,etcd的实例将与Kubernetes的etcd实例不同,这意味着,服务目录将具有与Kubernetes不同的持久存储。当使用TPRs时,这些资源将被存储在Kubernetes中,因此不需要单独的持久存储。
[DIFF] 到目前为止,API服务器只能使用etcd作为其持久存储。在不久的将来,API服务器的rest.storage接口将添加对TPRs的支持。
服务目录资源模型在pkg/apis/servicecatalog/types.go的文件中定义,模型的初始(当前)版本在pkg/apis/servicecatalog/v1alpha1/中。到目前为止,只有一个版本的模型,但随着时间的推移,将会创建其他版本,每个版本都将有自己的pkg/apis/servicecatalog /的子目录中。
控制器是服务目录的大脑。它监视资源模型(通过API服务器上watches接口),并根据其检测到的更改采取适当的操作。
要了解服务目录资源模型,最好通过一个典型的工作流程:
服务中介注册
在应用使用服务之前,服务中介首先向Kubernetes平台注册。服务中介管理服务,我们首先通过创建Broker实例来注册服务中介:
kubectl create -f broker.yaml
broker.yaml内容如下:
apiVersion: servicecatalog.k8s.io/v1alpha1 kind: Broker metadata: name: BestDataBase spec: url: http://bestdatabase.com
创建中介资源后,服务目录控制器将收到数据存储区添加资源的事件。然后,控制器将查询服务中介(指定的URL)以获取可用服务列表。然后,每个服务都将创建一个相应的服务资源:
apiVersion: servicecatalog.k8s.io/v1alpha1 kind: ServiceClass metadata: name: smallDB brokerName: BestDataBase plans...
请注意,每个服务可以有一个或多个与之相关联的计划。
用户可以查询可用服务列表:
kubectl get services
创建服务实例
在使用服务之前,必须创建一个新的实例。创建一个新的Instance资源:
kubectl create -f instance.yaml
instance.yaml内容如下:
apiVersion: servicecatalog.k8s.io/v1alpha1 kind: Instance metadata: name: johnsDB spec: serviceClassName: smallDB
在实例资源内可以指定使用的计划。允许用户指定他们想使用的服务的变体 - 可能是基于QoS的服务类型变体。
一旦Instance资源被创建,控制器会与指定的服务中介协商来创建一个所需服务的新的实例。
有两种创建方式: 同步和异步 。
对于同步操作,向服务中介发出请求,并且在成功完成请求(200 OK)后,服务实例可以被应用使用。
一些服务中介支持异步方式。当控制器向服务中介发出create/update/deprovision请求时,服务中介以202 ACCEPTED响应,并提供GET请求端点:GET /v2/service_instances/<service_instance_id>/last_operation,控制器可以轮询请求状态。
服务中介为每个last_operation请求发送返回一个last_operation字段。轮询请求的状态为“in_progress”时,控制器将继续轮询。控制器会考虑轮询请求的最大超时,并将停止轮询并将创建标记为失败。
虽然服务实例正在进行异步操作,但控制器必须确保没有其他操作(提供,取消,更新,绑定,取消绑定)。
使用服务实例
在使用服务实例之前,必须将其绑定到应用程序。这意味着应用和服务实例之间的链接或使用意图必须建立。创建一个新的Binding资源:
kubectl create -f binding.yaml
binding.yaml内容如下所示:
apiVersion: servicecatalog.k8s.io/v1alpha1 kind: Binding metadata: name: johnsBinding spec: secretName: johnSecret ...Pod selector labels...
控制器,接到新的Binding资源通知后,将与服务中介通信,为指定的服务实例创建一个新的绑定。从服务中介返回的Binding对象中有一组凭据。这些凭据包含应用程序与服务实例通信所需的所有信息。例如,它可能包括以下内容:
- 服务实例的URL
- 用户ID和密码来访问服务实例
OSB API规范不要求在凭据中显示什么属性,因此需要应用了解返回的指定数据以及如何正确使用它们。这通常通过阅读服务的文档来完成。
凭证不会存储在服务目录的数据存储中。相反,它们将作为秘密存储在Kubenetes中,并且将Secret的引用保存在Binding资源中。如果未指定Binding的Spec.SecretName,则控制器将使用Binding Name属性作为Secret的名称。
绑定不需要与服务实例位于相同的Kubenetes命名空间中。允许跨应用和命名空间共享服务实例。
除了Secret之外,控制器还将在Kubernetes中创建一个 Pod注入策略(PIP) 资源。有关更多信息,请参阅PIP提案,但简而言之,PIP定义了在创建Pod时如何修改Pod的规范以包含其他卷和环境变量。特别地,服务目录将使用PIPs来允许应用程序所有者指示Secret应该如何提供给其Pods。例如,他们可以定义一个PIP来指示Secret安装到Pod中。或者Secret的名称/值应该被暴露为环境变量。
PIP将使用标签选择器来指示哪些Pod将被修改。例如:
kind: PodInjectionPolicy apiVersion: extensions/v1alpha1 metadata: name: allow-database namespace: myns spec: selector: matchLabels: role: frontend env: - name: DB_PORT value: 6379
定义一个PIP,添加一个名为DB_PORT的环境变量,值为6379,所有具有Role标签的Pods都具有此前端值。
最终,OSB API规范将希望有关于凭证的额外元数据,以指出哪些字段被认为是“Secret”,哪些不是。当该支持可用时,期望将非Secret信息放入ConfigMap而取代Secret。
一旦Secret提供给应用Pods中,那么应用代码就可以使用该信息与服务实例进行通信。
删除服务实例
与Kubernetes中的资源一样,可以通过对资源执行HTTP DELETE来删除服务目录资源。 但是,请注意,有相关的绑定存在时,服务实例不能被删除。 换句话说,在删除服务实例之前,必须先删除其所有绑定。 删除具有绑定的实例将失败并产生错误。
删除绑定也将自动删除与之相关联的Secret或ConfigMaps。
当前设计
上述各节描述了服务目录的当前设计。 但是,有些尚未到位,代码不一定与之对齐。 目前的设计实际上更像是这样:
![](http://dockerone.com/uploads/article/20170815/2e9424034581e7ae939ea75fed470100.png)
不同的方面:
- API服务器只能使用etcd作为其持久存储。
- API服务器没有连接到控制器,这意味着它并没有被实际作为运行系统的一部分。 只是通过与API服务器通信完成资源的创建和存储。
- 可以使用Kubernetes的API服务器创建服务目录资源的TPRs版本是当前系统的工作方式。 然后,控制器将与Kubernetes中API服务器进行通信,并监视服务目录资源的TPRs版本,采取一切适当的措施。
原文链接:Design of the Service Catalog(翻译:范彬)
===============================================================
译者介绍:范彬,从事微服务、Docker和Kubernetes容器技术等方面的工作。可以关注译者的微信公众号:范范米饭。
原文发布时间为:2017-08-15
本文作者:范彬
本文来自云栖社区合作伙伴Dockerone.io,了解相关信息可以关注Dockerone.io。
原文标题:Kubernetes服务目录的设计
Kubernetes服务目录的设计相关推荐
- DEVOPS 运维开发系列一:ITIL服务目录管理流程的设计与信息化管理系统功能的开发
ITIL是世界范围内公认的运维服务管理的最佳实践.ITIL的理论落地,不需要什么信息系统的支持,使用word文件.Excel表格一样可以对ITIL的十几个关键管理流程做到很好的落地.虽然是这么讲,但现 ...
- Kubernetes的Device Plugin设计解读
摘要: Kubernetes的生态地位已经确立,可扩展性将是其发力的主战场.异构计算作为非常重要的新战场,Kubernetes非常重视.而异构计算需要强大的计算力和高性能网络,需要提供一种统一的方式与 ...
- azure云服务使用方法_在Azure Kubernetes服务上使用HashiCorp Consul
azure云服务使用方法 Kubernetes之类的工具在简化大规模构建分布式应用程序的过程上大有帮助. 但是它们只是故事的一部分,提供了在主机系统之间复制容器化微服务的方法. 如果要获得抽象的数据中 ...
- mysql servicebroker_阿里云Kubernetes服务 - Service Broker快速入门指南
4月底阿里云容器服务上线了基于Kubernetes集群的服务目录功能.阿里云的容器的服务目录遵循Open Service Broker API标准,提供了一系列的服务代理组件,实现了对主流开源服务如M ...
- 阿里云Kubernetes服务 - Service Broker快速入门指南
4月底阿里云容器服务上线了基于Kubernetes集群的服务目录功能.阿里云的容器的服务目录遵循Open Service Broker API标准,提供了一系列的服务代理组件,实现了对主流开源服务如M ...
- 将微服务部署到 Azure Kubernetes 服务 (AKS) 实践
介绍 本文的目的是:通过使用 DockerHub 和 Azure Kubernetes Service (AKS) 将之前 使用 .NET 和 Docker 构建的微服务 部署到微软 Azure 云上 ...
- 阿里P8架构师谈:从单体架构、到SOA、再到微服务的架构设计详解
本文涉及的内容以及知识点如下: 1.单体架构 2.单体架构的拆分 3.SOA与微服务的区别 4.微服务的优缺点 5.微服务的消息 6.服务集成 7.数据的去中心化 单体架构 Web应用程序发展的早期, ...
- 三大公有云托管 Kubernetes 服务 (EKS、GKE、AKS) 评估
EKS vs GKE vs AKS - Evaluating Kubernetes in the Cloud | StackRoxhttps://www.stackrox.com/post/2021/ ...
- 使用Docker和Azure Kubernetes服务将ASP.NET核心应用程序容器化
目录 介绍 应用概述 容器化ASP.NET核心应用程序 部署在本地Kubernetes集群上 Docker镜像和Azure容器注册表(ACR) 部署Azure Kubernetes服务(AKS)群集 ...
最新文章
- 【QM-05】Material Specification(物料说明)
- Centos 5.5下面架设NTP服务器
- 拓普微智能TFT液晶显示模块
- javascript event
- 从零基础到精通的前端学习路线
- 外卖员不满上楼送餐要求向外卖吐口水4次,顾客不知情吃下整份外卖...
- 一加手机安装鸿蒙系统,【新机】华为MatePad Pro 2官宣,刘作虎点赞鸿蒙手机
- Mozilla在Thunderbird 60.3中的修补了多个安全漏洞
- docker镜像的常用操作
- 富勒wms系统里的定时器id_WMS项目实施,该如何调研?
- android跳转界面的方法有多少,Android跳转WIFI界面的四种方式
- 访谈 | 币圈量化群英会——寻找适合你的量化基金!
- 计算机网卡实现的功能,网卡实现的主要功能是什么
- 特异度(specificity)与灵敏度(sensitivity)
- Excel 相对引用 绝对引用 区别是什么 如何快速转换 快捷键 F4
- Wincc 开机自检动态展示
- WPF控件模板和数据模板的区别
- C语言基础练习-输入球体半径,计算球体表面积和体积
- Java第十六天~第十七天/11.18~11.19
- 国内外著名的云计算厂商平台
热门文章
- 华为国产系统Android,在小米MIUI或华为中,哪种手机系统最适合2019年的国产Android?...
- 2020考研803计算机基础综合,2020年北京邮电大学803计算机学科基础综合考研大纲...
- Jenkins+cocoapods+pgy+多版本 持续集成
- 十六进制转十进制 python
- swift3 多个异步网络请求转同步
- 推荐Leangoo团队协作的20个理由
- C++程序设计实验之三国游戏
- 倦怠和枯燥_3个在家工作倦怠的警告信号
- Java从小兵到指挥官领兵作战—线程高并发扫盲篇
- kubernetes-事件监控