Infrastructure

Infrastructure in an MK.IO system is modelled with sites, networks and routes. When a project with SaaS access is first created, it will contain a simple starting layout of sites, networks and routes similar to below:

'world' is the default on-prem site used to host devices. If the project has access to an MK.IO SaaS location, another site with the name of the location will be present; for example 'westus2'. 'internet' is the default network and the default sites route to it. For simple system architectures, the default sites and networks could be enough. For system architectures that have a more advanced structure such as highly available, on-prem networking, sites and networks will need to be configured.

The default starting resources have some special behaviors:

• The 'world' on-prem site is a system owned site and cannot be deleted, however the routes can be modified.
• The 'westus2' SaaS site is a system owned site and cannot be deleted, however the routes can be modified.
• The 'internet' network is a system owned network and cannot be deleted.

Network concept

Network resources in MK.IO are simple representations of networks that are visible to sites. A network can be created with:

PUT https://app.mk.io/api/projects/myproject/v1/infra/networks/site-a-ingress

{
    "metadata": {
        "displayName": "Site A Ingress"
    },
    "spec": {}
}

Network resources:

• can represent networks on the edge of a system;
• can represent networks between sites within a system;
• can represent local networks within a site, and
• can model total bandwidth limitations.

Networks resources do not:

• connect directly to other networks (hops to another network must go through a site);
• directly manage network equipment, or
• represent complex network topologies.

👉

The idea of MK.IO network resources being 'simple representations' of real-world networks is an important concept. It is worth reiterating that network resources are not intended to model complex network topologies.

System owned networks

System owned networks are created automatically by the system and cannot be deleted directly; they are marked with an "owner": "System" field.

Connecting networks

Connecting networks are networks that link a site to another site, or a site to the edge of a MK.IO system.

Local networks

A local network is generated automatically when a site is created and is therefore also a system owned network; it has the same name as the site it belongs to. Local networks are marked with a "scope": "Local field.

Local networks represent a network that is local to the site (e.g. a LAN) and can only be used to connect flows, sources and destinations within the site. If flows, sources and destinations are on the same site, they must use the local network. Routing out of a site and back onto it through a connecting network is not possible.

Sites always have a route to the local network which cannot be deleted, but the existing route from a site to its local network can be modified to set default transports or constrain bandwidth.

Site concept

Site resources in MK.IO are representations of:

• SaaS locations (the SaaS location associated with the project), and
• On-prem customer sites.

Sites for SaaS locations can't be created directly, they are initialized automatically when the project is created. A 'world' on-prem site will also be initialized automatically. If more on-prem sites are needed, they can be created with:

PUT https://app.mk.io/api/projects/myproject/v1/infra/sites/site-a

{
    "metadata": {
        "displayName": "Site A"
    },
    "spec": {
        "routes": [
            {
                "networkName": "site-a-ingress"
            }
        ]
    }
}

👉

The concepts of Route and Transport below will be used by upcoming features. These are not necessary to enable onboarding and remote management of your fleet of devices.

Routes

Sites are linked to networks by adding routes inside a site resource. Routes:

• model the paths that network data can take between sites;
• can optionally configure default transports;
• can optionally model uplink/downlink bandwidth limitations.

Default transports

Default transport settings can optionally be added to a route; these settings influence the way that content will be transported in upcoming features.

⚠️

Default transport settings do not influence the way content is transported in services created via remote UI or the device's API.

System owned sites

System owned sites are created automatically by the system and cannot be deleted; they are marked with an "owner": "System" field. The routes on system owned sites can be edited.

Combining sites and networks

Sites and networks can be used together to partition systems in ways that model real-world constraints in on-prem systems. For example, for two on-prem sites that have separate networks for ingress, egress and highly available inter-site WANs, we could model it like this:

Combining on-prem and SaaS

In addition to linking on-prem sites, networks and sites can be used to seamlessly support streaming data between on-prem sites and SaaS sites. For example, we could model a system that encodes/encrypts content on on-prem site 'A' and streams it to the SaaS site 'westus2' for further transcoding and wider distribution.