Skip to main content
IMPORTANT Always ensure that your cluster, Orka tools and integrations, and Orka VM Tools run matching versions. For example, the respective available 3.x versions. Upgrading to 3.6.0 requires Orka 3.2.x. Contact MacStadium support if you need a staged upgrade. Some maintenance operations, such as adding Mac compute nodes, require the latest patch version (the .z in x.y.z). Patch upgrades are zero-downtime, include the latest bug fixes, and can be requested through MacStadium support. For downtime expectations, VM impact, and preparation steps by upgrade type, see Upgrading Orka.

​
Orka 3.6.2

​
Release summary

Orka 3.6.2 adds orka3 imagecache remove and a corresponding POST /v1/imagecache/remove API endpoint, fixes a VM runtime deadlock, adds UDP support for host/guest port reservations, ships code-signed darwin-arm64 binaries for the Virtual Kubelet and Upgrade Service agent, and includes an updated GitHub Actions integration (v1.1.14).

​
New features

​
Image cache removal

Orka 3.6.2 adds orka3 imagecache remove and a corresponding POST /v1/imagecache/remove API endpoint, enabling selective removal of cached images from Apple silicon nodes. Before this release, removing a cached image required a support ticket and manual intervention by MacStadium. Customers can now remove images directly to reclaim disk space, rotate old images, and support automated image lifecycle policies. Key behaviors:
  • Supports --nodes, --tags, and --all for targeted or cluster-wide removal, consistent with imagecache add
  • Removal is asynchronous; use orka3 imagecache info to check status
For usage and examples, see Image caching, the orka3 CLI reference, and the Orka API reference.

​
Improvements

AWS deployments Upgrading tooling on ARM nodes no longer requires replacing the AMI. Previously, an ARM tooling upgrade required deleting the instance, waiting approximately 2 hours for the replacement to provision, redeploying, and reapplying any custom namespace or tag configuration. ARM nodes can now receive tooling updates in place. On-prem deployments
  • Network isolation policy Ansible variables are now available for on-prem deployments. The VM network isolation feature introduced in Orka 3.6.0 can now be configured via Ansible for on-prem clusters. Contact MacStadium support to configure network isolation policies for your cluster.
Platform
  • VM port reservations now support an optional protocol suffix. Use <NODE_PORT>:<VM_PORT>/udp or <NODE_PORT>:<VM_PORT>/tcp when deploying a VM. The protocol is case-insensitive and defaults to TCP if omitted.
  • The Virtual Kubelet and Upgrade Service agent darwin-arm64 binaries are now code-signed with a Developer ID certificate in CI.
  • CLI help text image references have been updated.
GitHub Actions integration The GitHub Actions integration releases independently of Orka and is compatible with Orka 3.x. Version 1.1.14 is available.
  • The integration now tracks in-flight VM deployments to prevent over-provisioning when multiple jobs start at the same time.
  • On restart, the integration reconciles existing VMs rather than ignoring them. Running VMs are adopted and cleaned up when their jobs finish; failed or non-running VMs are cleaned up immediately, preventing orphaned VMs from consuming cluster resources. Controlled by the new ENABLE_RECONCILIATION environment variable (default: True).
  • The integration now reuses an existing runner scale set on restart instead of creating a new one, allowing in-progress jobs to continue uninterrupted. Controlled by the new MANAGE_RUNNER_SCALE_SETS environment variable (default: True).
  • Improved resilience for curl download errors during VM provisioning.

​
Bug fixes

  • Fixed: VM deadlock on long-lived VMs.
  • Fixed: Intel node disk performance regression.
  • Fixed: imagecache add with a :latest tag created duplicate and stale ImageCache CRDs due to missing tag normalization.
  • Fixed: The API did not accept single-encoded image names in the imagecache path.

​
Security

  • Updated golang.org/x/crypto and golang.org/x/net to address CVEs.

​
Known issues

imagecache remove and concurrent VM deployments orka3 imagecache remove is not protected against concurrent VM deployments. If removal runs during the brief window between a deployment’s pull and clone stages on the same node, the deployment may fail with a generic error. Do not run imagecache remove while VMs are actively being deployed from that image on the target node. Wait for in-flight deployments to complete first. See the orka3 imagecache remove reference for details.

​
Upgrade notes

