Инструментарий искусственного интеллекта для облачных вычислений: разработка платформы на GKE с использованием Gemini.

1. Введение

Устранение неполадок в неработающих развертываниях Kubernetes — распространенная и часто вызывающая разочарование часть повседневной работы инженера платформы. Обычно это включает в себя множество ручных исследований: изучение логов, выполнение команд kubectl describe и сопоставление YAML-файлов для поиска единичного несоответствия или неправильной конфигурации.

Хотя универсальные чат-боты с искусственным интеллектом могут помочь объяснить концепции или написать базовый код, они работают в вакууме. Они ничего не знают о вашей конкретной кодовой базе или текущем состоянии вашего кластера, что приводит к большому количеству ручного копирования и вставки, а также переключениям контекста.

В этой лабораторной работе вы узнаете, как преодолеть этот разрыв, используя инструменты искусственного интеллекта с возрастающим уровнем контекста. Вы будете использовать Gemini CLI и протокол контекста модели (MCP) для устранения неполадок в неработающем приложении в GKE. К концу лабораторной работы вы поймете, как использовать ИИ, учитывающий ваши файлы и инфраструктуру, для более быстрого решения сложных проблем, а также как кодифицировать эти рабочие процессы в многократно используемые «навыки» для вашей команды.

Основные концепции

  • Разработка платформ : Разработка платформ — это практика создания и поддержки внутренних инструментов и рабочих процессов, позволяющих разработчикам программного обеспечения управлять собственной инфраструктурой, не будучи экспертами во всех базовых облачных сервисах. Цель — уменьшить технические сложности, сохраняя при этом согласованность и безопасность. Создавая стандартизированный «золотой путь», команды платформы гарантируют, что разработчики приложений смогут безопасно и быстро развертывать приложения, сохраняя при этом контроль над управлением и затратами.
  • Gemini CLI : Gemini CLI — это интерфейс командной строки, позволяющий взаимодействовать с моделями Gemini непосредственно из терминала. В отличие от стандартного веб-чат-бота, CLI разработан для работы в вашей среде разработки, что упрощает интеграцию ИИ в существующие рабочие процессы на основе командной оболочки. Он позволяет передавать вывод других команд непосредственно в модель и выполнять инструкции, не покидая терминал.
  • Протокол контекста модели (MCP) : MCP — это открытый стандарт, позволяющий модели ИИ взаимодействовать с конкретными инструментами или источниками данных. Без MCP модель ИИ знает только то, на чём она обучалась, и не может видеть ваши конкретные ресурсы. С помощью сервера GKE MCP , Gemini CLI может активно запрашивать API вашего проекта Google Cloud, проверять состояние ваших кластеров и выполнять команды от вашего имени. Он выступает в качестве моста между механизмом рассуждений модели и фактическим API GKE.
  • Навыки агента : Навыки — это пакеты инструкций, скриптов и ресурсов, расширяющие возможности ИИ-агента для выполнения специализированных задач. Они позволяют кодифицировать организационные стандарты и автоматизировать сложные рабочие процессы.

Цели лабораторной работы

В этой лаборатории вы:

  1. Оцените прогресс контекста: посмотрите, как расширение контекста улучшает способность ИИ решать задачи.
  2. Сравнение ручного и автоматизированного устранения неполадок: сравните сложность ручной отладки с рабочими процессами, выполняемыми с помощью ИИ.
  3. Полноконтекстная отладка: используйте Gemini CLI с сервером GKE MCP для отладки приложений с полным учетом инфраструктуры.
  4. Расширьте возможности: научитесь создавать собственные навыки для автоматизации рабочих процессов.

Примечание к результатам LLM

Ввиду специфики этой лабораторной работы и принципов работы моделей LLM, полученные вами результаты, вероятно, будут отличаться от показанных примеров. Это ожидаемое поведение для генеративного ИИ. Сосредоточьтесь на понимании шагов и рассуждений, предоставляемых моделью, а не на попытке точно воспроизвести текст или форматирование из примеров.

