Docker / Kubernetes 면접 질문

Docker는 애플리케이션과 그 실행에 필요한 모든 것(라이브러리, 설정 파일, 코드 등)을 컨테이너라는 표준화된 유닛으로 패키징하는 기술입니다. 이를 통해 개발, 배포, 실행 환경에 관계없이 일관된 방식으로 애플리케이션을 실행할 수 있습니다.

Docker와 가상 머신(VM)의 주요 차이점은 가상화 수준에 있습니다. VM은 하이퍼바이저를 통해 운영체제(OS) 전체를 가상화하는 반면, Docker는 컨테이너 엔진을 사용하여 호스트 OS의 커널을 공유하고 애플리케이션 프로세스만 격리합니다.

이러한 차이점 때문에 Docker 컨테이너는 VM보다 훨씬 가볍고 빠릅니다. VM은 게스트 OS를 부팅해야 하지만, Docker 컨테이너는 프로세스처럼 빠르게 시작됩니다. 또한, Docker는 VM보다 적은 리소스를 사용하므로 더 많은 컨테이너를 동일한 하드웨어에서 실행할 수 있습니다. 따라서 Docker는 애플리케이션 배포 및 관리를 효율적으로 만들어줍니다.

Docker Image와 Docker Container는 템플릿과 인스턴스의 관계라고 생각하시면 됩니다.

Docker Image는 애플리케이션을 실행하는 데 필요한 모든 것, 즉 코드, 라이브러리, 환경 변수, 설정 파일 등을 포함하는 읽기 전용의 정적인 템플릿입니다. 마치 소프트웨어를 설치하기 전의 설치 파일과 같죠.

Docker Container는 이 Image를 기반으로 실행되는 격리된 환경입니다. Image라는 템플릿을 가지고 실제로 애플리케이션을 실행하는 동적인 인스턴스라고 할 수 있습니다. 여러 개의 Container가 동일한 Image로부터 생성될 수 있으며, 각 Container는 독립적으로 실행됩니다.

간단히 말해, Image는 '무엇을' 실행할지에 대한 정의이고, Container는 그 정의를 바탕으로 '실제로 실행되는 것'입니다.

Dockerfile의 주요 역할은 Docker 이미지를 만들기 위한 설계도 역할을 하는 것입니다. 이미지에 필요한 운영체제, 라이브러리, 애플리케이션 코드, 설정 파일 등을 정의해 놓은 텍스트 파일이죠.

컨테이너 이미지를 빌드하는 과정은 다음과 같습니다. 먼저 Dockerfile을 작성하고, docker build 명령어를 사용하여 Dockerfile에 정의된 내용대로 이미지를 생성합니다. 이 과정에서 Docker는 Dockerfile의 각 명령어를 순서대로 실행하며, 각 명령어는 이미지 레이어를 생성합니다. 이렇게 레이어가 쌓여 최종적인 컨테이너 이미지가 만들어집니다. Dockerfile을 사용하면 이미지 빌드 과정을 자동화하고, 동일한 환경을 쉽게 구축할 수 있다는 장점이 있습니다.

Docker Volume을 사용하는 주된 이유는 컨테이너가 삭제되더라도 데이터를 영구적으로 보존하기 위해서입니다. 컨테이너는 일시적인 존재이기 때문에, 컨테이너 내부에 데이터를 저장하면 컨테이너가 삭제될 때 데이터도 함께 사라집니다. Volume을 사용하면 컨테이너와 독립적으로 데이터를 관리할 수 있습니다.

Bind Mount와 Volume의 주요 차이점은 데이터 저장 위치와 관리 주체입니다. Bind Mount는 호스트 파일 시스템의 특정 디렉토리를 컨테이너에 마운트하는 방식으로, 호스트 파일 시스템에 직접 연결됩니다. 반면 Volume은 Docker가 관리하는 별도의 영역에 데이터를 저장하며, 컨테이너와 독립적으로 관리됩니다. 따라서 Volume은 컨테이너 간 데이터 공유에 더 용이하고, 호스트 파일 시스템에 대한 의존성을 줄일 수 있습니다.

Docker Compose는 여러 개의 Docker 컨테이너로 이루어진 애플리케이션을 관리할 때 유용합니다. 예를 들어, 웹 서버, 데이터베이스, 캐시 서버 등 여러 컨테이너가 함께 작동해야 하는 경우에 Docker Compose를 사용하면 각 컨테이너의 설정과 의존성을 YAML 파일 하나로 정의하고 관리할 수 있습니다.

