10일차

섹션11 Kubernetes 시작하기

쿠버네티스는 컨테이너화 된 애플리케이션의 배포, 확장 및 관리를 자동화하기 위한 오픈소스 시스템
컨테이너 배포에 도움이 되는 것, 도구 및 작업 방법의 모음이다.

수동 배포의 더 많은 문제점들

• 컨테이너가 충돌하거나, 다운될 수 있으며 새 컨테이너로 교체해야 한다
• 충돌이 발생할 때마다, 수동으로 모니터링 해야 하며 수동으로 다시 시작해야 한다
• 트래픽 중가시 더 많은 컨테이너가 필요하다
• 들어오는 트래픽을 균등하게 분할하여 한 컨테이너가 모든 작업을 수행하지 않도록 해야한다

Kubernetes가 정확히 무엇인가?

오픈소스 프로젝트

• 클라우드 서비스가 아님 AWS나 Azure의 대안이 아니다
• AWS는 실제로 쿠버네티스를 사용하는데 도움이 되는 서비스를 제공할 것이지만 쿠버네티스 자체는 오픈소스 프로젝트이며, 자체 머신에서 사용할 수 있다
• 도커의 대안이 아니다. 도커 컨테이너와 함께 작동하여 컨테이너를 어디에나 배포할 수 있다

Kubernetes is like Docker-Compose for multiple machines

쿠버네티스로 배포하는 방식, 컨테이너 스케일링, 컨테이너가 실패할 경우의 모니터링하는 방법과 컨테이너를 교체하는 방법을 정의할 수 있다.

또한 자동배포, 스케일링, 로드 밸런싱, 일반적인 배포와 컨테이너 관리와 같은 태스크를 수행하는데 도움이 된다.

쿠버네티스는 여러 머신을 위한 Docker-Compose라고 생각할 수 있다.
도커 컴포즈는 우리의 로컬머신에서 다중 컨테이너 프로젝트를 쉽게 관리하는데 도움이 된다.
쿠버네티스는 다중 머신 설정에 대해서도 동일한 작업을 수행한다.
애플리케이션을 배포할 때 하나의 머신이 아니라, 여러 컴퓨터, 여러 머신에서 애플리케이션을 실행한다.

따라서 다중 머신 설정에서 도커화되고 컨테이너화된 애플리케이션을 관리하고 실행하기 위한 몇가지 편리한 배포 특정 부가 기능이 있는 도커 컴포즈와 같다.

Kubernetes: 아키텍쳐 & 핵심 개념

Pod(컨테이너)

쿠버네티스의 가장 작은 단위
구성파일에서 정의할 수 있다
파드는 컨테이너를 보유한다
Pod는 워커 노드에서 자신을 실행한다

Worker Node

워커 노드는 컨테이너를 실행한다
워커 노드를 가상 인스턴스라고 생각할 수 있다
워커 노드는 특정 양의 CPU와 메모리가 있는 어딘가의 머신이며 그 위에 Pod를 실행한다.

Proxy/Config

프록시는 쿠버네티스가 워커 노드의 Pod 네트워크 트래픽 제어를 설정하는 또다른 도구
프록시는 기본적으로 이러한 포드가 인터넷에 연결할 수 있는지 여부와
내부에서 실행되는 컨테이너를 외부 세계에서 어떻게 접근할 수 있는지를 제어한다.

예를 들어 컨테이너에서 웹 애플리케이션을 실행하는 경우 사용자의 외부 트래픽이 이 컨테이너에 도달할 수 있도록 프록시를 구성해야 한다.

쿠버네티스로 작업할 때 일반적으로 하나 이상의 워커 노드가 필요하다.
그렇지 않으면 포드와 컨테이너를 실행할 장소가 없기 때문이다.

Master Node

마스터 노드는 단순히 다른 서버, 다른 리모트 머신이다.
마스터 노드는 마스터 노드에서 실행 중인 이 컨트롤 플레인을 갖고 있으며, 워커 노드와 워커 노드 상에서 실행 중인 Pod와 상호작용하는 책임을 가진다.

