Turing Pi의 Jetson Orin NX를 Yocto + k0s 노드로 운영하려면 어떻게 설계해야 하는가

결론

이 문서는 실제 노드에서 실행·검증되지 않은 참조 설계다. 현재 Orin NX 모듈·캐리어보드·BSP 버전과 저장장치·복구 경로가 확인되지 않아 Yocto + OE4T meta-tegra + 보드 적응 레이어 + k0s + NVIDIA Container Toolkit + SWUpdate A/B의 호환성이나 설치·업데이트 성공을 보장할 수 없다. 과거 r36.3 플래시 성공이나 r36.4.3 --no-flash 기록은 현 노드의 BSP나 재설치 절차를 입증하지 않는다.

아래 항목은 승인과 독립 검증이 필요한 설계 가설이지 현장 실행 순서가 아니다.

NVIDIA BSP는 Yocto로 대체하는 것이 아니라 meta-tegra를 통해 Yocto 이미지에 통합한다.
Yocto는 자동으로 immutable이 아니다. 초기 bring-up 단계에서는 writable rootfs와 SSH를 허용하고, 구성이 안정되면 read-only rootfs로 전환하는 편이 현실적이다.
k0s는 ARM64 Linux에서 동작하므로 Yocto 이미지에 포함할 수 있다. GPU 사용을 위해 k0s의 containerd에 NVIDIA runtime을 연결해야 한다.
네트워크로 서명·해시를 검증한 .swu를 받아 inactive 슬롯에 기록하는 A/B 업데이트는 후보 설계다. 현재 보드의 슬롯·부트전환·복구 절차와 아티팩트 검증을 입증하기 전에는 실행하지 않는다.
rootfs A/B와 DATA 파티션을 분리한다. Kubernetes 상태, 컨테이너 데이터, 모델 같은 변경 가능한 데이터는 OS 슬롯에 넣지 않는다.
bootloader/UEFI firmware 업데이트는 rootfs 업데이트와 별개로 취급한다. A/B rootfs가 있다고 해서 firmware까지 자유롭게 rollback할 수 있다는 뜻은 아니다.
최초 설치와 실패 복구에 사용할 공식 보드별 recovery 경로를 먼저 확인해야 한다. USB 경로의 필요 여부·가능 여부는 현재 모듈·캐리어·BSP 검증 전에는 확정하지 않는다.

1. NVIDIA BSP와 Yocto의 관계

BSP(Board Support Package)는 특정 하드웨어에서 운영체제가 부팅하고 장치를 사용할 수 있게 하는 하드웨어 지원 계층이다.

Jetson의 경우 NVIDIA가 제공하는 Jetson Linux Driver Package가 BSP이며 Linux kernel, UEFI bootloader, NVIDIA 드라이버, firmware, device tree, board configuration, flashing utility 등을 포함한다.

따라서 Yocto를 사용한다고 NVIDIA BSP가 사라지는 것은 아니다.

애플리케이션 / Kubernetes
        ↓
Yocto userspace
        ↓
meta-tegra
        ↓
NVIDIA Jetson Linux BSP
        ↓
Jetson Orin NX

2026-10-04 기준 NVIDIA의 최신 JetPack은 7.2.1, 대응 Jetson Linux는 R39.2.1이다. OE4T meta-tegra도 R39.2.1 / JetPack 7.2.1을 대상으로 하며 Orin NX용 reference-carrier 구성을 제공한다.

reference carrier와 실제 Turing Pi 보드의 차이, EEPROM 유무, MB2·device tree·firmware 변경 필요성은 현재 모듈·캐리어 식별값과 호환 BSP 릴리스 노트를 대조해 결정해야 한다. 다른 보드에 관한 가이드의 EEPROM 설정값을 현재 장비에 확인 없이 적용하지 않는다.

2. Yocto는 immutable OS가 아니다

Yocto는 Linux 이미지를 만드는 빌드 시스템이다. 결과 rootfs가 writable인지 read-only인지는 정책으로 정한다.

Yocto의 공식 이미지 기능 문서는 read-only-rootfs를 일반적인 선택지로 설명한다. 다음 구문은 빌드 설정의 예시이며 실제 Jetson 이미지에서 부팅·쓰기경로·업데이트가 검증됐다는 뜻이 아니다.

IMAGE_FEATURES += "read-only-rootfs"

반대로 package-management 기능을 포함하면 target에 패키지 관리자를 남기는 구성도 가능하다.

따라서 처음부터 immutable로 고정할 필요는 없다.

bring-up 단계: writable rootfs + SSH + debug tools
운영 단계: read-only rootfs + A/B + SWUpdate + persistent DATA

이 순서가 실용적이다.

3. JetPack 구성요소는 Yocto에 어떻게 들어가는가

