쿠버네티스 - Deployment / Pod / Service / Ingress

쿠버네티스는 VM을 통해 컨테이너화 된 개발환경으로 확장 가능한 오픈소스 플랫폼이다.

선언적 구성으로 자동화를 통해 효율적으로 관리할 수 있다.

 

그렇다면 컨테이너는 무엇인가?

"컨테이너는 애플리케이션을 실행하는데 필요한 모든 것이 포함된 소프트웨어 패키지를 의미합니다." 

개발자들이 자신의 환경에서 협업을 하거나 어떤 특정 프로젝트를 진행하고 싶은데 환경 세팅은 늘 번거럽고 어렵다.

누구는 윈도우 누구는 맥이면 OS도도 다를것이고, 자바 개발이라면 JDK 버전 등등 벌써 번거로운데 이 컨테이너는 필요한 패키지를 다 갖고있으니 어디서나 동일한 환경에서 사용할 수 있는 공간을 제공한다. 벌써 편하잖아.

그리고 프로젝트를 새로하고싶다면 똑같은 환경이 되어있는 컨테이너에 새로 만들면 그만. 간단하다.

 

그렇다면 환경 설정하는것도 힘들거 같은데 이걸 어떻게 받아오는가?

 

컨테이너 이미지

앞서 말한 컨테이너의 환경은 이 이미지 (image) 라는 개념으로 관리된다.

이미지는 실행가능한 소프트웨어 패키지며 불변의 특성을 갖고 있다.

불변의 특성을 갖는 이유는 컨테이너 개념에 있다.

동일한 환경. 즉 모두가 같은 공간을 받는데 이를 수정하면 이미 컨테이너를 사용한 의미가 없다.

만약 그럼에도 컨테이너 화 된 애플리케이션을 수정하고 싶다면 수정한 이미지를 만들어 빌드를 통해 새로운 컨테이너를 만들면 되겠다.

 

쿠버네티스 환경은 어떻게 구성?

 

쿠버네티스 아키텍처

클러스터

쿠버네티스는 컨트롤부분과 노드 애드온으로 생각할 수 있다.

 

컨트롤 플레인(Control Plane):
API 서버: 사용자와 다른 구성요소 간의 통신을 담당
스케줄러: 파드를 적절한 노드에 스케줄링
컨트롤러 매니저: 클러스터의 상태를 관리하고 목표 상태로 조정
etcd: 클러스터의 구성 데이터를 저장하는 키-값 저장소

노드(Node):
kubelet: 노드에서 실행되는 에이전트로 파드와 컨테이너를 관리
kube-proxy: 네트워크 규칙을 관리하고 서비스 레벨 네트워킹을 제공
컨테이너 런타임: 실제 컨테이너를 실행하는 소프트웨어(예: Docker, containerd)

애드온(Add-ons):
DNS: 서비스 검색을 위한 DNS 서버
웹 UI(대시보드): 웹 기반 사용자 인터페이스
컨테이너 리소스 모니터링: 리소스 사용량 모니터링
클러스터 수준 로깅: 로그 수집 및 저장

 

저런게 있는건 알겠어 근데 이게 뭔말이지.

쿠버네티스 컴포넌트로 보자.

• 쿠버네티스 클러스터
  • 쿠버네티스 클러스터는 컨테이너화된 애플리케이션을 실행하는 워커 노드의 집합
  • 모든 클러스터는 최소 한 개의 워커 노드를 가진다
  • 클러스터는 컨트롤 플레인 컴포넌트와 노드 컴포넌트로 구성.
  • 컨트롤 플레인 컴포넌트는 클러스터 전반에 걸친 결정을 내리고 이벤트를 감지/반응.
  • 프로덕션 환경에서는 일반적으로 컨트롤 플레인이 여러 컴퓨터에 걸쳐 실행되며, 클러스터 또한 여러 노드를 실행하여 내결함성과 고가용성을 제공.
  • 클러스터에는 컨트롤 플레인 컴포넌트와 노드 컴포넌트가 포함되며, 이들은 협력하여 쿠버네티스 클러스터를 운영
• 워커 노드
  • 워커 노드는 컨테이너화된 애플리케이션을 실행하는 컴퓨터
  • 각 워커 노드는 kubelet, kube-proxy 등의 노드 컴포넌트를 실행하며, 파드를 호스팅
  • 워커 노드는 컨트롤 플레인 컴포넌트에 의해 관리.
  • 워커 노드는 수직/수평으로 확장될 수 있어, 클러스터의 용량을 늘릴 수 있다.

• 파드
  • 파드는 쿠버네티스에서 배포/관리되는 가장 작은 단위의 컨테이너화된 애플리케이션
  • 하나의 파드는 하나 이상의 긴밀하게 관련된 컨테이너로 구성.
  • 파드는 스토리지, 네트워크 IP, 컨테이너 이미지 버전 등을 공유
  • 파드는 쿠버네티스 스케줄러에 의해 노드에 배포/실행

 

개념만 봐서는 이해하기 어려울 수 있다. 비유를 들어보자

클러스터 , 워커노드 , 컨트롤 플레인, 파드, 워커노드

 

클러스터 == 도시

