이전 직장에서 프로젝트 중에 Multus를 사용하여 5G환경에서 멀티 네트워크 CNI를 사용해서 패킷을 미러링하고 해당 패킷을 분석하는 프로젝트를 진행했었는데, 당시에 여러 사정으로 아쉽게 된 프로젝트도 존재하고 해서 이번 기회에 시리즈로 정리 해보려고 한다. 이번 포스트에서는 Kind cluster에 Multus를 구성하고 단일 인스턴스에서 노드끼리 통신할 수 있도록 koko를 사용해서 노드간 멀티 네트워크 환경을 구성하는 방법에 대해서 정리해보려고 한다.

Requirements​

• Kind: Kind(Kubernetes IN Docker)는 Docker 컨테이너를 사용하여 로컬 Kubernetes 클러스터를 실행할 수 있게 해주는 도구다. 주로 테스트 및 개발 목적으로 사용되며, 빠르고 쉽게 Kubernetes 환경을 구축할 수 있다.
• Multus: Multus는 Kubernetes에서 여러 네트워크 인터페이스를 지원하기 위한 CNI 플러그인이다. Multus를 통해 각 Pod가 여러 네트워크에 연결될 수 있으며, 다양한 네트워크 요구 사항을 충족할 수 있다. 특히 5G 워크로드에서 SR-IOV와 함께 사용될 때, Multus는 기본 네트워크 외에도 고성능 네트워크 인터페이스를 제공할 수 있다.
  • SR-IOV: SR-IOV(Single Root I/O Virtualization)는 하나의 물리적 네트워크 인터페이스를 여러 가상 함수(VF)로 나누어 각 Pod에 직접 할당할 수 있게 해주는 기술이다. 이를 통해 네트워크 성능을 크게 향상시킬 수 있으며, 특히 고성능 네트워킹이 필요한 5G 및 NFV(Network Function Virtualization) 환경에서 중요하게 사용되는 기술이다.
• Koko: Koko는 컨테이너 간 네트워크 연결을 위한 도구로, 특히 여러 네트워크 네임스페이스 간의 가상 이더넷 페어를 생성하는 데 사용된다. kind cluster에서 컨테이너로 구성된 노드간 통신을 위해서 사용된다.
• Macvlan: Macvlan은 네트워크 인터페이스를 가상화하여 여러 개의 가상 네트워크 인터페이스를 생성할 수 있는 기술이다. 이를 통해 각 컨테이너가 고유한 MAC 주소를 가지며, 물리 네트워크와 직접 통신할 수 있다.

Kubernetes에서 파드의 Readiness 및 프로브는 파드의 상태를 모니터링하고 트래픽을 효율적으로 관리하기 위한 중요한 메커니즘이다. 프로브는 파드가 요청을 처리할 준비가 되었는지를 판단하는 데 사용되며, Kubernetes가 파드를 관리하고 업데이트하는 데 중요한 역할을 한다.

파드 Readiness 및 프로브​

파드 Readiness는 따라 파드가 트래픽을 처리할 준비가 되었는지를 나타내는 추가적인 지표이다. 파드 Readiness는 외부 소스에서 파드 주소가 Endpoints 객체에 표시되는지를 결정한다. Kubernetes에서 파드를 관리하는 다른 리소스들, 예를 들어 Deployment 같은 것들은 파드 Readiness를 고려하여 롤링 업데이트 시 의사 결정을 한다. 롤링 배포 중에 새 파드가 준비되었지만 서비스, 네트워크 정책 또는 로드 밸런서가 어떤 이유로 인해 아직 새 파드에 대해 준비되지 않은 경우가 있을 수 있다. 만약 파드의 Readiness 프로브가 실패하면, 해당 파드의 IP 주소는 Endpoints 객체에서 제거되어 서비스가 그 파드로 트래픽을 라우팅하지 않는다. 이는 서비스 중단을 방지하기 위한 메커니즘이다. Readiness 프로브는 파드 .Status.Phase 에 영향을 줄 수 있으며, Kubelet이 이를 실행하여 성공 또는 실패에 따라 파드 상태를 업데이트한다.

