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 Kubernetes. 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: {} 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-container , sentinel-container ] 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?
Membership (Member. Of) direction is wrong for management (group): TOSCA Groups redis-master-pod implied “Member. Of” Relationship Kubernetes. Pod type: tosca. groups. Placement sources: [ master-container , implied “Member. Of” Relationship sentinel-container ] master-container sentinel-container Kubernetes. Container derived_from: Kubernetes. Container. .
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> capabilities: Container. App: attribute: response_time: properties: environment: <tosca: map of string > requirements: - host: • 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 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] derived_from: Kubernetes. Container. .
TOSCA Policy – Entities that compose Policy (Event, Condition, Action) model Policy Definition Event Type (new): <event_type_name>: derived_from: <parent_event_type> version: <version_number> description: <policy_description> 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) <policy_name>: type: <policy_type_name> description: <policy_description> properties: <property_definitions> # allowed targets for policy association targets: [ <list_of_valid_target_templates> ] * triggers: <filt <trigger_symbolic_name_1>: pro event: <event_type_name> # TODO: Allow a TOSCA node filter here # required node (resource) to monitor filter: node: <node_template_name> <node_type> cap # 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 <operation_name>: # (no lifecycle) # TBD: Do we care about validation of types? # If so, we should use a TOSCA Lifecycle type description: <optional description> inputs: <list of property assignments > implementation: <script> | <service_name> <trigger_symbolic_name_2>: . . . <trigger_symbolic_name_n>:
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 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” Target is a Kubernetes Pod of the tosca. groups. placement type 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 Describe NODE to attach an capability: Container alarm | alert | event to condition: utilization greater_than 80% action: # map to SENLIN: : ACTION: : RESIZE i. e. , Using the “node”, “req”, RESIZE_BEST_EFFORT: # logical operation name “cap” and “condition” keys inputs: # optional inputs parameters would expressed as a number: 1 descriptive “filter” Implementation: <script> | <service_name>. . . List optional input parms. here 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) TODO: Need a % data type for TOSCA Note: we combined the Senlin “Action” of SENLIN: ACTION: RESIZE with the strategy: BEST_EFFORT to have one name
Backup
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