2. Настройка проекта

Перед началом работы подготовьте рабочую среду. Откройте Cloud Shell, выберите свой проект и запустите скрипты настройки. Давайте начнём!

Открытая облачная оболочка

Для этой лабораторной работы используйте Cloud Shell — браузерную терминальную среду, предоставляемую Google Cloud. Она поставляется с предварительно настроенными всеми необходимыми инструментами, включая Google Cloud CLI ( gcloud ) , kubectl и Gemini CLI, что сэкономит вам время на их установке на локальном компьютере.

  1. Перейдите в консоль Google Cloud .
  2. Посмотрите в верхний правый угол консоли и нажмите кнопку «Активировать Cloud Shell» (она выглядит как приглашение терминала >_ ).
  3. В нижней части окна браузера откроется окно терминала. Если появится запрос, нажмите «Продолжить» .

Выберите проект

В терминале Cloud Shell убедитесь, что вы работаете в правильном проекте.

  1. Выберите существующий проект или создайте новый специально для этой лабораторной работы в консоли.
  2. Запишите идентификатор вашего проекта . Установите проект в текущей оболочке, выполнив команду: gcloud config set project [YOUR_PROJECT_ID]

Настройка лаборатории

Теперь запустите скрипты настройки, чтобы подготовить среду и внедрить ошибки для лабораторной работы.

  1. Клонируйте репозиторий:
     👉💻 Выполните следующие команды, чтобы клонировать только каталог lab: 
    git clone --depth 1 --filter=blob:none --sparse https://github.com/GoogleCloudPlatform/devrel-demos ~/devrel-demos
cd ~/devrel-demos
git sparse-checkout set codelabs/ai-toolkit-lab-1
  2. Перейдите в каталог лаборатории:
     👉💻 Бег: 
    cd ~/devrel-demos/codelabs/ai-toolkit-lab-1/
  3. Установите переменные среды:
     👉💻 Выполните следующие команды, чтобы задать проект и регион: 
    export PROJECT_ID=$(gcloud config get-value project)
export REGION=us-central1
  4. Запустите скрипт установки:
     Этот скрипт активирует перечисленные ниже API, создает кластер GKE Autopilot и обеспечивает установку необходимых инструментов.
    👉💻 Запустите скрипт из корневого каталога:
    ./setup.sh
    Примечание: Создание кластера может занять 5-10 минут.
  5. Инициализируем неисправное состояние:
     Чтобы смоделировать ситуацию, когда ваши коллеги оставили вам неработоспособную среду, запустите скрипт break.sh . Он скопирует поврежденные манифесты в активный каталог кода.
    👉💻 Запустите скрипт: 
    ./break.sh
  6. Подготовьтесь к лабораторным работам:
     Чтобы ИИ не жульничал (не видел решения), перейдите в каталог cymbal-bank для выполнения остальной части лабораторной работы.
    👉💻 Бег: 
    cd ~/devrel-demos/codelabs/ai-toolkit-lab-1/cymbal-bank

Включенные API

Скрипт настройки активирует несколько API Google Cloud. Вот что они делают:

  • container.googleapis.com: API Google Kubernetes Engine. Он необходим для любых операций на уровне кластера.
  • generativelanguage.googleapis.com: API, позволяющий Gemini CLI взаимодействовать с моделями Gemini.
  • cloudresourcemanager.googleapis.com: Необходим для просмотра метаданных на уровне проекта и управления правами доступа.
  • logging.googleapis.com: Незаменим для устранения неполадок, поскольку позволяет получать и анализировать журналы из ваших контейнеров.

3. Этап 0: Ручная диагностика неисправностей (без ИИ)

