Kubernetes From The Inside Out
Kubernetes is famously known for having an opinionated architecture; most notably container orientation, networking idioms, and declarative orchestration. As Kubernetes development has progressed, an increasing number of features have been added to accommodate and integrate with the very unopinionated (or at least diversely opinionated) world that surrounds it.
Back in late 2015 when I wrote the initial Cloudify to Kubernetes 1.0 integration for Cloudify, Kubernetes was narrowly focused on container orchestration. In those days, efforts were devoted to instantiating and operating Kubernetes, in other words, orchestration "from the outside in". These pursuits are still valid, and Cloudify continues to refine related features. However much has changed. While container orchestration of course remains the primary focus, many integration/extension related features have been added that greatly expand the possibilities for automation. I'm focusing on extensions that facilitate the consumption and coordination of services external to Kubernetes from the inside out. This is the first of a series of blog posts that explore a few of the more promising integration pathways from the Cloudify perspective.
An intriguing extension, and one that is a natural for Cloudify, is the service catalog. The service catalog extension provides access from applications running in Kubernetes to arbitrary external services, via a "service broker". A service broker is a service that could be running in or out of Kubernetes that provides a REST API Kubernetes as defined in the Open Service Broker API.
The Open Service Broker API defines a generic mean of exposing a service catalog or marketplace to Kubernetes. The service catalog concept as defined by the API supports describing service capabilities, bindings, and service variations called "plans". Plans define a particular service configuration and an optional related cost. Once Kubernetes is linked to the broker, services can be requested via the ServiceInstance kind.
apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceInstance
metadata:
name: cloud-queue-instance
namespace: cloud-apps
spec:
# References one of the previously returned services
clusterServiceClassExternalName: cloud-provider-service
clusterServicePlanExternalName: service-plan-name
#####
# Additional parameters can be added here,
# which may be used by the service broker.
#####The clusterServiceClassExternalName and clusterServicePlanExternalName are provided to Kubernetes via the broker API, and accessed by an operator via a kubectl command. Architecturally, the picture is as follows:
To implement this architecture for Cloudify, the service broker must be implemented with the proscribed Open Service Broker northbound interface, ultimately mapping to the Cloudify REST API on the south.
As part