학습 아키텍처 설계를 위한 Kubernetes 교훈

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

아키텍처

대상자

• 소프트웨어 개발자 및 시스템 아키텍트
• 복잡한 시스템 설계 및 유지보수에 관심 있는 개발자
• 초보자 및 중급 개발자 (복잡한 설계 패턴과 유지보수 전략을 이해하는 데 초점을 맞춤)

핵심 요약

• 과도한 추상화를 피하고 실제 중복이 있는 코드만 최적화해야 한다.
• Kubernetes의 CRI 추상화는 Docker와의 결합을 해제하고 더 유연한 인터페이스를 제공한다.
• 단일 책임 원칙을 준수하면 모듈 간 의존성 감소와 유지보수성 향상이 가능하다.

섹션별 세부 요약

1. 과도한 추상화의 위험

• 즉시 중복 제거를 피해야 하며, 중복이 진정한 의미에서 발생하는 경우에만 처리해야 한다.
• 다른 진화 경로를 가진 코드는 중복이 아니므로 과도한 추상화로 인해 미래 유지보수가 어려워질 수 있다.
• 복잡한 시스템에서 수정 시 부작용이 발생할 수 있으므로, 작은 단위 메서드를 재사용하는 방식이 유리하다.

2. Kubernetes의 추상화 전략

• CRI (Container Runtime Interface)는 Docker와의 결합을 해제하고, containerd와의 호환성을 위해 DockerShim을 사용한다.
• Kubernetes의 모듈 구조는 kube-scheduler, kubelet, containerd 등이 각각의 역할을 분리하여 유연한 확장성을 제공한다.
• 추상화 계층을 통해 호환성 유지와 다양한 환경에의 적응이 가능하다 (예: k3s는 ETCD에 대한 강한 의존성을 가지지 않음).

3. 프로그래밍 패러다임의 제약

• 구조화 프로그래밍은 goto 사용을 제한하고 if-else로 모듈 분리를 권장한다.
• 객체지향 프로그래밍은 싱글톤 패턴을 통해 중복된 구조를 재사용하고, 독립된 엔티티를 생성하여 변화 영향 최소화를 목표로 한다.
• 함수형 프로그래밍은 변수 값의 직접 수정을 피하고, 불변성을 강조한다.

4. 단일 책임 원칙과 모듈 설계

• 모듈은 하나의 기능만 수행해야 하며, kube-scheduler는 Pod 스케줄링에만 집중하고, CNI/CRI는 네트워크/런타임 환경을 담당한다.
• 원하는 상태(Desired State)를 Kubernetes에 명시하고, kubelet이 자동으로 상태 조정하도록 하는 것이 유지보수에 유리하다.
• 서비스 설계는 함수 호출보다 더 높은 비용이 발생하지만, 시스템 아키텍처와 무관하며 구현 세부 사항을 추상화해야 한다.

결론

• 과도한 추상화를 피하고, 실제 중복이 발생한 경우에만 최적화를 수행해야 한다.
• Kubernetes의 추상화 전략 (예: CRI, DockerShim)을 참고해 유연한 인터페이스를 설계하라.
• 단일 책임 원칙을 준수하고, 모듈 간 의존성을 최소화해 유지보수성을 향상시켜야 한다.