파드에 프로브가 명시되어 있지 않으면 Kubernetes가 기본적으로 해당 프로브의 상태를 성공으로 간주한다. 이런 경우 Kubernetes가 컨테이너를 Ready 상태로 간주하여 서비스의 Endpoints에 포함시키고 트래픽을 받을 수 있도록 한다. 그러나 이는 실제로 컨테이너가 준비되지 않았을 때도 트래픽을 받을 수 있어 사용자 경험에 부정적인 영향을 미칠 수 있다. 따라서, 애플리케이션의 상태를 정확히 반영하기 위해 적절한 프로브를 설정하는 것이 중요하다.

컨테이너 내부에서 실행 중인 애플리케이션이나 프로세스는 시스템 호출(system call)을 수행할 수 있다. 대표적인 예로 HTTP 요청을 수행하는 curl 명령을 들 수 있다. 시스템 호출은 커널에 서비스를 요청하기 위해 사용자 공간에서 실행되는 추상화된 프로그래밍인데, 커널 강화 도구를 사용하여 허용되는 시스템 호출을 제한할 수 있으며, CKS 시험에서는 AppArmor와 seccomp라는 두 가지 도구를 명시적으로 언급하고 있다. 이 두 도구는 컨테이너화된 환경에서 보안을 강화하는 데 중요한 역할을 하며, Kubernetes와의 통합을 통해 보다 안전한 클러스터 운영을 지원한다. 이 두 도구와 쿠버네티스와 통합하는 메커니즘에 대해 설명한다.

AppArmor​

AppArmor는 Linux 시스템에서 실행되는 프로그램에 대한 액세스 제어 기능을 제공한다. AppArmor는 경로 기반으로 작동하며, 프로필을 통해 특정 프로그램이나 컨테이너가 필요한 접근만 허용하도록 설정할 수 있다. Kubernetes에서는 AppArmor 프로필을 Pod 또는 컨테이너 수준에서 지정할 수 있으며, securityContext를 통해 적용한다. 이 도구는 user space에서 호출되는 애플리케이션과 기본 시스템 기능 사이에 추가적인 보안 계층을 구현한다. 네트워크 호출 또는 파일 시스템 상호 작용을 제한할 수 있다. 많은 Linux 배포판(예: Debian, Ubuntu, openSUSE)이 AppArmor를 기본으로 제공한다. AppArmor를 지원하지 않는 Amazon Linux와 같은 배포판은 AppArmor와 유사한 접근 방식을 취하는 SELinux를 대신 사용할 수 있다.

애플리케이션의 부하 테스트를 k6를 이용하여 진행하고 결과를 prometheus 및 grafana로 전달하여 확인하는 방법을 작성한다.

k6​

https://github.com/grafana/k6

k6는 오픈소스 부하테스트 도구로, Go와 자바스크립트를 이용해 성능 테스트를 할 수 있는 도구이다. k6은 다양한 프로토콜(HTTP, WebSocket 등)을 지원하며, 설치와 사용이 매우 간편하다. 이전에 k6 테스트를 작성해 본 적이 없다면 Running k6를 확인하고 작동 방식을 파악하는 것부터 시작하는 것이 좋다. 또한, 친철하게 한글로 설명되어 있는 tutorial 링크도 참조한다.

https://github.com/schooldevops/k6-tutorials/blob/main/GettingStarts/01_intro_install.md

kyverno 도구를 이용해서 쿠버네티스의 정책 엔진으로 활용하여 보안을 포함한 다양한 정책을 적용하는 방법을 알아본다.

kyverno​

Kyverno는 그리스어로 "지배하다, 다스리다"의 뜻으로 쿠버네티스 네이티브로 설계된 정책 엔진(policy engine)이다. Kyverno 정책을 활용하여 쿠버네티스 리소스가 정책에 부합하는지 검사하고, 필요하면 리소스를 변경하거나 생성할 수 있다. Kyverno 구조 및 동작 방식을 간단히 정리한다.

OPA Gatekeeper는 독자적인 policy 언어인 Rego를 사용하여 policy를 정의하만 kyverno는 쿠버네티스 리소스로 관리되며 정책을 작성하는 데 새로운 언어가 필요하지 않다. OPA Gatekeeper와 유사하게 pre-defined policy library 를 제공한다.