배포 가이드¶

이 가이드는 저장소에 실제로 존재하는 배포 표면인 릴리스 바이너리, 공식 컨테이너 이미지, Docker Compose, 유지 관리되는 Kubernetes/Kustomize 자산, Helm 차트, 사용자 정의 systemd 유닛을 설명합니다. Debian 패키지는 systemd 유닛을 설치하지 않습니다.

배포 전 준비¶

설정을 만들고 검증합니다.

continuum-router config generate --template production-ha --output config.yaml
# 템플릿이 참조하는 필수 환경 변수를 설정합니다.
continuum-router config validate config.yaml

더 작은 출발점에는 --template minimal을 사용하십시오. 사용 가능한 템플릿은 minimal, development, multi-provider, production-ha, api-gateway, kv-cache-optimized, smart-routing, disaggregated, cost-optimized입니다.

외부 리스너가 필요하지 않으면 루프백에 바인딩하십시오. 신뢰하지 않는 네트워크에 노출하기 전 API 및 Admin 인증을 활성화하십시오. 라우터는 평문 HTTP를 제공하므로 신뢰할 수 있는 리버스 프록시, 인그레스 컨트롤러 또는 로드 밸런서에서 TLS를 종료하십시오.

릴리스 기능 세트¶

기본 소스 빌드는 Cargo의 full 기능 세트를 사용합니다. 공식 릴리스 바이너리와 공식 컨테이너 이미지는 여기에 control-plane과 appproxy-router를 추가로 컴파일하며 둘 다 런타임 opt-in입니다. appproxy-legacy, bedrock-sigv4, redis-cache, s3-cache는 릴리스 워크플로가 명시적으로 추가하지 않는 한 소스 빌드 opt-in입니다.

런타임 설정으로 컴파일되지 않은 코드를 활성화할 수 없습니다. 기능 제한 배포를 진단할 때 Admin 자격 증명으로 /admin/capabilities를 확인하십시오.

Docker¶

공식 멀티 아키텍처 이미지는 릴리스 워크플로가 GitHub Container Registry에 게시합니다.

ghcr.io/lablup/continuum-router:<version> — Debian 기반 이미지
ghcr.io/lablup/continuum-router:<version>-alpine — Alpine/musl 이미지
latest, latest-alpine — 최신 비프리릴리스

프로덕션에서는 latest 대신 버전이나 digest를 고정하십시오.

docker run --rm \
  -p 8080:8080 \
  -v "$PWD/config.yaml:/etc/continuum-router/config.yaml:ro" \
  -e OPENAI_API_KEY \
  ghcr.io/lablup/continuum-router:1.14.0

이미지는 비root continuum 사용자로 실행되고 --config /etc/continuum-router/config.yaml로 시작하며 내장 --health-check 명령을 컨테이너 상태 검사에 사용합니다.

Docker Compose¶

저장소에는 docker-compose.yml이 있습니다. ./config.yaml과 VERSION 환경 변수를 사용합니다.

cp config.yaml.example config.yaml
# 주석 샘플을 실제 백엔드/인증 값으로 바꾼 뒤 검증합니다.
continuum-router config validate config.yaml
VERSION=1.14.0 docker compose up -d
docker compose logs -f continuum-router

Compose 파일은 ghcr.io/lablup/continuum-router:${VERSION:-latest}를 사용합니다. 마운트한 설정의 ${ENV_VAR} 참조에 제공자 자격 증명을 환경 변수로 전달하고 이미지나 Compose 파일에 비밀을 하드코딩하지 마십시오.

저장소 Dockerfile 빌드¶

Dockerfile과 Dockerfile.alpine은 일치하는 GitHub 릴리스 아카이브를 내려받습니다. 릴리스 버전을 명시하십시오.

docker build --build-arg VERSION=1.14.0 -t continuum-router:1.14.0 .
docker build -f Dockerfile.alpine --build-arg VERSION=1.14.0 \
  -t continuum-router:1.14.0-alpine .

