[쿠버네티스 기초 13] Service
in Kubernetes
이 포스팅은 Udemy의 Certified Kubernetes Administrator with Practice Tests 강의를 정리한 내용입니다.
Service 에 대해 알아봅시다.
Service
- Pod 는 별도의 도커 네트워크 공간에 있기 때문에 외부 사용자는 접근할 수 없음
- 이렇게 Pod 에 대한 외부 접근을 위해
Service라는 것이 필요함 - 아래 그림에서 보면, 사용자는 30008번 포트로 접근하고 Service 는 이를 10.144.0.2 로 포워딩 함 (NodePort)
Service 종류
NodePort
내부 Pod 가 외부에서 접근 가능하도록 함
ClusterIP
클러스터 내부에 가상의 IP를 생성하여 서로 다른 서비스 간 통신이 가능하게 함
LoadBalancer
외부 IP를 가지고 있는 로드밸런서를 할당 (보통 클라우드에서 사용)
NodePort
targetPort
- Pod 에서 LISTEN 하고 있는 포트 (80)
Port
- Service 가 가지는 포트 (80)
- Service 는 클러스터 내에서 하나의 가상 서버처럼 동작. 때문에 IP 주소(ClusterIP)도 있고 포트도 있음
NodePort
- 노드에서 LISTEN 하고 있는 포트 (30008)
- 외부 사용자가 접근하는 포트
- 기본적으로 30000~32767 번이 할당됨
Service 생성
spec 작성이 제일 핵심
apiVersion: v1
kind: Service
metadata:
name: myapp-Service
spec:
type: NodePort
ports:
- targetPort: 80
port: 80
nodePort: 30008
selector:
app: myapp
type: front-end
- 여기서
port만 필수파트임.targetPort는 생략 시port와 같은 포트로 설정됨 nodePort생략 시, 30000~32767 에서 랜덤하게 할당됨ports는 리스트 타입이기 때문에 하나의 서비스에서 여러 개의 포트를 매핑할 수 있음selector를 이용해서 pod 의 label과 매칭함- label 과 매칭되는 pod 가 여러 개일 경우, 트래픽이 랜덤하게 분산됨
- 복수 개의 pod 가 여러 노드에 걸쳐있는 경우에도 작동은 똑같음. 아래 그림처럼 서비스는 모든 노드에 걸쳐서 생성되기 때문에, 클러스터 내에 있는 어떤 노드의 IP 주소와 Port 로도 접근 가능
ClusterIP
- 위 그림처럼 각기 다른 티어 간에 서로 통신이 필요함
- pod 는 유동 IP 주소를 가지기 때문에 안정적인 접근이 불가
- 또한 같은 종류의 pod 가 여러 개인 경우 어느 쪽으로 접근할지 결정하는 것도 어려움
- Service 는 이렇게 관련 있는 Pod 들을 그룹화해서 단일 인터페이스를 제공함
- 덕분에 각 어플리케이션은 이런 통신 이슈를 걱정하지 않고 scale 조정이 가능
- 보통은 Service의 이름 혹은 IP 주소로 접근하는데, 이 때 사용하는 타입이
ClusterIP
예제 YAML 파일
apiVersion: v1
kind: Service
metadata:
name: back-end
spec:
type: ClusterIP
ports:
- targetPort: 80
port: 80
selector:
app: myapp
type: back-end
LoadBalancer
- 하나에 서비스에 대해 사용자가 접근할 수 있는 URL 은 노드 수만큼 존재함 (node01:30001, node02:30001, …)
- 서비스마다 단일 URL 로 제공하고 싶은 경우 (http://example.com) 에는 VM 를 하나 더 구해서
HA Proxy나nginx같은 로드밸런스를 앞 단에 두어 트래픽을 라우팅 함 - On Prem 환경이 아닌 클라우드 환경(GKE, AWS, .etc)에서는 그 플랫폼 자체적으로 제공하는 Load Balancer 를 이용할 수 있음
- 클라우드 환경에서는
spec.type만 LoadBalancer 로 세팅하면 됨
