[Kubernetes] 파드를 외부로 노출하기: 서비스(Service)

🔊 해당 포스팅은 시작하세요! 도커/쿠버네티스 서적을 읽고 개인적인 목적 하에 작성되는 글입니다. 포스팅에 사용되는 모든 자료는 제가 직접 재구성하였음을 알립니다.
 

Kubernetes

---

이번 포스팅에서는 저번 포스팅에서 소개한 쿠버네티스 기초 개념에 포함되는 서비스(Service)라는 오브젝트에 대해서 알아본다. 저번 포스팅 마지막에 배운 디플로이먼트라는 오브젝트를 활용하면 동일한 역할을 하는 파드 여러개를 한 번에 생성하거나 삭제하고, 파드의 생애주기까지 관리해주는 등 손쉽게 레플리카셋(파드들의 모음)을 관리할 수 있었다. 하지만 디플로이먼트가 수행하지 못하는 것이 한 가지 있는데, 외부(외부라 함은 로컬 또는 쿠버네티스 클러스터의 외부)에서 파드로 접근이 불가능한 것이다. 이를 가능하도록 하기 위해서 서비스라는 오브젝트를 별도로 생성해주어야 하는데, 이번 시간에는 이 서비스라는 것에 대해서 배워보도록 하자.

1. 외부에서도 파드에 접근을 가능하게 하는 오브젝트, 서비스!

저번 포스팅에서 파드, 레플리카셋을 배우면서 작성한 YAML 파일을 보면 파드 템플릿 영역에서 파드의 애플리케이션이 사용할 포트번호를 containerPort 라는 항목으로 정의해주었다. 하지만 이것을 정의해주었다고 해서 외부에서도 해당 파드로 접근이 가능하다는 것은 아니다. 이를 위해 서비스라는 오브젝트는 파드에 접근하기 위한 규칙을 정의하게 된다. 서비스에는 많은 기능이 있지만, 핵심 기능만 열거해보면 아래와 같다.

 

• 여러 개의 동일한 역할을 하는 파드에 쉽게 접근이 가능하도록 고유한 도메인 이름을 부여
• 여러 개의 동일한 역할을 하는 파드에 접근할 때, 요청을 분산하는 로드 밸런서 기능을 수행
• 클라우드 플랫폼의 로드 밸런서, 클러스터 노드의 포트 등을 통해 파드를 외부로 노출

위에서 열거한 기능 외에 서비스는 더 다양한 기능을 갖고 있지만, 지금은 위 3가지 기능만 알아두도록 하자. 참고로 서비스를 사용하지 않고도 클러스터 내부의 파드들 간에 통신이 가능한 것은 처음에 쿠버네티스 설치할 때 같이 설치한 calico 같은 네트워크 플러그인 덕분이다. 이 calico가 자동으로 오버레이 네트워크를 적용하여 서로 다른 노드들의 파드 간에 통신이 가능한 것이다. 이는 도커 스웜때와 비슷하다.

 

서비스에는 종류가 몇 가지 있다. 그래서 서비스를 정의할 때 설정하는 서비스 종류에 따라 파드를 외부에 노출시킬 수 있고 없고가 달라진다. 이에 대해 하나씩 알아보도록 하자. 우선은 파드랑 서비스를 연결해보기 위해, 아래 내용의 YAML 파일로 디플로이먼트를 생성해보자. 파드 생성 시 사용하는 이미지는 파드의 호스트 이름을 반환하도록 직접 제작안 책 저자분의 커스텀 이미지이다.

 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: zedd-hostname-deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webserver
  template:
    metadata:
      name: zedd-webserver
      labels:
        app: webserver
    spec:
      containers:
      - name:  zedd-webserver-pod
        image: alicek106/rr-test:echo-hostname
        ports:
        - containerPort: 80

 

그러면 이제 서비스의 종류에 대해 하나씩 짚어보자.

2. 쿠버네티스 내부에서만 접근이 가능한 서비스, ClusterIP 유형

ClusterIP는 이름에서 느낄 수 있는 것처럼 쿠버네티스 클러스터 내부에서만 파드들에 접근할 때 사용하는 서비스 유형이다. 그러면 ClusterIP 유형의 서비스를 설정하기 위한 YAML 파일을 살펴보자.

 

apiVersion: v1
kind: Service
metadata:
  name: zedd-hostname-svc-clusterip
spec:
  ports:
  - name: web-port
    port: 8080
    targetPort: 80
  selector:
    app: webserver
  type: ClusterIP

 

서비스를 배포할 때도 kubectl apply 명령어를 동일하게 사용하면 된다. 이제 위 YAML 파일 내용의 각 항목을 살펴보자.

 

