展开查看详情
1 .SIG-Service Catalog
Introduction
Doug Davis - dug@us.ibm.com - @duginabox
1
2 .Applications are rarely islands
● Often applications leverage ancillary "Services"
○ E.g. Application stores data in database
● Critical to application's success
○ But developers shouldn't spend their time managing them
2
3 .Services - an overloaded term
● Kubernetes “Services”
○ Applications running in the cluster accessible via DNS discovery
● Platform managed/hosted Services
○ e.g. Object Storage
● External Services - 3rd Party Services
○ e.g. Twillio
3
4 .Access to services can be challenging
● Creating and managing services is non-trivial
○ Duplication of effort across teams
○ Ops team manages it for you on their schedule
○ Managing credentials could be problematic
■ Sent via email, sticky-notes, etc…
■ Where are they stored? Plain text in config files?
○ Each service has its own set of provisioning APIs
● Let’s shift the burden to the Platform via self-service model
○ "Tell us what you need and we'll manage it for you"
○ Service Credentials are protected and provided at runtime
4
5 .What if ...?
$ svcat marketplace
CLASS PLANS DESCRIPTION
+------------+--------------------------+------------------------+
mysql free Simple SQL
basic
enterprise
mongodb free No-SQL DB
$ svcat provision myDB --class mysql --plan free
$ svcat bind myDB
Credentials (and connection info) in “myDB” secret
5
6 .The magic
Cluster Admin:
● Service Brokers are registered with Kubernetes
○ Each Broker manages one or more Services
○ Each Service offers a set of variant-QoSs/Plans
● Services are available via a “Marketplace” in Kubernetes $ svcat marketplace
Developer:
● Chooses a Service from the Marketplace $ svcat provision myDB...
● Kubernetes talks to owning Broker to provision it
and obtain the credentials $ svcat bind myDB
● Secret (credentials, connection info) is available to the app
6
7 .Making it all possible
● API between Kubernetes (or CF) and a Service Broker
○ get list of services / provision / deprovision / bind / unbind
● Abstracts the Service Lifecycle APIs
● Service Brokers
○ Manage all aspects of Service's lifecycle
○ User Initiated: Create, Delete, Provide Credentials
○ Automatic: Auto-Scale, Backup, Recovery, QoS, …
○ Hosted anywhere – in or out of the Platform
■ Application is usually unaware
7
8 .Why?
● Application Developers
○ Can focus on their business logic
○ Services managed by the experts
○ Self-service model speeds up CI/CD timelines
○ Platforms can do more for you - e.g. sharing of services across clusters & platforms
● Service Providers
○ Low barrier or entry for new Service Providers
○ Interop: easily integrated into environments that supports the API
■ Kube, CloudFoundry, custom platforms (e.g. IBM Cloud, SAP)
○ With ease of access to services, an increase in their usage ($)
8
10 .YAML all the things
apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceInstance
metadata:
name: myDB
spec:
serviceClassName: mysql
planName: free
apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceBinding
metadata:
name: myDB
spec:
instanceRef:
name: myDB
Credentials and connection info in “myDB” secret 10
11 .Service Catalog Summary
Why?
● Help developers discover and connect to 3rd party services
● Allowing them to focus on their business logic
○ Ask for the service - connection information provided at runtime
Status
● Kubernetes incubator project
● Can be deployed into any Kubernetes cluster via a Helm chart
● Beta
11
12 .One last thing about Services
● A service can be just about anything
● Data & Analytics – e.g. DBs, ElasticSearch
● Integration – e.g. Box, Twitter, SendGrid
● Utilities – e.g conversions, speech to text
● Infrastructure – networks, volumes, routing
● DevOps – monitoring, metrics, auto-scaling
12
13 .Questions
More information:
● https://svc-cat.io
● https://github.com/kubernetes-incubator/service-catalog
● https://www.openservicebrokerapi.org/
● Deep Dive session: Thursday, November 15, 11:30 - 12:05 (3M 3)
13
热门城市