Теперь, когда вы находитесь в каталоге cymbal-bank , давайте попробуем найти ошибки вручную. Это «сложный путь». Прежде чем позволять ИИ выполнять основную работу, проверьте базовый уровень. Ручное устранение неполадок подразумевает использование стандартных инструментов, таких как kubectl для проверки состояния кластера, получения логов и чтения YAML-файлов для выявления несоответствий. Это часто медленно, утомительно и требует специальных знаний для сопоставления фактов. Это послужит идеальной отправной точкой для инструментов ИИ, которые вы будете использовать позже.

  1. Попробуйте развернуть: посмотрим, что Kubernetes думает об этих манифестах.
    👉💻 Выполните следующую команду, чтобы применить манифесты:
    kubectl apply -f kubernetes-manifests/
    Запуск подов может занять несколько секунд. Вы можете следить за их запуском, используя команду 'watch kubectl get pods'. Как только они запустятся, используйте Ctrl+C, чтобы выйти из режима наблюдения. Вы заметите два пода, которые не запускаются:
    • В конфигурации фронтенд- пода отображается ошибка "CreateContainerConfigError" . Этот тип ошибки обычно указывает на проблемы с загрузкой необходимой конфигурации контейнера. Подумайте, какие внешние ресурсы могут потребоваться контейнеру для запуска — возможно, некоторые переменные окружения, секреты или ConfigMaps неправильно настроены или отсутствуют? Вам следует изучить конфигурацию пода, чтобы найти конкретную причину проблемы.
    • Под userservice находится в состоянии "ImagePullBackOff" . Когда вы видите это состояние, это обычно означает, что кластер не может получить образ контейнера, который ему был указан использовать. Обратите внимание на детали запроса образа: правильно ли указаны имя и тег образа? Есть ли потенциальные проблемы с правами доступа к реестру? Посмотрите, откуда загружается образ, чтобы понять, почему запрос не выполняется.
  2. Проанализируйте повреждения: используйте стандартные команды Kubernetes, чтобы определить причину сбоя.
    • 👉💻 Проверьте статус модулей, а также их названия:
      kubectl get pods
      • Наблюдение: Вы видите поды в ImagePullBackOff , CrashLoopBackOff , Pending или CreateContainerConfigError .
      • Примечание: Состояние Running не обязательно означает, что под функционирует корректно. Например, ему может не хватать достаточного количества проверок работоспособности (активности/готовности), из-за чего он может быть помечен как работающий, даже если приложение внутри него неисправно. В логах могут отображаться ошибки, несмотря на кажущуюся работоспособность пода. Всего необходимо исправить 11 различных ошибок.
    • 👉💻 Опишите неисправный под, чтобы увидеть события (замените [POD_NAME] на фактическое имя пода): 
      kubectl describe pod [POD_NAME]
    • 👉💻 Проверьте логи неисправного пода, чтобы увидеть ошибки приложения: 
      kubectl logs [POD_NAME]

Скриншот, показывающий вывод команды kubectl get pods

  1. Детективная работа: Откройте манифесты в папке kubernetes-manifests/ с помощью редактора Cloud Shell или cat в терминале. Попробуйте сопоставить ошибки, которые вы видите в логах и событиях, с конфигурацией в YAML-файлах. Задание: Попробуйте исправить всего ОДНУ ошибку вручную. Обратите внимание, как вам приходится переключаться между файлами, чтобы выяснить остальную цепочку сбоев.

4. Этап 1: Обращение к веб-интерфейсу (веб-интерфейс Gemini)

Поскольку ручная диагностика неисправностей занимает много времени, давайте попробуем использовать ИИ-помощника. Веб-приложение Gemini — это мощный универсальный чат-интерфейс. Он отлично справляется с объяснением концепций и генерацией фрагментов кода. Однако он работает без учета контекста вашей конкретной среды. Он не может видеть ваши файлы, проверять ваш кластер или выполнять команды. Вам придется вручную копировать и вставлять сообщения об ошибках и содержимое файлов.

