해당 포스팅은 현재 재직중인 회사에 관련이 없고, 개인 역량 개발을 위한 스터디 자료로 활용할 예정입니다.

이번 포스팅의 목적은 Gateway API의 개념을 이해하고 Lattice를 통해 AWS Gateway API Controller를 EKS에서 사용해보기 위함이다.

Cloud Native 환경에서의 서비스 디스커버리​

서비스 디스커버리는 클라우드 네이티브 환경에서 애플리케이션의 구성 요소들이 서로를 인식하고 통신할 수 있도록 하는 핵심 기능이다.

1. 동적 환경 지원: 클라우드 환경에서는 애플리케이션의 구성 요소가 동적으로 생성되거나 삭제될 수 있다. 서비스 디스커버리는 이러한 변화에 즉각적으로 대응하여, 새로운 인스턴스가 추가되거나 기존 인스턴스가 제거될 때에도 애플리케이션이 원활하게 작동할 수 있도록 한다.

2. 부하 분산: 서비스 디스커버리를 통해 클라이언트는 여러 서비스 인스턴스 중에서 적절한 인스턴스를 선택할 수 있다. 이를 통해 트래픽이 고르게 분산되어 시스템의 성능과 안정성을 높일 수 있다.

3. 장애 복구: 서비스 디스커버리는 장애가 발생한 인스턴스를 자동으로 감지하고, 클라이언트가 다른 정상 인스턴스에 연결할 수 있도록 해서 가용성을 높인다.

4. 유지보수 용이성: 서비스 디스커버리를 통해 애플리케이션의 구성 요소가 서로를 쉽게 찾을 수 있으므로, 시스템의 유지보수가 용이해진다. 개발자는 서비스의 위치나 상태를 신경 쓰지 않고, 애플리케이션의 비즈니스 로직에 집중할 수 있다.

5. 확장성: 서비스 디스커버리는 새로운 서비스 인스턴스를 추가할 때, 기존의 클라이언트가 이를 자동으로 인식할 수 있도록 하여, 시스템의 확장성을 지원한다. 이는 비즈니스 요구에 따라 유연하게 리소스를 조정할 수 있게 한다.

Headless Service​

Kubernetes Service는 클러스터 내외의 파드(pod) 간 통신을 위한 중요한 요소이다. 일반적인 Service는 클러스터 IP와 로드밸런서, 노드포드 등을 통해 파드 내, 외부의 트래픽을 관리하지만, 모든 서비스가 이런 방식으로 동작할 필요는 없다. 특히, 상태 기반 애플리케이션이나 각 노드가 고유성을 유지해야 하는 분산 시스템에서는 Headless Service가 필수적이다.

Headless Service는 서비스 디스커버리의 중요한 역할을 수행한다. 클러스터 IP를 생성하지 않기 때문에 각 파드는 고유한 DNS 레코드를 통해 서로를 발견하고 직접 통신할 수 있다. 이는 상태 기반 애플리케이션이 각 파드의 상태를 유지하면서도 서로 간의 통신을 원활하게 할 수 있도록 지원한다. 따라서, Headless Service는 동적 환경에서 서비스 디스커버리를 가능하게 하여, 애플리케이션의 유연성과 확장성을 높이는 데 기여한다.

이번 포스팅에서는 Kubernetes의 Headless Service를 설명하고, 이를 StatefulSet과 함께 사용하는 실제 사례를 통해 활용 방법을 정리하고자 한다. 아울러, 최근 실무에서 많이 사용되는 도구들에서 활용할 수 있는 간단한 코드로 제공하여, Kubernetes에서 stateful한 애플리케이션을 어떻게 효과적으로 운영할 수 있는지에 대해 다룬다.

엔터프라이즈 환경에서는 클러스터에서 실행되는 워크로드에 IP 주소를 직접 사용하여 액세스하는 것이 일반적이지 않다. 대신, 쿠버네티스 클러스터에서 Service를 실행하여 애플리케이션의 고가용성을 보장한다. 이번 포스팅에서는 ExternalDNS sigs 프로젝트를 사용하여 DNS에 서비스 이름 항목를 생성하는 방법에 대해 설명하고자 한다.

이전 직장에서 프로젝트 중에 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에 포함시키고 트래픽을 받을 수 있도록 한다. 그러나 이는 실제로 컨테이너가 준비되지 않았을 때도 트래픽을 받을 수 있어 사용자 경험에 부정적인 영향을 미칠 수 있다. 따라서, 애플리케이션의 상태를 정확히 반영하기 위해 적절한 프로브를 설정하는 것이 중요하다.