주요 기능으로는, YAML 파일을 기반으로 애플리케이션의 전체 구조를 정의하고, docker-compose up 명령어 하나로 모든 컨테이너를 한 번에 실행할 수 있다는 점입니다. 또한, 컨테이너 간의 네트워크 연결, 볼륨 공유, 환경 변수 설정 등을 쉽게 관리할 수 있으며, 컨테이너 실행 순서와 의존성을 정의하여 애플리케이션의 안정적인 실행을 보장합니다. 간단하게 말해, 복잡한 다중 컨테이너 환경을 쉽게 구축하고 관리할 수 있도록 도와주는 도구입니다.

Kubernetes는 컨테이너화된 애플리케이션을 배포, 관리, 확장하는 데 도움을 주는 오픈소스 플랫폼입니다. 컨테이너 오케스트레이션 도구라고도 불립니다.

컨테이너 오케스트레이션에서 Kubernetes는 다음과 같은 문제들을 해결해 줍니다.

• 배포 및 스케일링 자동화: 수동으로 컨테이너를 배포하고 확장하는 대신, Kubernetes는 이를 자동으로 처리하여 운영 효율성을 높입니다.
• 고가용성 확보: 컨테이너가 실패할 경우 자동으로 재시작하거나 복제본을 생성하여 애플리케이션의 가용성을 유지합니다.
• 로드 밸런싱: 트래픽을 여러 컨테이너에 분산시켜 애플리케이션의 성능을 향상시킵니다.
• 선언적 구성 관리: 원하는 상태를 정의하면 Kubernetes가 자동으로 해당 상태를 유지하도록 관리합니다. 예를 들어, "이 애플리케이션을 3개의 복제본으로 실행하라"고 설정하면 Kubernetes는 항상 3개의 복제본이 실행되도록 보장합니다.

Kubernetes에서 Pod는 애플리케이션을 실행하는 가장 작은 배포 단위입니다. 하나의 Pod는 하나 이상의 컨테이너 그룹과 해당 컨테이너들이 공유하는 스토리지 및 네트워크 리소스를 포함합니다.

Pod가 컨테이너의 최소 배포 단위인 이유는, 함께 실행되어야 하는 컨테이너들을 논리적으로 묶어 관리하기 위해서입니다. 예를 들어, 메인 애플리케이션 컨테이너와 로깅을 담당하는 사이드카 컨테이너는 같은 Pod에 속하게 됩니다. 이렇게 되면 Pod 내의 컨테이너들은 동일한 IP 주소와 포트 공간을 공유하며, localhost를 통해 서로 통신할 수 있습니다. 또한, 공유 볼륨을 통해 데이터를 쉽게 주고받을 수 있어 컨테이너 간의 긴밀한 협력이 가능해집니다. 이러한 추상화 덕분에 Kubernetes는 개별 컨테이너가 아닌 Pod 단위로 애플리케이션을 배포하고 관리할 수 있습니다.

멀티스테이지 빌드는 Docker 이미지 크기를 줄이고 빌드 속도를 높이는 데 핵심적인 기술입니다.

주된 목적은 개발/빌드 환경과 런타임 환경을 분리하여 최종 이미지에 불필요한 의존성이나 빌드 도구를 포함시키지 않는 것입니다. 예를 들어, Java 프로젝트를 빌드할 때 JDK가 필요하지만, 런타임에는 JRE만 있으면 됩니다. 멀티스테이지 빌드를 사용하면 JDK를 포함한 빌드 단계를 거친 후, JRE만 포함된 더 작은 이미지를 최종 결과물로 만들 수 있습니다.

이점으로는 이미지 크기 감소로 인한 배포 속도 향상, 보안 강화 (불필요한 도구 제거), 그리고 빌드 캐시 효율성 증대가 있습니다. 각 스테이지별로 캐싱이 가능하기 때문에, 코드 변경이 없는 의존성 설치 단계는 매번 반복하지 않아도 됩니다.

실제 프로젝트에서는, 프론트엔드 빌드 (npm install, build) 후 생성된 정적 파일만 Nginx 이미지에 복사하거나, Go 바이너리를 빌드한 후 scratch 이미지에 복사하는 방식으로 활용할 수 있습니다.

Docker 컨테이너 네트워크 모드는 컨테이너가 호스트 시스템의 네트워크와 어떻게 연결되는지를 정의합니다.