Ubuntu에서는 nvidia-jetpack을 설치하지만 Yocto에서는 필요한 NVIDIA 구성요소를 image recipe에 포함한다.

meta-tegra는 GPU container 지원을 위해 nvidia-container-toolkit recipe를 제공하며 meta-virtualization과 virtualization distro feature를 사용한다. NVIDIA container가 host의 하드웨어 종속 라이브러리를 기대하는 경우가 있으므로 workload가 요구하는 CUDA/TensorRT/cuDNN/멀티미디어 구성요소도 host image에 포함해야 한다.

turingpi-k0s-image
├── Jetson BSP
├── NVIDIA Container Toolkit
├── 필요한 NVIDIA runtime libraries
├── systemd
├── k0s
└── updater

4. k0s 통합

k0s는 Linux ARM64를 지원하고 OS 의존성이 적어 Yocto image에 넣기 좋다.

Yocto
├── k0s
├── NVIDIA Container Toolkit
└── k0s bundled containerd
        ↓
   nvidia runtime
        ↓
     Jetson GPU

k0s 1.36부터 bundled containerd는 containerd 2를 사용하므로 /etc/k0s/containerd.d/의 runtime drop-in은 containerd config v3 형식을 사용해야 한다. 과거의 io.containerd.grpc.v1.cri 기반 v2 설정은 그대로 쓰면 안 된다.

cluster join token, 인증서, node identity 같은 secret은 공통 OS 이미지에 bake하지 않고 provisioning 단계에서 주입한다.

5. 업데이트는 세 계층으로 나눈다

애플리케이션 업데이트

Kubernetes가 container image를 교체한다. OS와 BSP는 건드리지 않는다.

OS/rootfs 업데이트

Yocto CI에서 .swu artifact를 만들고 Jetson이 네트워크로 내려받는다.

Git
 ↓
BitBake / CI
 ↓
image.swu
 ↓ HTTPS
Jetson
 ↓
SWUpdate
 ↓
inactive rootfs slot
 ↓
reboot

OE4T tegra-demo-distro의 SWUpdate 구성은 검토할 참조 구현이다. 현재 Turing Pi 보드의 부트 파티션·A/B 전환·전원 차단 후 복구·서명된 아티팩트의 진위·롤백을 검증한 기록이 없으므로, .swu 배포와 재부팅을 안전한 현장 업데이트 절차로 제시하지 않는다.

BSP/boot firmware 업데이트

UEFI capsule과 ESP를 사용하는 참조 구현이 있더라도 현재 보드의 boot firmware 갱신·복구 호환성을 보장하지 않는다. BSP 전환이 bootloader에 미치는 영향과 제조사 복구 경로를 별도로 검증해야 한다.

그러나 rootfs A/B와 firmware rollback은 같은 것이 아니다. rootfs는 이전 슬롯로 되돌리는 설계가 가능하지만 UEFI/bootloader capsule은 별도 firmware update이며 버전에 따라 rollback 제약이 있다. 따라서 firmware는 BSP 호환상 필요한 경우에만 별도로 검증해 적용한다.

6. NVMe 레이아웃과 저장공간

다음 NVMe 분할도는 현 노드에서 확인된 파티션 구조가 아닌 설계 예시다. 현재 저장장치 용량·부트 방식·백업·복구 가능성을 확인하기 전에는 적용하지 않는다.

NVMe
├── EFI / boot
├── rootfs A
├── rootfs B
└── DATA
    ├── k0s state
    ├── container data
    ├── models
    └── application state

A/B의 저장공간 비용은 rootfs 한 벌을 추가로 보관하는 것이다. 예를 들어 실제 OS image가 10GB라면 대략 10GB를 추가로 예약하는 식이다.

Yocto는 필요한 구성만 넣을 수 있으므로 Ubuntu 범용 rootfs보다 슬롯을 작게 유지하기 쉽다. 실제 슬롯 크기는 image 크기와 update margin을 보고 정한다.

중요한 것은 mutable data를 A/B rootfs에서 분리하는 것이다. Kubernetes 상태, 모델, application state, 필요하면 container storage도 persistent DATA에 두는 편이 좋다.

7. 최초 설치와 이후 운영

현재 보드·BSP와 부트 저장장치의 실제 상태를 확인하기 전에는 recovery flash 필요성, BMC·USB_OTG 경로 또는 장착 상태에서의 flashing 가능성을 확정할 수 없다. 아래 흐름은 현장 실행 절차가 아니라 검증해야 할 설계 단계다. 원본 데이터와 부트·복구 경로의 백업, 공식 호환성 확인, 서명 검증, A/B health check 및 실패 시 복구·롤백 시험과 승인 없이는 적용하지 않는다.

