короче, обмазываюсь со всех сторон: aws, ansible, terraform, vault, kubernetes, docker

ты ты хочешь что бы волт тебе генерил серты для нод кубера?

уже генерит

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

следующая тема — кеширование в тот же vault

что-бы не перегенеривать

а потом уже asg, но там кеширования не надо, оно и без него жить будет, только сборщик мусора, который ревокать будет старые сертификаты

ясно

ну что, передеплоил кластер, все та же беда

kube-proxy не может авторизироваться для получения endpoints и services

static pod kube-proxy: https://pastebin.com/prTKs2ga kubeconfig kube-proxy: https://pastebin.com/D5Edc0hK certificate kube-proxy: https://pastebin.com/T41tiyzd

идей куда копать нет

вопрос со звездочко: а ктонибудь делал openwrt + zebra + bgp + metalb + flannel = loadbalancer на bm в домашних условиях?

порешал проблему с kube-proxy, там было неправильноe имя юзера в kubeconfig, было: kube-proxy надо было: system:kube-proxy

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

Посмотри на реализацию в kubespray, там уже есть поддержка vault как pki. Немного загонов с ttl и eku некоторых нету, но в целом vault pki мне очень нравится.

Всем привет! Кто-нибудь логи микросервисов в k8s снимает с помощью Graylog?

Мы делаем, но с помощью filebeat sidecar контейнера

Так же можно filebeat натравить на /var/lib/docker/*/logs тогда логи со всех контейнеров будут улетать

Так же можно filebeat натравить на /var/lib/docker/*/logs тогда логи со всех контейнеров будут улетать

спасибо за инфу

Здесь для ELK но суть та же. В грейлоге модуль ставится

Здесь для ELK но суть та же. В грейлоге модуль ставится

что за модуль?

На сайте грейлога где то есть модули или расширения для файлбита, он позволяет создать filebeat input

Зачем filebeat если докер из коробки поддерживает отправку логов в graylog?

Зачем filebeat если докер из коробки поддерживает отправку логов в graylog?

Вопрос. Если я буду посылать логи в грейлог, то не нарушится от этого экосистема кубера? Я как понимаю там в самом докере нужно менять эту опцию

Нужно обязательно включать кеширование, иначе при недоступности коллектора graylog контейнер подвиснет

Нужно обязательно включать кеширование, иначе при недоступности коллектора graylog контейнер подвиснет

Это в настройке самого logging driver?

Да

Да

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

--log-opt mode=non-block

https://docs.docker.com/config/containers/logging/configure/#configure-the-logging-driver-for-a-container

https://docs.docker.com/config/containers/logging/configure/#configure-the-logging-driver-for-a-container

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

Но я так и не понимаю, не нарушит ли такой сбор логов экоситему кубера?

Не нарушит, но kubectl logs не будет работать

Не нарушит, но kubectl logs не будет работать

Понял, спасибо

static pod kube-proxy: https://pastebin.com/prTKs2ga kubeconfig kube-proxy: https://pastebin.com/D5Edc0hK certificate kube-proxy: https://pastebin.com/T41tiyzd

вижу вы vault сертификаты выпускаете. c kube-proxy не помогу, но клиентский сертификат для kube-proxy у вас еще и для etcd00 годится, что неправильно. Вообще etcd сертификаты особенные и ни один инсталлер их секурно не делает по-моему (буду рад узнать если это не так), смысл в том, что они должны быть подписаны другим CA и цепочка доверия на etcd серверах не должна пересекаться ни с какими другими сертификатами в кластере, кроме тех что используют APIServers для подключения к etcd, иначе любой может пойти в etcd напрямую и все вычитать/поправить.

вижу вы vault сертификаты выпускаете. c kube-proxy не помогу, но клиентский сертификат для kube-proxy у вас еще и для etcd00 годится, что неправильно. Вообще etcd сертификаты особенные и ни один инсталлер их секурно не делает по-моему (буду рад узнать если это не так), смысл в том, что они должны быть подписаны другим CA и цепочка доверия на etcd серверах не должна пересекаться ни с какими другими сертификатами в кластере, кроме тех что используют APIServers для подключения к etcd, иначе любой может пойти в etcd напрямую и все вычитать/поправить.