CLI API URL for clusters with public NAT IPs If your cluster has public NAT IPs or a custom domain configured for the Orka API, the CLI now uses TLS based on a feature flag returned by the API rather than by detecting whether the configured address is a public IP. If your CLI is configured to use the internal IP address (http://10.221.188.20) on a cluster with public API access, connections will time out after upgrading to 3.6.2. Update your CLI configuration to use your public NAT IP or custom domain:
If you do not have a public URL or custom domain, no action is needed.

​
Orka 3.6.0

​
Release summary

Orka 3.6.0 introduces the Orka Upgrade Service: a Kubernetes-native update mechanism that enables MacStadium to deliver cluster upgrades to your environment. This release validates Orka against Kubernetes 1.35 on both on-prem and EKS, and adds configurable VM network isolation policies for Apple silicon nodes. Orka artifacts are now distributed publicly via CloudFront, eliminating the need for AWS credentials to pull binaries and images. The release also includes Jenkins and Packer plugin updates, GitHub Actions integration improvements, and automated Orka VM Tools updates.

​
New features

​
Orka Upgrade Service

Orka 3.6.0 ships the Orka Upgrade Service: a Kubernetes-native update mechanism that allows MacStadium to push Orka cluster upgrades to your environment. This initial release establishes the upgrade infrastructure. Future releases will expose available update versions to cluster administrators and allow them to control deployment timing.

​
Upgrade Service version visibility

orka3 version now includes the Upgrade Service operator version. kubectl get orkanodes -o wide shows the Upgrade Service agent version alongside each node.

​
Kubernetes 1.35 support

Orka 3.6 is validated against Kubernetes 1.35 on both on-prem deployments and AWS EKS. EKS customers can upgrade their clusters on schedule without risk of breaking Orka. A few things worth knowing during a Kubernetes upgrade:
  • Running VMs are not affected. Mac nodes are not part of the Kubernetes upgrade and do not restart.
  • The Virtual Kubelet does not need to be upgraded and is forward-compatible with new Kubernetes versions.
  • The API Server, Operator, and Webhooks may have brief downtime during node cordon/drain. Most orka3 CLI commands continue working during this window; only login and vm push require the API server. If the Operator pod is evicted during an upgrade, leader election takes up to 15 seconds. During this window VM deployments may be slower, but will not error.

​
VM network isolation

This feature is available on Apple silicon nodes only.
Orka 3.6.0 introduces configurable VM network isolation policies for Apple silicon nodes. MacStadium can configure explicit allow and deny rules by CIDR block, restricting which networks a VM can reach without changes to your broader network infrastructure. This is particularly useful in multi-tenant environments and for customers with security requirements around VM-level network segmentation. By default, VMs on MacStadium-hosted clusters have access to the storage network blocked. All other traffic, including internet access and VM-to-VM communication on the same node, is allowed unless explicitly restricted. Policy changes apply to VMs deployed after the change. VMs already running are not affected. To configure network isolation policies for your cluster, contact MacStadium support.

​
Automated Orka VM Tools updates

Orka VM Tools are now automatically updated in MacStadium’s base images on GitHub Container Registry (GHCR) with each Orka release. Images pulled from the orka-images GHCR repo now ship with the current VM Tools version automatically, without requiring manual installation.

​
Improvements

​
AWS and on-prem deployments

Several improvements reduce the operational footprint and permission requirements for AWS and on-prem deployments:
  • Orka no longer installs its own cert-manager if one is already present in the cluster. You can skip the bundled installation and use your existing cert-manager instead, eliminating version and configuration conflicts.
  • The permissions required for Orka to run have been scoped to least-privilege: separate, minimal credential sets are now defined for Orka configuration, the Virtual Kubelet, ECR access, and backup operations.
  • Webhook footprint has been reduced: the Pod webhook, ISO and image webhooks, and rolebinding webhook have been removed from AWS and on-prem installations.

​
Integrations

  • Jenkins OCI image support: The Orka Jenkins plugin now supports OCI images. Previously the plugin only allowed selecting images from NFS storage; you can now specify an OCI image directly.
  • Packer plugin bridge networking: The Orka Packer plugin now supports bridge networking, which was introduced in Orka 3.5 but was not supported in the plugin until this release.
  • GitHub Actions runner metrics: The Orka GitHub Actions integration now exposes an optional Prometheus metrics endpoint for runner scale set statistics. When enabled, the endpoint publishes labeled metrics per scale set with a configurable polling interval. The endpoint is opt-in and disabled by default.
  • GitHub Actions integration reliability: The Orka GitHub Actions runner now includes improved VM cleanup logic, an orphaned VM watcher that automatically removes VMs with no active runner, and expanded logging for better job observability.

​
Platform

  • ECDSA SSH key support: The Orka API now accepts ECDSA keys when uploading certificates. Previously only RSA keys were supported.
  • Prometheus metrics on port 443 with TLS: The Orka Prometheus data collector is now exposed on port 443 with TLS, unblocking use in environments that require all monitoring traffic to run over a secure port.
  • Object storage for cluster config backups: Orka cluster configuration backups are now stored via object storage instead of NFS, improving backup reliability and decoupling them from NFS availability.
  • Improved VM start error diagnostics: VM start failures during concurrent operations that previously produced empty error messages now surface actionable diagnostic information, including VZErrorDomain errors and configuration issues.
  • Public artifact distribution via CloudFront: Orka binaries and container images are now distributed publicly via CloudFront. AWS and on-prem deployments no longer require AWS credentials to pull Orka artifacts.
  • orka3 version reports Upgrade Service versions: The CLI now includes Upgrade Service operator and agent versions in version output.
  • Improved error message reporting from the Orka Engine for VM start failures.

​
Bug fixes

  • Fixed: Operator fails to configure Intel VMs
  • Fixed: Calico network plugin setup fails on Orka 3.5 clusters
  • Fixed: VM image push retries fail intermittently
  • Fixed: VK kubeconfig creation fails for on-prem deployments
  • Fixed: orka3 vm save fails when the cluster uses OCI image storage
  • Fixed: Updated the Kubernetes API TCP ingress route to use the built-in kubernetes service. If you manage your own Orka deployment and use public NAT IPs, apply the update by running:

​
Support

If you have questions or require assistance, please contact our support team.