Kubernetes POD는 원리적으로 프로세스의 집합이다. 프로세서들이 라이프사이클을 가지는 것처럼 POD 들도 라이프사이클을 가진다. 만약 워커 노드가 죽으면, 워커노드위에 작동하는 POD들도 종료된다. 서버가 죽으면 서버 위에서 작동하던 프로세스의 생명이 어떻게 될지를 생각하면 된다.
쿠버네티스에서는 POD에 대한 복제본을 설정할 수 있기 때문에, 워커 노드의 문제로 POD가 내려갈 경우 다른 작동 중인 노드에서 POD를 만들어서 복제본의 총합을 유지한다.
쿠버네티스에서 서비스는 논리적인 POD 셋과 그 POD들에 접근할 수 있는 정책을 정의하는 개념이다. 이 개념을 이용해서 POD들을 느슨하게 결합되도록 할 수 있다. 서비스는 다른 쿠버네티스 객체(POD 등)과 마찬가지로 YAML 혹은 JSON을 이용해서 정의 할 수 있다.
POD가 만들어지면 이들은 고유한 IP를 가지게 되는데, 이들은 클러스터 내부 IP로 외부에서 접근 할 수 없다. 쿠버네티스의 서비스 설정을 이용해서 외부에 IP를 노출 시켜줘야 한다. 쉽게 이해하기 위해서 쿠버네티스 네트워크 정책을 살펴보기로 했다.
Kubernetes Deployments vs Service
쿠버네티스를 처음 접하면 여러 용어들 사이에서 혼란을 겪는다. Deployments 와 Service에서도 혼란을 겪을 수 있는데, 두 개의 차이점을 살펴보도록 하자.
쿠버네티스 Deployments의 목표는 단순하다. 그 목표는 "유사한 포드를 관리하는 것"이다. 이들 포드에 대한 정보는 YAML 형식의 deployment 설정파일로 관리 한다. Deployments 컨트롤러(controller)는 복제 세트와 POD를 선언하며, 이를 업데이트하고 관리할 책임을 가진다. Deployments는 선언된 복제 세트와 POD의 정보를 읽어서 실제로 클러스터에 POD(애플리케이션)를 배포를 수행한다.
이제 클러스터에 전개된 POD를 외부에서 접근 할 수 있도록 노출(expose)해야 하는데, 이렇게 외부에 노출될 POD를 명확하게 정의하는 추상객체를 서비스라고 한다. 서비스를 통해서 비로서 외부에서 접근 할 수 있게 된다.
애플리케이션 준비
테스트에 사용할 Deployment 설정파일을 준비했다. "Hello World"를 출력하는 테스트용 노드 애플리케이션을 실행한다. 파일의 이름은 "hello-application.yaml"로 했다.
# kubectl cluster-info
Kubernetes control plane is running at https://192.168.49.2:8443
CoreDNS is running at https://192.168.49.2:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
# curl 192.168.49.2:31259
Hello Kubernetes!
쿠버네티스는 이 서비스 스펙을 읽어서 "hello"라는 service 객체를 생성한다. 모든 pod는 TCP 포트 80 번으로 접근 할 수 있다.
앞서 "pod와 service 는 서로 분리" 된다고 했다. 따라서 이 서비스 스펙을 적용할 pod를 선택(select)해야 한다. 셀렉터(selector)를 이용해서 선택 할 수 있다. "app: hello"로 서비스할 pod를 선택했다. pod 스펙 파일의 "metadata > labels"에 있는 값이다. 서비스를 실행하고 내용을 확인해보자.
백엔드 서비스를 만들었으니 프론트엔드 서비스를 만들 것이다. 프론트 엔드는 NginX를 가지고 있으며, NginX로 백앤드를 로드밸런싱한다. 사용자는 프론트 엔드 서비스를 통해서 hello 서비스를 사용 할 수 있다. frontend-deployment.yaml 파일이다.
Contents
소개
Kubernetes 서비스
Kubernetes Deployments vs Service
애플리케이션 준비
정리
서비스를 사용하여 프론트엔드를 백엔드에 연결
테스트 애플리케이션 구성
Backend
FrontEnd
정리
Recent Posts
Archive Posts
Tags