Получаем wildcard SSL-сертификат в Kubernetes с помощью cert-manager

Короткая заметка о том как быстро поставить cert-manager в кубер, поднять ишуеры и насетапить креды в AWS для получения как обычного так и wildcard сертификата с помощью Let's Encrypt: https://medium.com/@Amet13/wildcard-k8s-4998173b16c8
Также узнал недавно о том, что есть такая штука как kubernetes-replicator, о ней я тоже вскольз упомянул.

DevOps Days Kyiv 2019

17-18 мая в Киеве прошла ежегодная конференция DevOps Days Kyiv.

Особенность конференции заключается в том, что доклады посвящены культуре девопса, а не техническим деталям.
Помимо основных докладов можно было выступить со своей темой (ignite talks).
Например были небольшие доклады про Terraform, БД, VictoriaMetrics, звезды на Github, организацию сети в амазоне и много других интересных докладов.

Помимо докладов, каждый мог предложить какую-либо тему для обсуждения в формате open space, некоторые из обсуждаемых тем второго дня:

Terraform и СУБД в Kuberentes также были на open space обсуждениях.
В общем конфа получилась интересная, как с организаторской точки зрения, так и со стороны докладов и качества материала.

Фото: https://www.facebook.com/pg/devopsdayskyiv/photos/?tab=album&album_id=402849030443211&ref=page_internal
Слайды презентации: https://www.slideshare.net/MykolaMarzhan/presentations
Видео докладов: https://www.youtube.com/playlist?list=PL_O8YSX8ckffzeV9mIBUQniaKFxGnPdYh

Отправляем логи Kubernetes в AWS Elasticsearch Service

Написал небольшую статейку по поводу того, как можно отправлять логи кубера и в частности Nginx Ingress в AWS Elasticsearch Service: https://medium.com/@Amet13/sending-kubernetes-logs-to-amazon-elasticsearch-service-8fb8f18ac35d
В целом ничего сверхъестественного, в двух словах описал где можно разворачивать эластик и почему я использовал именно такой сетап. Также немного цифр по нагрузке и количеству логов.

Отправляем метрики из AWS Cloudwatch в Prometheus с помощью prometheus-operator в Kubernetes

Добавляем права нашему пользователю AWS для чтения метрик:

aws iam attach-group-policy \
--policy-arn arn:aws:iam::aws:policy/CloudWatchReadOnlyAccess \
--group-name kops-dev

Создаем values-файл для экспортера:

cat << EOF > values-cloudwatch-exporter.yml
service:
  annotations:
    prometheus.io/scrape: "true"
EOF

Устанавливаем экспортер:

helm install stable/prometheus-cloudwatch-exporter \
--name prometheus-cloudwatch-exporter \
--namespace kube-system \
--set aws.aws_access_key_id=${AWS_ACCESS_KEY_ID} \
--set aws.aws_secret_access_key=${AWS_SECRET_ACCESS_KEY} \
-f values-cloudwatch-exporter.yml


Создаем values-файл для оператора:

cat << EOF > values-operator.yml
prometheus:
  additionalServiceMonitors:
    - name: prometheus-operator-cloudwatch
      endpoints:
      - port: http
        path: /metrics
        interval: 30s
      namespaceSelector:
        matchNames:
          - kube-system
        selector:
          matchLabels:
            app: prometheus-cloudwatch-exporter
serviceMonitors:
  - name: ""
    namespaceSelector:
      any: true
EOF

Устанавливаем prometheus-operator с Alertmanager и Grafana:

helm install stable/prometheus-operator \
--name prometheus-operator \
--namespace monitoring \
-f values-operator.yml

Идем в дашборд прометеуса на страницу Targets и проверяем наш новый таргет:

Ну и наконец посмотрим сами метрики:

FOSDEM 2019

2-3 февраля мне удалось побывать на ежегодной конференции FOSDEM.
Конфа полностью бесплатная, проводилась на базе университета Брюсселя, примерно в часе пешком от центра Брюсселя.
Народу было много, гитхаб разливал кофеек бесплатно:

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

Теперь пару слов о докладах, на которых я побывал (тут неполный список, только те что я сходу нашел):
- Deploying PostgreSQL on Kubernetes — ожидал услышать хардкора, но по факту рассказывалось про базовые вещи кубера и что постгрес можно деплоить ямликами, хелмом или оператором
- MySQL Replication - Advanced Features — Петр Зайцев рассказал об истории появления различных репликаций в MySQL, чем отличаются различные типы репли чтоикаций и т.д.
- Loki - Prometheus for logs — презентация тулзы для логов от создателей Grafana, выглядит круто, посмотрим как покажет себя на деле
- Introducing kubectl-trace — вроде что-то про трассировку в кубере, толком не смотрел доклад, так как в это время чинил стейджевый куберовский кластер :)
- Upcoming Kubernetes Storage features — TLDR: скоро можно будет PVC мувать между неймспейсами, клонировать PVC и создавать Populating PVC (т.е. при создании PVC сразу же на него например клонировать код из git-репозитория или скачивать файл по http, что-то на манер packer)
- PostgreSQL Goes to 11! — немного истории постгреса и обзор чейнджлога к 11 версии
- Netflix and FreeBSD — доклад о том, как Netflix поддерживают свою кодовую базу FreeBSD, почему и как они гоняют большой траффик на своих CDN с помощью FreeBSD
- The Cloud is Just Another Sun — история о том, как было раньше с серверами, как сейчас все в облаках и что надо делать дальше
- 2019 - Fifty years of Unix and Linux advances — maddog интересно рассказал, как разивался Unix, GNU, Linux, open source, в интересной форме

