✅ NodePort
-
외부에서 쿠버네티스 클러스터로 접속하는 가장 쉬운 방법.
-
지정된 고정 포트를 열고, 해당 포트를 통해 외부 트래픽을 내부 파드로 전달.
-
포트는 30000~32767 사이에서 사용.
🌊 흐름
🚄 외부 -> 노드 포트 -> 노드 포트 서비스 -> 타겟 포드
실제 배포 환경
노드 포트 -> 로드 밸런서 -> 인그레스(도메인 기반 라우팅) 순으로 발전한다고 한다.
-
로드 밸런서
클라우드 환경에서 `Service type: LoadBalancer` 사용하면, 클라우드 로드 밸런서가 자동 생성 -> 각 노드의 포트로 트래픽 분산. -
인그레스
선행 : controller, nginx 설치 되어야 한다. 로드 밸런서 + 인그레스 컨트롤러 하나의 ALB로 모든 서비스 라우팅 가능.
yaml
apiVersion: v1
kind: Service
metadata:
name: k8s-backend-gateway-nodeport
spec:
type: NodePort
selector:
app: k8s-backend-user
ports:
- protocol: TCP
port: 8080
targetPort: 8080
nodePort: 30080 -> 생략시 포트 번호 랜덤
아래 그림처럼 외부 접근 포트로 api 호출이 가능함을 알 수 있다!
✅ 로드 밸런서
- 쿠버네티스 아님.
- 클라우드 플랫폼과 통합되어 자동으로 외부 로드 밸런서를 생성하는 서비스.
- 노드 포트의 상위 개념.
- 외부 클라우드와 협력해서 작업. (당장 실습할 수 없음)
외부 브라우저 -> 로드 밸런서 (ALB 생성.) -> api gateway -> 내부 서비스로 라우팅
클라이언트는 로드 밸런서하고만 소통하면 됨.
엔드포인트
- 서비스와 파드 간의 연결은 Kubernetes DNS로 해결
- 엔드포인트 이름과 서비스 이름이 같아야 함.
- Kubernetes의 내부 DNS 시스템이 자동으로 서비스 IP로 매핑
✅ 배포한 서비스 version up 하기
에디터 코드 수정 -> commit, push -> jenkins 빌드 -> 쿠버네티스 yaml 수정
운영 되고 있는 Deployment가 v1-> v2로 업그레이드 되었다고 해보자.
원래 있던 v1의 리플리카셋 -> 리플리카 0 -> 파트 0으로 줄어들어 사실상 종료가 되고 (완전 삭제 되지는 않음.)
v2에 맞춰 리플리카셋 새로 생성 -> 파드 개수에 맞춰 실행
✅ 실습
목표
- api gateway, user-service, alim-service를 쿠버네티스 클러스터에 배포
- 내부 서비스 간 호출을 위해 feign client를 사용
- 외부 요청은 api-gateway로 통합 라우팅
cf. 네임스페이스는 디폴트로 설정!
✅ 쿠버네티스와 스프링 클라우드의 로드밸런싱 방식 차이
application-dev.yml
spring:
cloud:
gateway:
mvc:
routes:
- id: backend-user
uri: http://k8s-backend-user-service:8080
predicates:
- Path=/api/user/**
- id: backend-alim
uri: http://k8s-backend-alim-service:8080
predicates:
- Path=/api/alim/**
...Spring Cloud: lb://~ 처럼 lb(LoadBalancer) 접두어를 명시
Kubernetes: http://~처럼 일반 URI 형식 사용
차이점은 uri의 lb 표시 유무이다.
✔ 쿠버네티스는 Service 리소스 자체가 클러스터 내부 DNS, 로드밸런서 역할(추상화) -> 자동 분산 가능
✔ 반면, 스프링 클라우드는 자체 로드 밸런서 사용 -> 명시적으로 서비스 탐색 요청(서비스 디스커버리)
✅ 결론
노드 포트 : 외부에서 접근 가능한 포트 제공
서비스 : 파드 앞에 놓이는 네트워크 접근 포인트, 전화번호부
api-gateway : 라우팅, 보안, 요청 처리 등, 전화상담원
디플로이먼트, 서비스 yaml 필수!
