Kubernetes 컨테이너 오케스트레이션 기초 (r1)

Pod는 Kubernetes에서 배포하고 관리할 수 있는 가장 작은 배포 단위이다. 하나 이상의 컨테이너 그룹으로 구성되며, 이 컨테이너들은 스토리지와 네트워크를 공유하고 같은 생명 주기를 갖는다. Pod는 단일 호스트(노드)에 배치되며, Pod 내의 컨테이너들은 항상 함께 스케줄링, 실행, 중지된다.

Pod의 주요 목적은 긴밀하게 결합된 애플리케이션 컨테이너들을 하나의 단위로 지원하는 것이다. 예를 들어, 주 애플리케이션 컨테이너와 로그 수집기, 또는 데이터 싱크를 위한 사이드카 컨테이너를 함께 묶어 배포할 수 있다. Pod 내 컨테이너들은 localhost를 통해 서로 통신할 수 있으며, 볼륨이라는 공유 스토리지도 사용할 수 있다.

Pod는 기본적으로 일시적이고 교체 가능한 엔티티로 설계되었다. Pod는 직접 생성되기보다는 Deployment나 StatefulSet과 같은 상위 수준의 컨트롤러를 통해 관리되는 경우가 일반적이다. 이러한 컨트롤러는 지정된 수의 Pod 복제본을 유지하며, Pod가 실패하면 자동으로 새로운 Pod를 생성한다.

Pod의 상태와 사양은 다음과 같은 주요 필드로 정의된다.

Pod 내 각 컨테이너는 도커 또는 containerd와 같은 컨테이너 런타임에 의해 실행된다. 컨테이너는 애플리케이션 프로세스 자체를 캡슐화하며, Pod는 이 컨테이너들을 실행하기 위한 공유 환경(네트워크 네임스페이스, IPC 네임스페이스 등)을 제공한다.

Deployment는 쿠버네티스에서 스테이트리스 애플리케이션을 배포하고 관리하기 위한 핵심 객체이다. 주된 목적은 애플리케이션의 원하는 상태를 선언하고, 해당 상태를 유지하도록 Pod 집합의 라이프사이클을 관리하는 것이다. 사용자는 YAML 매니페스트 파일에 원하는 Pod 템플릿, 복제본 수, 업데이트 정책 등을 정의한다. Deployment는 이 선언된 명세를 바탕으로 실제 상태를 조정하며, 롤링 업데이트나 롤백과 같은 무중단 배포 전략을 쉽게 구현할 수 있게 해준다.

Deployment는 내부적으로 ReplicaSet을 생성하고 관리함으로써 이러한 기능을 수행한다. ReplicaSet의 핵심 목표는 지정된 수의 동일한 Pod 복제본이 항상 실행되도록 보장하는 것이다. Pod 템플릿과 원하는 복제본 수를 정의하면, ReplicaSet은 해당 Pod를 생성하고 모니터링한다. 만약 Pod가 실패하거나 삭제되면, ReplicaSet은 새로운 Pod를 자동으로 생성하여 원하는 복제본 수를 유지한다.

Deployment와 ReplicaSet의 관계는 다음과 같이 요약할 수 있다.

예를 들어, 사용자가 nginx 이미지를 사용하는 Deployment를 생성하고 복제본을 3개로 지정하면, 쿠버네티스는 먼저 해당 명세를 가진 ReplicaSet을 생성한다. 그 후 ReplicaSet이 3개의 nginx Pod를 실행한다. 사용자가 컨테이너 이미지를 업데이트하는 새로운 Deployment 명세를 적용하면, Deployment는 새로운 Pod 템플릿을 가진 새로운 ReplicaSet을 생성하고, 이전 ReplicaSet의 Pod를 점진적으로 줄이면서 새로운 ReplicaSet의 Pod를 점진적으로 증가시킨다[1]. 이로써 서비스 중단 없이 배포가 이루어진다.