• Bridge 모드: 기본 모드이며, 각 컨테이너는 자체 네트워크 네임스페이스를 가지고 docker0 브리지에 연결됩니다. 컨테이너 간 통신은 가능하지만, 외부에서 접근하려면 포트 포워딩이 필요합니다. 격리 수준이 높지만, 포트 충돌 가능성이 있습니다.

• Host 모드: 컨테이너가 호스트의 네트워크 네임스페이스를 공유합니다. 성능은 가장 좋지만, 격리 수준이 낮고 포트 충돌 위험이 큽니다. 컨테이너가 호스트의 모든 네트워크 인터페이스에 직접 접근할 수 있습니다.

• None 모드: 컨테이너는 네트워크 인터페이스를 가지지 않습니다. 완전히 격리된 환경이 필요할 때 사용하며, 컨테이너 내부에서 네트워크 설정을 직접 구성해야 합니다.

• Overlay 모드: Docker Swarm이나 Kubernetes와 같은 클러스터 환경에서 컨테이너 간 통신을 위해 사용됩니다. 여러 호스트에 걸쳐 있는 컨테이너들이 하나의 가상 네트워크를 공유할 수 있게 해줍니다.

각 모드는 격리 수준, 성능, 네트워크 구성의 복잡성 측면에서 트레이드오프 관계를 가집니다. 어떤 모드를 선택할지는 애플리케이션의 요구사항과 보안 고려사항에 따라 달라집니다.

네, Docker에서 데이터를 영속적으로 저장하는 Volume과 Bind Mount는 모두 유용한 방법이지만, 데이터 관리 방식과 사용 시나리오에서 차이가 있습니다.

Bind Mount는 호스트 파일 시스템의 특정 디렉토리를 컨테이너에 마운트하는 방식입니다. 간단하고 빠르지만, 컨테이너와 호스트 시스템 간의 의존성이 높아져 이식성이 떨어집니다. 예를 들어, 개발 환경에서 소스 코드를 컨테이너에 바로 마운트하여 실시간으로 변경 사항을 반영할 때 유용합니다.

반면, Volume은 Docker가 관리하는 별도의 저장 공간을 사용합니다. 컨테이너와 호스트 파일 시스템 간의 의존성이 낮고, 컨테이너가 삭제되어도 데이터가 유지됩니다. 또한, 여러 컨테이너 간에 데이터를 공유하기에도 용이합니다. 데이터베이스와 같이 컨테이너의 라이프사이클과 독립적으로 유지되어야 하는 데이터를 저장할 때 적합합니다. Volume은 Docker에게 데이터 관리를 맡기고 싶을 때, Bind Mount는 호스트 시스템의 파일을 직접 공유하고 싶을 때 선택하는 것이 좋습니다.

Docker Compose에서 depends_on, networks, volumes는 컨테이너 오케스트레이션의 핵심입니다.

depends_on은 서비스 시작 순서를 제어합니다. 예를 들어, 웹 애플리케이션이 데이터베이스에 의존한다면, depends_on을 사용하여 데이터베이스 컨테이너가 먼저 시작되도록 보장할 수 있습니다.

networks는 컨테이너 간 통신을 위한 사용자 정의 네트워크를 생성합니다. 이를 통해 컨테이너들은 IP 주소 대신 서비스 이름으로 서로를 참조하며, 격리된 네트워크 환경을 구축할 수 있습니다.

volumes는 컨테이너의 데이터를 영속적으로 저장하거나 컨테이너 간에 데이터를 공유할 때 사용됩니다. 호스트 머신의 디렉토리를 컨테이너에 마운트하여 데이터 유실을 방지하고, 여러 컨테이너가 동일한 데이터를 사용할 수 있게 합니다. 이 옵션들을 통해 복잡한 애플리케이션의 배포와 관리를 효율적으로 할 수 있습니다.

네, Kubernetes Pod의 라이프사이클에 대해 설명드리겠습니다.

Pod는 크게 Pending, Running, Succeeded, Failed, Unknown의 5가지 상태를 가집니다.

• Pending: Pod가 생성되었지만 아직 노드에 스케줄링되지 않았거나, 필요한 이미지를 다운로드하는 중인 상태입니다. 이 단계에서는 kube-scheduler가 적절한 노드를 찾고, 컨테이너 이미지를 가져오는 데 시간이 소요될 수 있습니다.

• Running: Pod가 노드에 스케줄링되었고, 모든 컨테이너가 정상적으로 실행 중인 상태입니다. 이 단계에서는 liveness probe와 readiness probe가 동작하며, Pod의 상태를 지속적으로 확인합니다.

