쿠버네티스로 가는 길은 명확합니까?

쿠버네티스를 사용해야 할까요? 간단히 말해서 대답은 사람마다 다릅니다. 하지만 제가 Kubernetes를 이해하기까지의 여정을 안내해드리면 여러분도 스스로 답을 찾는 데 도움이 될 것입니다. 

저는 Kubernetes로 가는 길을 안내하기 위해 전체 책을 썼습니다( 여기에서 Manning의 초기 릴리즈 MEAP를 받으세요). 하지만 책에 대해 이야기하기 전에 소프트웨어 배포와 그에 이르는 제 여정에 대해 잠깐 이야기해 보겠습니다. 

거의 20년 전, 저는 인터넷에 소프트웨어를 배포하여 첫 번째 웹사이트를 게시하기 위한 첫 번째 시도를 시작했습니다. 당시에는 어디서부터 시작해야 할지 전혀 몰랐습니다. 가족 친구 몇 명이 친절하게도 몇 가지 조언을 해주었습니다:

기업가가 제안했습니다: 

"드림위버와 HTML에 관한 이 책 한 권만 있으면 첫 번째 웹사이트를 개발하는 데 한 푼도 들이지 않아도 됩니다."

시스템 관리자와 개발자는 다른 접근 방식을 취했습니다: 

"여기, 웹사이트를 호스팅할 수 있는 FTP 서버를 설정해 드리겠습니다. 서버 관리 방법을 배우지 않는 것이 좋습니다."

이 두 분 모두 제가 지금의 자리에 오를 수 있도록 도와주셨지만, 그 중 한 분이 의도치 않게 저의 학습을 오랫동안 지연시켰습니다. 누구일까요?

초창기 시절을 돌이켜보면 기초 지식과 실무 경험을 통한 학습이 제 여정을 형성하는 데 얼마나 중요한 역할을 했는지 알 수 있습니다. 기업가의 조언을 통해 웹 개발에 직접 뛰어들게 되었고, 시스템 관리자의 지도를 통해 복잡한 작업을 간소화할 수 있는 도구의 가치를 깨달았습니다. 

하지만 시간이 지나면서 깨달은 한 가지 중요한 교훈은 고급 도구를 사용할 때에도 기본 원리를 이해하는 것이 중요하다는 것이었습니다. 이러한 초기 학습 경험은 제 커리어에 큰 영향을 미칠 기술인 Kubernetes에 대한 관심의 시초가 되었습니다. 다른 도구와 마찬가지로 Kubernetes를 이해하려면 기본 기술에 대한 확실한 이해가 필요합니다. 

쿠버네티스는 복잡하나요? 그렇습니다. 완벽할까요? 아니요. 모든 상황에 적합한가요? 아니요. 하지만 Kubernetes를 사용해야 하는지에 대한 질문은 Kubernetes를 강력하게 만드는 기본 기술과 이를 사용하여 소프트웨어를 관리하고 보호하는 방법에 대한 이해 여부에 따라 결정됩니다.

"Kubernetes가 무엇인가요?"라고 궁금해하시거나, 바지의 종류를 넘어 "Docker"라는 용어와 컨테이너와의 연관성에 아직 익숙하지 않으신 분들을 위해 설명해드리겠습니다. 

애플리케이션은 데이터베이스에서 프로그래밍 언어에 이르기까지 각 구성요소가 끊임없이 진화하고 있으며, 새로운 버전이 자주 출시됩니다. 각 애플리케이션의 여러 버전과 타사 구성 요소의 수많은 반복을 추적하는 것은 특히 메인스트림 지원이 없는 이전 버전이나 레거시 버전의 경우 관리가 까다로울 수 있습니다. 지원되는 소프트웨어 버전이라도 시스템 수준 및 타사 설치 종속성이 많기 때문에 애플리케이션의 구성 요소로 사용하는 것은 말할 것도 없고 소프트웨어를 실행하는 데 복잡성을 가중시킬 수 있습니다.

