[k8s] 쿠버네티스 기초 스터디 1

쿠버네티스 스터디 

교재

- 쿠버네티스 교과서

https://product.kyobobook.co.kr/detail/S000208711643

쿠버네티스 교과서 | 엘튼 스톤맨 - 교보문고

 

로컬실습

- rancher Desktop

- kubectl

 

---

쿠버네티스

- 컨테이너를 자동으로 배포/관리/스케일링/복구해주는 컨테이너 오케스트레이션 툴

 

기능

- 배포 자동화

- 셀프 힐링 (첫 학습간 살펴본 내용 - Pod를 수동으로 삭제 시 Deployment가 자동으로 되살려놓음)

- 로드 밸런싱

- 수평 확장 (오토 스케일링)

- 롤링 업데이트/롤백

- secret key관리 & config 관리 (<-- 현재 번거로운 config 관리 문제를 해결 가능할 것 같음)

- 스토리지 관리

 

요소 정리

- Pod: 컨테이너 1개 이상이 실행되는 최소 단위 (내부에 컨테이너가 여럿 들어갈 수 있다고하지만 보통 1개로 쓴다고함)

- Node: 컨테이너가 실행되는 서버 (Pod과 살짝 헷갈림, Pod은 그냥 개념적인 컨테이너 래퍼고, Node가 물리적 서버인가?)

- Cluster: 여러 노드로 구성된 전체 쿠버네티스 환경

- Deployment: 앱을 어떤 방식으로 몇 개 실행할 지 정의 (Yaml 파일로 정의합니다.)

- Service: 외부/내부에서 Pod에 접근할 수 있게 해줌 (??)

- ConfigMap/Secret: 설정값 및 민감정보 저장용 (??)

 

---

1.1 장 매니페스트

- 애플리케이션을 기술한 yaml 파일은 애플리케이션 매니페스트라고 한다. 


2장  - 파드와 디플로이먼트로 컨테이너 실행하기

파드?
- 쿠버네티스의 기본 단위이자 컨테이너를 실제 실행하는 역할을 담당하는 리소스인 파드 

디플로이먼트?

- 파드의 관리를 담당하는 디플로이먼트 

컨테이너는 일반적으로 어플리케이션 구성 요소 하나를 실행하는 가상화된 환경을 가리킨다. 
그리고 쿠버네티스는 이 컨테이너를 또 다른 가상 환경인 파드로 감싼다. 

파드 <- 쿠버네티스가 컨테이너를 실행하는 수단 정도로 생각해도 틀리지 않다. 

 

자기수복성 (위에서 말한 self healing개념)
- 쿠버네티스는 파드에 필요한 컨테이너 개수를 유지시킨다,

- 때문에 파드 하나가 관리상에서 사라지거나 죽으면 자동으로 파드 개수를 채워준다. (여기서 관리상에서 사라진다는 표현을 쓴건, 밑에서 나오는 레이블이라는 개념 때문인데, 레이블로 리소스간 연결관계를 key value mapped된 데이터로 표현하는데 이때 연결관계를 임의로 수정 시 리소스간 관계가 끊어져서 유실된 것으로 간주하여 새 리소스를 자동으로 생성한다는 뜻임)

 

 

Pod에 대해
Pod는 쿠버네티스에서 컴퓨팅의 최소 단위다. 

하지만 파드는 원시 타입 리소스이므로 일반적으로 파드를 직접 실행할 일은 없다.
대개는 파드를 관리할 컨트롤러 객체를 따로 만들게 된다. (예를 들면 Deployment같은?)


2.2 컨트롤러 객체와 함께 파드 실행하기 
컨트롤러 객체는 다른 리소스를 관리하는 쿠버네티스 리소스
쿠버네티스에는 여러가지 컨트롤러 객체가 있는데, 그중에서도 파드를 주로 관리하는 컨트롤 객체가 디플로이먼트
어떤 노드가 고장을 일으켜 파드가 유실되면 디플로이먼트가 대체 파드를 다른 노드에 실행한다.  <-- 자기 수복성
즉 디플로이먼트는 파드를 관리하고, 파드는 컨테이너를 관리한다. 

 

