[Kubernetes] 쿠버네티스

쿠버네티스

간단히 말하면, 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고 확장 가능한 오픈소스 플랫폼이다. 

 

무언가 프로그램을 개발해서, 사람들에게 서비스를 제공하려면 특정 서버에 자신이 만든 소프트웨어를 배포(Deploy)해야 한다. 
이 "배포(Deployment)" 방식의 변화 과정을 이해하는 것이 컨테이너, 도커, 쿠버네티스의 개념을 이해하는데 있어서 중요하다. 

 

---

전통적인 배포 (Tradtional Deployment)

가장 오래되고 단순한 방식

물리적인 컴퓨터 한 대에 하나의 OS를 깔고, 여러가지 프로그램을 설치하는 방식

 

단점

• 다른 OS를 설치하려면 컴퓨터가 하나 더 필요하다. 
• 같은 컴퓨터 리소스를 공유하므로, 배포한 애플리케이션끼리 서로 영향을 줄 수 있으며 이는 성능 문제를 발생시킬 수 있다. 
• 하드웨어의 성능은 매우 빠르게 좋아지는 반면, 소프트웨어의 발전은 하드웨어 발전의 반도 따라가지 못한다. (무어의 법칙)
• 소프트웨어가 요구하는 서버 사양에 비해 하드웨어의 성능이 훨씬 좋다 보니,
  서버 성능의 10% 수준 밖에 사용하지 못하는 비효율이 발생한다. 
• 컴퓨팅 자원은 매우 비싸다. (과거에는 더욱 비쌌다)

한 대의 컴퓨터를 여러 대의 컴퓨터처럼 사용할 수는 없을까?

 

 

가상화 배포 (Virtualized Deployment)

가상화? 물리적인 하드웨어 장치를 논리적인 객체로 추상화하는 것을 의미한다. 

즉, 한 대의 서버 위에 동시에 여러개의 OS를 설치하고, 여러 애플리케이션을 실행시키는 방식으로 자원 비효율 문제 해결

 

가상화 배포는, 가상머신을 기반으로 배포하는 방법

가상머신(VM, Virtual Machine)은 각각의 논리적으로 구분된 가상 환경에서 실행되기 때문에,

각기 다른 OS, 분리된 리소스를 갖고 있다. 

 

하이퍼바이저(Hypervisor)

하나의 시스템 상에서 가상 컴퓨터를 여러개 구동할 수 있도록 해주는 중간 계층, 가상머신 각각에 자원 할당

(VMware Workstation, Oracle VM VirtualBox 등)

 

 

단점

• VM이 많을수록 전통적인 방식 대비 성능의 안정성이 떨어지고, 실행 속도가 느려진다. 
• 가상머신은 "완전한 컴퓨터" 이기 때문에, 각각의 가상머신에 guest OS를 일일히 설치해주어야 한다. 
  → 독립적인 플랫폼을 하나씩 증가시킬 때마다 불필요한 OS를 만들어야하기 때문에 확장성이 떨어지고, 메모리의 낭비가 일어남. 

 

 

컨테이너 중심의 배포 (Container Deployment)

컨테이너?

Host OS상에 논리적인 구획을 만들어서,

애플리케이션을 작동시키는데 필요한 라이브러리나 종속 항목들을 모아 마치 별도의 서버인 것처럼 사용할 수 있게 만든 것. 

즉, 애플리케이션과 필요한 모든 파일을 하나의 런타임 환경으로 묶는 데 사용하는 기술

 

컨테이너와 VM의 가장 큰 차이점은, 컨테이너는 애플리케이션 간에 OS를 공유한다는 점이다. 

Host OS의 리소스를 논리적으로 분리시키고, 여러 개의 컨테이너가 이를 공유하여 사용한다. 

그렇기 때문에, 컨테이너는 VM과 달리 프로그램 구동을 위해 OS를 매번 설치할 필요가 없다. 

 

→ Host OS를 공유하므로 OS 설치 작업이 필요없어 setup이 빠르고 확장성이 좋다. 

→ VM 보다 가벼워 마이그레이션, 백업, 전송이 빠르다. 

→ 오버헤드가 적기 때문에, 가볍고 고속으로 작동한다. (메모리를 적게 차지하고 시작, 종료 시간이 적게 소요됨)

 

애플리케이션의 실행에 필요한 모듈을 하나의 컨테이너로 모을 수 있기 때문에,

여러 개의 컨테이너를 조합하여 하나의 애플리케이션을 구축하는 MSA 애플리케이션과 친화성이 높다. 

https://littlebitawesome.tistory.com/entry/MSA%EB%9E%80

MSA란?

 

다른 컴퓨팅 환경으로 이동하더라도 안정적으로 실행 가능하다. 

