Эта страница переведена с помощью Cloud Translation API.

События для Cloud Run для Anthos Codelab

1. Введение

Cloud Run позволяет запускать контейнеры без сохранения состояния в полностью управляемой среде. Он построен на основе открытого исходного кода Knative , что позволяет вам выбирать между запуском контейнеров либо в полностью управляемой среде с помощью Cloud Run, либо в кластере Google Kubernetes Engine с помощью Cloud Run for Anthos .

Events for Cloud Run for Anthos упрощает подключение сервисов Cloud Run к событиям из различных источников. Он позволяет создавать архитектуры, управляемые событиями, в которых микросервисы слабо связаны и распределены. Он также берет на себя обработку событий, их доставку, обеспечение безопасности, авторизацию и обработку ошибок, что повышает гибкость разработчиков и отказоустойчивость приложений.

В этом практическом занятии вы узнаете о событиях для Cloud Run в Anthos. В частности, вы научитесь отслеживать события из Cloud Pub/Sub, журналов аудита, Cloud Storage, Cloud Scheduler, а также создавать и обрабатывать пользовательские события.

Что вы узнаете

Долгосрочная перспектива мероприятий Cloud Run для Anthos
Текущее состояние событий в рамках Cloud Run для Anthos
Создайте приемник Cloud Run.
Создайте триггер события для Cloud Pub/Sub.
Создайте триггер события для журналов аудита.
Создайте триггер события для облачного хранилища.
Создайте триггер события для планировщика облачных задач.
Создание и использование пользовательских событий

2. Долгосрочная перспектива

По мере внедрения бессерверной архитектуры события становятся неотъемлемой частью взаимодействия децентрализованных микросервисов. Events for Cloud Run for Anthos делает события полноправным элементом предложения Cloud Run for Anthos, что упрощает создание бессерверных приложений, управляемых событиями.

Events for Cloud Run for Anthos обеспечивает надежную, безопасную и масштабируемую асинхронную доставку событий из упакованных или созданных приложениями источников событий потребителям внутри кластера и за его пределами.

Источники Google Cloud	Источники событий, являющиеся продуктами, принадлежащими Google Cloud.
Источники Google	Источники событий, являющиеся продуктами Google, такими как Gmail, Hangouts, Android Management и другие.
Пользовательские источники	Источники событий, не являющиеся продуктами Google и созданные самими конечными пользователями. Это могут быть разработанные пользователями источники Knative или любое другое приложение, работающее в кластере и способное генерировать облачные события.
сторонние источники	Источники событий, которые не принадлежат ни Google, ни конечным пользователям. Сюда входят популярные источники событий, такие как Github, SAP, Datadog, Pagerduty и т. д., которые принадлежат и поддерживаются сторонними поставщиками, партнерами или сообществами с открытым исходным кодом.

События нормализуются в соответствии с форматом CloudEvents v1.0 для обеспечения совместимости между различными сервисами. CloudEvents — это независимая от поставщиков открытая спецификация, описывающая данные событий в общих форматах, что обеспечивает совместимость между сервисами, платформами и системами.

Events for Cloud Run соответствует стандарту Knative Eventing и обеспечивает переносимость контейнеров между другими реализациями на основе Knative. Это предоставляет согласованную, независимую от облачной среды структуру для декларативного связывания производителей событий с потребителями событий.

3. Текущее состояние

Эта предварительная версия — первая, которая предоставляет начальный набор долгосрочных функций.

Чтобы дать пользователям возможность создавать бессерверные приложения, управляемые событиями, мы изначально сосредоточимся на двух аспектах:

Предоставить широкую экосистему источников Google Cloud, которая позволит сервисам Cloud Run в кластере Anthos реагировать на события от сервисов Google Cloud.

Изначально события из источников Google Cloud доставляются через журналы аудита Cloud Audit Logs (CAL), что позволяет использовать широкий спектр источников событий. Задержка и доступность доставки событий из этих источников связаны с аналогичными параметрами журналов аудита Cloud Audit Logs. При каждой публикации события из источника Google Cloud создается соответствующая запись в журнале аудита Cloud Audit Log.
Наряду с журналами аудита Cloud Audit Logs, обеспечивается первоклассная поддержка получения событий из Cloud Storage, Cloud Pub/Sub и Cloud Scheduler. Мы будем продолжать расширять эту экосистему источников, добавляя новые первоклассные ресурсы по мере того, как будем получать больше информации из пользовательского опыта и отзывов.

