[Kubernetes] 쿠버네티스 기본 개념

Kubernetes를 사용하는 이유

쿠버네티스를 사용하지 않고 ECS와 같은 특정 클라우드 서비스에서 제공하는 컨테이너 매니징 서비스를 이용하여 배포하는 것도 방법이다. 하지만, 이는 다음과 같은 단점이 있다

• 해당 서비스에 대한 깊이 있는 학습이 필요하고, 의존도가 높아지게 된다
  • ⇒ 타 서비스로의 전환이 어렵다
• 결국엔 도커 컴포즈에 작성된 내용을 각 인스턴스로 띄우고 별개로 관리하는 형태가 된다
  • ⇒ 관리 포인트가 증가하여 유지보수가 어렵다

하지만, 쿠버네티스(Kubernetes)는 컨테이너 오케스트레이션 표준 도구로써 특정 서비스에 고정되지 않고 컨테이너 자동 배포, 관리, 헬스 체크, 오토 스케일링, 로드 밸런서, 모니터링 기능을 제공한다. 이를 정의한 쿠버네티스 설정 파일만 작성해주면 된다!

---

Kubernetes란?

쿠버네티스로 배포하는 방식, 컨테이너 스케일링, 컨테이너 모니터링, 컨테이너 교체 방법 등을 정의할 수 있다. 즉, 클라우드 서비스와는 독립적으로 이 모든 것을 정의함으로써 앞서 살펴본 프로바이더 고정 문제를 해결할 수 있다.

 

쿠버네티스는 오픈 소스 시스템이자 컨테이너 배포를 관리하고, 컨테이너를 오케스트레이션 하기 위한 사실상의 표준이다. 또한 자동 배포, 스케일링, 로드 밸런싱, 일반적인 배포와 컨테이너 관리와 같은 태스크를 수행하는 데 도움이 된다.

 

그리고 쿠버네티스를 사용하면 쉽게 쿠버네티스 구성(Kubernetes Configuration)을 작성할 수 있다. 즉, 원하는 배포를 정의하는 구성 파일, 배포할 컨테이너, 인스턴스 수, 스케일 업 여부, 컨테이너 교체 여부 등을 설정할 수 있다. 그런 다음 특정 도구를 사용하여 그 구성을 클라우드 프로바이더 또는 실제로 올바르게 구성된 우리의 자체 머신에 전달한다. 그러면 그 구성에 지정된 리소스와 배포를 생성하기 위해 그 쿠버네티스 구성을 적용한다.

 

구성파일을 작성하는 방법은 다음과 같다.

apiVersion: v1
kind: Service
metadata: 
    name: auth-service
    annotations:

spec:
    selector:
        app: auth-app
ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
type: LoadBalancer

이 구성은 쿠버네티스를 지원하는 한, 모든 클라우드 프로바이더와 함께 작동한다. 또는 지원하지 않는 경우에도, 자체 머신에 특정 쿠버네티스 소프트웨어를 수동으로 설치한 다음 그 소프트웨어의 구성 파일을 활용할 수 있고 이해할 수 있다. 뿐만 아니라, 특정 클라우드 프로바이더에 특화된 옵션을 실제로 이 구성 파일에 병합할 수도 있다.

 

이것이 쿠버네티스의 배경 아이디어이다. 배포를 설명하는 표준화 방식을 갖는 것.

=> 쿠버네티스는 여러 머신을 위한 Docker-compose와 유사하다.

=> 쿠버네티스는 배포용 Docker-compose와 같다.

---

Kubernetes: 아키텍처 & 핵심 개념

쿠버네티스 아키텍처

Pod

• 쿠버네티스 구성 파일에서 작성할 대상으로, 쿠버네티스의 가장 작은 단위이다
• 내부에 여러 컨테이너를 보유할 수 있으나, 보통 pod 당 하나의 컨테이너를 사용한다
• 컨테이너와 그 컨테이너에 필요한 리소스를 감싸는 껍질이라고 생각하자

Worker Node

• 컨테이너를 실행하는 컴포넌트로, AWS의 EC2 인스턴스를 워커 노드라고 생각해도 좋다
• Pod를 호스팅하는 실제 머신으로, 컨테이너 및 컨테이너에 필요한 리소스(ex. 볼륨)를 실행
• Worker Node는 내부에 하나 이상의 Pod를 갖고, Pod와 관련된 모든 리소스를 호스팅한다
• 쿠버네티스 작업 시 최소 하나 이상의 Worker Node가 필요하다
• 내부에 여러 개의 Pod를 두어, 이에 대한 오토 스케일링 및 로드 밸런싱이 가능하게 함
• 워커 노드에 필요한 소프트웨어
  • Docker
  • kubelet
    • 내부 Pod에 대한 상태를 모니터링하고 마스터 노드에게 알리거나 마스터 노드로부터 명령을 받는다
    • 워커 노드와 마스터 노드 간의 통신 장치
  • kube-proxy
    • 트래픽 관리 책임을 가진 프록시
    • 서로 다른 Node에 있는 컨테이너 끼리의 통신을 도와줌