manifest 확인
 ↓
.swu 다운로드
 ↓
서명/hash 검증
 ↓
inactive slot 설치
 ↓
maintenance window
 ↓
reboot
 ↓
health check

USB 복구와 네트워크 업데이트의 역할은 해당 보드에서 실제 부팅·복구·롤백이 독립 검증된 뒤 결정한다.

8. Ubuntu + JetPack과 비교

항목	Ubuntu + JetPack	Yocto
초기 구축	쉬움	복잡함
즉석 패키지 설치	매우 쉬움	가능하지만 주 운영방식은 아님
CUDA/TensorRT 실험	쉬움	image/recipe 변경 필요
OS 재현성	보통	높음
immutable 구성	별도 설계	자연스럽게 구성 가능
A/B image OTA	가능	SWUpdate와 강하게 통합 가능
동일 노드 여러 대 관리	drift 관리 필요	image 단위 관리에 유리
Kubernetes appliance	가능	특히 적합

개발용 Jetson과 전용 GPU appliance의 선택은 운영 요구와 검증 비용에 달려 있다. Yocto 기반 무인 네트워크 업데이트는 이 보드에서 달성된 결과가 아니라 안전성과 유지보수성을 평가할 가설이다.

9. 승인 전 검증 단계(미실행)

부팅: meta-tegra + Turing Pi carrier adaptation + writable rootfs + SSH
GPU worker: k0s + NVIDIA Container Toolkit + 필요한 NVIDIA runtime libraries
OTA: rootfs A/B + SWUpdate + 별도 DATA
appliance화: read-only rootfs + signed update + health check + rollback policy

먼저 현재 모듈·캐리어·BSP를 식별하고 공식 호환 릴리스 노트와 부트·데이터 백업/복구 절차를 확인해야 한다. 테스트 장비에서 서명/해시 검증, 부팅 및 GPU 작업, A/B health check, 전원 차단과 잘못된 이미지 대응, firmware 별도 복구를 독립 검증한 후에만 변경 승인을 논의할 수 있다. 위 단계는 수행 기록이 아니다.

미검증 참조 아키텍처(현재 설치 상태 아님)

Turing Pi
└── Jetson Orin NX
    ├── NVIDIA Jetson Linux BSP
    │    └── meta-tegra
    ├── meta-turingpi
    ├── Yocto rootfs A
    ├── Yocto rootfs B
    ├── persistent DATA
    ├── k0s
    │    └── containerd
    ├── NVIDIA Container Toolkit
    ├── 필요한 NVIDIA runtime
    └── SWUpdate

이 파티션·업데이트 구상은 현재 장비의 상태도 검증된 재설치·복구 절차도 아니다. 공식 보드/BSP 호환성과 백업·복구·서명·health check·롤백 시험이 끝나기 전에는 현장 업데이트를 권장하지 않는다.

주의할 점

NVIDIA reference carrier 설정을 Turing Pi에 그대로 장기 사용한다고 가정하지 않는다.
BSP major migration에서는 kernel, firmware, UEFI, NVIDIA userspace의 호환성을 함께 검증한다.
rootfs rollback과 boot firmware rollback을 동일시하지 않는다.
secret과 node identity를 공통 image에 넣지 않는다.
k0s/containerd 설정은 사용 중인 버전의 schema를 확인한다.
버전과 지원 범위는 조사 기준일 이후 변경될 수 있다.

출처

NVIDIA, JetPack SDK Downloads and Notes: https://developer.nvidia.com/embedded/jetpack/downloads
OE4T, meta-tegra: https://github.com/OE4T/meta-tegra
OE4T, JetPack 7.2 / L4T R39.2 release notes: https://github.com/OE4T/meta-tegra/blob/master/docs/release-notes/JetPack-7.2-L4T-R39.2.0-Notes.md
OE4T, NVIDIA Container Runtime Support: https://github.com/OE4T/meta-tegra/blob/master/docs/NVIDIA-Container-Runtime-support.md
OE4T, tegra-demo-distro SWUpdate reference implementation: https://github.com/OE4T/tegra-demo-distro/blob/master/layers/meta-tegrademo/dynamic-layers/meta-swupdate/README.md
k0s, Runtime (CRI): https://docs.k0sproject.io/head/runtime/
k0s, System Requirements: https://docs.k0sproject.io/head/system-requirements/
Yocto Project, Reference Manual, Image Features (read-only-rootfs; generic feature only, not a tested Jetson image): https://docs.yoctoproject.org/dev/ref-manual/features.html
Turing Pi, Jetson Orin Nano Super on Turing Pi 2.5 Setup Guide: https://turingpi.com/jetson-orin-nano-super-turing-pi-2-5-setup-guide/