Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Warning

This page was translated from the original Japanese version by PLaMo Translate. The Japanese version is authoritative; the English translation may contain inaccuracies.

Using Shared Nodes

Warning

This feature is currently only available in Service Release 1 (SR1). There is a limited number of shared nodes available, and their availability may vary depending on usage conditions. Visualization of the shared node usage status is planned for future implementation.

PFCP provides nodes shared among multiple organizations. Unlike dedicated nodes allocated to individual organizations, shared nodes are used by multiple organizations simultaneously.

Available Nodes

The following nodes are provided as shared resources:

  • MN-Server 2 (preferred.jp/mncore2)

Usage Instructions

By specifying a dedicated PriorityClass for your Pod, it will be automatically scheduled to shared nodes. While PriorityClass primarily functions for setting Pod priority, it also serves to control which type of node the Pod should be scheduled on. Therefore, users do not need to manually specify node selection (via nodeSelector). Below is an example of how to use a Pod with shared nodes:

apiVersion: v1
kind: Pod
metadata:
  name: shared
spec:
  priorityClassName: shared-standard # or shared-best-effort
  ...(omitted)...

The PriorityClasses available for using shared nodes are as follows:

  • shared-standard: Has the highest priority among shared node PriorityClasses and is not subject to preemption (cannot be forcibly removed)
  • shared-best-effort: May be preempted by Pods using the shared-standard PriorityClass

For detailed information on Pod priority and preemption, please refer to the official Kubernetes documentation.

Each organization has a resource quota for MN-Core 2 usage on shared nodes, with limits set for each PriorityClass. You can check the available MN-Core 2 quotas using the following command:

kubectl -n org-<organization-name> get hrq shared-standard shared-best-effort -o yaml

Constraints

  • There are limits on the maximum resource allocation per MN-Core 2. When requesting two MN-Core 2 resources per Pod, the quota is doubled. The maximum limits per MN-Core 2 for each resource are as follows:
    ResourceMaximum per MN-Core 2
    CPU7000m
    Memory125Gi
    Ephemeral Storage80Gi

Security

Unlike dedicated nodes, shared nodes share the same kernel with multiple organizations’ workloads running on the same physical machine. For stronger security isolation between different organizations, we recommend using dedicated nodes instead.

Additional Security Measures

Shared nodes employ Linux User Namespaces to enforce separation between container UID/GIDs in the Pod and the host system. This technology reduces the risk by preventing attackers who gain access from a container to the host from operating as root (user with UID 0) within the host environment. Linux User Namespaces are known to mitigate numerous past container-related CVEs1. For detailed information, please refer to the official Kubernetes User Namespaces documentation.


  1. https://github.com/kubernetes/enhancements/tree/217d790720c5aef09b8bd4d6ca96284a0affe6c2/keps/sig-node/127-user-namespaces#motivation