• Succeeded: Pod 내의 모든 컨테이너가 성공적으로 종료되었고, 더 이상 재시작할 필요가 없는 상태입니다. 주로 배치 작업에 사용됩니다.

• Failed: Pod 내의 컨테이너 중 하나 이상이 실패로 종료되었고, 재시작 정책에 따라 재시작되지 않는 상태입니다.

• Unknown: Pod의 상태를 확인할 수 없는 상태입니다. 주로 노드와의 통신 문제로 발생합니다.

각 단계에서 발생하는 이벤트들을 모니터링하여 Pod의 상태 변화를 추적하고 문제 해결에 활용할 수 있습니다. 예를 들어, kubectl describe pod <pod-name> 명령어를 통해 Pod의 이벤트 로그를 확인할 수 있습니다.

Deployment와 ReplicaSet은 Kubernetes에서 Pod를 관리하는 데 사용되는 리소스입니다. ReplicaSet은 지정된 수의 Pod 복제본을 항상 실행하도록 보장하는 역할을 합니다. 만약 Pod가 죽으면 ReplicaSet은 자동으로 새로운 Pod를 생성합니다.

Deployment는 ReplicaSet을 관리하는 상위 수준의 추상화 계층입니다. Deployment를 사용하면 애플리케이션 업데이트, 롤백, 스케일링과 같은 복잡한 배포 작업을 더 쉽게 수행할 수 있습니다.

예를 들어, 롤링 업데이트를 생각해 봅시다. Deployment는 새로운 버전의 애플리케이션을 배포할 때 이전 ReplicaSet을 점진적으로 새로운 ReplicaSet으로 교체합니다. 이를 통해 서비스 중단 없이 애플리케이션을 업데이트할 수 있습니다. 만약 업데이트에 문제가 발생하면 Deployment는 이전 버전으로 롤백하는 기능도 제공합니다. Deployment는 ReplicaSet을 직접 관리하는 것보다 훨씬 편리하고 안전한 배포 전략을 제공합니다.

Kubernetes Service의 주요 타입은 ClusterIP, NodePort, LoadBalancer 세 가지가 있습니다.

ClusterIP는 기본 타입으로, 클러스터 내부에서만 접근 가능한 가상 IP를 할당합니다. Pod 간 통신이나 클러스터 내부에서만 사용되는 애플리케이션에 적합합니다.

NodePort는 각 노드의 특정 포트를 외부에 개방하여 서비스에 접근하게 합니다. 클러스터 외부에서 간단하게 서비스를 노출할 때 유용하지만, 노드 IP가 변경될 경우 문제가 될 수 있습니다.

LoadBalancer는 클라우드 프로바이더의 로드밸런서를 사용하여 외부 트래픽을 서비스로 전달합니다. 외부에서 안정적으로 서비스를 제공해야 할 때 가장 많이 사용됩니다.

이 모든 서비스 타입은 kube-proxy를 통해 실제 Pod로 트래픽을 라우팅하며, 더 복잡한 라우팅 규칙이나 SSL 종료 등이 필요할 때는 Ingress를 함께 사용하는 것이 일반적입니다.

Operator 패턴을 설계할 때 가장 중요한 것은 CRD를 통해 애플리케이션의 상태를 명확하게 정의하는 것입니다. 예를 들어, MyApp이라는 CRD를 만들고, desired state (replicas, image version 등)와 observed state (available replicas, status)를 포함합니다.

Controller는 Reconcile 루프를 통해 desired state와 observed state를 지속적으로 비교하고, 차이가 있다면 desired state에 맞게 애플리케이션을 조정합니다. 이 과정에서 Kubernetes API를 사용하여 Pod, Service 등을 생성/관리합니다.

자동 복구를 위해서는 Controller가 애플리케이션의 상태를 주기적으로 확인하고, 문제가 발생하면 (예: Pod 실패) 자동으로 새로운 Pod를 생성하도록 구현합니다. 또한, 웹훅을 사용하여 CRD 생성/수정 시 유효성을 검사하고, 잘못된 설정으로 인해 시스템에 문제가 발생하는 것을 방지할 수 있습니다.

MSA 환경에서 Kubernetes 기반 서비스 메쉬를 도입하여 고급 트래픽 관리 전략을 구현하는 것은 매우 효과적인 방법입니다. 서비스 메쉬는 트래픽 관리 기능을 서비스 코드에서 분리하여 중앙 집중식으로 제어할 수 있게 해주기 때문입니다.