Предоставьте приложениям и службам конечных пользователей возможность генерировать пользовательские события путем публикации их по локальному URL-адресу брокера в пределах кластера, ограниченному пространством имен.

В основе механизма доставки лежат темы и подписки Cloud Pub/Sub, которые видны в проектах клиентов. Таким образом, эта функция обеспечивает те же гарантии доставки, что и Cloud Pub/Sub.

Триггер событий предоставляет способ подписки на события, чтобы события, соответствующие фильтру триггера, доставлялись в пункт назначения (или приемник), на который указывает триггер.

Все события передаются в формате Cloud Events v1.0 для обеспечения совместимости между различными сервисами.

Мы будем итеративно повышать ценность продукта на протяжении всего процесса, вплоть до выхода в общий доступ и после него.

4. Настройка и требования

Настройка среды для самостоятельного обучения

Войдите в Cloud Console и создайте новый проект или используйте существующий. Если у вас еще нет учетной записи Gmail или Google Workspace, вам необходимо ее создать .

Название проекта — это отображаемое имя для данного проекта. Если вы будете следовать принятым правилам именования, вы можете использовать любое имя по своему усмотрению и изменять его в любое время.
Идентификатор проекта должен быть уникальным для всех проектов Google Cloud и неизменяемым (его нельзя изменить после установки). Консоль Cloud автоматически генерирует уникальную строку; обычно вам неважно, какая она. В большинстве практических заданий вам потребуется указать идентификатор проекта (обычно он обозначается как PROJECT_ID ), поэтому, если он вам не нравится, сгенерируйте другой случайный идентификатор или попробуйте свой собственный и посмотрите, доступен ли он. Затем он "замораживается" после создания проекта.

Далее вам потребуется включить оплату в Cloud Console, чтобы использовать ресурсы Google Cloud.

Выполнение этого практического задания не должно стоить дорого, если вообще что-либо. Обязательно следуйте инструкциям в разделе «Очистка», где указано, как отключить ресурсы, чтобы избежать дополнительных расходов после завершения этого урока. Новые пользователи Google Cloud имеют право на бесплатную пробную версию стоимостью 300 долларов США .

Запустить Cloud Shell

Хотя Google Cloud можно управлять удаленно с ноутбука, в этом практическом занятии вы будете использовать Google Cloud Shell — среду командной строки, работающую в облаке.

В консоли GCP щелкните значок Cloud Shell на панели инструментов в правом верхнем углу:

Подготовка и подключение к среде займут всего несколько минут. После завершения вы должны увидеть что-то подобное:

Эта виртуальная машина оснащена всеми необходимыми инструментами разработки. Она предоставляет постоянный домашний каталог размером 5 ГБ и работает в облаке Google, что значительно повышает производительность сети и аутентификацию. Всю работу в этой лаборатории можно выполнять с помощью обычного браузера.

5. Включите API, установите зону и платформу.

Настройте идентификатор проекта и установите альфа-компоненты.

В Cloud Shell параметр GOOGLE_CLOUD_PROJECT должен быть уже установлен на идентификатор вашего проекта. Если это не так, убедитесь, что он установлен и ваш gcloud настроен с этим идентификатором проекта:

export GOOGLE_CLOUD_PROJECT=your-project-id
gcloud config set project ${GOOGLE_CLOUD_PROJECT}

Убедитесь, что компонент gcloud для alpha установлен:

gcloud components install alpha

Включить API

Включите все необходимые службы:

gcloud services enable cloudapis.googleapis.com 
gcloud services enable container.googleapis.com 
gcloud services enable containerregistry.googleapis.com
gcloud services enable cloudbuild.googleapis.com

Установить зону и платформу

Перед созданием кластера GKE с использованием Cloud Run Events необходимо задать имя кластера, зону и платформу. Например, здесь мы задаем имя и зону как events-cluster и europe-west1-b , а платформу — gke,

В Cloud Shell:

export CLUSTER_NAME=events-cluster
export CLUSTER_ZONE=europe-west1-b

gcloud config set run/cluster ${CLUSTER_NAME}
gcloud config set run/cluster_location ${CLUSTER_ZONE}
gcloud config set run/platform gke

Вы можете проверить, что конфигурация настроена:

gcloud config list

...
[run]
cluster = events-cluster
cluster_location = europe-west1-b
platform = gke

