есть еще вот такой вот биндинг, его разве не достаточно? $ kubectl get clusterrolebindings system:node-proxier -o yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" creationTimestamp: 2018-04-20T20:23:23Z labels: kubernetes.io/bootstrapping: rbac-defaults name: system:node-proxier resourceVersion: "96" selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/system%3Anode-proxier uid: acc5fed4-44d8-11e8-9b2e-12f98ec592fa roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:node-proxier subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: system:kube-proxy

а запускаете вы как kube-proxy?

как статик pod: apiVersion: v1 kind: Pod metadata: name: kube-proxy namespace: kube-system spec: hostNetwork: true containers: - name: kube-proxy image: gcr.io/google-containers/hyperkube-amd64:{{ k8s_hyperkube_tag }} command: - /hyperkube - proxy - --cluster-cidr={{ k8s_cluster_cidr }} - --hostname-override={{ ansible_fqdn }} - --kubeconfig=/etc/kubernetes/kube-proxy.kubeconfig - -v=2 securityContext: privileged: true volumeMounts: - mountPath: /etc/kubernetes/kube-proxy.kubeconfig name: kube-proxy-kubeconfig readOnly: true - mountPath: /etc/kubernetes/ssl name: kubernetes-ssl readOnly: true - mountPath: /etc/ssl/certs name: etc-ssl-certs readOnly: true - mountPath: /usr/share/ca-certificates name: usr-share-certs readOnly: true volumes: - hostPath: path: /etc/kubernetes/kube-proxy.kubeconfig name: kube-proxy-kubeconfig - hostPath: path: /etc/kubernetes/ssl name: kubernetes-ssl - hostPath: path: /etc/ssl/certs name: etc-ssl-certs - hostPath: path: /usr/share/ca-certificates name: usr-share-certs

--- apiVersion: v1 kind: Config clusters: - cluster: certificate-authority: /etc/kubernetes/ssl/ca.pem server: https://{{ k8s_api_endpoint }} name: {{ k8s_cluster_name }} contexts: - context: cluster: {{ k8s_cluster_name }} user: kube-prioxy name: default current-context: default users: - name: kube-proxy user: client-certificate: /etc/kubernetes/ssl/kube-proxy.pem client-key: /etc/kubernetes/ssl/kube-proxy-key.pem

используйте, пожалуйста, сервисы вроде pastebin / x-paste / etc для длинных конфигов

хорошо, простите

/etc/kubernetes/ssl/kube-proxy.pem а тут у вас и ключ и серт как я понимаю и все там верно.

cn: system:kube-proxy

хм, а не в этом ли проблема: - name: kube-proxy или это имя ни на что не влияет и не уходит api серверу?

не должно

в логах апи сервера нет подсказок?

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

и еще, у меня докер 1.13.1-0~ubuntu-xenial, у для него надо с форвардингом приседать?

проще проверить чем запомнить )

ну он filter FORWARD в DROP ставит

ну вот - значит нужны?

ага

значит нужно

может лучше докер запускать с iptables=false

может, но это уже когда стенд разверну, тогда и буду тестить

и да, есть смысл обновлять докер 1.13.1 и до какой версии если да?

может, но это уже когда стенд разверну, тогда и буду тестить

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

и да, есть смысл обновлять докер 1.13.1 и до какой версии если да?

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

не подскажешь где найти этот список?

Я видел только не ниже какой-то версии и все

https://kubernetes.io/docs/getting-started-guides/scratch/#docker

ща

Я видел только не ниже какой-то версии и все

On each of your machines, install Docker. Version v1.12 is recommended, but v1.11, v1.13 and 17.03 are known to work as well. Versions 17.06+ might work, but have not yet been tested and verified by the Kubernetes node team

какой релиз у тебя?

1.10?

Я видел только не ниже какой-то версии и все

https://kubernetes.io/docs/setup/independent/install-kubeadm/#installing-docker

ну тебе уже ответили

ок, у меня 1.13, емнип именно с докером на staging кластере проблем не было, так что живем

On each of your machines, install Docker. Version v1.12 is recommended, but v1.11, v1.13 and 17.03 are known to work as well. Versions 17.06+ might work, but have not yet been tested and verified by the Kubernetes node team

спасибо

1.10?

ага, 1.10.1 если быть точнее

ну с 1.13 проблем не наблюдал

ну плюс

set --iptables=false so docker will not manipulate iptables for host-ports (too coarse on older docker versions, may be fixed in newer versions) so that kube-proxy can manage iptables instead of docker. --ip-masq=false if you have setup PodIPs to be routable, then you want this false, otherwise, docker will rewrite the PodIP source-address to a NodeIP. some environments (for example GCE) still need you to masquerade out-bound traffic when it leaves the cloud environment. This is very environment specific. if you are using an overlay network, consult those instructions.

ага, 1.10.1 если быть точнее

ты сам кластер собираешь?

да

cri-containerd не пробовал?

cri-containerd не пробовал?

Это что такое?

неа, думал, но отсутсвие адекватных пакетов меня парит

это рантайм контейнерный

замена раздутому докеру

Это что такое?

это от докер ато, что надо для работы в кубере

лишнее выброшено

это от докер ато, что надо для работы в кубере

Все понял.Загуглил уже

замена раздутому докеру

это от докера просто кусок докера )

сначала с этим стендом закончу, потом уже буду тестить cri-containerd

там еще cri-o есть

там еще cri-o есть

он вроде к конкретной версии кубера хорошо привязан

ну и cri-containerd постабильнее будет

ахз, Я пока туда вообще не лезу, оно ж бета по самое не балуй

ну cri-containerd - это containerd с совместимым апи cri

ты сам кластер собираешь?

мне ж надо это дерьмо с hashicorp vault скрестить, у меня vault сертификаты генерит, туда-же секреты писать, а после тестов туда будут еще и инстансы из aws ags ходить и сами себе секреты вытягивать с сертификатами при скейлинге

мне ж надо это дерьмо с hashicorp vault скрестить, у меня vault сертификаты генерит, туда-же секреты писать, а после тестов туда будут еще и инстансы из aws ags ходить и сами себе секреты вытягивать с сертификатами при скейлинге

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

короче, обмазываюсь со всех сторон: 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 это уже следующий этап