Mac에서 LitmusChaos 설치하기
by rowing0328Intro
이번 글에서는 Mac 환경에서 LitmusChaos를 설치하는 과정을 정리해보려고 한다.
LitmusChaos는 Kubernetes 환경에서 카오스 엔지니어링을 실습할 수 있도록 도와주는 오픈소스 플랫폼이다.
처음에는 단순히 장애를 일부러 발생시키는 도구 정도로 생각했지만,
조금 더 살펴보니 시스템이 장애 상황에서 어떻게 버티는지 확인하기 위한 실험 도구에 가깝다는 생각이 들었다.
운영 환경에서 장애가 발생하면 이미 늦을 수 있다.
그래서 통제된 환경에서 먼저 장애를 만들어보고,
시스템이 예상한 방식으로 복구되는지 확인하는 과정이 필요하다.
이번 글에서는 MacBook Apple Silicon 환경에서
Minikube 클러스터를 실행하고,
그 위에 Litmus ChaosCenter를 설치한 뒤,
웹 UI에 접속하는 과정까지 정리한다.
실제 카오스 실험은 이후 과정에서 다루고,
이번 글에서는 LitmusChaos를 실행할 수 있는 기본 환경을 만드는 것에 집중한다.
실습 환경
이번 설치는 아래 환경에서 진행했다.
| 항목 | 값 |
| OS | macOS |
| CPU | Apple Silicon M4 |
| Memory | 16GB |
| Disk | 256GB |
| Kubernetes 환경 | Minikube |
| 설치 방식 | Helm |
LitmusChaos는 Kubernetes 위에서 동작하기 때문에,
먼저 로컬에서 Kubernetes 클러스터를 실행할 수 있어야 한다.
이번 글에서는 Minikube를 사용한다.
Minikube는 내 컴퓨터 안에 작은 Kubernetes 클러스터를 만들어주는 도구라고 볼 수 있다.
실제 서버를 준비하지 않아도 로컬에서 Kubernetes 클러스터를 만들어주는 도구라고 볼 수 있다.
Pod와 Service 상태를 확인하면서 실습할 수 있다.
LitmusChaos란
LitmusChaos는 Kubernetes 환경에서 카오스 엔지니어링을 수행할 수 있도록 도와주는 도구이다.
카오스 엔지니어링은 시스템의 약점을 찾기 위해 의도적으로 장애를 주입하는 실험 방법이다.
예를 들어 Pod를 강제로 삭제하거나,
네트워크 지연을 만들거나,
특정 리소스에 부하를 주면서 시스템이 어떻게 반응하는지 확인할 수 있다.
업무로 비유하면 장애 대응 훈련과 비슷하다.
실제 사고가 발생한 뒤에야 대응 절차를 확인하는 것이 아니라,
미리 정해진 상황을 만들어보고 담당자와 시스템이 예상대로 움직이는지 확인하는 과정이다.
LitmusChaos도 비슷하다.
운영 환경에서 갑자기 장애가 발생하기 전에,
테스트 가능한 환경에서 먼저 장애 상황을 만들어보고 시스템의 회복력을 확인한다.
LitmusChaos 구성 요소
LitmusChaos는 여러 컴포넌트로 구성되어 있다.
| 구성 요소 | 설명 |
| ChaosCenter | 카오스 실험을 구성하고 확인할 수 있는 웹 UI |
| Chaos Infrastructure | 실제 카오스 실험을 실행하는 영역 |
| ChaosHub | 다양한 카오스 실험 템플릿 모음 |
| Resilience Probe | 실험 후 시스템 상태를 검증하는 도구 |
이번 글에서는 이 중에서 ChaosCenter 설치와 접속까지만 진행한다.
즉, 전체 카오스 실험을 바로 실행하는 것이 아니라,
LitmusChaos를 사용할 수 있는 기본 Control Plane을 준비하는 단계라고 보면 된다.
전체 흐름
이번 글에서 진행할 흐름은 아래와 같다.
사전 준비물 설치
-> Minikube 클러스터 시작
-> Litmus ChaosCenter 설치
-> ChaosCenter 웹 UI 접속
전체 구조를 단순하게 보면,
로컬 Minikube 클러스터 안에 Litmus 관련 리소스들이 생성되고,
사용자는 브라우저를 통해 ChaosCenter에 접속하는 방식이다.
캡처 영역
이번 글에서는 Chaos Infrastructure나 실제 실험 대상 애플리케이션까지는 다루지 않는다.
먼저 ChaosCenter가 정상적으로 설치되고,
웹 UI에 접속할 수 있는 상태를 만드는 것이 목표이다.
사전 준비물
설치를 진행하기 전에 아래 도구들이 필요하다.
- Docker Desktop
- Minikube
- kubectl
- Helm 3
Docker Desktop은 Minikube가 컨테이너 기반으로 Kubernetes 클러스터를 실행하기 위해 필요하다.
따라서 설치만 되어 있는 것이 아니라 실행 중인 상태여야 한다.
Minikube 설치
brew install minikube
minikube version
kubectl 설치
brew install kubectl
kubectl version --client
Helm 설치
brew install helm
helm version --short
각 명령어를 실행했을 때 버전 정보가 출력되면 기본 준비는 완료된 것이다.
Minikube 클러스터 시작
LitmusChaos를 설치하려면 Kubernetes 클러스터가 필요하다.
이번 글에서는 Minikube 프로필을 따로 만들어 기존 Minikube 환경과 분리했다.
minikube start --profile=litmus-tutorial --cpus=4 --memory=7168 --driver=docker