Blue/Green 배포, Canary 배포, A/B 테스트 모두 서비스 메쉬의 트래픽 시프팅 기능을 활용합니다. 예를 들어, Istio의 VirtualService를 사용하면 특정 버전의 서비스로 트래픽을 점진적으로 이동시킬 수 있습니다. DestinationRule을 통해 서비스의 다양한 버전을 정의하고, VirtualService에서 이들을 참조하여 트래픽 분할 비율을 조정합니다.

요청 기반 라우팅은 VirtualService의 match 조건을 활용합니다. 특정 HTTP 헤더, 쿠키, URL 경로 등을 기반으로 트래픽을 다른 서비스로 라우팅할 수 있습니다. 예를 들어, 특정 사용자 그룹에게만 새로운 기능을 제공하는 A/B 테스트를 구현할 때 유용합니다.

폴트 인젝션은 서비스의 안정성을 테스트하는 데 사용됩니다. Istio의 Fault Injection 기능을 사용하면 지연 시간 추가 또는 HTTP 오류 반환과 같은 장애 상황을 시뮬레이션할 수 있습니다. 예를 들어, 특정 서비스에 5%의 확률로 500 에러를 발생시키도록 설정하여, 다른 서비스들이 이러한 장애 상황에 얼마나 잘 대처하는지 확인할 수 있습니다. 이를 통해 서비스 복원력을 향상시킬 수 있습니다.

대규모 클러스터에서 스케줄링 지연이나 자원 불균형 문제는 기본 스케줄러의 한계를 보여줍니다. 이를 해결하기 위해 저는 다음과 같은 복합적인 접근 방식을 고려할 것입니다.

먼저, 특정 워크로드의 요구사항이 복잡하거나 고도화된 경우, 커스텀 스케줄러를 구현하여 Predicate 및 Priority 로직을 세밀하게 조정할 수 있습니다. 예를 들어, 특정 하드웨어 가속기 사용이나 복잡한 네트워크 토폴로지 고려가 필요할 때 유용합니다.

또는, 기존 스케줄러의 기능을 확장하는 Scheduler Extender를 활용하여 외부 로직을 통합하는 것도 좋은 방법입니다. 이는 기존 스케줄러를 유지하면서 유연성을 확보할 수 있습니다.

이와 더불어, Taints/Tolerations, Node Affinity/Anti-Affinity, PriorityClass와 같은 고급 스케줄링 정책을 적극적으로 활용하여 워크로드와 노드 간의 관계를 명확히 정의하고, 우선순위를 관리하여 자원 활용률을 최적화할 것입니다. 특히, 특정 워크로드가 특정 노드에만 스케줄링되도록 하거나, 특정 워크로드 간의 격리를 보장하는 데 효과적입니다.

이러한 방안들을 워크로드의 특성과 클러스터 환경에 맞게 조합하여 적용함으로써, 스케줄링 지연을 줄이고 노드 자원 활용률을 균형 있게 개선할 수 있다고 생각합니다.

Kubernetes의 CRI는 컨테이너 런타임과의 추상화 계층 역할을 합니다. 이를 통해 Kubernetes는 Docker, containerd, CRI-O 등 다양한 런타임을 동일한 방식으로 관리할 수 있습니다. CRI는 gRPC 인터페이스를 통해 kubelet과 런타임 간 통신을 정의하며, OCI 표준 준수를 통해 컨테이너 이미지 및 런타임 호환성을 보장합니다.

자체 커스텀 런타임을 통합하려면, 먼저 CRI 인터페이스를 구현해야 합니다. 즉, 컨테이너 생성, 시작, 중지, 삭제 등 Pod 라이프사이클 관리를 위한 gRPC API를 개발해야 합니다. 또한, OCI 호환 이미지 포맷을 지원하고, 기존 런타임의 보안 및 성능 최적화 기능을 커스텀 런타임에 반영해야 합니다. 통합 후에는 kubelet이 커스텀 런타임을 인식하도록 설정하고, 로깅 및 모니터링 시스템과의 연동 방안도 마련해야 합니다.

Kubernetes 환경에서 I/O 성능이 중요한 스테이트풀 애플리케이션의 스토리지 병목 현상을 진단하고 최적화하는 방법은 다음과 같습니다.

먼저, kubectl describe pv <pv_name> 명령어로 PV의 상세 정보를 확인하여 스토리지 클래스, 프로비저닝 방식, 볼륨 모드 등을 파악합니다. IOPS와 Latency를 모니터링하여 성능 저하의 원인을 분석합니다.

