1. Kubernetes Analysis: 2 types of containers
Approach:
Use reuse exiting TOSCA normative node, capability and relationship types where possible
Model Kubernetes types (for now), then model similar container managers like Swarm, etc. and look for common base types, properties that can be abstracted.
Kubernetes Analysis: 2 types of containers
“Dumb” (no HA, no Autoscale) =
Pod Template
“Smart” (HA, Scaling) =
ReplicationController Template
kind: “Pod”
(i.e. Type)
kind: “ReplicationController”
(i.e. Type)
id: redis-master
kind: Pod
apiVersion: v1beta1
desiredState:
manifest:
version: v1beta1
containers:
- name: master
image: kubernetes/redis:v1
cpu: 1000
ports:
- containerPort: 6379
volumeMounts:
- name: data
mountPath: /redis-master-data
env:
- key: MASTER
value: "true"
- name: sentinel
- containerPort: 26379
- key: SENTINEL
volumes:
source:
emptyDir: {}
id: redis
kind: ReplicationController
apiVersion: v1beta1
desiredState:
replicas: 1
replicaSelector:
name: redis
podTemplate:
manifest:
version: v1beta1
containers:
- name: redis
image: kubernetes/redis:v1
cpu: 1000
ports:
- containerPort: 6379
volumeMounts:
- name: data
mountPath: /redis-master-data
volumes:
source:
emptyDir: {}
labels:
labels:
name: redis
role: master
redis-sentinel: "true" 1 1

2. Kubernetes Analysis: Pod Modeling: TOSCA Type mapping
A Pod is an aggregate of Docker Container Requirements of 1..N homogenous Container (topologies)
“Redis-master” Template of Kubernetes “Pod” Type:
TOSCA Types for Kubernetes:
kind: “Pod”
(a Template of type “Pod”)
Kubernetes.Pod
tosca.groups.Placement
derived_from: tosca.groups.Placement
version: <version_number>
metadata: <tosca:map(string)>
description: <description>
properties: TBD
attributes: TBD
# Allow get_property() against targets
targets:
[ tosca.nodes.Container.App.Kubernetes ]
id: redis-master
kind: Pod
apiVersion: v1beta1
desiredState:
manifest:
version: v1beta1 (non-numeric)
containers:
- name: master (TOSCA template name)
image: kubernetes/redis:v1 (TOSCA Container.App; create artifact of type image.Docker)
cpu: (TOSCA Container capability; num_cpus, cpu_frequency)
ports: (TOSCA EndPoint capability)
- containerPort: 6379 (TOSCA Endpoint; port, ports)
volumeMounts: (TOSCA Attachment capability)
- name: data
mountPath: /redis-master-data (TOSCA AttachesTo Rel.; location)
env:
- key: MASTER
value: "true” # passed as Envirronment vars to instance
- name: sentinel
image: kubernetes/redis:v1
ports:
- containerPort: 26379
- key: SENTINEL
value: "true” # passed as Env. var.
volumes:
source:
emptyDir: {}
labels:
name: redis
role: master
redis-sentinel: "true"
Kubernetes.Container
tosca.nodes.Container.App
derived_from: tosca.nodes.Container.App
metadata: <tosca:map(string)>
version: <version_number>
description: <description>
properties:
environment: <tosca:map of string>
requirements:
- host:
# hosted on kubelets
type: Container.Runtime.Kubernetes
- ports:
capability: EndPoint
properties: ports, ports, etc.
- volumes:
capability: Attachment
relationship: AttachesTo
properties: location, device
occurrences: [0, UNBOUNDED]
There was some assumptions made that the “cpu” was related to CGROUPS or “Control Groups” within Linux… from Wikipedia…
One of the design goals of cgroups is to provide a unified interface to many different use cases, from controlling single processes (by using nice, for example) to whole operating system-level virtualization (as provided by OpenVZ, Linux-VServer or LXC, for example). Cgroups provides:
Resource limitation: groups can be set to not exceed a configured memory limit, which also includes the file system cache[6][7]
Prioritization: some groups may get a larger share of CPU utilization[8] or disk I/O throughput[9]
Accounting: measures how much resources certain systems use, which may be used, for example, for billing purposes[10]
Control: freezing the groups of processes, their checkpointing and restarting[10] 2 2