Скриншот, демонстрирующий веб-интерфейс Gemini.

  1. Перейдите на сайт Gemini: откройте gemini.google.com в новой вкладке. Вам потребуется войти в систему, используя свою учетную запись Google.
  2. Обратитесь за помощью по конкретной ошибке: скажите, что вы видите ошибку ImagePullBackOff в модуле userservice .
    👉💬 Введите эту подсказку в веб-интерфейсе Gemini:
    My Kubernetes deployment for 'userservice' is failing with ImagePullBackOff. Here is the image name: us-central1-docker.pkg.dev/bank-of-anthos-ci/bank-of-anthos/user-service:v0.6.9. What is wrong?
  3. Ответ ИИ: Gemini предоставляет список распространенных причин:
    • Изображение не существует.
    • У вас нет разрешения на его извлечение.
    • Здесь опечатка.
    Предлагается проверить права доступа в реестре или IAM. Но система не сможет определить фактическое имя образа как userservice (без дефиса), если не увидит ваш проект.

Основная проблема заключается в том, что Gemini не имеет доступа к вашей локальной среде. Чтобы получить необходимый контекст, вам придется предоставлять его вручную (путем запроса и копирования текста), что отнимает много времени и чревато ошибками.

5. Этап 2: Питание терминала (Gemini CLI)

Теперь перейдите в терминал, используя Gemini CLI. Gemini CLI предоставляет возможности моделей Gemini прямо в вашем терминале. CLI находится там, где вы работаете. Он читает локальные файлы, принимает ввод через конвейер и даже выполняет команды оболочки от вашего имени (с вашего согласия). Это делает его невероятно полезным для интеграции ИИ в ваши рабочие процессы без переключения контекста. Для получения более подробной информации и расширенного использования обратитесь к официальной документации Gemini CLI .

Примечание: На данный момент Antigravity CLI официально выпущен и является преемником Gemini CLI. В этой лабораторной работе по-прежнему используется Gemini CLI. Для получения более подробной информации об Antigravity CLI ознакомьтесь с официальной документацией Antigravity CLI .

Контекст и видимость

Прежде чем перейти к инструкциям, обратите внимание, что видимость Gemini CLI в вашем проекте зависит от того, где вы его запускаете. Модель может видеть файлы и папки относительно текущего рабочего каталога. Если вы запускаете ее из корневого каталога проекта, она имеет доступ ко всем файлам этого проекта. Если вы запускаете ее из подкаталога, ее доступ ограничен этим подкаталогом и его дочерними каталогами. Всегда убедитесь, что вы находитесь в правильном каталоге, прежде чем просить модель анализировать или изменять файлы!

Запуск Gemini CLI

В Cloud Shell по умолчанию включен Gemini CLI. Просто запустите его, чтобы начать использовать его с локальными файлами.

  1. Перейдите в каталог Cymbal Bank:
     👉💻 Выполните следующую команду, чтобы убедиться, что вы находитесь в правильной директории: 
    cd ~/devrel-demos/codelabs/ai-toolkit-lab-1/cymbal-bank
  2. Запустите Gemini CLI:
     👉💻 Выполните следующую команду, чтобы запустить Gemini CLI: 
    gemini

Скриншот, демонстрирующий, как выглядит интерфейс командной строки Gemini.

Использование Gemini CLI

Всё, что вам известно об этом приложении, — это где найти код и то, что оно не работает. Давайте узнаем больше и посмотрим, как Gemini может помочь вам исправить приложение. Для начала попробуйте проверить его способность исследовать контекст, задав вопрос о файлах приложения, которые он должен видеть.

  1. Изучите код: попросите Gemini объяснить, что это за приложение и для чего оно нужно.
    👉💬 Введите эту команду в Gemini CLI:
     What is this application and what does it do?
    Gemini CLI считывает файлы в текущем каталоге и предоставляет общий обзор проекта.
  2. Попробуйте найти проблему в коде: поскольку Gemini CLI видит ваши файлы, попросите его найти несоответствие.
    👉💬 Введите эту команду в Gemini CLI:
     The contacts service pod is running, but I can't reach the service. Review kubernetes-manifests/contacts.yaml and check for common issues
    Gemini CLI считывает файлы и обнаруживает несоответствие между app: contacts-backend и app: contacts . Это огромное преимущество по сравнению с предыдущими этапами.
  3. Попросите его исправить это:
     👉💬 Введите эту команду в Gemini CLI:
     Fix the label mismatch in contacts.yaml so the service matches the deployment.
    Gemini CLI отображает исправленный YAML-файл или даже применяет изменения, если вы подтвердите команду.
  4. Ограничение: хотя система и видит файлы, она всё ещё не знает, что именно работает в вашем кластере. Если под завершается с ошибкой во время выполнения, неочевидной в статическом YAML-файле, она не сможет помочь без логов или состояния кластера.