서비스는 파드 집합에 대한 안정적인 네트워크 엔드포인트를 제공하는 추상화 계층이다. 파드는 일시적이며 IP 주소가 변경될 수 있기 때문에, 클라이언트 애플리케이션이 특정 파드의 IP에 직접 의존하는 것은 신뢰할 수 없다. 서비스는 고정된 IP 주소와 DNS 이름을 부여하여, 해당 서비스를 구성하는 파드들에 대한 로드 밸런싱된 트래픽을 전달한다. 서비스의 주요 유형으로는 클러스터 내부에서만 접근 가능한 ClusterIP, 단일 노드의 포트를 노출하는 NodePort, 그리고 클라우드 공급자의 로드 밸런서를 생성하는 LoadBalancer가 있다.

인그레스는 클러스터 외부의 HTTP/HTTPS 트래픽을 내부 서비스로 라우팅하는 API 오브젝트이다. 서비스의 LoadBalancer 타입은 각 서비스마다 외부 로드 밸런서를 필요로 하는 반면, 인그레스는 하나의 진입점을 통해 여러 서비스에 대한 라우팅 규칙을 중앙에서 관리할 수 있다. 인그레스는 호스트 이름, URL 경로 등을 기반으로 트래픽을 적절한 백엔드 서비스로 전달한다. 인그레스 자체는 트래픽을 처리하지 않으며, 규칙을 구현하는 인그레스 컨트롤러가 필요하다. 대표적인 인그레스 컨트롤러로는 NGINX Ingress Controller, Traefik 등이 있다.

서비스와 인그레스의 관계는 다음과 같이 정리할 수 있다.

간단한 웹 애플리케이션의 경우, 애플리케이션 파드들을 위한 ClusterIP 타입의 서비스를 생성하고, 외부 사용자를 위한 인그레스 리소스를 추가하여 example.com/app 경로의 트래픽을 해당 서비스로 전달하도록 구성한다. 이렇게 함으로써 내부 네트워크 토폴로지와 외부 접근 방식을 독립적으로 관리하고 유연성을 확보할 수 있다.

ConfigMap은 키-값 쌍 형태로 구성 데이터를 저장하는 쿠버네티스 오브젝트이다. 애플리케이션의 설정 파일, 환경 변수, 명령줄 인수와 같은 비기밀성 데이터를 컨테이너화된 애플리케이션과 분리하는 데 사용된다. 이를 통해 동일한 애플리케이션 이미지를 다양한 환경(개발, 스테이징, 프로덕션)에 배포할 때 설정만 변경하여 재사용성을 높일 수 있다. ConfigMap은 Pod에 마운트된 볼륨으로 제공되거나, 컨테이너의 환경 변수로 주입될 수 있다.

Secret은 암호, OAuth 토큰, SSH 키와 같은 민감한 정보를 저장하기 위해 설계된 오브젝트이다. Secret은 데이터를 Base64로 인코딩하여 평문 저장을 피하며, etcd 저장소에서 암호화된 상태로 보관될 수 있다[2]. ConfigMap과 유사하게 Pod에 볼륨으로 마운트하거나 환경 변수로 참조할 수 있지만, 접근 권한을 더 엄격하게 관리해야 한다.

두 리소스 모두 YAML 매니페스트를 통해 선언적으로 생성하고 관리한다. 주요 차이점과 사용 예시는 다음 표와 같다.

ConfigMap과 Secret을 사용할 때는 데이터 크기 제한(약 1MB)을 고려해야 하며, Secret의 Base64 인코딩은 보안 기능이 아닌 바이너리 데이터 호환을 위한 것임을 인지해야 한다. 민감도가 높은 데이터는 외부 시크릿 관리 시스템과 연동하는 것이 더 안전할 수 있다.

마스터 노드는 쿠버네티스 클러스터의 두뇌 역할을 하며, 클러스터의 상태를 관리하고 제어하는 핵심 구성 요소들을 실행하는 서버 또는 서버 그룹이다. 이 노드는 일반적으로 애플리케이션 워크로드를 직접 실행하지 않으며, 클러스터의 관리와 조정에 전념한다. 주요 구성 요소로는 kube-apiserver, etcd, kube-scheduler, kube-controller-manager가 있다.

