chaostoolkit/chaostoolkit-kubernetesРасширение драйвера Kubernetes для API проверок и действий Chaos Toolkit
Этот проект содержит активности, такие как пробы (probes) и действия (actions), которые вы можете вызывать из своего эксперимента через Chaos Toolkit для проведения Chaos Engineering против API Kubernetes: уничтожение пода, удаление statefulset или узла...
Чтобы использовать этот пакет в своих экспериментах, он должен быть установлен в Python-окружении, где уже находится chaostoolkit.
$ pip install chaostoolkit-kubernetes
Чтобы использовать пробы и действия из этого пакета, добавьте следующее в файл вашего эксперимента:
{
"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
}
}
]
}
Вот и всё! Обратите внимание, как действие даёт вам возможность случайным образом убить один под.
Пожалуйста, изучите документацию, чтобы узнать о существующих пробах и действиях.
Обратите внимание, что для стрессоров сети, 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 с именем контекста, который вы хотите использовать в эксперименте. Убедитесь, что вы также передаёте действиям и пробам записи секретов, которые им нужны: "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. Обычно это делается через:
$ gcloud auth login
Но это также можно сделать, определив переменную окружения GOOGLE_APPLICATION_CREDENTIALS.
Если вы хотите добавить больше функций в этот пакет, мы будем рады. Пожалуйста, сделайте форк этого проекта, напишите модульные тесты для предлагаемых изменений, реализуйте изменения, убедитесь, что они соответствуют стандартам форматирования, и затем отправьте PR в репозиторий на рассмотрение.
Пожалуйста, обратитесь к разделу форматирование для получения дополнительной информации о стандартах форматирования.
Проекты Chaos Toolkit требуют, чтобы все участники подписывали Developer Certificate of Origin для каждого коммита, который они хотели бы объединить в ветку master репозитория. Пожалуйста, убедитесь, что вы можете соблюдать правила DCO перед отправкой PR.
Если вы хотите разрабатывать этот проект, убедитесь, что установили зависимости для разработки. Но сначала установите PDM, а затем установите зависимости.
$ pdm install
Теперь вы можете редактировать файлы, и они будут автоматически подхватываться вашим окружением, даже при локальном запуске из команды chaos.
Чтобы запустить тесты проекта, выполните следующее:
$ pdm run tests
Мы используем ruff как для линтинга, так и для форматирования кода этого репозитория.
Перед отправкой Pull Request мы рекомендуем выполнить форматирование вашего кода с помощью:
$ pdm run format
Это автоматически отформатирует любой код, который не соответствует стандартам форматирования.
Поскольку некоторые вещи не обрабатываются форматированием, мы также рекомендуем выполнить:
$ pdm run lint
Это позволит выявить неиспользуемые операторы импорта, слишком длинные строки и т.д.