Kubernetes Container Pod Config Resource
Containers are becoming popular and docker has become an important part of how new services are build and deployed with container technology.
Kubernetes(k8s) is an open source system for managing containerized applications across multiple hosts, providing basic mechanisms for deployment, maintenance, and scaling of applications.
Kubelet, a k8s component, is a container agent that runs on nodes and works with container manifests. A container manifest is a YAML configuration that describes a pod. Kubelet agent running on each node takes a manifests (describing multiple pods) that can be provided in various (file/http url/etcd) mechanisms and ensures that the containers described in those manifests are started and continue running.
Heat can support container deployments and their lifecycle management by leveraging the Kubelet container agent.
A pod models an application-specific "logical host"in a containerized environment. It may contain one or more containers which are relatively tightly coupled. Pods correspond to colocated groups of [Docker containers](http://docker.io) with shared volumes, as supported by [Google Cloud Platform's container-vm images] (https://developers.google.com/compute/docs/containers)
Heat should support container deployemnt and their lifecycle management, the same way it manages other openstack resources and software configurations.
To solve this problem following changes are proposed:
a. Implement a k8s pod configuration resource, that describes a container manifest. This can be extended in the future to include other k8s models like 'services' and 'replicationContollers'.Sets of pods may created, maintained, and scaled using 'replicationControllers' and 'services' create load-balanced targets for sets of pods.
b. Implement a k8s pod deployment resource, that associates a pod configuration with an instance.
c. Implement a hook that deploys/updates a pod config for Kubelet and updates its status by querying it from k8s and signal heat.
Creation is currently not idempotent. There is plan to add a modification token to each resource.
Resource configuration that can then be used by Kubelet in instance agent to manage the containers in the spawned instance.
The container maanifest can be persisted in a. A in instance configuration file referred by Kubelet b. Signed heat url c. Swift temp url
We can't possibly use the b,c as they are temporary in nature and kubelet config requires the config to exist for it's lifetime.
d. All lifecycle operations on the resource would change this configuration and Kubelet agent would reflect that change by creating, removing and updating the pods.
An alternate solution with sofware config/structured config has already been implemented. However, this can't manage lifecycle operations for the pods.