kube-apiserver는 유일하게 etcd와 직접 통신하는 구성 요소이며, 클러스터 상태에 대한 모든 변경은 반드시 이를 통해 이루어진다. kube-controller-manager는 단일 바이너리로 실행되지만, 내부적으로 노드 컨트롤러, 레플리케이션 컨트롤러, 엔드포인트 컨트롤러 등 여러 컨트롤러 프로세스를 포함한다. 고가용성 클러스터를 구성할 경우, 이러한 마스터 구성 요소들은 여러 서버에 걸쳐 중복 실행되어 단일 장애 지점을 제거한다.

워커 노드는 Kubernetes 클러스터에서 실제 컨테이너 워크로드를 실행하는 머신(가상 또는 물리적)이다. 이 노드는 파드를 호스팅하고, 컨테이너 런타임을 제공하며, 네트워크 및 스토리지 리소스를 관리하는 여러 핵심 구성 요소를 포함한다. 각 워커 노드는 컨트롤 플레인의 지시를 받아 애플리케이션을 구동하는 책임을 진다.

워커 노드의 핵심 구성 요소는 다음과 같다.

kubelet은 노드의 상태와 리소스 사용량을 컨트롤 플레인에 지속적으로 보고한다. kube-proxy는 운영 체제의 패킷 필터링 계층(예: iptables 또는 IPVS)을 사용하여 트래픽 라우팅을 처리한다. 또한, 워커 노드는 애플리케이션 데이터를 영구적으로 저장하기 위해 로컬 스토리지나 네트워크 스토리지 볼륨을 마운트할 수 있다.

Kubernetes 클러스터의 아키텍처는 크게 컨트롤 플레인과 데이터 플레인이라는 두 개의 논리적 영역으로 구분된다. 이 구분은 시스템의 책임과 기능을 명확히 분리한다. 컨트롤 플레인은 클러스터의 두뇌 역할을 하며, 전체 상태를 관리하고 의사 결정을 내린다. 반면 데이터 플레인은 실제 컨테이너 워크로드를 실행하고 네트워크 트래픽을 처리하는 실행부 역할을 담당한다.

컨트롤 플레인은 주로 마스터 노드에 위치하는 구성 요소들로 이루어진다. 핵심 구성 요소로는 클러스터 상태를 저장하는 etcd, API 요청을 처리하는 kube-apiserver, 스케줄링 결정을 내리는 kube-scheduler, 그리고 의도한 상태를 유지하기 위해 컨트롤러를 운영하는 kube-controller-manager가 있다. 이들은 사용자가 정의한 YAML 매니페스트를 바탕으로 '의도한 상태'를 설정하고, 실제 상태가 이와 일치하도록 지속적으로 조정하는 작업을 수행한다. 컨트롤 플레인의 모든 통신은 kube-apiserver를 중심으로 이루어진다.

데이터 플레인은 워커 노드(또는 노드)에서 실행되는 구성 요소들로 구성된다. 각 노드에는 kubelet과 컨테이너 런타임(예: containerd, CRI-O), 그리고 kube-proxy가 필수적으로 설치되어 있다. kubelet은 해당 노드에서 Pod의 생명주기를 관리하는 에이전트이다. 컨테이너 런타임은 컨테이너를 실제로 실행하는 소프트웨어이다. kube-proxy는 Pod 간의 네트워크 통신을 가능하게 하는 네트워크 프록시 역할을 하며, Service 규칙을 관리한다.

이 두 플레인의 상호작용은 다음과 같이 요약할 수 있다.

사용자는 kubectl 명령어나 API를 통해 컨트롤 플레인에 명령을 전달한다. 컨트롤 플레인은 이 명령을 처리하고, 데이터 플레인의 구성 요소들에게 작업을 지시하여 최종적으로 애플리케이션이 원하는 상태로 배포되고 유지되도록 한다. 이 분리된 구조는 Kubernetes가 확장성과 견고성을 갖추는 데 기여한다.

쿠버네티스에서 애플리케이션과 리소스를 정의하는 가장 기본적인 방법은 YAML 형식의 매니페스트 파일을 사용하는 것이다. 이 파일은 선언적 방식으로 원하는 시스템 상태를 기술하며, 쿠버네티스 API 서버에 제출되어 실행된다. 모든 매니페스트는 몇 가지 필수 필드를 포함해야 한다. apiVersion은 사용하는 쿠버네티스 API의 버전을, kind는 생성하려는 리소스의 종류(예: Pod, Deployment, Service)를 지정한다. metadata는 이름, 네임스페이스, 라벨과 같은 리소스의 식별 정보를 담고 있으며, spec 섹션은 해당 리소스가 가져야 할 구체적인 상태와 설정을 정의한다.

