[패스트캠퍼스 챌린지 17일차] '76가지 DevOps 모의 실무 예제: AWS 기반 인프라 구축부터 재해복구, 보안까지' 강의 후기 본문
[패스트캠퍼스 챌린지 17일차] '76가지 DevOps 모의 실무 예제: AWS 기반 인프라 구축부터 재해복구, 보안까지' 강의 후기
ITst 2025. 4. 17. 22:27본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
※ 챌린지 URL: https://abit.ly/lisbva
오늘은 쿠버네티스 네트워크 구성과 Pod 생성 흐름, 그리고 내부 DNS 시스템인 CoreDNS에 대해 집중적으로 학습했다. 전체적으로 쿠버네티스 클러스터가 어떻게 통신을 구성하고, 각 컴포넌트가 어떤 역할을 하는지에 대한 큰 그림을 그릴 수 있는 시간이었다.
처음으로 배운 CoreDNS는 쿠버네티스 클러스터 내에서 서비스 디스커버리 역할을 하는 핵심 DNS 서버다. 초기에는 kube-dns라는 이름으로 제공되었지만, 현재는 CNCF 프로젝트인 CoreDNS로 대체되어 훨씬 더 경량화되고 빠른 동작이 가능하다.
CoreDNS는 파드나 서비스에 도메인 네임을 부여하고 이를 IP로 해석해 주므로, 파드 간 직접 IP 호출보다는 서비스 오브젝트를 통한 통신이 일반적인 구조로 정착된다. 실습에서는 실제 coredns의 configmap을 확인하거나 파드 내 /etc/resolv.conf를 확인하면서 내부 DNS가 어떻게 구성되어 있는지 확인할 수 있었다.
다음으로 Pod 생성의 전체적인 흐름을 살펴보았다. 사용자가 파드를 요청하면, kube-apiserver가 이를 검증하고 etcd에 저장한다. 이후 스케줄러가 노드를 바인딩하고, kubelet이 해당 노드에서 컨테이너를 실행한다. 이 모든 정보는 지속적으로 etcd를 통해 갱신되고, kube-apiserver가 이를 중계하는 중심 허브 역할을 한다. 쿠버네티스의 선언적 인프라 구조가 이렇게 각 컴포넌트의 역할 분담을 통해 실현된다는 점이 인상 깊었다.
Pod 간 네트워크는 더욱 흥미로운 주제였다. 각 파드는 고유한 IP를 가지고 통신하지만, 서로 다른 노드에 위치한 파드 간 통신이 발생하면 IP 충돌이나 라우팅 문제가 생길 수 있다. 이를 해결하기 위해 overlay network가 필요하고, 쿠버네티스 자체에는 해당 기능이 없기 때문에 플라넬, 칼리코, 실리움 같은 CNI 플러그인을 사용해야 한다. 이 플러그인들은 컨테이너 간의 브릿지를 생성하고 네트워크 대역을 나눠줘서 통신을 가능하게 한다. CNI는 쿠버네티스뿐 아니라 AWS ECS, 클라우드 파운드리 같은 다양한 플랫폼에서도 표준으로 사용되는 만큼, 컨테이너 네트워킹의 근간을 형성하는 중요한 개념이었다.
마지막으로, 각 컴포넌트의 포트 및 버전 관리에 대해서도 확인했다. kube-apiserver는 여러 컴포넌트와 통신의 중심축이 되므로, 반드시 가장 높은 버전으로 관리되어야 하며, 나머지 컴포넌트는 그보다 낮거나 같은 버전이어야 한다는 정책이 인상적이었다. 실제 운영 환경에서는 이 포트 정보와 버전 정책을 명확히 이해하고 있어야 유지보수나 디버깅 시에 큰 도움이 될 것 같다.
오늘 학습을 통해 쿠버네티스 내부에서의 통신 구조, DNS 처리 방식, 파드 생성 흐름 등 실질적인 운영 관점에서 필수적인 내용을 잘 정리할 수 있었다.
