Router Manager

KubeEdge supports routing management with the help of Kubernetes CRDs and a router module. Users can deliver their custom messages between cloud and edge by mqtt broker.

Usage scenarios

  • used for user’s control data delivery;
  • not suitable for large data delivery;
  • the data size of delivery at one time is limited to 12MB.

Use Cases

  • user can deliver custom message from cloud to edge by calling api in cloudcore. And it will deliver the message to mqttbroker on edge finally.

    1. user creates a rule which defines the message’s source and target info.
    2. user’s app in cloud calls an api of cloudcore to deliver custom message; the message is delivered to edge, and published to mqttbroker with a topic.
    3. user’s app in edge subscribes the message with the same topic in step 2.
  • user can deliver custom message from edge to cloud by publishing message to mqttbroker. And it will deliver the message to rest api in cloud finally.

    1. user creates a rule which defines the message’s source and target info.
    2. user’s app in edge published message to mqttbroker with a topic.
    3. user’s app in cloud got the message in step 2.
  • user can deliver custom message from cloud to edge by calling api in cloudcore. And it will call rest api on edgenode finally. And get the result.

    1. user creates a rule which defines the message’s source and target info.
    2. user’s app in cloud calls an api of cloudcore to deliver custom message; cloudcore delivered the message to edgecore. Edgecore will call edge’s rest api.
    3. user’s app in edge got the result of api call in step 2.

Rule And ruleendpoint Model

RuleEndpoint and Rule definition

  • A ruleEndpoint defines where messages come from, or where messages go to. It contains 3 types: rest, eventbus, servicebus.

    1. rest: a rest endpoint in the cloud. It is a source ruleEndpoint to send rest requests to the edge. Or a target ruleEndpoint to receive message from edge.

    2. eventbus: It is a source ruleEndpoint to send data to the cloud, or a target ruleEndpoint to receive messages from the cloud.

    3. servicebus: a rest api on edge node. It is a target ruleEndpoint to receive messages delivered from cloud.

  • Rule defines how messages were delivered from source ruleendpoint to target ruleendpoint. It contains 3 rule types.

    1. rest->eventbus: users’ app calls rest api in cloud to send messages, finally messages were sent to mqttbroker in edge.
    2. eventbus->rest: users publish messages to mqttbroker in edge, finally messages were sent to rest api in cloud.
    3. rest->servicebus: users’ app calls rest api in cloud to send messages, finally messages were sent to user’s app in edge.

RuleEndpoint and Rule CRD design

  • RuleEndpoint

    1. apiVersion: apiextensions.k8s.io/v1
    2. kind: CustomResourceDefinition
    3. metadata:
    4. name: ruleendpoints.rules.kubeedge.io
    5. spec:
    6. group: rules.kubeedge.io
    7. versions:
    8. - name: v1
    9. served: true
    10. storage: true
    11. schema:
    12. openAPIV3Schema:
    13. type: object
    14. properties:
    15. spec:
    16. type: object
    17. properties:
    18. ruleEndpointType:
    19. description: |
    20. ruleEndpointType is a string value representing rule-endpoint type. its value is
    21. one of rest/eventbus/servicebus.
    22. type: string
    23. properties:
    24. description: |
    25. properties is not required except for servicebus rule-endpoint type. It is a map
    26. value representing rule-endpoint properties.when ruleEndpointType is servicebus,
    27. its value is {"service_port":"8080"}.
    28. type: object
    29. additionalProperties:
    30. type: string
    31. required:
    32. - ruleEndpointType
    33. scope: Namespaced
    34. names:
    35. plural: ruleendpoints
    36. singular: ruleendpoint
    37. kind: RuleEndpoint
    38. shortNames:
    39. - re
  • Rule

    1. apiVersion: apiextensions.k8s.io/v1
    2. kind: CustomResourceDefinition
    3. metadata:
    4. name: rules.rules.kubeedge.io
    5. spec:
    6. group: rules.kubeedge.io
    7. versions:
    8. - name: v1
    9. served: true
    10. storage: true
    11. schema:
    12. openAPIV3Schema:
    13. type: object
    14. properties:
    15. spec:
    16. type: object
    17. properties:
    18. source:
    19. description: |
    20. source is a string value representing where the messages come from. Its
    21. value is the same with rule-endpoint name. For example, my-rest or my-eventbus.
    22. type: string
    23. sourceResource:
    24. description: |
    25. sourceResource is a map representing the resource info of source. For rest
    26. rule-endpoint type its value is {"path":"/a/b"}. For eventbus rule-endpoint type its
    27. value is {"topic":"<user define string>","node_name":"xxxx"}
    28. type: object
    29. additionalProperties:
    30. type: string
    31. target:
    32. description: |
    33. target is a string value representing where the messages go to. its value is
    34. the same with rule-endpoint name. For example, my-eventbus or my-rest or my-servicebus.
    35. type: string
    36. targetResource:
    37. description: |
    38. targetResource is a map representing the resource info of target. For rest
    39. rule-endpoint type its value is {"resource":"http://a.com"}. For eventbus rule-endpoint
    40. type its value is {"topic":"/xxxx"}. For servicebus rule-endpoint type its value is
    41. {"path":"/request_path"}.
    42. type: object
    43. additionalProperties:
    44. type: string
    45. required:
    46. - source
    47. - sourceResource
    48. - target
    49. - targetResource
    50. status:
    51. type: object
    52. properties:
    53. successMessages:
    54. type: integer
    55. failMessages:
    56. type: integer
    57. errors:
    58. items:
    59. type: string
    60. type: array
    61. scope: Namespaced
    62. names:
    63. plural: rules
    64. singular: rule
    65. kind: Rule