관리

디플로이먼트 --> 파드 --> 컨테이너

 

Deployment 생성 명령어

kubectl create deployment hello-kiamol-2 --image=kiamol/ch02-hello-kiamol

디플로이먼트가 자신이 관리해야할 리소스를 어떻게 추적하는지? 
- 쿠베 전반에서도 쓰이는 패턴인데, 모든 쿠버네티스 리소스는 간단한 key-value 쌍 형태의 레이블을 가진다. (위에서도 언급함)

- 이 레이블에 원하는 데이터를 담는다. (메타데이터 저장하는 용도로 보면됨, 혹은 내가 원하는 임의의 Tag등을 넣을 수도 있음)
- 레이블을 이용해서 리소스 간 관계를 파악하는 것은 쿠버네티스에서 매우 자주 쓰이는 중요한 패턴이다. 그래서 pod의 레이블을 직접 수동으로 수정하면 리소스 간 관계를 흐트러트릴 수 있기 때문에 주의해야한다.

 

아래 명령어처럼 app이라는 key의 값이 hello-kiamol-2를 가진 레이블을 찾겠다(-l)는 의미의 명령어를 보면 쿠베에서 레이블의 key만으로 리소스를 찾는 형태가 빈번하다는 것을 알 수 있다. (여기서 -l 이 라벨 셀렉터다. 이 라벨이 붙은 pod만 조회하겠다는 뜻이다.)

kubectl get pods -l app=hello-kiamol-2

 

아래는 pod목록을 출력하는데 출력 패턴을 지정하는 명령어임 (여기서 -o는 출력 패턴을 지정하는 옵션임)

kubectl get pods -o custom-columns=NAME:metadata.name,LABELS:metadata.labels

 

 

 

애플리케이션 매니페스트 example

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-kiamol-4
spec:
  selector:
    matchLabels:
      app: hello-kiamol-4
  template:
    metadata:
      labels:
        app: hello-kiamol-4
    spec:
      containers:
        - name: web
          image: kiamol/ch02-hello-kiamol

 

---

 

현재 ECS에서 EKS 전환 시 이득

- 클라우드 벤더 락인 탈피 (?? BE와 큰 관련없는 이점)

- *** 쿠버네티스 생태계 활용 가능 *** 

- 표준화된 인프라 관리 (데브옵스랑 공통 언어로 협업) (?? BE와 큰 관련없는 이점)

- MSA, Job처리, 오토스케일링 조건 다양화 등 복잡하게 가능  (BE와 조금은 관련있는 이점)

 

 

쿠버네티스 생태계 (BE에 도움이 될 것으로 생각된 툴)

• Istio: 서비스 간 트래픽을 제어하는 서비스 메시 (메시라는 표현이 뭔지?)
  • MSA간 트래픽을 보안, 관측, 제어하게 해줌 (특정 트래픽만 10%보내기 + 트래픽 라우팅 + rate limiting, circuit breaker)
• Prometheus
  • Pod, Node, Deployment 등 쿠베 리소스 메트릭 수집함 (CPU, memory, request, error rate)등 모니터링 가능
• Grafana
  • 메트릭 시각화 대시보드 (대시보드 구성이 가능하므로 Datadog과 유사한 서비스로 보임)

위 세가지 정도 툴을 사용할 수 있는것이 현재 프로젝트에 도움이 될 수 있겠다고 생각함.

 

 

개인적으로 느낀점

첫인상은 컨테이너를 추상화하여 좀 더 세밀한 컨트롤이 가능한 오픈소스 정도라고 생각됨 (managed ECS의 컨트롤을 좀 더 엔지니어가 수동으로 할 수 있게 해주는 기술 정도 아닐까?)

무엇보다 같이 딸려있는 툴들이 좀 좋아보임 (생태계)

추가로 Argo workflow로 지금 Airflow실행하는 작업들을 전환할 수 있을까 정도를 생각하고 찾아보았는데, 그정도의 로지컬함을 지원하는 툴까지는 아님. (AWS MWAA가 비싸니까 대안이 있으면 좋겠다고 생각해서 찾아봤는데 아쉽게도...)