Description
The service catalog binds together the K8s service files for deploying the service, service descriptions for project admins to configure a service with options via a CLI/GUI, and provides interfaces to configure service repositories and to manage and maintain the per-cluster service catalog that is cached in etcd.
Design Session Notes - 16/02/16:
Resolved:
- Dev side: Separate docker image builds from catalog/configure/deploy files
- proposed repo names: ndslabs/images.git, ndslabs/ccd.git
- CCD:
- Catalog file - Declarative
- static service description
- composite dependencies for composites
- Config options (simple)
- Configure -
- Assign options and provision resources
- Deploy -
- generate K8s and run
- Catalog file - Declarative
Unresolved:
- Workflow and format for CCD spec files
- Detailed defn and workflow
- Catalog generation from catalogs in URL
- Simple aggregation of static data - yes?
- Configure time - options vs resources
- Options
- validatable
- May influence subordinates
- Other options - ex. (log(yes|no)->yes)->logfile(input(name))
- Resources - ex. (logvol(named)->yes)->vols.map(logvol(lookup(name)))
- Resources
- Need lookup in system
- volumes, etc.
- need consistent naming/identification scheme
- Need lookup in system
- Generating K8s
- Unknown, but could leverage other declarative->declarative transformation tools
- Options
- Catalog generation from catalogs in URL
Design Notes - 16/02/15:
- Goals
- Simplicity - Easy to understand and use for cluster admins, project admins, and tool/service developers
- Glean as much optional information as possible from build/images/K8s manifests
- Volumes, ports, scalability(replication controllers), etc. -
- Sensible and simple defaults, with expert override support for Project deployments
- Glean as much optional information as possible from build/images/K8s manifests
- Automation - Set the catalog references and run - updates/changes appear without intervention
- Extensible - Multiple catalogs - nds, other-public and private catalogs per-cluster, support experimental/dev ad-hoc use in shared and person dev environments
- Independent - Not tightly bound to NDS or docker.io, does not require administrative intervention for developers
- Trusted - support signing/verification as an option for service repos and individual services
- Workflow Support:
- Develop - create descriptions with source
- Publish - publish catalog service descriptions when publishing image
- Catalog to Cluster - Cluster admins add catalog refs to cluster, catalog automatically available
- Service Configuration - Project admin selects from cluster catalog, resolves service options in (CLI/GUI) to generate a deployment on cluster
- Service Deploy - Project admin deploys configured service in cluster run-time
- Manage - Track per-project deploys and feedback configuration to CLI/GUI for reconfig (scaling, data mgmt, etc.)
- Data Types and Objects
- Kubernetes Pod manifest, Service manifest, and Replication Controller Manifest
- Container images (by reference)
- Catalog-specific info and configuration data (to be specified)
- Configuration options
- Etcd catalog: Above information cached under /nds/service/catalog/<catalog-ref>/<service-name>
- Project Admin Input: The optional configuration information provided by the project admin on configure/deploy
- Implementation Possibilities
- Service and Configuration file locations:
- Service/config distributed inside the implementation container(s) in a specified path: /usr/local/etc/nds/...
- Service/config outside container, in parallel catalog server system (Juju model)
- Service/Config in related containers, using name-associations (<service>, <service>-ndscat)
- Service/Config in related containers with parallel service and config docker repos: ndslabs-service with ndslabs
- Service/Config In image tags via Docker, (LABEL in Dockerfile)
- Service/Config in git repositories
Discussion:
- Simple, docker model, single-image, spec/image not independent
- Assume immutable container - service spec's immutable
- Requires pulling containers to access catalog/service info
- startup overhead to pull everything NDS at cluster/catalog start
- Needs catalog-side pull/add for new/changed images
- Complex custom model - requires most development
- Service spec independent of image
- Requires moderate implementation
- catalog server and population process
- cluster-side catalog sync for image additions and updates
- Difficult independence for devs and 3rd parties - requires catalog server deployment
- Simpler with svc-spec independence and docker model
- Harnesses docker repos
- Needs docker naming scheme that is searchable via docker cli
- Catalog update - search/pull from repos and store - simple
- Complex, not entirely docker-model with svc/container independence
- Dual-repo version of #3
- Push to 2 repos involves parallel tagging and dual repo creds
- Prefer #3 for simplicity?
- Simple, docker model, svc/image not independent
- Similar to #1 without entering container
- Efficient if it's possible to pull only image meta without layers
- Can leverage other meta-data
- Image meta also contains definitive volumes and ports spec's which we need
- Simple, svc/image independent, may complicate developers
- Easy - parallel git repo for services
- Nice to keep service/configurator/K8s together - single repos
- Simple, docker model, single-image, spec/image not independent
Other Ideas:
- Use an active configurator object/container provided by developer (Juju model)
- Probably impractical and likely to be misused (shortcuts)