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 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 sentinel 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 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?
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 Policies: Security, Scaling, Update, etc. 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, . . . ] • • “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 (heterogenous is possible in future) Container. App. Rocket Container. APP 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
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: <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 Condition(s) described as a constraint of an attribute of the resource (or capability of the resource) Action(s) 1) A strategy that matches the policy type 2) An scripts 3) Notifications <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> * node, relationship templates (or groups)
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: cpu_utilization: description: referenced by scaling policies type: float (percent) | integer (percent) | scalar-percent ? required: no ? constraints: - in_range: [ 0, 100 ]
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: 10