애플리케이션의 실행에 필요한 라이브러리, 바이너리 파일, 기타 구성파일 등을 패키지로 묶어서 배포하기 때문에

구동 환경이 바뀌어도 실행에 필요한 파일이 함께 따라다니기 때문에 오류를 최소화할 수 있다. 

 

한 프로그램 내의 문제는 다른 프로그램에 영향을 끼치지 않는다. 

그러나, OS를 공유하는 방식이기 때문에 한 프로그램의 문제가 OS에 문제를 일으킬 경우,

OS에서 구동 중인 전체 컨테이너의 문제가 될 가능성이 있으므로 주의해야 한다. 

 

※ 가상머신의 OS 위에도 컨테이너 기반 배포가 가능하다. 

※ 전통적 배포 방식과 달리, 컨테이너 기반 배포는 각 프로그램들이 서로 간섭을 일으킬 수 없도록 장벽을 치고,

   OS는 각 프로그램들이 사용할 수 있는 CPU, 메모리 등의 자원을 독립적으로 사용할 수 있도록 할당하고 관리한다. 

 

---

도커

도커는 컨테이너를 만들고 사용할 수 있도록 하는 컨테이너화 기술

애플리케이션의 실행에 필요한 환경을 하나의 이미지로 모아두고,
그 이미지를 사용하여 다양한 환경에서 애플리케이션 실행 환경을 구축 및 운영하기 위한 오픈소스 가상화 플랫폼.

 

이미지?

• 컨테이너 실행에 필요한 파일과 설정 값 등을 포함하는 것으로, 상태값을 가지지 않고 (Stateless) 변하지 않음 (Immutable).
• 컨테이너는 이미지를 실행한 상태(Runtime)라고 볼 수 있고 추가되거나 변하는 값는 컨테이너에 저장된다.
• 같은 이미지에서 여러개의 컨테이너를 생성할 수 있고 컨테이너의 상태가 바뀌거나 삭제되더라도 이미지는 변하지 않는다.

https://littlebitawesome.tistory.com/entry/Docker-%EB%8F%84%EC%BB%A4%EB%9E%80

[Docker] 도커란?

 

---

쿠버네티스 (Kubernetes)

쿠버네티스의 등장배경

도커의 등장으로 컨테이너 기반 배포 방식이 보편화되고, 많은 서비스들이 도커라이징 되어 이미지로 관리되기 시작함
점점 이미지가 많아지면서, 관리해야할 컨테이너와 서버들 또한 많아짐 → 엔지니어가 할일이 많아졌다

 

컨테이너들의 관리를 자동화할 도구(컨테이너 오케스트레이션 툴) 의 필요성이 대두됨
(Kubernetes, Docker Swarm, AWS의 ECS, 하시코프의 Nomad, Mesos의 Marathone 등)

쿠버네티스란?

• 컨테이너를 쉽고 빠르게 배포 및 확장하고, 관리를 자동화해주는 오픈소스 플랫폼
• 명칭은 조타수(helmsman)나 조종사(pilot)를 뜻하는 그리스어에서 유래
• k8s라는 약자로 불리는데, 이는 k,s 사이의 8글자를 나타내는 약식 표기
• 단순한 컨테이너 플랫폼이 아닌 마이크로서비스, 클라우드 네이티브 플랫폼(CNCF) 을 지향하고 컨테이너로 이루어진 것들을 손쉽게 담고 관리할 수 있는 그릇 역할

쿠버네티스 특징

(1) 대기업들의 참여 (거대한 생태계)

• 대규모 컨테이너를 관리했던 구글의 노하우와 강력한 확장성
• 마이크로소프트, RedHat, IBM 등 수많은 기업의 참여
• AWS, GCP, Zure, Digital Ocean, IBM Cloud, Oracle Cloud 등에서 관리형 서비스를 내놓음으로써 클라우드 컨테이너 시장을 평정
•  

(2) 다양한 배포 방식

• Deployment, StatefulSets, DaemonSet, Job, CronJob 등 다양한 배포 방식을 지원
• 여러 대의 애플리케이션을 띄우고 싶을 경우, Deployment 이용
• 로그나 모니터링 등 모든 서버에 설치가 필요한 경우, DaemonSet을 이용
• 배치성 작업은 Job이나 CronJob을 이용

(3) Namespace & Label

• 네임스페이스(Namespace) 기능으로 하나의 클러스터를 논리적으로 구분하여 사용 가능
• 라벨(label) 기능으로 유연하면서 확장성 있게 리소스를 관리

※ pod : 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위

(4) RBAC (role-based access control)