옵션의 의미는 아래와 같다.
| 옵션 | 설명 |
| `--profile=litmus-tutorial` | 기존 Minikube 환경과 분리된 프로필을 생성 |
| `--cpus=4` | CPU 4개 할당 |
| `--memory=7168` | 메모리 약 7GB 할당 |
| `--driver=docker` | Docker를 드라이버로 사용 |
처음에는 메모리를 `8192`로 지정할 수도 있다고 생각했지만,
Docker Desktop에 할당된 메모리보다 큰 값을 지정하면 에러가 발생할 수 있다.
그래서 이번 환경에서는 `7168`로 설정했다.
클러스터 상태 확인
클러스터가 정상적으로 실행되었는지 확인한다.
minikube status --profile=litmus-tutorial
정상적으로 실행되면 아래와 비슷한 결과를 확인할 수 있다.

Node 상태도 확인한다.
kubectl get nodes

여기서 중요한 것은 ==`STATUS`가 `Ready`인지 확인하는 것이다.
`Ready` 상태라면 Kubernetes 클러스터가 정상적으로 준비된 것이다.
Litmus Helm 저장소 추가
Kubernetes 클러스터가 준비되었으니 이제 LitmusChaos를 설치한다.
LitmusChaos는 여러 컴포넌트로 구성되어 있기 때문에,
직접 YAML을 하나씩 작성해서 설치하기보다는 Helm Chart를 사용하는 것이 편하다.
먼저 LitmusChaos Helm 저장소를 추가한다.
helm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/
helm repo update
정상적으로 추가되면 저장소가 등록되고 업데이트가 완료된다.


Namespace 생성
LitmusChaos 관련 리소스를 분리하기 위해 전용 Namespace를 만든다.
kubectl create ns litmus

Namespace는 Kubernetes 클러스터 안에서 리소스를 논리적으로 나누는 공간이다.
업무에서 프로젝트별로 폴더를 나누는 것처럼,
Kubernetes에서도 목적에 따라 Namespace를 나누면 리소스를 관리하기 쉬워진다.
Litmus ChaosCenter 설치
이제 Helm을 사용해서 Litmus ChaosCenter를 설치한다.
helm install chaos litmuschaos/litmus --namespace=litmus \
--set portal.frontend.service.type=NodePort \
--set mongodb.image.registry=docker.io \
--set mongodb.image.repository=bitnami/mongodb \
--set mongodb.image.tag=latest \
--set mongodb.auth.enabled=true \
--set-string mongodb.auth.rootPassword=litmus1234

여기서 몇 가지 옵션을 지정했다.
`portal.frontend.service.type=NodePort`는 로컬 환경에서 ChaosCenter 웹 UI에 접근하기 위한 설정이다.
또한 Apple Silicon 환경에서는 기본 MongoDB 이미지가 ARM에서 문제가 될 수 있어,
Bitnami MongoDB 이미지를 사용하도록 지정했다.
그리고 비밀번호 설정에는 `--set-string`을 사용했다.
숫자만 포함된 값을 `--set`으로 넘기면 Helm이 문자열이 아니라 정수로 해석할 수 있다.
이번에는 `litmus1234`를 사용했지만,
비슷한 문제를 피하려면 문자열로 명확히 전달하는 것이 안전하다.
Pod 상태 확인
설치 후에는 Litmus 관련 Pod들이 정상적으로 실행되는지 확인한다.
kubectl get pods -n litmus

처음에는 이미지 다운로드와 초기화 때문에 `ContainerCreating` 상태가 보일 수 있다.
조금 기다린 뒤 다시 확인하면 `Running` 상태로 변경된다.
MongoDB는 ReplicaSet으로 구성되기 때문에 여러 Pod가 생성된다.
처음에는 생각보다 Pod가 많이 보여서 헷갈릴 수 있지만,
모두 `Running` 상태라면 정상적으로 설치된 것이다.
Service 상태 확인
ChaosCenter에 접속하려면 Service도 확인해야 한다.
kubectl get svc -n litmus

여기서 확인해야 할 것은 `chaos-litmus-frontend-service`의 타입이다.
`NodePort`로 설정되어 있어야 Minikube 환경에서 브라우저를 통해 ChaosCenter에 접근할 수 있다.
ChaosCenter 접속
이제 ChaosCenter 웹 UI에 접속한다.
minikube service chaos-litmus-frontend-service -n litmus --profile=litmus-tutorial

