컨테이너화 2025: containerd 2.0와 eBPF가 모든 것을 바꾸는 이유

I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (excluding the source line you already provided) so I can translate it into Korean while preserving the formatting?

컨테이너화 환경 – 2024 → 2025

컨테이너화 환경은 언제나 역동적인데, 2024년 말부터 2025년까지 실용적이고 견고한 발전이 급증했습니다. 시니어 개발자로서 우리는 이제 “과대광고 사이클”을 지나 실제 운영상의 이점을 제공하고 현실적인 제약을 해결하는 기능을 평가하는 단계에 있습니다. 지난 한 해는 몇 가지 트렌드를 확고히 했습니다:

• 공급망 보안 강화
• 근본적인 런타임 효율성 개선
• 다중 아키텍처 배포를 위한 빌드 인체공학의 큰 도약
• 특정 워크로드에 대해 신뢰할 수 있는, 아직 초기 단계인 대안으로서 WebAssembly 등장

아래는 실제로 중요한 개발 사항들을 깊이 있게 살펴본 내용입니다.

1. 컨테이너 런타임 – containerd 2.0

컨테이너화된 세계의 기반인 컨테이너 런타임은 containerd 2.0이 2024년 말에 출시되면서 크게 진화했습니다. 이는 단순한 마이너 버전 업그레이드가 아니라, 1.0 출시 7년 후 핵심 기능을 전략적으로 안정화하고 강화한 것입니다.

• Kubernetes v1.24에서 dockershim을 제거하면서 containerd와 CRI‑O가 전면에 부상했으며, **Container Runtime Interface (CRI)**가 kubelet과 하부 런타임 간 표준 상호작용 프로토콜로 확고히 자리 잡았습니다.

안정 채널의 주요 기능

예시 사용 사례 – NRI를 통한 CPU 고정
성능이 중요한 워크로드에 대해 특정 CPU 고정을 강제해야 하는 조직이 있습니다. NRI 플러그인은 컨테이너 시작 시 이를 중재하여, 코어 containerd 데몬을 수정하지 않고도 다양한 노드 유형에 일관된 적용을 보장합니다.

2. 이미지 서명 – Sigstore가 선두에 서다

2025년은 컨테이너 이미지 서명 분야에서 결정적인 전환점이 되었습니다. Sigstore는 소프트웨어 공급망 보안을 위한 오픈 표준으로 확고히 자리 잡았으며, Docker는 2025년 8월에 Docker Content Trust (DCT)(Notary v1 기반)를 공식적으로 단계적으로 폐지하기 시작했습니다.

Sigstore 워크플로 (Mermaid로 시각화)

graph TD
    A["📥 OIDC Identity"] --> B{"🔍 Fulcio Check"}
    B -->|Valid| C["⚙️ Issue Certificate"]
    B -->|Invalid| D["🚨 Reject Request"]
    C --> E["📊 Sign & Log (Rekor)"]
    D --> F["📝 Audit Failure"]
    E --> G(("✅ Image Signed"))
    F --> G

    classDef input fill:#6366f1,stroke:#4338ca,color:#fff
    classDef process fill:#3b82f6,stroke:#1e40af,color:#fff
    classDef success fill:#22c55e,stroke:#15803d,color:#fff
    classDef error fill:#ef4444,stroke:#b91c1c,color:#fff
    classDef decision fill:#8b5cf6,stroke:#6d28d9,color:#fff
    classDef endpoint fill:#1e293b,stroke:#475569,color:#fff

    class A input
    class C,E process
    class B decision
    class D,F error
    class G endpoint

Sigstore 구성 요소

Source: …

signing event |

이 세 가지 요소는 키 없는 서명을 가능하게 합니다: 개발자는 자신의 신원 제공자(GitHub, Google 등)에서 OIDC 토큰을 받아 Fulcio에서 일시적인 서명 인증서를 획득합니다. 그런 다음 Cosign이 해당 인증서로 이미지를 서명하고, 서명(및 인증서)은 변경 불가능한 Rekor 로그에 기록됩니다.

이미지 서명 및 검증 (키 없는 방식)

# 1️⃣ OIDC 제공자와 인증
# (Cosign은 보통 환경 변수에서 자동으로 가져옵니다.)

# 2️⃣ 이미지 서명 (키 없는 방식)
cosign sign --yes /:

# 3️⃣ 이미지 검증
cosign verify /:

• --yes 플래그는 대화형 프롬프트를 건너뛰게 하며, CI/CD 파이프라인에 필수적입니다.
• cosign verify는 Rekor에 질의하여 서명의 진위와 무결성을 확인하고, 이를 검증 가능한 신원과 연결합니다. 이는 컨테이너가 실행되기 전, 공급망 수준의 강력한 보증을 제공합니다.

3. 팀에 미치는 의미

4. TL;DR

