쿠버네티스
클러스터 > 노드 > 파드 > 컨테이너
컨테이너화된 애플리케이션 배포, 관리, 확장 및 자동화된 운영을 위한 오픈소스 시스템이다. 주로 도커같은 컨테이너화 기술 사용해 애플리케이션을 배포하고, 이를 여러 서버에 분산시켜 관리할 수 있게 해준다.
- 자동화된 확장 제공한다!
- 트래픽이 급증하면 자동으로 prod를 늘릴 수 있음.
- 트래픽이 줄어들면 자동으로 줄여 자원을 효율적으로 사용할 수 있는 자동 스케쥴링 기능이 있다.
클러스터
쿠버네티스 내 가장 큰 단위로, 가상 서버들이 속한 클라우드이다.
쿠버네티스에서 서버는 노드라는 단위로 불린다.
클러스터는 마스터노드 + 워커 노드를 합친 것이다.
노드
노드란 클러스터 내 가상 서버 = 컴퓨터 엔진 단위이다.
클러스터 다음으로 큰 단위이고, 마스터 노드와 워커 노드로 분리되어 있다.
마스터 노드
전체 쿠버네티스 시스템을 관리 및 통제하는 쿠버네티스 컨트롤 플레인을 관장한다.
워커노드
배포하고자 하는 어플리케이션의 실제 실행을 수행한다.
Pod
![](https://blog.kakaocdn.net/dn/dBSduk/btsL7PZ9gyc/LMa6OcKJ9VddFJG3w2a3J1/img.png)
kubernates에서 가장 작은 배포 단위이자 관리 단위이다.
하나의 pod = 하나 이상의 컨테이너를 실행하는 논리적인 단위
- pod 안에 여러개의 컨테이너를 탑재할 순 있지만, pod와 컨테이너는 1:1로 매핑하는 것이 좋다.
- 예를 들어 redis와 mysql 같은 것들은 상시로 상태를 유지하고 있어야 하는데, 같은 pod로 엮게되면 여차할 때 종료될 수 있다.
1. 컨테이너의 묶음
![](https://blog.kakaocdn.net/dn/bwvYUC/btsL8FJrXqK/lrk03g1vxH7ww53KMWwIRk/img.png)
pod는 기본적으로 하나 이상의 컨테이너로 구성된다. 하지만 보통 하나의 컨테이너만 포함하는 경우가 많다.
같은 Pod에 포함된 컨테이너들은 같은 네트워크 = 네임스페이스를 공유한다. = 같은 IP주소, 포트를 공유해 쉽게 통신이 가능하다.
2. 같은 호스트에서 실행
같은 pod에 속한 컨테이너들은 같은 노드에서 실행된다.
3. 공유되는 리소스
pod 내의 컨테이너들은 볼륨을 공유할 수 있다. 공유 저장소 사용 가능.
4. 하나의 배포 단위
kubernates에서는 애플리케이션을 여러 pod에 배포한다.
즉, pod는 쿠버네티스의 최소 배포 단위로, 서비스나 애플리케이션을 실행할 때 여러 pod가 필요할 수 있다.
5. pod의 생명주기
파드의 생명주기 ≠ 파드 내 컨테이너의 생명주기
- 컨테이너 하나의 문제가 발생한다면, 그 컨테이너만 재실행하면 된다. 파드 자체를 재실행할 필요는 없다.
- 반대로 파드에 문제가 발생한다면, 파드에 포함된 모든 컨테이너가 재실행된다.
pod는 단기적인 생명주기를 가진다.
즉, pod가 종료되면 kubernates는 자동으로 해당 pod를 다시 생성하거나 새로 배치한다. 만약 Pod에 문제가 생기면 kuber는 그 상태를 감지하고 새 pod를 자동으로 생성한다.
쿠버네티스 실행 방법
쿠버네티스에서 애플리케이션 실행을 위해 개발자가 해야할 역할은 크게 두가지이다.
- 애플리케이션을 개발한다.
- 파드들을 어떻게 운영할지 쿠버네티스에게 구체적으로 알려준다.
개발자는 애플리케이션을 파드 단위로 개발하고, 이를 쿠버네티스에 실행시켜달라고 요청한다.
쿠버네티스는 개발자의 실행 요청에 따라 클러스터 내에서 안정적이고 효율적으로 파드들을 스케쥴링(해당 파드를 어떤 워커 노드에서 실행시킬지 결정) 한다. 클러스터의 개발 노드는 자신에게 할당된 파드들을 실행시킨다.
Deployment Strategies
쿠버네티스는 배포 전략을 자동으로 수행할 수 있는 기능을 제공하는 Deployment 리소스를 활용한 업데이트 방식이다.
![](https://blog.kakaocdn.net/dn/LocdN/btsL9utLO85/Wrwfh8hUA5WK7kvLVvvqd1/img.png)
1. 롤링 업데이트
롤링 업데이트는 기존 애플리케이션을 한 번에 교체하는 것이 아닌, 점진적으로 새로운 버전으로 교체하며 서비스 중단없이 배포하는 방식이다.
롤링 업데이트를 수행하려면 먼저 업데이트된 버전을 실행하는 애플리케이션의 새 인스턴스를 만든다.
![](https://blog.kakaocdn.net/dn/bu4Kpw/btsL9Ns8VQ6/lx1a726r10mL2kDXd2xMR0/img.png)
차례차례 교체하는 전략이다. 마지막 인스턴스가 업데이트된 인스턴스로 교체되면 배포가 완료되고, 애플리케이션이 예상대로 작동하는지 확인한다. 문제가 발견되면 모든 변경 사항을 롤백할 수 있다.
- 새 버전의 pod 생성 → 기존 pod 를 하나씩 제거
- kubectl apply -f deployment.yaml 실행 시 기본적으로 롤링 업데이트가 적용된다. (디폴트값)
2. Canary 배포
카나리 배포는 새 버전의 애플리케이션을 일부 사용자에게만 배포한 후, 문제가 없으면 점진적으로 전체 트래픽을 새로운 버전으로 전환하는 방식이다.
![](https://blog.kakaocdn.net/dn/HXpqI/btsL9deKtAE/kKmQbhq9BzFwN9aBddHuh0/img.png)
- 새로운 버전 A와 기존 버전 B 를 동시에 실행한다.
- 서비스의 트래픽을 일정 비율 (80,20)으로 조장한다.
- 모니터링 후 이상이 없으면 점진적으로 B의 비율을 조정한다.
쿠버네티스 In docker (kind)
쿠버네티스를 로컬에서 돌려볼 수 있는 것
![](https://blog.kakaocdn.net/dn/cUjQVd/btsL89XCnf4/fzBa6pme044aKM7JbRKkQ1/img.png)
Kind 문서: (https://kind.sigs.k8s.io/docs/user/quick-start#installing-from-release-binaries)
kubernates in docker = kuber kind
kind는 Docker 컨테이너 노드를 사용해 로컬 Kubernates 클러스터를 실행하기 위한 도구이다. kind 주로 kubernates 자체를 테스트하기 위해 설계되었지만, 로컬 개발이나 CI에 사용될 수 있다.
참고
https://computing-jhson.tistory.com/102
https://www.baeldung.com/ops/deployment-strategies
https://developer-jiing.tistory.com/48
'BACKEND' 카테고리의 다른 글
nginx 의 SSL 인증서를 옮겨오는 법..? (0) | 2025.01.29 |
---|---|
Nginx 프록시 설정 중 SSL 발급 오류 해결 (0) | 2025.01.29 |
제목: 엔지닉스에 OPTION 처리 달지말자 (0) | 2024.12.02 |