일반적인 Deployment 매니페스트의 구조는 다음과 같다. spec 내부에는 replicas로 실행할 Pod의 복제본 수, selector로 이 Deployment가 관리할 Pod를 선택하는 기준, 그리고 template으로 생성될 Pod의 명세를 정의한다. template.spec 아래에는 Pod 안에서 실행될 하나 이상의 컨테이너 정보를 containers 배열로 나열한다. 각 컨테이너는 name과 image(도커 이미지)를 필수로 지정해야 한다.

작성 시 유의할 점은 들여쓰기에 민감한 YAML 문법을 정확히 지키고, 라벨(labels)과 셀렉터(selector)가 일치하도록 구성해야 한다는 것이다. 또한, 컨테이너의 환경 변수, 포트 설정, 리소스 요청 및 제한(resources.requests/limits) 등을 spec.containers 하위에 상세히 정의할 수 있다. 매니페스트 파일은 kubectl apply -f <파일명.yaml> 명령어를 통해 클러스터에 적용된다.

애플리케이션의 인스턴스 수를 조정하는 스케일링은 Deployment나 ReplicaSet의 replicas 필드 값을 변경하여 수행한다. 명령어 kubectl scale deployment/<배포명> --replicas=<숫자>로 즉시 적용하거나, 매니페스트 파일을 수정한 후 kubectl apply 명령어로 적용할 수 있다. Horizontal Pod Autoscaler를 구성하면 CPU 사용률이나 사용자 지정 메트릭에 따라 자동으로 Pod 수를 조정할 수 있다.

애플리케이션 업데이트는 주로 롤링 업데이트 전략을 통해 이루어진다. Deployment는 새 ReplicaSet을 생성하고, 새 Pod를 하나씩 생성하면서 기존 Pod를 순차적으로 제거한다. 이 방식은 다운타임 없이 서비스를 지속할 수 있게 한다. 업데이트 진행 상황은 kubectl rollout status deployment/<배포명> 명령으로 확인할 수 있다.

업데이트 중 문제가 발생하면 kubectl rollout undo deployment/<배포명> 명령을 실행하여 이전 정상 ReplicaSet 버전으로 빠르게 롤백할 수 있다. Deployment 기록을 통해 특정 리비전으로의 롤백도 가능하다. 업데이트 전략과 속도는 maxSurge(한 번에 추가 생성할 Pod 수)와 maxUnavailable(업데이트 중 사용 불가능하게 허용할 Pod 수) 매개변수로 세밀하게 제어할 수 있다.

헬스 체크는 Kubernetes가 Pod 내 컨테이너의 상태를 지속적으로 모니터링하고, 비정상적인 컨테이너를 자동으로 복구하거나 트래픽에서 제외하는 핵심 메커니즘이다. 이를 통해 애플리케이션의 가용성과 신뢰성을 높일 수 있다. Kubernetes는 주기적으로 컨테이너 상태를 진단하는 라이브니스 프로브와 서비스 요청을 보낼 준비가 되었는지 확인하는 레디니스 프로브, 그리고 애플리케이션의 초기 시작이 완료되었는지를 점검하는 스타트업 프로브를 제공한다.

각 프로브는 HTTP GET 요청, TCP 소켓 연결, 또는 컨테이너 내에서 명령어 실행 등 세 가지 핸들러 방식 중 하나로 정의된다. 프로브의 동작은 initialDelaySeconds, periodSeconds, timeoutSeconds, failureThreshold 등의 매개변수를 통해 세밀하게 조정할 수 있다. 예를 들어, 애플리케이션 시작에 시간이 오래 걸린다면 initialDelaySeconds 값을 늘려 초기 진단을 지연시킬 수 있다.

