Использование rclone для копирования файлов в GCS бакет

Попробовал использовать rclone для переноса файлов из on-prem хостинга в облако Google. В отличии от утилит gcloud или gsutil, rclone есть в репозитарии Debian/Ubuntu и его легко поставить через APT.

Для переноса я не стал создавать user-managed ключ для IAM сервис аккаунта, вместо этого взял токен от виртуальной машины которая запущена с нужными правами в GCP.

$ curl -H 'Metadata-Flavor:Google' 169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token
{"access_token":"ya29.c.[redacted]_af","expires_in":3599,"token_type":"Bearer"}

Тут важно взять весь вывод целиком если задаётся параметр "token", либо только значение "access_token" для соответствующего параметра в rclone. В противном случае будет ошибка вида:

Failed to create file system for "gcs:example-files/": failed to configure Google Cloud Storage: google: could not find default credentials. See https://cloud.google.com/docs/authentication/external/set-up-adc for more information

Далее создание конфигурации для GCS (можно отвечать на вопросы в rclone config, но на всякий случай оставлю готовую конфигурацию для приватных бакетов с uniform access) и собственно сама миграция.

Диски в GCP заметно дороже

Давно не заглядывал в стоимость ресурсов Google Cloud Platform и сегодня удивился стоимости дисков в GCP. Для сравнения зональный диск на 100 GB в AWS и GCP:

• AWS: gp3, 100GB, 3000 IOPS, 125 MB/s - 8.00 USD в месяц (калькулятор)
• GCP: pd-balanced, 100GB, 600 IOPS чтение и 600 IOPS запись (6/GB), 28 MiB/s (0,28/GB) - 10 USD в месяц (документация, калькулятор)

Т.е. за большие деньги получаешь меньше производительности. Если пытаться подобрать аналогичную производительность диска, то это уже нужен pd-extreme где минимальный размер 500GB и стоимость больше 250 USD в месяц.

Ограничение доступа в контроллере ingress-nginx

Нередко возникает задача разрешить доступ к какому-либо приложению в Kubernetes кластере только для определённых подсетей. В случае с ingress-nginx (не путаем ingress-nginx и nginx-ingress) классический подход это использование аннотации nginx.ingress.kubernetes.io/whitelist-source-range

Например так

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: restricted-app
  annotations:
    nginx.ingress.kubernetes.io/whitelist-source-range: 192.168.0.0/16,172.16.0.0/12,10.0.0.0/8
spec:
  ingressClassName: nginx
  rules:
  - host: restricted-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app-service
            port:
              number: 3000

У этого подхода есть несколько недостатков:

• аннотации нужно обновить в каждом приложении когда изменится список разрешённых подсетей
• в ingress-nginx контроллере могут найти уязвимость которая позволит обойти ограничение доступа

Подключение к kubernetes кластерам в разных облаках

 Набросал себе инструкции для подключения к различным Kubernetes кластерам в GCP, AWS и Azure с установкой утилит для Debian 12.

GCP

Документация от GCP по установке google cloud sdk.

$ curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/cloud.google.gpg
$ cat <<_EOF_ | sudo tee /etc/apt/sources.list.d/google-cloud-sdk.list
deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main
_EOF_
$ sudo apt-get update
$ sudo apt-get install google-cloud-sdk google-cloud-sdk-gke-gcloud-auth-plugin
$ gcloud auth login
$ gcloud container clusters get-credentials <cluster> --region <region> --project <project>

Что нужно помнить про Cloud IAM и Kubernetes RBAC в GKE

Чтобы разграничить права пользователей по namespace нужно использовать Kubernetes RBAC, т.к. Cloud IAM не позволяет гранулярно задать привилегии внутри namespace. Сделал простую роль для namespace (Role/RoleBinding) и кластерную роль для просмотра namespace, storageclass и прочих ресурсов, которые не имееют привязки к namespace.