• spec.selector : 해당 서비스에서 어떠한 라벨을 갖는 파드에 접근할 수 있게 만들 것인지 결정한다. 여기서 '라벨'이라는 것은 저번 포스팅에서 배운 레플리카셋과 파드 간의 연결을 수행하는 즉 파드 템플릿 내에 정의하는 LabelSelector를 의미한다.
• spec.ports.port : 생성된 서비스는 쿠버네티스 내부에서만 사용할 수 있는 고유한 IP(ClusterIP 라고 부름)를 할당 받는데, port 항목에는 그 고유한 IP에 접근할 때 사용할 포트번호를 설정한다.
• spec.ports.targetPort : 위에서 디플로이먼트를 배포할 때 적용한 YAML 파일 즉, 파드 템플릿 내에서 정의한 파드가 사용할 포트 즉, containerPort 항목에 설정된 포트번호와 동일해야 한다.

 

서비스를 잘 생성했다면, 아래 명령어로 생성된 서비스 목록을 출력해보자.

 

 

그런데 우리가 직접 생성하지 않은 kubernetes 라는 이름의 서비스가 존재하는 것을 볼 수 있다. 이것도 ClusterIP 유형인 것을 알 수 있다. 이 서비스는 파드 내에서 쿠버네티스의 API에 접근하기 위한 서비스를 의미한다. 지금 상황에서는 중요한 내용이 아니니 스킵하자.

 

그러면 우리가 생성한 ClusterIP 서비스를 활용해서 파드에 접근하는 방법에 대해 알아보자. 방법은 간단하다. 위 출력화면에서 CLUSTER-IP 와 PORT(S) 항목에 명시되어 있는 값들을 이용해서 요청을 하면 된다. 다른 워커 노드로 접속해서 해당 "IP:포트번호" 형태로 요청을 보내보자.

 

 

curl 요청을 보냈을 때, 리턴되는 response를 보면 파드의 고유한 이름이 리턴된 것을 볼 수 있다. 이는 아까 위에서 디플로이먼트를 생성할 때 같이 생성된 파드들이다. 실제로 마스터 노드로 이동애서 파드 목록을 출력해보면 이름이 동일한 것을 알 수 있다.

 

 

또 한 가지 살펴볼 것은 curl 로 요청을 보낼 때마다 response 되는 파드의 이름이 매번 달라지는 것을 알 수 있다. 즉, 서비스와 연결된 여러 개의 파드에 자동으로 요청이 분산되는 것이다. 이는 서비스를 생성할 때 별도의 설정을 하지 않아도 서비스는 연결된 파드들에 대해 로드 밸런싱을 수행한다. 

 

그리고 위에서는 IP 및 포트번호로 요청을 보냈지만, 생성한 ClusterIP 서비스 이름 자체만으로도 접근할 수 있다. 이것이 가능한 이유는 쿠버네티스 내부적으로 DNS를 구동하고 있고, 파드들은 자동으로 이 DNS를 사용하도록 설정되기 때문이다. 구체적으로는 CoreDNS 서버를 이용하는데, 주의할 점은 서비스 이름으로 접근하려면 특정 파드 내부에서 요청을 보낼 때만 가능하다. 만약 호스트 환경에서 테스트한다면 서비스 이름으로는 접근이 불가능하고 서비스의 ClusterIP 주소로만 접근이 가능하다.(저자분 Q&A)

3. 파드를 외부에 노출하는 서비스, NodePort 유형

이번에는 클러스터 외부에서도 파드에 접근할 수 있는 NodePort 유형의 서비스에 대해 배워보자. NodePort 서비스는 모든 노드의 특정 포트를 개방해 서비스에 접근하는 방식이다. NodePort 유형의 서비스를 정의하는 YAML 파일 내용은 아래와 같다. ClusterIP 일 때의 YAML 파일 내용과 거의 동일하고, type 항목만 달라진다.

 

apiVersion: v1
kind: Service
metadata:
  name: zedd-hostname-svc-nodeport
spec:
  ports:
  - name: web-port
    port: 8080
    targetPort: 80
  selector:
    app: webserver
  type: NodePort

 

위 파일 내용을 작성하고 NodePort 서비스를 생성해보도록 하자.

 

 

생성한 NodePort 서비스를 출력해보자. 주목할 부분은 PORT(S) 항목에 31033 이라는 포트번호가 추가되었다. 이는 모든 노드에서 동일하게 접근할 수 있는 포트를 의미한다. 즉, 클러스터의 모든 노드에서 내부 IP 또는 외부 IP를 통해 31033 포트로 접근하면 동일한 서비스에 연결이 가능하다. 실제로, 모든 노드에서도 접근이 가능한지 살펴보자. 우선 노드의 내부 IP가 무엇인지부터 살펴보자.

 

 