3. Kubernetes Analysis: Pod Modeling: TOSCA Template Mapping: Simple “Group Approach”:
Using the Types defined on the previous slide the TOSCA Topology Template looks like this for “redis-master”
TOSCA Topology for Kubernetes “:
“Redis-master” Template of Kubernetes “Pod” Type:
redis-master
Kubernetes.Pod
type: tosca.groups.Placement
version: 1.0
metadata:
name: redis
role: master
redis-sentinel: true
targets:
[ master, sentinel ]
kind: “Pod”
(a Template of type “Pod”)
implied “InvitesTo”
Relationship
implied “invitesTo”
Relationship
id: redis-master
kind: Pod
apiVersion: v1beta1
desiredState:
manifest:
version: v1beta1 (non-numeric)
containers:
- name: master
image: kubernetes/redis:v1
cpu: 1000
ports:
- containerPort: 6379
volumeMounts:
- name: data
mountPath: /redis-master-data
env:
- key: MASTER
value: "true” # passed as Envirronment vars to instance
- name: sentinel
- containerPort: 26379
- key: SENTINEL
value: "true” # passed as Env. var.
volumes:
source:
emptyDir: {}
labels:
name: redis
role: master
redis-sentinel: "true"
master
sentinel
Kubernetes.Container
Kubernetes.Container
derived_from: Kubernetes.Container
metadata: <tosca:map(string)>
version: <version_number>
description: <description>
artifacts: kubernetes/redis:v1
properties:
requirements:
- host:
num_cpus: 1000 ?
- port:
capability: EndPoint
port: 6379
- volume:
capability: Attachment
relationship: AttachesTo
properties: location, device
occurrences: [0, UNBOUNDED]
interfaces:
inputs:
MASTER: true
derived_from:
Kubernetes.Container
...
There was some assumptions made that the “cpu” was related to CGROUPS or “Control Groups” within Linux… from Wikipedia…
One of the design goals of cgroups is to provide a unified interface to many different use cases, from controlling single processes (by using nice, for example) to whole operating system-level virtualization (as provided by OpenVZ, Linux-VServer or LXC, for example). Cgroups provides:
Resource limitation: groups can be set to not exceed a configured memory limit, which also includes the file system cache[6][7]
Prioritization: some groups may get a larger share of CPU utilization[8] or disk I/O throughput[9]
Accounting: measures how much resources certain systems use, which may be used, for example, for billing purposes[10]
Control: freezing the groups of processes, their checkpointing and restarting[10]
Choice: or use Docker.Runtime type to allow use of template on Swarm, etc.?
Issue: location property lost as there is no “AttachesTo” relationship in the topology.
Create new Capability Type?
Issue: Are there more than 1 volumes / mount points allowed? 3 3

4. tosca.groups.Placement
BETTER: We do not need to define Kubernetes specific Types (reuse Docker types) :
Kubernetes Pod reuses “Docker” Container.App type which can now reference other Container.App types like Rocket (Rkt)
tosca.groups.Placement
tosca.groups.Root
derived_from: tosca.groups.Placement
version: <version_number>
metadata: <tosca:map(string)>
description: <description>
properties: TBD
attributes: TBD
# Allow get_property() against targets
targets:
[ Container.App.Docker,
Container.App.Rocket, ... ]
Policies:
Security,
Scaling,
Update,
etc.
“AppliesTo” group (members)
i.e., targets
Not using “BindsTo” as that implies it is coupled to an implementation
Container.App.Docker
tosca.nodes.Container.App
There is no need for a “Kubernetes” Runtime type, just use the real Container’s built-in runtime requirement
(don’t care to model or reference Kubelets)
Homogenous Pods/Containers for Kubernetes is still an issue, but
this is a current Kubernetes limitation (heterogenous is possible in future)
derived_from: tosca.nodes.Container.App
metadata: <tosca:map(string)>
version: <version_number>
description: <description>
properties:
environment: <tosca:map of string>
requirements:
- host:
capability: Container.Docker
type: Container.Runtime.Kubernetes
- ports:
capability: EndPoint
properties: ports, ports, etc.
- volumes:
capability: Attachment
relationship: AttachesTo
properties: location, device
occurrences: [0, UNBOUNDED]
There was some assumptions made that the “cpu” was related to CGROUPS or “Control Groups” within Linux… from Wikipedia…
One of the design goals of cgroups is to provide a unified interface to many different use cases, from controlling single processes (by using nice, for example) to whole operating system-level virtualization (as provided by OpenVZ, Linux-VServer or LXC, for example). Cgroups provides:
Resource limitation: groups can be set to not exceed a configured memory limit, which also includes the file system cache[6][7]
Prioritization: some groups may get a larger share of CPU utilization[8] or disk I/O throughput[9]
Accounting: measures how much resources certain systems use, which may be used, for example, for billing purposes[10]
Control: freezing the groups of processes, their checkpointing and restarting[10]
Container.App.Rocket
Container.APP
derived_from:
Kubernetes.Container
... 4 4

