Orka Technical Architecture

📘

Orka 2.4.x content

This page has not been updated to reflect the changes introduced in Orka 3.0. Some of the information might be outdated or incorrect. Use 2.4.x to 3.0.0: API Mapping and 2.4.x to 3.0.0: CLI Mapping to figure out the correct endpoints and commands.

The software layers involved start at the bare metal and scale all the way up to a containerized web front end. The following architectural overview outlines the physical build, the operating environment, and the software automation layer.

System overview

All of the available hardware capacity is layered with a base orchestration image that allows automation and control over the hardware assets. This layer allows containers of macOS images to be orchestrated to the Mac hardware.

On top of the base layer, we add our custom virtualization layer integrated with Docker and Kubernetes. We use this MacStadium virtualization to control the orchestration of Kubernetes environments on Mac hardware. We call it Orka.

In the case of the system view, the user namespace and Orka allow our Kubernetes environments to be presented and integrated as control systems to the overall platform. The user has full privilege to their own namespace to manipulate VMs and services. The user also has access to services provided by the Orka VM and images to initiate from the Image Manager.

Infrastructure

The Orka infrastructure leverages components that exist in the MacStadium data center environment. Typically, the control system runs from a set of 6- or 12-core Mac Pros, or Mac minis. Mac hardware provides the raw capacity used for images and builds. Storage provides a connected layer of space to unite the compute resources. The top end is headed by switches and firewalls. However, the Orka layer provides dynamic connectivity without the need for any firewall modifications by the customer.

Hardware components for internal networking are a command rack with network, storage, and compute. The command rack is capable of hosting several instances of Orka across multiple capacity racks. These instances are virtually isolated but can be further isolated by physical racks, VLAN, port isolation, and storage zoning. If a customer needs complete isolation at the physical layer, we can provide a completely dedicated command rack. Mac capacity could also be added to this rack to provide a self-contained VM of command and capacity.

Orka hosts are connected via physical layer-2 networking and integrated through the Orka host image OS.

Software layers

The Orka system consists of multiple service and microservice layers. Each component provides functionality to the system to allow operational, administrative, and developmental control aspects.

MacStadium automation layer

The automation layer is applied to all hardware infrastructure related to computational resources. This means blades and Macs. It consists of MacStadium code that unites a PXE system with Linux and embedded KVM drivers.

On top of this layer sits control and automation tooling such as Terraform, DNS services, and custom YAML. These tools help drive and update the core itself as well as implement image loading/checking.

Orka virtualization layer

The virtualization layer of the system integrates Docker and Kubernetes functionality to the core. Additional proprietary code allows these services, the base layer, and image management to integrate Docker-wrapped macOS images. These images can run on any of the Mac hardware running the Orka technical stack.

Interface layer

The interface layer provides logic and entry point into the Orka software system. It is the source for graphic interfaces and command-line interfaces for users.

The Orka database contains system information.

The image library contains references to the stored macOS and other Docker images.

The Orka command-line interface lets you control and connect to Orka resources.

The Orka RESTful interface provides API hooks to the system.

The Orka protocol service enables dynamic routing and networking over HTTPS, SSH, and other connection protocols.

The interface layer is also a microservice extendible entry point for MacStadium outside of Orka. Each system is deployed as a Kubernetes cluster with secured namespaces. This Kubernetes cluster is contained within secure VMs for the environment.

The Image Manager is an NFS mounted storage with software, allowing limited user interaction to pull and list available images. Orka provides the control interfaces for users to interact with the environment. The user sandbox is a Kubernetes namespace and is the primary user workspace that allows root control of the environment for the user to build and manipulate their environment.