쿠버네티스 STEP3 Service, NodePort, ClusterIP

ABTCEFG♪  안녕하세요, 여러분!

 

BTC_뚜벅이입니다.

 

이번 주부터 본격적으로 Service리소스에 대해  알아보는 시간을 갖도록 할게요.

 

---

 

1. Service는 왜 사용하는거지?

 

쿠버네티스 자체에도 Pod 생성할 때 네트워킹을 담당하도록 IP가 부여됩니다.

하지만 굳이 Service를 둬서 네트워크 통신을 담당하게 만드는 이유는 무엇일까요?

 

Pod는 언제든지 종료될 수 있는 리소스로 생각하기 때문에 불안정한 서비스 Endpoint를 제공합니다.

이 때문에 끊임없이 Pod의 Ip를 추적해야 하는데 이럴 필요없이 Service는 안정적인 서비스 Endpoint를 제공하기 때문에 Service를 사용하여 네트워킹을 합니다.

Service로 들어오는 트래픽을 Pod로 전달해주는 리버스 프록시와 같은 역할을 담당합니다.

 

리버스 프록시가 하는 역할이란 어떤 뜻일까요?

리버스 프록시란 클라이언트-서버 구조에서 서버로 전송되는 요청을 대신 받아 원래의 서버로 전달해주는 대리 서버를 의미합니다.

서버로 요청되는 부하를 분산시키고 보안을 높이는 용도로 사용됩니다.

반대로 포워드 프록시는 일반적인 프록시로 기관에 소속된 사람들이 웹사이트에 직접 방문하는걸 방지하도록 사내 네트워크를 앞단에 두어 특정 컨텐츠 접속 제한하는 역할을 합니다. 

 

 

2. 라벨링 시스템을 왜 사용해?

 

각 리소스의 관계를 loose coupled로 표현합니다.

이는 특정 리소스를 직접 참조하는 것이 아닌 간접 참조한다는 것을 의미합니다.

만약 간접이 아닌 직접 참조를 하게 되면 매번 새로운 Pod가 올라올때마다 Pod 정보를 Service에 등록 및 삭제해야 합니다.

그리고 특정 라벨을 가지고 있는 어떠한 Pod에도 트래픽 전달에 용이합니다.

 

 

3. Service DNS

 

Service DNS에 대해 이해하기 위해 간략하게 테스트를 하고 이야기 해볼게요!

 

kubectl run mynginx –image nginx –port 80
kubectl get pod -o wide

# myservice.yaml 
apiVersion: v1 
kind: Service 
metadata: 
  labels: 
    hello: world 
  name: myservice 
spec: 
  ports: 
  - port: 8080 
    protocol: TCP 
    targetPort: 80 
  selector: 
    run: mynginx

kubectl apply -f myservice.yaml
kubectl get svc # myservice svc IP 확인
kubectl get pod -o wide # pod IP 확인

# 셋 모두 같은 결과
kubectl exec client -- curl <Service IP>
kubectl exec client -- curl <Pod IP>
kubectl exec client -- curl myservice:8080 # myservice.defaultsvc.cluster.local

위의 명령어 모두 myservice.defaultsvc.cluster.local이라는 결과가 나옵니다.

 

도메인 주소 법칙은 <Service Name>.<Namespace>.svc.cluster.local이고

여기서 <Service Name>.<Namespace> 혹은 <Service Name>만 사용해도 됩니다.

 

4. Cluster DNS Server 동작 원리

 

Service Name을 도메인 주소로 사용 가능한 이유에 대해 알아볼게요!

이는 쿠버네티스가 제공하는 DNS 서버가 존재하기 때문이에요.

모든 Pod는 nameserver IP로 DNS 조회를 합니다.

 

cluster DNS 확인하는 절차는 아래 순서로 진행됩니다.

1) namespace kube-system 확인

2) ns kube-system & kube-dns label 확인

3) ns kube-system & kube-dns label 일치하는 pod 확인

# nameserver <IP> 확인 가능 
kubectl exec client -- cat /etc/resolv.conf 

# svc 조회, kube-dns 서비스 확인 
kubetctl get svc -n kube-system 

# label 정보 확인, k8s-app=kube-dns ... 
kubectl get svc kube-dns -n kube-system --show-labels 

# 매핑되는 Pod 조회, coredns-xxx Pod 조회됨 
kubectl get pod -n kube-system -l k8s-app=kube-dns

coredns는 쿠버네티스에서 제공하는 클러스터 DNS 서버입니다. 

모든 Pod들은 클러스터 내부, 외부 DNS 질의를 coredns를 통해 수행하게 됩니다.

이 때문에 자체적인 도메인 네임 시스템을 가질 수 있게 되는 겁니다.

 

여기까지가 쿠버네티스 Service에 대한 이론적인 필수 내용이었고 앞으로 Service 리소스에 대해 알아보려고 해요.

이번 주는 Cluster IP와 NodePort에 대해 알아보도록 할게요.

 

---

 

5. Cluster IP와 NodePort

 

1) Cluster IP

 Default Service type로 endpoint는 쿠버네티스 내부 클러스터에서만 접근 가능합니다.

쿠버네티스 클러스터 내부에 Pod level에서의 안정적인 Service endpoint 제공하며

Cluster IP를 사용하는 이점은 ClusterIP 기반으로 더 복잡한 네트워킹 수행가능(확장 위한 기본 빌딩블럭 사용)이 있습니다.

kubectl run cluster-ip --image nginx --expose --port 80 \
--dry-run=client -o yaml > cluster-ip.yaml

# cluster-ip.yaml
apiVersion: v1
kind: Service
metadata:
  name: cluster-ip
spec:
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 80
  selector:
    run: cluster-ip
--- # yaml 1개 파일 내에 2개 이상 리소스 표현할 때 사용하는 지시자
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: cluster-ip
  name: cluster-ip
...

kubectl apply -f cluster-ip.yaml
kubectl get svc cluster-ip -o yaml | grep type # type: ClusterIP 확인
kubectl exec client -- curl -s cluster-ip

 

 

2) NodePort

특정 포트를 Service 특정 포트와 연결시켜 외부 트래픽으로 전달합니다.

이를 가능하게 만들어주는 컴포넌트가 kube-proxy이고 NodePort의 범위는 30000-32767입니다.

NodePort는 외부에서 접근가능한지 확인하기 위해 테스트용도로 사용합니다.

NodePort의 중요한 기능으로 NodePort는 단지 Pod가 위치한 노드 뿐만 아니라 모든 노드에서 동일하게 서비스 endpoint를 제공한다는 점이 있습니다.

# node-port.yaml
apiVersion: v1
kind: Service
metadata:
  name: node-port
spec:
  type: NodePort
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 80
    nodePort: 30080 
  selector:
    run: nginx
---
apiVersion: v1
kind: Pod
...

kubectl apply -f node-port.yaml
kubectl get svc # NodePort - PORT 8080:30080 확인