|
|
| Line 1: |
Line 1: |
| − | Kubernetes Container Pod Config Resource
| |
| − | ----------------------------------------------------------
| |
| | | | |
| − | https://blueprints.launchpad.net/heat/+spec/k8s-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)
| |
| − |
| |
| − | Problem description
| |
| − | ===================
| |
| − |
| |
| − | Heat should support container deployemnt and their lifecycle management, the same way
| |
| − | it manages other openstack resources and software configurations.
| |
| − |
| |
| − | Proposed change
| |
| − | ===============
| |
| − |
| |
| − | 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 quering 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 createing, removing and updating the pods.
| |
| − |
| |
| − |
| |
| − | Alternatives
| |
| − | ------------
| |
| − | An alternate solution with software config/structured config has already been implemented.
| |
| − | However, this can't manage lifecycle operations for the pods.
| |
