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.

Learning the Fundamentals of Kubernetes

PFCP is built on Kubernetes, an open-source container orchestration platform. The documentation on this site assumes familiarity with basic Kubernetes concepts and terminology. If you’re new to Kubernetes, please review these fundamentals here. Additionally, gaining deeper knowledge of Kubernetes through official documentation or books will help you make more effective use of PFCP.

Overview of Kubernetes

Kubernetes is an open-source container orchestration platform hosted by the Cloud Native Computing Foundation (CNCF). It provides automated tools for deploying, scaling, and managing the availability of containerized applications, and has gained widespread adoption as the standard in this field.

For detailed information, please refer to the official Kubernetes documentation.

Note

PFCP is configured as a cloud service for deep learning and AI workloads based on Kubernetes. The clusters we provide are managed, meaning users do not need to operate the clusters themselves.

Clusters and Nodes

A cluster refers to a collection of machines that execute and manage workloads. From a user’s perspective, it can be treated as a single unified computing resource.

A node represents an individual machine that constitutes a cluster. In practice, this typically refers to either a standard virtual machine or a physical machine.

When a user instructs Kubernetes to deploy a workload, the system examines the resource requirements specified in the workload definition—including CPU, memory, and device specifications like MN-Cores—and then schedules and executes the workload on the appropriate node.

Note

In PFCP terminology, a node that runs user workloads is referred to as a “compute node.”

Namespace

A Kubernetes Namespace is a mechanism for logically partitioning a single cluster. Within Kubernetes, resource names must be unique within their respective Namespaces. Namespaces facilitate resource management by allowing separation of environments like staging and production, or by enabling shared usage among multiple teams or projects.

For detailed information, please refer to the official Kubernetes documentation.

Note

Typically, Kubernetes Namespace management requires cluster-wide administrator privileges. However, in PFCP, organizational administrators can manage Namespaces using Kubernetes custom add-ons.

Pod

In Kubernetes, workloads are organized into Pods, which consist of one or more containers. A Pod represents the smallest deployable unit in Kubernetes. Containers within a single Pod must always execute on the same node, sharing both network and storage resources while operating together.

For detailed information, please refer to the official Kubernetes documentation.

Containers and Container Images

Containers are a technology that enables the execution of isolated processes separate from the rest of the system. Since containers operate independently from the host and other processes, they are less prone to environment-dependent issues and can be executed consistently across different environments.

The necessary code, libraries, and runtime required to run containers must be packaged into a container image. These container images are stored and distributed through a service called a container image registry.

For detailed information, please refer to the official Kubernetes documentation.

Note

The PFCP dedicated container image registry provides container images containing all required files and software for MN-Core deployment, allowing you to quickly begin using MN-Core.

Note

PFCP does not provide its own container image registry for users to build and use container images in their clusters. Please use an external container image registry service instead.

Higher-level resources managing Pods: Deployment, StatefulSet, Job, CronJob…

Kubernetes offers higher-level resource types to manage Pods, supporting various types of workloads.

  • Deployment: Runs multiple Pod replicas distributed across cluster nodes. It automatically replaces failed or non-responsive Pods, making it ideal for maintaining highly available services.
  • StatefulSet: Runs Pod replicas with unique identifiers for each instance. Particularly useful for running stateful applications.
  • Job: Creates and retries running Pod replicas until a specified number of Pods successfully complete execution. Suitable for one-time training tasks.
  • CronJob: Creates Kubernetes Jobs based on specified schedules, similar to Linux cron.

    Warning

    Pods created directly by users without using higher-level resources (Bare Pods) will not be automatically rescheduled on other nodes if they stop due to node failures. Generally speaking, avoid creating Pods directly and instead use higher-level resources.

For detailed information, please refer to the official Kubernetes documentation.

Service

A Service provides a fixed network endpoint for a set of Pods. Since Pods automatically receive different IP addresses each time they are launched, you cannot reliably access them directly.

Additionally, Kubernetes includes built-in DNS functionality for address resolution within the cluster and provides service discovery capabilities using Service names. This allows you to access your workloads reliably by referencing the Service name.

For detailed information, please refer to the official Kubernetes documentation.

Ingress

An Ingress provides HTTP/HTTPS access to Kubernetes Services from outside the cluster. It enables request routing based on hostnames and paths.

For detailed information, please refer to the official Kubernetes documentation.

Note

In PFCP, you can use Ingress to securely expose services to the internet. See Publishing Workloads as Web APIs or Publishing Workloads as Web Applications for details.

Persistent Storage

Data stored in running Pods is lost when the Pod is terminated. For data that needs to be retained beyond the lifecycle of a Pod, you can provision persistent storage using PersistentVolumeClaims and mount it to your Pods for use.

For detailed information, please refer to the official Kubernetes documentation.

Manifest Files

YAML or JSON files that define the configuration state of resources you want to create and manage in your cluster are called manifest files. They are typically written in YAML format.

Kubernetes provides two methods for deploying workloads to your cluster: imperative creation/update via command-line tools, and declarative creation/update using manifest files. The imperative method offers the advantage of quick operations for temporary use. However, due to its lower reproducibility, we recommend using the declarative method with manifest files, which allows you to manage desired states as files—a practice that is generally preferable in most scenarios. For detailed information, please refer to the official Kubernetes documentation.