다른 머신에 있기 때문에 워커 노드가 다운되어도 마스터 노드가 함께 다운되지 않는다!

Control Plane
마스터 노드의 내부에 있다.
워커 노드와 상호작용하여 제어하는 컨트롤 센터이다.
마스터 노드에서 실행되는 다양한 서비스의 다양한 도구 모음이다.

이 모든 것들이 클러스터를 형성한다.
마스터 및 워커 노드의 클러스터를 형성하고, 이러한 모든 부분이 연결된 하나의 네트워크를 형성한다.
그런 다음 마스터 노드는 클라우드 프로바이버 api에 명령을 보내 그 클라우드 프로바이더에게 특정 리소스를 생성하고 이 최종 상태를 클라우드 프로바이더에게 복제하도록 지시한다.

워커 노드 자세히 살펴보기

워커노드는 단순히 우리의 컴퓨터, 어딘가에서 실행 중인 ec2 인스턴스이다.
마스터 노드에서 관리한다.
워커 노드 내부에 Pod가 있다.
Pod는 하나 이상의 애플리케이션 컨테이너와 컨테이너에 속한 리소스를 호스팅한다.
예를 들어, 컨테이너를 올바르게 실행하기 위한 구성이나 볼륨같은 것도 리소스에 들어가있다.

포드 자체는 쿠버네티스에 의해 관리된다.
쿠버네티스는 Pod를 생성하거나 삭제할 수 있다.
Pod 내부에 여러 컨테이너와 볼륨을 가질 수 있다.

워커노드에는 둘 이상의 Pod가 실행되는게 일반적이다.
같은 Pod일 수도 있고 완전히 다른 역할을 할 수도 있다.

• Docker
• Kubelet
• Kube-proxy

Docker: 컨테이너를 생성하고 실행하는 포드라 당연히 필요하다
Kubelet: 워커 노드와 마스터 노드 간의 통신 장치, 마스터 노드가 이 워커 노드의 Pod를 제어할 수 있도록 한다.
Kube-proxy: 들어오고 나가는 트래픽을 처리한다. 허용된 트래픽만이 포드에 접근하게 한다.

마스터 노드 자세히 살펴보기

• API Server
• Scheduler
• kube-controller-manager
• Cloud-Controller-Manager

API Server
마스터 노드 내부에서 가장 중요한 서비스는 api 서버이다.
워커노드의 kubelet 서비스와 통신하는 서비스이다.

Scheduler
Pod를 관찰하고 어떤 Worker Node에서 실행할던지 선택하는 스케줄러이다.
Pod가 비정상적이 되거나, 다운되었거나, 또는 스케일링으로 인해 새로운 Pod를 생성해야 한다.
실제로 워커 노드에 무엇을 알려야 하는지 api 서버에 알리는 역할을 한다.

kube-controller-manager
워커노드 전체를 감시하도 제어하며 적당한 수의 포드를 가동 중에 있는지 확인하는 역할을 한다.
그러므로 스케줄러 및 api 서버와 긴밀하게 연동된다.

Cloud-Controller-Manager
동일한 작업을 수행하지만 클라우드에 따라 다르다.
AWS, Azure과 같은 클라우드 프로바이더에게 무엇을 해야 하는지 알려준다.

중요 용어 & 개념

• Cluster
• Node
• Pod
• Containers
• Services

Cluster
클러스터는 노드 머신, 마스터, 워커 노드 배포 혹은 원하는 최종 상태를 구성하는 컬랙션 세트

Node
하나 또는 여러 개의 Pod를 호스팅하는 특정 하드웨어 용량을 가지며 클러스터와 통신하는 물리적인 머신이다.

Master Node
Pod를 관리하는 컨트롤 플레인을 가졌다.

Worker Node
Pod를 호스팅하는 실제 머신이며, 얍 컨테이너와 이러한 컨테이너에 필요한 리소스를 실행한다.