CSI 드라이버를 활용한다면, 드라이버의 컨트롤러 플러그인이 스토리지 프로비저닝을 어떻게 처리하는지, 노드 플러그인이 볼륨을 어떻게 마운트하는지 확인합니다. 스토리지 백엔드의 특성에 맞춰 최적화된 CSI 드라이버를 선택하거나 직접 개발하는 것을 고려할 수 있습니다. 예를 들어, NVMe SSD를 사용하는 경우 해당 성능을 최대한 활용할 수 있도록 드라이버를 튜닝합니다.

또한, StorageClass의 프로비저닝 방식을 조정하여 성능을 개선할 수 있습니다. 필요에 따라 볼륨 모드를 Block으로 변경하여 파일 시스템 오버헤드를 줄일 수도 있습니다. QoS 설정을 통해 특정 워크로드에 더 많은 I/O 자원을 할당하는 것도 방법입니다.

Kubernetes 클러스터에서 Pod 간 통신 문제, 특히 Network Policy와 CNI 플러그인 상호작용으로 인한 문제를 진단하고 해결하는 것은 복잡할 수 있습니다.

먼저, kubectl describe pod <pod-name> 명령어로 해당 Pod의 상태와 이벤트를 확인하여 네트워크 관련 오류 메시지가 있는지 살펴봅니다. kubectl logs <pod-name>으로 Pod 내부 애플리케이션 로그를 분석하여 통신 실패 지점을 파악합니다.

문제가 특정 Pod 간 통신에 국한된다면, Network Policy 설정을 검토해야 합니다. kubectl get networkpolicy -n <namespace>로 관련 Network Policy를 확인하고, kubectl describe networkpolicy <policy-name> -n <namespace>로 상세 설정을 분석하여 Ingress 및 Egress 규칙이 의도대로 적용되고 있는지 평가합니다. 특정 Pod가 다른 Pod로 접근하지 못한다면, 해당 Pod의 Egress 규칙이나 대상 Pod의 Ingress 규칙에 문제가 있을 수 있습니다.

만약 외부 네트워크 접근 실패라면, Pod의 Egress 규칙과 함께 CNI 플러그인의 동작을 의심해 볼 수 있습니다. CNI 플러그인(예: Calico, Cilium)의 설정 파일과 로그를 분석하여 네트워크 인터페이스 설정, 라우팅 규칙, IP 할당 등에 문제가 없는지 확인합니다. tcpdump와 같은 도구를 사용하여 Pod 내부 또는 노드에서 실제 네트워크 트래픽을 캡처하고 분석하면, 패킷이 어디서 드롭되는지 파악하는 데 도움이 됩니다. netshoot과 같은 디버깅 Pod를 활용하여 클러스터 외부로 ping이나 curl을 시도하며 네트워크 경로를 추적하는 것도 유용합니다.

kube-proxy의 동작도 확인해야 합니다. Service IP로의 접근이 실패하는 경우, kube-proxy가 올바른 Endpoints로 트래픽을 전달하고 있는지 점검합니다.

이러한 단계들을 체계적으로 거치면 Network Policy와 CNI 플러그인의 복합적인 문제로 인한 Pod 통신 문제를 효과적으로 진단하고 해결할 수 있습니다.

네, Kubernetes 클러스터 보안 강화를 위해 PSS와 Admission Controller를 효과적으로 적용하는 방안을 말씀드리겠습니다.

우선, 네임스페이스별로 PSS restricted 프로파일을 적용합니다. 이는 Pod Security Admission Controller(PSA)를 통해 간단하게 설정할 수 있습니다. restricted 프로파일은 가장 엄격한 보안 정책을 적용하므로, 대부분의 워크로드에 안전한 기반을 제공합니다.

하지만 모든 워크로드가 restricted를 만족할 수 없으므로, 예외 처리가 필요합니다. 이때, Validating Admission Webhook을 활용하여 특정 조건 하에 예외를 허용하는 커스텀 정책을 구현합니다. 예를 들어, 특정 네임스페이스 또는 특정 어노테이션이 있는 Pod에 대해서만 특정 보안 설정을 완화할 수 있습니다.

RBAC를 통해 이러한 예외 정책을 관리할 권한을 제한하여, 보안 위험을 최소화합니다. 즉, 특정 그룹의 사용자만 예외 정책을 변경하거나 적용할 수 있도록 합니다.

이러한 방식으로 PSS의 강력한 보안 정책을 유지하면서도, 필요한 경우 유연하게 예외를 관리하여 클러스터 운영의 효율성을 높일 수 있습니다.