Примечание: Gemini CLI будет запрашивать ваше согласие при выполнении команд или внесении изменений в файлы. Это гарантирует сохранение контроля над вашей средой. Когда вы увидите запрос, подобный приведенному ниже, вы можете нажать «Enter», чтобы ответить «1. Разрешить один раз» для каждого запроса действия. Вы также можете нажать клавишу со стрелкой вниз и нажать Enter, чтобы выбрать «2. Разрешить на время этой сессии», что приведет к тому, что Gemini CLI будет всегда выполнять это действие независимо, без запроса вашего разрешения, в течение всего этого диалога. Однако, если вы закроете Gemini CLI и откроете его снова, у него больше не будет этого разрешения, и он снова запросит ваше разрешение перед выполнением каких-либо действий.

Скриншот, демонстрирующий окно согласия Gemini CLI.

Примечание: Если у вас возникнут проблемы или вы захотите попробовать снова с нуля, вы можете в любой момент восстановить манифесты Kubernetes до их исходного неисправного состояния, запустив скрипт ../break.sh из каталога cymbal-bank .

Примечание: Если вы достигли лимита использования, выберите «Остановить», а затем запустите команду /model, чтобы увидеть, какие модели достигли своих лимитов, и переключиться на другую модель, например gemini-2.5-flash-lite. Затем введите команду «продолжить» для выбранной модели, чтобы продолжить выполнение лабораторной работы с использованием новой модели.

6. Этап 3: Полная контекстная отладка (Gemini CLI + GKE MCP)

Хотя второй этап продемонстрировал, насколько мощным может быть ИИ, когда он видит ваши файлы, он также был сопряжен с определенными трудностями. Приходилось вручную подтверждать каждое чтение файла и действие инструмента, что создавало значительные препятствия во время сложной сессии отладки. Третий этап представляет сервер GKE MCP, призванный решить эту проблему, обеспечивая ИИ прямую «информацию об инфраструктуре». Это позволяет Gemini устранять неполадки в журналах, событиях и метаданных с меньшим количеством ручных вмешательств, создавая более автоматизированный и согласованный процесс устранения неполадок.

Что такое MCP?

Для понимания MCP полезно сначала разобраться в концепции инструментов в мире ИИ. Инструмент — это, по сути, внешняя функция или приложение, которое LLM может использовать для выполнения действий или получения данных, к которым он иначе не смог бы получить доступ — например, для проверки погоды, запуска определенного скрипта или запроса к базе данных. Хотя отдельные инструменты обладают большой мощностью, их безопасное и согласованное совместное использование различными агентами ИИ и средами всегда было проблемой. MCP решает эту проблему, выступая в качестве стандартизированной платформы, которая может размещать эти инструменты и предоставлять к ним доступ любому совместимому клиенту ИИ.

Протокол контекста модели (MCP) — это протокол с открытым исходным кодом, который позволяет моделям ИИ безопасно получать доступ к внешним источникам данных и инструментам. Вместо того чтобы жестко прописывать интеграцию для каждого конкретного инструмента или базы данных, MCP предоставляет стандартизированный способ взаимодействия моделей с окружающей средой.

