ну хоть ведутся, у меня как-то наоборот получается: "чуваки, я тут в свое свободное время исследовал новую штуку и она подойдет лучше текущей, вот тут получим то-то а тут ускорится на столько-то" а они такие: "ну не знаю... нам кажется тебе просто скучно" :)

Вот уж не знаю, что лучше))) Воздушные замки, или дикие слоупоки

обычно середина

Всем привет

Никого Helm не бесит? :)

меня)

Никого Helm не бесит? :)

Кто-нибудь использует в чартах network policy? Как helm upgrade можно делать с ними?

helm это вроде менеджер пакетов, сеть тут каким боком?

helm это вроде менеджер пакетов, сеть тут каким боком?

Достаточно простым. Это такой же объект как pod или service

ну и объект. как это связано с менеджером пакетов то?

А внутри пакета что?)

nginx например

или ещё какой софт

это обычный apt или yum по сути

это обычный apt или yum по сути

нет, это кривой kubectl apply с блэкджеком

никакой транзакционности и роллбэков. может посчитать что изменений нет,хотя если сравнить оъект в helm get release и в kubectl get XXX -o yaml они будут разными

все подвязано на labels и selectors ,от этого ты можешь установить новый релиз, удалить его, а оно с собой утянит что-то что было до этого. просто потому что labels совпали :)

из свежего: изменения в initContainers напрочь игнорятся :)

Привет, а http://www.telepresence.io/ кто-нибудь пробовал? у меня чёт какие-то странные ошибки при запуске, хотя шелл вроде взлетел но вот на второй запуск днс перестал работать куберовский из шелла

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

Неплохая штука, но вообще есть minikube

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

Привет, а http://www.telepresence.io/ кто-нибудь пробовал? у меня чёт какие-то странные ошибки при запуске, хотя шелл вроде взлетел но вот на второй запуск днс перестал работать куберовский из шелла

на вид классно, жаль что не работает :)

можно с миникубом как-то не запускать эти 3 сервиса локально?

а использовать те что в тестинг контуре кубера

Ещё оно мне tor-socks в процессе установки поставило, и зачем-то собрало 3й питон из исходников

а так хотелось что-бы просто заработало :(

вон оно чо.. действительно Unhealthy =)

охуеть. у меня тоже

etcd-0 Unhealthy Get https://etcd.cluster1:2379/health: remote error: tls: bad certificate

хотя с сертификатами точно все в порядке

уже ссылку кидали закрытую багу.. думаю в 1.6.3 пофиксят

а. не заметил сначала

т.е. это только health check сбоит?

а данные куба ты в etcd нашел? по дефолтному префиксу /registry у меня тоже ничего нет. странно

Я хз где там что... в etcd2 был удобный list.. в 3 я похожее не нашел

но судя по статам, что-то да в кластере есть

+--------------------------+------------------+---------+---------+-----------+-----------+------------+ | ENDPOINT | ID | VERSION | DB SIZE | IS LEADER | RAFT TERM | RAFT INDEX | +--------------------------+------------------+---------+---------+-----------+-----------+------------+ | https://10.8.38.25:2379 | 8db60315ecac18c6 | 3.1.5 | 4.1 MB | false | 15 | 2700359 | | https://10.8.27.91:2379 | 2c158b35add3cc39 | 3.1.5 | 4.1 MB | false | 15 | 2700359 | | https://10.8.164.13:2379 | 50ad704529b6bb22 | 3.1.5 | 4.1 MB | true | 15 | 2700359 | +--------------------------+------------------+---------+---------+-----------+-----------+------------+

а данные куба ты в etcd нашел? по дефолтному префиксу /registry у меня тоже ничего нет. странно

сам не пробовал, но что если смотреть клиентом от 3 версии? ETCDCTL_API=3 или как-то так

ага

советую сделать алиас

мой пример

source /etc/environment.tf alias etcdctl="etcdctl --endpoints https://$(hostname):2379 --ca-file /etc/ssl/ca.pem --cert-file /etc/ssl/server.pem --key-file /etc/ssl/server-key.pem" alias etcdctl3="ETCDCTL_API=3 /usr/bin/etcdctl --cacert=/etc/ssl/ca.pem --cert=/etc/ssl/server.pem --key=/etc/ssl/server-key.pem --endpoints=$K8S_APISERVER_ETCD_SERVERS]"

/etc/bash_completion.d/aliases.sh

алиас у меня есть, но в etcd пусто # cluster-etcdctl ls --recursive /coreos.com /coreos.com/network /coreos.com/network/config /coreos.com/network/subnets /coreos.com/network/subnets/10.2.91.0-24

аа, опять пропустил сообщения…

сейчас посмотрю с ETCDCTL_API=3

да есть данные, можно спать спокойно вот команда для вывода списка: ETCDCTL_API=3 cluster-etcdctl get --keys-only --prefix /

ООО! Спасиб)

народ, расскажите как дебажить кубернетес? например, начали падать поды... скорее всего ООМ, или еще что поды-то перезапускаются, там логов никаких нет куда правильно заходить, что искать на предмет выявления ошибок?

Тоже интересно, как отлавливать ООМ, в ивенты это не попадает

у вас dmesg логи собираются же куда-то? вон там видно

ну и может kubelet что-нибудь пишет себе в лог

Люди, а cloud provider можно уже отдельно запускать? Мне б запатчить его и пустить рядышком

парни нужен коллективный разум)

ID=coreos VERSION=1353.7.0 Server Version: 1.12.6

flannel 0.7.0 в rkt , куб 1.6.2, рандомная половина контейнеров не пингуется

