2.2. OPENMARU COP Configuration

---

Master (Control Plane) Nodes

A Master node runs the cluster control components such as the API server, etcd, the controller manager, and the scheduler. At least 3 are recommended to secure high availability.

VM Information

Item	Specification (recommended minimum)
vCPU	4 cores or more
Memory	16 GB or more
Disk	100 GB or more (OS) + a separate volume for /var/lib/rancher recommended
OS	Rocky Linux 9.5+ / Alma Linux 9.5+ / RHEL 9.5+
Network	At least 1 management network, static IP

ℹ️ Note: Adjust the node specifications for the actual production environment to the scale of the workload, together with the master: entries in env.yaml.

---

Infra Nodes

Infra nodes are optional nodes for running infrastructure workloads such as monitoring and CI/CD separately from the application workloads. When nodes are listed under infra: in env.yaml, taints and tolerations make sure only infrastructure workloads are scheduled on them.

VM Information

Item	Specification (recommended minimum)
vCPU	4 cores or more
Memory	16 GB or more
OS disk	100 GB or more
Data disk	200 GB or more (for metric and log storage, when Observability/APM is configured)
OS	Rocky Linux 9.5+ / Alma Linux 9.5+ / RHEL 9.5+

Taint-related configuration keys:

Configuration key	Description
taint_master_node	Applies a taint to Master nodes to block scheduling of general workloads
taint_infra_node	Applies a taint to Infra nodes so only infrastructure workloads are scheduled
tolerate_ingress_master_node	Allows the Ingress controller to run on Master nodes as well
tolerate_ingress_infra_node	Allows the Ingress controller to run on Infra nodes as well

---

Worker Nodes

Worker nodes run the actual application workloads (pods). They can be added freely as the scale of operation requires.

VM Information

Item	Specification (recommended minimum)
vCPU	8 cores or more
Memory	32 GB or more
Disk	200 GB or more
OS	Rocky Linux 9.5+ / Alma Linux 9.5+ / RHEL 9.5+
GPU (optional)	With an NVIDIA GPU installed, AI workloads such as CogentAI and vLLM can be run

ℹ️ For the procedure to add Worker nodes, refer to 3.1. OPENMARU COP Operating Procedures - Adding Worker/Infra Nodes.

GPU Node (Optional) VM Information

When running AI/GPU workloads such as CogentAI and vLLM, configure separate GPU nodes.

Item	Specification (recommended minimum)
vCPU	16 cores or more
Memory	64 GB or more
GPU	At least 1 NVIDIA GPU (48 GB VRAM or more recommended)
OS disk	200 GB or more (NVMe recommended)
Data disk	500 GB or more (NVMe recommended, for storing LLM models)
OS	Rocky Linux 9.5+ / Alma Linux 9.5+ / RHEL 9.5+

ℹ️ Note: The table above gives recommended minimums for ease of operation. For detailed specifications per workload type, refer to the system requirements document provided at installation.

---

Bastion

The Bastion is the management server hosting installation automation and the DevOps tools. For the detailed configuration, refer to 2.1. System Architecture - Bastion Server Configuration.

VM Information

Item	Specification (recommended minimum)
vCPU	4 cores or more
Memory	16 GB or more
Disk	500 GB or more (including NFS shared storage and registry storage space)
OS	Rocky Linux 9.5+ / Alma Linux 9.5+ / RHEL 9.5+

---

Cluster Startup and Shutdown Procedures

Starting the OPENMARU COP Cluster Nodes

When restarting after the cluster has been fully shut down for a power cut, scheduled maintenance, or similar, the following order must be kept.

1. Start the Bastion server

   # Power on the Bastion server first, then check the state of the basic services
   systemctl status named chronyd haproxy nfs-server docker
   
   # The Docker Engine must start normally for the GitLab/Harbor/Jenkins/Nexus/ChartMuseum/MariaDB
   # containers to come up with it. Check the container states as well.
   docker ps -a

2. Start the Master nodes one at a time (power on one node, then check the service state)

   systemctl status rke2-server

3. Check that etcd and the API server are healthy (after all Masters have started)

   kubectl get nodes -o wide

   Wait until every Master node is in the Ready state.

4. Start the Worker nodes

   systemctl status rke2-agent

5. Check the state of the whole cluster

   kubectl get nodes -o wide
   kubectl get pods -A | grep -v Running

⚠️ Caution: Master nodes must be started one at a time, and Worker nodes must be started only after every Master is in the Ready state. Starting them at the same time can delay etcd quorum formation and make cluster initialization fail.

Shutting Down the OPENMARU COP Cluster Nodes

When the cluster has to be fully shut down for a planned power outage, a data center move, or similar, follow this order.

1. Check that the application workloads have shut down safely

   kubectl get pods -A

2. Cordon and drain the Worker nodes one at a time

   kubectl cordon <worker-node>
   kubectl drain <worker-node> --ignore-daemonsets --delete-emptydir-data

3. Stop the service on the Worker nodes, then power them off

   systemctl stop rke2-agent

4. Stop the service on the Master nodes, then power them off (in reverse order, starting with the last node, is recommended)

   systemctl stop rke2-server

5. Shut down the Bastion server (Power off after confirming that the DevOps tools, DNS, and NFS services have all stopped normally.)

⚠️ Caution: Forcibly shutting down a Worker node without draining it terminates the workloads abnormally (SIGKILL) and can lose data. Always perform the cordon and drain steps first.

ℹ️ Note: For a rolling restart without downtime for scheduled maintenance, this is not a shutdown -- use 3.1. OPENMARU COP Operating Procedures - Adding Worker/Infra Nodes and the rolling restart automation playbook (openmaru-cop-rke2-rolling-restart.yaml).

---