[Kubernetes] Service 이해하기

- 목차

 

들어가며.

 

Kubernetes 의 Service 는 Pod 들을 네트워크적으로 묶어줍니다.

네트워크적으로 묶는다는 의미는 하나의 단일 IP 를 통해서 Pod 에게 트래픽을 전송할 수 있는 의미입니다.

이를 그림으로 표현하면 아래와 같습니다.

 

Service 는 Pod 1, Pod 2, Pod 3 을 네트워크적으로 대표하게 됩니다.

그래서 외부 트래픽이 Service 로 유입되면 Service 는 3개의 Pod 중 하나에게 네트워크 트래픽을 전달합니다.

 

이렇게 Service 를 Load Balancer 방식으로 사용하는 것이 일반적입니다.

그 외에서 여러가지 Service Type 이 존재하는데요.

이번 글에서 Service 에 대해서 알아보는 시간을 가지도록 하겠습니다.

 

Endpoint 와 Pod.

Kubernetes Service 는 Pod 들을 네트워크적으로 묶기 위해서 Endpoint 라는 리소스를 사용합니다.

Endpoint 는 Service 와 연결되는 Pod 들의 IP 를 저장하고 있습니다.

그리고 지속적으로 Pod 의 상태 변화에 따라서 Pod 의 IP 를 업데이트합니다.

이러한 구조를 그림으로 표현하면 아래와 같습니다.

 

Service 는 연결된 Pod 들을 찾기 위해서 Pod 와 IP 정보를 가지고 있는 Endpoint 를 활용하게 됩니다.

이러한 역할을 Service Discovery 라고도 부르죠.

 

Endpoint 는 어떻게 생성하는가 ?

Endpoint 는 Service 를 생성할 때에 자동적으로 생성됩니다.

Service 는 matchLabels 설정을 통해서 연결할 Pod 들을 설정하는데요.

이 과정에서 연결된 Pod 들의 IP 정보를 가진 Endpoint 가 생성됩니다.

 

Endpoint Controller.

그럼 Endpoint 는 어떻게 Pod 의 IP 를 저장할 수 있을까요 ?

Kubernetes 에는 여러 Built-in Controller 들이 존재합니다.

Endpoint Controller 는 Pod 의 상태 변경을 감지하고, Pod 의 IP 가 변경되면 Endpoint 의 정보를 업데이트합니다.

 

이렇게 Pod 의 변경을 감지하여 Endpoint 를 Update 하는 Reconcile Loop 을 수행하면서

Endpoint 의 정보는 최신의 상태를 유지합니다.

 

 

Kubernetes DNS.

Kubernetes 는 자체적인 DNS 시스템을 가집니다.

모든 Pod 와 Service 는 고유한 IP 를 가지는데요.

이 IP 에 매칭되는 도메인 네임을 가집니다.

그리고 도메인 네임을 결정하는 패턴 또한 존재합니다.

 

Kubernetes Domain Name Pattern.

도메인 네임을 가지는 주체는 Pod 와 Service 입니다.

이들의 Domain Name Pattern 은 다음과 같습니다.

 

Pod 의 도메인 네임은 다음과 같습니다.

PodIP . Namespace . pod . cluster . local

 

Service 의 도메인 네임은 다음과 같습니다.

ServiceName . Namespace . svc . cluster . local

 

이처럼 5개의 word 와 그 사이의 4개의 dot 들로 구성됩니다.

만약 api 라는 Namespace 에 auth-server 라는 Pod 가 존재하고, Pod 의 IP 가 10.1.0.163 이라면

auth-server 의 도메인 네임은 10-1-0-163.api.pod.cluster.local 입니다.

그리고 동일한 Namespace 에 auth-service 라는 Service 가 존재한다면,

auth-service 의 도메인 네임은 auth-service.api.svc.cluster.local 입니다.

 

그리고 cluster.local 과 같은 Root Domain 은 생략이 가능합니다.

pod 나 svc 와 같은 Main Domain 도 생략이 가능합니다.

그래서 일반적으로 auth-service.api 나 auth-server.api 와 같이 Service Name (Pod IP) 과 Namespace 의 조합으로 도메인을 표현합니다.

 

 

 

Pod 의 resolv.conf 살펴보기.

Pod 의 resolv.conf 파일에 대해서 살펴보도록 하겠습니다.

Pod 는 다른 Pod 나 Service 와 소통하기 위해서 DNS Resolving 과정을 수행해야합니다.

resolv.conf 파일 내부에 DNS Nameserver 의 주소와 Lookup 을 위한 설정들이 존재합니다.

 

간단하게 Pod 의 생성 후 resolv.conf 파일을 살펴보겠습니다.

cat <<EOF> /tmp/nginx.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
EOF

kubectl apply -f /tmp/nginx.yaml

 

위 명령어를 실행하게 되면, 아래 이미지처럼 nginx 라는 이름의 Namespace 하위에 2개의 Pod 가 생성됩니다.

 

 

아래 명령어를 통해서 Pod 의 resolv.conf 에 접근할 수 있습니다.

kubectl exec -n nginx nginx-deployment-6595874d85-h7b2n -- cat /etc/resolv.conf

search nginx.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.96.0.10
options ndots:5

 

우선 nameserver 는 Kubernetes DNS 의 네임서버의 IP 입니다.

coredns Pod 들의 Service 인 kube-dns Service 의 IP 가 적용됩니다.

 

 

search 지시자을 통해서 축약된 형식으로 DNS 를 사용할 수 있는데요.

동일한 Namespace 내부의 Service 또는 Pod 간의 통신이라면 Service Name 또는 Pod IP 만으로 통신할 수 있습니다.

"nginx.svc.cluster.local" 이 이러한 역할을 수행합니다.

 

그리고 서로 다른 Namespace 라면 "svc.cluster.local" 의 역할에 의해서

ServiceName.Namespace 또는 PodIP.Namespace 정보만으로 통신을 수행할 수 있습니다.

 

그리고 Root Domain 인 cluster.local 는 항상 생략이 가능합니다.