6. Создайте кластер GKE с использованием Cloud Run Events.

Создайте кластер GKE с установленным Kubernetes >= 1.15.9-gke.26 и включите следующие дополнения: CloudRun , HttpLoadBalancing , HorizontalPodAutoscaling :

gcloud beta container clusters create ${CLUSTER_NAME} \
  --addons=HttpLoadBalancing,HorizontalPodAutoscaling,CloudRun \
  --machine-type=n1-standard-4 \
  --enable-autoscaling --min-nodes=3 --max-nodes=10 \
  --no-issue-client-certificate --num-nodes=3 --image-type=cos \
  --enable-stackdriver-kubernetes \
  --scopes=cloud-platform,logging-write,monitoring-write,pubsub \
  --zone ${CLUSTER_ZONE} \
  --release-channel=rapid

7. Настройка событий Cloud Run (управляющая плоскость)

В Cloud Run Events есть плоскость управления и плоскость данных, которые необходимо настраивать отдельно. Для настройки плоскости управления:

В Cloud Shell:

gcloud beta events init

Это инициализирует обработку событий, а также создаст необходимое количество учетных записей служб. Убедитесь, что вы выбрали «Да» при запросе на создание учетных записей служб.

На этом этапе плоскость управления должна быть корректно инициализирована. Вы должны увидеть четыре модуля с...

Статус Running : 2 ( controller-xxx-xxx и webhook-xxx-xxx ) в пространстве имен cloud-run-events и 2 ( eventing-controller-xxx-xxx и eventing-webhook-xxx-xxx ) в пространстве имен knative-eventing . Проверить это можно, выполнив следующие команды:

kubectl get pods -n cloud-run-events

NAME                         READY   STATUS    RESTARTS   AGE
controller-9cc679b67-2952n   1/1     Running   0          22s
webhook-8576c4cfcb-dhz82     1/1     Running   0          16m

kubectl get pods -n knative-eventing

NAME                                   READY   STATUS    RESTARTS   AGE
eventing-controller-77f46f6cf8-kj9ck   1/1     Running   0          17m
eventing-webhook-5bc787965f-hcmwg      1/1     Running   0          17m

8. Настройка событий запуска в облаке (плоскость данных)

Далее необходимо настроить плоскость данных в пространствах имен пользователей. Это создаст брокера с соответствующими правами доступа на чтение/запись в/из Pub/Sub.

В Cloud Shell установите переменную среды NAMESPACE для пространства имен, которое вы хотите использовать для своих объектов. Вы можете установить значение по default , если хотите использовать пространство имен по умолчанию, как показано ниже:

export NAMESPACE=default

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

kubectl create namespace ${NAMESPACE}

Инициализируйте пространство имен секретным ключом по умолчанию:

gcloud beta events namespaces init ${NAMESPACE} --copy-default-secret

Создайте брокер по умолчанию в пространстве имен:

gcloud beta events brokers create default --namespace ${NAMESPACE}

Убедитесь, что брокер создан. Обратите внимание, что для готовности брокера может потребоваться несколько секунд:

kubectl get broker -n ${NAMESPACE}

NAME      READY   REASON   URL
default   True             http://default-brokercell-ingress.cloud-run-events.svc.cluster.local/default/default

9. Обнаружение событий

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

Чтобы посмотреть список различных типов мероприятий:

gcloud beta events types list

Для получения более подробной информации о каждом типе событий:

gcloud beta events types describe google.cloud.pubsub.topic.v1.messagePublished

10. Создайте облачный приемник выполнения (Cloud Run Sink).

В качестве приемника событий разверните службу Cloud Run, которая будет регистрировать содержимое получаемого ею события CloudEvent.

Вы можете использовать уже скомпилированный компонент event_display из Knative и его образ контейнера, собранный в рамках релиза Knative. Подробную информацию об образе контейнера можно найти в файле event-display.yaml :

...
containers:
  - image: gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display@sha256:8da2440b62a5c077d9882ed50397730e84d07037b1c8a3e40ff6b89c37332b27

Развертывание в облаке. Запуск.

Разверните ваше контейнеризированное приложение в Cloud Run:

export SERVICE_NAME=event-display
gcloud run deploy ${SERVICE_NAME} \
  --namespace=${NAMESPACE} \
  --image gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display@sha256:8da2440b62a5c077d9882ed50397730e84d07037b1c8a3e40ff6b89c37332b27