процессе отладки возникла проблема что пользователь, который должен видеть список namespace и оперировать ресурсами в пространстве имён "abc-dev", смог создать ресурс в пространстве имён "xyz-dev". Если проверять через kubectl auth can-i create secret --as user@example.com --namespace xyz-dev то возвращает false, но при этом ресурс создаётся.

Эмуляция Google Cloud Storage

Для тестирования Spark с хранилищем S3 мы используем MinIO. Это позволяет запускать тесты локально в Docker не имея доступа к реальной инфраструктуре. Недавно дошли до тестирования Spark с Google Cloud Storage и мне довелось разрабатывать аналогичный тест.

В году этак 2019, я искал способ эмулировать GCS для тестирования приложений, но тогда ничего работающего не нашлось.

Скачать объект из GCS бакета без gsutil

Чтобы скачать объект из Google Cloud Storage (GCS) бакета необязательно устанавливать google-cloud-sdk или даже gsutil. При условии что токен можно получить у metadata server, то достаточно curl и jq

Пример ниже скачивает gs://GCS_BUCKET_NAME/tests/data.zip

AUTH_TOKEN=$(curl -fsSH 'Metadata-Flavor:Google' http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token | jq -r .access_token)

curl -X GET -H "Authorization:Bearer ${AUTH_TOKEN}" -Lo /tmp/data.zip https://storage.googleapis.com/GCS_BUCKET_NAME/tests/data.zip

The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B53DC80D13EDEF05

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