클러스터에는 다양한 인프라가 존재하고 이 인프라 담당이 컨트롤 플레인 컴포넌트와 노드 컴포넌트 이다.

이를 통해 애플리케이션이 실행된다

 

워커노드 == 아파트

도시 속 아파트로 이 공간에서 파드가 존재한다.

 

컨트롤 플레인 == 공무원

도시에 대한 의사 결정을 내리고, 이벤트나 상황을 감지해서 대처한다.

 

파드 == 가족

파드 안에는 가족이 한 집에 사는것처럼 연관된 컨테이너들이 존재한다.

스토리지, 네트워크 등을 공유하고 하나의 단위로 관리가 된다.

 

워커노드 == 도시 속 다양한 상가 인프라

다양한 상가가 사람들에게 기능을 포함한 공간을 제공하듯이 가족인 파드들을 호스팅하는 역할을 한다.

kubelet, kube-proxy (노드 컴포넌트)등의 구성요소를 통해 파드를 관리하고 필요하다면 추가 또는 확장도 가능하다.

---

파드

하나 이상의 컨테이너 그룹이며 가장 작은 단위이다.

그룹은 앞서 말했듯 가족처럼 연관성이 존재해서 스토리지와 네트워크를 공유한다.

콘텐츠가 있다면 항상 함께 배치가 되고, 스케쥴되며 공유 컨텍스트에서 실행된다.

가장 작은 단위인 만큼 복제도 쉬워 확장성을 높힐 수 있다.

 

파드 예시

pods/simple-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml

명령어를 통해 생성할 수 있다.

일반적으로 직접 생성하는게 아닌 워크로드 리소스를 사용해 생성한다.

 

대표적으로 디플로이먼트(Deployment)를 활용해서 생성한다. 스테이트 풀셋, 데몬셋 등의 워크로드 리소스도 존재한다.

디플로이먼트에서 의도하는 상태 를 설명하고, 디플로이먼트 컨트롤러(Controller)는 현재 상태에서 의도하는 상태로 비율을 조정하며 변경한다. 새 레플리카셋을 생성하는 디플로이먼트를 정의하거나 기존 디플로이먼트를 제거하고, 모든 리소스를 새 디플로이먼트에 적용할 수 있다.

---

디플로이먼트 

디플로이먼트는 파드의 생성, 업데이트, 스케일링, 복구 등을 관리하는 상위 수준의 리소스이다.

개발자는 디플로이먼트를 통해 애플리케이션의 배포와 운영을 보다 효과적으로 관리할 수 있다.

 

디플로이먼트 예시

controllers/nginx-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

 

metadata 필드로 nginx-deployment 라는 이름의 디플로이먼트를 생성하고,

spec.replicas 필드로 3개의 nginx 레플리카 파드를 생성한다.

selector: 필드로 관리할 파드를 찾을 방법을 정의한다. 예제는 app: nginx 를 선택했다.

다음 template: 필드에는 labels, spec, containers가 있는데

labels: 를 통해 이름을 붙이고,

spec: 을 통해 nginx:1.14.2 라는 이미지를 실행하는 nginx 컨테이너를 1개 실행하는것을 볼 수 있다.

포트는 80번을 갖게된다.

 

kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml

명령어를 통해 디플로이먼트를 생성하고,

kubectl get deployments

를 통해 생성되었는지 확인할 수 있다.

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   0/3     0            0           1s

생성중이라면 이 같이 출력된다.

 

배포가 성공적으로 진행되는지 보려면 롤 아웃 상태를 통해 확인하는데 

kubectl rollout status deployment/nginx-deployment

이 같은 명령어로 확인할 수 있다.

Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment "nginx-deployment" successfully rolled out

롤 아웃 진행도를 확인 할 수 있고 

 

kubectl get deployments

를 통해 

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           18s

상태를 확인할 수 있다.

---

서비스

외부와 접하는 단일 엔드포인트 뒤에 있는 클러스터에서 실행되는 애플리케이션을 노출시키며, 이는 워크로드가 여러 백엔드로 나뉘어 있는 경우에도 가능하다.

---

인그레스(Ingress)

URI, 호스트네임, 경로 등과 같은 웹 개념을 이해하는 프로토콜-인지형(protocol-aware configuration) 설정 메커니즘을 이용하여 HTTP (혹은 HTTPS) 네트워크 서비스를 사용 가능하게 한다. 인그레스 개념은 쿠버네티스 API를 통해 정의한 규칙에 기반하여 트래픽을 다른 백엔드에 매핑할 수 있게 해준다.

---

또 개념만 보면 이해가 안간다.. 나만 그런가 호호 식당으로 비유해보자.

서비스(Service)는 마치 식당의 웨이터이다. 서비스는 고객의 요청을 받아 적절한 리소스(음식)를 찾아 제공한다. 서비스는 고객이 원하는 리소스에 접근할 수 있도록 연결해 주는 역할을 맡는다.

인그레스(Ingress)는 식당의 입구와 같다. 클러스터에 들어오는 관문 역할을 하며 들어오는 고객의 요청에 맞는 적절한 서비스를 제공한다.

---

추가 정리예정