DevOps K8S(2) – Pod와 Pod를 연결하는 Service

by

안녕하세요,

오늘은 베스핀글로벌 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 종류
  1. NodePort : Node 안에 Pod에 접근할 수 있는 내부 포트를 생성
  2. Cluster IP : 가상 IP를 만들어 Kubernetes 클러스터 안에 다른 서비스끼리 소통할 수 있도록 한다.
  3. Load Balancer : 보통 클라우드 벤더에서 제공하는 설정 방식. 외부 IP 를 가지고 있는 로드밸런서를 할당하고 외부 IP를 통해 외부에서 접근한다.
NodePort
  • Node Port 는 3가지 port가 존재
  1. 실제 웹 애플리케이션 Pod에 접근하는 Port
  2. Kubernetes Service 객체 자체의 Port
  3. 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