1. what is k8s service

응용 프로그램 내부 및 외부의 다양한 구성 요소 간의 통신을 가능하게하는 객체

1. web, was, db 3티어 구성에서 각 서비스 그룹 간의 연결을 가능하게 함(내부→내부)
2. 사용자가 외부에서 web front를 호출 가능하게 함(외부→내부)

2. Service 종류 - 3가지

1. nodeport

   • 외부에서 호출할 때, 노드의 내부 포트로 외부에서 접근 가능하게 함

2. cluster ip

   • 클러스터 내부에서 서비스끼리 통신할 때, selector로 동일한 역할의 여러 파드를 하나로 묶어서 호출할 수 있는 인터페이스 역할

3. load balancer

   • 동일한 역할의 파드 여러 개가 여러 노드에 걸쳐 띄워진 경우 특정 파드의 ip를 입력해서 호출하는 것은 불편하니까, 로드밸런서라는 단일 인터페이스로 호출
   • k8s가 csp에서 지원하는 로드밸런서를 사용할 수 있는 경우, 그 csp 로드밸런서를 사용하여 외부 호출 할 수 있음
   • 로드밸런서를 지원하지 않는 환경일 경우, nodeport 를 사용하는 것과 같은 효과

2-1. Nodeport

사용자 → 노드포트 → 서비스 → 파드
targetport, port, nodeport

pod.yml의 labels를 service.yml의 selector에 사용하여 서비스와 파드를 연결시킴

서비스는 생성 즉시 클러스터에 공유되어 모든 노드가 접근할 수 있게됨

포트 설명

1. target port
   • 파드의 포트 번호
   • 서비스가 이 포트로 요청을 전달
2. port
   • 서비스 자체에 대한 포트 번호
3. nodePort
   • 외부에서 웹 서버를 호출하기 위해 사용
   • 30000 ~ 32767 포트만 사용 가능

nodeport는 보안상의 이유로 권장되는 방식이 아님. 아래 2가지 방식이 권장됨

• LB service 사용하기
• Ingress : 클러스터 외부에서 내부로 http, https 트래픽을 과닐하는 방법. Ingress 컨트롤러, Ingress 리소스 정의 하는 등 복잡함 → 이 강의에서 다루지는 않음

yaml

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  type: NodePort
  ports:
  - targetPort: 80
    port: 80
    nodePort: 30008
  selector:
    type: myapp

2-2. Cluster IP

모든 파드에는 ip가 할당되어 있음
그러나 이 파드 ip는 고정된 것이 아니라, 다운/생성시 변경될 수 있음
그래서 파드 ip로는 애플리케이션끼리 통신을 보장 할 수 없음
클러스터 내부의 애플리케이션끼리 확실하게 통신 할 수 있도록 cluster ip라는 개념을 사용함

cluster ip
파드를 그룹화하고 그룹 내의 파드에 접근하기 위한 단일 인터페이스
들어온 요청은 서비스에 속한 파드 중 하나로 전달

yaml

apiVersion: v1
kind: Service
metadata:
  name: redis
spec:
  ports:
  - port: 6379
    targetPort: 6379
  selector:
    name: redis-pod
    app: demo-voting-app

• cluster IP는 default 이기 때문에 spec.type을 명시하지 않아도 됨
• selector는 pod의 label을 동일하게 사용함(nodeport와 마찬가지)
  
  

2-3. Load Balancer

위에서 배운 것 처럼 사용자는 외부에서 nodeport를 사용하여 서비스를 호출할 수 있다.

이 때, http://노드ip:nodeport 처럼 호출하면 되는데,
모든 노드가 서비스를 공유하고 있으므로 이 노드ip에는 모든 노드ip를 사용할 수 있다.
(http://192.168.56.70:30035 = http://192.168.56.71:30035 = http://192.168.56.72:30035 = http://192.168.56.73:30035)

그러나 사용자는 이런 방식을 원하지 않는다. http://ex-front:30000처럼 단일 url을 사용하기를 원한다.

2가지 방식으로 이 요구사항을 구현할 수 있다.

1. LB 목적의 VM을 생성하고, HAProxy 또는 nginx 같은 로드밸런서를 구성하는 것
   • 관리포인트가 많고 구성하기 귀찮다
2. CSP(AWS, GCP, Azure)에서 제공하는 LB를 활용하는 것
   • 상대적으로 간단하다
   • front 서비스 type을 LB로 설정하기만 하면 됨