5. However: We do not want to “buy into” Docker file as a Capability Type:
Old Style: Docker capability type
that mirrors a Dockerfile:
Instead we want to use
Endpoints (for ports) and
Attachments (for volumes)
This allows Docker, Rocket and containers
to be modeled with other TOSCA nodes
(i.e., via ConnectsTo) and leverage underlying Compute attached BlockStorage
tosca.capabilities.Container.Docker:
derived_from: tosca.capabilities.Container
properties:
version:
type: list
required: false
entry_schema: version
publish_all:
type: boolean
default: false
publish_ports:
entry_schema: PortSpec
expose_ports:
volumes:
entry_schema: string
TBD: Need to show this
There was some assumptions made that the “cpu” was related to CGROUPS or “Control Groups” within Linux… from Wikipedia…
One of the design goals of cgroups is to provide a unified interface to many different use cases, from controlling single processes (by using nice, for example) to whole operating system-level virtualization (as provided by OpenVZ, Linux-VServer or LXC, for example). Cgroups provides:
Resource limitation: groups can be set to not exceed a configured memory limit, which also includes the file system cache[6][7]
Prioritization: some groups may get a larger share of CPU utilization[8] or disk I/O throughput[9]
Accounting: measures how much resources certain systems use, which may be used, for example, for billing purposes[10]
Control: freezing the groups of processes, their checkpointing and restarting[10] 5 5

6. TOSCA Policy Type – Based upon Event, Condition, Action model
Policy Definition
<policy_type_name>:
derived_from: <parent_policy_type_name>
version: <version_number>
description: <policy_description>
properties:
<property_definitions>
targets: [ <list_of_valid_target_types> ]
events:
<event_name_1>:
node: <node_type>
# Compute -> Nova
capability: <capability_type>
# Container
attribute: <attribute_name>
# utilization -> cpu
...
strategies:
# set of strategy names and
# strategy-specific properties
<list_of_strategy_definitions>
# TODO: Perhaps define policy lifecycle
<policy_name>:
type: <policy_type_name>
description: <policy_description>
properties:
<property_definitions>
targets: [ <list_of_valid_target_templates> ] * see below
events:
<event_name_1>:
node: <node_template_name>
capability: <capability_name>
constraints:
- <attribute_name> <constraint_clause> <value>
... e.g., cpu_utilization > 80%;
cpu_utilization = RED, YELLOW, GREEN
# TODO: Perhaps make this a policy lifecycle def.
actions:
- <action_name_1>:
type: strategy
value: <valid_strategy_name>
properties: <list_of_property_values>
# TODO: See if we can avoid imperative scripts
- <action_name_2>:
type: operation (senlin = custom action)
value: <implementation_artifact>
Event(s)
based upon resource in TOSCA topology
or a Capability of that resource.
Condition(s)
described as a constraint of an attribute of the resource (or capability of the resource)
Action(s)
A strategy that matches the policy type
An scripts
Notifications
* node, relationship templates (or groups) 6 6

7. Possible TOSCA Metamodel and Normative Type additions
NodeType, Rel. Types
tosca.capabilities.Container
<node_type_name>:
metadata:
description: >
allow tags / labels for search of instance model
type: map of string
derived_from: <parent_node_type_name>
version: <version_number>
description: <node_type_description>
properties:
<property_definitions>
attributes:
<attribute_definitions>
requirements:
- <requirement_definitions>
capabilities:
<capability_definitions>
interfaces:
<interface_definitions>
artifacts:
<artifact_definitions>
tosca.capabilities.Container:
derived_from: tosca.capabilities.Root
properties:
num_cpus:
type: integer
required: false
constraints:
- greater_or_equal: 1
cpu_frequency:
type: scalar-unit.frequency
disk_size:
type: scalar-unit.size
mem_size:
attributes:
cpu_utilization:
description: referenced by scaling policies
type: float (percent) |
integer (percent) |
scalar-percent ?
required: no ?
- in_range: [ 0, 100 ] 7 7

8. Backup

9. Container.App.Kubernetes Container.App.Kubernetes
Software Component 1: SW Component with VM image deployment artifact
master
redis_master
Container.App.Kubernetes
Kubernetes.Pod
Properties
TBD
Attributes
Properties
TBD
Attributes
Artifacts:
kubernetes/redis:v1
type: image.Docker
Requirements
Container.Runtime.Docker
Properties
TBD
Lifecycle.Standard
HostedOn
create …
Capabilities
Container.Runtime.Docker
sentinel
HostedOn
Container.App.Kubernetes
Properties
TBD
Attributes
Artifacts:
kubernetes/redis:v1
type: image.Docker
Requirements
Container.Runtime.Docker
Properties
TBD
Lifecycle.Standard
create …

10. Container.Application.Docker Container.Application.Docker
Docker Hub
(Repository)
‘mysql’
Docker Image
‘wordpress’
Docker Image
wordpress_container
mysql_container
Container.Application.Docker
Container.Application.Docker
artifacts:
- my_image:
type: Image.Docker
URI: wordpress
repository: docker_hub
artifacts:
- my_image:
type: Image.Docker
URI: mysql
repository: docker_hub
Requirements
Requirements
Container
Container
Runtime.Docker
Runtime.Docker
Docker.LinksTo
Docker.Link
Capabilities
Docker.Link 10 10