이는 소스 빌드 Dockerfile이 아닙니다. 사용자 정의 기능 세트가 필요하면 바이너리를 별도로 컴파일한 뒤 해당 산출물을 복사하는 이미지를 만들거나 CI Dockerfile을 의도적인 빌드 파이프라인에 맞게 수정하십시오.

Kubernetes¶

유지 관리되는 Kustomize 번들은 deploy/kubernetes/base에 있습니다. 3개 replica, 리소스 요청/제한, startup/readiness/liveness probe, ClusterIP Service, TLS Ingress, HPA, PodDisruptionBudget, 제한된 pod 보안 설정, 읽기 전용 root 파일 시스템, ingress/egress NetworkPolicy를 포함합니다. deploy/kubernetes/overlays/staging의 스테이징 오버레이는 자동 스테이징 워크플로가 사용합니다.

적용 전에 제공자/모델 설정, 이미지 태그 또는 digest, Ingress 호스트와 TLS Secret, NetworkPolicy namespace selector, egress 규칙, 리소스 크기, 신뢰할 프록시 등 운영자별 값을 모두 검토하십시오. continuum-router-secrets는 별도로 생성해야 하며 체크인된 번들은 자격 증명을 생성하거나 저장하지 않습니다.

kubectl apply -f deploy/kubernetes/base/namespace.yaml
kubectl -n continuum-router create secret generic continuum-router-secrets \
  --from-literal=OPENAI_API_KEY="$OPENAI_API_KEY" \
  --from-literal=ROUTER_API_KEY="$ROUTER_API_KEY" \
  --from-literal=ADMIN_TOKEN="$ADMIN_TOKEN"
kubectl apply -k deploy/kubernetes/base
kubectl -n continuum-router rollout status deployment/continuum-router --timeout=5m

매니페스트를 바꾼 뒤 scripts/validate-deployment-assets.sh를 실행하십시오. 이 스크립트는 base, 스테이징 오버레이, 모니터링 번들, 모든 Helm 프로필을 렌더링하며 CI도 같은 검증을 수행합니다.

다음 최소 예시는 핵심 객체를 설명하는 용도로 유용합니다. 실제 배포의 유지 관리되는 단일 소스는 deploy/kubernetes/ 아래 파일입니다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: continuum-router-config
data:
  config.yaml: |
    server:
      bind_address: 0.0.0.0:8080
      workers: 4
    selection_strategy: RoundRobin
    backends:
      - name: ollama
        type: ollama
        url: http://ollama:11434
        models: [llama3.2]
    health_checks:
      interval: 30s
      timeout: 5s
      unhealthy_threshold: 3
      healthy_threshold: 2
      endpoint: /health
    logging:
      level: info
      format: json
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: continuum-router
spec:
  replicas: 2
  selector:
    matchLabels:
      app: continuum-router
  template:
    metadata:
      labels:
        app: continuum-router
    spec:
      terminationGracePeriodSeconds: 30
      containers:
        - name: router
          image: ghcr.io/lablup/continuum-router:1.14.0
          args: ["--config", "/etc/continuum-router/config.yaml"]
          ports:
            - name: http
              containerPort: 8080
          readinessProbe:
            httpGet:
              path: /health
              port: http
          livenessProbe:
            httpGet:
              path: /health
              port: http
          volumeMounts:
            - name: config
              mountPath: /etc/continuum-router/config.yaml
              subPath: config.yaml
              readOnly: true
          resources:
            requests:
              cpu: 100m
              memory: 256Mi
            limits:
              # server.max_concurrent_requests와 따로가 아니라 함께
              # 정하십시오. 아래 "용량 산정: 메모리"를 참고하십시오. 최악의
              # 상주 메모리는 동시성 곱하기 요청당 예산입니다. 파일 업로드는
              # 디스크로 스트리밍되어 더 이상 이 예산을 지배하지 않지만, 파일
              # 해석 상한에 닿은 요청 하나도 base64 확장 후 약 43 MiB를
              # 더합니다.
              memory: 1Gi
      volumes:
        - name: config
          configMap:
            name: continuum-router-config
