Всем привет! На связи Евгений Торин, DevOps-инженер компании «Флант». Я давно хотел попробовать в деле искусственный интеллект и даже в качестве эксперимента генерировал картинки для своих презентаций. Но полноценно погрузиться в эту область удалось, лишь когда появилась практическая необходимость.
Однажды меня попросили онбордить новичков в работе с Kubernetes — научить их решать возникающие проблемы. У нас есть рабочий процесс онбординга и даже собственный обучающий курс, но мне хотелось внедрить новый инструмент, который помогал бы решать эту задачу. Сейчас особую популярность набирают AI и LLM (Large Language Models, большая языковая модель), которые я и решил использовать для решения задач онбординга. То есть решил переложить эту работу на машины.
Одним из новых инструментов в области AI, которые связаны с работой Kubernetes, является k8sgpt — чат-бот, который появился весной 2023 года. Он помогает получать информацию, советы и решения по различным вопросам, связанным с Kubernetes. Для сравнения можно найти похожие утилиты в статье про инструменты с открытым исходным кодом на основе OpenAI для Kubernetes.
В этой статье я расскажу, что за утилита k8sgpt, как её поставить, какие есть полезные опции и как подключить к ней AI. Я покажу, какого уровня диагностику можно провести с помощью этого инструмента и на какие ответы чат-бота можно рассчитывать.
Для этого я попробовал в действии разные доступные интеграции с AI, несколько моделей, в том числе и локальную. Всё с примерами, командами запуска и подробными логами.
k8sgpt используется для сканирования кластеров Kubernetes, диагностики проблем и поиска вариантов их устранения. В его основе — богатый опыт SRE (Site Reliability Engineering). Опираясь на него, k8sgpt извлекает наиболее релевантную информацию и дополняет её с помощью искусственного интеллекта.
Например, в кластере появился под со статусом Pending. И если на ум не приходят причины этой проблемы, можно запустить утилиту k8sgpt и получить разъяснение, список возможных проблем и, возможно, даже команды для дальнейшей диагностики.
Так k8sgpt помогает дебажить проблемы в «кубе». А ещё утилита добавляет в чат к стандартному запросу формат общения и контекст проблемы. Конечно, запрос в чат можно составить и самостоятельно, но k8sgpt упрощает и ускоряет этот процесс.
Если не хочется устанавливать утилиту, с её работой можно начать знакомиться в песочнице. Если же есть желание полноценно разобраться с инструментом, его нужно установить. Существуют два основных варианта установки:
В качестве простой консольной утилиты — при её вызове мы получаем ответ.
В качестве оператора K8s в кластере — утилита работает в фоне и складывает результаты в отдельный CR (Custom Resource) типа Result. Это вариант подойдёт, когда нужна история проверок, а также когда нужно автоматизировать проверку проблемы, которую нельзя застать при ручном подходе — при работе с консольной утилитой.
В этой статье я разберу только первый вариант установки. Вариант с оператором можно найти в этой статье.
1. Устанавливаю утилиту на мастере k8s-кластера:
curl -LO https://github.com/k8sgpt-ai/k8sgpt/releases/download/v0.3.40/k8sgpt_amd64.deb
dpkg -i k8sgpt_amd64.deb
2. Регистрирую интеграцию с AI (далее бэкенд или просто бэк). Сейчас утилита поддерживает несколько вариантов бэков, из основных это:
внешние: OpenAI, Azure OpenAI, Cohere, Google Gemini, HuggingFace и др.;
Полный список можно посмотреть на сайте.
Примечание
Noopai — фейковый AI. Это заглушка на случай тестирования утилиты. Отвечает так:
I am a noop response to the prompt ...
Вместо многоточия подставляется текст ошибок, результат работы модуля analyze, о нём подробнее будет чуть ниже.
Выполняю регистрацию на первом по очереди рабочем бэке — от OpenAI. API-ключ можно получить по ссылке. В команде регистрации бэка нужно указать собственно имя бэка openai
и имя модели, например gpt-3.5-turbo
:
k8sgpt auth add -b openai -m gpt-3.5-turbo
Enter openai Key:
Далее предполагается, что конфиг ~/.kube/config
уже есть и API кластера доступен, после чего утилита готова к работе.
Подробнее об установке и первом запуске можно почитать в официальной документации.
Прежде чем разбирать работу утилиты, рассмотрим её основные функции. Ниже можно увидеть одни из главных команд:
Доступные команды:
analyze Команда поможет найти проблемы в кластере Kubernetes
cache Для работы с кэшем результатов анализа
filters Настраивайте фильтры для анализа ресурсов Kubernetes
e, explain Команда для обращения к AI для решения проблемы
Допустим, такой командой я попрошу утилиту рассказать, что происходит в кластере:
k8sgpt analyze -b openai --explain --no-cache --namespace=dev --filter Pod
analyze
(анализатор) собирает данные о проблемах в кластере.
С помощью опции explain
происходит обращение к бэку AI. Без неё утилита не будет использовать AI, а запустит внутренний анализатор — по сути сборник SRE-практик по дебагу определённой проблемы, где по статусу ресурса определяется перечень дальнейших диагностических действий.
Опция --no-cache
добавлена, чтоб не учитывать результат предыдущего анализа из кэша.
Фильтр --namespace=dev -f Pod
анализирует проблемы в определённом неймспейсе по ресурсам типа Pod.
Например, в запросе ниже я не использовал AI, но в ответе утилита дала структурированную информацию по найденным проблемам, по которой можно догадаться о причинах возникновения ошибок:
# k8sgpt analyse --namespace=dev
AI Provider: AI not used; --explain not set
0 dev/web-0(StatefulSet/web)
- Error: 0/2 nodes are available: 1 node(s) didn't match Pod's node affinity/selector,1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate.
...
А если использовать в команде опцию -d
, утилита добавит к каждой ошибке описание из документации в секции Kubernetes Doc:
# k8sgpt analyze --namespace=dev --filter Service -d
AI Provider: AI not used; --explain not set
0 dev/web-0(web-0)
- Error: Service has no endpoints, expected label app.kubernetes.io/name=local-ai
Kubernetes Doc: Route service traffic to pods with label keys and values matching this selector. If empty or not present, the service is assumed to have an external process managing its endpoints, which Kubernetes will not modify. Only applies to types ClusterIP, NodePort, and LoadBalancer. Ignored if type is ExternalName. More info: https://kubernetes.io/docs/concepts/services-networking/service/
В итоге даже без подключения бэка с AI утилита может быть полезна. Опция же explain
отправляет найденные ошибки в указанный бэк для поиска решения. Дальше в статье я буду всегда использовать опцию explain
и сравнивать суммарный ответ — результат работы модуля анализатора для конкретного ресурса и ответа определённого бэк-сервера с работающей в нём моделью.
Благодаря встроенному анализатору сокращается количество ложных и выдуманных теорий, которые бы предложил на месте анализатора AI.
Снижение количества запросов
Утилита поддерживает два типа управления количеством запросов, это фильтры через опцию --filter
по типам ресурсов и --max-concurrency
— количество запросов, отправляемых в «куб», где цифра указывает на количество отправленных в API параллельных запросов:
-m, --max-concurrency int Maximum number of concurrent requests to the Kubernetes API server (default 10)
Эта опция поможет не создавать избыточную нагрузку, если, например, требуется проанализировать ресурсы всего кластера или неймспейса сразу.
А для снижения количества запросов к AI бэка (например, на доступ к API openai
существуют rate-limits и может появится ошибка 429 — Too Many Requests) помогут только фильтры.
Русский язык
Большинство моделей обучались преимущественно на англоязычных текстах, при этом k8sgpt работает и на русском языке, но только в качестве перевода. Для этого при проверке проблемы нужно добавить опцию --language ”russian”
. Но она работает только в режиме обращения к внешнему бэку, то есть с опцией --explain
.
Интерактивный режим
У k8sgpt есть возможность уточнить свой вопрос, спросить про синтаксис команд и прочее — интерактивность. Запустить её можно с помощью ключа --interactive
:
# k8sgpt analyze -b openai --no-cache -m 1 --namespace=dev --filter Ingress --explain --interactive
...
0 dev/torin-test(torin-test)
- Error: Ingress uses the ingress class nginxa which does not exist.
...
Solution:
1. Verify the existence of the specified ingress class (nginxa).
...
Interactive mode enabled [type exit to close.]
Input text: Write me command to fix ingress class name
To fix the ingress class name, you can use the following command:
```
kubectl edit ingress dev/torin-test
```
This command will open the Ingress resource in an editor where you can update the specified ingress class from "nginxa" to the correct value. Make sure to save the changes after editing the file.
Далее открывается огромное пространство для коммуникации с AI.
Проверим k8sgpt на практике с помощью внешних AI-бэкендов. Для этого я сымитировал несколько проблем с ресурсами кластера и посмотрел, какие советы по их устранению предлагает утилита.
Через .spec.affinity.nodeAffinity
ограничил узлы, на которых может запускаться под. Если условия не будут удовлетворены, то под будет в статусе Pending. Проверим эту проблему через утилиту:
# k8sgpt analyse --explain --namespace=dev
100% |█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| (2/2, 16 it/min)
AI Provider: openai
0 dev/web-0(StatefulSet/web)
- Error: 0/3 nodes are available: 1 node(s) didn't match Pod's node affinity/selector, 1 node(s) had taint {dedicated: kafka}, that the pod didn't tolerate, 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate.
Solution:
1. Update the pod's node affinity/selector to match a node that is available.
2. Remove the taint {dedicated: kafka} from the node or add toleration in the pod's spec to tolerate the taint.
3. Remove the taint {node-role.kubernetes.io/master: } from the node or add toleration in the pod's spec to tolerate the taint.
В ответе k8sgpt в первую очередь предлагает проверить верность указанных selectors (nodeselector) и affinity, что является верным предположением. Дальнейшие рекомендации по удалению taint также могут быть полезны, так как в этих местах тоже часто допускаются ошибки.
Следующая ошибка связана с невозможностью скачать образ. В данном примере я изменил имя текущего образа на несуществующее, и вот что ответила на это утилита и базовая модель gpt-3.5-turbo
от openai
:
# k8sgpt analyze --explain -m 1 --namespace=dev
100% |████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| (2/2, 13 it/min)
AI Provider: openai
0 dev/web-0(StatefulSet/web)
- Error: Back-off pulling image "registry.k8s.io/alpine:3.88"
Error: The Kubernetes container is experiencing a back-off while trying to pull the image "registry.k8s.io/alpine:3.88".
Solution:
1. Check the image repository registry for any issues or downtime.
2. Verify the image name and tag are correct.
3. Ensure there is enough disk space on the Kubernetes node.
4. Restart the Kubernetes cluster or pod to retry the image pull.
5. If the issue persists, check network connectivity to the image registry.
6. Consider using a different image or version if the problem persists.
В своём ответе модель с помощью утилиты предлагает проверить, работает ли вообще registry. И потом предлагает проверить имя тега. Если не помогло, ещё можно проверить место для хранения образа, перезагрузить кластер, проверить доступность между кластером и хранилищем образов, а в конце рекомендуется попробовать другой образ.
Ход мыслей у модели верный, но предложение перезагрузить кластер приведёт к недоступности всего, что в нём запущено. Поэтому следовать рекомендациям всё же нужно с оглядкой на масштаб возможных последствий.
Если посмотреть документацию, утилита парсит вывод нескольких источников, в том числе kubectl get events
. Выглядит этот вывод так:
# kubectl -n dev get events --sort-by='.metadata.creationTimestamp'
LAST SEEN TYPE REASON OBJECT MESSAGE
20s Normal Pulling pod/web-0 Pulling image "registry.k8s.io/alpine:3.88"
20s Warning Failed pod/web-0 Error: ErrImagePull
20s Warning Failed pod/web-0 Failed to pull image "registry.k8s.io/alpine:3.88": rpc error: code = NotFound desc = failed to pull and unpack image "registry.k8s.io/alpine:3.88": failed to resolve reference "registry.k8s.io/alpine:3.88": registry.k8s.io/alpine:3.88: not found
5s Normal BackOff pod/web-0 Back-off pulling image "registry.k8s.io/alpine:3.88"
5s Warning Failed pod/web-0 Error: ImagePullBackOff
Это подтверждает то, что утилита опирается на данные кластера. Значит, она видит проблему и предлагает решение именно по возникшей ситуации.
Теперь проверим утилиту на этой же проблеме только с использованием стороннего AI-сервера — Cohere. Описание модели можно найти по этой ссылке. Добавить новую модель можно не только через k8sgpt auth add -b cohere -m command-nightly
, но и через редактирование файла конфигурации /root/.config/k8sgpt/k8sgpt.yaml
. Модель проста в регистрации, для подтверждения не требуется номер телефона, и даже в бесплатном режиме можно комфортно отправлять запросы.
Модель Cohere справилась с проблемой неверного имени тега следующим образом:
# k8sgpt analyze --explain -m 1 --no-cache --namespace=dev
100% |███████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| (1/1, 17 it/min)
AI Provider: cohere
0 dev/test-6645f4b985-rbm7z(Deployment/test)
- Error: Back-off pulling image "alpine:3.88"
Error: Kubernetes is having trouble pulling the image "alpine:3.88".
This could be due to a few reasons, such as a network issue,
a problem with the image repository, or a slow download.
Solution: Check the Kubernetes logs for more details on the error.
You can also try to pull the image manually to see if there are any issues
with the repository or download.
If the issue persists, try restarting the Kubernetes node or cluster.
В этом варианте как будто поменялся prompt. Например, нет пронумерованного списка рекомендаций. Также подход к решению немного иной: предлагается верхнеуровнево проверить сетевые проблемы, проблемы с registry или низкой скоростью загрузки. Ещё рекомендуется посмотреть логи K8s и попробовать скачать образ вручную. А если совсем ничего не помогает, нужно перезапустить кластер. Но о том, к какой проблеме это может привести, мы говорили ранее.
Решение той же проблемы от флагманской модели OpenAI gpt-4o
по сути ничем не отличается от ответа gpt-3.5-turbo
:
0 dev/test-6645f4b985-rbm7z(Deployment/test)
- Error: Back-off pulling image "alpine:3.88"
Error: Kubernetes is unable to pull the Docker image "alpine:3.88".
Solution:
1. Verify the image name and tag are correct.
2. Check if the image exists in the repository.
3. Ensure your Kubernetes nodes have internet access.
4. Try pulling the image manually using `docker pull alpine:3.88`.
5. Update the image tag if necessary.
Тут, сравнивая два бэка и три модели, две из которых с одинаковой настойчивостью рекомендуют перезапустить кластер, логично выбрать последнюю — 4o
, да и визуально и технически структурированный ответ от OpenAI мне нравится больше. С другой стороны, Cohere проще в регистрации и работает без VPN.
Теперь я подбрасываю утилите проблемы в рамках недоступности образа. Но на этот раз поменяю логин и пароль для доступа к gitlab.registry
— локальный registry, в который перепушил образ alpine
, поэтому тег изменился. Тестирую k8sgpt на модели gpt-3.5-turbo
от openai
. Получаю такой ответ:
# k8sgpt analyze --explain -m 1 --no-cache --namespace=dev
100% |████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| (2/2, 8 it/min)
AI Provider: openai
1 dev/web-0(StatefulSet/web)
- Error: Back-off pulling image "registry.k8s.io/alpine:7c36eb2e27a23465498b483c1fc02c94142b31919e51bdede2146e6a-1690898126442"
Error: The Kubernetes is experiencing a back-off while pulling the image "registry.k8s.io/alpine:7c36eb2e27a23465498b483c1fc02c94142b31919e51bdede2146e6a-1690898126442".
Solution:
1. Check the network connectivity to the image registry.
2. Verify the image name and tag are correct.
3. If using custom image repository, ensure proper authentication is configured.
Советы такие: проверить сеть, имя тега и верность кредов подключения к частному хранилищу. Последний вариант верный, но есть нюанс — спустя некоторое время список рекомендаций обновился:
1 dev/web-0(StatefulSet/web)
- Error: Back-off pulling image "registry.k8s.io/alpine:7c36eb2e27a23465498b483c1fc02c94142b31919e51bdede2146e6a-1690898126442"
Error: There is an issue with pulling the specified image from the registry.
Solution:
1. Check if the image name and tag are correct.
2. Verify if the registry URL is accessible.
3. Ensure that you have the necessary permissions to pull the image.
4. Make sure there is an active internet connection.
5. Restart the Kubernetes pod or deployment.
Обновление списка рекомендаций может показаться странным, так как при обращении к модели не была явно указана высокая температура — параметр, который отвечает за случайность генерируемого текста. На эту тему даже было открыто обращение, и начиная с версии утилиты v0.3.18 можно указать этот параметр, по умолчанию — 0,7, и это делает модель более креативной в ответах. Сама настройка температуры вынесена в файл конфигурации:
cat /root/.config/k8sgpt/k8sgpt.yaml
ai:
providers:
- name: openai
model: gpt-3.5-turbo
password: ...
temperature: 0.7
topp: 0.5
maxtokens: 2048
...
Но вариант с параметром — это всего лишь догадки. Также обновление текста рекомендаций можно списать на новые события в кластере и использование опции --no-cache
, что делает каждый новый запрос без учёта данных предыдущего.
Новый ответ утилиты рекомендует проверить имя тега, корректность ссылки до registry и наличие необходимых прав для скачивания — это бывает важно в некоторых случаях. Также рекомендуется проверить интернет-подключение и, по уже сложившейся традиции, если ничего не помогает, перезапустить кластер.
Обновлённый список рекомендаций оказался шире, и большинство предложенных решений имеют право на существование. При этом пропал вариант с корректностью логина и пароля, который я загадал, хотя всё это время в описании пода (kubectl -n dev describe pod web-0
) можно видеть явную ошибку доступаfailed to authorize: failed to fetch anonymous token: unexpected status: 403 Forbidden
.
К сожалению, модель не всегда выдаёт удовлетворяющий на 100% ответ. Но это искусственный пример, в котором я знаю, что сломал. В реальной же ситуации от модели потребуются варианты, перепробовав которые можно спросить ещё раз. Но справедливости ради нужно отметить, что на этот раз 4o
-модель справилась с задачей лучше своей предшественницы:
Solution:
1. Verify image registry URL and credentials.
2. Ensure your Kubernetes secret for the registry is correctly configured.
3. Check OAuth token endpoint and permissions.
4. Retry pulling the image.
Имитирую следующую проблему: делаю любую ошибку в команде запуска пода, например вызываю несуществующий в этом образе bash. В итоге вижу от k8sgpt такой ответ:
# kubectl -n dev get pod
NAME READY STATUS RESTARTS AGE
test-6dbdf798f9-skb8t 0/1 CrashLoopBackOff 4 (22s ago) 2m2s
# k8sgpt analyze --explain --no-cache --namespace=dev
100% |████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| (2/2, 7 it/min)
AI Provider: openai
1 dev/test-6dbdf798f9-skb8t(Deployment/test)
- Error: back-off 1m20s restarting failed container=alpine pod=test-6dbdf798f9-skb8t_dev(9e727950-e020-4422-b4d5-36e725933a26)
Error: The container "alpine" in the "test-6dbdf798f9-skb8t_dev" pod is failing and restarting with a back-off time of 1 minute and 20 seconds.
Solution:
1. Check the logs of the "alpine" container to identify the cause of the failure.
2. Make necessary changes to fix the issue.
3. Restart the pod to apply the changes and validate if the "alpine" container starts successfully.
Утилита рекомендует посмотреть логи контейнера, пофиксить проблему и рестартануть под без какой-либо конкретики.
Смотрю events:
19s Warning Failed pod/test-6dbdf798f9-skb8t Error: failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "bash": executable file not found in $PATH: unknown
Предположительная проблема — exec: "bash": executable file not found in $PATH: unknown
, но упоминаний в решении о ней нет.
Та же ошибка — и новая попытка анализа показывает, что ответ всё же не статичен — есть некоторая вариативность. Но даже изменение температуры до 0,7 кардинально не изменит качество ответа:
# k8sgpt analyze --explain --namespace=dev
100% |████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| (2/2, 15 it/min)
AI Provider: openai
1 dev/test-6dbdf798f9-skb8t(Deployment/test)
- Error: back-off 2m40s restarting failed container=alpine pod=test-6dbdf798f9-skb8t_dev(9e727950-e020-4422-b4d5-36e725933a26)
Error: The container "alpine" in the pod "test-6dbdf798f9-skb8t_dev" failed to restart after a back-off period.
Solution:
1. Check the logs of the pod to identify the specific error causing the container to fail.
2. Update the container configuration or troubleshoot the issue causing the failure.
3. Apply the necessary changes to resolve the error.
4. Restart the pod to check if the issue has been resolved.
Модель 4o
предложила:
Solution:
1. Check container logs: `kubectl logs test-6dbdf798f9-skb8t -c alpine`
2. Describe the pod for more details: `kubectl describe pod test-6dbdf798f9-skb8t`
3. Fix any issues found in the logs or description.
4. Restart the pod: `kubectl delete pod test-6dbdf798f9-skb8t` (it will be recreated).
Как и ожидалось, новые рекомендации отличаются по форме, но идентичны по сути: проверить логи, обновить конфигурацию контейнера, найти и исправить проблему, перезагрузить под. Новая модель лишь предложила конкретные команды для дебага.
Ещё одна частая ошибка — эмулирую запуск пода со следующей командой:
command:
- bash
- "-c"
- "for i in {1..100};do echo \" $i s waiting...\" && sleep 1;done\necho \"some strange command\"\ntail /dev/zero\nEOF \n"
В событиях виден циклический ребут пода:
52s Normal Started pod/test-858c7f9f7d-tp69t Started container alpine
52s Normal Pulled pod/test-858c7f9f7d-tp69t Container image "alpine:3.6" already present on machine
52s Normal Created pod/test-858c7f9f7d-tp69t Created container alpine
4s Warning BackOff pod/test-858c7f9f7d-tp69t Back-off restarting failed container
По events нельзя однозначно судить о проблеме. Про OOM тут явно не сказано, но это можно обнаружить, сделав describe
:
# kubectl -n dev describe pod test-858c7f9f7d-tp69t
...
State: Waiting
Reason: CrashLoopBackOff
Last State: Terminated
Reason: OOMKilled
Также ненадолго эту информацию поймал в статусе пода:
# kubectl -n dev get pod -w
NAME READY STATUS RESTARTS AGE
test-858c7f9f7d-tp69t 1/1 Running 2 (25s ago) 49s
test-858c7f9f7d-tp69t 0/1 OOMKilled 2 (26s ago) 50s
test-858c7f9f7d-tp69t 0/1 CrashLoopBackOff 2 (13s ago) 63s
test-858c7f9f7d-tp69t 1/1 Running 3 (29s ago) 79s
test-858c7f9f7d-tp69t 0/1 OOMKilled 3 (40s ago) 90s
test-858c7f9f7d-tp69t 0/1 CrashLoopBackOff 3 (13s ago) 102s
Чат на это даёт следующие рекомендации:
# k8sgpt analyze --explain --no-cache --namespace=dev -f Pod
0% | | (0/1, 0 it/hr) [0s:0s]^ 100% |█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| (1/1, 7 it/min)
AI Provider: openai
0 dev/test-858c7f9f7d-tp69t(Deployment/test)
- Error: back-off 5m0s restarting failed container=alpine pod=test-858c7f9f7d-tp69t_dev(2dcd7352-a56c-4c87-a74f-88f964b60d02)
Error: The alpine container in pod test-858c7f9f7d-tp69t_dev failed to start and is continuously restarting with a back-off period of 5 minutes.
Solution:
1. Check the logs of the pod using `kubectl logs pod/test-858c7f9f7d-tp69t_dev`
2. Identify the cause of the failure in the logs.
3. Fix the issue with the alpine container.
4. Update the pod using `kubectl apply -f <pod_yaml_file>` to apply the changes.
5. Monitor the pod using `kubectl get pods -w` to ensure it is running without restarts
Нужно найти причину, внести изменения, перезапустить под и продолжать наблюдение. Повторные запуски с разными задержками и попытки подловить ошибку не увенчались успехом. Получается, что k8sgpt может не заметить плавающие ошибки. Возможно, тут подошла бы операторная версия утилиты.
Дальше будет достаточно простая ошибка с опечаткой. Чуть ниже покажу, с какой именно, а пока запускаю под c образом nginx и подключаю его к kind: Ingress. По events ошибок нет:
# kubectl -n dev get events
LAST SEEN TYPE REASON OBJECT MESSAGE
6m Normal Pulled pod/test-548bf544cd-nttq5 Container image "alpine:3.6" already present on machine
6m Normal Created pod/test-548bf544cd-nttq5 Created container alpine
9m24s Normal Sync ingress/torin-test Scheduled for sync
В describe тоже пусто:
# kubectl -n dev describe ingress
Name: torin-test
Labels: <none>
Namespace: dev
Address: 95.217.82.184
Default backend: default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
TLS:
torin-test-tls terminates torin-test.sandbox.echo-shared.hf.flant.com
Rules:
Host Path Backends
---- ---- --------
torin-test.sandbox.echo-shared.hf.flant.com
/ torin-test:app (<error: endpoints "torin-test" not found>)
Annotations: kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/force-ssl-redirect: true
nginx.ingress.kubernetes.io/ssl-redirect: true
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Sync 10m (x2 over 10m) nginx-ingress-controller Scheduled for sync
И если нет идей, куда после этого смотреть, k8sgpt может подсказать возможную проблему:
# k8sgpt analyze --explain -m 1 --namespace=dev
100% |█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| (2/2, 20 it/min)
AI Provider: openai
0 dev/torin-test(torin-test)
- Error: Ingress uses the ingress class nginxa which does not exist.
- Error: Ingress uses the service dev/torin-test which does not exist.
- Error: Ingress uses the secret dev/torin-test-tls as a TLS certificate which does not exist.
Error: Ingress uses the ingress class nginxa which does not exist. Ingress uses the service dev/torin-test which does not exist. Ingress uses the secret dev/torin-test-tls as a TLS certificate which does not exist.
Solution:
1. Check the spelling and syntax of the ingress class "nginxa" to ensure it matches a valid ingress class name.
2. Verify if the service "dev/torin-test" exists. If not, create the service with the required specifications.
3. Confirm if the secret "dev/torin-test-tls" exists. If not, create the secret with the correct TLS certificate information.
И первым же пунктом утилита предлагает верное решение: опечатка в имени ingress class
, а класса nginxa
не существует в кластере:
# kubectl get ingressclasses.networking.k8s.io --no-headers -o custom-columns=":metadata.name"
nginx
Тут нужно отметить, что ошибка Error: Ingress uses the ingress class nginxa which does not exist
была обнаружена в секции analyze
— то есть анализатором k8sgpt на основе данных из кластера и до использования AI. Поэтому неудивительно, что в секции Solution AI тоже подчёркивает важность этой проблемы и предлагает верный вариант её решения.
По поводу опечатки в имени ресурса — неожиданно подробный ответ и пошаговые рекомендации с командами дал бэк Cohere c моделью command-nightly (полный список актуальных моделей можно получить из документации) даже без опции -d
:
# k8sgpt analyze -b cohere --explain -m 1 --namespace=dev
100% |██████████████████████████████████████████████████████████████████████████████████████████████| (2/2, 5 it/min)
AI Provider: cohere
1 dev/torin-test(torin-test)
- Error: Ingress uses the ingress class nginxa which does not exist.
- Error: Ingress uses the service dev/torin-test which does not exist.
- Error: Ingress uses the secret dev/torin-test-tls as a TLS certificate
which does not exist.
Error: Ingress uses the ingress class nginxa which does not exist.
Ingress uses the service dev/torin-test which does not exist.
Ingress uses the secret dev/torin-test-tls as a TLS certificate
which does not exist.
Solution: To resolve this error, you can follow these steps:
1. Verify the ingress class: Make sure that the ingress class `nginx`
exists in the Kubernetes cluster. You can use the following command to check:
```
kubectl get ingressclass nginxa
```
2. Verify the service: Make sure that the service `dev/torin-test`
exists in the Kubernetes cluster. You can use the following command to check:
```
kubectl get service dev/torin-test
```
3. Verify the secret: Make sure that the secret `dev/torin-test-tls`
exists in the Kubernetes cluster. You can use the following command to check:
```
kubectl get secret dev/torin-test-tls
```
If any of these resources do not exist, you can create them with the
following commands:
```
kubectl apply -f ingress.yaml
kubectl apply -f service.yaml
kubectl apply -f secret.yaml
```
4. Update the ingress: Once you have verified that the required
resources exist, you can update the ingress to use the correct resources.
You can use the following command to patch the ingress:
```
kubectl patch ingress torin-ingress --type='json'
--patch='{"spec": {"ingressClassName": "nginx",
"defaultBackend": {"serviceName": "torin-test", "servicePort": 80}}'
```
5. Verify the ingress: After updating the ingress, you can verify that it is
using the correct resources by running the following command:
```
kubectl get ingress torin-ingress
```
Output:
```
NAME CLASS HOSTNAME ADDRESS PORTS AGE
torin-ingress nginxa 127.0.0.1 80 1d3h
```
This output shows that the ingress `torin-ingress` is using the correct
ingress class (`nginx`), service (`torin-test`), and secret (`torin-test-tls`).
Что предлагает бэк Cohere:
Проверить наличие ингресс-класса с таким именем.
Проверить наличие сервиса и секрета.
Поменять настройки ингресса с учётом найденных имён ресурсов.
Проверить корректность настройки ингресса.
И как уже сказал, всё это с конкретными командами.
Использование внешних бэков может показаться небезопасным, так как в запросах в бэк явно фигурируют имена неймспейсов, подов и прочих ресурсов кластера. И может возникнуть вопрос, отправляются ли данные, например, секретов. На этот случай утилита предлагает возможность анонимизации отправляемых данных с помощью опции --anonymize
. Например, так выглядит запрос без --anonymize
:
# k8sgpt analyze -b localai --no-cache -m 1 --namespace=dev --filter Ingress --explain
...
--- Ingress uses the ingress class nginxa which does not exist. Ingress uses the service dev/torin-test which does not exist. Ingress uses the secret dev/torin-test-tls as a TLS certificate which does not exist. ---.
...
Здесь после команд представлены логи запроса от утилиты со стороны бэка. Логи взяты из бэка localai
, пример запуска которого будет ниже.
А так со стороны бэка выглядит тот же запрос, но с опцией --anonymize
:
# k8sgpt analyze -b localai --no-cache -m 1 --namespace=dev --filter Ingress --explain --anonymize
...
--- Ingress uses the ingress class ZWIyfD5S which does not exist. Ingress uses the service Rkwv/c0gnUmJZNjhPIw== which does not exist. Ingress uses the secret ZUUx/LVdhSF9rbF0xNEIjLVA= as a TLS certificate which does not exist. ---.
...
Видно, что имена ресурсов в данном случае скрыты. Со стороны же ответа утилиты пользователю разница в именах не видна, поэтому для демонстрации работы опции потребовались именно логи бэка.
Если же нужен ещё более безопасный способ использования утилиты k8sgpt, стоит рассмотреть возможность использования собственного бэка (-b localai
).
Для кластера может подойти решение LocalAI — приложение, которое позволяет запускать модели искусственного интеллекта без необходимости подключения к интернету. Тут может возникнуть путаница проекта LocalAI и бэка утилиты k8sgpt (-b localai). Последняя — это общий ключ для подключения любого бэка с моделью, а LocalAI — одна из возможных реализаций этого бэка, так как утилите для подключения бэка localai достаточно ссылки и ключа доступа. Провайдером же для модели может быть любое другое приложение.
Для установки LocalAI понадобится следующее:
Для установки LocalAI я использовал werf, а не чистый Helm: подредактировал Helm-чарты, создал werf.yaml
и .gitlab-ci.yml
для выката в K8s-кластер удобным для себя способом. Вы можете использовать либо чистый Helm, либо любые другие его аналоги.
values.yaml
выглядит так:
deployment:
env:
...
preload_models: '[{ "url": "github:go-skynet/model-gallery/gpt4all-j.yaml", "overrides": { "parameters": { "model": "ggml-gpt4all-j" }}, "files": [ { "uri": "https://gpt4all.io/models/ggml-gpt4all-j.bin", "sha256": "acd54f6da1cad7c04c48b785178d686c720dcbe549903032a0945f97b1a43d20", "filename": "ggml-gpt4all-j" }]}]'
Здесь стоит обратить внимание на имя модели и ресурсы. По умолчанию используется модель ggml-gpt4all-j
(ниже будет пример с запуском другой модели). Эксперименты с запуском начал проводить на K8s-кластере с доступным на тот момент рабочим узлом с характеристиками 4cpu 8gb и отдал поду почти все доступные ресурсы (узла с GPU под рукой не оказалось, но в следующей части попробую запуститься уже с ними):
resources:
requests:
cpu: 3500m
memory: 7Gi
Диск, чтобы хватило места под модель:
persistence:
pvc:
enabled: true
size: 20Gi
Забегая вперёд, по графикам можно увидеть утилизацию ресурсов во время обработки запроса и длительность подготовки ответа:
7,45 ГБ памяти и 100% CPU — утилизируются почти все ресурсы, что были доступны на узле, так как лимиты поду не указывал.
Также в переменных values.yaml
можно настроить шаблон запроса:
promptTemplates:
ggml-gpt4all-j.tmpl: |
The prompt below is a question to answer, a task to complete, or a conversation to respond to; decide which and write an appropriate response.
### Prompt:
{{.Input}}
### Response:
И его тоже видно в логах пода во время выполнения запроса:
Prompt (after templating): The prompt below is a question to answer, a task to complete, or a conversation to respond to; decide which and write an appropriate response.
### Prompt:
Simplify the following Kubernetes error message delimited by triple dashes written in --- english --- language; --- Ingress uses the ingress class ZWIyfD5S which does not exist. Ingress uses the service Rkwv/c0gnUmJZNjhPIw== which does not exist. Ingress uses the secret ZUUx/LVdhSF9rbF0xNEIjLVA= as a TLS certificate which does not exist. ---.
Provide the most possible solution in a step by step style in no more than 280 characters. Write the output in the following format:
Error: {Explain error here}
Solution: {Step by step solution here}
### Response:
Здесь хорошо видны часть запроса, которую принес бэк для LocalAI, и часть от утилиты k8sgpt — {{.Input}}
. Остальные параметры values.yaml
оставил дефолтными.
Если с ресурсами для пода всё хорошо, достаточно места на runner для скачивания образа и imagePullSecrets на месте, то всё запустится с первого раза:
gitlab-runner:~$ docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
quay.io/go-skynet/local-ai latest ba9a2b1bff11 2 days ago 14GB
В этом случае в логе можно увидеть:
# kubectl -n dev logs local-ai-dev-6b67766d44-59cxh -f
...
12:42PM DBG File "ggml-gpt4all-j" downloaded and verified
12:42PM DBG Prompt template "gpt4all-completion" written
12:42PM DBG Prompt template "gpt4all-chat" written
12:42PM DBG Written config file /models/gpt4all-j.yaml
┌───────────────────────────────────────────────────┐
│ Fiber v2.48.0 │
│ http://127.0.0.1:8080 │
│ (bound on host 0.0.0.0 and port 8080) │
│ │
│ Handlers ............ 55 Processes ........... 1 │
│ Prefork ....... Disabled PID ................ 14 │
└───────────────────────────────────────────────────┘
После успешного развёртывания образа с LocalAI и запуска внутри этого пода модели нужно зарегистрировать новый бэк в k8sgpt:
k8sgpt auth add -b localai -u local-ai-dev.dev.svc.cluster.local:8080/v1 -m ggml-gpt4all-j
k8sgpt auth default -p localai
Запрос k8sgpt в локальный бэк с фильтром по подам:
k8sgpt analyze -b localai --explain --no-cache --namespace=dev -f Pod
И, как уже показывал выше, когда запрос завёрнут в наш локальный под с моделью, можно увидеть, как именно k8sgpt творит свою магию. То есть какими вопросами она оборачивает исходный отчёт по неисправностям, полученный в результате запуска утилиты с опцией --analyze
:
...
### Prompt:
Simplify the following Kubernetes error message delimited by triple dashes written in --- english --- language; --- Back-off pulling image "alpine:3.88" ---.
Provide the most possible solution in a step by step style in no more than 280 characters. Write the output in the following format:
Error: {Explain error here}
Solution: {Step by step solution here}
...
Вот что ответил бэк LocalAI
+ ggml-gpt4all-j
на случай проблемы с отсутствующим тегом:
# k8sgpt analyze -b localai --explain --no-cache --namespace=dev -f Pod
100% |██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| (1/1, 2 it/min)
AI Provider: localai
0 dev/test-6645f4b985-t2ntj(Deployment/test)
- Error: Back-off pulling image "alpine:3.88"
I'm sorry, as an AI language model, it is not within my programming to provide step-by-step solutions or explain errors. However, I can provide the most common response that could occur. In this case, it seems like an error message about pulling the image "alpine:3.88" is being displayed, but there may be no solution to it.
Ответ бесполезный, но честный: данная модель не может предоставить пошаговое решение, но предлагает обратить внимание на ошибку скачивания образа.
Следующий ответ был получен на той же модели, но с температурой 0,9:
# k8sgpt analyze -b localai --explain --no-cache --namespace=dev -f Pod
100% |██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| (1/1, 1 it/min)
AI Provider: localai
0 dev/test-6645f4b985-t2ntj(Deployment/test)
- Error: Back-off pulling image "alpine:3.88"
The error message is "back-off pulling image alpine:3.88". The possible cause of the error is a network issue or an incorrect configuration. To resolve the error, you need to check your network connection and make sure that the image has been successfully pushed to your server. Once the image is uploaded, you can specify it as a dependency in your project's package.json file and run "npm install" to include it in your project. Alternatively, you can also use a CI/CD tool such as Jenkins or Travis CI to automate the build process and ensure that all dependencies are up-to-date.
Тут ответ получился более развёрнутый. Например, утилита предлагает проверить сетевое соединение и убедиться в наличии упомянутого образа на сервере. При этом сервис ввёл меня в заблуждение: совет про package.json
явно не относится к проблеме. Из плюсов — модель не предлагает перезапустить кластер.
Как видно из примеров выше, подход с использованием локальной модели применим. При этом требуется узел с бо́льшими объёмами вычислительных мощностей, так как не представляется возможным ждать рекомендаций по несколько часов при интерактивном взаимодействии с утилитой. Возможно, такой вариант подойдёт, например, в режиме запуска утилиты как оператора. А ещё при использовании приложения LocalAI в кластере не удалось найти возможности использовать одну из ключевых фишек K8s: запустить несколько Pod с моделью для параллельных вычислений. Скорее всего, такой вариант запуска модели не поддерживается.
Дальше захотелось попробовать запустить другую модель. Для этого комьюнити подготовило несколько готовых вариантов в галерее. Например, вот модель, которая использовалась выше. Или можно попробовать такую известную модель, как llama_7b
, для этого в values.yaml
нужно поменять или добавить параметр preload_models
:
preload_models: '[{"url": "github:go-skynet/model-gallery/openllama_7b.yaml", "name": "gpt-3.5-turbo"}]'
Но допустим, мне захотелось попробовать модель, которой нет в галерее, то есть нет среди доступных шаблонов для LocalAI. Или же у меня есть собственная обученная модель. В этом случае может помочь локальная галерея шаблонов. Для этого можно сделать следующее: скачать модель с общедоступного репозитория или обучить свою, составить шаблон и сделать доступным файл шаблона (например, через отдельный ингресс того же кластера). После этого нужно указать приложению LocalAI на свой подготовленный yaml-файл со скачанной моделью.
Вот пример такого файла-шаблона для модели llama_2_7b_chat_gglm.yaml
:
name: "llama-2-7b-chat-gglm"
description: |
...
license: ...
urls:
- https://huggingface.co/meta-llama/Llama-2-7b-chat-hf
config_file: |
backend: llama
parameters:
model: llama-2-7b-chat.ggmlv3.q6_K.bin
top_k: 80
temperature: 0.2
top_p: 0.7
context_size: 1024
template:
completion: openllama-completion
chat: openllama-chat
files:
- filename: "llama-2-7b-chat.ggmlv3.q6_K.bin"
sha256: "e32c8f063b357001a1da0431778b40a78aa71dd664561ff14c51f18556381818"
uri: "https://huggingface.co/TheBloke/Llama-2-7B-Chat-GGML/blob/main/llama-2-7b-chat.ggmlv3.q6_K.bin"
prompt_templates:
- name: "openllama-completion"
content: |
Q: Complete the following text: {{.Input}}\nA:
- name: "openllama-chat"
content: |
Q: {{.Input}}\nA:
Остальные параметры можно крутить. В моём случае можно считать, что они остались по умолчанию.
Добавляю в values.yaml
приложения LocalAI ссылку на локальный шаблон и перезапускаю деплой:
preload_models: '[{"url": "https://gallery.sandbox.echo-shared.hf.flant.com/llama_2_7b_chat_gglm.yaml", "name": "llama_2_7b_chat_gglm"}]'
Поскольку выделенных тестовых мощностей для запуска модели мне, естественно, не хватило, то и показать ответы модели тут не смогу. Рекомендованные мощности обычно указаны в описании модели. Например, в репозитории huggingface для llama_2_7b
требуемые ресурсы указаны здесь.
Из вышеперечисленного можно сделать вывод, что утилите k8sgpt для формирования полезной рекомендации зачастую недостаточно моделей, обученных на небольшом количестве данных, или сильно квантованных моделей, например ggml-gpt4all-j
. При квантовании уменьшается объём памяти, необходимый для хранения модели, и ускоряется её выполнение за счёт снижения вычислительной нагрузки. Но это также приводит к потере точности и ухудшению качества результатов модели. А для достижения лучших результатов нужны большие мощности, но об этом я постараюсь рассказать в следующих статьях.
Самый важный вывод, который я сделал для себя: утилиту k8sgpt можно использовать как неплохую помощь при онбординге. Даже без бэкенда в виде AI в утилиту встроены полезные анализаторы состояния ресурсов кластера, которые в некоторых случаях достаточно информативны. Кроме этого, можно добавить информацию из документации K8s, не выходя из консоли.
При этом отмечу, что обычно новичок с помощью некоторых самых базовых команд диагностистики, таких как kubectl explain
, describe
, get events
, logs
, и любимого поисковика сможет найти решение представленных в статье проблем, но ответы k8sgpt помогают быстрее пойти в правильном направлении за счёт фокуса на возможных решениях, а не на кодах ошибок, а также за счёт структурированной выдачи и примеров команд.
Полезность советов k8sgpt по устранению проблем зависит от используемого бэкенда — модели, которая генерирует ответ. После анализа нескольких бэков субъективно лучшей на момент сравнения показалась OpenAI с моделью 4o
, хотя gpt-3.5-turbo
зачастую даёт сопоставимые ответы, а стоит меньше. Из плюсов ответов 4o
— она, помимо рекомендаций, выдавала и команды для диагностики. Локальные модели также дают полезные ответы, но здесь всё зависит от доступных мощностей.
В этом эксперименте я не сравнивал вывод утилиты с диалогом в чате. Кажется, данное сравнение было бы некорректным. Чат всё же является более гибким инструментом, где можно многократно обновлять контекст, делать замечания и уточнения, например скопировать вывод kubectl get events
и логи пода в веб выбранного чата и получить схожий набор рекомендаций. Но тем не менее граница стала более размытой после добавления утилите k8sgpt интерактивного режима.
В качестве плюса утилиты отмечу удобство, так как рекомендации по дебагу можно получить, не переключаясь из терминала кластера в браузер. k8sgpt подсвечивает опечатки или отсутствие требуемых ресурсов, если их забыли определить. А модуль анализа дополнительно проверяет ошибки некоторых ресурсов, отправляя в бэк, помимо текста ошибки, дополнительную отладочную информацию, подходящую данному типу ресурса. Таким образом, используя утилиту при онбординге и получая список пошаговых действий, можно начать включаться в дебаг кластера, исключая с помощью утилиты сначала самые простые и частые ошибки.
Из явных минусов стоит отметить, что анализ проводится по определённому количеству ресурсов кластера, пробовать дебажить кастомные ресурсы пока нет возможности, но проект открытый и активно развивающийся. Продолжая про минусы, плавающие ошибки отловить так и не удалось, а из неожиданного — ту же ошибку ErrImagePull можно поймать утилитой k8sgpt только на основном контейнере, для initContainer ошибка осталась незамеченной.
Кроме этого, хотелось бы в будущем получить возможность менять шаблон запроса (prompt), сохранять контекст и обогащать его новыми событиями. Ещё был бы полезен анализ логов пода. Тем не менее проект быстро развивается, и некоторые фичи, которых мне не хватало в начале обзора, появились к его концу, например интерактивный режим.
Статья является компиляцией личного опыта и других обзоров. Полезные ссылки по теме:
K8sGPT: Simplifying Kubernetes Diagnostics with Natural Language Processing
LocalAI meets k8sgpt: Analyzing Kubernetes Cluster States Locally with CPU at the Edge and Beyond
A Gentle Intro to K8sGPT: Your Kubernetes Debugging Sidekick
Читайте также в нашем блоге:
Создание скрипта на Python с помощью ChatGPT-4о: автоматизация миграции доменов
Обзор Simulator — платформы для обучения инженеров безопасности Kubernetes с помощью CTF-сценариев
Обзор инструментов для оценки безопасности кластера Kubernetes: kube-bench и kube-hunter
Обзор K8s LAN Party — сборника задач по поиску уязвимостей в кластере Kubernetes прямо в браузере