chaostoolkit/chaostoolkit-kubernetesChaos Toolkit 프로브 및 액션 API를 위한 Kubernetes 드라이버 확장
이 프로젝트는 실험에서 Chaos Toolkit을 통해 호출할 수 있는 probe 및 action과 같은 활동들을 포함하며, Kubernetes API에 대해 Chaos Engineering을 수행할 수 있게 해줍니다: 파드 죽이기, statefulset 또는 노드 제거 등.
실험에서 사용하려면 이 패키지는 이미 chaostoolkit이 설치되어 있는 Python 환경에 설치되어 있어야 합니다.
$ pip install chaostoolkit-kubernetes
이 패키지의 probe와 action을 사용하려면 실험 파일에 다음을 추가하세요:
{
"title": "Do we remain available in face of pod going down?",
"description": "We expect Kubernetes to handle the situation gracefully when a pod goes down",
"tags": ["kubernetes"],
"steady-state-hypothesis": {
"title": "Verifying service remains healthy",
"probes": [
{
"name": "all-our-microservices-should-be-healthy",
"type": "probe",
"tolerance": true,
"provider": {
"type": "python",
"module": "chaosk8s.probes",
"func": "microservice_available_and_healthy",
"arguments": {
"name": "myapp"
}
}
}
]
},
"method": [
{
"type": "action",
"name": "terminate-db-pod",
"provider": {
"type": "python",
"module": "chaosk8s.pod.actions",
"func": "terminate_pods",
"arguments": {
"label_selector": "app=my-app",
"name_pattern": "my-app-[0-9]$",
"rand": true
}
},
"pauses": {
"after": 5
}
}
]
}
그게 전부입니다! action이 파드 하나를 무작위로 죽이는 방법을 제공한다는 점에 주목하세요.
기존 probe와 action을 살펴보려면 문서를 탐색해 보세요.
네트워크, CPU, 메모리 스트레서의 경우 훌륭한 인터페이스를 제공하는 멋진 Chaos Mesh 프로젝트에 의존합니다.
이러한 장애를 사용하려면 먼저 클러스터에 Chaos Mesh를 설치해야 합니다.
대상 클러스터에 대한 유효한 항목이 ~/.kube/config 파일에 있다면 추가로 할 일은 없습니다.
다른 위치를 지정하려면 KUBECONFIG를 설정할 수 있습니다.
$ export KUBECONFIG=/tmp/my-config
Kubernetes 구성에 여러 항목이 포함되어 있는 경우가 많으며, 명시적으로 제공되지 않았을 때 기본 컨텍스트로 사용할 항목을 정의해야 합니다.
물론 kubectl config use-context KUBERNETES_CONTEXT를 사용하여 기본값을 변경할 수 있지만, 실험에서 다음과 같이 명시적으로 지정할 수도 있습니다:
{
"title": "Do we remain available in face of pod going down?",
"description": "We expect Kubernetes to handle the situation gracefully when a pod goes down",
"tags": ["kubernetes"],
"secrets": {
"k8s": {
"KUBERNETES_CONTEXT": "..."
}
},
"steady-state-hypothesis": {
"title": "Verifying service remains healthy",
"probes": [
{
"name": "all-our-microservices-should-be-healthy",
"type": "probe",
"tolerance": true,
"secrets": ["k8s"],
"provider": {
"type": "python",
"module": "chaosk8s.probes",
"func": "microservice_available_and_healthy",
"arguments": {
"name": "myapp"
}
}
}
]
},
"method": [
{
"type": "action",
"name": "terminate-db-pod",
"secrets": ["k8s"],
"provider": {
"type": "python",
"module": "chaosk8s.pod.actions",
"func": "terminate_pods",
"arguments": {
"label_selector": "app=my-app",
"name_pattern": "my-app-[0-9]$",
"rand": true
}
},
"pauses": {
"after": 5
}
}
]
}
실험에서 사용할 컨텍스트 이름으로 KUBERNETES_CONTEXT 시크릿 키를 지정해야 합니다. 또한 action과 probe에 전달할 시크릿 항목을 "secrets": ["k8s"]로 반드시 알려주세요.
파드에서 실행할 때(예: 로컬 머신이나 CI가 아닌 경우) ./.kube/config 파일은 존재하지 않습니다. 대신 자격 증명은 /var/run/secrets/kubernetes.io/serviceaccount/token에서 찾을 수 있습니다.
확장 프로그램이 이를 인식하도록 하려면 파드 스펙의 환경 변수에 CHAOSTOOLKIT_IN_POD를 설정하기만 하면 됩니다:
env:
- name: CHAOSTOOLKIT_IN_POD
value: "true"
이 환경 변수를 사용하면 실험이 실행 중인 클러스터와 동일한 클러스터를 대상으로 한다고 가정합니다. 실험이 다른 클러스터를 대상으로 한다면 이 변수를 설정하지 않아야 합니다. 대신 대상 클러스터의 Kubernetes 구성이 포함된 볼륨을 마운트하고 KUBECONFIG가 이를 가리키도록 설정할 수 있습니다.
마지막으로, 필요한 모든 자격 증명 정보를 다음과 같이 실험에 명시적으로 전달할 수 있습니다:
{
"secrets": {
"kubernetes": {
"KUBERNETES_HOST": "http://somehost",
"KUBERNETES_API_KEY": {
"type": "env",
"key": "SOME_ENV_VAR"
}
}
}
}
{
"secrets": {
"kubernetes": {
"KUBERNETES_HOST": "http://somehost",
"KUBERNETES_USERNAME": {
"type": "env",
"key": "SOME_ENV_VAR"
},
"KUBERNETES_PASSWORD": {
"type": "env",
"key": "SOME_ENV_VAR"
}
}
}
}
{
"secrets": {
"kubernetes": {
"KUBERNETES_HOST": "http://somehost",
"KUBERNETES_CERT_FILE": {
"type": "env",
"key": "SOME_ENV_VAR"
},
"KUBERNETES_KEY_FILE": {
"type": "env",
"key": "SOME_ENV_VAR"
}
}
}
}
일부 관리형 Kubernetes 클러스터에서는 Kubernetes 인증이 플랫폼에 위임되므로 플랫폼 자체에 대해서도 인증해야 합니다.
Kubernetes 자격 증명(~/.kube/config 파일) 외에도 Google Cloud Platform 자체에 인증해야 합니다. 일반적으로 이는 gcloud를 통해 수행됩니다:
$ gcloud auth login
그러나 GOOGLE_APPLICATION_CREDENTIALS 환경 변수를 정의하여 수행할 수도 있습니다.
이 패키지에 더 많은 기능을 기여하고 싶다면 언제든 환영합니다. 이 프로젝트를 포크하고, 제안된 변경 사항을 다루는 단위 테스트를 작성하고, 변경 사항을 구현하고, 형식 표준을 충족하는지 확인한 다음 검토를 위해 저장소에 PR을 올려주세요.
형식 표준에 대한 자세한 내용은 형식 지정 섹션을 참조하세요.
Chaos Toolkit 프로젝트는 모든 기여자가 저장소의 master 브랜치에 병합하려는 각 커밋에 개발자 원천 증명서(DCO)에 서명해야 합니다. PR을 제출하기 전에 DCO 규칙을 준수할 수 있는지 확인하세요.
이 프로젝트에서 개발하려면 개발 의존성을 설치해야 합니다. 먼저 PDM을 설치한 다음 의존성을 설치하세요.
$ pdm install
이제 파일을 편집할 수 있으며, 로컬에서 chaos 명령으로 실행할 때도 변경 사항이 환경에 자동으로 반영됩니다.
프로젝트의 테스트를 실행하려면 다음을 실행하세요:
$ pdm run tests
이 저장소의 코드를 린트하고 형식화하기 위해 ruff를 사용합니다.
Pull Request를 올리기 전에 코드에 대해 형식 지정을 실행할 것을 권장합니다:
$ pdm run format
이렇게 하면 형식 표준을 준수하지 않는 모든 코드가 자동으로 형식화됩니다.
형식 지정으로 처리되지 않는 일부 사항이 있으므로 다음도 실행할 것을 권장합니다:
$ pdm run lint
사용되지 않는 import 문이나 너무 긴 문자열 등도 함께 확인할 수 있습니다.