---
apiVersion: v1
kind: Service
metadata:
  name: continuum-router
spec:
  selector:
    app: continuum-router
  ports:
    - name: http
      port: 8080
      targetPort: http

제공자 자격 증명에는 비밀 관리자나 Kubernetes Secret-to-environment 통합을 사용하십시오. ${ENV_VAR} 확장은 라우터 프로세스 안에서 일어납니다.

/health가 실제 구현된 비인증 상태 엔드포인트입니다. /healthz는 존재하지 않습니다. /version도 공개됩니다. 메트릭은 설정한 경로와 별도 인증 설정을 사용합니다.

위 readinessProbe 예시에는 periodSeconds/failureThreshold를 명시하지 않았지만 일부 오케스트레이터와 임베딩 호스트는 /health를 고정된 준비성 데드라인으로 폴링합니다. 기본값(health_checks.block_startup: true)에서는 모든 백엔드의 연결 프리워밍과 첫 헬스 체크 라운드가 끝날 때까지 리스너 바인딩을 기다리므로 응답 없는 백엔드 하나가 그 프리바인드 구간을 좁은 데드라인 너머로 늘릴 수 있습니다. 리스너를 먼저 바인딩하고 백엔드 상태를 백그라운드에서 수렴시키려면 health_checks.block_startup: false로 설정하세요. 자세한 내용은 시작 시 동작을 참고하십시오.

종료와 롤링 업데이트¶

HTTP 서버는 SIGINT/SIGTERM을 처리해 graceful shutdown을 시작합니다. 예상 스트리밍 요청에 충분한 오케스트레이션 유예 시간을 설정하되 라우터도 백그라운드 작업과 연결에 설정된 종료 시간 제한을 적용함을 고려하십시오.

롤아웃 가용성에는 두 개 이상의 replica를 사용하십시오. 인메모리 속도 제한, 응답 캐시, 저장된 Responses 세션, 일부 통계 같은 라우터 로컬 상태는 replica 사이에 자동 공유되지 않습니다. 지원되는 경우 Redis/영속 기능을 선택하거나 인스턴스별 동작을 수용하십시오.

Helm¶

deploy/helm/continuum-router는 development, staging, canary, production values 프로필을 제공합니다. 차트는 유지 관리되는 Kustomize 번들과 같은 보안·가용성 제어를 렌더링하며 Prometheus Operator ServiceMonitor를 선택적으로 생성할 수 있습니다.

helm lint deploy/helm/continuum-router
helm template router deploy/helm/continuum-router \
  --namespace continuum-router \
  -f deploy/helm/continuum-router/values-production.yaml
kubectl create namespace continuum-router --dry-run=client -o yaml | kubectl apply -f -
kubectl label namespace continuum-router app.kubernetes.io/name=continuum-router --overwrite
helm upgrade --install router deploy/helm/continuum-router \
  --namespace continuum-router \
  -f deploy/helm/continuum-router/values-production.yaml \
  --set-string image.digest="$IMAGE_DIGEST"

프로덕션 설치에서는 IMAGE_DIGEST를 승인된 sha256:... manifest digest로 설정하고 예제 호스트를 교체하며 existingSecret을 제공하고 기본 NetworkPolicy를 검토해야 합니다. 공식 이미지는 replica별 인메모리 속도 제한을 사용합니다. 공유 Redis 속도 제한과 Redis 응답 캐시는 redis-cache Cargo 기능으로 만든 사용자 정의 빌드가 필요하며 차트는 지원되지 않는 Redis 동작을 조용히 설정하지 않습니다.

자동 스테이징 배포¶

.github/workflows/deploy-staging.yml은 성공한 공개 릴리스 워크플로 실행 또는 수동으로 선택한 이미지 태그를 continuum-router-staging namespace에 배포합니다. 보호된 GitHub staging environment에 KUBECONFIG_B64, ROUTER_HOST, 필수 reviewer, 배포 branch 제한을 설정하십시오. 첫 실행 전에 continuum-router-staging namespace를 먼저 만들고 app.kubernetes.io/name=continuum-router 레이블을 지정한 뒤 그 안에 continuum-router-secrets와 continuum-router-tls를 생성해야 합니다.