• containerd 2.0은 NRI, 안정적인 이미지 검증 플러그인, 간소화된 구성 마이그레이션을 제공합니다.
• Sigstore는 이제 이미지 서명의 사실상 표준이며, Docker의 DCT는 단계적으로 폐기되고 있습니다.
• Cosign/Fulcio/Rekor를 이용한 키 없는 서명은 장기 키를 관리하지 않아도 검증 가능한 출처 정보를 제공합니다.
• aufs에서 탈피하고 새로운 런타임 기능을 수용하면 보안 태세와 성능 모두가 향상됩니다.

앞으로도 2025년에는 특히 WebAssembly 런타임과 멀티‑아키텍처 빌드 파이프라인에 대한 개선이 계속될 예정이며, 올해 구축된 기반이 대규모 컨테이너 배포와 운영 방식을 이미 재편하고 있습니다.

Docker Buildx & BuildKit

Docker의 Buildx는 BuildKit 백엔드에 의해 구동되며, 특히 다중 플랫폼 이미지 빌드와 캐싱 전략에 있어 어느 정도 규모의 컨테이너 개발 워크플로우에서도 없어서는 안 될 도구로 자리 잡았습니다.

전통적인 docker build 명령은 기능적으로는 사용할 수 있지만, 성능 병목 현상과 제한된 크로스 아키텍처 지원으로 어려움을 겪는 경우가 많습니다. BuildKit은 빌드 작업을 Directed Acyclic Graph (DAG) 로 재구성하여 독립적인 단계들을 병렬로 실행하고, 뛰어난 캐싱 메커니즘을 제공합니다.

왜 다중 플랫폼 빌드가 중요한가

두드러진 기능인 다중 플랫폼 빌드는 이제 틈새 기능이 아니라 amd64, arm64, 심지어 arm/v7 아키텍처로 급속히 다양화되는 환경에서 실질적인 필수 요소가 되었습니다. buildx를 사용하면 하나의 docker buildx build 명령으로 매니페스트 리스트를 생성하여 여러 대상 플랫폼용 이미지를 한 번에 만들 수 있어 별도의 빌드 환경을 마련할 필요가 없습니다.

예시 Dockerfile

# Dockerfile
FROM --platform=$BUILDPLATFORM golang:1.21-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
ARG TARGETOS TARGETARCH
RUN CGO_ENABLED=0 GOOS=$TARGETOS GOARCH=$TARGETARCH go build -o /app/my-app ./cmd/server

FROM --platform=$BUILDPLATFORM alpine:3.18
COPY --from=builder /app/my-app /usr/local/bin/my-app
CMD ["/usr/local/bin/my-app"]

여러 플랫폼에 대한 빌드 및 푸시

docker buildx create --name multiarch-builder --use
docker buildx inspect --bootstrap
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t myregistry/my-app:latest \
  --push .

캐싱 장점

• 로컬 레이어 캐싱 – 표준 Docker 동작.
• 레지스트리 캐싱 – 이전에 푸시된 레이어를 이후 빌드에서 재사용하여, 자주 업데이트되는 프로젝트의 빌드 시간을 크게 단축합니다.
• CI/CD 영향 – 빌드 환경이 일시적인 경우 특히 유용합니다.

Kubernetes 네트워킹 및 관측성에서의 eBPF

eBPF (extended Berkeley Packet Filter) 가 Kubernetes 네트워킹 및 관측성 스택에 통합된 것은 실험적 호기심 단계에서 2024년 말과 2025년에 이르러 기본 기술로 자리 잡았습니다. eBPF는 샌드박스된 프로그램이 Linux 커널 내부에서 직접 실행되도록 하며, 다양한 이벤트에 의해 트리거되어 전통적인 커널‑유저‑스페이스 컨텍스트 전환의 오버헤드 없이 전례 없는 성능과 유연성을 제공합니다.

Networking

• CNI 플러그인인 Cilium과 Calico가 이제 eBPF를 활용하여 iptables 기반 접근 방식을 대체하거나 더 우수한 대안을 제공합니다.
• 효율성 – eBPF 프로그램은 커널 네트워크 스택 초기에 라우팅 및 정책 결정을 수행함으로써 CPU 오버헤드와 지연 시간을 감소시키며, 특히 대규모 클러스터에서 큰 효과를 발휘합니다.

Observability

• 시스템 콜, 네트워크 이벤트, 프로세스 활동에 eBPF 프로그램을 연결함으로써 개발자는 커널에서 실시간으로 상세한 텔레메트리 데이터를 캡처할 수 있습니다.
• 도구 – 예를 들어 Cilium Hubble은 eBPF를 사용해 네트워크 흐름을 모니터링하고, 서비스‑간 통신에 대한 지연 시간, 바이트 수, 정책 적용 결정 등을 노출합니다.

서버‑사이드 WebAssembly (Wasm)

