일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- docker
- elasticsearch
- DevOps
- Django
- EKS
- leetcode
- dockerfile
- FastAPI
- IAM
- asyncio
- EC2
- YAML
- POD
- 자바스크립트
- intervals
- 쿠버네티스
- event loop
- Kubernetes
- Service
- terraform
- ebs
- Python
- ansible
- asgi
- AWS
- Deployment
- IAC
- K8S
- github
- WSGI
- Today
- Total
궁금한게 많은 개발자 노트
[ k8s ] Service YAML 작성 본문
Service란
An abstract way to expose an application running on a set of Pods as a network service.
파드의 집합 위에서 실행 중인 application들을 network service로 노출시키는 추상적인 방법입니다.
쿠버네티스는 Pod들에게 자체 IP를 제공하고 Pod집합에 대해 단일 DNS이름일 제공하고, 이들 간에 부하를 분산시켜 줍니다.
Service는 Pod들의 논리적 집합과 그들에 접근하는 정책에 대한 추상화입니다.
Service object는 클러스터 내부에서 접근 가능한 port와 외부에서 접근 가능한 nodePort를 가집니다. 이 port를 통해 요청이 왔을 경우, service object에 설정된 selector를 이용하여 요청이 전달될 pod를 찾는데, spec.selector에 정의된 label을 가진 pod그룹을 찾고, load balancing설정에 따라 특정 pod에 요청이 전달됩니다.
Service가 필요한 이유
Service가 필요한 이유로는 각 Pod들은 자체의 ip를 가지고 있지만, deployment를 이용한다면 현재의 pod 집합들이 얼마 후의 pod집합들과 다를 수 있기 때문에서 시작됩니다. 만약 어떤 Pod집합들이 backend 기능을 수행하고 다른 Pod집합들이 frontend 기능을 수행하고 있어서 서로의 ip를 통해 통신을 하고 있다면 얼마 후 Pod재시작 등에 의해 ip가 변경된다면 어떻게 추적이 가능할지가 문제가 되어 Service라는 추상적인 개념이 필요합니다.
For example, consider a stateless image-processing backend which is running with 3 replicas. Those replicas are fungible—frontends do not care which backend they use. While the actual Pods that compose the backend set may change, the frontend clients should not need to be aware of that, nor should they need to keep track of the set of backends themselves.
Service는 Cluster IP라는 클러스터 안에서만 유효한 내부 IP를 할당 받고, selector에서 정의한 label을 가진 Pod들 중 하나에 명령을 수행하여 클라이언트가 요청한 작업을 Pod에 전달할 수 있습니다.
Defining a Service
Service에 의해 관리되는, target되어지는 pod들의 집합은 spec.selector에 의해 결정됩니다. service selector의 controller는 계속해서 selector에 명시한 label과 일치하는 pod들을 스캔하고, service name에 해당하는 endpoint 개체에 업데이트를 POST합니다.
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app.kubernetes.io/name: proxy
ports:
- name: name-of-service-port
protocol: TCP
port: 80
targetPort: http-web-svc
Service object의 name은 다음 규칙에 의해 작성되어야 합니다.
https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#rfc-1035-label-names
service는 어떤 incoming port와 targetPort를 매핑할 수 있으며, 편의를 위해 기본적으로 targetPort는 port필드와 동일하게 셋팅됩니다. pod들에 정의된 port name은 service에서 targetPort에서 name으로 referencing이 가능합니다.
추가로, service에서는 여러개의 포트 지원이 가능합니다. 또한 service 생성 시 nodePort를 설정할 수 있으며 설정하지 않으면 기본적으로 임의의 포트가 선택됩니다.
서비스가 생성되면 서비스 IP를 통해서도 접근이 가능하고, 노드의 IP와 nodePort를 통해서도 액세스가 가능합니다.
'DevOps' 카테고리의 다른 글
[ k8s ] 쿠버네티스 Role, RoleBinding (2) | 2023.02.16 |
---|---|
[ k8s ] kubernetes 개념 (node, control plane) (0) | 2023.02.13 |
[ k8s ] Deployment YAML (0) | 2023.02.07 |
[ k8s ] pod, deployment, service (0) | 2023.02.06 |
[ AWS ] ECR이란? (0) | 2023.02.05 |