워크플로는 게시된 semver 릴리스만 허용하고 manifest attestation을 검증하며 이미지를 변경 불가능한 digest로 해석합니다. 취소하지 않는 단일 concurrency group에서 server-side apply와 Deployment rollout 대기를 수행합니다. 모든 high/critical 이미지 취약점은 게시를 차단하며 빌드는 최종 멀티 아키텍처 manifest에 대한 SBOM과 provenance attestation을 게시합니다.

배포 전략¶

유지 관리되는 Deployment는 maxUnavailable: 0인 롤링 업데이트를 사용합니다. 롤백할 때는 helm rollback을 실행하거나 이전의 변경 불가능한 이미지를 다시 적용하십시오. 블루-그린 배포는 후보를 별도 release로 설치하고 상태와 메트릭을 확인한 뒤 ingress나 상위 Service를 원자적으로 전환하며 관찰 기간 동안 이전 release를 유지합니다.

카나리는 values-canary.yaml과 변경 불가능한 후보 이미지로 두 번째 release를 설치합니다. 이 프로필은 별도 Ingress, HPA, disruption budget 없이 레이블이 지정된 replica 하나를 만듭니다. Ingress controller나 service mesh에서 해당 release의 Service에 작은 명시적 가중치를 할당하고 오류율과 지연 시간을 관찰한 뒤 기본 release를 업그레이드해 승격하십시오. 차트는 특정 제품의 가중 라우팅 annotation을 가정하지 않습니다. 설정 및 기능 롤아웃도 같은 두 release 패턴을 사용할 수 있으며 release가 겹치는 동안 라우터 로컬 session, cache, 통계, 속도 제한 counter를 고려해야 합니다.

systemd¶

Debian 패키지는 바이너리, 예시, 문서, manpage를 설치하지만 유닛 파일은 설치하지 않습니다. systemd 관리가 필요하면 로컬 유닛을 만드십시오.

[Unit]
Description=Continuum Router
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=continuum-router
Group=continuum-router
EnvironmentFile=-/etc/continuum-router/environment
ExecStart=/usr/bin/continuum-router --config /etc/continuum-router/config.yaml
Restart=on-failure
RestartSec=5s
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/lib/continuum-router /var/log/continuum-router
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

활성화한 기능에 맞게 사용자와 쓰기 가능 경로를 만든 뒤 시작 전 검증합니다.

sudo /usr/bin/continuum-router config validate /etc/continuum-router/config.yaml
sudo systemctl daemon-reload
sudo systemctl enable --now continuum-router
journalctl -u continuum-router -f

tarball 설치는 ExecStart를 /usr/local/bin/continuum-router로 바꾸십시오. Files API, 통계 영속성, OAuth 토큰 저장소, control-plane 상태, Unix 소켓, 캐시 저장소에 맞게 sandbox 경로를 조정하십시오.

용량 산정: 메모리¶

최악의 상주 메모리는 합이 아니라 곱입니다.

최악 메모리  ~=  (동시 요청 수)  x  (요청당 예산)

라우터가 집행하는 메모리 상한은 모두 오른쪽 항에 걸려 있습니다. 왼쪽 항은 server.max_concurrent_requests가 생기기 전까지 아무것도 묶지 않았으므로, 이 값을 설정하기 전에는 상한이 곧 클라이언트가 열 수 있는 연결 수입니다.

요청당 항목¶

각 항목은 요청 하나에 걸리는 독립적인 상한입니다. 요청 하나가 모든 항목에 동시에 도달하지는 않지만, 각각은 단독으로 도달할 수 있습니다.