이제 각 노드의 내부 IP 번호와 포트번호 31033을 결합해서 요청을 날려보자. 잘 응답이 되고 있다.

 

 

만약 GKE나 EKS를 쓰고 설정을 한 것이라면 각 노드의 랜덤한 포트에 접근하기 위해 별도의 방화벽 설정을 추가해주어야 한다. 이는 책 내용의 322페이지를 참고하자. 

 

위 YAML 예시에서는 모든 노드에 공통적으로 개방할 포트 번호를 랜덤으로 설정하도록 했지만, 이것도 명시적으로 설정할 수 있다. YAML 파일 내 spec.ports.nodePort 항목에 별도로 명시해주면 된다. 

 

그런데, NodePort 유형의 서비스여도 CLUSTER-IP 항목에 내부 IP가 할당되어 있는 것을 볼 수 있다. 이는 NodePort 서비스가 ClusterIP의 기능을 포함하고 있기 때문이다. 그래서 NodePort 서비스를 사용하면 내부 네트워크와 외부 네트워크 양쪽에서 접근이 가능해지는 것이다. 

 

그런데 실제로 운영 환경에서 NodePort 서비스를 외부에 제공하는 경우는 많지 않다. 왜냐하면 NodePort에서 포트번호를 80 또는 443으로 설정하기에는 적절지 않기 때문이다. 쿠버네티스의 설계 상,  NodePort가 사용할 수 있는 포트번호는 기본적으로 30000 ~ 32767 번 사이로 제한이 된다. 하지만 80번이나 443번은 해당 번호의 범위 밖에 있다. 또한 SSL 인증서 적용, 라우팅 등과 같은 복잡한 설정을 NodePort 서비스에 적용하기가 어렵기 때문이다. 따라서, NodePort 서비스 그 자체를 통해 서비스를 외부로 제공하기보다는 인그레스(Ingress)라고 부르는 쿠버네티스의 오브젝트에서 간접적으로 사용되는 경우가 많다. 인그레스에 대해서는 추후에 배울 예정이지만, 여기서는 '외부 request 요청을 실제로 받아들이는 관문'으로만 개념적으로 이해해두자. 인그레스 오브젝트는 아래에서 배울 LoadBalancer 와 NodePort를 합쳐서 사용할 수 있다.

4. 클라우드 플랫폼의 로드 밸런서랑 연동이 가능한 서비스, LoadBalancer 유형

다음은 서비스 생성과 동시에 로드 밸런서를 새롭게 생성해 파드와 연결하는 서비스이다. NodePort 서비스를 사용하면 각 노드의 IP를 알아야만 파드에 접근이 가능했지만, 이번에 배울 LoadBalancer 유형의 서비스는 클라우드 플랫폼으로부터 도메인 이름과 IP를 할당 받는다. 클라우드 플랫폼에 의존하다 보니 반드시 로드 밸런서를 동적으로 생성하는 기능을 제공하는 GCP, AWS와 같은 클라우드 플랫폼 환경에서만 사용할 수가 있다. 물론 온프레미스 환경에서도 MetaLB라는 오픈소스 프로젝트를 이용할 수도 있긴 하지만 MetalLB는 쿠버네티스의 공식 프로젝트가 아니라서 유지보수가 지속적이지 않을 수 있다는 점을 유의해야 한다. 필자도 GKE, EKS를 사용하는 환경이 아니기 때문에 LoadBalancer 서비스를 사용하는 방법은 책 원본 내용을 참고하도록 하자. 여기에서는 생략하도록 하겠다.

4-1. 트래픽 분배 방식을 결정하는 속성, externalTrafficPolicy

대신 여기서는 LoadBalancer 서비스를 사용하게 됨으로써 트래픽을 분배하는 정책을 결정하는 속성 값에 대해 배워보려고 한다. 바로 externalTrafficPolicy 라는 속성값이다. 속성 값에 대해 배우기 전에 LoadBalancer 유형의 서비스를 이용했을 때, 외부로부터 들어온 트래픽을 어떻게 각 노드, 각 파드에 분산시키는지부터 알아보자. 아래 그림을 보자.

 

 

우리가 주목할 부분은 워커 노드 1 즉, Node 1로 들어온 외부 트래픽 요청이 (1)번 루트를 타지 않고 굳이 (2)번 루트를 타는 방식이다. 이렇게 되면 불필요한 네트워크 홉(네트워크 홉이란)이 한 단계 더 발생하게 되고 노드 간의 리다이렉트가 발생하게 되어 트래픽의 출발지 주소가 바뀌는 SNAT(SNAT이란)가 발생하게 된다. 이렇게 되면 클라이언트의 IP 주소 또한 보존되지 않는 문제가 발생한다.

 

