Kubernetes(쿠버네티스) 개념 정리하기

들어가기 앞서

본 포스팅은 subicura님의 강좌를 보고 정리한 글입니다.

쿠버네티스 시작하기 - Kubernetes란 무엇인가?

초보를 위한 쿠버네티스 안내서 - 인프런

 

 

 

컨테이너 오케스트레이션

등장배경

1) 서버관리의 어려움으로 도커의 등장

2) 도커의 장점으로 인해 모든 서버관리를 도커 이미지/컨테이너로 관리하기 시작함

3) 그러한 컨테이너가 엄청나게 많아져서 컨테이너를 관리해야 할 필요가 생기기 시작

-> 복잡한 컨테이너 환경을 효과적으로 관리하기 위한 도구로 "컨테이너 오케스트레이션" 등장

-> 서버관리자가 해야하는 일들을 대신해주는 프로그램을 만드는 것

 

컨테이너 오케스트레이션이 하는 일

1) 중앙제어 (클러스터 단위로 추상화, 마스터서버 두고 관리)

2) 네트워킹

3) 노드 스케일

4) 상태 관리 

5) 배포 관리

6) 버전 관리

7) 서비스 등록 및 조회

8) 볼륨 스토리지

 

컨테이너 오케스트레이션 종류

- 매우 다양함

- 도커에서도 스웜을 만듦

- 그 중 쿠버네티스가 표준처럼 등장함

 

 

 

쿠버네티스

https://bcho.tistory.com/1269

왜, 그 중 쿠버네티스인가?

- 우선 쿠버네티스란, 컨테이너를 쉽고 빠르게 배포/확장하고 관리를 자동화해주는 오픈소스 플랫폼 (구글관리)

- 오픈소스, 활발한 활동, 인기가 많음, 무한한 확장성, 행성스케일, 유연함, 어디서든 동작, 사실상의 표준, 클라우드에 적합

- 도커도 어쩔수 없이 스웜말고도 쿠버네티스를 지원함

 

컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리

- 데모나 직접 실습을 하는 것이 더 이해하기 편함

 

쿠버네티스를 줄여서 k8s라고 함 (혹은 큐브)

 

 

 

1. 쿠버네티스 아키텍처 (구성 및 흐름)

기본적인 동작 방식

기본적인 동작 : https://subicura.com/2019/05/19/kubernetes-basic-1.html

-> 컨테이너 1개를 생성하라는 요청이 들어오면 Desired State에 기록해놈

-> Current State가 컨테이너 1개라는 Desired State와 다르므로 조치를 취함

-> 즉, 상태 체크(Observe) -> 차이점 발견(Diff) -> 조치(Act) -> 상태 체크(Observe) -> loop...

-> 이러한 루프를 하는 애들을 Controller라고 하고, 만들 수 있음

-> 종류도 다양함 (Replication, Endpoint, Namespace, Custom, ML, CI/CD ... controller)

 

 

구성

간략화한 마스터와 노드 : https://subicura.com/2019/05/19/kubernetes-basic-1.html

 

 

Master 더보기

Master : https://subicura.com/2019/05/19/kubernetes-basic-1.html

etcd (엣지디, 이티씨디)

- "모든 데이터를 확실하게 관리, 저장"

- 모든 상태와 데이터를 저장

- 분산 시스템으로 구성하여 안정성을 높임

- 가볍고 빠름, 정확한 설계 가능

- Key-Value 형태로 데이터 저장

- TTL(Time To Live), watch 같은 부가기능

- 백업

 

API server

- "조회나 요청은 모두 API server를 통해서"

- etcd와 유일하게 통신하는 모듈

- 상태를 바꾸거나 조회

- REST API 형태로 제공

- 권한을 체크하여 적절한 권한이 없을 경우 요청을 차단

- 관리자 요청 뿐 아니라 다양한 내무 모듈과 통신

- 수평으로 확장되도록 디자인

 

Controller

- "Loop 반복"

- 생성 요청이 있는지 체크 및 할당 요청 (with etcd) 

- 끊임 없이 상태를 체크하고 원하는 상태를 유지

- 논리적으로 다양한 컨트롤러가 존재

- 복제 컨트롤러, 노드 컨트롤러, 엔드포인트 컨트롤러..

- 복잡성을 낮추기 위해 하나의 프로세스로 실행

 

Scheduler

- "어디에, 어떤 노드에, 할당할까"

- 할당 요청이 있는지 체크 및 할당 (with etcd)

- 생성 요청된 Pod을 감지하고 실행할 노드를 선택

- 노드의 현재 상태와 Pod의 요구사항을 체크

 -> 노드에 라벨을 부여

 

흐름

1) Controller가 API Server에게 Desired State요청

2) API Server가 etcd한테 읽기 권한 체크 후 정보 조회

3) 변경된 Desired State를 API Server에게 주고 그것을 Controller에게 줌

4) Controller는 CurrentState를 DesiredState로 리소스 변경

5) 변경된 내용을 API Server에게 전달