те куб запускает поды все ок, кубелеты ругаются, что не могут сделать хэлфчек контейнерам, при ручной проверке этих контейнеров видно , что они запущены и айпи в у них есть внутри, но docker0 они пинговать не могут, также их не видно с хоста, если кильнуть под то с вероятностью в 50% он поднимется с сетью после рестарта

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

также заметил, что docker inspect для непингующихся контейнеров не показывает ип в NetworkSettings, хотя из контейнера ип видно и docker network inspect bridge их показывает

хотя последнее видимо совпадение, сейчас нашел нормальный непингующийся контейнер с ип в NetworkSettings, arp -a на такие ip пишет <incomplete> on docker0

хотя последнее видимо совпадение, сейчас нашел нормальный непингующийся контейнер с ип в NetworkSettings, arp -a на такие ip пишет <incomplete> on docker0

если у вас сеть через CNI , то с точки зрения докера это всё net=none

если у вас сеть через CNI , то с точки зрения докера это всё net=none

сеть flannel, что еще заметил разницу ip addr sh

13: veth893da0a@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1472 qdisc noqueue state UP group default link/ether 12:f6:91:c5:71:80 brd ff:ff:ff:ff:ff:ff inet6 fe80::10f6:91ff:fec5:7180/64 scope link valid_lft forever preferred_lft forever 15: veth84e29ce@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1472 qdisc noqueue master docker0 state UP group default link/ether 7a:82:c3:e3:e9:32 brd ff:ff:ff:ff:ff:ff inet6 fe80::7882:c3ff:fee3:e932/64 scope link valid_lft forever preferred_lft forever

у тех что без сети нет master docker0

сеть flannel, что еще заметил разницу ip addr sh

flannel кажется по-разному может конфигурироваться. речь о том как kubelet настроен?использует CNI плагины?

нет, не использует чистый фланнел

ERROR: S client not available

фланнел сеть работает, я могу пинговать с одной машинки подсеть другой машины, тут скорее глюки докера, он не всегда добавляет к сети master docker0

вот еще dmesg инициализацию на disabled state

worker02 core # dmesg -T|grep veth4b0 [Sun Apr 30 02:58:36 2017] docker0: port 4(veth4b02130) entered blocking state [Sun Apr 30 02:58:36 2017] docker0: port 4(veth4b02130) entered disabled state [Sun Apr 30 02:58:36 2017] device veth4b02130 entered promiscuous mode [Sun Apr 30 02:58:36 2017] IPv6: ADDRCONF(NETDEV_UP): veth4b02130: link is not ready [Sun Apr 30 02:58:36 2017] docker0: port 4(veth4b02130) entered blocking state [Sun Apr 30 02:58:36 2017] docker0: port 4(veth4b02130) entered forwarding state [Sun Apr 30 02:58:36 2017] device veth4b02130 left promiscuous mode [Sun Apr 30 02:58:36 2017] docker0: port 4(veth4b02130) entered disabled state [Sun Apr 30 02:58:36 2017] IPv6: ADDRCONF(NETDEV_CHANGE): veth4b02130: link becomes ready worker02 core # dmesg -T|grep veth839 [Sun Apr 30 02:58:49 2017] docker0: port 10(veth839a387) entered blocking state [Sun Apr 30 02:58:49 2017] docker0: port 10(veth839a387) entered disabled state [Sun Apr 30 02:58:49 2017] device veth839a387 entered promiscuous mode [Sun Apr 30 02:58:49 2017] IPv6: ADDRCONF(NETDEV_UP): veth839a387: link is not ready [Sun Apr 30 02:58:49 2017] IPv6: ADDRCONF(NETDEV_CHANGE): veth839a387: link becomes ready [Sun Apr 30 02:58:49 2017] docker0: port 10(veth839a387) entered blocking state [Sun Apr 30 02:58:49 2017] docker0: port 10(veth839a387) entered forwarding state [Sun Apr 30 02:58:49 2017] docker0: port 10(veth839a387) entered disabled state [Sun Apr 30 02:58:49 2017] docker0: port 10(veth839a387) entered blocking state [Sun Apr 30 02:58:49 2017] docker0: port 10(veth839a387) entered forwarding state

виновником оказалась преднастройка от ovh - линк в /dev/null в /etc/udev/rules.d/80-net-setup-link.rules

крутая преднастройка ?

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

Я чет не понимаю при чем тут куб вообще

И какие альтернативы монут быть

почему не подходят?

чтобы что то собирать надо иметь все для сборки

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

в проде ничего этого быть не должно никогда

и как вы это тестить будете?

или тут петонист пришёл, щас пипом все поставим ачотаково

кубернетис типа прод. там должен быть чистый протестеный бинарь и все

чём плох обычный подход с дженкинсом, кучей тестов и возможно стейджинг ом?

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

а если кажется, что это не подходит, то в консерватории проблемы, кажется.

очень рад, что вы все на дженкинсе делаете, даже воду смываете, но мой вопрос в другом был. не хотелось бы разводить холивары, интересует, монтирует ли кто-нибудь на проде через hostPath

нет, конечно

ну а если исключить сборку контейнеров с исходниками и всем-всем-всем, то какие альтернативы?

Никаких нормальных

Это все напоминает проблему ХУ. Что мешает билдить образы?

Билдить и выкатывать куча вариантов, а вот делать в бою лайврелоад из примапленой директории, меняя код через самбу или sshfs - прямой путь в ад. Разрабатывать можно локально

Если появится проект на компилируемом языке, то там сразу ой всё

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

в кубе единица работы - это контейнер. контейнер неделим, и для куба нет разницы, завалился контейнер из-за недочетов сборки или ошибки синтаксиса в приложении

но в общем вся контейнерная философия пиравнивает приложение к образу

все это "работает локально - работатет в проде"

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