Scheduled Caching
About
Orka Cluster version 3.2 brings a helpful new feature called Scheduled Caching. This feature allows users with admin privileges to download Orka images ahead of time, to any node in the Orka cluster. This means users enjoy a faster and more reliable VM deployment experience, as it helps to reduce delays caused by network bandwidth issues. Without Scheduled Caching, users would likely encounter delays during VM deployment, as automated CI jobs pull new images from the local cluster datastore (NFS mount) or a remote registry (cloud OCI registry service) during CI runtime.
System Requirements
Scheduled Caching is Only Available for:
- Orka Cluster 3.2+
- Mac computers based on Apple Silicon
- Updated Orka3 CLI Installer
Overview
The first time a VM is run on a node, the image needs to be cached locally on that node. Previously, there was no user control to bypass this step prior to running automated CI pipeline jobs. Since initial image pull speed is impacted by many variables (image size, network bandwidth, node resource utilization), a build operation using a new VM image deployment can take several minutes to complete and even provide an inconsistent deployment time. The Orka Scheduled Caching feature allows admin users to bypass these typical causes of delay by pre-caching new images on Orka Cluster nodes before CI automation starts.
The cluster knows which nodes have necessary images cached, greatly reducing image loading and scheduled downtime. But in the case where a node cache lacks a needed image, users can use the new feature to pick nodes for cache operations and stipulate VMs deploy on those nodes using those images. In other words, Scheduled Caching is an asynchronous operation.
Key Concepts
- Scheduled Caching allows preemptive copying of a Orka VM image on any cluster node member, to avoid delays caused by network bandwidth when images are pulled from the cluster NFS mount or from a public registry cloud service.
- An image is the bits on disk representing a VM that can be used for saving state and sharing modifications.
- MacStadium base VM Orka images are macOS OCI compliant VM images stored in our public GitHub registry ghcr.io/macstadium/orka-images/ with user credentials user/pwd: admin/admin, have Homebrew package manager installed, orka-vm-tools installed, and have screen sharing enabled and SSH access enabled.
- Cluster local storage is an NFS mounted filesystem for storing images locally (local registry service).
- A VM is a virtual runtime on top of the macOS host. The VM runs a guest OS image and macOS supports up to 2 running VMs per cluster node.
- Sequoia refers to macOS 15.0 the latest public GA release available from Apple’s servers.
NOTE:
Orka Cluster 3.0 and later can deploy a VM from multiple image sources: a cloud image datastore (OCI registry service), Orka’s local cluster registry (Cluster NFS mount), and lastly cached images on a cluster node member. Now in Orka 3.2 release there are three distinct CLI commands to display each type of storage and the images available on that specific datastore.
Getting Started
After the cluster nodes are upgraded to version 3.2 users can access the new Scheduled Caching feature and support for Sequoia guest OS VMs. To gain familiarity with Scheduled Caching via the Orka CLI take the following steps:
- Run the new orka3 CLI installer package for version 3.2 [[https://orkadocs.macstadium.com/docs/downloads#orka3-cli]]
- Connect to the cluster via VPN and login with the IP Plan credentials
- Open a Terminal window for shell access
- Run
orka3 imagecache -h
to see the CLI tree structure: commands, subcommands and options/flags - Run
orka3 remote-image list
to view Orka VM images available on MacStadium's public registry (ghcr.io/macstadium/orka-images/) - Run
orka3 image list
to view images already downloaded to the cluster local registry (cluster NFS mount) - Run orka3 imagecache list to view images currently stored on Orka Cluster nodes
- View the Orka Cluster node names by typing
orka3 nodes list
- Add a new image to a cluster node
orka3 imagecache add
- Check the status of a image caching operation
orka3 imagecache info
- Rapidly deploy a new VM using a recently cached Orka image on a specific node
orka3 vm deploy --image <image_name> --node <node_name>
Login to the Orka Cluster
orka3 login
Attempting to automatically open the authorization page in your default browser.
Waiting for successful login... (Press Ctrl+C to abort)
Login successful!
Check Images Available on Each Orka Cluster Storage Type
To view images available on Orka’s GitHub cloud registry repo that typically have the longest deployment times:
orka3 remote-image list
To view images available on your cluster’s NFS mount which is typically the second fastest to deploy:
orka3 image list
Also added to Orka Cluster version 3.2 is the ability view images available and already cached on Orka Cluster Kubernetes node members that deploy nearly instantaneously:
orka3 imagecache list
NAME TAG IMAGE-ID SPACE-USED NODES-COUNT
ghcr.io/user/orka/sonoma_dev_base latest 2683ee69c462 32G 1
ghcr.io/macstadium/orka-images/sequoia latest 39a6b0a1a66e 21G 1
ghcr.io/macstadium/orka-images/sonoma_ios latest ee27c37b1ec5 59G 1
sonoma-90gb-orka3-arm 8fdcb30befc9 17G 1
sonoma-90gb-orka3-arm-nfs 8fdcb30befc9 17G 2
ventura-90gb-orka3-arm 8666ab938a4a 15G 1
Note
The alias for imagecache is ic.
Ex.
orka3 ic list
is the alias equivalent to the above new version 3.2 command.
Check Cluster Node Names
By caching new images on specific nodes of the Orka Cluster, users can enable near spontaneous VM deployment with that image.
From the Orka CLI retrieve the node names:
orka3 nodes list
NAME AVAILABLE-CPU AVAILABLE-MEMORY STATUS arm-mini-001 2 6.40G READY arm-mini-002 5 11.20G READY
Add a New Image to a Node Cache
As an example If an image by the name of ventura-90gb-orka3-arm is needed for a coming CI job and it is not already cached on a cluster node with name arm-mini-001, then type the following command:
orka3 imagecache add ventura-90gb-orka3-arm --nodes arm-mini-001
Run orka3 imagecache info ventura-90gb-orka3-arm
to check the image cache status
Check the Node Cache Operation Status
To check the availability of an image cached to specific nodes and/or the status of an active image caching operation, use the orka3 imagecache info command and provide the desired image name:
orka3 imagecache info ventura-90gb-orka3-arm
NODE-NAME IMAGE-ID SPACE-USED STATE arm-mini-001 Caching arm-mini-002 8666ab938a4a 15G Ready
Once the image is cached it shows state Ready and the image can be used for VM deployment.
NODE-NAME IMAGE-ID SPACE-USED STATE arm-mini-001 8666ab938a4a 15G Ready arm-mini-002 8666ab938a4a 15G Ready
Deploy a New VM Using a Recently Cached Image
To use the newly cached image on node arm-mini-002 to deploy a VM, do the following:
- Check what VMs are running and determine on which nodes in the cluster. Recall there is an Apple Hypervisor Framework hard coded limit of two VMs per Apple system. The output shows that there is an active VM named vm-pl452 running on node arm-mini-002 so both nodes can run a VM.
orka3 vm list
NAME IP SSH VNC SCREENSHARE STATUS vm-pl452 10.221.188.32 8826 6003 5905 Running
orka3 vm list vm-pl452 --output wide
NAME IP SSH VNC SCREENSHARE STATUS IMAGE CPU MEMORY
vm-pl452 10.221.188.32 8826 6003 5905 Running sonoma-90gb-orka3-arm 3 4.80Gi
- Deploy a new VM using the recently cached image ventura-90gb-orka3-arm and run the VM on node node
arm-mini-002
:
orka3 vm deploy --image ventura-90gb-orka3-arm --node arm-mini-002
Waiting for VM vm-hpw6n to be deployed.
NAME IP SSH VNC SCREENSHARE STATUS vm-hpw6n 10.221.188.32 8822 5999 5901 Running
Note
The duration to deploy new VM vm-hpw6n was ~ 6s using the node cached image.
Updated about 1 month ago