23
안녕하세요,
오늘은 베스핀글로벌 DevOps실 구연수 님이 작성해 주신 ‘Pod와 Pod를 연결하는 Service’에 대해 알아보겠습니다 🙂
Pod.
Kubernetes의 궁극적인 목표는 Cluster 내 Worker Node로 구성된 머신 각각에 컨테이너 형식의 애플리케이션들을 배포하는 것이다.
– 하지만 k8s는 Worker Node에 직접 Container를 배포하지 않는다.
Pod
- container는 Pod로 캡슐화되어 있다.
- Kubernetes에서 우리가 생성할 수 있는 가장 작은 단위
- Pod는 기본적으로 container와 1:1 관계이다. (1:n 관계가 불가능한 것은 아니다.)
- 같은 application이 하나 더 배포되어야 한다면?
- 한 Pod에 컨테이너를 하나 더 추가하는 것이 아닌, 컨테이너를 담은 Pod를 하나 더 배포하여 환경에 분리된 2개의 Pod가 존재하게 한다.
- 만약 사용량이 늘어나고 현재 노드가 충분한 공간이 없다면?
- 클러스터의 물리적인 용량을 늘리기 위해 새 노드를 만들고 추가적인 Pod를 배포한다.
Multiple Container in a Pod
- 하나의 Pod는 여러개의 컨테이너를 가질 수 있다. -> 하지만 같은 종류의 container를 한 Pod 안에 두는 일은 거의 없다.
- 메인이 되는 하나의 application 컨테이너와 그를 보조하는 helper application 컨테이너가 하나의 Pod에 들어있다면?
- 이 두 컨테이너는 Pod의 LifeCycle을 공유한다.
- 둘은 같은 network를 공유하기 때문에 서로를 localhost로 부를 수 있다.
- 추가로 같은 저장 공간을 공유할 수도 있다.
Pod 생성
kubectl run nginx --image nginx # nginx pod 생성 명령어명령어에 따른 실행 순서 확인
1. 컨테이너를 담을 Pod 자동 생성
2. nginx docker 이미지 인스턴스를 배포
– `–image` 속성을 이용해 Docker hub 레파지토리(public이기에 가능)에서 확인 가능한 이미지를 다운로드 받는다.
Pod With Yaml
Yaml을 이용해 설정 파일을 만들어 Pod를 생성할 수 있다.
# top(root) level fields of configuration yaml file apiVersion:
kind:
metadata:
spec:
1. apiVersion
- 객체 생성에 사용하는 Kubernetes API Version
- value :
String - 객체 정보에 따라 알맞은 api version을 작성해주어야 한다.
- Pod : v1
- Service : v1
- ReplicaSet : apps/v1
- Deployment : apps/v1
2. kind
- 생성 객체 타입
- value :
String - 객체 타입 ex : pod, service, replicaset ….
3. metadata
- name, label 등등 객체의 구분자
- value : dictionary
4. spec
- 객체에 따라 제공해야 할 추가 정보들
- value : List or Array
- Why List? 특히 pod 내부에 여러 container가 있을 때, spec의 필드 container(하위에 name, image … )를 두 개 이상 정의해야 한다.
파일이 설정된다면 kubernetes에 다음과 같은 명령어를 입력한다.
kubectl create -f pod-definition.yaml생성된 pod 를 자세히 보고 싶다면 다음과 같은 명령어를 실행한다.
kubectl describe pod 설정한-label값Service
여러 Component 사이에서 그 밖에 앱 외부에서까지 커뮤니케이션을 지원하는 Service
외부 사용자가 Kubernetes에 올라간 Web Application에 접근하는 방법은?
- Kubernetes Node는 IP 주소를 가지고 있다.
- Kubernetes 내부 Pod는 내부 네트워크를 가지고 있다.
- 당연하게 Kubernetes 외부에서는 접근하지 못한다.
- Kubernetes Node에 SSH로 접근하면 Pod에 접근 가능하다.
Service
- 외부 요청을 Kubernetes Node 속, Pod 속으로 전달해주는 중간 매체
Service 종류
- NodePort : Node 안에 Pod에 접근할 수 있는 내부 포트를 생성
- Cluster IP : 가상 IP를 만들어 Kubernetes 클러스터 안에 다른 서비스끼리 소통할 수 있도록 한다.
- Load Balancer : 보통 클라우드 벤더에서 제공하는 설정 방식. 외부 IP 를 가지고 있는 로드밸런서를 할당하고 외부 IP를 통해 외부에서 접근한다.
NodePort
- Node Port 는 3가지 port가 존재
- 실제 웹 애플리케이션 Pod에 접근하는 Port
- Kubernetes Service 객체 자체의 Port
- Kubernetes 서버 외부에서 접근 가능한 Port이며, Cluster 안에 자체 IP(= cluster IP) Port
- Port 번호 범위 : 30,000 ~ 32,767
- Pod가 여러 Node에 분산 확장되어 있다면, Kubernetes는 자동으로 Service 객체를 클러스터 내 모든 Node로 확장하고 target port와 매핑시킨다.
Cluster IP
- 통신하는 application들이 분산처리되어 있을때 이 서비스들의 연결을 유지하는 방법
- Pod들은 각자 IP 주소를 할당받고 있지만, 고정 IP가 아니기 때문에 IP에 의존하면 안된다.
- Pod는 Service를 통해 그룹을 가질 수 있고, 한 인터페이스를 통해 접근이 가능하다.
- Service 내에 IP와 이름을 할당하여 다른 Service에서 접근 가능하도록 돕는다.
Load Balancer
- Kubernetes 외부 환경의 사용자가 각 다른 노드에 퍼져있는 분산된 Pod에 접근할려면 각 Node의 IP와 Pod의 NodePort 설정을 조합하여 접근해야 한다.
- AWS, GCP, Azure 같은 클라우드 플랫폼을 사용한다면 이런 분산환경에서도 하나의 외부 인터페이스를 통해 접근할 수 있다.
- 클라우드 플랫폼을 사용한다면, Service spec type을
LoadBalancer로 설정한다.- 만약 지원되지 않는 환경에서 해당 타입을 쓴다면 그냥
NodePort을 사용한 것과 같다.
- 만약 지원되지 않는 환경에서 해당 타입을 쓴다면 그냥
감사합니다:)
Written by 구 연수 / Yeonsoo koo
Software Engineer
