参考:https://kubernetes.io/docs/concepts/extend-kubernetes/service-catalog/
Service Catalog是kubernetes的一种API扩展,方便kubernetes集群内部应用访问集群外部、由第三方管理、提供的服务,如由云供应商提供的数据库服务。Service Catalog通过Service Brokers使集群内应用能够列出外部服务、提供实例、将集群内应用与实例绑定,使集群内应用不必关心外部服务的实现、管理细节。总结起来就是Service Broker代表外部服务,集群内应用通过Service Catalog使用Service Broker。
Example use case
假如集群内应用的开发者想要使用一个消息队列,但又不想关心消息队列的方方面面,即纯粹只是作为消费者而不是提供者。正好,有一个云服务供应商,通过它们的service broker提供此种类型的服务供外部用户使用。这里又出现了"service broker"一词,但这里的意思与上文应该不同,这里指的应该是云服务商的"service broker",代表的是云服务商内部想要提供给外部使用的服务。由些可见,想要让集群内服务被集群外实例使用,也要提供"service broker"。
集群管理员通过设置Service Catalog,由它负责与云服务供应商的service broker通信、提供服务实例,而集群内的应用通过Service Catalog使用外部服务。这样,集群内应用无需关系外部服务的实现细节、管理等。
Architecture
首先要明确,Service Catalog通过Open service broker API与外部service broker通信,而不是随意的其它什么东西。Service Catalog扮演中间人角色,负责在集群内应用与外部服务之间协商如实例初始化、认证等相关操作,注意它的角色:中间人。
那么Service Catalog是怎么实现的呢?Kubernetes是高度可配置、可扩展的平台,Service Catalog就是通过扩展实现。包含两个方面,一个是对apiserver的扩展,Service Catalog本身就是一个扩展的apiserver。另外一个方面是管理控制器控制,是对kubernetes控制管理面的扩展,总之是通过扩展实现。另外需要提供额外的etcd存储,也就是说Service Catalog并没有完全使用Kubernetes的etcd。它也使用从1.7版本开始可用的aggregation layger表示API。
API Resources
要使用Service Catalog需要先安装servicecatalog.k8s.io API,它提供了如下可使用的kubernetes资源:
- ClusterServiceBroker:这类资源由集群管理员根据所有使用的外部服务创建、管理。表示集群内的service broker,负责封装低层通信有关的细节。
- ClusterServiceClass:由外部service broker管理、提供的服务。当ClusterServiceB