17강 - 인트로 (Intro)
<Pod 생성>
nodeSelector → label : 특정 노드를 지정
resource → cpu, memeory : worker 노드의 resource는 pod에 지정된 resource보다 많아야 함
image → image : image를 가져와서 컨테이너와 앱이 만들어짐
<Pod 기동/운영>
probe를 설정하면 kubelet이 앱에 헬스 체크 API(/readiness, /startup, /liveness)를 날려준다.
앱에는 이 API에 맞춰 헬스 체크를 하는 로직이 필요함.
- configmap: 환경변수(envFrom)를 줄 수 있음, 애플리케이션에서는 파라미터를 받아서 처리해주는 설정이 있어야 함.
- secret : 민감하게 다루어야 되는 설정 파일의 경우 secret을 통해서 컨테이너로 마운팅 할 수 있음. 앱에서 이 파일에 접근하는 로직을 통해서 데이터를 읽ㄹ을 수가 있음.
-pv : 파일을 저장하고 영구적으로 보관을 해야 되는 경우 pv를 통해서 워커 노드에 넣을 수 있음.
(오른쪽 수집 서버 구조)
수집 서버 입장에서 모든 파드의 정보를 조회해 볼 목적으로 API를 날리는 상황이라고 가정했을 때
서비스에서는 파드로 트래픽을 랜덤하게 보내주기 대문에 트래픽을 여러번 시도해야지 모든 파드를 식별할 수가 있고, 이런 구조는 많은 네트워크 트래픽을 유발시키기 때문에 좋지 않은 구조이다.
기존 VMware 환경에서는 내가 배포할 앱에 대해서 고정 IP가 정해져 있었고 이 IP들을 모두 수집 서버에 config로 등록을 해서 딱 필요한 만큼의 조회 트래픽을 날렸었음.
근데 pod는 ip가 자동 생성되기도 하지만 pod가 재생성 됐을 때는 이 ip가 변경되기도 하기 때문에 쿠버네티스 환경에서 수집 서버는 내가 정보를 조회해야 될 pod들한테 트래픽을 보내기가 힘들어짐.
쿠버네티스 환경에서는 pod 스스로가 자신의 pod 정보를 수집 서버에 전송해주는 구성으로 만들어야 한다.
앱에서 내 pod 정보를 조회하는 로직이 필요하며, 그 로직에는 Args, File, kube-apiserver 라는 세 가지 방식이 있다.
이러한 구성이 마이크로 서비스 아키텍처에서 전체 트래픽을 줄이기 위한 구성이다.
그리고 또 애플리케이션이 내 ip주소를 알아야 되는 또 다른 경우가 있다면, 서비스를 통해서 특정 파드에 호출이 된 다음에 이후에는 두 파드끼리 서로 양방향 통신을 해야되는 경우가 있다. 대표적으로 P2P 통신이고, 메세징 관련된 어플리케이션을 만들 대 그 통신 로직에 내 IP주소를 넣어야 된다. 그래야 시스템 성능적인 면, 전체적인 네트워크 트래픽을 줄이는데 유리하다.
<Pod종료>
- SIGTERM(preStop) : pod 삭제 명령을 받으면 kubelet은 앱한테 종료 신호를 보내고, 어플리케이션으 스스로 종료가 될 때가지 기다린다.
- terminationGraceperiodSeconds : 어느 정도 시간이 지나도 앱이 스스로 종료되지 않으면 강제로 pod를 삭제시킨다.
그래서 앱에는 종료 신호를 받았을 때 현재 실행 중인 앱들을 잘 정리하도록 로직을 만들어놔야 한다.
- kubectl 재시작 사유 조회 : 앱은 종료 신호와 별개로 내부적으로 메모리 릭이 발생하거나 해서 장애가 발생하고 종료될 수도 있다. 이럴 때 쿠버네티스가 알아서 컨테이너를 재시작시켜주기 때문에 걱정할 필요는 없지만 한 번씩 이전 컨테이너가 왜 재시작됐는지에 대한 사유는 조회를 해봐야 한다. kubectl로 이전 컨테이너 상태를 확인하고, 앱이 종료될 때 특정 파일의 에러에 대한 사유를 저장해놓고 볼 수 있게 해주는 기능도 있다.
<Phase>
: 파드의 상태 속성
Pending : Pod 생성
Running : Pod 기동/운영
Succeeded/Failed : 파드 종료
<ContainerStatuses>
: 컨테이너 상태 속성
wating : Reason(CrashLoopBackOff/ContainerCreating)
Runnung
Terminated : Reason(Completed/Error)
'인프런 > 쿠버네티스 어나더 클래스 (지상편) - Sprint 3' 카테고리의 다른 글
섹션 6. - 가장 이해하기 어려운 Ingress, 그리고 Nginx의 수 많은 기능들 (0) | 2025.01.29 |
---|---|
섹션 5. - 인프라 구성으로 배우는 Service의 거의 모든 기능들 (0) | 2025.01.29 |
섹션 3. - 로컬 환경 세팅 (0) | 2025.01.29 |
섹션 2. - 가상화 한방정리 (0) | 2025.01.29 |
섹션 1. - Sprint3 - 강의 소개 (0) | 2025.01.29 |