이 명령어를 실행하면 브라우저가 자동으로 열리고,
ChaosCenter 로그인 화면으로 이동한다.
주의할 점은 이 명령어가 실행된 터미널은 계속 점유된 상태로 남는다는 것이다.
다른 명령어를 실행하려면 새 터미널 탭을 열어야 한다.

기본 로그인 정보는 아래와 같다.
| 항목 | 값 |
| Username | `admin` |
| Password | `litmus` |
첫 로그인 시 비밀번호 변경을 요구할 수 있다.
이 경우 새 비밀번호를 설정하고 기억해 두면 된다.
ChaosCenter 대시보드가 보이면 설치가 정상적으로 완료된 것이다.
트러블슈팅
설치 과정에서 몇 가지 문제가 발생할 수 있다.
이번에는 로컬 환경에서 설치하는 과정이기 때문에,
대부분 Docker Desktop 상태나 리소스 설정과 관련된 문제가 많다.
Docker Desktop이 실행 중이 아닐 때
아래와 같은 에러가 발생할 수 있다.
Cannot connect to the Docker daemon at unix:///...docker.sock. Is the docker daemon running?
이 경우 Docker Desktop이 실행 중인지 확인해야 한다.
상단 메뉴바에 Docker 아이콘이 표시되고,
`docker info` 명령어가 정상적으로 실행되면 준비된 상태이다.
Pod가 Pending 상태에서 멈출 때
Pod가 `Pending` 상태에서 멈춘다면 리소스 부족이나 Volume 관련 문제일 수 있다.
kubectl describe pod <pod-이름> -n litmus
`Events` 항목을 보면 어떤 이유로 Pod가 실행되지 못하는지 확인할 수 있다.
리소스가 부족하다면 Minikube를 삭제하고 더 적절한 리소스로 다시 시작한다.
minikube delete --profile=litmus-tutorial
minikube start --profile=litmus-tutorial --cpus=4 --memory=7168 --driver=docker
Helm 설치 중 타입 에러가 발생할 때
비밀번호를 숫자만 포함해서 넘기면 Helm이 문자열이 아니라 정수로 해석할 수 있다.
Invalid type. Expected: string, given: integer
이 경우 `--set-string`을 사용한다.
--set-string mongodb.auth.rootPassword=litmus1234
이미 설치된 릴리즈가 있을 때
같은 이름의 Helm 릴리즈가 이미 설치되어 있으면 재설치가 실패할 수 있다.
helm list -n litmus
helm uninstall chaos -n litmus
기존 릴리즈를 제거한 뒤 다시 설치하면 된다.
마무리
이번 글에서는 Mac 환경에서 Minikube를 실행하고,
그 위에 LitmusChaos ChaosCenter를 설치한 뒤 웹 UI에 접속하는 과정까지 정리해 보았다.
처음에는 LitmusChaos를 단순히 카오스 실험을 실행하는 도구로만 생각했지만,
설치 과정을 따라가다 보니 Kubernetes 위에서 여러 컴포넌트가 함께 동작하는 구조라는 점이 더 눈에 들어왔다.
특히 ChaosCenter, MongoDB, Service, Namespace 같은 리소스를 직접 확인하면서,
카오스 엔지니어링도 결국 Kubernetes 리소스의 흐름을 이해하는 것에서 시작된다는 생각이 들었다.
이번 글에서는 기본 설치까지만 진행했지만,
다음 단계에서는 실제 애플리케이션을 대상으로 카오스 실험을 구성하고,
장애 상황에서 시스템이 어떻게 반응하는지 확인해 볼 수 있을 것 같다.
참고 자료:
ChaosCenter installation | Litmus Docs
---
docs.litmuschaos.io
GitHub - litmuschaos/litmus-helm: Helm Charts for the Litmus Chaos Operator & CRDs
Helm Charts for the Litmus Chaos Operator & CRDs . Contribute to litmuschaos/litmus-helm development by creating an account on GitHub.
github.com
LitmusChaos-Korea-Mentorship/2week-litmus
2week-litmus/02-litmus-installation.md at main · LitmusChaos-Korea-Mentorship/2week-litmus
Contribute to LitmusChaos-Korea-Mentorship/2week-litmus development by creating an account on GitHub.
github.com
CNCF Blog - LitmusChaos and Backstage Integration
Elevating System Resilience: Leveraging LitmusChaos and Backstage Integration
This blog post provides step-by-step instructions for injecting chaos using LitmusChaos and managing...
dev.to
'📌ETC > Development Log' 카테고리의 다른 글
| MinIO 자동화 운영을 위한 환경설정과 윈도우 배치 파일 작성 (3) | 2025.07.28 |
|---|---|
| MinIO로 버킷 관리부터 이벤트 자동화까지 (3) | 2025.07.10 |
| Jenkins Pipeline와 DooD를 결합한 CI&CD 환경 구성하기 (0) | 2025.02.21 |
| SonarQube와 JaCoCo로 테스트 커버리지 측정하기 (0) | 2025.01.29 |
| SonarQube와 GitHub Actions로 정적 코드 품질 관리하기 (0) | 2025.01.21 |
블로그의 정보
코드의 여백
rowing0328