6) API Server가 etcd한테 수정 권한 체크 후 정보 수정

 

 

Node 더보기

노드 : https://subicura.com/2019/05/19/kubernetes-basic-1.html

Kubelet

- "컨테이너를 확실히 관리"

- 미실행중인 Pod 체크 및 생성, 실행 (with etcd)

- 각 노드에서 실행

- Pod을 실행/중지하고 상태 체크

- API Server를 통해 할당된 Pod중에 미실행인 Pod확인

- CRI (Container Runtime Interface)

 -> docker, Containerd, CRI-O

- 컨테이너를 직접 사용하는 것이 아닌 Pod이라는 것으로 감싸서 사용

 

Proxy

- "내/외부 통신 설정"

- 네트워크 프록시와 부하 분산 역할

- 성능상의 이유로 별도의 프록시 프로그램 대신 iptables or IPVS을 사용 (설정만 관리)

 

흐름 다시보기 (*매우 중요)

-> kubectl로 Pod요청

-> API Server -> etcd에 Pod 생성 요청으로 수정

-> Controller가 etcd 조회 결과에 생성 요청이 있으므로 Pod 할당하는 요청을 함

-> etcd에 Pod 할당 요청으로 수정 됨

-> Scheduler가 etcd 조회 결과에 Pod할당 요청이 있으므로 특정 Node에 Pod을 할당

-> API Server -> etcd에 Pod을 노드에 할당 + 미실행으로 수정

-> Node의 Kubelet이 etcd에 미실행 Pod을 확인함

-> Kubelet이 Pod을 생성 및 실행

-> 그 정보를 etcd에 실행중인 Pod으로 수정

-> Scheduler, Controller, Kubelet은 계속해서 상태 체크

흐름 : https://subicura.com/2019/05/19/kubernetes-basic-1.html

 

Addons(에드온) 더보기

- CNI (네트워크), DNS (도메인, 서비스 디스커버리), 대시보드 (시각화)를 제공

 

 

 

2. 쿠버네티스 아키텍처 (오브젝트)

Pod

가장 작은 배포 단위

컨테이너를 직접 사용하는 것이 아니라 Pod으로 감싸서 사용

여러개의 컨테이너가 하나의 Pod에 속할 수 있음 (보통 하나)

전체 클러스터에서 고유한 IP를 할당받아서 사용

Pod : https://subicura.com/2019/05/19/kubernetes-basic-1.html

 

ReplicaSet

여러개의 Pod을 관리

새로운 Pod은 해당 Pod Template을 참고하여 생성

신규 Pod을 생성하거나 기존 Pod을 제거하여 원하는 수(Replicas)를 유지

ReplicaSet : https://subicura.com/2019/05/19/kubernetes-basic-1.html

 

Deployment

배포 버전을 관리

내부적으로는 ReplicaSet을 이용

예를들어 버전 v1 -> v2로 무중단으로 옮길 때

기존에 있던 ReplicaSet의 replicas를 0으로 만들고

새로 ReplicaSet을 만들어, 이것을 기존에 있던 replicas로 하여 하나씩 옮김

Deployment : https://www.inflearn.com/course/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-%EC%9E%85%EB%AC%B8 강의중에

 

다양한 Workload

cf) 위의 ReplicaSet, Deployment 말고도 다양한 워크로드를 제공

 -> DaemonSet, StatefulSet, Job... 

 

Service - ClusterIP

클러스터 내부에서 사용하는 프록시

-> 외부에서 ClusterIP로 접근하지 못함 -> 이때는 NodePort를 사용할 수 있음

로드밸런서 역할을 할 수 있음

-> 서비스로 들어오면 연결된 Pod중 하나로 감

Pod은 동적이지만 서비스는 고유한 IP를 가짐

Service ClusterIP : https://www.inflearn.com/course/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-%EC%9E%85%EB%AC%B8 강의중

 

Service - NodePort

노드(host)에 노출되어 외부에서 접근 가능한 서비스

ClusterIP는 내부만 통신이 가능하므로 외부랑 통신이 가능한 NodePort 서비스가 있음 -> ft_services에서는 사용하지 못함

모든 노드에 동일한 포트로 생성

-> 이로 인해 어느 노드에 요청을 보내도 원하는 Pod과 통신이 가능함

Service NodePort : https://www.inflearn.com/course/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-%EC%9E%85%EB%AC%B8 강의중

 

Service - LoadBalancer

하나의 IP주소를 외부에 노출

NodePort가 물론 통신이 가능하나, Node가 죽었을 경우 중단되는 현상을 방지하기 위함

외부요청 -> 로드밸런서 -> 노드포트 -> 클러스터IP -> Pod

Service LoadBalancer : https://www.inflearn.com/course/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-%EC%9E%85%EB%AC%B8 강의중

 

Ingress

도메인 또는 경로별 라우팅

-> 도메인 혹은 Path로 접근이 가능하게 함 (example.com 혹은 example.com/help)

 