Доступные инструменты в Gemini CLI можно просмотреть, запустив команду /mcp внутри Gemini CLI.

В этой лабораторной работе сервер GKE MCP позволяет Gemini CLI напрямую взаимодействовать с вашим кластером GKE, обеспечивая проверку ресурсов, чтение журналов и помощь в отладке проблем с полным пониманием текущего состояния кластера. Это превращает ИИ из статического анализатора кода в активного помощника по устранению неполадок, который понимает текущее состояние вашей инфраструктуры.

Настройка расширения GKE MCP

По умолчанию Gemini CLI — это инструмент общего назначения. Настройте сервер GKE MCP, создав конфигурационный файл.

  1. 👉💻 Сначала, если вы все еще находитесь в Gemini CLI, выйдите из него, набрав /quit .
  2. 👉💻 Выполните следующую команду, чтобы создать каталог расширений: 
    mkdir -p ~/.gemini/extensions/gke
  3. 👉💻 Выполните следующую команду, чтобы создать файл конфигурации. Эта команда автоматически добавит ваш PROJECT_ID в файл: 
    cat << EOF > ~/.gemini/extensions/gke/gemini-extension.json
{
  "name": "gke",
  "version": "1.0.0",
  "mcpServers": {
    "container": {
      "httpUrl": "https://container.googleapis.com/mcp",
      "authProviderType": "google_credentials",
      "oauth": {
        "scopes": ["https://www.googleapis.com/auth/container"]
      },
      "timeout": 30000,
      "headers": {
        "x-goog-user-project": "$PROJECT_ID"
      }
    }
  }
}
EOF
  4. 👉💻 Запустите Gemini CLI: 
    gemini
  5. Убедитесь, что сервер MCP включен, введя команду /mcp в командной строке Gemini.

Попросите Gemini выполнить отладку с использованием состояния кластера.

  1. Отладка сбоя развертывания: Теперь попросите Gemini проверить кластер и исправить манифесты на основе обнаруженных ошибок.
    👉💬 Введите эту команду в Gemini CLI:
     The frontend deployment is failing. Can you use your tools to check the logs and events of the pods, and then fix it?
    Gemini использует инструменты MCP для вызова команд kubectl в фоновом режиме. Он обнаруживает ошибку ImagePullBackOff , объясняет причину и предлагает правильное решение.
  2. Устранение сложных проблем: запросите у системы просмотр журналов на предмет ошибок на уровне приложения.
    👉💬 Введите эту команду в Gemini CLI:
     Check the logs for the 'contacts' pod. Why is it failing to connect to the database?
    Программа обнаруживает ошибку "соединение отклонено" и отслеживает её причину до несоответствия порта или имени службы в config.yaml !
  3. Повторение: Продолжайте просить Gemini исправить другие проблемы, обнаруженные вами на этапе 0.
    👉💬 Введите эту команду в Gemini CLI:
     Check if the service 'contacts' is correctly routing traffic to its pods
    👉💬 Введите эту команду в Gemini CLI:
     Are there any pods failing due to resource limits?

Примечание: Если у вас возникнут проблемы или вы захотите попробовать снова с нуля, вы можете в любой момент восстановить манифесты Kubernetes до их исходного неисправного состояния, запустив скрипт ../break.sh из каталога cymbal-bank .

7. Этап 4: Расширение возможностей команды (навыки агентов)

Наконец, расширьте возможности ИИ в соответствии со своими конкретными потребностями, создав собственные навыки агента.

Что такое навыки агента?

Навыки агента — это пакеты инструкций, скриптов и ресурсов, расширяющие возможности ИИ-агента для выполнения специализированных задач. Они позволяют кодифицировать организационные стандарты и автоматизировать сложные рабочие процессы. Навык находится в определенной директории и содержит файл SKILL.md , определяющий его поведение. Создавая навыки, вы гарантируете, что ИИ будет следовать последовательному, повторяемому процессу, а не импровизировать.

Типичная папка Skill выглядит следующим образом: 

