쿠버네티스에서 서비스는 애플리케이션 간 통신, 외부 사용자와 애플리케이션의 통신을 가능하게 하는 역할을 담당한다.
위의 이미지에서 처럼, 각각 다른 애플리케이션을 담당하는 파드들이 있고 각 파드들이 모두 원활히 통신을 하여야 제대로 된 서비스를 유저에게 제공할 수 있다.
위와 같이 구성된 예시에서, 외부 사용자는 파드와 같은 내부 네트워크에 위치하고 있지 않기 때문에 일반적으로는 접속할 수 없는 것이 정상이다.
이러할 경우 외부 사용자가 내부 애플리케이션에 접근할 수 있는 방법은, 노드에 SSH로 접속한 뒤, 노드 내부에서 파드의 애플리케이션을 불러와 접속하는 방식으로 접근을 할 수 있다. 하지만 일반적인 외부 사용자에 대한 서비스는 이러한 방식으로 제공되지 않는다.
외부 사용자가 SSH 같은 접근 방식이 아닌, 바로 접근할 수 있도록 서비스를 구성하여야 한다.
위와 같이, 외부 사용자는 별도의 노드 연결 필요 없이 바로 파드 어플리케이션에 접속할 수 있어야 한다. 이 때 쿠버네티스의 서비스가 역할을 담당한다.
Services Type
NodePort : 노드의 포트에 서비스 포트를 설정하여 바로 서비스로 접근할 수 있도록 구성한다.
ClusterIP : 가상 IP를 생성하여 서비스 간 통신을 가능하도록 구성한다.
LoadBalancer : 로드밸런서를 앞단에 두어 부하 분산 및 서비스로 접근할 수 있게끔 구성한다.
NodePort 구성 방식에 대해 자세히 살펴봅니다.
위와 같은 구성일 경우를 가정한다. 3개의 포트가 위치하는 것을 확인할 수 있다. (30008, 80, 80)
TargetPort(1) : 실제 웹 애플리케이션을 담고 있는 파드는 80 포트를 사용한다.
Port (2) : 서비스는 노드 내부의 가상 서버와 같다. 클러스터 내부에는 고유 IP 주소가 할당되어 있는데, 해당 IP 주소를 위에서 언급하였던 서비스의 ClusterIP라고 한다. 이 ClusterIP가 사용하는 포트 역시 80 포트를 사용한다.
NodePort (3) : 노드 자체가 사용하는 포트로, 외부에서 웹 애플리케이션으로 접근할 때 사용하는 포트이다. 노드 포트는 30000~32767 범위 내에서 값을 가진다. 예시에서는 30008 포트로 설정되어 있다.
yaml 파일 작성 후 사용하는 명령어는 아래와 같다.
kubectl create -f service-definition.yaml => 서비스 생성
kubectl get services => 서비스 조회
부하 분산 및 고가용성을 목적으로 여러 파드를 사용하는 경우가 단일 파드를 사용하는 경우보다 많다.
이 때, 파드들은 모두 같은 label 을 가지고 있을 것이며 서비스는 해당 label 을 통해 파드를 식별하여 외부 사용자의 접근 요청을 전달한다. 즉, 여러 파드를 이용하지만 단일 파드때와 동일하게 동작하는 것이다. 추가적으로 별도 구성을 진행할 필요가 없다.
그렇다면 여러 노드를 사용하는 경우에는 어떤지 살펴본다. 서비스를 생성할 때, 쿠버네티스는 자동으로 모든 클러스터의 노드가 대상 포트를 매핑하도록 설정한다. 클러스터의 모든 노드들은 같은 포트 번호를 사용하게 된다.
종합하여 정리해보자면, 위 3가지 케이스는 전부 동일하게 동작한다고 이해할 수 있다. 파드가 추가되어도, 노드가 추가되어도 서비스는 자동으로 동일한 설정을 업데이트하여 외부 사용자가 새로운 파드, 노드에도 접근에 문제없도록 동작한다.
Cluster IP
일반적으로 서비스는 다양한 애플리케이션 파드들이 상호작용하며 동작한다. 프론트엔드 / 백엔드 / 데이터베이스 파드들이 나뉘어 상호 통신하며 동작하는 것이 일반적이다.
예시로는 위와 같은 구성이 있다. 이렇게 파드들이 종류별로 나뉘어 있을 때, 각각의 파드들은 다른 역할을 담당하는 파드들과 어떻게 통신을 하게 되는지 고민해보자. 일일히 다른 파드들의 IP로 통신하는 것은 매우 번거롭다.
쿠버네티스는 여기서, 동일한 역할을 하는 파드들을 묶어 단일 인터페이스인 가상 IP를 제공한다.
위의 이미지에서는 back-end 인터페이스와 redis 인터페이스가 라우팅 역할을 대신한다고 볼 수 있겠다.
Cluster IP definition file 생성
Cluster IP 역시 여느 다른 객체와 동일하게 definition 파일을 통해 생성할 수 있다.
각 요소들 중 눈여겨 봐야 할 요소는 아래와 같다.
types : ClusterIP
targetPort : 백엔드로 향하는 포트
port : 서비스가 들어오는 포트
객체 생성은 다른 명령어들과 동일하다.
kubectl create -f service-definition.yaml
Load Balancer
위에서 Nodeport 타입의 서비스를 학습했다. Nodeport 는 worker 노드의 포트를 이용하여 외부에서 애플리케이션에 접근할 수 있도록 하는 역할을 하였다.
예시로, 위와 같이 투표 앱과 결과 앱을 가진 파드들이 나뉘어 있다고 가정한다.
Nodeport 를 통해 학습했듯이, 이 애플리케이션들은 worker 노드의 포트를 통해 외부에서 접속이 가능하다. 그런데 위와같이 파드의 수가 많을 때, 유저는 어느 파드에 접근을 해야 하는지가 문제가 된다.
투표 앱에 접근하는 방법 4개, 결과 앱에 접근하는 방법이 4개이다. (IP와 포트의 조합)
그러나, 최종 사용자는 총 8개의 접근 URL에 대해 알아야 할 필요가 없다.
일반적으로 서비스는 1개의 도메인으로 서비스에 접근하게 되므로, 이 8개의 URL을 묶어줄 필요가 있다.
이 때, Load Balancer의 역할을 담당하는 VM을 생성 및 사용하여 묶은 뒤, 로드밸런서에 1개의 도메인을 매핑하여 서비스를 구성한다.
이에 적합한 애플리케이션으로는 nginx, AJ/Proxy 와 같은 것들이 있다.
쿠버네티스를 클라우드 환경에서 사용할 경우, 클라우드 벤더사의 로드밸런서 서비스를 매핑할 수도 있다. 쿠버네티스는 각 플랫폼에서 제공하는 LB를 지원하고 있다. 따라서 서비스를 정의하는 것도 간단하다.
type을 로드밸런서로 지정하고, targetPort / port / nodePort 만 설정해둔다면, 각 클라우드 플랫폼의 로드밸런서가 나머지 구성을 지원한다.
'IT > CKA' 카테고리의 다른 글
| CKA 준비과정 - Kubernetes 개념 (8) / Imperative vs Declarative (0) | 2023.05.09 |
|---|---|
| CKA 준비과정 - Kubernetes 개념 (7) / Namespaces (0) | 2023.05.06 |
| CKA 준비과정 - Kubernetes 기초 (5) / Deployments (0) | 2023.05.01 |
| CKA 준비과정 - Kubernetes 개념 (4) / ReplicaSets (1) | 2023.04.26 |
| CKA 준비과정 - Kubernetes 개념 (3) / Pod (0) | 2023.04.24 |