В случае успеха в командной строке отобразится URL-адрес сервиса. Теперь вы можете получить доступ к развернутому контейнеру, открыв URL-адрес сервиса в любом окне браузера.

11. Создайте триггер события для Cloud Pub/Sub.

Один из способов получения событий — использование Cloud Pub/Sub. Пользовательские приложения могут публиковать сообщения в Cloud Pub/Sub, и эти сообщения могут доставляться в обработчики событий Google Cloud Run через Events for Cloud Run.

Создать тему

Сначала создайте тему Cloud Pub/Sub. Вы можете заменить TOPIC_ID на уникальное имя темы по вашему выбору:

export TOPIC_ID=cr-gke-topic
gcloud pubsub topics create ${TOPIC_ID}

Создайте триггер

Прежде чем создавать триггер, получите более подробную информацию о параметрах, необходимых для его настройки для обработки событий из Cloud Pub/Sub:

gcloud beta events types describe google.cloud.pubsub.topic.v1.messagePublished

Создайте триггер для фильтрации событий, публикуемых в тему Cloud Pub/Sub, и перенаправляйте их в развернутый сервис Cloud Run:

gcloud beta events triggers create trigger-pubsub \
  --namespace ${NAMESPACE} \
  --target-service ${SERVICE_NAME} \
  --type google.cloud.pubsub.topic.v1.messagePublished \
  --parameters topic=${TOPIC_ID}

Проверьте спусковой крючок

Проверить создание триггера можно, перечислив все триггеры:

gcloud beta events triggers list

Возможно, вам придётся подождать до 10 минут, пока информация о создании триггера распространится и начнётся фильтрация событий.

Для имитации отправки сообщения пользовательским приложением можно использовать gcloud для запуска события:

gcloud pubsub topics publish ${TOPIC_ID} --message="Hello there"

Созданный нами приемник Cloud Run записывает в лог тело входящего сообщения. Вы можете просмотреть его в разделе «Журналы» вашего экземпляра Cloud Run:

Обратите внимание, что сообщение "Hello there" будет закодировано в формате base64, как оно было отправлено через Pub/Sub, и вам придется декодировать его, если вы хотите увидеть исходное отправленное сообщение.

Удалите триггер

При желании, после завершения тестирования вы можете удалить триггер.

gcloud beta events triggers delete trigger-pubsub --namespace ${NAMESPACE}

12. Создайте триггер события для журналов аудита.

Вам потребуется настроить триггер для отслеживания событий из журналов аудита. В частности, вы будете искать в журналах аудита события создания тем Pub/Sub.

Включить журналы аудита

Для получения событий от сервиса необходимо включить журналы аудита. В консоли Cloud Console выберите IAM & Admin > Audit Logs в верхнем левом меню. В списке сервисов отметьте Google Cloud Pub/Sub:

В правой части экрана убедитесь, что выбраны параметры «Администратор», «Чтение» и «Запись». Нажмите «Сохранить».

Журналы аудита тестирования

Чтобы научиться определять параметры, необходимые для настройки реального триггера, выполните реальную операцию.

Например, создайте тему Pub/Sub:

gcloud pubsub topics create cre-gke-topic1

Теперь давайте посмотрим, какой журнал аудита был сгенерирован этим обновлением. В консоли Cloud выберите Logging > Logs Viewer в меню в левом верхнем углу.

В разделе Query Builder, выберите Cloud Pub/Sub Topic и нажмите Add :

После выполнения запроса вы увидите логи для тем Pub/Sub, и одна из них должна быть google.pubsub.v1.Publisher.CreateTopic :

Обратите внимание на serviceName , methodName и resourceName . Мы будем использовать их при создании триггера.

Создайте триггер

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

Более подробную информацию о параметрах, необходимых для создания триггера для событий из источников Google Cloud, можно получить, выполнив следующую команду:

gcloud beta events types describe google.cloud.audit.log.v1.written

Создайте триггер с соответствующими фильтрами:

gcloud beta events triggers create trigger-auditlog \
  --namespace ${NAMESPACE} \
  --target-service ${SERVICE_NAME} \
  --type=google.cloud.audit.log.v1.written \
  --parameters serviceName=pubsub.googleapis.com \
  --parameters methodName=google.pubsub.v1.Publisher.CreateTopic

Проверьте спусковой крючок

Чтобы подтвердить успешное создание триггера, перечислите все триггеры:

