docker run --name myd my_daemon:0.1
nano save.dat => 100 (임의변경)
📘 PV(Persistent Volume)을 이용한 컨테이너 외부 데이터 저장 실습 정리
📌 1. 왜 Persistent Volume(PV)이 필요한가?
컨테이너는 기본적으로 휘발성(volatile) 저장 구조를 가진다.
- 컨테이너 내부에서 생성된 파일은 컨테이너가 삭제되면 함께 삭제된다.
- 즉, 데이터를 유지하려면 컨테이너 외부 공간에 저장해야 한다.
이를 해결하는 방법이 바로 Persistent Volume(PV) 이다.
📌 2. Persistent Volume의 역할
- PV는 호스트 머신의 특정 디렉터리를 Pod에 마운트하여,
컨테이너가 삭제되더라도 외부 디렉터리에 데이터가 남도록 해준다. - Pod는 이 마운트된 디렉터리를 로컬 디렉터리처럼 사용하지만,
실제 파일은 컨테이너 외부에 안전하게 저장된다.
📌 3. 이번 실습에서 할 내용
✨ (1) 외부 저장소를 Pod에 마운트
외부 디렉터리를 설정하여, 컨테이너 내부에서 생성한 값을 외부 디렉터리에 저장한다.
✨ (2) 환경변수 사용 실습
컨테이너 실행 시 환경변수(API)를 전달해본다.
- 환경변수를 사용하면 이미지를 다시 빌드하지 않고도 설정을 변경할 수 있다.
✨ (3) 실습 준비
/home/vagrant/apil디렉터리를 만든다.- 해당 디렉터리에
Dockerfile과my_daemon파일을 복사해 사용한다.
📌 4. 학습 포인트 요약
- 컨테이너는 삭제되면 데이터도 사라진다.
- 데이터를 유지하려면 Persistent Volume(PV) 이 필수이다.
- PV를 사용하면 Pod 내부 데이터 → 외부 저장소로 안전하게 보존 가능.
- 환경변수를 사용하면 이미지 재빌드 없이 컨테이너 설정 변경 가능.
🟦 SA(Service Account)와 RBAC 정리
클라우드 환경에서는 여러 개발자와 여러 애플리케이션이 동시에 동작하기 때문에
사용자·프로세스별 권한 관리가 필수이다.
🔹 SA(Service Account)
- Pod 내부에서 실행되는 애플리케이션 전용 계정
- 쿠버네티스 API 서버에 접근할 때 사용됨
- 애플리케이션이 “누구의 권한으로” 실행되는지 결정
🔹 RBAC(Role-Based Access Control)
- 역할(Role) 을 기반으로 권한을 부여하는 방식
- “무엇을 할 수 있는지(권한 범위)”를 정의
- SA 또는 User에게 Role을 연결시켜 실행 가능한 행동을 제한·허용
🟩 핵심 관계 정리
[SA] → 어떤 주체가 실행하는가?
[RBAC] → 무엇을 할 수 있는가?SA는 “실행 주체”,
RBAC는 “권한 규칙”을 담당한다.
🟨 한 줄 요약
SA + RBAC = 쿠버네티스에서 권한을 체계적으로 관리하는 핵심 오브젝트 조합
ssh로 접속하지만, 이미 키들이 다 들어가 있어서,
인증 과정없이 접속이 가능함.
🟦 SA, Role, ClusterRole 정리
SA(Service Account)는 쿠버네티스에서 권한을 부여받아 동작하는 오브젝트로,
Pod 내부 애플리케이션이 API 서버에 접근할 수 있게 해주는 계정이다.
SA는 네임스페이스(NS) 단위에 속하는 리소스이며 기본적으로 default SA가 존재한다.
하지만 kubectl create sa kim 으로 새로운 SA를 만들어도,
권한이 없으면 아무것도 할 수 없다.
예를 들어:
- Kubernetes cluster 전체를 관리하는 권한 =
cluster-admin - 사용자 정의 SA(kim)는 기본적으로 권한이 없어서 조회조차 못함
- 따라서 kim SA가 특정 작업을 하려면 Role 또는 ClusterRole을 연결해 권한을 부여해야 한다
🟩 Role vs ClusterRole 비교
Role과 ClusterRole은 모두 "권한의 범위(scope)"를 정의하는 쿠버네티스 RBAC 오브젝트지만
적용 범위가 다르다.
| 종류 | 설명 |
|---|---|
| Role | 네임스페이스 단위 권한을 정의. 특정 NS 내 리소스(Pod, Deployment, Service)의 조회/생성/삭제 권한만 설정 가능. → kubectl get role 로 확인 |
| ClusterRole | 클러스터 전체 단위의 권한을 정의. 네임스페이스에 속하지 않는 리소스(노드, PersistentVolume 등)까지 권한 부여 가능. 여러 네임스페이스에서 반복적으로 사용할 수 있음. → kubectl get clusterrole 로 확인 |
🟨 핵심 흐름 정리
- SA는 “실행 주체”
- Role/ClusterRole은 “무엇을 할 수 있는지(권한)”
- SA → RoleBinding or ClusterRoleBinding → 권한 연결
- 권한을 부여받은 SA만 Kubernetes API 작업 가능
🟧 한 줄 요약
SA는 실행 계정이고, Role/ClusterRole은 권한 범위이며, 둘을 묶어줘야 실제로 Kubernetes 리소스를 조작할 수 있다.
🟦 SA → Role → RoleBinding 흐름 정리 (보기 좋게)
1) 기본 과정
- SA(ServiceAccount)를 생성한다.
- Role 또는 ClusterRole로 권한을 정의한다.
- RoleBinding/ClusterRoleBinding으로 SA와 Role을 연결한다.
→ 이때 SA는 Role에 적힌 권한 그대로 사용할 수 있게 된다.
🟩 개념 비교 예시 (쉽게)
▪ 데이터베이스(DB)
- 유저 생성 → Role 생성 → Role을 유저에게 부여
- 그러면 유저는 Role에 정의된 권한으로 쿼리를 실행한다.
▪ Windows Server
- 그룹 생성 → 그룹에 권한 부여 → 사용자들을 그룹에 추가
- 그러면 사용자는 그룹이 가진 권한을 그대로 물려받는다.
🟨 핵심 요약
권한 구조는 “주체 + 권한 정의 + 권한 연결”이라는 동일한 패턴으로 이루어진다.
Kubernetes에서도 SA가 “주체”, Role이 “권한”, RoleBinding이 “권한 연결”을 담당한다.
🟧 한 줄 결론
SA + Role + RoleBinding 구조는 쿠버네티스를 포함한 대부분의 시스템에서 공통적으로 사용하는 권한 관리 방식이다.
default namespace안에 있는 service 목록을 볼 수 있다.
kubectl get svc --as system:serviceaccount:default:alicek106
service에는 권한이 있지만, deploy, pod 에는 권한이 없다.
Aggregation
🟦 Limits (리밋)
컨테이너가 사용할 수 있는 최대 자원량을 정의한다.
Kubernetes는 내부적으로 Docker와 동일하게 cGroup 기술을 활용하여
CPU·RAM 등의 최대 사용량을 제한한다.
리밋을 지정하지 않으면 컨테이너는 노드의 자원을 마음대로 모두 사용할 수도 있다.
➤ Limits의 종류 예시
—memory—cpus—cpu-shares—cpu-quota—cpu-runtime
🟩 Requests (리퀘스트)
컨테이너가 최소한으로 보장받아야 하는 자원량이다.
Pod 스케줄러는 Requests 값을 기준으로
해당 Pod를 적절한 노드에 배치해 효율적으로 자원을 사용하도록 한다.
🟨 예제로 이해하는 Limits & Requests
예시 상황
- A Pod와 B Pod가 있고, 두 컨테이너 모두 Requests=500MB,
전체 노드 RAM은 1GB라고 가정한다.
→ 두 컨테이너는 각각 최소 500MB가 필요하므로 노드 1GB에 정확히 맞게 배치된다.
하지만 실제 사용량이 달라질 때
- B 컨테이너는 실제로 100MB밖에 쓰지 않아도
- 남은 400MB는 A 컨테이너가 사용할 수 있다 (OverCommit 가능)
단, Limits에 도달하면?
예시:
- A가 800MB까지 필요
- B가 700MB까지 필요
→ 만약 Limits를 낮게 설정하면 충돌이 발생할 수 있음
→ Kubernetes는 Requests로 최소치만 보장하고,
Limits는 최대 경계선만 지정하기 때문
즉, Requests는 "최소 확보 자원",
Limits는 "최대 허용 자원"을 나타낸다.
🟧 핵심 요약
- Requests = 최소 보장
- Limits = 최대 허용량
- Requests 기준으로 Pod가 배치되고
- Limits 기준으로 Pod가 자원을 넘어서 쓰지 못한다
- OverCommit이 가능하지만, Limits를 초과하면 제한된다
🟦 메모리 경쟁(Eviction)과 Pod 종료 우선순위
메모리는 CPU와 다르게 압축하거나 되돌릴 수 없는 자원이다.
한번 메모리에 올라간 데이터는 즉시 줄일 수 없기 때문에
노드에서 메모리 경쟁이 발생하면 심각한 문제가 생길 수 있다.
➤ 메모리 경쟁이 발생하면 어떻게 되는가?
- 노드의 메모리가 부족해지면
우선순위가 가장 낮은 Pod부터 강제로 종료(Kill)된다. - 강제로 종료된 Pod가 들고 있던 데이터나 실행 중이던 작업은
손실될 수 있으며,
다른 노드로 옮겨지는 상황을 Eviction(축출) 이라고 부른다.
➤ 왜 메모리 경쟁이 위험한가?
- CPU는 스케줄링으로 조절 가능하지만
- RAM은 누군가 차지하고 있으면 즉시 회수 불가
- 따라서 메모리 부족 상황은 시스템 전체의 안정성을 크게 흔들 수 있다.
🟩 쿠버네티스의 Pod 종료 우선순위(QoS Class)
Kubernetes는 설정된 Requests / Limits 값을 기준으로
Pod의 우선순위를 다음 3가지 QoS(Quality of Service) 로 분류한다.
우선순위 (높음 → 낮음)
- Guaranteed
- Burstable
- BestEffort
➤ 어떤 Pod가 가장 먼저 종료될까?
BestEffort Pod → Burstable Pod → Guaranteed Pod 순으로 강제 종료(Eviction) 된다.
즉,
메모리를 가장 많이 쓰거나,
Requests·Limits 설정이 불완전한 Pod일수록
노드 메모리 부족 시 가장 먼저 희생된다.
🟧 한 줄 요약
메모리가 부족해지면 Kubernetes는 QoS가 가장 낮은 Pod부터 강제 종료시키며, 이를 Eviction이라고 한다.
🟦 Scheduling(스케줄링) 이란?
클라우드 환경에서는 자원 제한뿐 아니라, 컨테이너를 어느 노드(node)에 배치할지 결정하는 기능이 매우 중요하다.
이 작업을 바로 스케줄링(Scheduling) 이라고 한다.
스케줄링은 다음을 결정한다:
- 어떤 노드에 Pod를 생성할지
- 노드의 자원 상황(CPU·메모리)을 고려해 적절히 분배할지
- 특정 컨테이너는 SSD를 가진 빠른 노드에 배치할지
- 장애가 발생해도 가용성을 유지하기 위해 Pod를 여러 노드에 분산할지
즉, 컨테이너를 최적의 노드에 배치하는 전체 과정이 스케줄링이다.
🟩 스케줄링 과정 요약
-
사용자가 Pod를 생성 요청
-
ServiceAccount, Role, RoleBinding 등 인증/권한 검증
-
AdmissionController 가
- ResourceQuota
- LimitRange
- 기타 정책
을 확인하여 Pod 생성이 가능한지 판단
-
검증 통과 시 Pod가 “스케줄링 대기 상태”에 놓임
-
kube-scheduler가 모든 노드를 탐색 후
→ 가장 조건이 맞는 노드에 Pod를 배치 -
최종적으로 kubelet이 해당 노드에서 컨테이너 실행
🟨 내부 동작 구성 요소
-
kube-apiserver
모든 요청의 입구. 인증·권한·검증 처리. -
etcd
클러스터 상태 저장소. 어떤 Pod가 어디에 있는지 등의 정보를 저장함. -
kube-scheduler
실제로 “어떤 노드에 Pod를 배치할지"를 결정하는 핵심 스케줄러.
🟧 한 줄 요약
스케줄링은 컨테이너를 어느 노드에 배치할지 결정하는 과정이며, kube-scheduler가 모든 노드의 상태를 고려해 가장 적합한 노드에 Pod를 자동으로 배치한다.
Node Affinity를 이용한 스케줄링 정리
1️⃣ nodeSelector vs Node Affinity
- 위의 YAML처럼
nodeSelector를 사용하면
특정 라벨을 가진 노드에만 Pod를 스케줄링할 수 있다. - 하지만 단순히
키:값형태 라벨만으로 노드를 선택하면
조건을 세밀하게 주기 어렵고, 활용성이 떨어진다. - 그래서 쿠버네티스에서는 더 유연한 방식인 Node Affinity 스케줄링을 제공한다.
2️⃣ Node Affinity란?
-
Node Selector 기능을 확장한 라벨 기반 노드 선택 방법이다.
-
단순 “이 라벨을 가진 노드만”이 아니라,
- 반드시 만족해야 하는 조건(하드 조건)
- 가능하면 만족했으면 하는 조건(소프트 조건)
을 나눠서 설정할 수 있다.
3️⃣ Node Affinity의 두 가지 유형
-
하드 조건 (필수 조건)
requiredDuringSchedulingIgnoredDuringExecution- 스케줄링 시 반드시 만족해야 하는 조건
- 조건을 만족하는 노드가 없으면 Pod가 스케줄되지 않음
-
소프트 조건 (선호 조건)
preferredDuringSchedulingIgnoredDuringExecution- 조건을 만족하는 노드를 우선적으로 선택
- 없으면 다른 노드에도 스케줄링할 수 있음
4️⃣ 한 줄 정리
Node Affinity는 Node Selector보다 더 정교하게
“어떤 노드에 Pod를 배치할지”를 제어하기 위해
필수 조건 + 선호 조건을 라벨 기반으로 설정하는 스케줄링 방식이다.
노드를 선택 => 스케쥴
그리고 몇 가지 종류가 있다.
🟦 Taint(테인트) 정리 — 보기 좋게 구성
Pod 스케줄링에서 Label과 NodeSelector는
“이 노드에 배치되면 좋겠다”라는 선택 기준을 제공한다.
반면, Taint(테인트) 는 그 반대로 작동한다.
🟩 Taint란?
Taint는 특정 노드로의 Pod 배치를 막기 위한 설정이다.
노드에 Taint를 설정해두면,
해당 Taint를 허용(Toleration) 하지 않는 Pod는 절대 그 노드에 스케줄링되지 않는다.
즉:
- Label / Affinity → 이 노드에 배치하고 싶다
- Taint → 이 노드에는 배치하지 마라
이런 차이가 있다.
🟨 Taint와 Toleration 관계
- Taint = 노드에 적용되는 차단 규칙
- Toleration = Pod가 Taint를 “허용”하는 예외 규칙
Pod에 Toleration이 지정되어 있으면
해당 Taint가 있어도 그 노드에서 실행될 수 있다.
🟧 예시로 이해하기
✔ master 노드에 Pod가 스케줄링되지 않게 하려면?
master 노드에 다음과 같은 Taint를 설정:
kubectl taint nodes master node-role.kubernetes.io/master=:NoSchedule→ Toleration이 없는 Pod들은
master 노드에 절대 배치되지 않음.
🟥 한 줄 요약
Taint는 노드에서 Pod를 쫓아내거나 막는 규칙이며,
Toleration은 그 규칙을 예외적으로 허용하는 설정이다.
(대표적인 동작: NoSchedule)
🟦 Cordon, Drain, 그리고 PodDisruptionBudget(PDB)
노드를 업데이트하거나 점검해야 할 때,
해당 노드의 Pod를 안전하게 이동시키고 스케줄링을 비활성화하는 과정에서
cordon, drain, PDB가 사용된다.
🟩 1. cordon — 노드 스케줄링 비활성화
cordon 명령은 해당 노드에 앞으로 새로운 Pod가 배치되지 않도록
노드를 “스케줄 불가(NotSchedulable)” 상태로 만든다.
예)
kubectl cordon worker01→ worker01 노드에는 새로운 Pod가 더 이상 스케줄되지 않음
→ 단, 이미 실행 중인 Pod는 그대로 실행됨
핵심: “더 이상 새로운 Pod는 못 들어오게 막음”
🟧 2. drain — 기존 Pod까지 모두 퇴거(Eviction)
drain 명령은 노드를 완전히 비우기 위해
해당 노드의 Pod들을 다른 노드로 이동(Eviction) 시킨다.
kubectl drain worker01동작 방식
- DaemonSet, Static Pod 제외한 대부분의 Pod가 다른 노드로 옮겨짐
- 노드는 클러스터에서 일시적으로 제외됨
- 노드 유지보수, 업그레이드 시 사용하는 명령
🟦 3. uncordon — 노드를 다시 사용 가능하게
유지보수 후 노드를 다시 클러스터에 복귀시키려면:
kubectl uncordon worker01→ worker01이 정상 노드로 돌아오고,
다시 새로운 Pod가 스케줄링될 수 있음.
🟨 4. PodDisruptionBudget(PDB)
Drain 시 Pod가 너무 많이 빠지면 서비스 장애가 날 수 있다.
PDB(PodDisruptionBudget) 는 “최소 몇 개의 Pod는 반드시 유지되어야 한다”는 정책을 설정하여
Drain / Eviction 시 안정성을 보장한다.
예: replicas=3인 Deployment에서 최소 2개는 살아있게 하고 싶을 때
🟧 한 줄 정리
Cordon = 새로운 Pod 스케줄링 차단
Drain = 기존 Pod도 전부 다른 노드로 이동
Uncordon = 노드를 다시 활성화
PDB = Drain 시 서비스 중단 방지(최소 Pod 유지 정책)
Rolling Update 정리
1️⃣ Rolling Update가 필요한 이유
- 실제 운영 환경에서는 Pod를 직접 하나씩 만들기보다는 Deployment를 사용한다.
- Deployment의 설정(이미지 버전, 환경변수 등)을 변경하면
새로운 ReplicaSet이 생성되고, 이에 따라 새 버전의 Pod가 점진적으로 배포된다. - 이때
--record옵션을 쓰면 변경 이력이 남아서
나중에 이전 버전 ReplicaSet으로 롤백(Rollback) 하기 쉽다.
2️⃣ Rolling Update의 동작 방식
쿠버네티스에서는 일정 수의 Pod를 유지하면서 순차적으로 업데이트하는 방식을 사용한다.
예를 들어:
-
nginxDeployment에replicas=3으로 설정 -
nginx Pod가 3개 떠 있는 상태에서 이미지를 새 버전으로 변경하면,
- 한 번에 4~5개 정도까지 잠깐 늘어났다 줄어들 수 있지만,
- 전체 3개의 Pod 수는 거의 유지되도록 하면서
- 기존 Pod 하나를 종료 → 새 버전 Pod 하나 생성 식으로
순차 업데이트가 진행된다.
-
이 과정에서 서비스는 계속 살아 있으므로 HA(고가용성) 이 유지된다.
3️⃣ 특징 정리
- Pod를 한꺼번에 내렸다 올리는 것이 아니라, 조금씩 교체하기 때문에
서비스 중단 시간이 거의 없다. - 특정 시점에는 이전 버전과 새 버전 Pod가 동시에 존재할 수 있지만
이는 매우 짧은 순간이며, 실제 운영상 문제는 거의 없다.
🔚 한 줄 요약
Rolling Update는 Deployment를 업데이트할 때, 서비스 중단 없이 Pod를 순차적으로 새 버전으로 교체하는 방식이다.
🟦 애플의 상태 검사를 위한 LivenessProbe, ReadinessProbe, StartupProbe
Pod가 Running 상태가 되기 위해서는
- Init 컨테이너 실행
- postStart 실행
- 메인 컨테이너 정상 구동
이 모두 문제없이 진행되어야 한다.
이 과정 중 값이 비정상이라면 Kubernetes는 Probe를 통해 Pod의 상태를 확인하고,
필요하면 재시작시키거나 트래픽 전달을 막아 서비스 안정성을 보장한다.
🟩 Probe 종류별 설명
| 종류 | 설명 |
|---|---|
| livenessProbe | 컨테이너 내부 애플이 살아있는지(정상 작동 중인지) 검사. 이 검사에 실패하면 restartPolicy 에 따라 컨테이너가 재시작됨. |
| readinessProbe | 컨테이너가 서비스 요청을 받을 준비가 되었는지 검사. 실패 시 해당 Pod는 Service 엔드포인트에서 제외되어 트래픽을 받지 않는다. |
| startupProbe | 애플이 시작되는 데 시간이 오래 걸리는 경우에 사용. startupProbe가 먼저 통과해야 livenessProbe/readinessProbe가 활성화됨. 실패하면 restartPolicy에 따라 재시작됨. |
🟧 핵심 비교 요약
- livenessProbe
→ 살아있는지 여부 체크. 실패하면 컨테이너 재시작 - readinessProbe
→ 준비됐는지 체크. 실패하면 트래픽 전달 중단 - startupProbe
→ 느린 앱의 초기 구동 안정화용. 성공 후에야 다른 Probe 작동 시작
🟦 CRD (Custom Resource Definition)
Kubernetes에서는 사용자가 직접 새로운 리소스 타입을 정의할 수 있으며,
이때 사용하는 객체가 CRD(Custom Resource Definition) 이다.
예를 들어, Redis를 crd 형태의 리소스로 만들었다면,
사용자는 다음과 같이 Redis 커스텀 리소스를 생성하여 컨트롤러가 자동으로 관리하도록 만들 수 있다.
CRD 동작 방식
- 먼저 개발자가 Redis 구조를 정의한 CRD를 생성
- Kubernetes API에 새로운 리소스 타입이 등록됨
- 사용자는 이 CRD에 맞는 Custom Resource(예: RedisCluster)를 생성
- Custom Controller가 이 정보를 읽어 Deployment, Service 등을 자동으로 생성
즉,
CRD = 새로운 리소스 타입 정의
Custom Resource = 그 타입의 객체 생성
이라고 이해하면 쉽다.
🟦 Jobs와 CronJob
🟩 1. Job
Job은 “특정 작업을 수행한 뒤 종료되어야 하는 작업”을 위한 K8s 객체이다.
Deployment처럼 계속 실행되는 서비스용이 아니라,
한 번 실행 → 정상 종료(Completed) → 끝
이 목적이다.
Job은 다음과 같은 작업에 적합하다:
- 데이터 변환
- DB 마이그레이션
- 파일 처리
- 백업 스크립트 실행
Job이 생성되면 Pod가 실행되고,
해당 Pod가 정상적으로 작업을 끝내 0을 반환하면
Pod 상태가 Completed가 된다.
즉,
Job = “성공적으로 끝났는지 확인하고 종료시키는 실행 단위”
🟧 2. CronJob
CronJob은 Job을 일정 주기로 실행시키는 K8s 객체이다.
UNIX/Linux의 Cron 개념과 동일하며,
*/5 * * * * 같은 스케줄 표현식으로 실행 시간을 정의한다.
CronJob의 특징:
- 정해진 스케줄마다 Job 생성
- Job이 생성되면 Pod 실행 → 완료되면 종료
- 반복적으로 실행되어야 하는 작업에 적합
예)
- 매일 새벽 3시마다 백업 실행
- 10분마다 로그 정리 Job 실행
- 주기적 ETL 작업 실행
🟨 한 줄 요약
- Job = 한 번 실행 후 끝나야 하는 작업
- CronJob = Job을 일정 주기로 반복 실행시키는 작업 스케줄러
🟦 DaemonSet (데몬셋)
DaemonSet은 쿠버네티스 클러스터의 모든 노드(또는 지정된 노드)에 동일한 Pod를 하나씩 자동으로 배포하는 오브젝트이다.
노드가 추가되면 자동으로 해당 노드에도 Pod가 생성되고,
노드가 삭제되면 그 노드의 DaemonSet Pod도 함께 삭제된다.
🟩 DaemonSet이 필요한 이유
DaemonSet은 주로 노드마다 실행되어야 하는 에이전트(Container) 를 배포할 때 사용한다.
대표적인 활용 예:
- 로그 수집 에이전트
(예: Fluentd, Filebeat) - 모니터링 에이전트
(예: Prometheus Node Exporter) - 네트워킹 구성 요소
(예: kube-proxy, CNI plugin) - 보안/감사 에이전트
즉,
“각 노드마다 반드시 실행되어야 하는 Pod” → DaemonSet으로 배포해야 한다.
🟧 한 줄 요약
DaemonSet = 클러스터 내 모든 노드에서 동일한 Pod를 자동으로 실행시키는 오브젝트
노드 단위 로깅·모니터링·네트워킹 에이전트 배포에 필수적이다.