Proxy

• 쿠버네티스가 Worker Node에서 Pod 네트워크 트래픽 제어를 설정하는 도구
• Pod가 인터넷에 연결할 수 있는지 여부와 Pod 및 내부에서 실행되는 컨테이너를 외부에서 어떻게 접근 가능한지를 제어한다
  • ex. 사용자 외부 트래픽이 Pod에서 실행되는 컨테이너에 어떻게 접근 가능한지를 프록시로 구성

Master Node

• 마스터 노드는 워커 노드와 상호작용하며 제어하는 컨트롤 센터로, 관리자 역할을 하는 서버이다
• = 모든 Worker Node에 걸쳐 Pod를 관리하는 Control Plane을 가진 노드
• 내부에 ‘Control Plane’이라는 다양한 도구 모음이 있는데, 이를 통해 컨테이너와 포드를 만들고 시작, 실패하거나 불필요한 컨테이너의 교체 및 종료 등을 관리
• 우리는 워커노드 또는 포드와 직접 상호작용하는 것이 아니라, 마스터 노드의 컨트롤 플레인을 이용할 것
• 마스터 노드에 필요한 소프트웨어
  • Etcd
    • Key-value 형태의 데이터 저장 스토리지
    • Worker Node, Pod, Config, Secret, Account, Role, Binding 등과 같은 정보들을 저장하고 있다
    • kubectl get pod와 같은 명령어를 수행해서 얻는 정보는 모두 etcd에서 조회하는 것이다
  • API Server
    • Worker Node와 통신하기 위한 장치
    • 뿐만 아니라, 마스터 노드 내부의 다른 구성요소와의 통신도 담당
    • 중간 관제탑 역할
  • Kube-Controller-Manager
    • Worker Node 전체를 모니터링하고 제어하기 위한 장치
    • 내부에 여러 컨트롤러들이 있고, 각 컨트롤러가 하는 일이 다르다
    • ex. node-controller, replication-controller 등
  • Clooud-Controller-Manager
    • 클라우드 서비스 제공자에겍 무엇을 해야 하는지 알려주기 위한 장치로, KCM과 동일한 작업을 수행하지만, 제공자에 따라 다르다.
    • 이 덕분에 제공자에서 우리가 직접 마스터 노드, 워커 노드 등 필요한 서비스를 직접 설치할 필요가 없다.
  • Scheduler
    • Pod를 관찰하고, 새 Pod가 생성되어야 하는 Worker Node를 선택하는 일을 담당
    • Worker Node에게 무엇을 알려야 하는지 API 서버에게 알려주는 역할
• Kube-Controller-Manager이 모니터링하고, Scheduler가 의사 결정 후, API Server가 Worker Node에게 명령을 내리는 형태

Cluster

• 마스터 노드와 워커 노드들의 집합
• 원하는 최종 상태를 구성하는 모든 구성들의 집합체
• 클러스터 = 마스터 노드 + 1개 이상의 워커 노드 + 각 노드에 필요한 모든 소프트웨어(서비스) 설치

쿠버네티스는 인프라를 관리하지 않는다

쿠버네티스는 포드와 컨테이너를 모니터링하거나 스케일링, 접근/도달 여부 등 관리에만 관심을 가지며, 애플리케이션 리소스를 생성해주지 않는다.

이는 우리가 직접 수행하거나 'Kubermatic'과 같은 도구 또는 EKS와 같은 관리형 서비스를 사용해야 한다.

---

쿠버네티스 클러스터와 통신하는 방법 w. minikube

kubectl(kube control tool)를 통해 쿠버네티스 클러스터와 통신할 수 있다.

어떤 클라우드 서비스를 사용하더라도 클러스터와 통신을 하기 위해서는 kubectl을 설치해야 한다

여기서는 로컬에서 클러스터를 구성해보기 위해 minikube라는 도구를 사용해보자

• minikube : 쿠버네티스를 로컬 환경에서 사용할 수 있게 만든 쿠버네티스의 가벼운 구현체
  • 로컬 머신 위에 VM을 만들고 하나의 노드로 구성된 간단한 클러스터를 생성
  • ⇒ VM을 사용하여 다른 머신을 시뮬레이션하고 이 가상 머신은 클러스터를 보유하는 형태

1. kubectl 설치

$ brew install kubectl

$ kubectl version --client # kubectl 버전 확인

2. minikube 설치

$ brew install minikube

$ minikube start # 미니큐브 실행

$ minikube dashboard # 미니큐브 클러스터 웹 대시보드

• 이를 통해 마스터 노드, 워커 노드, 필요한 소프트웨어를 모두 자동으로 설치된다
• 즉, 로컬 클러스터가 생성되었다!
• +) Docker를 사용한다면 minikube 컨테이너가 실행 중인 것을 확인할 수 있다