my-skill/
├── SKILL.md          # Main instruction file (Required)
├── scripts/           # Helper scripts (Optional)
└── resources/         # Templates or data files (Optional)

Развитие навыков устранения неполадок в Kubernetes

Вместо создания этих файлов вручную, Gemini CLI предоставляет мощный способ поэтапного обучения навыкам с использованием естественного языка.

Представьте, что вы хотите создать навык под названием k8s-troubleshooter , чтобы автоматизировать шаги, которые вы только что выполнили.

  1. Создайте навык с помощью подсказки: вы можете попросить Gemini CLI создать навык для вас на основе того, что вы изучили сегодня.
    👉💬 Введите эту команду в Gemini CLI:
     Create a new skill called 'k8s-troubleshooter' that helps diagnose issues with Kubernetes manifests and cluster state. It should be able to analyze pod logs, events, and resource descriptions to identify common deployment problems and configuration errors.
    Аналогично вызову инструмента или выполнению действия, Gemini CLI должен сообщить вам, что ваша командная строка активировала навык "skill-creator". Это предварительно настроенный навык в Gemini CLI, который позволяет Gemini создавать навыки агентов.
    Gemini запросит у вас разрешение на создание каталога навыков. Подтвердите, выбрав « 1. Разрешить один раз ».
    Близнецы автоматически:
    • Создает каталог по адресу ~/.gemini/skills/k8s-troubleshooter/ .
    • Создает файл SKILL.md с инструкциями на основе вашей подсказки.
    • Создает стандартные каталоги ресурсов.
  2. Перезапустите Gemini CLI:
     👉💻 Закройте Gemini CLI ( /quit ), затем перезапустите его: 
    gemini
  3. Убедитесь, что навык загружен:
     👉💻 Убедитесь, что навык активен, введя команду /skills в Gemini CLI. В списке вы должны увидеть k8s-troubleshooter .
  4. Как это работает на практике: Теперь активируем навык:
    👉💬 Введите эту команду в Gemini CLI:
     Use the k8s-troubleshooter skill to find out why the contacts service is failing.
    Искусственный интеллект следует структурированному плану, изложенному в файле SKILL.md вместо того чтобы импровизировать, что приводит к более стабильным результатам.

Упражнение: Сформулируйте собственные навыки.

Подумайте о своем ежедневном рабочем процессе. Какие повторяющиеся задачи можно автоматизировать с помощью навыка?

  • Идея: Навык для проверки манифестов на соответствие передовым методам обеспечения безопасности перед развертыванием.
  • Идея: Навык для генерации сложных конфигураций кластера GKE на основе типа рабочей нагрузки.

8. Заключение

В этой лабораторной работе демонстрируется новый способ взаимодействия с облачной инфраструктурой путем последовательного прохождения различных уровней контекста ИИ. Переходя от нулевого контекста к полному контексту инфраструктуры (Gemini CLI + GKE MCP), вы увидите, насколько эффективнее становится ИИ-помощник, когда он видит ваши файлы и состояние кластера.

Краткое описание лабораторной работы

  • Контекст имеет значение: вы видите, как инструменты ИИ, не имеющие контекста, не могут помочь в решении конкретных проблем с кодом.
  • Контекст терминала: Вы используете Gemini CLI для анализа локальных файлов и выявления ошибок конфигурации непосредственно из вашей рабочей области.
  • Полноценная контекстная отладка: вы используете Gemini CLI с MCP, чтобы позволить ИИ диагностировать и исправлять сложные проблемы, сопоставляя файлы кодовой базы с текущим состоянием кластера.
  • Расширяемость: Вы узнаете о навыках и о том, как использовать их для систематизации организационных знаний.

Уборка

Чтобы предотвратить дальнейшие списания средств, запустите скрипт завершения работы. Обратите внимание, что этот шаг не требуется, если вы запускаете лабораторию на платформе Qwiklabs.

👉💻 Выполните следующую команду из каталога мастерской: 