적절한 헬스 체크 구성은 시스템 안정성에 매우 중요하다. 라이브니스 프로브가 너무 민감하게 설정되면 불필요한 컨테이너 재시작이 빈번히 발생할 수 있으며, 반대로 둔감하면 장애 상태의 컨테이너가 계속 서비스될 위험이 있다. 레디니스 프로브는 데이터베이스 연결이나 외부 의존성 초기화가 완료되기 전까지 트래픽을 받지 않도록 하여 사용자 요청 실패를 방지한다.

컨테이너는 기본적으로 스테이트리스이며, 컨테이너가 재시작되면 디스크에 기록된 파일이 사라진다. 쿠버네티스는 컨테이너에 지속적인 데이터를 저장하고 공유할 수 있도록 볼륨 추상화를 제공한다. 볼륨은 Pod에 정의되며, Pod 내의 하나 이상의 컨테이너가 마운트하여 사용할 수 있다. 볼륨의 수명은 Pod와 연결되어 있어, Pod가 삭제되면 해당 볼륨의 데이터도 일반적으로 사라진다.

데이터를 영구적으로 보존하기 위해서는 PersistentVolume과 PersistentVolumeClaim 오브젝트를 사용한다. PersistentVolume은 관리자가 프로비저닝하거나 스토리지 클래스를 통해 동적으로 제공되는 클러스터의 스토리지 자원이다. 반면, PersistentVolumeClaim은 사용자가 특정 크기 및 접근 모드의 스토리지를 요청하는 선언문이다. 쿠버네티스 시스템은 Claim을 만족하는 PersistentVolume을 찾아 바인딩한다.

주요 볼륨 타입과 PersistentVolume의 접근 모드는 다음과 같다.

Pod는 PersistentVolume을 직접 참조하지 않으며, 항상 PersistentVolumeClaim을 통해 스토리지를 요청한다. 이 분리는 스토리지 제공 방식과 사용 방식을 분리하여 관리의 유연성을 제공한다. 관리자는 다양한 스토리지 백엔드를 PersistentVolume으로 제공하고, 개발자는 필요한 스토리지 용량과 성능만을 Claim으로 정의하여 애플리케이션에 사용한다.

스토리지 클래스는 쿠버네티스 클러스터에서 퍼시스턴트볼륨의 동적 프로비저닝을 가능하게 하는 리소스입니다. 사용자가 퍼시스턴트볼륨클레임을 생성하면, 스토리지 클래스는 지정된 프로비저너와 파라미터를 기반으로 자동으로 적절한 스토리지를 생성하고 바인딩합니다. 이는 관리자가 수동으로 퍼시스턴트볼륨을 미리 생성하고 관리해야 하는 번거로움을 크게 줄여줍니다.

각 스토리지 클래스는 provisioner, parameters, reclaimPolicy 등의 필드를 정의합니다. provisioner는 사용할 스토리지 백엔드(예: kubernetes.io/aws-ebs, kubernetes.io/gce-pd)를 결정합니다. parameters는 프로비저너에 따라 다른 설정값을 제공하며, 예를 들어 볼륨 유형, IOPS, 암호화 여부 등을 지정할 수 있습니다. reclaimPolicy는 PVC가 삭제된 후 PV를 어떻게 처리할지(Retain, Delete, Recycle) 정의합니다.

다음은 주요 클라우드 공급자별 일반적인 스토리지 클래스 프로비저너의 예시입니다.

클러스터 관리자는 애플리케이션의 성능, 가용성, 비용 요구사항에 맞게 다양한 스토리지 클래스를 정의할 수 있습니다. 예를 들어, fast 클래스는 SSD를 사용하고 slow 클래스는 표준 HDD를 사용하도록 설정할 수 있습니다. 개발자는 PVC 매니페스트에서 storageClassName 필드를 지정함으로써 원하는 스토리지 클래스를 간단히 선택하여 사용합니다. 이를 통해 스토리지 인프라의 세부 사항을 추상화하고, 애플리케이션 코드 변경 없이 유연하게 스토리지 백엔드를 교체하거나 업그레이드할 수 있습니다.

