38 posts tagged with "Kubernetes"

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

로컬 PC에서 테스트한 내용은 gasida 님이 작성하신 설치 가이드를 참고했습니다.

비교 기준: 로컬 PC(RTX 4070 Ti SUPER, GeForce) 환경의 같은 절차

측정 환경: AWS EC2 g6.2xlarge (NVIDIA L4 24GB, compute capability 8.9) · 순정 Ubuntu 24.04.4 LTS AMI · NVIDIA Driver 595.84 / CUDA 13.2 · Container Toolkit 1.20.0 · K3s v1.36.4 · device-plugin v0.20.0 · DCGM Exporter 4.6.0 · NFD 0.18.3 · HAMi v2.10.0 · vLLM 0.28.0

GPU가 꽂힌 물리 PC에 Ubuntu를 깔고 드라이버부터 쿠버네티스 GPU 분할까지 올리는 방법을 바탕으로 AWS EC2에서 그대로 진행해 보고 로컬 PC 환경과 어떤 부분에 차이가 있는지 비교하고 기록했다.

Deep Learning AMI를 쓰지 않았다. 앞선 실습들은 드라이버가 미리 깔린 DL용 AMI를 썼는데 이번에는 드라이버 설치 과정 자체가 주요 내용이다. DKMS 빌드, .ko.zst 모듈, /dev/nvidia* 장치 노드가 어떻게 생기는지 보려면 순정 이미지에서 시작해야 한다. 그래서 Canonical 순정 Ubuntu 24.04 AMI로 진행했다.

결론부터 말하자면 계획한 항목이 Utilyze 하나만 빼고 전부 통과했고 로컬 PC와 갈린 지점이 몇 가지 확인되었다. kubeadm과 GPU Operator를 전제로 한 후반부(HAMi, DRA)는 K3s에서 수동 스택으로 돌리려면 손을 봐야 했고, 그 과정에서 나온 것들을 정리했다.

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

Tetragon​

Tetragon를 사용하여 Kubernetes 클러스터의 보안 및 프로세스 모니터링을 수행하는 방법에 대해 간단히 알아보자.

Tetragon이란 무엇인가?​

그림 출처: https://isovalent.com/blog/post/2022-05-16-tetragon/​

https://tetragon.io/

Tetragon은 eBPF(extended Berkeley Packet Filter)를 기반으로 하는 강력한 보안 및 모니터링 도구이다. eBPF는 커널 레벨에서 실행되는 프로그램으로, 시스템 성능에 최소한의 영향을 주면서 실시간으로 데이터를 수집하고 처리할 수 있다. Tetragon은 이를 활용하여 Kubernetes 환경에서 네트워크 트래픽, 시스템 호출, 컨테이너 활동 등을 모니터링하고 분석할 수 있다.

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

이번 포스팅의 목적은 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에 서비스 이름 항목를 생성하는 방법에 대해 설명하고자 한다.