Pro'двинутый Finch

Злостный перфикционист внутри меня каждый раз склоняется к реализации лучших практик (best practices) в работе. К счастью, это не клинический случай, поэтому экстраполяция за пределы рабочего процесса происходит крайне редко. Я просто люблю, когда специалист (specialist) (неважно, в какой сфере) делает свою работу хорошо!

Это я к тому, что отдельно стоящий в нашем кластере (cluster) Kubernetes сервис (service) Cloud SQL proxy меня жутко раздражал. Мы его держали лишь потому, что повторяющиеся по расписанию задачи (Cron Jobs) приложения (application) должны были иметь возможность соединяться с базой данный (database) в Google Cloud SQL и завершаться без ошибок, то есть по красоте (graceful).

Рекомендации Google только усугубляли внутреннее недовольство по этому поводу. Именно поэтому моему счастью не было предела, когда я обнаружил в репозитории (repository) cloud-sql-proxy релиз (release) от 16 февраля 2023 года v2.1.0 с поддержкой фичи (feature) quitquitquit endpoint.

Для начала, давайте подсветим понятие сайдкар (sidecar) в контексте Kubernbetes, а не из коктейльной карты, как вы могли подумать (коктейль Сайдкар) 🙃

Sidecar — это контейнер (container) в пределах одного пода (pod), который позволяет расширить или улучшить функциональность основного приложения (application) без внесения в него изменений. Мой любимый пример это init-контейнеры (init containers) — почитайте, если не знаете о них.

Согласно документации README в репозитории cloud-sql-proxy нам необходимо добавть в аргументы (args) флаг (flag) --quitquitquit, чтобы активировать сервер (admin server) внутри контейнера (container) локального хоста (localhost) по порту (port) 9091. По умолчанию (by default) сервер (admin server) не включен.

Итак, добавляем в манифест (manifest) пода (pod) конфигурация контейнера (container):

- name: cloud-sql-proxy
  image: gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.6.0
  args:
  - «--private-ip» # соединяться только по внутренним адресам Cloud SQL инстанса
  - «--health-check»
  - «--http-address=0.0.0.0»
  - «--quitquitquit» # необходимый нам флаг
  - «--structured-logs»
  - «--address=0.0.0.0»
  - «--port=xxxx» # зависит от вашей базы данных
  - «$(CLOUD_SQL_INSTANCE)» # имя вашего Cloud SQL инстанса (сonnection name)
  securityContext:
    runAsNonRoot: true
  env:
  - name: CLOUD_SQL_INSTANCE
    valueFrom:
      configMapKeyRef:
        key: cloud-sql-instance # переменная configmap
        name: configmap-name # имя configmap
  readinessProbe:
    httpGet:
      path: /readiness
      port: 8090
    periodSeconds: 5
  livenessProbe:
    httpGet:
      path: /liveness
      port: 8090
    failureThreshold: 5
  resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: «1»
      memory: 512Mi

Теперь нам остаётся добавить красивое завершение команды (graceful), чтобы /quitquitquit конечная тока (endpoint) сервера (admin server) получила POST запрос (request) от нашей CronJob:

containers:
- name: cronjob
  image: alpine/curl
  command: [«/bin/bash», «-c»]
  args: [«echo Hello World! && curl -X POST localhost:9091/quitquitquit»]
resources:
  limits:
    cpu: «100m»
    memory: 128Mi
  requests:
    cpu: 100m
    memory: 256Mi

В итоге, получаем «зелёные» задачи, работающие по расписанию.