cd ~/devrel-demos/codelabs/ai-toolkit-lab-1/
./teardown.sh

Следующие шаги

Вот несколько рекомендаций для дальнейшего чтения:

9. Приложение: Решение проблемы явных повреждений

Если у вас возникли проблемы или вы хотите проверить ошибки, вот список неполадок, возникших в каталоге manifests-broken/ и способы их устранения:

  1. Некорректные URL-адреса в config.yaml :
    • Ошибка: TRANSACTIONS_API_ADDR: "ledgerwriter::8080" (двойное двоеточие).
    • Причина: Приложение не может правильно обработать адрес, что приводит к ошибкам подключения.
    • Исправление: Верните значение "ledgerwriter:8080" .
  2. Несоответствие меток в contacts.yaml :
    • Ошибка: В селекторе сервиса установлено app: contacts-backend вместо contacts .
    • Причина: Сервис не может найти Pod-ы (у которых по-прежнему присутствует app: contacts ), поэтому трафик не будет маршрутизироваться.
    • Исправление: Измените селектор на app: contacts .
  3. Несоответствие портов в userservice.yaml :
    • Ошибка: targetPort службы установлен на 8081 вместо 8080 .
    • Причина: Трафик, отправляемый в сервис, будет перенаправлен на неправильный порт контейнера, что приведет к отказу в соединении.
    • Исправление: Измените targetPort обратно на 8080 .
  4. Несоответствие имен сервисов в config.yaml :
    • Ошибка: BALANCES_API_ADDR: "balance-reader:8080" (вместо balancereader ).
    • Причина: Имя хоста не разрешается в DNS, потому что служба называется balancereader .
    • Исправление: Верните значение "balancereader:8080" .
  5. Политика загрузки изображений в contacts.yaml :
    • Ошибка: imagePullPolicy: Never .
    • Причина: Kubernetes не сможет загрузить образ из реестра, предполагая, что он находится локально. Загрузка завершится ошибкой ErrImagePull .
    • Исправление: Удалите строку или установите значение IfNotPresent .
  6. Сбои при проверке готовности в userservice.yaml :
    • Ошибка: Путь изменен на /healthz вместо /ready .
    • Причина: Контейнер не обслуживает каталог /healthz , поэтому проверка завершается неудачей, и под никогда не помечается как готовый.
    • Исправление: Измените путь обратно на /ready .
  7. Ограничения на использование ресурсов в contacts.yaml :
    • Ошибка: лимит памяти установлен на 10Mi вместо 128Mi .
    • Причина: Приложению требуется больше памяти для запуска, из-за чего оно завершается с ошибкой OOMKilled.
    • Решение: Восстановить ограничение на использование памяти.
  8. Отсутствуют переменные окружения в frontend.yaml :
    • Ошибка: Удалена переменная среды REGISTERED_OAUTH_CLIENT_ID .
    • Причина: Приложение может дать сбой или отключить некоторые функции, если отсутствуют необходимые переменные среды.
    • Исправление: Восстановите определение переменной среды.
  9. Несоответствие ключей ConfigMap в frontend.yaml :
    • Ошибка: key: DEMO_USER вместо DEMO_LOGIN_USERNAME .
    • Причина: Kubernetes не может найти ключ в ConfigMap, из-за чего контейнер не запускается.
    • Исправление: Верните ключ к значению DEMO_LOGIN_USERNAME .
  10. Опечатка в названии изображения в файле userservice.yaml :
    • Ошибка: user-service вместо userservice .
    • Причина: Изображение отсутствует в реестре, что приводит к ImagePullBackOff .
    • Исправление: Исправить название изображения.
  11. Проблемы с учетными записями служб в contacts.yaml :
    • Ошибка: bank-of-anthos-sa вместо bank-of-anthos .
    • Причина: Учетная запись службы не существует или не имеет необходимых прав доступа.
    • Исправление: Используйте правильное имя учетной записи службы.