[Kubernetes] 쿠버네티스 시작하기

쿠버네티스 시작

조타 손잡이? 맞나?

드디어 도커를 끝내고 쿠버네티스 포스팅을 시작한다!

 

쿠버네티스도 처음 접한건 학회에서였다. 

 

그 당시에는 도커도 모르던 시절이라 쿠버네티스가 뭐지?? 하고 넘겼었는데

 

도커를 어느정도 쓸줄 알게 되니까 쿠버네티스도 배우고 싶어져 학회원들과 스터디까지 진행했었다.

 

학회 스터디와 개인적으로 공부한 내용을 앞으로의 포스팅에 담으려고 한다.

 

쿠버네티스 너 누구니?

쿠버네티스를 보통 k8s라고 부르는데, 이는 kubernetes 에서 가운데가 8글자여서 이렇게 줄인다고 한다. ㅋㅋ

 

쿠버네티스는 컨테이너 오케이스트레이션 도구이다.

 

구글에서 2014년 오픈소스로 공개하고 현재 CNCF(Cloud Native Computing Foundation)에 소속되어 있다고 한다.

 

컨테이너 오케스트레이션?

말 그대로 컨테이너들을 지휘해준다는 뜻이다.

 

지휘라고 하면 생성과 삭제, 장애 대응, 자원 활용 및 제한 등 여러가지 관리 작업을 말하는데

 

이전에 도커에서 다루었던 도커 스웜도 이와 같은 기능을 제공하는 컨테이너 오케스트레이션 툴이다.

 

하지만 현재 업계에서는, 쿠버네티스가 표준으로 자리 잡았고 엄청나게 빨리 성장중이라고 한다.

 

그래도 쿠버네티스 공부를 하다보니 도커 스웜과 유사한 내용이 많아서

 

도커 스웜을 먼저 다뤄보길 잘했다는 생각이 들었다.

 

왜 핫하니?

요즘 Micro Service Architecture, MSA가 핫해지고 있다.

 

애플리케이션을 여러 서비스 단위로 잘게 나누어 배포하는 형태인데,

 

쿠버네티스는 이러한 서비스들을 파드단위로 배포해주면서 안정적인 아키텍쳐를 구성하는데 도움을 준다!

 

쿠버네티스 클러스터

쿠버네티스는 클러스터 단위로 운용된다.

 

다시 말해, 한대의 호스트 머신에서 동작하는것이 아닌 최소 3대 이상의 노드로 구성된 클러스터 위에서 동작한다.

 

쿠버네티스 클러스터를 구축하는 방법은 3가지로 정리할 수 있는데,

 

1. On-Premise 환경
2. 클라우드 플랫폼
3. 클라우드 Managed 서비스

당연한 얘기겠지만 On-Premise 환경은 자유도가 무제한이라는 장점과 관리의 복잡함이라는 단점을 가지고 있다.

 

클라우드 Managed 서비스(AWS EKS, GCP GKE, ...)는 자유도가 제한되지만 관리가 매우 편하다.

 

On-Prem 환경에 쿠버네티스를 구축하게되면 설치도 쉽지않고

 

무엇보다 쿠버네티스 자체가 워낙 복잡해서 장애나 에러가 발생했을 때 쉽게 대응할 수 없다.

 

따라서 학습용으로는 1번, 실무용으로는 3번 환경이 좋다고 생각한다.

 

쿠버네티스 주요 개념

 

다음은 쿠버네티스를 다루기 전에 필수적으로 알아야 할 개념에 대해 간략하게 다룬다.

 

쿠버네티스 오브젝트

쿠버네티스는 대부분의 리소스를 오브젝트라는 단위로 관리한다.

 

컨테이너의 집합을 Pod라는 오브젝트로 관리하는데, 이는 도커 스웜에서 다루었던 서비스와 매우 비슷하다.

 

이외에도 ReplicaSet, Node, Service(도커 스웜에서의 서비스와 다르다), Deployment 등 여러가지 오브젝트가 있으며

 

이 오브젝트들이 쿠버네티스의 시작이자 끝이다. 이에 대해선 다른 포스팅에서 더 자세하게 다루겠다.

 

YAML 파일

그렇다면 이러한 오브젝트들을 어떻게 관리할까?

 

쿠버네티스는 YAML 파일로 오브젝트를 관리한다.

 

물론 docker처럼 명령어를 제공하긴 하지만 복잡한 오브젝트들을 다루기에는 적절하지 않다.

 

다음은 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

 

뭐가 엄청 많다... 확실히 명령어로 관리하기에는 힘들것 같다.

 

하지만 우리는 YAML 파일을 다뤄보았다! 바로 docker-compose에서 말이다.

 

docker-compose가 여러 개의 컨테이너들을 한번에 하나의 YAML 파일로 다루기 위해 등장했다는것을 이해하면

 

쿠버네티스에서도 YAML파일을 사용하는것이 이해 된다.

 

Desired State와 Current State

쿠버네티스는 컨테이너 오케스트레이션 도구라고 앞에서 소개했다.

 

쿠버네티스가 지원하는 많은 기능중에 가장 핵심은 안정적인 클러스터 환경을 유지시켜준다는 점이다.

 

쿠버네티스 클러스터는 하나의 노드(호스트 머신)이 아닌 여러 개의 노드로 구성되어 있다고 했었다.

 

만약 어떤 노드에 여러 개의 컨테이너가 실행되고 있었는데, 해당 노드가 죽어버리면 어떻게 될까?

 

쿠버네티스 클러스터는 이를 Desired State를 통해 해결한다.

 

말 그대로 내가(개발자가) 바라는 상태를 뜻하며 해당 노드가 죽으면 이를 감지해서 다른 노드에 컨테이너를 띄워준다.

 

위의 예시는 도커 스웜에서 다루었던 예시를 가져왔다.

 

현재 Desired State는 무엇일까? 답은 클러스터내에서 컨테이너 3개를 항상 유지시켜줘! 이다.

 

따라서 애플리케이션 관점에서는 하나의 노드가 죽어도 크게 영향을 받지 않는다.(물론 Utilization이 떨어지겠지만)

 

그렇다면 Desired State는 어떻게 정의할까? 바로 YAML 파일이다!

 

Current State와 Desired State를 계속 비교하면서, Current State를 Desired State와 똑같이 만드려고 노력한다.

 

쿠버네티스 핵심 구성요소

이 많은 기능들을 지원하기 위해서 쿠버네티스는 여러가지 컴포넌트들을 내장하고 있다.

 

• kube-apiserver
• kube-controller-manager
• etcd
• kube-scheduler
• CoreDNS
• kube-proxy

이외에도 여러가지가 있다. 이에 대한 자세한 내용은 다음 포스팅에서 다루겠다.

 

자 가보자!