쿠바네티스 서비스 기능
- pod 디스커버리 기능
- LB 기능
쿠바네티스 서비스 종류 3가지
- 클러스터 IP → 클러스터 내부에서만 접속 가능
- Node port → 클러스터 외부에서 접속 가능
- LB → csp만 지원 가능 (
type: LoadBalancer)
쿠바네티스 서비스 구성도
쿠바네티스 서비스 #1 - 클러스터 IP
기본적으로 쿠바네티스 클러스터 내에서, 동일 namespace에 존재한다면, 서비스들은 클러스터 IP로 통신 가능하다!
💡 서비스는 무조건 fqdn으로 클러스터 dns에 등록된다!!!
여기에서 주의해야할 점은, 클러스터 IP =! 파드 IP 라는 것이다.
쿠바네티스 클러스터 내에서 IP를 부여 받는 오브젝트는 pod, node, service, ingress가 있다.
각각 부여 받는 IP주소 명칭은 다음과 같다.
| 오브젝트 | IP 주소 명칭 | 기타 |
|---|---|---|
| pod | pod IP | 동일 namspace에 있는 다른 node 위에 있는 파드와 IP 주소로 통신이 가능하다. |
| node | node IP | <노드 이름>.<네임스페이스>.pod.cluster.local |
| service | cluster IP | <서비스 이름>.<네임스페이스>.svc.cluster.local |
| ingress | ingress controller의 외부 IP | ingress controller는 외부에서 내부 서비스로의 HTTP 및 HTTPS(7계층) 요청을 라우팅하는 기능 담당 |
쿠바네티스 node와 service는 생성될 때 자동으로 dns에 등록된다.
동일 namespace 안에서 통신할 때는 node와 service 모두 IP주소로 통신하지만 다른 namespace에 있는 node랑 service 와 통신할 때는 fqdn 사용해야 한다.
그 fqdn의 예시는 위에 표에 나와있다.
참고로, 동일 namespace에 있는 node 혹은 service가 통신할 때는
<서비스 이름>.<네임스페이스>형식으로 충분하다.
💡 service가 클러스터 IP로 통신하는 방법 2가지!
1. IP 주소 이용 → 동일 namespace에서만 가능
2. fqdn 이용 → 다른 namespace에 있는 service와 통신할 때
쿠바네티스 서비스 #2 - NodePort
'type: NodePort' 옵션
서비스가 클러스터 IP만으로 통신하면 클러스터 외부로 노출할 수 없다.
즉, 외부에서 서비스로 접근할 수 없다. 외부에서 클러스터 내부에 있는 서비스로 접근하도록 만들어줄 수 있는 서비스의 타입은type: NodePort이다.
Node port를 만들어도 클러스터 IP는 남아있다.
NodePort 구성도
구성도 해설) 노드 포트로 접속하면 서비스로 연결되고, 서비스는 파드를 로드밸런싱 해준다.
[type: NodePort 옵션을 사용한 서비스 야물 파일 예시]
apiVersion: v1
kind: Service
metadata:
name: mynginx
spec:
selector:
app: nginx
ports:
- port: 80
targetPort: 80
nodePort: 31000
type: NodePort하지만 이 옵션만을 지정해주면, 외부에서 서비스로 직접 접근할 수 없다는 단점이 있다.
서비스에 외부 IP가 생성되는지 확인해보자.
→ 해당 옵션을 추가해줘도, 서비스는 외부로 노출되지 않는 것을 볼 수 있다.
그러면 어떤 오브젝트가 외부로 노출된다는 것일까?
바로 node이다. node의 외부 IP로 클러스터 외부에서 접근 가능하다.
직접 눈으로 확인해보자!
→ 서비스의 백엔드인 pod를 가지고 있는 node를 찾아 외부 IP와 포트로 접속해보자!
→ 이 노드로 접속해보겠다.
→ 외부에서 클러스터 내부로 접속 가능한 것을 알 수 있다!
💡
type: NodePort옵션만 사용했을 때 문제점
1) 클러스터 외부에서 node로 직접 접근
2) node의 외부 IP를 알아야 클러스터 내부로 접근 가능
3) node의 LB 불가능
쿠바네티스 서비스 #3 - LB
1. 'nodePort: 31000', 'type: LoadBalancer' 옵션
GCP 는 LB 기능을 지원하기에, GKE에서 해당 옵션을 줘서 LB 기능을 사용할 수 있다.
위 옵션을 주면, node의 부하 분산도 가능하고, 외부에서 node로 직접 접근하지 않아도 된다!
다음은 위 2개의 옵션을 추가해준 서비스 야물 파일 예시이다.
apiVersion: v1
kind: Service
metadata:
name: mynginx
spec:
selector:
app: nginx
ports:
- port: 80
targetPort: 80
nodePort: 31000
type: LoadBalancer
→ 네트워크(L4) 부하 분산기가 생성된 것을 확인할 수 있다.
서비스에 LB 옵션을 주면 4계층 부하분산기가 생성되는데, 그 이유는 다른 글에서 다뤄보겠다.
→ 또한 백엔드로 노드들을 가지는 것을 확인할 수 있다.
→ 생성된 서비스도 확인해준 결과, 서비스에 외부 IP가 생긴 것을 확인할 수 있다.
→ 즉, 위에서 언급한 문제점들을 해결했다!
이제 LB의 외부 IP로 접속해보겠다!
→ 접속 가능하다! 이제 파드에도 고르게 접속 가능한지 살펴보자
접속해야하는 파드는 총 3개이다.
위 3개의 파드에 모두 접속 가능한지 확인해보자!
→ 3개에 파드에 모두 접속 가능한 것을 확인할 수 있다!
→ mynginx 파드도 LB되는 것을 확인할 수 있다!
💡 여기에서 문제점!!
LB된 node와 동일한 node 위에 있는 pod로 접속될 수도, 다른 node 위에 있는 pod로 접속될 수도 있다!
즉, Latency가 발생한다.
즉, Hop이 늘어난다.
✔️ Latency란?
네트워크에서 전송된 데이터가 도착하기까지 걸리는 시간
일반적으로 레이턴시는 데이터 패킷이 보내진 후 받는 곳에서 처리될 때까지의 시간을 의미한다.
✔️ Hop이란?
네트워크에서 데이터 패킷이 한 장비에서 다음 장비로 이동하는 것을 의미한다.
홉의 수는 데이터 패킷이 목적지에 도달하기 위해 지나가는 네트워크 장비의 수를 나타낸다.
2. 'externalTrafficPolicy: Local' 옵션
레이턴시를 줄이기 위해서 썼던 externalTrafficPolicy: Local 는 파드가 정확히 LB되지 않는다.
진입한 노드에 있는 파드들로 바로 연결해주기 때문이다.
이 설정의 목적은 클라이언트 ip를 유지하는 것이다.
[야물 파일 예시]
apiVersion: v1
kind: Service
metadata:
name: mynginx
spec:
selector:
app: nginx
ports:
- port: 80
targetPort: 80
nodePort: 31000
type: LoadBalancer
externalTrafficPolicy: Local이제 진입한 노드에 있는 파드들로만 접속되는지 확인해보자!
→ 같은 노드 위에 있는 myapp 파드로만 접속해야한다!
→ 해당 옵션을 줬지만, 동일 node에 있는 pod로 접속하지 않은 것을 볼 수 있다.
💡 이처럼,
externalTrafficPolicy: Local옵션은 동일한 노드에 있는 파드들로부터 외부 클라이언트의 접근을 유도하는 설정이다.
이 옵션을 설정하면, Kubernetes 서비스가 외부 클라이언트의 요청을 처리할 때, 가능한 한 클러스터 내 동일 노드에 있는 파드로 요청을 전달하려고 시도한다.
즉, 반드시 동일 node에 있는 pod로 접속하는 것은 아니다.
쿠바네티스 서비스 종류 정리
쿠버네티스 서비스의 종류는 3가지가 있다.
- 클러스터 IP
- NodePort
- LB
클러스터 IP는 서비스가 만들어질 때 자동으로 클러스터 dns에 등록된다.
동일 namespace에 있는 서비스에 통신할 때는 도메인 이름으로만 통신 가능하고,
외부 namespace에 있는 서비스에 통신할 때는 fqdn을 사용해야 한다.
쿠바네티스 서비스를 외부에서 접속 가능하게 만들어주기 위해, type: NodePort 옵션을 사용한다.
이를 사용하면 서비스 타입이 NodePort로 변경되어 서비스를 클러스터 외부에서 접속할 수 있다.
하지만 이 옵션을 주는 것 만은 문제점이 있다.
1) 노드의 외부 IP를 알아야 접속 가능한 것
2) 노드의 로드밸런싱이 불가능한 것
이다.
위와 같은 문제점을 해결하기 위해 등장한 것이 node 부하분산기(type: LoadBalancer)를 만들어 외부로 노출해주는 것이다.
여기에서, 이 부하분산기는 L4 장비에 속한다. IP주소와 포트, 그리고 TCP/UDP 프로토콜을 이용하여 로드밸런싱해주기 때문이다.
하지만 LB는 csp에서만 가능하다는 단점이 있기도 하다.
node 부하분산기를 생성해줘도, 문제점이 발생한다
지나친 레이턴시와 hop이 발생한다는 것이다.
이를 줄이기 위해 동일 node에 있는 pod로 접근을 유도하는 옵션인 externalTrafficPolicy: Local 를 줄 수 있다.
