коллеги, среди нас есть достаточно смелые, кто уже пробовал? https://cilium.io/blog/2018/08/21/cilium-12/

привет, кто-то настраивал fluent-bit с containerd?

Да все по ману: [INPUT] Name tail Path /var/log/containers/*.log Parser crio Tag kube.* Mem_Buf_Limit 25MB [FILTER] Name kubernetes Match kube.*

спасибо большое, а какой парсер для kubernetes фильтра?

Вот все, что есть. Ниже опции для подключения к k8s только. Т.е парсер - в инпуте. В фильтре - фильтр, kubernetes и все

Всем привет, кто нить сталкивался, правильно ли я понял, отключить авторизацию нельзя для kubernetes-dashboard (так как токен он использует из RBAC). Но может кто то решал, нужно что бы дашборда пропускала авторизацию, при этом авторизовывалась в самом кубере токеном и правами, а мой фронт использовал http авторизацию с ldap. В идеале группы ldap завязать на namespace-ы но судя по тому что нарыть удалось об этом речи пока не идет

Если надо авторизоваться в лдапе, то dex

https://github.com/coreos/dex

https://github.com/coreos/dex

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

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

Ребят, есть вопрос: Обновлял кластер до v1.11.2 с v1.10.3 через kubespray, на тестовом кластере все прошло хорошо. Сеть calico. На другом вылезла интересная трабла: локально на нодах api сервера доступны, но при попытке выкатить под, он выкатывается, но после этого до api серверов не достучаться вообще (на любые порты) Грешу на то, что из репы с общими настройками проскочила опция enable_network_policy: true, которая раньше была в false и фаерволл все это блочит… P.S. Да, hard way для лучшего понимания еще не юзал, ибо не успел добраться P.P.S. Попутно переносил один инстанс etcd на другую машину, но с ним все ок, healthy, и endpoint’ы везде актуальные

Привет! Подскажите,в чем может быть проблема: kubectl get nodes возвращает все ноды кластера (5 штук, все Ready), kubectl top node - все, кроме одной (4 штуки). При этом поды на отсутствующей в выводе ноде работают корректно, kubelet на ней перезапускал, ошибок подключения к этой ноде в логе heapster'a нет. При попытке получить данные по отсутствующей в списке ноде командой kubectl top node %NODENAME% возвращается ошибка Error from server (NotFound): the server could not find the requested resource (get services http:heapster:)

Привет! Подскажите,в чем может быть проблема: kubectl get nodes возвращает все ноды кластера (5 штук, все Ready), kubectl top node - все, кроме одной (4 штуки). При этом поды на отсутствующей в выводе ноде работают корректно, kubelet на ней перезапускал, ошибок подключения к этой ноде в логе heapster'a нет. При попытке получить данные по отсутствующей в списке ноде командой kubectl top node %NODENAME% возвращается ошибка Error from server (NotFound): the server could not find the requested resource (get services http:heapster:)

а что в response для этой ноды в kubectl top node {{NODENAME}} -v=8 ?

https://pastebin.com/raw/SwYsJHZX

версия куба 1.9 или ниже?

1.11 все ноды

я бы смотрел почему https запрос к API серверу https://10.90.8.15:6443/api/v1/namespaces/kube-system/services/http:heapster:/proxy/apis/metrics/v1alpha1/nodes/srv-kub02 возвращает 404 с других нод этот запрос отдает 200?

я бы смотрел почему https запрос к API серверу https://10.90.8.15:6443/api/v1/namespaces/kube-system/services/http:heapster:/proxy/apis/metrics/v1alpha1/nodes/srv-kub02 возвращает 404 с других нод этот запрос отдает 200?

а еще лучше посмотреть какие метрики под хипстера возвращает для ноды /api/v1/model/nodes/{node-name}/metrics/: Returns a list of available node-level metrics. и если они там есть, возможно apiserver не может их получить и надо искать где пакетики не доходят

Ребят, есть вопрос: Обновлял кластер до v1.11.2 с v1.10.3 через kubespray, на тестовом кластере все прошло хорошо. Сеть calico. На другом вылезла интересная трабла: локально на нодах api сервера доступны, но при попытке выкатить под, он выкатывается, но после этого до api серверов не достучаться вообще (на любые порты) Грешу на то, что из репы с общими настройками проскочила опция enable_network_policy: true, которая раньше была в false и фаерволл все это блочит… P.S. Да, hard way для лучшего понимания еще не юзал, ибо не успел добраться P.P.S. Попутно переносил один инстанс etcd на другую машину, но с ним все ок, healthy, и endpoint’ы везде актуальные

началось, гитхаб стал квадратным []__[]

Привет. Кто-то сталкивался с таким: https://github.com/kubernetes/kubernetes/issues/62061 (rbd том не детачится от умершей ноды и мигрирующие поды зависают на создании)? Как лечили/обходили, подскажите. Воспроизводится на k8s 1.9.5

Привет. Кто-то сталкивался с таким: https://github.com/kubernetes/kubernetes/issues/62061 (rbd том не детачится от умершей ноды и мигрирующие поды зависают на создании)? Как лечили/обходили, подскажите. Воспроизводится на k8s 1.9.5

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

допустим куб перезапускает такой под на другой ноде, при этом не до конца убедившись что старый однозначно мертв. а через какое-то время восстанавливется подключение к стораджу на прежней ноде, i/o продолжается исход такой-же: поврежденная фс и даннные на ней

Но в случае клауда, провайдер сообщает сразу, что нода мертва

для проксмокса, например, можно гарантированно пристретить сервак через ipmi

@SinTeZoiD посмотришь письки?

@SinTeZoiD посмотришь письки?