쿠버네티스란?
- 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하기 위해 사용되는 오픈 소스 시스템
주요 기능
특징 설명 컨테이너 오케스트레이션 다수의 컨테이너를 자동으로 배포, 관리, 확장하고, 이들 간의 네트워킹과 스토리지를 관리합니다. 서비스 디스커버리와 로드 밸런싱 컨테이너에 IP 주소와 단일 DNS 이름을 할당하여 서비스를 쉽게 찾을 수 있게 하며, 트래픽이 많을 때는 로드 밸런싱을 통해 부하를 분산합니다. 스케일링 애플리케이션의 필요에 따라 자동으로 또는 수동으로 스케일 업(확장) 및 스케일 다운(축소)을 수행할 수 있습니다. 자동화된 롤아웃과 롤백 애플리케이션 또는 그 구성의 변경 사항을 점진적으로 롤아웃하고, 문제가 발생하면 이전 버전으로 롤백할 수 있는 기능을 제공합니다. 자동화된 빈 패킹(Bin Packing) CPU와 메모리(RAM) 요구 사항을 기반으로 컨테이너를 노드에 자동으로 배치하여, 자원을 최적화합니다. 자체 치유(Self-Healing) 실패한 컨테이너를 자동으로 재시작하고, 정의된 사용자 상태와 맞지 않는 컨테이너를 교체하며, 준비되지 않은 컨테이너로 들어오는 트래픽을 차단합니다. 시크릿과 구성 관리 비밀번호, OAuth 토큰, SSH 키와 같은 중요한 정보를 저장하고 관리할 수 있게 해서, 컨테이너 이미지를 재빌드하거나 스택 구성에 이 정보들을 노출시키지 않고도 애플리케이션 스택과 비밀정보를 업데이트하고 배포할 수 있습니다. 보관 및 복구 볼륨을 사용하여 스토리지 시스템을 마운트할 수 있으며, 로컬 스토리지뿐만 아니라 퍼블릭 클라우드 제공자의 스토리지도 지원합니다.
컨테이너를 파일 형태로 저장한것을 이미지
쿠버네티스의 Immutable란?
Immutable Infrastructure
- Immutable 인프라스트럭처는 한 번 구축되면 변경되지 않는 인프라를 의미함, 기존의 방식에서는 서버나 인프라를 업데이트하거나 패치하는 등 변경을 가하는 방식이 일반적이었음, 하지만 Immutable 인프라스트럭처에서는 변경 대신 새로운 인프라를 구축하고 이전 인프라를 대체함
- 이 접근 방식은
예측 가능성과 신뢰성을 높이며,"작동 중인 서버"와 "생산 중인 서버" 사이에 발생할 수 있는 불일치를 제거함
Immutable Containers
- 컨테이너는 Immutable하게 취급됨. 즉, 컨테이너는 실행 중에 변경되지 않음. 변경이 필요한 경우, 새로운 컨테이너 이미지를 생성하고 이를 기반으로 새로운 컨테이너를 배포해야함
- 이 방식은 애플리케이션의 안정성과 일관성을 향싱시키며, 롤백이나 새로운 버전의 배포를 보다 쉽고 빠르게 만듦
-
컨테이너 이미지는 일반적으로 여러 개의 레이어(layer)로 구성
-
예를들어, 베이스 이미지(ubuntu), 응용 프로그램에 필요한 라이브러리나 의존성 파일(Layer A, Layer B, Layer C), 그리고 응용 프로그램의 실행 파일 또는 코드가 될 수있음
-
이미지의 각 레이어는 변경이 발생할 때마다 새롭게 필드되는데, 이러한 방식으로 이미지를 빌드하면 이미 존재하는 레이어는 재사용하고 변경된 부분만 새로운 레이어로 추가함. 이렇게 하면 변경되지 않은 부분을 다시 다운로드하거나 저장할 필요가 없으므로 저장 공간과 시간을 절약할 수 있음
예
원래 이미지(a, b, c 레이어 포함)의 크기가 1GB였다면,
새로운 레이어 d가 추가되어 이미지를 재빌드할 때,
변경되지 않은 a, b, c 레이어는 재사용되고, 새롭게 추가된 d 레이어만큼 용량이 증가하여 최종 이미지 크기가 1.2GB가 됨
- 이방식은 컨테이너의 Immutable한 특성과도 관련이 있는데, 이미지의 한 레이어가 변경될 때, 전체 이미지를 새로 만들지 않고 해당 레이어만 업데이트하여 새로운 이미지를 만듬. 따라서 이전 버전의 이미지와 새로운 버전의 이미지는 공유되는 레이어를 가질 수 있으며, 이는 효율적인 저장 공간 사용과 빠른 배포를 가능하게 함
쿠버네티스의 단점
| 단점 | 설명 |
|---|---|
업그레이드의 복잡성 | 잦은 릴리즈로 인해 대규모 시스템에서 업그레이드 관리가 복잡해질 수 있음 |
호환성 문제 | 새 버전 릴리즈 시 이전 버전과의 호환성 문제가 발생할 가능성 |
운영 비용 증가 | 시스템을 최신 상태로 유지하기 위한 시간과 자원의 증가로 운영 비용이 상승 |
문서화 및 학습 곡선 | 지속적인 업데이트로 인한 문서화 필요성과 학습 곡선의 가파름 |
안정성과 예측 가능성 | 빈번한 시스템 변경이 장기적인 안정성과 예측 가능성에 영향을 줄 수 있음 |
- 이러한 단점들에도 불구하고, 쿠버네티스는 계속해서 발전하고 있으며, 커뮤니티는 이러한 단점들을 극복하기 위한 방안들을 지속적으로 개발하고 있음. 사용자들은 자신의 운영 환경과 요구 사항에맞춰 적절한 업그레이드 전략을 세우고, 필요한 경우 롤링 업데이트나, 카나리 릴리즈와 같은 점진적인 업데이트 방법을 사용하여 위험을 최소화할 수 있음.
💡 롤링 업데이트(Rolling Update)
- 애플리케이션의 새 버전을 점진적으로 배포하는 방식
- 한 번에 하나 또는 소수의 인스턴스만 새 버전으로 업데이트하고, 그 다음에 다른 인스턴스를 순차적으로 업데이트함
- 이는 전체 시스템을 한꺼번에 업데이트하는 대신, 애플리케이션의 가용성과 서비스 중단 시간을 최소화하며 업데이트를 수행함
- 문제가 발생하면 즉시 롤백할 수 있으며, 사용자에게 미치는 영향을 최소화하는 업데이트 방법
💡 카나리 릴리즈
- 새 버전의 애플리케이션을 제한된 사용자 그룹에게 먼저 배포하여, 새 버전의 성능과 안정성을 테스트하는 방식
- 이름은
카나리아 새에서 유래한 것으로, 탄광에서 가스 유출 감지를 위해 사용된 새의 역할에 비유됨- 카나리 릴리즈는 모든 사용자에게 영향을 미치기 전에 문제를 발견하고 수정할 기회를 제공함
- 성공적으로 테스트가 완료되면, 나머지 사용자들에게 점차적으로 새 버전을 배포함
쿠버네티스 아키텍처
Node
- 노드는 클러스터의 일부로, 컨테이너화된 애플리케이션이 실제로 실행되는
물리적 또는 가상의 서버
- 워커 노드(Worker Node) : 이들은 애플리케이션 컨테이너의 실제 호스트이며, 각 워커 노드는 여러 개의
파드(Pods)를 실행할 수 있으며, 각 파드는 하나 이상의 컨테이너를 가질 수 있음- 쿠블릿(Kubelet) : 각 워커 노드에는 쿠블릿이라는 에이전트가 실행되며, 이는
쿠버네티스 마스터 노드의 API 서버와 통신하여, 해당 노드에 할당된 파드들이 적절히 실행되고 있는지 관리함- 컨테이너 런타임(Container Runtime) : 노드에는 컨티에너 런타임이 설치되어 있어야함.예를 들어, 도커(Docker)가 그 역할을 함. 이는 실제로 컨테이너를 실행하고 관리하는 역할을 함
- Kube-proxy : 이는 네트워크 프록시와 로드 밸런서의 역할을 하며, 쿠버네티스의 서비스 추상화를 실현하는 데 사용됨. Kube-proxy는 네트워크 트래픽을 적절히 포워딩하여, 컨테이너간의 통신과 외부에서의 접근을 가능하게 함
- 파드(Pods) : 쿠버테니스에서
배포의 기본 단위, 각 파드는 하나 이상의 컨테이너를 포함하며, 공유된 저장 공간(볼륨), IP 주소 등을 가짐. 파드들은 공통된 목적을 가진 컨테이너들을 그룹화하여 관리하기 위해 사용됨
👏🏻 노드들은 마스터 노드의 지휘를 받아 작동하며, 마스터 노드의 스케줄러는 새로 생성할 파드를 적절한 노드에 할당하는 작업을 담당함. 컨트롤러 매니저는 다양한 컨트롤러를 통해 클러스터의 상태를 마스 노드가 원하는 상태로 유지하는 역할을 함. etcd는 클러스터의 상태를 저장하는 분산된 키 - 값 스토어로서, 모든 클러스터 데이터를 저장하고, 클러스터를 복구하기 위한 백업과 같은 중요한 정보를 담고 있음
Service
- 서비스는 클러스터 내부 또는 외부에서 실행 중인 파드(Pods)에 대한 안정적인 접근 방법을 제공함
- 사용자/클라이언트(Users/Clients) : 이들은 서비스에 요청을 보내는 외부의 엔드 유저 또는 클라이언트 애플리케이션을 나타냄
- 외부 로드 밸런서(External Load Balancer) : 클라이언트의 요청을 받아 쿠버네티스 클러스터로 전달하는 역할을 함. 이 로드 밸런서는 클라이언트의 요청을 쿠버네티스 서비스로 균등하게 분배하여, 단일 진입점으로서의 역할을 수행함
- 쿠버네티스 서비스(Kubernetes Service) : 서비스는 클러스터 내에 정의된 리소스로, 하나 이상의 파드로 들어오는 네트워크 트래픽을 관리함. 서비스는 일련의 파드에 대한 단일 지점으로서 작동하며, 파드가 죽거나 스케일링되어도 서비스의 IP 주소와 포트는 변하지 않아서, 클라이언트 입장에서는 안정적인 접속을 보장받을 수 있음
- 파드(Pods) : 쿠버네티스에서 컨테이너를 실행하는 기본 단위. 각 파드는 하나 이상의 컨테이너로 구성될 수 있으며, 서비스에 의해 로드 밸런싱된 트래픽을 받음. 서비스는 이 파드들을 대상으로 트래픽을 분산시켜 부하를 균등하게 처리함
Namespace
- 쿠버네티스 클러스터 내의 리소스를 논리적으로 분리하여 관리하는 방법을 제공
네임스페이스를 사용하는 이유는?
- 리소스 격리(Resource Isolation) : 다른 네임스페이스의 리소스와 충돌 없이 독립적으로 리소스를 관리할 수 있게 해줌
- 환경 관리(Environment Managemnet) : 개발, 테스트, 프로덕션 등 다양한 환경을 분리하여 관리할 수 있음. 이를 통해 각 환경의 설정과 리소스 사용을 구분할 수있음
- 액세스 제어(Access Control) : 각 네임스페이스마다 다른 사용자 권한을 설정하여, 특정 팀이나 개인이 접근할 수있는 리소스를 제한할 수 있음
- 리소스 할당(Resource Allocation) : 네임스페이스별로 리소스 할당량(CPU, 메모리 등)을 설정하여, 각 환경의 리소스 사용을 제어할 수 있음
쿠버네티스 복구
카오스 엔지니어링(Chaos Engineering)?
- 시스템의 견고함과 복원력을 평가하기 위해 의도적으로 서비스 중단이나 실패를 유발하는 실험적 접근 방식. 쿠버네티스에서 복구 메커니즘은 카오스 엔지니어링의 개념을 사용하여 시스템의 무중단(Zero-Downtime)운영 체계를 설계하고 검증하는 데 사용될 수 있음
- 파드 실패 실험(Pod Failure Experiments) : 임의의 파드를 중단시켜 보고 시스템이 자동으로 복구하는지 확인. 쿠버네티스의
셀프-힐링(Self-Healing)메커니즘은 자동으로 피드를 재시작하거나 대체 파드를 생성해야 함- 네트워크 지연 실험(Network Latency Experiments) : 네트워크 지연을 일으켜 서비스 간 통신의 견고함을 테스트함. 서비스는 네트워크 문제에도 유연하게 반응해야 하며, 요청을 성공적으로 처리할 수 있어야 함
- 리소스 제약 실험(Resource Constraint Experiments) : 특정 노드나 파드에 CPU나 메모리 제약을 적용하여 시스템이 리소스 부족 상황에서 어떻게 작동하는지 관찰
무중단 체계와 복구
- 쿠버네티스는 무중단 서비스를 위한 다양한 기능을 제공함
롤링 업데이트(Rolling Updates): 애플리케이션을 업데이트할 때 파드를 점진적으로 교체하여, 서비스 중단 없이 새 버전으로의 전환을 가능하게 함.
레플리카셋(ReplicaSets)과 디플로이먼트(Deployments): 레플리카셋은 여러 개의 파드 복제본을 유지하며, 디플로이먼트는 이러한 레플리카셋을 관리하여 애플리케이션의 선언적 업데이트를 제공함.
서비스(Service) 추상화: 서비스 오브젝트는 파드 그룹에 안정적인 주소를 제공하며, 파드가 실패하거나 교체될 때도 지속적인 네트워크 액세스를 보장함.
오토스케일링(Auto-Scaling): 부하가 증가하면 자동으로 파드의 수를 늘려 부하를 처리하고, 부하가 감소하면 파드의 수를 줄여 리소스를 절약함.
🖍️ 오토스케일링(Auto-Scaling)과 스케일 아웃(Scaling out)
오토스케일링
- 클라우드 컴퓨팅 환경에서 흔히 볼 수 있으며, 쿠버네티스와 같은 오케스트레이션 시스템에서도 중요한 기능
오토스케일링의 두 가지 유형
- 수평 오토스케일링(Horizontal Auto-Scaling) : 인스턴스의 수(예: 파드의 수)를 눌리거나 줄이는 방식. 쿠버네티스에서는 Horizontal Pod Autoscaler(HPA)를 통해 구현
- 수직 오토스케일링(Vertical Auto-Scaling) : 각 인스턴스에 할당된 리소스(예: CPU, 메모리)의 양을 자동으로 조절하는 방식
스케일 아웃
- 시스템의 처리 능력을 증가시키기 위해 추가 인스턴스(예: 서버, 컨테이너, 파드)를 시스템에 추가하는 프로세스. 스케일 아웃은 수평확장(Horizontal Scaling)의 한 형태로, 리소스를 추가하여 시스템의 병렬 처리 능력을 향상시킴
차이점
- 오토스케일링 : 자동화된 프로세스를 통해 시스템이 부하에 반응하여 스스로 리소스를 조절함
- 이는 수평 또는 수직의 스케일링이 될 수 있음
- 스케일 아웃 : 오토스케일링의 한 형태로, 리소스를 수평적으로 추가하는 특정 행위를 지칭함. 수동으로 수행될 수 있고, 오토스케일링 정책의 일부로 자동으로 수행될 수 있음
즉, 스케일 아웃은 오토스케일링에 의해 자동으로 실행될 수 있는 구체적인 조치이며, 오트스케일링은 그러한 조치를 자동으로 실행할 수 있는 전체적인 메커니즘을 말함
내가 이해한 쿠버네티스
웹 애플리케이션,서버,DB,대용량 파일 저장소,젠킨스,도커가 어떻게 구성되고 운영될까?
쿠버네티스 클러스터 내의 파드 구성
Worker node
- 웹 애플리케이션(Front, Pod1) : 사용자 인터페이스(UI)를 제공하는 프론트엔드 애플리케이션이 포함된 파드로 웹서버(Nginx, Apache)를 통해 정적 파일을 제공하고, 사용자의 요청을 백엔드 서버(Pod2)로 전달함
- 서버(Backend, Pod2) : 클라이언트의 HTTP 요청을 처리하고 비즈니스 로직을 실행하는 백엔드 서버가 포함된 파드로 DB(Pod3)와 통신하여 데이터를 처리하고, 필요한 정보를 프론트엔드로 전달함
- DB(Pod3) : 데이터를 저장하고 관리하는 DB 서비스가 포함된 파드로 백엔드 서버(Pod2)는 필요한 데이터를 조회하거나 저장하기 위해 이 DB와 통신함
- 대용량 파일 저장소(Pod4) : 대용량 데이터 저장 및 관리를 위한 스토리지 서비스가 포함된 파드로 필요에 따라 백엔드 서버(Pod2)에서 접근할 수 있음
젠킨스와 도커
- 젠킨스(Jenkins, Pod5) : CI/CD 파이프라인을 관리하며, 코드 변경에 대응하여 백엔드 서버(및 필요한 경우 프론트엔드)의 빌드, 테스트, 배포를 자동화하는 도구가 포함된 파드
- 도커(Docker) : 백엔드 서버 및 프론트엔드 애플리케이션의 컨테이너 이미지를 생성함. 이 이미지들은 쿠버네티스 클러스터 내에서 각각의 서비스를 실행하는 파드로 배포
연결 및 상호 작용
- 프론트엔드와 백엔드는 서로 통신하여 사용자 요청을 처리하고 데이터를 주고받음
- 백엔드 서버는 DB와 통신을 담당하며, 대용량 파일 저장소에 접근할 수 있음
- 젠킨스는 소스 코드의 변경을 감지하여 프론트엔드와 백엔드의 새로운 버전을 빌드, 테스트, 배포함
쿠버네티스 활용 사례
수강신청 쿠버네티스 활용
- 수강신청과 시스템에 쿠버네티스를 활용하면 시스템의 성능과 안정성을 크게 향상시킬 수 있음
- 자동 스케일링 : 쿠버네티스는 트래픽의 변화에 따라 자동으로 애플리케이션을 스케일 업하거나 스케일 다운함. 수강신청 시 발생하는 트래픽 피크 시 자동으로 리소스를 추가하여 과부하를 방지하고, 피크가 끝나면 리소스를 줄여 비용을 절감할 수 있음
- 로드 밸런싱 : 쿠버네티스의 로드 밸런싱 기능은 트래픽을 여러 서버 또는 파드에 균일하게 분산시켜 모든 사용자에게 안정적인 서비스를 제공함. 이는 서버 한 곳에 트래픽이 집중되어 발생할 수 있는 장애를 방지함
- 자가 치유 : 쿠버네티스는 시스템의 안정성을 유지하기 위해 실패한 컨테이너를 자동으로 재시작하고, 문제가 있는 파드를 교체함. 이는 서비스 중단을 최소화하고 신혹한 복구를 가능하게 함
- 클라우드 통합 : 쿠버네티스는 다양한 클라우드 환경과의 통합을 지원함. 이를 통해 필요에 따라 추가적인 컴퓨팅 리소스를 확보할 수 있으며, 클라우드의 유연성과 확장성을 활용할 수 있음
종합적으로, 쿠버네티스는 수강신청 시스템의 효율성을 높이고, 피크 시간 동안의 트래픽 관리를 개선하며, 전체적인 시스템 안정성을 강화할 수 있음. 이는 학생들에게 원활한 수강신청 경험을 제공하고, 시스템 관리자에게는 더 나은 리소스 관리와 유지 보수의 용이성을 제공
HW + SW = 1