시간이 지나면 모든 소프트웨어는 결국 구식이 되어 최신 버전으로 교체됩니다. 문제는 필요할 때 오래된 소프트웨어를 실행하는 데 있습니다. 소프트웨어의 사소한 변경 사항도 최신 애플리케이션에 큰 영향을 미칠 수 있습니다. 예를 들어, Python 2.7(가장 최신 버전인 Python 3.11과 비교)은 Apple의 Mac OS X에 내장되어 있었습니다. Python 2.7에는 명령줄에 텍스트를 출력하는 이상한 구문이 있었는데, 최신 버전인 Python 의 보다 논리적인 버전인 `print("this thing")` 대신 `print "this thing" `이었습니다. 이 구문 하나 때문에 괄호가 누락되어 기존 Python 애플리케이션 전체가 중단될 수 있습니다.

이전 버전의 소프트웨어를 사용하는 것은 비현실적일 수 있지만, 구형 소프트웨어를 실행해야 하는 상황도 분명 존재합니다. 하지만 어떻게 해야 할까요? 

오래된 소프트웨어를 실행할 수 있는 특정 시점의 하드웨어 또는 가상 머신 이미지를 찾는 데 시간을 할애할 수도 있습니다. 또는 Docker가 개척한 개념인 컨테이너로 전환할 수도 있습니다. 컨테이너는 필요에 따라 수정할 수 있는 종속성과 함께 패키징된 독립적인 애플리케이션입니다. 컨테이너의 고유한 장점은 한 시스템에서 다른 시스템으로 원활하게 전환할 수 있다는 점입니다.

다음은 Python 2.7을 컨테이너의 빌딩 블록으로 사용하는 Docker파일의 예시입니다:

```dockerfile
FROM python:2.7.7-slim

COPY ./src /app/
WORKDIR /app

RUN python -m pip install -r requirements.txt

CMD [“python”, “manage.py”, “runserver”]
```

```dockerfile
FROM python:2.7.7-slim

COPY ./src /app/
WORKDIR /app

RUN python -m pip install -r requirements.txt

CMD [“python”, “manage.py”, “runserver”]
```

이 도커파일은 로컬 머신과 `/src` 아래의 로컬 경로에 존재하는 코드로 이 새 컨테이너를 빌드하는 데 필요한 것을 도커에게 알려줍니다. 도커파일은 훨씬 더 복잡해질 수 있지만, 이 예시는 도커를 사용하는 것이 얼마나 쉬운지 보여줍니다. 

이 컨테이너화된 애플리케이션을 빌드하고 실행하는 것은 매우 간단합니다:

```bash
docker build -f Dockerfile -t hello-python:v1 .
docker run hello-python -p 8000:8000
```

컨테이너화가 없다면 Python 2.7을 머신에 직접 설치해야 하는데, 이는 결코 간단하지 않습니다. Docker 및 기타 컨테이너를 사용하면 애플리케이션을 이식할 수 있으며, 이 예제에서 Python 2.7을 거의 모든 오픈 소스 언어 또는 도구로 대체할 수 있습니다.

그러나 컨테이너화된 애플리케이션을 업데이트하려는 경우, 특히 프로덕션 환경에서 문제가 발생합니다. 로컬에서 컨테이너를 업데이트하는 것은 간단합니다. 컨테이너 실행을 중지하고 다시 빌드한 다음 다시 실행하면 됩니다. 그러나 프로덕션 환경에서는 동일한 방식으로 컨테이너를 업데이트할 수 있지만 빌드에 실패할 경우 큰 다운타임이 발생할 위험이 있습니다.

이것이 바로 Kubernetes가 필요한 이유입니다. Kubernetes는 특정 컨테이너로의 트래픽 라우팅을 관리하고 특정 시간에 실행 중인 컨테이너의 수를 감독합니다. 컨테이너에 장애가 발생하는 경우, Kubernetes는 다운타임을 최소화하거나 전혀 없이 이전 버전으로 쉽게 롤백할 수 있도록 지원합니다.

쿠버네티스에 컨테이너를 배포하기 위한 구성을 매니페스트라고 한다. 다음은 비교적 간단한 매니페스트의 예시이다:

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-py-deploy
spec:
    replicas: 3
    selector:
        matchLabels:
            app: hello-py-deploy
    template:
        metadata:
            labels:
                app: hello-py-deploy
        spec:
            containers:
            - name: hello-py-container
              image: jmitchel3/hello-python:v1
              ports:
                - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: hello-py-service
