1. kind: “Pod” (i.e. Type) kind: “Pod” (i.e. Type) Kubernetes Analysis: 2 types of containers “Dumb” (no HA, no Autoscale) = Pod Template kind: “ReplicationController” (i.e. Type) kind: “ReplicationController” (i.e. Type) id: redis kind: ReplicationController apiVersion: v1beta1 desiredState: replicas: 1 replicaSelector: name: redis podTemplate: desiredState: manifest: version: v1beta1 id: redis containers: - name: redis image: kubernetes/redis:v1 cpu: 1000 ports: - containerPort: 6379 volumeMounts: - name: data mountPath: /redis-master-data volumes: - name: data source: emptyDir: {} labels: name: redis id: redis-master kind: Pod apiVersion: v1beta1 desiredState: manifest: version: v1beta1 id: redis-master 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 image: kubernetes/redis:v1 ports: - containerPort: 26379 env: - key: SENTINEL value: "true" volumes: - name: data source: emptyDir: {} labels: name: redis role: master redis-sentinel: "true" 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. “Smart” (HA, Scaling) = ReplicationController Template

2. Kubernetes.Pod tosca.groups.Placement derived_from: tosca.groups.Placement version: metadata: description: properties: TBD attributes: TBD # Allow get_property() against targets targets: [ tosca.nodes.Container.App.Kubernetes ] kind: “Pod” (a Template of type “Pod”) kind: “Pod” (a Template of type “Pod”) id: redis-master kind: Pod apiVersion: v1beta1 desiredState: manifest: version: v1beta1 (non-numeric) id: redis-master containers: -------------------------------------------------------------------------------------------------- - name: master (TOSCA template name) image: kubernetes/redis:v1 (TOSCA Container.App; create artifact of type image.Docker) cpu: 1000 (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 env: - key: SENTINEL value: "true” # passed as Env. var. ------------------------------------------------------------------------------------------------ volumes: - name: data source: emptyDir: {} labels: name: redis role: master redis-sentinel: "true" Kubernetes Analysis: Pod Modeling: TOSCA Type mapping A Pod is an aggregate of Docker Container Requirements of 1..N homogenous Container (topologies) TOSCA Types for Kubernetes: “Redis-master” Template of Kubernetes “Pod” Type: Kubernetes.Container tosca.nodes.Container.App derived_from: tosca.nodes.Container.App metadata: version: description: properties: environment: 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]

3. redis-master-pod Kubernetes.Pod type: tosca.groups.Placement version: 1.0 metadata : name: redis role: master redis-sentinel: true targets: [ master-container, sentinel-container ] 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: master-container Kubernetes.Container derived_from: Kubernetes.Container metadata: version: description: artifacts: kubernetes/redis:v1 properties: requirements: - host: properties: num_cpus: 1000 ? - port: capability: EndPoint properties: port : 6379 - volume: capability: Attachment relationship: AttachesTo properties: location, device occurrences: [0, UNBOUNDED] interfaces: inputs: MASTER: true kind: “Pod” (a Template of type “Pod”) kind: “Pod” (a Template of type “Pod”) id: redis-master kind: Pod apiVersion: v1beta1 desiredState: manifest: version: v1beta1 (non-numeric) id: redis-master 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 image: kubernetes/redis:v1 ports: - containerPort: 26379 env: - key: SENTINEL value: "true” # passed as Env. var. ------------------------------------------------------------------------------------------------ volumes: - name: data source: emptyDir: {} labels: name: redis role: master redis-sentinel: "true" sentinel-container Kubernetes.Container implied “InvitesTo” Relationship implied “InvitesTo” Relationship Issue: location property lost as there is no “AttachesTo” relationship in the topology. Create new Capability Type? derived_from: Kubernetes.Container... Issue: Are there more than 1 volumes / mount points allowed? Choice: or use Docker.Runtime type to allow use of template on Swarm, etc.?

4. redis-master-pod Kubernetes.Pod type: tosca.groups.Placement sources: [ master-container, sentinel-container ] Membership (MemberOf) direction is wrong for management (group): TOSCA Groups master-container Kubernetes.Container sentinel-container Kubernetes.Container implied “ MemberOf ” Relationship implied “ MemberOf ” Relationship derived_from: Kubernetes.Container...

5. tosca.capabilities.Container.Docker: derived_from: tosca.capabilities.Containertosca.capabilities.Container properties: version: type: list required: false entry_schema: versionversion publish_all: type: booleanboolean default: false required: false publish_ports: type: list entry_schema: PortSpecPortSpec required: false expose_ports: type: list entry_schema: PortSpecPortSpec required: false volumes: type: list entry_schema: stringstring required: false 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 TBD: Need to show this

