서비스 : 파드 집합에 대한 안정적인 엔드포인트 제공

• 모든 파드는 고유한 IP를 가지지만, 파드가 재시작되거나 다른 노드로 옮겨갈 때마다 이 IP가 변경되는 비영속적인 특성을 가지고 있다.
  ->즉, 파드는 고정된 IP를 가지지 않기 때문에, 이렇게 수시로 바뀌는 파드들의 IP를 일일이 추적하고 관리하는 것은 현실적으로 어렵다.
  예를 들어, 어떤 애플리케이션이 여러 개의 파드로 구성되어 있고 그 파드들이 언제든 재시작될 수 있다고 가정해보면, 그때마다 바뀌는 IP를 매번 찾아서 요청을 보내야 하는데, 이는 비효율적이고 안정적인 통신이 불가능한 구조이다.

이런 문제를 해결하기 위해 쿠버네티스가 제공하는 것이 바로 Service이다.

• Service는 여러 개의 파드 집합에 대해 변하지 않는 하나의 고정된 접근 지점(엔드포인트)을 제공한다.
  즉, 파드가 재시작되거나 교체되어도 Service의 주소는 그대로 유지된다.
• 따라서 사용자는 매번 새로운 파드의 IP를 알 필요 없이 항상 같은 경로로 접근할 수 있다.

쿠버네티스 공식 홈페이지 (Service에 대한 설명)
“서비스는 외부와 접하는 단일 엔드포인트 뒤에서 클러스터 내에서 실행되는 애플리케이션을 노출시키며, 이는 워크로드가 여러 백엔드로 나뉘어 있는 경우에도 가능하다.”
처음 들으면 조금 어려운 말처럼 보이지만, 결국 의미는 같다.

-> 즉, 여러 개의 파드(백엔드)가 실제로 존재하더라도 사용자는 그 모든 파드를 일일이 구분할 필요 없이, 단일한 서비스 엔드포인트를 통해 접근할 수 있다는 뜻이다.

ex)마치 여러 명의 직원이 근무하는 콜센터를 하나의 대표 전화번호로 연결하듯이, Service는 파드 집합을 대표하는 안정된 연결 창구 역할을 한다.

서비스 내부 동작 과정

쿠버네티스에서 서비스는 파드의 논리적 집합, 그리고 그것에 접근할 수 있는 정책에 대해 정의하는 "추상적 개념"이다.

서비스가 대상으로 하는 파드집합은 일반적으로 selector가 결정한다.
(selector를 쓰지 않는 서비스도 있다. 이는 밑에서 추가적으로 다룰 것이다.)

쿠버네티스 공식 홈페이지 인용
예를 들어, 3개의 레플리카로 실행되는 스테이트리스 이미지-처리 백엔드를 생각해보자. 이러한 레플리카는 대체 가능하다. 즉, 프론트엔드는 그것들이 사용하는 백엔드를 신경쓰지 않는다. 백엔드 세트를 구성하는 실제 파드는 변경될 수 있지만, 프론트엔드 클라이언트는 이를 인식할 필요가 없으며, 백엔드 세트 자체를 추적해야 할 필요도 없다. 서비스 추상화는 이러한 디커플링을 가능하게 한다.

쿠버네티스 공식 홈페이지에는 이렇게 나와있다.
말이 굉장히 어렵게 들리지만 조금씩 뜯어서 해석해보면 다음과 같다.

일단 디커플링에 대한 설명은 아래에서 확인할 수 있으며,

이미지를 처리하는 백엔드 서버를 3개(레플리카3개)를 띄워놓았다고 가정한다면
이 서버들은 모두 한 역할을 하기 때문에 어느 서버(파드)가 일을 하든 상관이 없다
-> 즉, 하나가 죽고 새로 만들어져도 프론트엔드(요청을 보내는 쪽)에서는
"어떤 서버가 실제로 일하고 있는지"를 알 필요가 없다는 것이다.

쿠버네티스의 Service는 이렇게 디커플링을 가능하게 해주는데,
-> 실제 파드가 바뀌더라도 프론트엔드는 항상 같은 주소(DNS name)로 요청을 보낼 수 있게 하여
서로 직접 연결 상태를 관리하지 않아도 되게 해준다.

서비스에 대한 한마디 정리
서비스는 백엔드 파드들이 바뀌어도 프론트엔드(연결을 보내는 쪽)가 끊김 없이 연결될 수 있도록 도와주는 역할을 한다.

디커플링 vs 커플링

디커플링(Decoupling) vs 커플링(Coupling)

• 디커플링 : '결합을 느슨하게 만든다'라는 것이다.
  즉, 한쪽이 바뀌어도 다른 쪽이 영향을 받지 않도록 분리하는 것을 말한다.
  ex)프론트엔드가 백엔드의 구체적인 IP나 구조를 몰라도 요청을 보낼 수 있다면,
  이건 “디커플링”이 잘 되어 있는 상태다.
  
  
• 커플링 : '결합되어 있다'라는 것이다.
  즉, 한쪽이 바뀌면 다른 쪽도 영향을 받는 상태를 말한다.
  ex)프론트엔드가 백엔드 파드의 IP주소를 직접 알고 있어야 통신이 가능하다면,
  백엔드의 파드가 새로 만들어질 때마다 프론트엔드 코드를 수정해야 한다.

selector을 쓰지 않는 서비스

링크: 셀렉터가 없는 서비스

에서 그 예시를 확인할 수 있다.

정리해보자면

• 프로덕션 환경에서는 외부 데이터베이스 클러스터를 사용하지만, 테스트 환경에서는 자체 데이터베이스를 사용한다.
• 한 서비스에서 다른 네임스페이스 또는 다른 클러스터의 서비스를 지정하려고 하는 경우
• 워크로드를 쿠버네티스로 마이그레이션하는 경우, 쿠버네티스에서는 백엔드의 일부만 실행한다.
  -> 위 세 시나리오에서는 파드 셀렉터 없이 서비스를 정의 할 수 있다

참고자료
[쿠버네티스 공식 홈페이지 - Service]
https://kubernetes.io/ko/docs/concepts/services-networking/service/
[CNF - 8.2 서비스 (Service): 파드 집합에 대한 안정적인 엔드포인트 제공]
https://www.cncf.co.kr/ebook/kubernetes/part-3-mastering-core-kubernetes-objects/chapter-8-service-discovery-and-networking/8-2-kubernetes-service/