항목	기본 상한	설정 키	비고
요청 본문	10 MiB	설정 불가	Files 업로드를 제외한 모든 라우트에 적용됩니다. 파싱된 `serde_json::Value`가 원본 바이트 위에 추가로 상주하며, 보통 원본보다 큽니다.
파일 업로드 본문	512 MiB	`files.max_file_size`	청크 단위로 디스크에 스트리밍되므로, 상한과 무관하게 전송 1건의 메모리 비용은 64 KiB 버퍼입니다. 이 상한은 디스크와 정책의 문제입니다. 업로드는 전송이 끝날 때까지 `files.storage_path`에서 제 크기만큼을 차지하며, 검증에서 거부될 업로드도 마찬가지입니다. `files` 섹션을 생략하면 활성화가 기본값입니다.
요청당 해석된 파일 내용	원본 32 MiB, base64 확장 후 약 43 MiB	설정 불가	chat-completions, Anthropic Messages, Responses 경로에서 한 요청의 모든 `file_id` 참조를 합산한 값이며, 같은 파일을 여러 번 참조해도 참조마다 계산합니다. chat-completions는 요청당 참조 20개, Anthropic Messages와 Responses는 요청당 참조 100개 상한도 함께 적용됩니다. 인라인 파일 하나는 내용을 읽기 전에 10 MiB로 제한됩니다.
비스트리밍 업스트림 응답	없음	설정 불가	통째로 버퍼링됩니다. 실질적으로는 라우터가 아니라 프로바이더가 돌려주는 크기가 상한입니다.

곱셈 해 보기¶

속도 제한은 동시성 항을 대신하지 못합니다. 속도 제한이 묶는 것은 단위 시간당 도착 수이지, 동시에 상주하는 수가 아닙니다. Little의 법칙에 따르면 다음과 같습니다.

동시 요청 수  ~=  도착 속도  x  평균 요청 지속 시간

LLM 완성은 수십 초가 예사이므로, per_client: 10(초당 10건)에 평균 30초면 한 클라이언트에서만 약 300건이 동시에 떠 있고, 이는 전부 정책 안입니다. 파일 해석 상한까지 채우면 약 12.6 GiB가 상주하고, 본문만 따져도 파싱된 JSON을 세기 전에 약 2.9 GiB입니다. 업로드는 이제 이 메모리 수치에 기여하지 않지만, 기본 files.max_file_size로 업로드 10건이 동시에 진행되면 끝날 때까지 디스크 5 GiB를 차지하므로, files.storage_path는 허용하는 동시성에 맞춰 잡으십시오.

상한 설정¶

server:
  max_concurrent_requests: 64

기본값은 설정하지 않음이며, 이는 상한 없음, 즉 이전 모든 릴리스와 같은 동작을 뜻합니다. 상한을 넘으면 라우터는 대기열에 넣지 않고 503과 Retry-After, 그리고 상한을 명시한 JSON 본문으로 응답합니다. 대기열에 넣으면 메모리 부족 종료를 무한정 늘어나는 지연으로 바꿀 뿐, 메모리는 그대로 붙잡고 있기 때문입니다.

CPU가 아니라 감수할 메모리를 기준으로 정하십시오.

max_concurrent_requests  ~=  (컨테이너 메모리 상한 - 기본 사용량)  /  (예상 요청당 비용)

값을 고르기 전에 알아 둘 것이 둘 있습니다.

퍼밋은 요청 전체 동안 유지되며, 스트리밍 완성이라면 스트림 전체 동안입니다. 짧은 비스트리밍 트래픽에 맞춰 잡은 상한은 긴 스트리밍 트래픽을 굶깁니다. 가장 긴 요청을 기준으로 잡으십시오.
/health, /healthz, 설정된 metrics.path는 면제됩니다. 포화된 라우터도 자기 활성 상태 검사에 답하고 스크레이프도 계속 받습니다. 프로브를 차단하는 것은 정상적으로 성능을 낮추고 있는 레플리카를 과부하 한복판에서 재시작시키는 길입니다.

상한과 rate_limiting은 택일이 아니라 함께 씁니다. 속도 제한은 도착을, 상한은 상주를 묶으며 서로를 대체하지 않습니다. 앞단 리버스 프록시는 동시 연결 수와 본문 크기를 제한하도록 명시적으로 설정해야만 도움이 되고, 파일 참조 100개를 실은 요청의 비용은 알지 못합니다.