WebAssembly는 원래 브라우저용으로 설계되었지만, 2025년 현재 서버‑사이드 및 클라우드‑네이티브 환경으로 확실히 진입하여 특정 사용 사례에서 기존 컨테이너에 대한 매력적인 대안을 제공하고 있습니다. 빠른 시작 시간, 매우 작은 메모리 footprint, 강력한 샌드박스 보안이라는 핵심 장점 덕분에 서버리스 함수와 엣지 컴퓨팅에 특히 적합합니다.

런타임 현황 (2025)

• Node.js, Deno, Bun 등 다양한 런타임이 Wasm을 네이티브로 지원하도록 진화하고 있습니다.
• 콜드‑스타트 차이: Wasm 모듈은 밀리초 단위로 시작되는 반면, 일반 컨테이너는 수 초가 걸립니다.

Kubernetes에서 Wasm 실행

Kubernetes는 CRI‑호환 런타임 및 shim을 통해 Wasm 모듈을 스케줄링합니다. runwasi와 같은 프로젝트는 containerd shim을 제공하여 Kubernetes가 Wasm 워크로드를 일반 포드처럼 취급할 수 있게 합니다.

예시: crun으로 Wasm 애플리케이션 배포

# runtimeclass.yaml
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: wasm-crun
handler: crun
---
# wasm-app.yaml
apiVersion: v1
kind: Pod
metadata:
  name: wasm-demo
  annotations:
    module.wasm.image/variant: compat
spec:
  runtimeClassName: wasm-crun
  containers:
  - name: my-wasm-app
    image: docker.io/myuser/my-wasm-app:latest
    command: ["/my-wasm-app"]

Kubernetes API Deprecations & Removals

Kubernetes는 새로운 기능을 도입하고 더 이상 사용되지 않는 기능을 퇴출하기 위해 API 표면을 지속적으로 정제합니다. 2024년 말과 2025년에는 API 폐기 및 제거에 대한 경계가 여전히 중요한 운영 작업입니다. 이 프로젝트는 Alpha → Beta → GA 단계에 걸친 명확한 폐기 정책을 따릅니다.

왜 중요한가

• v1.19 이후, 폐기된 REST API에 대한 모든 요청은 경고를 반환합니다.
• 자동화 도구와 CI/CD 파이프라인 검사는 폐기된 API를 사용하는 리소스를 식별하는 데 필수적입니다.

예시: extensions/v1beta1 API를 사용하는 Deployment 찾기

kubectl get deployments.v1.apps -A \
  -o custom-columns="NAMESPACE:.metadata.namespace,NAME:.metadata.name,APIVERSION:.apiVersion" \
  | grep "extensions/v1beta1"

사전 마이그레이션

• 업그레이드 창이 열리기 훨씬 이전에 마이그레이션을 계획하십시오.
• 주요 릴리스: v1.34 (2025년 8월) 및 v1.31 (2024년 7월) 에서는 주목할 만한 폐기 및 제거가 발생했으며, 이에 대한 주의가 필요했습니다.

런타임‑레벨 보안 향상

취약점 스캔은 여전히 기본적인 모범 사례이지만, 최근 개발은 런타임 수준에서 보안 프리미티브를 강화하는 데 초점을 맞추고 있습니다. containerd 2.0의 중요한 진전은 im (source에서 내용이 잘려 있음).

(원본 텍스트는 여기서 갑자기 끝납니다; 나머지 세부 사항은 제공되지 않았습니다.)

2025년 컨테이너 보안 및 개발자 도구

User Namespaces – 컨테이너는 이제 컨테이너 내부에서는 root 로 실행되면서 호스트에서는 권한이 없는 UID 로 매핑됩니다. 이는 컨테이너 탈출 시 발생할 수 있는 피해 범위를 크게 줄여줍니다.

런타임 보안

• eBPF‑based 솔루션은 컨테이너 동작을 실시간으로 가시화하고, 이상 징후와 정책 위반을 표시합니다.
• 최소 권한 적용:
  • 불필요한 Linux capability 를 제거합니다 (예: CAP_NET_ADMIN).
  • 가능한 경우 읽기 전용 파일 시스템을 사용합니다.

개발자 도구 개선

시니어 개발자에게 이러한 점진적이면서도 꾸준한 개선은 보다 실용적이고, 안전하며 효율적인 워크플로우로 이어집니다.

유용한 링크

• 개인 사이트:

  • henrikgerdes.me
  • karp.dev
  • github.io
  • dev.to
  • kubernetes.io

• DataFormatHub 도구 (주제와 관련):

  • YAML to JSON – Kubernetes 매니페스트 변환
  • JSON Formatter – 컨테이너 설정 포맷팅

• 최근 기사:

  • dbt & Airflow in 2025: Why These Data Powerhouses Are Redefining Engineering
  • AWS Lambda & S3 Express One Zone: A 2025 Deep Dive into re:Invent 2023
  • GitHub Actions & Codespaces: Why 2025

이 글은 원래 DataFormatHub에 게재된 것으로, 데이터 포맷 및 개발자 도구 인사이트를 제공하는 주요 리소스입니다.