О, спасибо большое

ну а по сути вопроса: включите audit log на apiserver и смотрите как kube-proxy ломится. Хотя лучше вообще перестать мучаться и поднимать инсталлером только ноды, etcd, kubelets, все остальное bootkube , тогда будет максимально self-hosted. например вот kube-proxy как daemonset: https://github.com/kubernetes-incubator/bootkube/blob/076b5434770d17f0e922dade82d00e7f7229f600/pkg/asset/internal/templates.go#L635-L702 и никакие сертификаты создавать/раскладывать не надо

Кстати, вопрос в догонку про сервис аккаунт ключ и про ключи для подписывания на контроллере. Как Я понял сервисный это просто рандомный приватный ключ без подписи а вот насчет ключей для подписи Я так и не понял :(

ну а по сути вопроса: включите audit log на apiserver и смотрите как kube-proxy ломится. Хотя лучше вообще перестать мучаться и поднимать инсталлером только ноды, etcd, kubelets, все остальное bootkube , тогда будет максимально self-hosted. например вот kube-proxy как daemonset: https://github.com/kubernetes-incubator/bootkube/blob/076b5434770d17f0e922dade82d00e7f7229f600/pkg/asset/internal/templates.go#L635-L702 и никакие сертификаты создавать/раскладывать не надо

Спасибо

Self-Hosted это уже следующий этап

self-hosted проще и настройка нод минимальна: только kubelet ы поднять, даже apiserver сам bootkube поднимет

Кстати, вопрос в догонку про сервис аккаунт ключ и про ключи для подписывания на контроллере. Как Я понял сервисный это просто рандомный приватный ключ без подписи а вот насчет ключей для подписи Я так и не понял :(

вы про какие опции контроллера сейчас? у service account создается секрет с JWT токеном для него, токен подписан контроллером, секретным ключем и проверяется на apiserver при запросах с этим JWT токеном

IPAM

вы про какие опции контроллера сейчас? у service account создается секрет с JWT токеном для него, токен подписан контроллером, секретным ключем и проверяется на apiserver при запросах с этим JWT токеном

вот про эту для аписервера и контроллера: - --service-account-private-key-file=/etc/kubernetes/ssl/ca.key

сейчас у меня там приватный ключ CA но мне это очень не нравится

а еще у контроллера есть вот такие опции: - --cluster-signing-cert-file=/etc/kubernetes/ssl/ca.crt - --cluster-signing-key-file=/etc/kubernetes/ssl/ca.key куда Я тоже впихнул ключи CA так как цейтнот был, но мне тоже очень и очень не нравится отдвать куда-либо CA ключи

вы про какие опции контроллера сейчас? у service account создается секрет с JWT токеном для него, токен подписан контроллером, секретным ключем и проверяется на apiserver при запросах с этим JWT токеном

> токен подписан контроллером, секретным ключем вот про этит секретный ключ судя по всему

и еще, а есть где-то дока по self-hosted? хочу для начала сам ручками поднять, любопытно как оно работает и делается, или исходники bootkub'а ковырять?

и еще, а есть где-то дока по self-hosted? хочу для начала сам ручками поднять, любопытно как оно работает и делается, или исходники bootkub'а ковырять?

https://github.com/kelseyhightower/kubernetes-the-hard-way

это уже читал, по ней и делал, там кстати ошибок много и кейс со static pods не описан, что жаль очень

да и для aws нет, но по аналогии легко сделать

и еще, а есть где-то дока по self-hosted? хочу для начала сам ручками поднять, любопытно как оно работает и делается, или исходники bootkub'а ковырять?

с селфхостед самое сложное поднять apiserver & controller-manager и scheduler так чтобы они были полноценными подами и управляли сами собой. для этого нужен bootkube там руками не поднять на коленке. если все это не self-hosted делать, а по-старинке, то дальше все эти kube-proxy kube-dns и проч можно и самому как daemonset сделать

с селфхостед самое сложное поднять apiserver & controller-manager и scheduler так чтобы они были полноценными подами и управляли сами собой. для этого нужен bootkube там руками не поднять на коленке. если все это не self-hosted делать, а по-старинке, то дальше все эти kube-proxy kube-dns и проч можно и самому как daemonset сделать

спасибо большое, жаль, что нельзя, тогда буду смотреть на bootkube

Вообще я на интеграцию с Vault в AWS убил лучшие годы своей жизни и в итоге выпилил это все нафиг нещадно (неосилил).слишком о многом надо думать: проприсать корректные роли в vault, следить чтобы ноды были с правильными тагами (чтобы получить нужную роль), много возни с systemd демонами, особенно если хочется корректного обновления ключей (а мне хотелось) на лету без рестарттов

и все это ради непонятно чего :) kubelet tls bootstrap работает отличненько

вот, надо будет посмотреть на него поближе

вот про эту для аписервера и контроллера: - --service-account-private-key-file=/etc/kubernetes/ssl/ca.key

вот этот подписывает JWT токены создаваемые внутри кластера для service account . открытая часть этого ключа должна быть среди ключей, которыми apiserver проверяет подписи (их может быть несколько, необходимо для ротации подписывающих ключей)

а еще у контроллера есть вот такие опции: - --cluster-signing-cert-file=/etc/kubernetes/ssl/ca.crt - --cluster-signing-key-file=/etc/kubernetes/ssl/ca.key куда Я тоже впихнул ключи CA так как цейтнот был, но мне тоже очень и очень не нравится отдвать куда-либо CA ключи

эти используютя для TLS bootstrapping, подробнее тут : https://kubernetes.io/docs/admin/kubelet-tls-bootstrapping/

а есть где-то дока по тому какие ключи кому и для кого нужны в kubernetes?

google site:kubernetes.io/docs/

там вразброс, но всё где-нибудь да описано

эх, тогда буду копать там, в любом случае огромное спасибо

альфа фичи только в коде бывают, требование к beta фичам уже полноценная дока, так что они есть

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

FileBeat такую заразу пишет в лог: INFO Connected to Elasticsearch version 6.2.4 INFO Template already exists and will not be overwritten. ERR Failed to perform any bulk index operations: 502 Bad Gateway ERR Failed to publish events: 502 Bad Gateway Причём в эластик пишутся логи

Нужно обязательно включать кеширование, иначе при недоступности коллектора graylog контейнер подвиснет

Это только при TCP было, да и то уже поправили. При UDP не вешались.

кхех. Плохая была идея слать логи filebeat через ингрес :)