Err:9 https://packages.cloud.google.com/apt cloud-sdk InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B53DC80D13EDEF05
Fetched 6,361 B in 1s (4,349 B/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
27 packages can be upgraded. Run 'apt list --upgradable' to see them.
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://packages.cloud.google.com/apt cloud-sdk InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B53DC80D13EDEF05
W: Failed to fetch https://packages.cloud.google.com/apt/dists/cloud-sdk/InRelease  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B53DC80D13EDEF05
W: Some index files failed to download. They have been ignored, or old ones used instead.

Судя по выводу GPG старый ключ (7F92E05B31093BEF5A3C2D38FEEA9169307EA071) истёк еще в начале марта

$ gpg /usr/share/keyrings/cloud.google.gpg
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
pub   rsa2048 2021-03-01 [SC] [expired: 2023-03-02]
      7F92E05B31093BEF5A3C2D38FEEA9169307EA071
uid           Rapture Automatic Signing Key (cloud-rapture-signing-key-2021-03-01-08_01_09.pub)
sub   rsa2048 2021-03-01 [E] [expired: never     ]
pub   rsa2048 2020-12-04 [SC] [expired: 2022-12-04]
      59FE0256827269DC81578F928B57C5C2836F4BEB
uid           gLinux Rapture Automatic Signing Key (//depot/google3/production/borg/cloud-rapture/keys/cloud-rapture-pubkeys/cloud-rapture-signing-key-2020-12-03-16_08_05.pub) <glinux-team@google.com>
sub   rsa2048 2020-12-04 [E] [expired: never     ]

GCloud prompt

Много работаю с GCP и зачастую приходится иметь дело с несколькими проектами одновременно и переключаться между ними в течении дня. Случаются досадные ситуации когда команда была выполнена не в том проекте или не в том GKE кластере. Последнее особенно коварно, т.к. в корпоративной среде обычно один и тот же пользователь имеет доступ в разные кластера в разных проектах и переключение профиля gcloud не влияет на kubectl.

Nginx запрашивает / вместо /.well-known/openid-configuration

Настраиваю workload identity federation между on-prem GitLab и GCP согласно документации. Сделал настройки в GCP, взял готовый пример пайплайна, но джоба падает с ошибкой

$ gcloud auth print-access-token
ERROR: (gcloud.auth.print-access-token) ("Error code invalid_grant: Parsing error for OIDC discovery document: [Line 0, column 0: Unexpected end of stream : expected '{']", '{"error":"invalid_grant","error_description":"Parsing error for OIDC discovery document: [Line 0, column 0: Unexpected end of stream : expected \'{\']"}')

Смотрю что выдаёт https://GITLAB/.well-known/openid-configuration и вижу 302 редирект на /users/sign_in - это неожиданное поведение. На этот запрос должно возвращать JSON вида

$ curl -s https://gitlab.com/.well-known/openid-configuration
{"issuer":"https://gitlab.com","authorization_endpoint":"https://gitlab.com/oauth/authorize","token_endpoint":"https://gitlab.com/oauth/token","revocation_endpoint":"https://gitlab.com/oauth/revoke","introspection_endpoint":"https://gitlab.com/oauth/introspect","userinfo_endpoint":"https://gitlab.com/oauth/userinfo","jwks_uri":"https://gitlab.com/oauth/discovery/keys","scopes_supported":["api","read_api","read_user","read_repository","write_repository","read_registry","write_registry","sudo","openid","profile","email"],"response_types_supported":["code"],"response_modes_supported":["query","fragment"],"grant_types_supported":["authorization_code","password","client_credentials","refresh_token"],"token_endpoint_auth_methods_supported":["client_secret_basic","client_secret_post"],"subject_types_supported":["public"],"id_token_signing_alg_values_supported":["RS256"],"claim_types_supported":["normal"],"claims_supported":["iss","sub","aud","exp","iat","sub_legacy","name","nickname","email","email_verified","website","profile","picture","groups","groups_direct","https://gitlab.org/claims/groups/owner","https://gitlab.org/claims/groups/maintainer","https://gitlab.org/claims/groups/developer"]}

Нужно разобраться откуда у меня берется этот редирект.

Spinnaker - день второй

Второй день изучения Spinnaker (почитать про первый день можно тут). На сегодня в планах построить минимальную инфраструктуру вокруг Spinnaker и задеплоить приложение в отдельный GKE кластер.

Spinnaker у меня крутится в VirtualBox, поэтому нужно создать ключ для IAM сервис аккаунта, который будет использоваться для доступа в GCS, GCR и Pub/Sub. Для подключения к GKE я сгенерировал отдельный kubeconfig.

При составлении пайплайна для Spinnaker я пользовался репозитарием spinnaker-for-gcp. Сам туториал у меня не завелся из-за недоступности управления IAM в Cloud Playground.

Подключение к Kafka в изолированном окружении

Есть изолированное от внешнего мира окружение в GCP с кластером Kafka, который живет в GKE. Kafka используется как внутри GKE кластера, так и виртуальными машинами, которым Kafka выставлена через внутренний балансировщик. Часть пользователей не приемлют использование консольных команд чтобы подключиться к Kafka и хотят пользоваться привычными им инструментами вроде Offset Explorer и ему подобными.

Итого у нас есть три брокера Kafka, которые доступны внутри кластера как kafka-0.kafka-headless.default.svc.cluster.local:9092, kafka-1.kafka-headless.default.svc.cluster.local:9092 и kafka-2.kafka-headless.default.svc.cluster.local:9092. Для виртуальных машин создано три балансировщика с адресами 172.16.0.16:19092, 172.16.0.17:19092 и 172.16.0.18:19092.

Если просто пробросить порты на локальную машину, то ничего работать не будет, т.к. после подключения к Kafka брокеру клиент получит метаданные в которых будет фигурировать Kafka advertised listeners и клиент будет пытаться подключиться к ним вместо работы с проброшенными портами.

Первые впечатления от Backup for GKE

В рамках ликбеза потрогал немного Backup for GKE чтобы понять чем он отличается от привычного Velero. На данный момент времени он в preview и часть выводов может стать неактуальными в будущем.

Первое что бросается в глаза это его ценообразование - оно зависит не только от объема данных, которые попадают в бэкап, но и от количества подов, которые бэкапятся. Т.е. если у вас условно в среднем 30 подов в месяц, то вам нужно заплатить около 30$ за backup management, плюс стоимость хранения данных. В этом плане Velero выигрывает, т.к. там в основном стоимость только за хранение данных.

Далее его региональная доступность - сейчас он поддерживается только в некоторых регионах, но при этом создать бэкапить дает кластера и в неподдерживаемых регионах. Но вот восстановить бэкап в тот же кластер уже не получится - обязательно проверяйте список поддерживаемых регионов через gcloud beta container backup-restore locations list.

Сравнение gcloud storage и gsutil

Недавно команда gcloud storage вышла в GA и я решил проверить насколько ее производительность отличается от gsutil. Для тестов нашелся GCS бакет с примерно 21k мелких объектов (средний размер 24kB), которые сжаты gzip.

Запускать тесты буду в e2-standard-2 VM (2 vCPU / 8 GB). Текущая версия Google SDK:

$ gcloud version
Google Cloud SDK 403.0.0
alpha 2022.09.20
beta 2022.09.20
bq 2.0.77
bundled-python3-unix 3.9.12
core 2022.09.20
gcloud-crc32c 1.0.0
gsutil 5.13

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

$ sudo mkdir /mnt/ramdisk
$ sudo mount -t ramfs none /mnt/ramdisk
$ sudo chmod 777 /mnt/ramdisk
$ cd /mnt/ramdisk
$ mkdir test1 test2

Копирование данных через gcloud storage cp

$ cd /mnt/ramdisk/test1/
$ time gcloud storage cp -r gs://BUCKET/SAMPLE/DATA/* .

[skipped output]

  Completed files 21000/21000 | 448.9MiB/448.9MiB | 1.5MiB/s

Average throughput: 1.5MiB/s

real    4m54.065s
user    9m4.797s
sys     0m30.854s

Копирование данных через gsutil cp (используется многопоточность)

$ cd /mnt/ramdisk/test2/
$ time gsutil -m cp -r gs://BUCKET/SAMPLE/DATA/* .

[skipped output]

Operation completed over 21.0k objects/448.9 MiB.

real    5m58.861s
user    10m8.143s
sys     1m18.350s

В моем тесте копирование мелких объектов c использованием gcloud storage быстрее gsutil примерно на 18%. Пока что gcloud storage не заменит полностью gsutil, но для простых операций стоит использовать её.

Настройка Google Cloud Ops Agent для Nextcloud

В процессе настройки отправки логов Nextcloud в Google Cloud Logging довелось поработать с Google Cloud Ops Agent. Это относительно новый агент, который отвечает и за логи и за метрики.

Nextcloud пишет структурированные логи в JSON формате так что возиться с регулярками не придется. Одна запись выглядит примерно так:

{
  "reqId": "fA6aIAL7fObKyDA2YeDq",
  "level": 2,
  "time": "2022-06-21T06:55:18+00:00",
  "remoteAddr": "",
  "user": "--",
  "app": "news",
  "method": "",
  "url": "--",
  "message": "https://[skipped]/data/rss read error : Server error: `GET https://[skipped]/data/rss` resulted in a `500 Internal Server Error` response:\n<html>\r\n<head><title>500 Internal Server Error</title></head>\r\n<body bgcolor=\"white\">\r\n<center><h1>500 Internal Server E (truncated...)\n",
  "userAgent": "--",
  "version": "23.0.5.1"
}

Для начала нужно вытащить timestamp и severity. Timestamp буду брать из поля time, а severity из поля level, но для level потребуется преобразование из значения Nextcloud в значение Google LogEntry:

SSH логин в GCP VM по паролю

Чтобы зайти на виртуальную машину через SSH в GCP удобно использовать команду gcloud compute ssh, но по умолчанию используются ключи, которые добавляются на уровень проекта, либо в саму виртуальную машину. Чтобы зайти с авторизацией по паролю нужно указать опцию --plain

$ gcloud compute ssh <instance> --plain --project <gcp-project> --zone <gcp-zone>

Такой подход удобен когда у виртуальных машин нет публичных IP адресов и можно подключаться используя Identity Aware Proxy (IAP) без промежуточных решений вроде AWS Workspace, bastion host или VPN.

Как скачать лог Stackdriver

Журналирование в GCP реализовано через Stackdriver Logging. На прошлой неделе пришлось обратиться в техническую поддержку Google по поводу поломанной работы с зависимостями в AI Platform (ML Engine). Для тикета нужно было скачать логи заданий с ошибкой и без нее. Если пытаться выгружать логи через консоль GCP, то сохранит только ту часть, который видна в данный момент в интерфейсе (в моем случае это малая часть от полного лога).

Чтобы выгрузить весь лог целиком воспользуемся консольной командой gcloud logging read. В моем случае для успешной задачи ML Engine фильтр будет resource.labels.job_id="some_successful_ml_job" timestamp>="2020-01-27T14:28:43Z" а для задания с ошибкой: resource.labels.job_id="some_failed_ml_job" timestamp>="2020-01-30T13:42:58Z" (чтобы использовать этот запрос в команде нужно экранировать двойную кавычку).

gcloud logging read "resource.labels.job_id=\"some_successful_ml_job\" timestamp>=\"2020-01-27T14:28:43Z\"" --format=json --order=asc > success.json
gcloud logging read "resource.labels.job_id=\"some_failed_ml_job\" timestamp>=\"2020-01-30T13:42:58Z\"" --format=json --order=asc > failure.json

Для удобства чтения я извлекаю из JSON только сам текст сообщения (узнать больше о фильтрации в jq можно тут).

jq -r .[].jsonPayload.message < success.json > success.txt
jq -r .[].jsonPayload.message < failure.json > failure.txt

Ошибка при создании Cloud Functions через Terraform

При очередном тестировании конфигурации Terraform выдал ошибку при создании Cloud Functions в GCP: googleapi: Error 403: Your application has authenticated using end user credentials from the Google Cloud SDK or Google Cloud Shell which are not supported by the cloudfunctions.googleapis.com. We recommend that most server applications use service accounts instead. For more information about service accounts and how to use them in your application, see https://cloud.google.com/docs/authentication/.

Для работы с Terraform я использую авторизацию приложения с правами пользователя (application default credentials). Это продиктовано требованиями безопасности, да и в целом это имеет смысл т.к. приложение выполняет изменения в GCP от моего имени. Если использовать сервис аккаунт, то все работает без проблем, но тогда либо нужно создавать по отдельному сервис аккаунту на каждого пользователя, либо смириться с проблемами аудита.

Неслабо лихорадит GCP

Больше суток длится инцидент, связанный с Compute Engine в облаке Google. Из-за него деградировали многие сервисы.

Судя по описанию "застряли" операции по созданию/удалению сетей и подсетей. Если инфраструктура статичная, то по-идее зацепить не должно.

Текущий статус можно увидеть на странице Google Cloud Status Dashboard.

Еще три сертификата по Google Cloud Platform

В сентябре ездил в Киев чтобы пройти дополнительную сертификацию по Google Cloud Platform.

Годом ранее я получил сертификат Professional Cloud Architect, а в этом году я сдавал сразу три экзамена:

• Associate Cloud Engineer
• Professional Network Engineer
• Professional Security Engineer

Самым сложным для меня оказался Network. Security был средней сложности - достаточно разобраться в Cloud Identity и Cloud KMS.

Cloud Engineer многие считают слишком простым и я планировал сдать его "на сдачу" от Cloud Architect, но этот экзамен оказался очень и очень практическим. Если не нет опыта работы с утилитами gcloud, gsutil, kubectl и GCP Console, то сдать будет непросто.

Подготовка к экзаменам заняла примерно полтора месяца по вечерам. В итоге сдал все экзамены с первой попытки.

В этом году Google запустил публичный каталог сертификатов по GCP. Можно посмотреть у кого какие есть сертификаты.