Использование PGAudit в Amazon RDS

Написал статью о том, как мы используем PGAudit для базы в RDS: https://medium.com/preply-engineering/pgaudit-7e0c3eebd54d

Миграция сообщений в очередях RabbitMQ с помощью Shovel

У RabbitMQ существует возможность миграции сообщений между очередями, как в пределах одной ноды, так и между различными нодами.
Для этого можно использовать плагин Shovel (вообще кроме Shovel полезно будет знать про федерацию и кластеризацию в RabbitMQ, в некоторых кейсах можно использовать и их).

Установка плагина Shovel:
rabbitmq-plugins enable rabbitmq_shovel rabbitmq_shovel_management

Пример использования Shovel для миграции очереди celery с ноды node1 на node2:
rabbitmqctl set_parameter shovel celery-migration \
'{"src-uri": "amqp://node1user:[email protected]/node1vhost", "src-queue": "celery", "dest-uri": "amqp://node2user:[email protected]/node2vhost", "dest-queue": "celery"}'

Для того чтобы node1 могла подключиться к node2, на второй должен быть открыть порт 5672.
Помимо использования CLI можно и использовать веб-интерфейс, пример можно посмотреть тут.

Пробрасываем реальный IP-адрес в Nginx Ingress от Cloudfront

По умолчанию установленный Nginx Ingress с помощью HELM в AWS не пробрасывает реальный IP-адрес внутрь балансера, поэтому в логах ингресс-контроллера будут присутствовать логи с внутренних адресов сети.

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

Включаем аннотацию для прокси в сервисе контроллера:
kubectl edit svc nginx-ingress-controller -n kube-system
metadata:
...
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: '*'

Разрешаем в конфигмапе использование прокси, добавляем список адресов Cloudfront и перезаписываем the_real_ip:
kubectl edit configmap nginx-ingress-controller -n kube-system
data:
...
  # curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | jq  -r '.prefixes[] | select(.service=="CLOUDFRONT") | .ip_prefix' | awk '{print $1}'
  proxy-real-ip-cidr: "54.155.0.0/16,172.96.98.0/24..."
  http-snippet: |
    map '' $the_real_ip {
      default          $http_x_forwarded_for;

    }
  use-proxy-protocol: "true"

Собственно говоря после этого все.
Идем в логи контроллера и смотрим адреса с которого приходят запросы:
kubectl logs -f nginx-ingress-controller-56f4bf4dc9-5pqjn
1.1.1.1 - [1.1.1.1] - - [22/Jan/2019:18:58:23 +0000] "GET /ping HTTP/1.1" 503 197 "-" "Wget" 85 0.000 [-]

В самом конфиге ингресса добавляем:
    nginx.ingress.kubernetes.io/server-snippet: |
        real_ip_header X-Forwarded-For;
        real_ip_recursive on;

Аутентификация в Kubernetes с помощью GitHub OAuth и Dex

Описал в статье как мы настраивали аутентификацию для кубера.
На хабре: https://habr.com/ru/post/436238/
На медиуме (англ): https://medium.com/preply-engineering/k8s-auth-a81f59d4dff6

Пока мы все это настраивали, много раз выстрелили себе в ноги. Однако таки удалось добить ее, сейчас успешно используем это на паре-тройке куберовских кластеров.
И да, подписывайтесь на телеграм-канал моего коллеги Юры: https://t.me/catops именно он добил эту аутентификацию, пока я мучался с ней тонну времени.
Он вместе с Максимом практически ежедневно выкладывает ссылки на годное чтиво, о том что связано с DevOps и смежными IT-темами.

Создание read-only пользователя в PostgreSQL

Источник: https://gist.github.com/oinopion/4a207726edba8b99fd0be31cb28124d0

Сохраню себе для копипасты.

-- Create a group
CREATE ROLE readaccess;

-- Grant access to existing tables
GRANT USAGE ON SCHEMA public TO readaccess;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readaccess;

-- Grant access to future tables
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO readaccess;

-- Create a final user with password
CREATE USER user WITH PASSWORD 'secret';
GRANT readaccess TO user;