gcloud beta events triggers list

Подождите до 10 минут, пока информация о создании триггера распространится и начнется фильтрация событий. Как только все будет готово, система отфильтрует события создания и отправит их в сервис. Теперь вы готовы отправить событие.

Создайте еще одну тему Pub/Sub, как вы делали ранее:

gcloud pubsub topics create cre-gke-topic2

Если вы проверите журналы службы Cloud Run в Cloud Console, вы должны увидеть полученное событие:

Удалите триггер и темы.

При желании, после завершения тестирования вы можете удалить триггер:

gcloud beta events triggers delete trigger-auditlog

Также удалите следующие темы:

gcloud pubsub topics delete cre-gke-topic1 cre-gke-topic2

13. Создайте триггер события для облачного хранилища.

Вам потребуется настроить триггер для отслеживания событий из облачного хранилища.

Создайте корзину

Сначала создайте сегмент Cloud Storage в том же регионе, что и развернутая служба Cloud Run. Вы можете заменить BUCKET_NAME на уникальное имя по вашему выбору:

export BUCKET_NAME=[new bucket name]
export REGION=europe-west1

gsutil mb -p $(gcloud config get-value project) \
  -l $REGION \
  gs://$BUCKET_NAME/

Настройка разрешений для облачного хранилища

Перед созданием триггера необходимо предоставить учетной записи службы Cloud Storage по умолчанию разрешение на публикацию в Pub/Sub.

Для начала вам нужно найти учетную запись службы, которую Cloud Storage использует для публикации в Pub/Sub. Вы можете использовать шаги, описанные в разделе «Получение учетной записи службы Cloud Storage» , чтобы получить учетную запись службы, или использовать следующую команду:

curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://storage.googleapis.com/storage/v1/projects/$(gcloud config get-value project)/serviceAccount"

Учетная запись службы должна быть указана в поле email_address .

Предположим, что найденная вами выше учетная запись службы — service-XYZ@gs-project-accounts.iam.gserviceaccount.com . Установите для нее значение переменной среды:

export GCS_SERVICE_ACCOUNT=service-XYZ@gs-project-accounts.iam.gserviceaccount.com

Затем предоставьте этой учетной записи службы права на публикацию в Pub/Sub:

gcloud projects add-iam-policy-binding ${GOOGLE_CLOUD_PROJECT} \
  --member=serviceAccount:${GCS_SERVICE_ACCOUNT} \
  --role roles/pubsub.publisher

Создайте триггер

Теперь вы готовы создать триггер событий для событий Cloud Storage.

Более подробную информацию о параметрах, необходимых для создания триггера, можно получить здесь:

gcloud beta events types describe google.cloud.storage.object.v1.finalized

Создайте триггер с соответствующими фильтрами:

gcloud beta events triggers create trigger-storage \
  --namespace ${NAMESPACE} \
  --target-service ${SERVICE_NAME} \
  --type=google.cloud.storage.object.v1.finalized \
  --parameters bucket=${BUCKET_NAME}

Проверьте спусковой крючок

Чтобы подтвердить успешное создание триггера, перечислите все триггеры:

gcloud beta events triggers list

Подождите до 10 минут, пока завершится обработка событий создания триггера и начнется фильтрация событий. После завершения фильтрации события создания будут отправлены в сервис.

Теперь вы готовы инициировать событие.

Загрузите случайный файл в хранилище Cloud Storage:

echo "Hello World" > random.txt
gsutil cp random.txt gs://${BUCKET_NAME}/random.txt

Если вы проверите журналы службы Cloud Run в Cloud Console, вы должны увидеть полученное событие:

Удалите триггер

При желании, после завершения тестирования вы можете удалить триггер:

gcloud beta events triggers delete trigger-storage

14. Создайте триггер события для планировщика облачных задач.

Вам потребуется настроить триггер для отслеживания событий от Cloud Scheduler.

Создайте приложение на платформе App Engine.

В настоящее время Cloud Scheduler требует от пользователей создания приложения App Engine. Выберите местоположение App Engine и создайте приложение:

export APP_ENGINE_LOCATION=europe-west
gcloud app create --region=${APP_ENGINE_LOCATION}

Создайте триггер

gcloud beta events types describe google.cloud.scheduler.job.v1.executed

Выберите местоположение Cloud Scheduler для создания планировщика:

export SCHEDULER_LOCATION=europe-west1