spec:
    type: LoadBalancer
    ports:
        - name: http
          port: 80
          targetPort: 8080
          protocol: TCP
    selector:
        app: hello-py-deploy
```

위의 예에서, yaml 형식의 Kubernetes 매니페스트는 로드 밸런싱 서비스와 배포라는 두 가지 리소스를 프로비저닝합니다. 로드 밸런서는 트래픽을 배포로 라우팅하는 데 도움이 됩니다. 선언된 컨테이너의 `replicas: 3`을 통해, 선언된 컨테이너 `hello-python:v1`의 배포는 3개의 버전을 실행하고 있습니다.

이제 배포된 버전을 업데이트하고 싶을 때 `hello-python:v1`을 `hello-python:v2`로 변경하기만 하면 쿠버네티스가 애플리케이션을 정상적으로 업데이트합니다. 그리고 문제가 발생하면 `hello-py-deploy:v1`으로 롤백됩니다. 쿠버네티스는 이 프로세스를 쉽고 간편하게 관리할 수 있게 해줍니다. 매니페스트는 git으로 쉽게 버전 제어할 수 있으므로 롤백 기능을 매우 세분화할 수 있습니다. 컨테이너화된 애플리케이션을 자동화, 확장 및 관리하기 위한 프레임워크를 제공하여 점점 더 복잡해지는 소프트웨어 환경에서 시스템 복원력과 효율성을 보장하기 때문에 Kubernetes는 배포에 필수적인 요소입니다.

저는 Kubernetes를 통해 애플리케이션 배포를 간소화할 수 있는 방법을 발견하게 된 몇 가지 방법을 살펴보고 싶었습니다. Kubernetes를 최대한 활용하려면 몇 가지 단계를 거쳐야 했지만 가치 있는 여정이었습니다. 로드 투 쿠버네티스에서는 쿠버네티스 및 기타 최신 배포 관행에 뛰어들기 전에 이해해야 할 중요한 다양한 기술을 사용하여 애플리케이션을 배포하는 여정을 살펴볼 것입니다.

로드 투 쿠버네티스에서는 방법을 안내해드리겠습니다:

• 자체 호스팅 또는 클라우드 플랫폼에서 git 리포지토리 관리

• git을 사용하여 클라우드 기반 VM을 통해 Python 및 Node.js 앱 배포

• 다음을 사용하여 VM 구성 및 배포 자동화 Ansible

• Docker 및 Docker Compose로 앱 컨테이너화 및 배포

• 오케스트레이션 없이 VM에서 직접 컨테이너 실행

• DockerHub 레지스트리로 컨테이너 푸시 및 호스트하기

• 컨테이너화된 애플리케이션을 Kubernetes에 배포하기

• Kubernetes에서 퍼블릭 및 프라이빗 앱 구현하기

• HTTP 및 HTTP 트래픽에 대한 로드밸런서 구성

• Github Actions와 오픈 소스 대안인 Nectos의 Act를 사용하여 CI/CD 기술을 사용하세요.

• 그리고 더!

배포는 소프트웨어에 대한 궁극적인 테스트입니다. 로드 투 쿠버네티스는 15년간의 배포 학습을 하나의 접근 가능하고 실용적인 가이드로 압축한 책입니다. 이 책은 소프트웨어를 처음부터 배포하는 것부터 Kubernetes의 강력한 기능을 구현하는 것까지 안내합니다. 모든 언어와 모든 종류의 웹 앱에 사용할 수 있는 지속 가능한 배포 방법, 배포 옵션과 클라우드 제공자 간에 이동할 수 있는 이식 가능한 애플리케이션을 만드는 방법, 모든 규모의 프로젝트에 Kubernetes를 활용할 수 있는 방법을 배울 수 있습니다.

Kubernetes를 이해하기 위한 여정을 시작하려면 여기에서 Manning의 초기 릴리스 MEAP를 받으세요.