how to deliver custom messages

  1. cloud to edge : rest->eventbus

1.1 create rest and eventbus type ruleEndpoint if they don’t exist. Exec command:

kubectl create -f create-ruleEndpoint-rest.yaml

kubectl create -f create-ruleEndpoint-eventbus.yaml

create-ruleEndpoint-rest.yaml’s contents are as follows:

  1. apiVersion: rules.kubeedge.io/v1
  2. kind: RuleEndpoint
  3. metadata:
  4. name: my-rest
  5. labels:
  6. description: test
  7. spec:
  8. ruleEndpointType: "rest"
  9. properties: {}

create-ruleEndpoint-eventbus.yaml’s contents are as follows:

  1. apiVersion: rules.kubeedge.io/v1
  2. kind: RuleEndpoint
  3. metadata:
  4. name: my-eventbus
  5. labels:
  6. description: test
  7. spec:
  8. ruleEndpointType: "eventbus"
  9. properties: {}

1.2 create rule. Exec command:

kubectl create -f create-rule-rest-eventbus.yaml

create-rule-rest-eventbus.yaml’s contents are as follows:

  1. apiVersion: rules.kubeedge.io/v1
  2. kind: Rule
  3. metadata:
  4. name: my-rule
  5. labels:
  6. description: test
  7. spec:
  8. source: "my-rest"
  9. sourceResource: {"path":"/a"}
  10. target: "my-eventbus"
  11. targetResource: {"topic":"test"}

1.3 call rest api in the cloud to send messages to edge.

The rest api in the cloud can be called to send messages to eventbus on an edge node based on the node name and sourceResource.

  • Method: POST
  • URL: http://{rest\_endpoint}/{node\_name}/{namespace}/{path}, {rest_endpoint} is router’s endpoint, {node_name} is name of edgenode, {namespace} is the namespace of rule, {path}’s prefix is source ruleEndpoint’s sourceResource.
  • Body: {user_message}, {user_message} is user’s message

For example: - Method: POST - URL: http://{rest\_endpoint}/{node\_name}/default/a - Body: {“message”:“123”}

1.4 User’s app subscribes custom topics from mqtt-broker in edge to receive messages from the cloud.

  • Topic: {topic}, {topic} is target ruleEndpoint’s targetResource.
  • Message: {user_message}

For example: - subscribe Topic: ‘test’, exec command with mosquitto: mosquitto_sub -t 'test' -d - Get Message: {“message”:“123”}

  1. edge to cloud: eventbus->rest:

2.1 create rest type and eventbus type ruleEndpoint if they don’t exist. Exec command:

kubectl create -f create-ruleEndpoint-rest.yaml

kubectl create -f create-ruleEndpoint-eventbus.yaml

create-ruleEndpoint-rest.yaml’s contents are as follows:

  1. apiVersion: rules.kubeedge.io/v1
  2. kind: RuleEndpoint
  3. metadata:
  4. name: my-rest
  5. labels:
  6. description: test
  7. spec:
  8. ruleEndpointType: "rest"
  9. properties: {}

