Clean up on-prem and AWS install docs after 3.6 simplification

orka/orka-on-aws-and-on-prem/orka-on-aws-getting-started.mdx

@@ -13,7 +13,7 @@
 The diagram below illustrates the architecture of an Orka Cluster on AWS, detailing how it integrates with Amazon EC2 Mac instances, Amazon EKS (Elastic Kubernetes Service), and Amazon ECR (Elastic Container Registry) within a customer’s AWS account.
 
 ![Orka Cluster on AWS architecture diagram showing EC2 Mac, EKS, and ECR integration](/images/attachments/44003706780059.png)  
 The EC2 Mac hosts are set up with Orka AMIs, which provide a stable runtime for virtual machines. Each VM is deployed on the host using an OCI image, which can be fetched from Amazon ECR or an external OCI Registry. The use of OCI images enables rapid deployment (within a few minutes) of different macOS versions, pre-configured with various tools and optionally with SIP (System Integrity Protection) disabled. This addresses challenges that typically exist on Mac EC2 without Orka VMs. An EKS cluster will integrate with CI tools, CLI, or API, and orchestrate workloads, including spin-up and tear-down of VMs, and scheduled caching of images as needed.
 
 Key elements in the architecture include:
 
@@ -32,15 +32,15 @@
   * Storage
     * We recommend using ECR or alternative OCI repositories for image storage.
   * Mac EC2
     * We will provide an AMI based on an official AWS macOS base image that includes our tooling (Virtual Kubelet, Orka Engine) and a bootstrap script that accepts the EKS parameters to connect as an Orka worker node.
     * We have a new AMI available that supports the external NVMe disk available with M4 instances. Per the [official Amazon docs](https://aws.amazon.com/ec2/instance-types/mac/): "Amazon EC2 M4 Mac instances come with a new 2TB instance store volume per EC2 Mac Dedicated Host, providing low latency storage for improved caching and build/test performance."
 
 The new AMI is compatible with Orka 3.5 and later, and all EC2 Apple silicon Mac instance types (M1, M2, M4).
 
 By default:
 
 - The NVMe disk is used for Orka storage of VM and image data on M4 instances only
 - Autologin is enabled for the `ec2-user`, and is required when running a Sequoia guest OS or newer
 
 <Note>
   The `ENABLE_NVME_DISK` and `ENABLE_AUTOLOGIN` variables are **not** required. These are set to `true` by default, and either variable may be disabled if needed:
@@ -53,7 +53,7 @@
 /usr/local/bin/bootstrap-orka <eks-cluster-name> <vpc-region> <orka-license-key>
 ```
   * Networking
     * Apple silicon nodes don’t have a direct tie-in to the traditional k8s networking stack. With Orka, we provide a private network, expose certain ports, and require NATing for access. We do provide modes for network isolation and internet isolation. We provide documentation below for how to expose Orka services outside of the cluster. As of Orka 3.5.0, we also support [bridge networking mode](/orka/orka-on-aws-and-on-prem/using-bridge-networking-with-orka-350), enabling the ability to get an IP on a subnet in your VPC.
   * User Management and Authorization
     * Users need to register at portal.macstadium.com, as all user management is handled through the portal service. A future release will allow customers to use their own OIDC provider or Authentication mechanism.
   * Logging, Monitoring, and Alerting
@@ -73,17 +73,17 @@
     * Orka Operator: TCP 8080 (metrics), TCP 8081 (health check), TCP 443 (webhook), Linux worker nodes should be accessible from within the cluster on any port. Does not require Internet access.
     * Orka OIDC Provider: TCP 443. Requires connectivity to the authentication provider.
   * EC2 Mac Nodes
     * Virtual Kubelet / Orka Engine AMI: Ingress ports can be internal to the cluster network. The customer should allow ingress to all ports within the network. The following ports should be open to all networks that need access to the VMs: TCP 5900-5912 (Screenshare), TCP 5999-6011 (VNC), and TCP 8822-8834 (SSH). In general, we recommend allowing outbound requests uniformly for forward compatibility.
 
 
 
 ## Install Overview
 
   1. **Talk to your MacStadium Account Team about your Orka on AWS install.**
      1. Provide MacStadium with your AWS account ID and region to be used. This is needed so that the Orka AMI can be shared with your account.
   2. Follow the installation steps below for the EKS Cluster and the CodeBuild role.
      1. **Take note of the EKS Node IAM role and the CodeBuild role ARN, and share the 2 ARNs with your MacStadium Account Team**
   3. MacStadium provides customers with an OIDC Client ID to use during CodeBuild execution and with AMI details so they can install Orka software onto EC2 Mac.
   4. Follow the steps below to update your build spec with the OIDC Client ID, set up IAM roles so that CodeBuild can manage the EKS cluster, and execute CodeBuild to install Orka Services into the EKS cluster.
   5. Follow the steps below to set up the OIDC Provider
   6. Follow the steps below to expose the Orka API service via Load Balancer
@@ -98,28 +98,28 @@
      2. To set up the cluster, follow the AWS guidelines for [EKS Auto Mode](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-automode.html) or the [EKS QuickStart](https://docs.aws.amazon.com/eks/latest/userguide/quickstart.html).
   2. **Recommendations** :
      1. Select the same region for the cluster as the one used for deploying the EC2 Mac nodes to avoid costly cross-region traffic.
      2. Deploy the cluster in private subnets only, as none of the Orka services need to be accessed from the Internet directly.
      3. Deploy at least two Linux worker nodes for resiliency and high availability.
-  3. **Note down the ARN of the**[**EKS Node IAM role**](https://docs.aws.amazon.com/eks/latest/userguide/create-node-role.html)**.** This ARN is required by MacStadium to access the Orka service images.
+  3. **Note down the ARN of the**[**EKS Node IAM role**](https://docs.aws.amazon.com/eks/latest/userguide/create-node-role.html)**.** MacStadium needs this ARN to configure EKS cluster admin access for the node.
   4. **Optional:**
      1. Set Cluster endpoint access to “Private” to restrict access to your cluster API from the Internet.
         1. This setting depends on your access needs. All Orka clients (CLI, integrations, etc.) must have connectivity to the cluster.
      2. Use EKS API for Cluster authentication mode.
         1. This is the [newest authentication mode for EKS](https://aws.amazon.com/blogs/containers/a-deep-dive-into-simplified-amazon-eks-access-management-controls/), replacing the old aws-auth config map.
   5. Orka Cluster installs itself into EKS using Ansible scripts.
      1. **MacStadium support will provide an OIDC Client ID**
      2. Additional considerations
         1. The Ansible runner must have connectivity to the cluster API.
         2. The Ansible runner must have Cluster Admin privileges to set up the cluster.
         3. MacStadium recommends using CodeBuild to run Ansible and configure the EKS cluster. CodeBuild provides direct visibility to the cluster, alleviating networking concerns.
 
 
 
 ### Setup a CodeBuild project to run Orka Installation into the EKS Cluster
 
-MacStadium recommends using CodeBuild to run Ansible and configure the EKS cluster. CodeBuild provides direct visibility to the cluster, alleviating networking concerns. You will need to supply MacStadium with the ARN for the role that has permission to pull the image. To set up a CodeBuild project as an Ansible runner:
+MacStadium recommends using CodeBuild to run Ansible and configure the EKS cluster. CodeBuild provides direct visibility to the cluster, alleviating networking concerns. To set up a CodeBuild project as an Ansible runner:
 
-  1. **Allow AWS to create the CodeBuild role for you. Note down the name and ARN of the role, as you will need to share it with MacStadium and modify it later.**
+  1. **Allow AWS to create the CodeBuild role for you. Note down the name and ARN of the role — you will need to share the ARN with MacStadium and modify the role later.**
   2. Select the following options:
      1. Project type - Default project
      2. Source - no source
@@ -130,12 +130,10 @@
         4. Environment type - Linux Container
         5. Image registry - Other registry
            1. Under External registry URL, enter `ghcr.io/macstadium/orka-ansible-aws:<version_tag>` where `<version_tag>` is the Orka version.
-  3. Allow AWS to create the CodeBuild role for you.
-     1. Note down the name of the role, as you will need to modify it later.
-  4. (Optional) Set VPC, Subnets and security group to be used by CodeBuild. This is only needed if the EKS access is set to private. To do that:
+  3. (Optional) Set VPC, Subnets and security group to be used by CodeBuild. This is only needed if the EKS access is set to private. To do that:
      1. Click Additional Configuration
      2. Select the VPC where your cluster is deployed
      3. Select the subnets which EKS uses
      4. Select a security group that has access to the EKS API
   5. In the BuildSpec, add the following commands:
 
@@ -146,8 +144,8 @@
 Where:
 `{cluster_name}` - the name of your EKS cluster
 `{region}` - the region where the cluster is deployed
 `{k8s_api_address}` - the K8s API address of your cluster
 `{kube_oidc_client_id}` - the OIDC client ID provided by MacStadium
 
   6. Save the configuration.
   7. Next, Configure CodeBuild to manage the EKS cluster:
@@ -175,14 +173,14 @@
 
 To use the Orka API/CLI, you need to set up the OIDC provider.
 
 The issuer URL and client ID will be provided by MacStadium.
 
 To set up the provider:
 
   * Go to the Cluster Access tab.
   * Click `Associate Identity Provider`.
   * Add the `Issuer URL` provided by MacStadium.
   * Add the `Client ID` provided by MacStadium.
   * Add `cognito:groups` for the `Groups claim`.
   * Add `oidc:` for the `Groups prefix`.
 
@@ -196,7 +194,7 @@
 
 ### Cluster Admin Access
 
 By default, Orka's validator webhooks restrict certain operations (including deleting another user's VM) to cluster admins only. On AWS and on-prem deployments, cluster admin status must be explicitly configured. This differs from MacStadium-hosted clusters, where kubeadm automatically establishes the `kubeadm:cluster-admins` group.
 
 The default admin group for AWS and on-prem is `orka:cluster-admins`. To use a different group, set the `cluster_admin_group` Ansible variable before running the installation playbook.
 
@@ -236,7 +234,7 @@
 
 ## Provisioning Steps
 
   1. We will provide an AMI based on an official AWS macOS base image that includes our tooling (Virtual Kubelet, Orka Engine)
   2. The AMI will additionally include a bootstrap script that should be run via user data. See the section below for more detailed information
   3. The IAM role must be linked to an instance profile and attached to the instance
   4. The security group allowing access to the EKS control plane must be attached to the instance
@@ -250,7 +248,7 @@
 
 Orka Engine requires a valid license key to operate. To request a license key:
 
 1. Contact your MacStadium account representative
 
 2. Provide your organization name, deployment details, and use case
 
@@ -260,13 +258,13 @@
 
 5. Activate: `orka-engine license set --key YOUR_KEY`
 
 You can also download Orka Engine directly from MacStadium. Contact your account representative for the current installer link.
 
 ### Bootstrap Script
 
 The AMI includes a bootstrap script that can be run via [user data](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) and accepts the following parameters to connect as an Orka worker node:
 
   * EKS cluster name, EKS cluster VPC region, Orka License Key (provided by MacStadium)
   * The customer should pass the following as user data when launching an instance:  
 
 
@@ -293,7 +291,7 @@
 
 IAM-based or certificate-based kubeconfig authentication is not sufficient for `vm push` on its own. An `Unauthorized` error from `vm push` in this context indicates a missing Orka API token, not an ECR authentication issue.
 
 You can get credentials for use with a private ECR registry with the aws CLI as follows:
 
 
 ```
@@ -341,13 +339,13 @@
 
 
 
 ## Mac Node Deprovisioning Steps
 
 To deprovision a Mac Node you need to:
 
   1. Delete the Mac instance
   2. (Optional) Release the Mac dedicated host if you no longer need it
   3. Delete the Kubernetes node by running `kubectl delete node <node_name>` where `<node_name>` is the name of the node you want to deprovision
 
 
 
@@ -355,7 +353,7 @@
 
 ### OpenTelemetry Standards
 
 Logging and monitoring conform to OpenTelemetry best practices, meaning that metrics can be scraped from the appropriate resources via Prometheus and visualized with Grafana using Prometheus as a data source.
 
 Logs can be exposed on EC2 Mac workers via CloudWatch or by installing a `promtail` service, allowing them to be aggregated through Loki.
 
@@ -365,8 +363,8 @@
 
 What | Resource | Accessing | Purpose  
 ---|---|---|---  
 Virtual Kubelet Logs | Mac EC2 Node | Via promtail: `/usr/local/virtual-kubelet/vk.log` | Interactions between EKS and worker node for managing virtualization.  
 Orka VM Logs | Mac EC2 Node | Via promtail: `/Users/administrator/.local/state/virtual-kubelet/vm-logs/*` | Logs pertaining to the lifecycle of a specific VM  
 Pod Logs | EKS | Kubernetes Client, Kubernetes Dashboard, Helm Chart further exposing logs to a secondary service | All Kubernetes-level behavior  
 
 #### Key Metrics
@@ -386,4 +384,4 @@
 macOS 15 Sequoia guest OSes (VMs) will not work out of the box on AWS EC2 Mac. This is due to the newly required Apple ID guest functionality in Sequoia guest OS images which requires the host user that starts the VM to have a login keychain, even if they do not intend to use the Apple ID guest functionality. This is discussed in the [Apple Virtualization documentation](https://developer.apple.com/documentation/virtualization/using-icloud-with-macos-virtual-machines). Unfortunately, Marketplace security requirements do not allow the setup of any credentials on the host OS. As a result we have two options for macOS 15 support:
 
   1. After setting up your EC2 Mac, you will need to set up a login keychain on the host OS before running the Sequoia OS Orka VM image.
   2. MacStadium will supply a Sequoia OCI image that is upgraded from a Sonoma image rather than created from a Sequoia IPSW on Sequoia host. This will run without the Apple ID functionality in guest.

orka/orka-on-aws-and-on-prem/orka-on-prem-getting-started.mdx

@@ -4,7 +4,7 @@
 zendesk_id: 39570839057819
 ---
 
 With Orka On-Prem, you can now effortlessly integrate macOS development and macOS CI/CD into your On-Prem Mac Compute and Kubernetes-based workflows and environments. Don't have Kubernetes experience on-prem? Don't worry, MacStadium can configure a Hybrid Cluster using any Managed k8s Service like AWS Elastic Kubernetes Service, Google Kubernetes Engine, Azure Kubernetes Service, or using MacStadium hosted Kubernetes.
 
 # How does Orka On-Prem work?
 
@@ -12,14 +12,14 @@
 
 ![Orka On-Prem architecture diagram showing Kubernetes, Mac nodes, and OCI registry](/images/attachments/44003753966363.png)
 
 The Kubernetes 1.35 Cluster provides a runtime for the Orka Cluster Services. The Mac hosts are set up with Orka Engine (VM Runtime), which provides a stable runtime for virtual machines. VMs are deployed to the host using an OCI image, which can be fetched from any OCI registry, such as Artifactory, GitHub Container Repo (GHCR), or Amazon ECR. The use of OCI images enables sub-minute deployment of different macOS versions, pre-configured with various tools and optionally with SIP (System Integrity Protection) disabled. This addresses challenges that typically exist on Mac without Orka VMs. CI tools will integrate via the Orka API installed into Kubernetes, or the CLI or API it exposes to orchestrate workloads, including spin-up and tear-down of VMs, and scheduled caching of images as needed.
 
 Key elements in the architecture include:
 
   * A private network configuration for Orka.
   * A dedicated Kubernetes 1.35 cluster, which runs Orka Cluster Services for orchestration and automation.
   * Mac Nodes to be used for compute, usually on-prem.
   * An OCI Registry such as Artifactory, GitHub Container Registry, Docker Registry, AWS ECR, or others..
   * A load balancer for Orka Users to interact with the Orka Services on Kubernetes via CLI, API, or CI tools.
 
 
@@ -42,15 +42,15 @@
 
 We recommend following the [official guidelines](https://kubernetes.io/docs/setup/) for setting up a Kubernetes cluster. The official recommended tool for setting up Kubernetes clusters is [kubeadm](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/).
 
 If you are familiar with Ansible, you could also use [Kubespray](https://kubespray.io/) to set up your cluster.
 
 If you do not have experience with Kubernetes, MacStadium can host and manage the Kubernetes cluster for you in our Data Centers, or you can use an AWS EKS service to run your Orka Cluster Services.
 
 The following assumes you are installing and managing your own Kubernetes cluster.
 
 ### Setting up OIDC for Authentication
 
 Orka uses OIDC for user authentication. Make sure to configure the MacStadium OIDC provider in your Kubernetes cluster.
 
 This can be done by setting the following values for your Kubernetes API Server:
 
@@ -63,11 +63,11 @@
   --oidc-username-prefix=-
   '--oidc-groups-prefix=oidc:'
 ```
 If you are using kubeadm to set up your cluster, you can pass these values as extra args to the apiServer property in the ClusterConfiguration resource:
 
 
 ```
 apiVersion: kubeadm.k8s.io/v1beta3
 kind: ClusterConfiguration
 ...
 apiServer:
@@ -80,13 +80,13 @@
     oidc-groups-prefix: "oidc:"
 ...
 ```
 Alternatively, you could also add these manually as ApiServer arguments by editing the ApiServer config file (usually /etc/kubernetes/manifests/kube-apiserver.yaml)
 
 ### Obtaining an Orka License Key
 
 Orka Engine requires a valid license key to operate. To request a license key:
 
 1. Contact your MacStadium account representative
 
 2. Provide your organization name, deployment details, and use case
 
@@ -96,13 +96,11 @@
 
 ### Installing the Orka Cluster Services
 
-MacStadium distributes the Service Images needed to install Orka Cluster On Prem via AWS. As a result, the easiest way to perform an installation is to use some credentials that the MacStadium Support team will provide to gain access to the Ansible image with runners that are used to install.
-
-You will need an environment with outbound internet access to connect to AWS and download the installer (Ansible image). Ideally, this environment can also connect to the Kubernetes API and have admin access to the Kubernetes Cluster. If not, make sure to move the downloaded Ansible image to an environment with the appropriate connectivity and access.
+MacStadium provides the Orka Cluster Services installer as a public container image on GitHub Container Registry (GHCR). You will need an environment with outbound internet access to pull the Ansible image, connectivity to the Kubernetes API, and cluster admin access.
 
 1. Ensure the Ansible runner is set up correctly:
   1. The Ansible runner must have connectivity to the cluster API.
   2. The Ansible runner must have Cluster Admin privileges to set up the cluster (i.e. a kube config with admin privileges)
 
 2. On the host create a file called `cluster.yml`. This file will contain Ansible variables needed for the Orka setup. Add the following content:
 
@@ -127,7 +125,7 @@
 ```
 docker run -it -v <kube_config_location>:/root/.kube/config -v ./cluster.yml:/ansible/group_vars/all/cluster.yml ghcr.io/macstadium/orka-ansible-onprem:<version_tag> bash
 ```
-where `<kube_config_location>` is the location of the kube config file on the host. Typically `~/.kube/config`. `cluster.yml` is the file created in the previous step. And `version_tag` is the Orka version you are installing (i.e 3.6.0).
+where `<kube_config_location>` is the path to your kubeconfig (typically `~/.kube/config`), `cluster.yml` is the file created in the previous step, and `<version_tag>` is the Orka version you are installing (e.g. `3.6.0`).
 
 4. Make sure you are in the `/ansible` directory
 5. You can now run the Ansible playbook:
@@ -151,7 +149,7 @@
 
 ### Cluster Admin Access
 
 By default, Orka's validator webhooks restrict certain operations (including deleting another user's VM) to cluster admins only. On AWS and on-prem deployments, cluster admin status must be explicitly configured. This differs from MacStadium-hosted clusters, where kubeadm automatically establishes the `kubeadm:cluster-admins` group.
 
 The default admin group for AWS and on-prem is `orka:cluster-admins`. To use a different group, set the `cluster_admin_group` Ansible variable before running the installation playbook.
 
@@ -176,7 +174,7 @@
 
 ### Setup
 
 MacStadium provides another Ansible playbook that allows you to configure your Mac nodes with the software needed to run these nodes as Kubernetes worker nodes.
 
 To set up the Mac Nodes:
 
@@ -200,31 +198,26 @@
 ```
   4. Run the same Ansible image that was used to configure the Orka services:
 
-
-
-
 ```
 docker run -it -v <kube_config_location>:/root/.kube/config -v ./cluster.yml:/ansible/group_vars/all/cluster.yml -v ./nodes.yml:/ansible/group_vars/arm-nodes/nodes.yml -v ./hosts:/ansible/hosts -v <mac_ssh_key_location>:/root/.ssh/id_rsa ghcr.io/macstadium/orka-ansible-onprem:<version_tag> bash
 ```
-where `<mac_ssh_key_location>` is the location of the SSH key used to connect to the Mac nodes. And `version_tag` is the Orka version you are installing (i.e 3.6.0).
 
-  5. Ensure you are in the `/ansible` directory
-  6. Run the configuration playbook:
+where `<kube_config_location>` is the path to your kubeconfig (typically `~/.kube/config`), `<mac_ssh_key_location>` is the SSH key used to connect to the Mac nodes, and `<version_tag>` is the Orka version (e.g. `3.6.0`).
 
+  5. Ensure you are in the `/ansible` directory.
+  6. Run the configuration playbook:
 
-
-
 ```
 ansible-playbook configure-arm.yml -i hosts --ask-become-pass
 ```
 You will be asked for the ansible_user password. This is needed so that Ansible can set up autologin for the hosts. This is needed so you can run Sequoia VMs.
 
 ## Setting Up Backups
 
 Orka backups are exports of the Orka specific resources within the cluster:
 
   1. Orka Nodes
   2. Virtualmachine configs
   3. Service Accounts
   4. RoleBindings
 
@@ -237,18 +230,18 @@
      2. You define where the backups are stored
   2. Use the functionality provided by MacStadium
      1. MacStadium provides an Ansible playbook that:
      2. Sets up a cronjob that runs every 30 min by default
      3. The cronjob exports the resources mentioned above by default
      4. The job stores the backups in an S3 bucket that you have specified
 
 
 
 ### Using The MacStadium Provided Backup
 
 To use the MacStadium provided functionality you need to:
 
   1. Create an AWS S3 bucket and generate AWS access id and secret access key that provide permissions to write to the bucket
   2. Run the Ansible image provided by MacStadium and mount a backup.yml file with the following content
 
 ```
      aws_access_key_id_backup: # The creds that allow access to the S3 bucket  
@@ -269,11 +262,11 @@
 ```
 ### Implementing Your Own Backup
 
 The recommended way to backup Orka resources is via a CronJob, similar to what MacStadium provides out of the box.
 
 The resources you need to backup are:
 
   1. All namespaces with the label orka.macstadium.com/namespace
 
 ```
      kubectl get namespaces -l orka.macstadium.com/namespace=true -o yaml \
@@ -281,20 +274,20 @@
 ```
 Note - we are removing some metadata as otherwise restore would fail.
 
   2. OrkaNodes, VirtualMachineConfigs, ServiceAccounts, Rolebindings from these namespaces  
 Note - you need to remove some metadata from these resources. To do that, run the following:
 
 ```
      kubectl get "$resource" -n "$namespace" -o yaml \ 
         yq eval 'del(.items[].metadata.resourceVersion, .items[].metadata.uid, .items[].metadata.creationTimestamp, .items[].metadata.selfLink, .items[].metadata.managedFields, .items[].metadata.ownerReferences, .items[].metadata.generation, .items[].status)' 
 ```
 These resources can be stored in an yml file, which you can archive and store somewhere.
 
 # Logging, Monitoring, and Alerting
 
 ## OpenTelemetry Standards
 
 Logging and monitoring conform to OpenTelemetry best practices, meaning that metrics can be scraped from the appropriate resources via Prometheus and visualized with Grafana using Prometheus as a data source.
 
 Logs can be exposed on Mac workers installing a `promtail` service, allowing them to be aggregated through Loki.
 
@@ -302,16 +295,16 @@
 
 | What | Resource | Accessing | Purpose |
 | --- | --- | --- | --- |
 | Virtual Kubelet Logs | Mac Node | Via promtail: `/usr/local/virtual-kubelet/vk.log` | Interactions between k8s and worker node for managing virtualization. |
 | Orka VM Logs | Mac Node | Via promtail: `/Users/administrator/.local/state/virtual-kubelet/vm-logs/*` | Logs pertaining to the lifecycle of a specific VM |
 | Pod Logs | k8s | Kubernetes Client, Kubernetes Dashboard, Helm Chart further exposing logs to a secondary service | All Kubernetes-level behavior |
 
 #### Orka v3.4+ Log Sources
 
 | What | Resource | Accessing | Purpose |
 | --- | --- | --- | --- |
 | Virtual Kubelet Logs | Mac Node | Via promtail: `/var/log/virtual-kubelet/vk.log` | Interactions between k8s and worker node for managing virtualization. |
 | Orka VM Logs | Mac Node | Via promtail: `/opt/orka/logs/vm/` | Logs pertaining to the lifecycle of a specific VM |
 | Orka Engine Logs | Engine Node | `/opt/orka/logs/com.macstadium.orka-engine.server.managed.log` | Logs pertaining to Orka Engine |
 | Pod Logs | k8s | Kubernetes Client, Kubernetes Dashboard, Helm Chart further exposing logs to a secondary service | All Kubernetes-level behavior |