쿠버네티스 클러스터 내부 통신은 파드와 서비스를 중심으로 이루어집니다. 각 파드는 고유한 IP 주소를 할당받지만, 파드는 일시적이므로 직접 IP 주소로 통신하는 것은 권장되지 않습니다. 대신, 고정된 DNS 이름을 제공하는 서비스 객체가 파드 집합에 대한 안정적인 네트워크 엔드포인트 역할을 합니다. 서비스는 선택기(Selector)를 통해 특정 레이블을 가진 파드들을 타겟으로 지정하며, 클러스터 내부의 DNS 서버(CoreDNS)는 서비스 이름을 해당 클러스터 IP로 자동으로 변환해줍니다.

클러스터 네트워킹 모델은 몇 가지 기본 요구사항을 충족시킵니다. 모든 파드는 IP 주소를 가지며 다른 모든 파드와 NAT 없이 통신할 수 있어야 합니다(IP-per-Pod 모델). 모든 노드도 모든 파드와 통신할 수 있어야 합니다. 이러한 모델을 구현하기 위해 CNI 플러그인(Calico, Flannel, Cilium 등)이 사용됩니다. 이 플러그인들은 파드 IP 할당, 노드 간 네트워크 라우팅 구성을 담당하여 복잡한 네트워크 인프라를 추상화합니다.

서비스의 주요 타입과 내부 통신 방식을 비교하면 다음과 같습니다.

예를 들어, my-app이라는 서비스가 default 네임스페이스에 있다면, 동일한 클러스터 내의 다른 파드는 my-app.default.svc.cluster.local 이라는 도메인 이름으로 이 서비스에 연결할 수 있습니다. Headless 서비스는 클러스터 IP가 없으며, DNS 쿼리를 수행하면 해당 서비스에 속한 파드들의 IP 주소 목록이 반환되어, 스테이트풀셋과 같은 워크로드에서 피어 디스커버리에 활용됩니다.

서비스 오브젝트는 파드 집합에 대한 안정적인 네트워크 엔드포인트를 제공하는 주요 방법이다. 특히 LoadBalancer 타입의 서비스를 생성하면, 대부분의 클라우드 공급자는 자동으로 외부 로드 밸런서를 프로비저닝하고 해당 서비스에 공인 IP를 할당한다. 이 IP를 통해 클러스터 외부에서 애플리케이션에 접근할 수 있다. NodePort 타입은 각 워커 노드의 특정 포트를 열어, 해당 노드의 IP와 포트로의 접근을 허용한다.

보다 복잡한 HTTP/HTTPS 라우팅 요구사항을 처리하기 위해 인그레스 리소스를 사용한다. 인그레스는 클러스터 내부 서비스에 대한 외부 접근을 관리하는 API 오브젝트로, 호스트 기반 또는 경로 기반 라우팅 규칙을 정의할 수 있다. 인그레스 규칙을 실제로 구현하려면 인그레스 컨트롤러가 필요하다. 널리 사용되는 인그레스 컨트롤러로는 NGINX, Traefik, HAProxy 등이 있다.

인그레스를 구성할 때는 TLS 보안 연결을 설정하는 것이 일반적이다. 이는 인그레스 매니페스트에 시크릿 오브젝트로 저장된 TLS 인증서와 키를 참조하여 이루어진다. 인그레스 컨트롤러는 이를 통해 들어오는 HTTPS 트래픽의 TLS 연결을 종료한다. 또한, 특정 애플리케이션은 NodePort 서비스와 외부 로드 밸런서를 조합하거나, 서비스 메시 솔루션의 게이트웨이를 활용하는 등 하이브리드 방식으로 외부 접근을 구성하기도 한다.

RBAC은 쿠버네티스 클러스터 내에서 사용자, 파드, 서비스 계정 등이 가진 권한을 세밀하게 관리하기 위한 접근 제어 메커니즘이다. 이는 "누가(Who) 어떤 자원(What)에 대해 어떤 행동(How)을 할 수 있는지"를 정의하는 규칙을 기반으로 한다. RBAC를 사용하면 관리자는 특정 네임스페이스나 클러스터 전체에 대해 역할을 생성하고, 그 역할에 권한을 부여한 후, 사용자나 그룹에게 역할을 할당하는 방식으로 권한을 제어한다. 이는 모든 사용자에게 동일한 관리자 권한을 부여하는 방식보다 훨씬 안전한 보안 모델을 제공한다.