요청 타임아웃도 함께 두십시오. 라우터가 적용하는 타임아웃은 업스트림 호출에 대한 것이지, 인바운드 클라이언트가 슬롯을 얼마나 오래 쥐고 있어도 되는지에 대한 것이 아닙니다. 스트리밍 완성을 열어 두고 읽기를 멈춘 클라이언트는 연결이 살아 있는 동안 퍼밋을 계속 붙잡습니다. 그래서 상한만 두면 메모리 고갈 공격(공격자에게 비싼 공격)이 슬롯 고갈 공격(유휴 소켓 N개면 되는 값싼 공격)으로 바뀝니다. 프록시나 인그레스에서 인바운드 요청 또는 유휴 타임아웃을 걸어 두십시오.

컨트롤 플레인 supply 피드를 사용한다면 보고상의 주의점이 하나 있습니다. max_concurrency는 모든 라우트를 아우르는 상한인 반면 active_requests는 API 라우트만 셉니다. 따라서 파일 업로드로 포화된 라우터는 상한이 꽉 찬 상태에서도 낮은 active_requests를 보고하므로, 이 비율을 이용률로 읽지 마십시오.

컨테이너 크기 잡기¶

위의 Kubernetes 예시는 256Mi를 요청하고 1Gi로 제한합니다. 이 숫자들은 유휴 라우터의 하한으로만 보고, 설정하는 상한과 함께 올리십시오. 파일 해석 상한에 닿은 요청 하나도 base64 확장 후 약 43 MiB를 더하므로 동시성 상한과 컨테이너 메모리 상한은 사실상 한 결정입니다. 예를 들어 요청당 10 MiB를 예상하며 max_concurrent_requests: 64를 쓴다면 기본 사용량 위로 대략 1Gi의 여유가 필요합니다.

files.max_file_size는 메모리 예산이 아니라 디스크 예산입니다. 업로드를 받는 배포라면 files.storage_path를 그 값 곱하기 허용 동시성으로 잡으십시오. 또한 files.max_file_size가 컨테이너 메모리 한도에 비해 크면 라우터가 시작 시 경고합니다. 파일 전체를 한 번에 다루는 소비자가 아직 몇 군데 남아 있기 때문입니다(채팅 요청으로의 base64 파일 주입, 프로바이더 패스스루 재업로드). chat-completions의 base64 주입 경로는 내용을 읽기 전에 저장된 메타데이터를 확인해 10 MiB를 넘는 파일이나 원본 합계 32 MiB를 넘는 요청을 거부하므로, 더 큰 업로드가 디스크에 존재할 수는 있어도 하나의 채팅 요청 안으로 확장되지는 않습니다.

메모리 상한이 설정된 오케스트레이터 아래에서 상한을 넘기면 OOM 종료 후 재시작이며, 영향 범위는 해당 레플리카의 가용성과 그 위에서 처리 중이던 모든 요청입니다. 베어메탈이거나 메모리 상한이 없는 컨테이너라면 호스트 수준의 압박이 됩니다.

고가용성¶

Continuum Router에는 regions:, geographic_routing:, failover:, postgresql: 최상위 설정이 없습니다. 리전 간 트래픽 관리와 TLS는 외부 인프라에서 구현하십시오.

단일 라우터 안에서는 상태 필터, 서킷 브레이커, 재시도, 모델 폴백, 여섯 선택 전략이 백엔드 수준 복원력을 제공합니다. 일반 프록시 트래픽은 결과를 기록하고 열린 백엔드 서킷을 우회합니다. 여러 라우터 replica에서는 다음을 고려하십시오.

/health 검사를 사용하는 외부 로드 밸런서를 둡니다.
설정과 비밀 버전을 일치시킵니다.
어떤 속도 제한/캐시/통계 저장소가 프로세스별인지 확인합니다.
현재 세션 저장소는 프로세스 로컬이므로 sticky ingress 없이 저장된 /v1/responses/{id} 세션을 다른 replica에서 조회할 수 있다고 가정하지 않습니다.
Files API를 수평 확장하기 전 공유 스토리지와 소유권 메타데이터를 계획합니다.

