- 앱 외부와 내부의 컴포넌트 간의 연결을 가능하게 함
- 프론트와 백엔드 Pod group 간의 연결
- end user와의 연결
- DB와의 연결
서비스란, 노드상에 떠 있는 일종의 가상-서버같은 역할을 한다
192.168.1.2라는 IP를 가진 Node 위에 있는 Pod의 네트워크 범위가 10.244.0.0/24 라고 하고, Pod의 IP가 10.0.244.2라고 하자.
NodePort
NodePort 서비스는 노드에서 외부 IP로 들어오는 특정 포트에 대해 listen하고 있다가, 해당 포트로 들어오는 연결을 Pod의 포트로 포워딩하는 역할을 한다.
- TargetPort: Pod에서 Listen하고 있는 포트
- Port: NodePort 서비스의 포트
- ClusterIP: NodePort 서비스의 내부 IP
- NodePort: 실제 노드가 listen하는 포트 (기본값: 30000-32767)
apiVersion: v1
kind: service
metadata:
name: myapp-svc
//optional: labels
spec:
type: NodePort
ports:
- targetPort: 80
port: 80
nodePort: 30008
selector: # 어떤 Pod에 대해 포워딩 서비스를 제공할지 선택
app: myapp
type: frontend
만약 같은 label (app, type)을 가진 여러 Pod이 존재한다면 (예: 여러 개 떠 있는 웹 서버), 해당 Pod들 중에 하나가 랜덤으로 선택됨
- 일종의 로드밸런서 역할을 하게 되는
Pod가 여러 노드에 걸쳐 분산되어있을 경우:
- 하나의 서비스를 만들면 해당 노드들에 자동으로 같은 nodePort를 listen하는 service가 배포됨
- 따라서 같은 포트, 다른 IP로 접속하면 같은 종류의, 다른 노드에 분산되어 있는 Pod에 접속하는 것이 됨
주:
- targetPort를 지정하지 않는 경우 port와 동일한 값이 사용됨
- nodePort를 지정하지 않는 경우 남는 포트가 자동 지정됨
- 여러 개의 port mapping이 있을 수 있음, 예를 들어
spec: type: NodePort ports: - targetPort: 80 port: 80 nodePort: 30008 - targetPort: 443 port: 443 nodePort: 30443
ClusterIP
클러스터 내부에 가상 IP 주소를 만들어서 다른 서비스 간 (프론트와 백 등) 통신을 가능하게 한다.
Pod들에는 IP가 있다 - 하지만 이 IP들은 static IP가 아니다 (새로운 Pod가 생성되고 기존 Pod는 죽을 수 있음)
서비스를 통해 Pod를 그룹으로 묶고, 해당 그룹에 접근할 수 있는 단일 인터페이스를 제공할 수 있다 (예를 들어 backend 그룹, ...)
apiVersion: v1
kind: service
metadata:
name: myapp-svc
//optional: labels
spec:
type: ClusterIP
ports:
- targetPort: 80
port: 80
selector:
app: myapp
type: back-end
- targetPort: 백엔드가 노출될 포트
- port: 서비스가 노출될 포트
이렇게 하면, 단일 cluster IP나 서비스의 이름을 통해, 여러 Pod 그룹에 접근할 수 있다
NAME TYPE CLUSTER-IP
backend ClusterIP 10.96.0.1
Imperative Way
kubectl expose pod 포드명 --port=포트명 --name myapp-svc --type=ClusterIP
이 방법을 쓰면 Pods Label을 Selector로 사용한다. 또 6379:6379이다.
apiVersion: v1
kind: Service
metadata:
labels:
tier: db
name: myapp-svc
spec:
ports:
- port: 6379
protocol: TCP
targetPort: 6379
selector:
tier: db
type: ClusterIP
또는 kubectl create service ClusterIP myapp --tcp=6379:6379
- 이 방법을 쓰면 Pods Label을 Selector로 사용할 수 없고, 자동으로
app=myapp
셀렉터가 지정된다.
LoadBalancer
지원되는 클라우드 프로바이더에서 사용할 수 있는 로드 밸런싱 뭐시기
CKA는 벤더 뉴트럴한 시험이므로 이것은 출제되지 않는다
'콤퓨우터 > 필기: KodeKloud CKA 강의' 카테고리의 다른 글
44. Imperative v. Declarative (0) | 2024.05.14 |
---|---|
41. Namespaces (0) | 2024.05.14 |
29-32. ReplicaSet과 Deployment (0) | 2024.05.14 |
22. Pods with YAML (0) | 2024.05.14 |
16-20. kube-apiserver, kube-controller-manager, kube-scheduler, kubelet, kube-proxy (0) | 2024.05.14 |