RBAC의 주요 구성 요소는 Role, ClusterRole, RoleBinding, ClusterRoleBinding이다. Role과 ClusterRole은 실제 수행할 수 있는 권한(예: 파드 생성, 조회, 삭제)의 집합을 정의한다. Role은 특정 네임스페이스 내에서만 유효한 반면, ClusterRole은 클러스터 전체에 걸쳐 적용된다. RoleBinding과 ClusterRoleBinding은 정의된 Role 또는 ClusterRole을 특정 사용자, 그룹, 또는 서비스 어카운트에 연결(bind)하는 역할을 한다. RoleBinding은 네임스페이스 범위의 Role이나 ClusterRole을 바인딩할 수 있으며, ClusterRoleBinding은 클러스터 전체 범위의 ClusterRole을 바인딩한다.

권한 설정은 YAML 매니페스트를 통해 이루어진다. 아래는 monitoring 네임스페이스에서 파드와 ConfigMap을 조회할 수 있는 Role과, 이를 특정 서비스 계정에 바인딩하는 RoleBinding의 예시이다.

RBAC를 효과적으로 운영하기 위해서는 최소 권한의 원칙을 따르는 것이 중요하다. 즉, 각 사용자나 애플리케이션에게 작업을 수행하는 데 필요한 최소한의 권한만 부여해야 한다. 또한, 사전 정의된 cluster-admin, edit, view와 같은 클러스터롤을 상황에 맞게 활용할 수 있다. 정기적으로 역할과 바인딩을 감사(audit)하여 불필요하거나 과도한 권한이 부여되지 않았는지 확인하는 것도 좋은 보안 관행이다.

네트워크 정책은 Kubernetes 클러스터 내 Pod 간의 네트워크 트래픽을 제어하는 규칙 집합이다. 파이어월과 유사한 기능을 제공하여, 특정 Pod 그룹이 서로 통신할 수 있는 방법을 정의한다. 기본적으로 대부분의 Kubernetes 클러스터는 모든 Pod 간의 통신을 허용하지만, 네트워크 정책을 적용하면 "기본 거부" 모델로 전환하여 명시적으로 허용된 트래픽만 흐르도록 할 수 있다. 이는 마이크로서비스 아키텍처에서 애플리케이션 계층을 분리하거나, 민감한 구성 요소를 격리하는 데 필수적인 보안 도구이다.

네트워크 정책은 YAML 매니페스트로 정의하며, 주요 규칙은 Ingress(수신)와 Egress(송신) 방향으로 구성된다. 각 규칙은 트래픽을 허용할 소스(PodSelector, NamespaceSelector, IPBlock)와 대상 포트를 지정한다. 예를 들어, 특정 레이블을 가진 Pod들만 데이터베이스 Pod의 3306 포트로의 트래픽을 허용하는 정책을 작성할 수 있다. 네트워크 정책의 동작은 CNI 플러그인에 의해 구현되므로, 클러스터의 네트워크 솔루션(예: Calico, Cilium, Weave Net)이 네트워크 정책을 지원해야 한다.

다음은 기본적인 네트워크 정책의 예시이다. 이 정책은 role: db 레이블을 가진 모든 Pod에 적용되어, role: api 레이블을 가진 Pod로부터의 6379 포트 TCP 트래픽만 허용한다.

```yaml

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: allow-api-to-db

spec:

podSelector:

matchLabels:

role: db

policyTypes:

• Ingress

ingress:

• from:

• podSelector:

matchLabels:

role: api

ports:

• protocol: TCP

port: 6379

```

네트워크 정책은 기본적으로 네임스페이스 범위에서 작동하지만, 다른 네임스페이스의 Pod를 선택하는 규칙도 작성할 수 있다. 여러 정책이 하나의 Pod에 적용될 경우, 규칙은 추가적(누적적)으로 적용된다. 즉, 한 정책에서 허용한 트래픽은 다른 정책에 의해 거부되지 않는다. 효과적인 Zero Trust 보안 모델을 구축하려면, 애플리케이션의 각 구성 요소에 대해 필요한 최소한의 통신 경로만 허용하는 세분화된 네트워크 정책을 설계하는 것이 좋다.