Создайте триггер, который будет создавать задание, выполняемое каждую минуту в Google Cloud Scheduler, и вызывать целевой сервис:

gcloud beta events triggers create trigger-scheduler \
  --namespace ${NAMESPACE} \
  --target-service=${SERVICE_NAME} \
  --type=google.cloud.scheduler.job.v1.executed \
  --parameters location=${SCHEDULER_LOCATION} \
  --parameters schedule="* * * * *" \
  --parameters data="trigger-scheduler-data"

Проверьте спусковой крючок

Чтобы подтвердить успешное создание триггера, перечислите все триггеры:

gcloud beta events triggers list

Если вы проверите журналы службы Cloud Run в Cloud Console, вы должны увидеть полученное событие.

Удалите триггер

При желании, после завершения тестирования вы можете удалить триггер:

gcloud beta events triggers delete trigger-scheduler

15. Пользовательские события (конечная точка брокера)

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

Создайте модуль Curl для генерации событий.

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

Чтобы создать Pod, который будет выступать в роли производителя событий, выполните следующую команду:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: curl
  name: curl
  namespace: $NAMESPACE
spec:
  containers:
  - image: radial/busyboxplus:curl
    imagePullPolicy: IfNotPresent
    name: curl
    resources: {}
    stdin: true
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    tty: true
EOF

Убедитесь, что под curl работает корректно. Вы должны увидеть под с именем curl и Status=Running :

kubectl get pod curl -n ${NAMESPACE}

Создайте триггер

Вам потребуется создать триггер с фильтром по конкретному типу CloudEvents (в данном случае alpha-type ), который вы будете генерировать. Обратите внимание, что поддерживается фильтрация по точному совпадению для любого количества атрибутов CloudEvents, а также расширений . Если ваш фильтр задает несколько атрибутов, событие должно содержать все эти атрибуты, чтобы триггер мог его отфильтровать. И наоборот, если вы не укажете фильтр, все события будут получены вашим сервисом.

Создайте триггер:

gcloud beta events triggers create trigger-custom \
  --namespace ${NAMESPACE} \
  --target-service ${SERVICE_NAME} \
  --type=alpha-type \
  --custom-type

Проверьте спусковой крючок

Чтобы подтвердить успешное создание триггера, перечислите все триггеры:

gcloud beta events triggers list

Создайте событие, отправив HTTP-запрос брокеру. Чтобы не забыть URL-адрес брокера, выполните следующую команду:

kubectl get brokers -n ${NAMESPACE}

NAME      READY   REASON   URL
default   True             http://default-broker.<NAMESPACE>.svc.cluster.local

Подключитесь по SSH к созданному ранее pod-у curl :

kubectl --namespace ${NAMESPACE} attach curl -it

Вы подключились к поду по SSH и теперь можете отправлять HTTP-запросы. Появится приглашение, похожее на приведенное ниже:

Defaulting container name to curl.
Use 'kubectl describe pod/curl -n default' to see all of the containers in this pod.
If you don't see a command prompt, try pressing enter.
[ root@curl:/ ]$

Создать событие:

curl -v "<BROKER-URL>" \
-X POST \
-H "Ce-Id: my-id" \
-H "Ce-Specversion: 1.0" \
-H "Ce-Type: alpha-type" \
-H "Ce-Source: my-source" \
-H "Content-Type: application/json" \
-d '{"msg":"send-cloudevents-to-broker"}'

Если событие получено, вы получите ответ HTTP 202 Accepted . Завершите сеанс SSH с помощью Ctrl + D

Убедитесь, что опубликованное событие было отправлено, просмотрев журналы службы Cloud Run:

kubectl logs --selector serving.knative.dev/service=$SERVICE_NAME \
 -c user-container -n $NAMESPACE --tail=100

Удалите триггер

При желании, после завершения тестирования вы можете удалить триггер:

gcloud beta events triggers delete trigger-custom

16. Поздравляем!

Поздравляем с завершением практического занятия!

Что мы рассмотрели

Долгосрочная перспектива мероприятий Cloud Run для Anthos
Текущее состояние событий в рамках Cloud Run для Anthos
Создайте приемник Cloud Run.
Создайте триггер события для Cloud Pub/Sub.
Создайте триггер события для журналов аудита.
Создайте триггер события для облачного хранилища.
Создайте триггер события для планировщика облачных задач.
Создание и использование пользовательских событий