Pod
애플리케이션 컨테이너와 요구 리소스가 포드라고 하는 유닛으로 결합됨을 의미한다. 포드는 컨테이너를 감싼 껍질이다. 컨테이너를 시작하여 컨테이너를 관리한다. Pod 자체는 마스터 노드에 의해 관리된다. 그리고 Pod가 생성되는 것은 Pod에서 컨테이너를 실행하는 것과 같다.

Container
일반 Docker 컨테이너이다.

Services
고유한 Pod 및 컨테이너에 독립적인 IP 주소를 가진 포드 그룹이다.
서비스는 Pod에 접근하는데 중요하며, 따라서 그 안에 있는 컨테이너도 중요하다.
서비스는 프록시와 관련있다.
서비스는 특정 포드를 외부로 노출하여 특정 IP 주소 또는 도메인으로 특정 Pod에 연결할 수 있도록 하는 용어이다.

11일차

섹션12(1/2) 실전 Kubernetes - 핵심 개념 자세히 알아보기

쿠버네티스는 인프라를 관리하지 않는다

내가 해야 하는 작업들

• 머신을 미리 생성한다
• 클러스터와 노드 인스턴스 생성
• 쿠버네티스 api 서버, kublet등 다양한 서비스를 설치해야 한다

쿠버네티스는 애플리케이션이 필요한 인프라를 관리하지 않는다!

• 작업하려는 컴퓨터에 대해 전혀 알지 못한다.

쿠버네티스가 하는 작업들

• Pod를 생성한다
• Pod에서 컨테이너를 실행
• 모니터링, 교체, 스케일링
• 워커노드와 생성한 머신을 활용한다

요구 설정 & 설치 단계

kubectl
클러스터에 명령을 보내는데 사용하는 도구
마스터 노드에 명령을 보낼 수 있다
마스터 노드는 워커 노드와 관련하여 필요한 모든 작업을 수행한다

m1 minikube 설치

brew install minikube
minikube start --driver=docker --container-runtime=containerd

쿠버네티스 객체(리소스) 이해하기

• Imperatively, Declaratively하게 객체 생성 가능하다

Declaratively하게 접근할 예정

Pod

• 쿠버네티스가 알고 있으며 상호 작용하는 가장 작은 유닛
• 하나 또는 여러 개의 컨테이너를 포함하고 실행한다
• 컨테이너 뿐만 아니라 볼륨 같은 공유 리소스를 보유한다
• 외부와 통신이 가능하다
• 디폴트로 클러스터 내부 IP 주소를 가지고 있다
• 이 주소는 Pod와 Pod에서 실행 중인 컨테이너에 요청을 보내는데 사용된다
• Pod에 여러 컨테이너가 있을 경우 localhoist를 사용해서 서로 통신할 수 있다

중요

• Pod는 임시적이다
• Podrk 쿠버네티스에 의해 교체되거나 제거되면, Pod의 모든 리소스는 사라진다
• Pod를 직접 관리하지 않고 Deployment 객체를 만들어서 관리한다
• for Pods to be managed for you. you need a Controller(=Deployment)

Deployment 객체

• 생성하고 관리해야 하는 pod의 수와 컨테이너 수에 대한 지침을 제공
• deploy 객체는 하나 이상의 pod를 제어할 수 있다
• 원하는 목표 상태를 설정하면 쿠버네티스는 이 목표 상태에 도달하기 위해 필요한 모든 작업을 수행한다
• pod를 생성하고 워커 노드에 배치하는 모든 일들을 쿠버네티스가 관리한다
• deployment를 멈추가 삭제하고 롤백도 가능하다
• deployment도 스케일링이 가능하다

첫 번째 Deployment - 명령적 접근 방식 사용

kubectl get deployments 클러스터에 deployment가 얼마나 있는지 확인할 수 있다

하나의 deployment가 있고 그 중 1개가 준비되어 있다. (READY)

deployment에서 생성된 모든 pod

kubectl delete depolyment first-app 디플로이먼트 삭제

kubectl: 작동 배경

Service 객체 (리소스)

Service로 Deployment 노출하기

컨테이너 재시작

실제 스케일링

Deployment 업데이트하기

Deployment 롤백 & 히스토리

명령적 접근 방식 vs 선언적 접근방식