[Kubernetes] 쿠버네티스 배포 및 구성요소 / 쉽게 시작하는 쿠버네티스(v1.25) - 3일차

1. 배포를 통한 쿠버네티스 체험

1)  pod란?

• 컨테이너의 집합 하나의 일을 하기 위해 묶여진 집합
• 볼륨 - 계속 저장되어야 하는 데이터
• 대부분은 하나의 컨테이너가 하나의 파드로 이루어지는 형태가 많음

pod nginx 배포

• 명령어 kubectl run 이름 --image=이미지 이름

nginx pod 생성 완료

• pod 확인 명령어 : kubectl get pod

내부에서 nginx 접근 확인

2) 외부에서도 파드에 접근하게 하는 서비스

배포한 파드를 외부에서도 접속하게 하려면 ?

해결방법

1) 문을 없앤다.
2) 문 밖에 안전한 구역을 만들어준다. Service 영역

• Service 영역에 파드를 연결해두면 서비스를 통하여 파드를 찾아간다
• 노드 포트에 접근해서 노드에 접근 그 후 파드를 찾아간다

nginx 외부 노출

• 외부 노출 명령어 : kubectl expos pod 이름 --type=NodePort --port=포트번호
• 타입의 대소문자를 주의하여 입력해야 한다.
• 서비스가 노드포트를 통하여 외부로 노출된 것을 확인할 수 있다.

외부에서 nginx 접근 확인

 

3) pod와 deployment 차이

만약 pod가 한 개 밖에 없는데 그 pod가 어떠한 이유로 죽는다면 더 이상 받아줄 곳이 없다.
-> pod를 여러개 사용할 필요가 있다.

 

파드를 여러개 사용하려면?

->deployment를 사용하자

 

deployment란? pod를 여러개 가지고 있는 큰 단위

• 예전 1.16,1.17버전에서는 pod와 deployments를 kubectl run으로 배포할 수 있었지만
  현재의 버전에서는 pod만 배포할 수 있다.
• deployment를 배포하려면 kubectl create or kubectl apply 를 통하여 둘 다 배포할 수 있다
  *kubectl apply는 파일이 필요하다.
• kubectl run은 테스트 목적에 가깝고 거의 사용하지 않는다. 단일 pod로만 사용하는 곳이 거의 없기 때문이다.

deployment 배포

• 여러개 배포한다면서 왜 하나밖에 배포가 안된거지?
  -> 여러개를 배포하려면 내부에 ReplicaSet이라는 것의 도움을 받아야한다.

replicas 값 수정

• replicas 값 수정 명령어 : kubectl scale deployment 이름 --replicas=값

pod 수 증가

3)  외부로 노출하는 방법 로드 밸런서

노도포트가 외부로 노출하는 최선의 방법은 아니다.
-> 노드의 ip를 일단 알아야하고, 노드의 ip를사용자에게 직접 알려준다는 건 부담스럽다. 마치 대문의 비밀번호를 알려주는 느낌

 

deployment를 노출하는 가장 좋은 방법은 로드 밸런서라는 타입으로 선언하는 방법이 좋은 방법
현재 네이티브 쿠버네티스에서는 로드밸런서라는 타입이 기본으로 설정되어있지 않고 MetalLB라는 것을 사용해서 로드밸런서 타입을 사용할 수 있도록 함

metalLB 설치 완료

• 강의에서 제공해준 metallb.yaml으로 metallb를 설치했다.

로드밸런서를 이용할 deployment 생성

type LoadBalacer로 외부에 노출

pods 확인

노드포트보다 로드밸런서가 좋은 점

노드 포트는 ip를 알려줘야 함, 하지만 로드밸런서는 대표하는 ip를 만들어서 사용자에게 알려줄 수 있다. 또한 로드밸런서를 사용하면 가야할 경로를 최적화 하여 구현할 수 있음

 

2. 쿠버네티스 인사이드

1) 쿠버네티스 구성 요소

kube-system 구성요소

• 구역을 나누는 네임스페이스 (default, kube-system, metallb-system) (ex. 호텔의 101호, 203호 와 비슷하다)
• 쿠버네티스으 주요한 구성요소들은 kube-system 밑에 있다.
• 서로의 구역이 나누어져있고 무엇을 하는지 모른다.
• 네이티브 쿠버네티스가 아니고 다른 쿠버네티스도 구성이 같을까?
  ->AWS EKS, Azure AKS, Google GKE 에서도 쿠버네티스 구성요소 
  -> 3사의 쿠버네티스 구성 요소의 차이가 있으며 보여지지 않는 부분이 많다.
  -> 3사가 제공하는 관리형 쿠버네티스에서는 주요하게 다루는 부분은 보여주지 않는다.
  
  

2) 쿠버네티스의 철학

• 마이크로서비스 아키텍처 형태로 이루어져있다.
  ->하는 일들이 나누어져있다. vs 모놀리식 아키텍처 하나의 구역에서 여러가지 기능을 다 한다.

파드가 배포되면?

pod의 생명주기

1. API 서버 & etcd로 파드 생성요청을 보낸다.
   -> 일반적인 생각으로는 컨트롤러 매니저에게 명령을 한다고 생각하지만 파드의 생성 감시
2. 컨트롤러 매니저는 API서버에 선언 되어있는 값을 가지고 파드를 생성한다.
3. API서버는 모든 것에 중심에 있으며, 선언되어 있는 값만 가지고 있다.
4. API서버는 새로운 파드가 워커 노드에 들어갔는지 감시
5. 스케줄러가 API서버에 와서 바뀐 것이 없는지 확인하고 워커 노드에 넣도록 스케줄한다.
6. API서버는 Kubelet 새로운 파드가 노드에 잘 소속되어 있는지 감시
7. Kubelet은 API서버에게 파드 상태 정보를 전달
8. Kubelet은 컨테이너 런타임의 파드의 동작 관리를 한다.
9. 컨테이너 런타임이 컨테이너를 생성한다.

선언적인 시스템

-> 추구하는 상태와 현재 상태를 맞추려고 함

감시 -> 차이 발견 -> 상태 변경 ->감시 ... 

 

API 서버와 ETCD

API 서버와 ETCD

1. API 서버는 etcd에 매번 클러스터의 업데이트된 정보를 기록 (선언되어있는 정보)
2. etcd는 API서버에 업데이크 되었음을 알림

정리

쿠버네티스는 선언적인 구조이며, 각 요소들은 자기의 할 일만 한다.

선언되어 있는 값을 계속 추적하여 현재 상태와 계속 맞추려고 한다.