Kubernetes

쿠버네티스란?

 

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

 

애플리케이션 배포 환경의 변화

 

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

Container Deployment (컨테이너 배포) 시대로 오기까지의 여정

 

전통적인 방식 (Traditional Deployment)

- 가장 오래되고 단순한 방식
- 물리적인 컴퓨터 한대에 하나의 OS를 깔고, 여러가지 프로그램을 설치하는 방식
- 문제점
다른 OS 설치하려면? -> 컴퓨터 한대 더 필요
같은 컴퓨터 리소스를 공유하므로, 배포한 애플리케이션 끼리 서로 영향 -> 성능 문제 발생
하드웨어의 성능은 매우 빠르게 좋아지는 반면에, 소프트웨어 발전은 반도 못따라감

(무어의 법칙 :  반도체 칩의 성능, 즉 메모리의 용량이나 CPU의 속도가 약 24개월마다 2배로 증가하고, 가격은 2배씩 낮아진다는 법칙입니다. 인텔의 공동 창업자인 골든 무어가 1965년에 발표한 내용이기 때문에 무어의 법칙이라고 불립니다.)

소프트웨어가 요구하는 서버 사양에 비해 소프트웨어를 실행 중인 서버의 성능이 훨씬 좋다 보니, 서버 성능을 10% 수준 밖에 활용하지 못하는 비효율이 발생
심지어 그 당시 컴퓨팅 자원들은 지금보다 훨씬 비쌌다.

 

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

리소스가 충분한 컴퓨터를 여러대의 컴퓨터처럼 사용해보자.

 

가상화 배포 (Virtualized Deployment)

통적인 방식의 이러한 문제점 때문에, 사람들은 "가상화" 라는 개념을 생각해내게 됩니다.

가상화란 ?

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

쉽게 말하자면, 하드웨어는 1개인데 이걸 여러대 처럼 동작시키거나, 반대로 여러대의 장치를 묶어 하나의 장치인 것 처럼 해서, 사용자는 내부적으로 어떻게 돌아가는지 알 필요 없이, 사용자가 원하는 방식으로 자원을 사용할 수 있다는 거예요.

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

 

 가상화 배포는, 가상머신을 기반으로 배포하는 방법으로 가상머신은 위에서 말한 가상화 기술이 적용된 컴퓨터인데, 개별적으로 자체 컴퓨팅 자원(CPU, memory, Disk)과 OS를 갖춘 가상 컴퓨팅 환경입니다.

 

 

특징

가상머신은 각각의 논리적으로 구분된 가상 환경에서 실행되기 때문에, 각기 다른 OS, 분리된 리소스를 갖고있음

하이퍼바이저(Hypervisor) : 하나의 시스템 상에서 가상 컴퓨터를 여러개 구동할 수 있도록 해주는 중간 계층, 가상머신 각각에 자원 할당 (VMware Workstation, Oracle VM VirtualBox 등)

문제점

VM이 많을수록 전통적인 방식 대비 성능의 안정성이 떨어지고, 실행속도가 느려짐
가상머신은 "완전한 컴퓨터"이기 때문에, 각각의 가상머신에 guest OS를 일일히 설치해주어야 함
=> 독립적인 플랫폼을 하나씩 증가시킬 때마다 불필요한 OS 를 만들어야 해서 확장성이 떨어지고 OS 크기 생각하면 부담스러움

 

이러한 문제를 해결하기위해 등장한 개념이, 컨테이너(Container) 입니다.

 

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

컨테이너 중심의 배포는 말 그대로, 컨테이너를 기반으로 애플리케이션을 배포하는 방법입니다.

 

컨테이너란?
Host OS상에 논리적인 구획을 만들어서, 애플리케이션을 작동시키는데 필요한 라이브러리나 종속 항목들을 모아 마치 별도의 서버인 것 처럼 사용할 수 있게 만든 것
애플리케이션과 필요한 모든 파일을 하나의 런타임 환경으로 묶는 데 사용하는 기술 (/w redhat)

 

컨테이너와 VM의 가장 큰 차이점은, 컨테이너는 애플리케이션 간에 운영체제(OS)를 공유한다는 점입니다.