• 역할 기반 액세스 제어
• 누가(주체), 무엇을(동사), 어디에(네임스페이스) 실행할 수 있는지 결정하는 권한 또는 템플릿 집합을 수반하는 Identity 및 액세스 관리 형식
• 각각의 리소스에 대해 유저별로 CRUD스러운 권한을 손쉽게 지정
• 클러스터 전체에 적용하거나 특정 네임스페이스에 적용
• AWS의 경우 IAM을 연동해서 사용 가능

(5) Auto Scaling

• 손쉽게 리소스 확장 가능
• Horizontal Pod Autoscaling(HPA) : CPU, MEM 사용량에 따라 Pod 수평 확장 기능
• Vertical Pod Autoscaling(VPA) : Pod 리소스 할당량 조정 (CPU, memory 등)
• Cluster Autoscaling(CA) : 노드(서버) 개수 조정 가능 (클라우드 환경에서만)

이 외에도 KEDA 라는 오픈소스를 활용하여 HTTP 요청량이나 이벤트 수에 따라 Pod를 스케일링 할 수 있다.

 

 

---

쿠버네티스 기본 개념과 구성 요소

마스터 - 노드 구조

• 중앙(Master)에 API 서버와 상태 저장소를 두고 각 서버(Node) 의 에이전트(kubelet)과 통신하는 단순한 구조
• 모든 명령은 마스터의 API 서버를 호출하고, 노드는 마스터와 통신하면서 필요한 작업 수행
• Kubectl 이라는 Client 도구로 API 서버 접근 가능

Desired State

 

관리자가 서버를 배포할 때 직접적인 동작을 명령하지 않고 원하는 상태를 선언하는 방식을 사용 (RUN x, Create o)

 

Run

“nginx 컨테이너를 실행해줘. 그리고 80 포트로 오픈해줘.”
→ 현재 상태를 원하는 상태로 바꾸기 위한 명령(imperative)

 

Create
“80 포트를 오픈한 nginx 컨테이너를 1개 유지해줘”
→ 원하는 상태를 선언(declarative)

 

 

Desired State (원하는 상태)

• 관리자가 바라는 환경 (구체적으로 웹서버 몇개 띄울건지, 몇번 포트로 띄울건지)
• 현재 상태(current state) 를 모니터링하면서 관리자가 설정한 원하는 상태(desired state)를 유지하는 방향으로 동작

• 쿠버네티스의 핵심은 상태이며 쿠버네티스를 사용하려면 어떤 상태가 있고 어떻게 상태를 선언하는지를 알아야 함

 

Kubernetes Object

쿠버네티스의 대표적인 Object들에는 Pod, Deployment, Service가 있다. 

Pod

• 쿠버네티스에서 배포할 수 있는 가장 작은 단위
• 한 개 이상의 컨테이너와 스토리지, 네트워크 속성 가짐
• 컨테이너를 하나만 사용하는 경우도 반드시 Pod으로 감싸서 관리

Replicaset & Deployment

• Pod을 여러 개(한 개 이상) 복제하여 관리하는 오브젝트
• 복제할 개수, 개수를 체크할 라벨 선택자, 생성할 Pod의 설정값(템플릿)등 설정
• 자동으로 롤링 업데이트 가능

Service

• 네트워크 관련 Object
• Pod ↔︎ Pod 연결, 외부에서 접근할 때 등에 사용

Kubernetes Object Spec 기술 - Manifest 파일

• 오브젝트의 명세Spec, 상태desired state 정의는 YAML 파일로 정의
• 오브젝트의 종류와 원하는 상태를 입력
• 배포 노드나 RBAC(접근 권한 설정) 도 가능

 

<nginx pod 3개를 배포하는 manifest 예시>

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: dev
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        command: ["/bin/bash", "-c", "--"]
        args: ["while true; do sleep 30; done;"]
        ports:
        - containerPort: 80

 

Kubernetes 배포 방식

애플리케이션을 배포하기 위해

1. 오브젝트(object)에 라벨Label 을 붙여
2. 원하는 상태(desired state) 로 정의(yaml)하고
3. API 서버에 전달하는 방식을 사용

 

yaml 파일을 만들어서, 쿠버네티스 API 서버에 전달하면 됨

 

“tomcat 컨테이너를 2개 배포하고 8080 포트로 오픈해줘”

 

“컨테이너를 Pod으로 감싸고 type=app, app=web이라는 라벨을 달아줘.
type=app, app=web이라는 라벨이 달린 Pod이 2개 있는지 체크하고,
없으면 Deployment Spec에 정의된 템플릿을 참고해서 Pod을 생성해줘.
그리고 해당 라벨을 가진 Pod을 바라보는 가상의 서비스 IP를 만들고 외부의 8080 포트를 방금 만든 서비스 IP랑 연결해줘.”

 

 

 

 

https://velog.io/@holicme7/K8s-%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80

[K8s] 쿠버네티스란 무엇인가?

https://kubernetes.io/ko/docs/home/

쿠버네티스 문서