Approach Use reuse exiting TOSCA normative node capability
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) = Replication. Controller Template kind: “Pod” (i. e. Type) kind: “Replication. Controller” (i. e. Type) id: redis-master labels: kind: Pod name: redis api. Version: v 1 beta 1 role: master desired. State: redis-sentinel: "true" manifest: version: v 1 beta 1 id: redis-master containers: - name: master image: kubernetes/redis: v 1 cpu: 1000 ports: - container. Port: 6379 volume. Mounts: - name: data mount. Path: /redis-master-data env: - key: MASTER value: "true" - name: sentinel image: kubernetes/redis: v 1 ports: - container. Port: 26379 env: - key: SENTINEL value: "true" volumes: - name: data source: empty. Dir: {} id: redis kind: Replication. Controller api. Version: v 1 beta 1 desired. State: replicas: 1 replica. Selector: name: redis pod. Template: desired. State: manifest: version: v 1 beta 1 id: redis containers: - name: redis image: kubernetes/redis: v 1 cpu: 1000 ports: - container. Port: 6379 volume. Mounts: - name: data mount. Path: /redis-master-data volumes: - name: data source: empty. Dir: {} labels: name: redis
• 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: kind: “Pod” (a Template of type “Pod”) id: redis-master kind: Pod labels: api. Version: v 1 beta 1 name: redis desired. State: role: master manifest: redis-sentinel: "true" version: v 1 beta 1 (non-numeric) id: redis-master containers: ------------------------------------------------- name: master (TOSCA template name) image: kubernetes/redis: v 1 (TOSCA Container. App; create artifact of type image. Docker) cpu: 1000 (TOSCA Container capability; num_cpus, cpu_frequency) ports: (TOSCA End. Point capability) - container. Port: 6379 (TOSCA Endpoint; port, ports) volume. Mounts: (TOSCA Attachment capability) - name: data mount. Path: /redis-master-data (TOSCA Attaches. To Rel. ; location) env: - key: MASTER value: "true” # passed as Envirronment vars to instance ------------------------------------------------ name: sentinel image: kubernetes/redis: v 1 ports: - container. Port: 26379 env: - key: SENTINEL value: "true” # passed as Env. var. ------------------------------------------------volumes: - name: data source: empty. Dir: {} TOSCA Types for Kubernetes: 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: [ tosca. nodes. Container. App. Kubernetes ] 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: End. Point properties: ports, etc. - volumes: capability: Attachment relationship: Attaches. To properties: location, device occurrences: [0, UNBOUNDED]
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-pod kind: “Pod” (a Template of type “Pod”) id: redis-master kind: Pod labels: api. Version: v 1 beta 1 name: redis desired. State: role: master manifest: redis-sentinel: "true" version: v 1 beta 1 (non-numeric) id: redis-master containers: ------------------------------------------------- name: master image: kubernetes/redis: v 1 cpu: 1000 ports: - container. Port: 6379 volume. Mounts: - name: data mount. Path: /redis-master-data env: - key: MASTER value: "true” # passed as Envirronment vars to instance ------------------------------------------------ name: sentinel image: kubernetes/redis: v 1 ports: - container. Port: 26379 env: - key: SENTINEL value: "true” # passed as Env. var. ------------------------------------------------volumes: - name: data source: empty. Dir: {} Kubernetes. Pod type: tosca. groups. Placement implied “invites. To” Relationship version: 1. 0 metadata : implied “Invites. To” Relationship name: redis role: master redis-sentinel: true targets: [ master , sentinel ] master-container Kubernetes. Container derived_from: Kubernetes. Container metadata: <tosca: map(string)> version: <version_number> description: <description> artifacts: kubernetes/redis: v 1 properties: requirements: - host: properties: num_cpus: 1000 ? - port: capability : End. Point properties: port: 6379 - volume: capability: Attachment relationship: Attaches. To properties: location, device occurrences: [0, UNBOUNDED] interfaces: inputs: MASTER: true sentinel-container Kubernetes. Container derived_from: Kubernetes. Container. . Choice: or use Docker. Runtime type to allow use of template on Swarm, etc. ? Issue: location property lost as there is no “Attaches. To” relationship in the topology. Create new Capability Type? Issue: Are there more than 1 volumes / mount points allowed?
However: We do not want to “buy into” Docker file as a Capability Type: Old Style: Docker capability type that mirrors a Dockerfile: tosca. capabilities. Container. Docker: derived_from: tosca. capabilities. Container properties: version: type: list required: false entry_schema: version publish_all: type: boolean default: false required: false publish_ports: type: list entry_schema: Port. Spec required: false expose_ports: type: list entry_schema: Port. Spec required: false volumes: type: list entry_schema: string required: false 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 Connects. To) and leverage underlying Compute attached Block. Storage TBD: Need to show this
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: [ Container. App. Docker, Container. App. Rocket, . . . ] Policies: Security, Scaling, Update, etc. • • “Applies. To” group (members) • i. e. , targets • Not using “Binds. To” as that implies it is coupled to an implementation Container. App. Docker 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: capability: Container. Docker type: Container. Runtime. Kubernetes - ports: capability: End. Point properties: ports, etc. - volumes: capability: Attachment relationship: Attaches. To 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) Container. App. Rocket Container. APP derived_from: Kubernetes. Container. .
TOSCA Policy – Entities that compose Policy (Event, Condition, Action) model Event Type (new): Policy Definition <event_type_name>: derived_from: <parent_event_type> version: <version_number> description: <policy_description> <policy_name>: type: <policy_type_name> description: <policy_description> properties: <property_definitions> # allowed targets for policy association targets: [ <list_of_valid_target_templates> ] * triggers: <trigger_symbolic_name_1>: event: <event_type_name> # TODO: Allow a TOSCA node filter here node_filter: # required node (resource) to monitor node: <node_template_name> # Used to reference another node related to # the node above via a relationship requirement: <requirement_name> # optional capability within node to monitor capability: <capability_name> # required clause that compares an attribute # with the identified node or capability # for some condition: <constraint_clause> action: # a) Define new TOSCA normative strategies # per-policy type and use here OR # b) allow domain-specific names <strategy_name>: # TBD: Do we care about validation of types? # If so, we should use a TOSCA Lifecycle type inputs: <list of property assignments > <trigger_symbolic_name_2>: . . . <trigger_symbolic_name_n>: 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)
Possible TOSCA Metamodel and Normative Type additions Node. Type, 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: derived_from: tosca. capabilities. Root properties: num_cpus: type: integer required: false constraints: - greater_or_equal: 1 cpu_frequency: type: scalar-unit. frequency required: false disk_size: type: scalar-unit. size required: false mem_size: type: scalar-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 ]
TOSCA Policy Mapping – Example Senlin “scaling_out_policy_ceilometer. yaml” using the Kubernetes “redis” example from earlier slides (and its pod, container): TOSCA Policy Definition Target is a Kubernetes Pod of the tosca. groups. placement type my_scaling_policy: type: tosca. policies. scaling # for now any TOSCA node Symbolic name targets: [redis-master-pod ] for the triggers: (could be used to resize: reference an externalized event: tosca. events. resource. utilization version; however, this node_filter: would violate a node: master-container Policy’s integrity as a requirement: host capability: Container “Security document” condition: utilization > 80% action: RESIZE_BEST_EFFORT: inputs: TODO: number: 1. . . Look to use the TOSCA normative event type (name) that would map to domain-specific names (e. g. , Open. Stack Ceilometer) 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) node_template grammar here i. e. , The “node”, “req”, “cap” and “condition” keys would expressed as a node_filter List your input parms. here Note: we combined the Senlin “Action” of SENLIN: ACTION: RESIZE with the strategy: BEST_EFFORT to have one name TODO: Need a % data type for TOSCA
Backup
TOSCA Policy Type – Based upon Event, Condition, Action model Policy Type Event(s) based upon resource in TOSCA topology or a Capability of that resource. 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: # requirement-like? <event_name_1>: node: <node_type> # Compute -> Nova capability: <capability_type> # Container attribute: <attribute_name> # cpu_utilization -> cpu. . . strategies: # set of strategy names and # strategy-specific properties <list_of_strategy_definitions> <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> triggers: # expression of the Condition # e. g. , utilization_percent > 80% filter: <attribute_name> <constraint_clause> <value> condition: action: <action_name_1> # e. g. , utilization_level: RED filter: <attribute_name> <constraint_clause> <value> action: <action_name_2> # TODO: Perhaps make this a policy lifecycle def. actions: - <action_name_1>: 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> Old proposal # TODO: Perhaps define policy lifecycle Condition(s) described as a constraint of an attribute of aresource (or capability of the resource) Action(s) 1) A strategy that matches the policy type 2) An scripts 3) Notifications * node, relationship templates (or groups)
Software Component 1: SW Component with VM image deployment artifact master Container. App. Kubernetes redis_master Properties • TBD Attributes • TBD Kubernetes. Pod Properties • TBD Attributes • TBD Artifacts: • kubernetes/redis: v 1 • type: image. Docker Requirements Container. Runtime. Docker Properties • TBD Lifecycle. Standard Hosted. On create … Capabilities Container. Runtime. Docker sentinel Hosted. On Container. App. Kubernetes Properties • TBD Attributes • TBD Requirements Artifacts: • kubernetes/redis: v 1 • type: image. Docker
‘wordpress’ Docker Image Docker Hub (Repository) wordpress_container ‘mysql’ Docker Image mysql_container Container. Application. Docker artifacts: - my_image: type: Image. Docker URI: wordpress repository: docker_hub - my_image: type: Image. Docker URI: mysql repository: docker_hub Requirements Container Runtime. Docker. Links. To Capabilities Docker. Link
- Slides: 12