성능 프로필¶

안전한 튜닝 절차:

생성된 템플릿에서 시작합니다.
제공자 직접 트래픽과 라우터 경유 트래픽을 측정합니다.
server.connection_pool_size, 시간 초과, 재시도, 상태 확인, selection_strategy를 튜닝합니다.
관측 트래픽을 기준으로 응답 캐시와 속도 제한 크기를 정합니다.
모든 변경을 검증합니다. 선택 전략, 재시도 정책, 요청별 타임아웃 예산은 실시간 리로드됩니다. 리스너/HTTP 클라이언트 구성처럼 시작 시 만들어지는 필드(timeouts.connection, 공유 클라이언트 상한인 timeouts.request.streaming.total)는 재시작합니다.

보안¶

공개 API 트래픽에는 API 키 blocking 모드를 사용합니다.
Admin, Files, WebUI, Metrics 인증을 각각 설정합니다.
라우터 앞에서 TLS를 종료합니다.
제공자 키는 환경/비밀 저장소에 두고 ${ENV_VAR}로 참조합니다.
Admin 접근은 사설 네트워크나 엄격한 프록시 정책으로 제한합니다.
config show --resolved 출력은 평문 자격 증명을 포함할 수 있으므로 공개하지 않습니다.
Admin 설정 저장/import 작업을 사용하지 않는다면 설정을 읽기 전용으로 마운트합니다.

공개 /health와 /version 엔드포인트는 운영 정보를 포함하며 API 키 인증을 사용하지 않습니다. 이 정보도 비공개여야 하면 네트워크 계층에서 필터링하십시오.

관측성¶

메트릭을 명시적으로 활성화하고 보호합니다.

metrics:
  enabled: true
  endpoint: /metrics
  auth:
    enabled: true
    username: metrics
    password: "${METRICS_PASSWORD}"

구조화된 프로덕션 로그에는 logging.format: json을 사용하십시오. CONTINUUM_LOG_LEVEL과 RUST_LOG로 상세도를 조절할 수 있으며 민감한 워크로드에서 디버그 로그를 장기간 사용하지 마십시오.

Admin 진단 예시:

curl -H "Authorization: Bearer $ADMIN_TOKEN" http://localhost:8080/admin/health
curl -H "Authorization: Bearer $ADMIN_TOKEN" http://localhost:8080/admin/backends
curl -H "Authorization: Bearer $ADMIN_TOKEN" http://localhost:8080/admin/circuit/all

백업과 복구¶

설정에서 실제 활성화한 운영자 소유 상태를 백업하십시오.

비밀을 제외하고 버전 관리하는 config.yaml 또는 TOML 원본
설정한 경우 외부 API 키 파일
Files API 스토리지와 메타데이터 데이터베이스
통계/메트릭 영속 파일
OAuth 토큰 저장소
기능 활성 시 control-plane 상태와 probe-budget sidecar
영속성이 필요한 응답 캐시 백엔드

동일한 바이너리 버전과 기능 세트로 복원 절차를 시험하십시오. 시작 전 복원한 설정을 검증합니다.

문제 해결¶

컨테이너 비정상¶

docker exec continuum-router continuum-router --health-check \
  --health-check-url http://localhost:8080/health
docker logs continuum-router

컨테이너 안에서 라우터가 루프백이 아니라 0.0.0.0:8080에 수신 중인지 확인하십시오.

설정 실패¶

continuum-router config validate /etc/continuum-router/config.yaml
continuum-router config show /etc/continuum-router/config.yaml

config show --resolved는 해석된 비밀을 노출할 수 있으므로 보호된 터미널에서만 사용하십시오.

백엔드가 선택되지 않음¶

요청 모델, 백엔드 모델 목록, 상태, 서킷 상태, 호출자 허용 목록을 확인하십시오. 선택 전략은 적격 후보 안에서만 선택합니다.