이러한 트래픽 분배 방식을 변경하기 위해 우리는 서비스 생성 시 설정하는 YAML 파일에서 externalTrafficPolicy 항목을 정의할 수 있다. 우선 위와 같이 기본적으로 설정되어 있는 방식은 Cluster 라는 방식이다. 하지만 이를 Local 로 변경하면 파드가 생성된 노드에서만 파드로 접근할 수 있게 된다. 다시 말해, 위 예시로 들면, Node 1로 들어오게 된 요청들은 모두 Node 1 내의 파드들에게만 요청이 가도록 강제하는 것이다. 이렇게 하면 당연히 Cluster 방식에서 발생되었던 여러가지 문제들이 발생하지 않게 된다.

 

하지만 이러한 Local 방식이 무조건적으로 좋은 것은 아니다. 만약 각 노드에 파드가 고르지 않게 스케쥴링 되었다면 요청이 고르게 분산되지 않게 되어 각 파드가 받는 부하의 양이 동일해지지 않는다. 즉, 어떤 파드는 많은 양의 부하를 받게 되고, 다른 파드는 상대적으로 적은 양의 부하를 받게 된다. 아래처럼 말이다.

 

 

위 그림처럼 되면 워커 노드 3에있는 파드만 유일하게 트래픽의 50% 부하를 받게 된다. 이렇게 되면 자원 활용률 측면에서 부적절하다. 이렇게 Local 방식도 단점이 존재하기 때문에 트래픽 분배 방식 중에 정답은 없다. 각 상황에서 어떤 요소를 더 중요하게 고려하는지에 따라 트래픽 분배 방식을 결정하는 것이 좋다.

5. 파드가 외부 시스템과 연결되도록 하는 서비스, ExternalName 유형

다음으로 알아볼 서비스 유형은 쿠버네티스를 외부 시스템과 연동해야 할 때 사용하는 ExternalName 서비스이다. 이 서비스를 생성하면 서비스가 외부 도메인을 가리키도록 설정할 수 있다. 예를 들어, 아래와 같은 YAML 파일이 있다고 가정해보자.

 

apiVersion: v1
kind: Service
metadata:
  name: externalname-svc
spec:
  type: ExternalName
  externalName: my.database.com

 

위 파일로 서비스를 생성하게 되면 파드들은 externalname-svc 라는 이름으로 요청을 보낼 경우, 쿠버네티스의 내부 DNS가 my.database.com으로 접근할 수 있도록 CNAME 레코드를 반환한다. 다시 말해, 파드가 externalname-svc로 요청을 보내면 my.database.com에 접근하게 된다는 것이다. 이는 쿠버네티스 파드가 기존에 우리가 사용하던 외부 시스템에 접근해야 하는 상황에 매우 유용하게 사용할 수 있다.

 

그런데 방금 CNAME 레코드를 반환한다고 했는데, CNAME 레코드가 무엇일까? 작은 배경지식으로 알아두는 게 좋을 것 같아 정리해보려 한다. Canonical Name의 줄임말로, 도메인을 가리키는 다른 이름을 뜻한다. 예를 들어서, DNS에는 크게 아래와 같이 2개 종류의 매핑 값들이 있을 것이다. DNS 테이블이 아래와 같다고 해보자.

 

사용하는 도메인 이름	변환되는 실질적인 주소
externalname-svc	my.database.com
zedd-hostname-nodeport	11.22.33.44.55

 

두 번째 행부터 살펴보자. 우리는 아까 NodePort 서비스를 생성하면서 zedd-hostname-nodeport 라는 서비스 이름을 명시했고, 이는 ClusterIP와 매핑된다고 배웠다. 이렇게 특정 도메인 이름이 숫자 형태의 IP 주소로 매핑되는 것을 A 레코드라고 한다. 

 

반면에, 첫 번째 행처럼 특정 도메인 이름(externalname-svc)이 숫자 형태의 IP 주소가 아닌 또 다른 도메인 이름(my.database.com)으로 매핑되는 것을 CNAME 레코드라고 한다.

---

이렇게 해서 쿠버네티스의 기초 개념인 서비스까지 모두 다루어보았다. 다음 포스팅부터는 쿠버네티스 리소스의 관리와 설정을 다루는 방법에 대해 배울 예정이다. 다음 포스팅만 진행하고 나면 쿠버네티스의 기초는 모두 끝이 난다. 그 이후는 고급 기법에 적용되는 챕터들인데, 이는 지금 당장 필자에게 필요한 내용은 아니기 때문에 백로그 형태로 남겨놓으려고 한다.