[Kubernetes Best Practice] 13. 외부 서비스와 쿠버네티스 통합

이 글은 Kubernetes Best Practice를 읽고 개인적으로 중요하다고 생각하는 부분과 잘 모르는 부분에 대해 공부한 내용을 작성한 글입니다.모든 내용은 책에 포함되어 있는 내용을 기반으로 작성하였으며 자세한 내용이 궁금하신 분들은 책을 구매해서 읽는 것을 권장드립니다.

최근 서비스 메시에 대해 알아보거나 쿠버네티스를 사용하고 공부하면서 가장 많이 들었던 생각은 이 방법이 최선인가? 라는 생각이었습니다. 이에 대한 궁금증을 해결하는데 도움이 될만한 책을 발견해서 읽어보고자 합니다.

---

이번 장에서는 쿠버네티스 클러스터와 외부 서비스를 통합하는 상황에 대하여 다루고 있습니다. 쿠버네티스에서 운영되는 대부분의 서비스는 VM 혹은 물리 머신에서 실행되는 서비스에 접근하거나, 다른 쿠버네티스 클러스에 존재하는 서비스와 연결괼 수도 있습니다. 

---

외부 서비스 사용

가장 일반적인 상황은 쿠버네티스 클러스터가 외부 서비스를 사용하는 경우입니다. 특히, 온프레미스로 구축되었던 서비스를 클라우드 네이티브 환경으로 바꾸는 경우가 이에 해당합니다. 쿠버네티스에서 외부 서비스에 접근하기 위해서는 기본적으로 서비스가 연결되어 있어야 합니다. 그리고 외부 서비스가 쿠버네티스 서비스처럼 검색되기 위해서는 쿠버네티스 DNS를 사용해 서비스를 검색할 수 있어야 합니다.

고정된 IP를 가지는 서비스

고정된 IP를 가지는 서비스의 경우, Selector가 없는 쿠버네티스 서비스를 사용함으로써 클러스터 DNS를 통해 검색되도록 만들 수 있습니다. 문서를 참고하면 다음과 같은 서비스를 생성할 수 있습니다.

Service.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

해당 서비스에 대한 Endpoint로 외부 서비스의 IP를 매핑할 수 있습니다.

Endpoint.yaml

apiVersion: v1
kind: Endpoints
metadata:
  name: my-service
subsets:
  - addresses:
      - ip: 192.0.2.42
    ports:
      - port: 9376

 

동적인 IP를 가지는 서비스

클라우드 환경에 배포되어있는 서비스와 같이 동적인 IP를 가지고 있는 서비스의 경우에는 위의 방법처럼 IP를 지정해줄 수 없습니다. 이런 경우에는 CNAME 레코드 기반 쿠버네티스 서비스를 사용합니다. CNAME 레코드는 DNS 주소와 서버의 IP가 직접 매핑되는 A 레코드와는 달리 또 다른 DNS 주소로 매핑하는 방법입니다. 

NAME                     TYPE                VALUE
--------------------------------------------------
bar.example.com.   CNAME            foo.example.com.
foo.example.com.   A                      192.0.2.23

즉, 서비스가 다른 DNS 주소로 매핑되는 CNAME 레코드 서비스를 생성하여 동적으로 IP주소가 변하는 외부서비스에 안정적으로 접근할 수 있습니다. 문서를 참고한 예제는 다음과 같습니다.

apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: prod
spec:
  type: ExternalName
  externalName: my.database.example.com

 

외부 DNS를 쿠버네티스가 해석할 수 없는 경우

외부 DNS 이름이 쿠버네티스 클러스터 네트워크 범위보다 큰 경우에는 쿠버네티스가 해석할 수 있지만, 그렇지 않은 경우에는 DNS 이름을 변환할 수 없습니다. 이런 경우에는 쿠버네티스 DNS의 설정을 변경해줘야 합니다.

쿠버네티스 문서에 따르면 v1.12.0 이후부터 kube-dns가 아닌 CoreDNS를 사용하는 것을 권장하고 있기 때문에 이에 대한 설정을 살펴보겠습니다. CoreDNS 서버는 kube-system 네임스페이스에 coredns라는 ConfigMap을 통해 DNS 서버 설정인 Corefile을 구성합니다. 외부 DNS 서버와 통신하도록 설정하는 방법은 다음과 같습니다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health {
            lameduck 5s
        }
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
        }
        prometheus :9153
        cache 30
        loop
        reload
        loadbalance
        forward . 172.16.0.1
    }    
    consul.local:53 {
        errors
        cache 30
        forward . 10.150.0.1
    }

여기서 forward와 consul.local을 살펴보겠습니다.

• consul.local : 만약 10.150.0.1에 위치한 Consul DNS 서버가 있고, 이에 대해 점미사가 .consul.local인 경우 DNS 조회를 Consul 서버에서 수행하도록 지정합니다.
• forward : 기본적으로 클러스터 내부의 DNS에서 찾지 못하는 경우 사전에 정의된 /etc/reslov.conf에서 찾게됩니다. 하지만 외부 DNS 서버를 사용하려는 경우 (위에 예제에서는 172.16.0.1이라고 가정) forward에 해당 DNS 서버 주소를 명시함으로써 외부 DNS 서버와 통신할 수 있습니다.

---

서비스 노출

클러스터 내부에서 외부 서비스를 사용하는 것과 마찬가지로 외부에서 클러스터 내부 서비스를 사용하는 경우도 존재합니다. 이를 위해서는 외부 어플리케이션과 쿠버네티스 Pod간에 라우팅 설정이 필요합니다.

내부 로드밸런서 사용 (클라우드)

가장 손쉬운 방법은 내부 로드밸런서를 사용하는 방법입니다. 기본적으로 클라우드 프로바이더는 로드 밸런서 타입의 서비스를 통해 외부 트래픽을 클러스터 Pod을 노출합니다. 하지만 VPC 내부에서만 사용되는 서비스의 경우 외부로 노출하는 것은 보안상 위험이 존재합니다. 이를 위해 내부 로드밸런서를 사용하여 VPC에 할당되는 내부 로드밸런서를 설정함으로써 VPC에만 노출할 수 있습니다.

클라우드 프로바이더에 따라  이를 사용할 수 있는 방법은 다음과 같습니다.

• AWS : service.beta.kubernetes.io/aws-load-balancer-internal: "true" 어노테이션 추가
• GCP : networking.gke.io/load-balancer-type: "Internal" 어노테이션 추가 

NodePort 사용 (온프레미스)

온프레미스에 구축된 서버의 경우에는 내부 로드밸런서를 사용할 수 없습니다. 이런 경우에는 클러스터 내 모든 노드의 해당 포트를 개방하는 NodePort 타입의 서비스를 사용해야 합니다. 클러스터 외부에서는 node-ip:port 형태로 서비스를 노출할 수 있습니다. 또한, 가상 IP를 가지는 로드밸런서를 구축해 서비스를 노출하는 것도 가능합니다.