6. tosca.groups.Placement tosca.groups.Root derived_from: tosca.groups.Placement version: metadata: description: properties: TBD attributes: TBD # Allow get_property() against targets targets: [ Container.App.Docker, Container.App.Rocket,... ] Kubernetes Pod reuses “Docker” Container.App type which can now reference other Container.App types like Rocket (Rkt) Container.App.Docker tosca.nodes.Container.App derived_from: tosca.nodes.Container.App metadata: version: description: capabilities: Container.App: attribute: response_time: properties: environment: 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 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 (heterogonous is possible in future) Policies: Security, Scaling, Update, etc. “AppliesTo” group (members) i.e., targets Not using “BindsTo” as that implies it is coupled to an implementation BETTER: We do not need to define Kubernetes specific Types (reuse Docker types) : Container.App.Rocket Container.APP derived_from: Kubernetes.Container...

7. Event Type (new): :event_type_name derived_from: version: version_number description: policy_description Policy Definition :policy_name type: policy_type_name description: policy_description properties: property_definitions # allowed targets for policy association targets: [ ] * triggers: : event: # TODO: Allow a TOSCA node filter here # required node (resource) to monitor filter: node: # Used to reference another node related to # the node above via a relationship requirement: # optional capability within node to monitor capability: # required clause that compares an attribute # with the identified node or capability # for some condition condition: action: # a) Define new TOSCA normative strategies # per-policy type and use here OR # b) allow domain-specific names : # (no lifecycle) # TBD: Do we care about validation of types? # If so, we should use a TOSCA Lifecycle type description: inputs: property assignments implementation: | :... : Event name of a normative TOSCA Event Type Condition described as a constraint of an attribute of the node (or capability) identified) by the filter. Action Describes either: a)a well-known strategy b)an implementation artifact (e.g., scripts, service) to invoke with optional property definitions as inputs (to either choice) TOSCA Policy – Entities that compose Policy (Event, Condition, Action) model : properties: - -... - capabilities: - : properties: - -... - -... - : properties: - -... -

8. Possible TOSCA Metamodel and Normative Type additions NodeType, Rel. Types :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 tosca.capabilities.Container: derived_from: tosca.capabilities.Roottosca.capabilities.Root properties: num_cpus: type: integer required: false constraints: - greater_or_equal: 1 cpu_frequency: type: scalar-unit.frequencyscalar-unit.frequency required: false disk_size: type: scalar-unit.sizescalar-unit.size required: false mem_size: type: scalar-unit.sizescalar-unit.size required: false attributes: utilization: description: referenced by scaling policies type: # float (percent) | integer (percent) | # scalar-percent ? required: no ? constraints: - in_range: [ 0, 100 ]

9. TOSCA Policy Definition my_scaling_policy: type: tosca.policies.scaling properties: # normative TOSCA properties for scaling min_instances: 1 max_instances: 10 default_instances: 3 increment: 1 # target the policy at the “Pod” targets: [ redis-master-pod ] triggers: resize_compute: # symbolic name event: tosca.events.resource.utilization filter: node: master-container requirement: host capability: Container condition: utilization greater_than 80% action: # map to SENLIN::ACTION::RESIZE RESIZE_BEST_EFFORT: # logical operation name inputs: # optional inputs parameters number: 1 Implementation: |... TOSCA Policy Mapping – Example Senlin “scaling_out_policy_ceilometer.yaml”scaling_out_policy_ceilometer.yaml Target is a Kubernetes Pod of the tosca.groups.placement type TODO: Need a % data type for TOSCA TODO: Need a % data type for TOSCA using the Kubernetes “redis” example from earlier slides (and its pod, container): TOSCA normative event type (name) that would map to domain-specific names (e.g., OpenStack Ceilometer) TOSCA normative event type (name) that would map to domain-specific names (e.g., OpenStack Ceilometer) Symbolic name for the trigger (could be used to reference an externalized version; however, this would violate a Policy’s integrity as a “Security document” Find the attribute via the topology: a)Navigate to node (directly or via the requirement name) and optionally the Capability name b)The condition to map & register with the target monitoring service (e.g., Ceilometer) Describe NODE to attach an alarm | alert | event to i.e., Using the “node”, “req”, “cap” and “condition” keys would expressed as a descriptive “filter” Describe NODE to attach an alarm | alert | event to i.e., Using the “node”, “req”, “cap” and “condition” keys would expressed as a descriptive “filter” Note: we combined the Senlin “Action” of SENLIN:ACTION:RESIZE with the strategy: BEST_EFFORT to have one name Note: we combined the Senlin “Action” of SENLIN:ACTION:RESIZE with the strategy: BEST_EFFORT to have one name List optional input parms. here

10. Backup

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

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