Hi, I heard that Russia shielded Telegram recently. Is it true?😳

Hi, I heard that Russia shielded Telegram recently. Is it true?😳

tried to shield, but there is no success as you can see :)

Коллеги, zebra + metalb + k8s. Это нормально?

Коллеги, zebra + metalb + k8s. Это нормально?

metal пока альфа, но в целом выглядит интересно

Коллеги, если есть кто нибудь кто поднимал Rancher 2.0 с SSL отзовитесь :)

Вопрос-то какой?

Вопрос-то какой?

У них оф документация видимо устарела, по словам разработчика валидный мануал для использования со своими сертификатами вот этот: https://medium.com/@superseb/ssl-tls-options-for-rancher-2-0-dca483a7070d Если использовать вместе с Nginx как linked контейнер для терминации SSL, то написано, что нужно дополнительно пробросить сертификаты cacerts.pem по пути /etc/rancher/ssl/cacerts.pem. Вопрос: агенты не могут подключиться к серверу, выкатывая в лог ошибку: Failed to connect to proxy" error="x509: certificate signed by unknown authority". Цепочка сертификатов валидная, как победили? Сталкивались ли вообще?

Народ, а кто нибудь билдит контейнеры в контейнерах?

ну я

и как оно?

нормас

нормас

а как именно? что используешь?

Народ, а кто нибудь билдит контейнеры в контейнерах?

Сейчас я закину немного когнитивности. Смотри, у тебя есть какие-то конкретные опасения / пробелы в знаниях, которые ты хочешь закрыть. Мы о них не узнаем, пока ты прямо о них не скажешь, поэтому стоит прямо сразу все это делать озвучить, чтобы мы могли ответить чем-то большим, чем "билдим / не билдим".