호스트 OS의 리소스를 논리적으로 분리시키고, 여러개의 컨테이너가 공유하여 사용합니다.
그렇기 때문에, 컨테이너는 VM과 달리 프로그램의 구동을 위해 OS를 매번 설치할 필요가 없습니다.
즉, 하나의 Host OS 위에서 마치 각각의 독립적인 프로그램처럼 관리되고 실행됩니다.

 

다른 컴퓨팅 환경으로 이동하더라도 안정적으로 실행 가능합니다.
애플리케이션의 실행에 필요한 라이브러리, 바이너리 파일, 기타 구성파일 등을 패키지로 묶어서 배포하면, 구동 환경이 바뀌어도 실행에 필요한 파일이 함께 따라다니기 때문에 오류를 최소화 할 수 있습니다.

 

도커 (Docker)

도커는 컨테이너를 만들고 사용할 수 있도록 하는 컨테이너화 기술입니다.
애플리케이션의 실행에 필요한 환경을 하나의 이미지로 모아두고, 그 이미지를 사용하여 다양한 환경에서 애플리케이션 실행 환경을 구축 및 운영하기 위한 오픈소스 가상화 플랫폼 입니다.

 

이미지 (Image) 란?

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

 

쿠버네티스의 등장배경

도커의 등장으로 컨테이너 기반 배포 방식이 보편화되고, 많은 서비스들이 도커라이징 되어 이미지로 관리되기 시작했습니다.
점점 이미지가 많아지면서, 관리해야할 컨테이너와 서버들 또한 많아지게 되었죠.
이 말은 즉슨, 엔지니어가 할일이 많아졌다는 말입니다.

 

할일이 많아지면 이런 잡스러운 일들을 자동화 시켜야합니다.
컨테이너들의 관리를 자동화할 도구(컨테이너 오케스트레이션 툴) 의 필요성이 대두되고, 비로소 컨테이너 오케스트레이션의 시대가 열리게 됩니다.

 

많은 컨테이너 오케스트레이션 도구가 있음에도 불구하고, 현재는 쿠버네티스가 컨테이너 오케스트레이션 툴의 사실상 표준(De facto) 로 자리매김하게 되었습니다.
이렇게 될 수 있었던 몇가지 이유는 다음과 같습니다.

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

 

 

쿠버네티스란?

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

쿠버네티스 특징

 

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

• 전 세계적 스케일의 경험과 기술
• 거대한 커뮤니티와 생태계
• 잘 안되는 건 찾아보면 되고 이런거 만들어 볼까 하면 이미 있음

다양한 배포 방식

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

Namespace & Label

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

RBAC (role-based access control)

 

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

Auto Scaling

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

Federation, Multi Cluster

• 클라우드에 설치한 쿠버네티스 클러스터와 자체 서버에 설치한 쿠버네티스를 묶어서 하나로 사용 가능
• 구글의 Anthos를 이용하면 한 곳에서 여러 클라우드의 쿠버네티스 클러스터들을 관리 가능
•  

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

마스터 - 노드 구조

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

Desired State

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

 

• esired State (원하는 상태)
  • 관리자가 바라는 환경 (구체적으로 웹서버 몇개 띄울건지, 몇번 포트로 띄울건지)
  • 현재 상태(current state) 를 모니터링하면서 관리자가 설정한 원하는 상태(desired state)를 유지하는 방향으로 동작
• 쿠버네티스의 핵심은 상태이며 쿠버네티스를 사용하려면 어떤 상태가 있고 어떻게 상태를 선언하는지를 알아야 함

 

Kubernetes Object

Pod

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

Replicaset & Deployment

 

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

Service

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

Kubernetes Object Spec 기술 - Manifest 파일

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

Kubernetes 배포 방식

• 애플리케이션을 배포하기 위해 오브젝트(object)에 라벨Label 을 붙여 원하는 상태(desired state) 로 정의(yaml)하고 API 서버에 전달하는 방식을 사용
• yaml 파일을 만들어서, 쿠버네티스 API 서버에 전달하면 됨

 

 

 

 

*참조

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