create-ruleEndpoint-eventbus.yaml’s contents are as follows:

  1. apiVersion: rules.kubeedge.io/v1
  2. kind: RuleEndpoint
  3. metadata:
  4. name: my-eventbus
  5. labels:
  6. description: test
  7. spec:
  8. ruleEndpointType: "eventbus"
  9. properties: {}

2.2 create rule. Exec command:

kubectl create -f create-rule-eventbus-rest.yaml

create-rule-eventbus-rest.yaml’s contents are as follows:

  1. apiVersion: rules.kubeedge.io/v1
  2. kind: Rule
  3. metadata:
  4. name: my-rule-eventbus-rest
  5. labels:
  6. description: test
  7. spec:
  8. source: "my-eventbus"
  9. sourceResource: {"topic": "test","node_name": "xxx"}
  10. target: "my-rest"
  11. targetResource: {"resource":"http://a.com"}

2.3 User’s app in edge publishes messages with custom topic to MQTT broker on edge node. - Topic: {namespace}/{topic} - Message: {user_api_body}

for example: - publish data with mosquitto, exec command:

mosquitto_pub -t 'default/test' -d -m '{"edgemsg":"msgtocloud"}'

2.4 Kubeedge delivers messages to user api address in cloud.

For example: user’s app in cloud gets the data {“edgemsg”:“msgtocloud”}

  1. cloud to edge : rest->servicebus

3.1 create rest and servicebus type ruleEndpoint if they don’t exist. Exec command:

kubectl create -f create-ruleEndpoint-rest.yaml

kubectl create -f create-ruleEndpoint-servicebus.yaml

create-ruleEndpoint-rest.yaml’s contents are as follows:

  1. apiVersion: rules.kubeedge.io/v1
  2. kind: RuleEndpoint
  3. metadata:
  4. name: my-rest
  5. labels:
  6. description: test
  7. spec:
  8. ruleEndpointType: "rest"
  9. properties: {}

create-ruleEndpoint-servicebus.yaml’s contents are as follows:

  1. apiVersion: rules.kubeedge.io/v1
  2. kind: RuleEndpoint
  3. metadata:
  4. name: my-servicebus
  5. labels:
  6. description: test
  7. spec:
  8. ruleEndpointType: "servicebus"
  9. properties: {"service_port":"6666"}

3.2 create rule. Exec command:

kubectl create -f create-rule-rest-servicebus.yaml

create-rule-rest-servicebus.yaml’s contents are as follows:

  1. apiVersion: rules.kubeedge.io/v1
  2. kind: Rule
  3. metadata:
  4. name: my-rule-rest-servicebus
  5. labels:
  6. description: test
  7. spec:
  8. source: "my-rest"
  9. sourceResource: {"path":"/a"}
  10. target: "my-servicebus"
  11. targetResource: {"path":"/b"}

3.3 user’s app calls rest api in the cloud to send messages to edge.

The rest api in the cloud can be called to send messages to servicebus on an edge node based on the node name and sourceResource.

  • Method: POST/GET/DELETE/PUT
  • URL: http://{rest\_endpoint}/{node\_name}/{namespace}/{path}, {rest_endpoint} is router’s endpoint, {node_name} is name of edgenode, {namespace} is namespace of rule. {path} is source ruleEndpoint’s sourceResource.
  • Body: {user_message}, {user_message} is user’s message

finally, kubeedge’s servicebus will call api on edgen node.

  • Method: POST/GET/DELETE/PUT
  • URL: http://127.0.0.1:{port}/{path}, {port} is target ruleEndpoint’s properties, {path} is target ruleEndpoint’s targetResource.

  • Body: {user_message}, {user_message} is user’s message

For example:

finnaly, kubeedge’s servicebus calls api on edge node. For example:

user’s app gets the result of the api on edge node.

Exception scenarios/Corner cases handling

CloudCore restart

  • When cloudcore restarts or starts normally, it will get all rules from edge-controller, and store in memory.

Implementation plan

  • Alpha: v1.6 rest->eventbus, eventbus->rest
  • Beta: v1.7 rest->servicebus
  • GA: TBD

最近更新于 Sep 7, 2021