일반적인 구성

Deployment -> ReplicaSet -> Pod

+ Service - Cluster, NodePort, LoadBalancer를 붙임

+ Ingress 도 붙임 (참고로 Ingress를 붙이면 NodePort랑 LoadBalancer가 따라옴)

 

cf) k8s 가 어려운 이유는 추상적인 개념이 많기 때문, 그래서 실습하면서 익히는게 중요

 

 

 

3. 쿠버네티스 아키텍처 (API 호출)

YAML (야믈) 파일을 이용함 (json은 잘 안쓴다고 함)

원하는 상태(Desired State)를 다양한 오브젝트(object)로 정의(spec)하고 API서버에 .yml형식으로 전달

예시    (cf. ReplicaSet을 만들경우 spec이 더욱 상세해짐)

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  container:
    - name: my_ubuntu
      image: ubuntu

 

 

 

YAML 문법

1) 들여쓰기

기본적으로 2칸(o) 또는 4칸

 

2) Key: value 형식

key: 다음에 띄어쓰기가 꼭 필요함

 

3) 배열은 - 로 표시

skills:
  - docker
  - kubernetes

 

4) 주석은 #

 

5) 참/거짓은 true, false, yes, no 가능 (대소문자X)

 

6) 숫자를 따옴표로 감싸서 사용하면 string으로 인식

 

7) 여러줄 표현

| : 줄바꿈

|- : 마지막 줄바꿈은 제외

> : 지시어 중간에 들어간 빈줄은 제외

 

8) 주의

key: value는 띄어쓰기 필요

:가 value라면은 " "를 사용

 

9) YAML Lint로 문법 유효성 검사

YAMLlint - The YAML Validator

 

 

 

설치 및 따라하기 (for MAC)

minikube

클러스터를 실행하려면 스케줄러, 컨트롤러, api서버, 엣지드 등 설치해야 하고 많은 설정이 필요하나

이러한 설치를 쉽고 빠르게 하기위한 도구가 minikube임

즉, minikube를 이용해서 가상환경을 만들고 클러스터를 빠르게 만들 수 있음

# 설치
# homebrew가 없다면 따로 설치해야 함
brew install minikube

# 가상머신 시작
# minikube는 다양한 가상머신을 지원함
# minikube start를 하면 k8s버전을 가상머신에서 다운받음
# 이 이미지안에 k8s에서 필요한 스케줄러, 컨트롤러, 큐블릿 등이 포함
minikube start --driver=hyperkit
# hyperkit을 사용할 수 없다면 virtualbox사용
minikube start --driver=virtualbox
# 특정 k8s버전 실행
minikube start --kubernetes-version=v1.20.0

# 상태 확인
minikube status

# 정지
# 실습을 다하면 정지를 해줘야 함
# 가상머신이기 때문에 리소스 잡아 먹음
# 다시하고 싶으면 start하면 됨
minikube stop

# 삭제
minikube delete

# ssh로 가상머신에 접속 -> exit로 나옴
# docker ps -a하면 아키텍처 구성요소가 보임
minikube ssh

# ip확인
# minikube가 만든 가상머신의 ip를 알아옴
minikube ip

 

kubectl

쿠버네티스에 명령을 전달하기 위해서 kubectl을 사용함

# 설치
brew install kubectl

# 버전확인
# 강의에서는 서버 GitVersion:v1.20.0을 사용
kubectl version

 

 

 

실습

실습 토폴로지? : https://subicura.com/k8s/guide

일단 minikube를 실행함

minikube delete

minikube start --driver=hyperkit

minikube status

 

링크 : guide/index/wordpress-k8s.yml 

위의 yaml 파일을 작성한 후에 kubectl이용

 

# yml파일을 적용시킴 -> yml에 맞춰서 배포함

kubectl apply -f wordpress-k8s.yml

 

# 배포 상태 확인

kubectl get all

 

minikube ip로 확인한 ip와 배포 상태에서 보인 wordpress의 호스트 포트를 로컬 브라우저에 입력해보면 워드프레스를 볼 수 있음

 

# 삭제 후 다시 로딩이 되는지 확인하기

kubectl delete pod/wordpress-5f59577d4d-pzzfb

잠시 워드프레스가 내려갔다가 알아서 재실행 됨

kubectl get all로 AGE 확인

잠시 내려가는 것도 싫다면 replicas를 2로 두고 다시 apply하면 됨

 

# 전체 삭제는 만든거에 반대

kubectl delete -f wordpress-k8s.yml

전체 삭제 -> 확인 -> 확인 -> minikube stop -> 확인

이게 기본적인 실습

 

더 자세히 알아봐야 할 듯 -> ft_services에서는 쓰면 안되는 것이 있기 때문

 

연습은 여기서

subicura.com/k8s/guide/kubectl.html#kubectl-%E1%84%86%E1%85%A7%E1%86%BC%E1%84%85%E1%85%A7%E1%86%BC%E1%84%8B%E1%85%A5

기본 명령어