티스토리 뷰
Kubernetes and Container
목차:
0. Introduction
1. Containers
2. Kubernetes and Kubernetes Engine
0.Introduction
- 쿠버네티스는 개념적으로 IaaS를 제공하는 compute engine과 PaaS를 제공하는 app engine 사이에 위치하며 둘의 이점을 이용하고 있습니다.
- 쿠버네티스에 대해서 간단하게 정리한 포스팅입니다. 참고하세요.
쿠버네티스란?
쿠버네티스란? 쿠버네티스는 컨테이너를 쉽고 빠르게 배포/확장하고 관리를 자동화해주는 오픈소스 플랫폼입니다. 컨테이너 오케스트레이션이 하는 일은 여러 개의 서버에 컨테이너를 배포하
puzzle-puzzle.tistory.com
1. Containers
- (첫 번째 그림) 컨테이너의 개념은 PaaS에서 워크로드의 독립적인 확장성과 IaaS에서 OS 및 하드웨어의 추상화 계층을 제공합니다.
- (두 번째 그림) 우리가 얻는 것은 파일 시스템, 하드웨어의 자체 파티션에 대한 제한된 액세스와 함께 코드와 그 종속성 주위에 보이지 않는 상자입니다. 생성하는데 몇 개의 시스템 호출만 필요하며 프로세스만큼 빠르게 시작합니다.
- (두 번째 그림) 각 호스트에 필요한 것은 컨테이너와 컨테이너 런타임을 지원하는 OS 커널뿐입니다. 본질적으로 OS를 가상화하는 것입니다. PaaS와 같이 확장되지만 IaaS와 거의 동일한 유연성을 제공합니다.
- (세 번째 그림) 이 추상화를 통해 코드는 휴대성이 뛰어나고 OS와 하드웨어를 블랙박스로 취급할 수 있습니다.
- 예를 들어 웹 서버를 확장하려는 경우 몇 초 안에 이를 수행하고 단일 호스트에 수십 또는 수백 개 (크기 또는 워크로드에 따라 다름)를 배포할 수 있습니다. 이제 단일 호스트에서 전체 애플리케이션을 실행하는 하나의 컨테이너를 확장하는 간단한 예시를 보여드리겠습니다.
- 각각 마이크로 서비스와 같은 자체 기능을 수행하는 많은 컨테이너를 사용하여 애플리케이션을 빌드하고 싶을 때, 이러한 방식으로 구축하고 네트워크 연결을 통해 연결하면 모듈식으로 만들고 쉽게 배포하고 호스트 그룹 전체에서 독립적으로 확장할 수 있습니다. 또한 호스트는 앱에 대한 요구가 변경되거나 호스트가 실패할 때 컨테이너를 확장 및 축소하고 컨테이너를 시작 및 중지할 수 있습니다.
2. Kubernetes
- 위의 설명드린 상황을 잘 수행하는 데 도움이 되는 도구는 Kubernetes입니다. Kubernetes를 사용하면 여러 호스트에서 여러 컨테이너를 쉽게 오케스트레이션 하고, 마이크로 서비스로 확장하고, 롤아웃 및 롤백을 배포할 수 있습니다.
- 먼저 컨테이너를 빌드하고 실행하는 방법을 보여 드리겠습니다. 애플리케이션, 해당 종속성 및 머신 별 설정을 컨테이너에 번들링 하기 위한 형식을 정의하는 Docker라는 오픈 소스 도구를 사용합니다. Google Container Builder와 같은 다른 도구를 사용할 수 있습니다. 어떤 방식을 선택할지는 자유입니다.
2.1 Example
- 파이썬 웹을 가지고 예시를 들어보겠습니다. 먼저 파이썬 웹 코드를 준비합니다.
- requirements.txt 파일 사용 방법, Python 설치 방법 등을 명시합니다.
- 그리고 Dockerfile을 사용하여 코드를 컨테이너로 패키징 하는 방법을 지정합니다.
- 그런 다음 "docker build" 명령을 사용하여 컨테이너를 빌드합니다. 그러면 컨테이너가 빌드되고 실행 가능한 이미지로 로컬에 저장됩니다.
- 또한 이미지를 컨테이너 레지스트리 서비스에 저장 및 업로드하고 공유하거나 다운로드할 수 있습니다. 그런 다음 "docker run" 명령을 사용하여 이미지를 실행합니다.
- 수많은 오류들 중에서 애플리케이션 패키징은 문제의 약 5%에 불과합니다. 나머지는 애플리케이션 구성, 서비스 검색, 업데이트 관리 및 모니터링과 관련이 있습니다.
- 시스템은 control plane으로 실행되는 master구성 요소 세트와 컨테이너를 실행하는 nodes 세트로 나뉘어 있습니다. Kubernetes에서 노드는 컴퓨터와 같은 컴퓨팅 인스턴스를 나타냅니다. GCP에서 노드는 Compute Engine에서 실행되는 가상 머신입니다.
-애플리케이션 세트와 애플리케이션이 서로 어떻게 상호 작용해야 하는지 설명할 수 있으며 Kubernetes는 이를 실현하는 방법을 파악할 수 있습니다. 이제 컨테이너를 구축했으므로 하나를 클러스터에 배포해보겠습니다.
- Kubernetes는 많은 옵션과 추가 기능으로 구성할 수 있지만 처음부터 부트스트랩 하는데 시간이 오래 걸릴 수 있습니다. 대신 Kubernetes Engine 또는 (GKE)를 사용하여 Kubernetes를 부트스트랩 할 수 있습니다.
- GKE는 Google에서 호스팅 하는 Kubernetes입니다. GKE 클러스터는 맞춤 설정할 수 있으며 다양한 머신 유형, 노드 수, 네트워크 설정을 지원합니다. GKE의 클러스터에서 Kubernetes를 시작하려면 다음 명령어를 실행하기 만하면 됩니다.("gcloud container clusters create k1")이 시점에서는 'k1'이라는 클러스터가 구성되고 사용할 준비가 되어 있어야 합니다. admin console에서 상태를 확인할 수 있습니다.
- 다음으로 pod를 사용하여 하나 이상의 컨테이너를 래퍼를 이용하여 노드에 컨테이너를 배포합니다. Pod는 생성하거나 배포하는 Kubernetes에서 가장 작은 단위입니다.
- Pod는 클러스터에서 실행 중인 프로세스를 애플리케이션의 구성 요소 또는 전체 앱으로 나타냅니다. 일반적으로 팟 (Pod) 당 하나의 컨테이너만 있지만 종속성이 강한 여러 컨테이너가 있는 경우 단일 팟 (Pod)으로 패키징하고 네트워킹 및 스토리지를 공유할 수 있습니다.
- Pod는 컨테이너를 위한 고유 네트워크 IP 및 포트 세트와 컨테이너 실행 방법을 제어하는 옵션을 제공합니다. 포드 내부의 컨테이너는 다른 노드에서 시작 및 중지될 때 고정된 상태로 유지되는 로컬 호스트 및 포트를 사용하여 서로 통신할 수 있습니다.
- Kubernetes의 pod에서 컨테이너를 실행하는 한 가지 방법은 "kubectl run" 명령어를 사용하는 것입니다. 이 모듈의 뒷부분에서 더 나은 방법을 배우게 되지만 위 명령어를 통해 빠르게 시작할 수 있습니다. 그러면 Pod에서 실행 중인 컨테이너로 배포가 시작됩니다. 예시의 Pod 내부의 컨테이너는 nginx 서버의 이미지입니다.
- 배포는 동일한 pod의 복제본 그룹을 나타내며 노드가 실패할 때 실행되는 경우에도 pod가 계속 실행되도록 합니다. 또한 애플리케이션의 구성 요소 또는 전체 앱을 나타낼 수 있습니다. 이 경우 nginx 웹 서버입니다. 실행 중인 nginx 포드를 보려면 다음 명령어를 실행하시면 됩니다.
- 기본적으로 배포의 pod는 GKE 클러스터 내에서만 액세스 할 수 있습니다. 이를 공개적으로 사용하려면 kubectl expose 명령어를 실행하여 부하 분산기를 배포에 연결할 수 있습니다.
- Kubernetes는 pod에 대한 고정 IP로 서비스를 생성합니다.
- 컨트롤러는 "클러스터 외부의 다른 사용자가 액세스 할 수 있도록 공용 IP 주소가 있는 외부 로드 밸런서를 해당 서비스에 연결해야 합니다."라고 말합니다. GKE에서 부하 분산기는 Network Load Balancer로 생성됩니다.
- 해당 IP 주소에 도달하는 모든 클라이언트는 서비스 뒤의 pod로 라우팅 됩니다. 위 예시의 경우 nginx pod가 하나뿐입니다.
- 서비스는 Pod의 논리적 집합과 이에 액세스 하는 정책을 정의하는 추상화입니다. 배포가 Pod를 만들고 제거하면 Pod는 자체 IP 주소를 얻습니다. 그러나 이러한 주소는 시간이 지남에 따라 안정적으로 유지되지 않습니다.
- 서비스는 Pod 집합을 그룹화하고 이에 대한 안정적인 엔드 포인트 (또는 고정 IP)를 제공합니다. 예를 들어 프론트 엔드와 백엔드라는 두 세트의 Pod를 만들고 자체 서비스 뒤에 두면 백엔드 Pod가 변경될 수 있지만 프런트 엔드 Pod는 이를 인식하지 못합니다. 단순히 백엔드 서비스를 참조합니다.
- kubectl get services 명령을 실행하여 public IP를 가져와 nginx 컨테이너에 원격으로 연결할 수 있습니다.
- 배포를 확장하려면 kubectl scale 명령어를 실행합니다. 이 경우 3 개의 포드가 배포에 생성되며 서비스 뒤에 배치되고 하나의 고정 IP를 공유합니다.
- 모든 종류의 매개 변수와 함께 자동 확장을 사용할 수도 있습니다. 다음은 CPU 사용률이 80 %에 도달할 때 배포를 10 ~ 15 개 포드로 자동 확장하는 방법의 예입니다.
- 지금까지 노출 및 확장과 같은 명령형 명령을 실행하는 방법을 보여 드렸습니다. 이는 Kubernetes를 단계별로 학습하고 테스트하는 데 효과적입니다. 그러나 Kubernetes의 강점은 선언적 방식으로 작업할 때 나타납니다.
- 명령을 실행하는 대신 원하는 상태를 Kubernetes에 알려주는 구성 파일을 제공하면 Kubernetes가 이를 수행하는 방법을 알아냅니다. 기존 배포 구성 파일을 사용하여 배포를 확장하는 방법을 보여 드리겠습니다. 파일을 가져오기 위해 다음과 같이 kubectl get pods 명령을 실행할 수 있습니다.
- 그리고 다음과 같은 배포 구성 파일이 제공됩니다. 이 경우 nginx 포드의 복제본 3 개가 필요하다고 선언합니다. 배포에서 특정 Pod를 복제본으로 그룹화하는 방법을 알 수 있도록 선택기 필드를 정의하고 Pod 템플릿에 라벨을 추가하여 선택되도록 합니다.
- 이제 복제본을 보고 업데이트된 상태를 확인할 수 있습니다.
- 그런 다음 kubectl get pods 명령을 사용하여 포드가 온라인 상태인지 확인합니다. 이 경우 5 개 모두 READY 및 RUNNING입니다.
- 그리고 배포를 확인하여 $ kubectl get deployments 또는 $ kubectl describe deployments를 사용하여 적절한 수의 복제본이 실행되고 있는지 확인합니다. 이 경우 5 개의 포드 복제본은 모두 AVAILABLE입니다.
- 그리고 $ kubectl get services를 사용하여 서비스의 외부 IP를 가져오기 전과 같이 엔드 포인트에 도달할 수 있습니다.
- 클라이언트에서 public IP를 접근하세요. 이 시점에서 GKE에서 실행 중인 nginx 포드의 사본 5 개가 있고 트래픽을 5 개 포드 모두로 프록시하는 단일 서비스가 있습니다. 이를 통해 Kubernetes에서 부하를 공유하고 서비스를 확장할 수 있습니다.
- 앱의 새 버전을 업데이트하려는 경우 어떻게 진행할 수 있을까요? 사용자에게 새 코드를 표시하도록 컨테이너를 업데이트하고 싶지만 모든 변경 사항을 한 번에 배포하는 것은 위험할 수 있습니다.
- 따라서 kubectl 롤아웃을 사용하거나 배포 구성 파일을 변경하고 kubectl apply를 사용하여 변경 사항을 적용합니다. 업데이트 전략에 따라 새 포드가 생성됩니다. 다음은 새 버전 포드를 하나씩 만들고 이전 포드 중 하나를 제거하기 전에 새 포드를 사용할 수 있을 때까지 기다리는 구성 예시입니다.