https://kubernetes.io/ko/docs/concepts/services-networking/service/
https://kubernetes.io/docs/concepts/services-networking/service/
서비스는 단일 엔드포인트를 가진 클러스터에서 실행되는 애플리케이션을 외부 네트워크에 노출시키며, 워크로드가 여러 백엔드로 구성되어있는 경우도 지원한다.
서비스는 기존 전통적인 애플리케이션 배포를 위한 컨테이너 관리에서 어떤 문제를 해결한 추상화된 리소스인가?
AWS를 이용해 ec2에 컨테이너를 배포할때, ec2를 내렸다가 올리면 매번 할당되는 ec2의 IP가 변동되어서 그 때마다 이를 로드밸런서와 수동으로 매핑해주거나, 혹은 돈을 지불하고 고정 IP를 이용해야 했었던 적이 있다.
쉽게 말하자면 서비스는 위와 같은 문제를 해결하기 위해 존재하는 리소스임.
쿠버네티스 서비스를 사용하면 파드에게 고유한 IP 주소, 그리고 단일 DNS명을 부여하고 그것들 간에 로드밸런싱을 수행한다.
파드는 비영구적인 리소스이다. 특히 deployments를 사용하고 있다면 동적으로 파드를 생성하고 제거할 수도 있다.
각 파드는 고유한 IP주소를 갖는다. 하지만 동적으로 생성되다보니 프론트엔드 역할을 하는 파드 집합이 백엔드 파드 집합의 IP주소를 어떻게 찾아가려고 해도 매번 이 IP가 달라져버리는 문제가 있다.
쿠버네티스의 services 리소스는, 파드의 논리적 집합, 그리고 그 집합에 접근할 수 있는 정책을 정의하는 추상화된 리소스이다. (이 패턴을 흔히 Micro-Service라고 한다) 서비스가 대상으로 하는 파드 집합은 일반적으로 Selector가 결정한다.
셀렉터 없이 서비스를 정의할 수도 있음. 이는 관련 문서를 찾아볼 것.
💡 Selector: 레이블에 따라서 리소스들을 필터링할 수 있게 해주는 오브젝트
쿠버네티스에서 대부분의 파드들은 레플리카 셋을 갖고 있고, 이러한 레플리카는 대체 가능하다. 즉, 프론트엔드 입장에서는 실제로 어떤 고유한 백엔드 파드를 사용하는지는 관심 없다. 다시 말해 백엔드 파드 집합을 구성하는 실제 파드는 변경될 수 있지만 프론트엔드 파드는 변경을 인식할 필요도 없고 이걸 일일이 추적할 필요가 없어야 한다.
서비스 리소스가 이러한 디커플링을 가능하게 한다.
서비스가 어떤 파드 집합을 타게팅 할지는 사용자가 정의한 selector에 의해 결정된다.