А так с net host у тебя процесс сразу открывает порт на самих нодах, а демонсет следит чтобы контроллер был везде

А так с net host у тебя процесс сразу открывает порт на самих нодах, а демонсет следит чтобы контроллер был везде

И правда, а я чтото пропустил hostNetwork там (https://kubeapps.com/charts/stable/nginx-ingress) , думал что они совсем его убрали в пользу сторонних балансировщиков.

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

все ноды могут быть одинаковыми. мастер-компоненты могут быть как вне этих нод, так и крутиться на них же средствами кубернета и переезжать с ноды на ноду при их падении. на нодах должно быть - kubelet (основной исполнитель) и kube-proxy (для заворачивания трафика между нодами). ну и докер конечно же. к мастер-компонентам относятся api-server, kube-controller-manager и sheduler. также нужен кластер БД (etcd) (может крутиться на нодах, а может стоять отдельно) и что-то, что будет управлять сеткой - flannel или calico. я для нод использую CoreOS - там почти всё уже есть (докер, фланнел). а вообще я сам ещё разбираюсь, так что если кто может уточнить/дополнить - вэлкам!

я лью ноды по PXE (использую machbox) и описываю всё в cloud-config. на данный момент у меня поднимается (автоматом, за 9,5мин) etcd на каждой ноде (в виде компонента CoreOS), flannel, kubelet. все мастер-компоненты поднимаются на одной из нод и пока прибиты к ней гвоздями. вот сейчас бьюсь с ДНС (компонент kube-dns поднимается отдельно). далее в планах настроить кластерный айпишник (один для всех нод), задеплоить мастер-компоненты кубернета в сам кластер, чтобы они переезжали по нодам и не были привязаны к какой то одной. тоже самое сделать с etcd. и прицепить к кубернету внешнюю хранилкутипа CEPH что бы не хранить ничего на нодах локально ))

кто же тебя нанял то

на эту авантюру

Кто нибудь знает как правильно балансировку сделать на bare-metal? ingress встал и nginx-ingress-controller в режиме NodePort подрубил порты 30000+, по ним на нодах все открывается. Но не могу найти как все это выкинуть на 80/443 что бы выше только DNS был. На GCE и AWS есть внешний LB а что делать если кластер на своих железках?

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

Они перепилили репозитории, там раньше было 100500 примеров а теперь всего парочка для GCE/AWS и т д. Попробую через helm

ага, теперь даже не упоминается что можно с daemonset

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

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

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

DaemonSet

DaemonSet

То-есть через Deployment Kind никак?

можно поиграть с Affinity и replicas, но при добавлении/удалении ноды из кластера работаь не будет

По сути DaemonSet и есть Deployment, который запускает ровно один экзепляр pod на каждой ноде кластера. (Или ноде удовлетворяющей опр NodeSelector)

Минус только один, нету встроенного RollingUpdate механизма

вдруг ему взбредает в голову kubelet[28382]: W1012 17:36:48.046037 28382 eviction_manager.go:331] eviction manager: attempting to reclaim nodefs kubelet[28382]: I1012 17:36:48.046053 28382 eviction_manager.go:345] eviction manager: must evict pod(s) to reclaim nodefs и начинает выгонять поды (все) kubelet[28382]: I1012 17:36:48.046263 28382 eviction_manager.go:363] eviction manager: pods ranked for eviction:

экспериментировал и даже шкейлил по 80 реплик в деплойменте, думая что у меня баг, типа этого: https://github.com/kubernetes/kubernetes/issues/52336 в 1.7 и 1.8 есть похоже проблема у cadvisor с подсчетом пространства при использовании overlay2. но в итоге оказалось что kubelet генерит /var/lib/kubelet/pods и хранит там вольюмы типа emptyDir, чего я не ожидал, раздел под /var оказался маловат. я то думал оно все по докеровскому graph path будет. контролировать расположение emptyDir можно? и какой сторейдж драйвер юзать, если не overlay2, учитывая тот issue, который пока что не исправлен в cadvisor

Минус только один, нету встроенного RollingUpdate механизма

чет устарела инфа: https://kubernetes.io/docs/tasks/manage-daemon/update-daemon-set/

на эту авантюру

а в чём проблема? )))

мм видимо в 1.8 полностью переделали на основе Deployment

The DaemonSet rolling update feature is only supported in Kubernetes version 1.6 or later.

раньше оно был на rc

Кубер будет нативно сворм заменять

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

за одно с ibm и ещё парочкой компаний

При локальной разработке использую docker-compose. Как локально разрабатывать с кубером?

точно так же. просто потом образы едут в кубер

Есть вариант развернуть реальный кубер удаленно, но дебажить свои сервисы локально?

https://kubernetes.io/docs/concepts/services-networking/service/

так... читаю... DNS For example, if you have a Service called "my-service" in Kubernetes Namespace "my-ns" a DNS record for "my-service.my-ns" is created. Pods which exist in the "my-ns" Namespace should be able to find it by simply doing a name lookup for "my-service". Pods which exist in other Namespaces must qualify the name as "my-service.my-ns". The result of these name lookups is the cluster IP. вот это у меня не работает. сервисы по длинному имени (kubernetes.default.svc.cluster.local) резолвятся, а поды по вышеописанной схеме - нет(( как это починить?

При локальной разработке использую docker-compose. Как локально разрабатывать с кубером?

миникуб советовали

так... читаю... DNS For example, if you have a Service called "my-service" in Kubernetes Namespace "my-ns" a DNS record for "my-service.my-ns" is created. Pods which exist in the "my-ns" Namespace should be able to find it by simply doing a name lookup for "my-service". Pods which exist in other Namespaces must qualify the name as "my-service.my-ns". The result of these name lookups is the cluster IP. вот это у меня не работает. сервисы по длинному имени (kubernetes.default.svc.cluster.local) резолвятся, а поды по вышеописанной схеме - нет(( как это починить?

А должны? Я вот читаю и не вижу что должны

При локальной разработке использую docker-compose. Как локально разрабатывать с кубером?

Подписывайся на новый докер бету который сразу с кубером :)

Подписывайся на новый докер бету который сразу с кубером :)

эээээ

щьто????

Вот что :)

Kubernetes становится все популярнее, и сегодня Docker Inc анонсировали поддержку использования Kubernetes в качестве оркестратора наряду с ранее используемым Swarm в Docker platform. https://goo.gl/MrRFY2

И слайд выше я постил

А должны? Я вот читаю и не вижу что должны

странно,.. может я этот текст неправильно понимаю? я вот это имею ввиду: например, если у вас есть служба «my-service» в пространстве имен kubernetes «my-ns», создается запись dns для «my-service.my-ns». pods, которые существуют в пространстве имен «my-ns», должны быть в состоянии найти его, просто выполнив поиск имени для «my-service». которые существуют в других пространствах имен, должны иметь название «my-service.my-ns». результатом этих поисков имен является кластер ip.

пользовал кто https://kubernetes.io/docs/tasks/debug-application-cluster/local-debugging/ ?

У тебя сервис по лейблам смотрит на поды, сервис имеет запись и адрес. Если тебе нужно ходить из подов другого приложения в этот сервис, то сервис будет резолвится по service_name.namespace. Посмотри внутри подов /etc/resolf.conf в разных ns.

Вопрос селдующий - только начинаю разбираться с сабжом. Задача такая - есть сервера, около 100, надо на каждый развернуть какие-то докер контейнеры, но у каждого под каждый сервер - свои настройки (из гита, либо дефолтные общие). Подходит ли кубер для этого?

100 серверов с одним приложением? 100 приложений? все сервера хочешь в один кластер загнать?

У тебя сервис по лейблам смотрит на поды, сервис имеет запись и адрес. Если тебе нужно ходить из подов другого приложения в этот сервис, то сервис будет резолвится по service_name.namespace. Посмотри внутри подов /etc/resolf.conf в разных ns.

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

вот я хочу понять. это устаревшая тема или у меня что-то поломано

вот я хочу понять. это устаревшая тема или у меня что-то поломано

service_name.namespace.cluster.local попробуй

Kubernetes становится все популярнее, и сегодня Docker Inc анонсировали поддержку использования Kubernetes в качестве оркестратора наряду с ранее используемым Swarm в Docker platform. https://goo.gl/MrRFY2

ах ты ж боже ты мой, какие пупсы

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

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

покажи как неработает

service_name.namespace.cluster.local попробуй

вообще для второго пода, к которому не нужен доступ снаружи, а нужен только из соседнего пода логично было бы вообще не создавать привязки к сервису. в голом докере это работает - под резолвится по имени пода и всё ок. в старой версии кубера это работало (которая поднималась два года назад). а сейчас, в 1.6.1 у меня какие то траблы.

сдохнет у тебя под, ты пойдешь изменять конфиг подключения?

Вот от судя и сервисы.

вообще для второго пода, к которому не нужен доступ снаружи, а нужен только из соседнего пода логично было бы вообще не создавать привязки к сервису. в голом докере это работает - под резолвится по имени пода и всё ок. в старой версии кубера это работало (которая поднималась два года назад). а сейчас, в 1.6.1 у меня какие то траблы.

Statefulsets используешь? тогда сделай сервис который собирает поды сервиса и обращайся к нему по pod_name.service_name.namespace.cluster.local

покажи как неработает

в деплойменте поднимается один под spec: hostname: nginx containers: - image: nginx:1.13.5-alpine name: nginx и точно так же второй (пхп) из пода пхп не резолвится нгинкс резолвится только по имени пода (типа "nginx-3238736888-t0g6b") хотя я ему в конфиге явно указываю name: nginx - вот по этому имени он и должен резолвиться... наверное)))... по крайней мере два года назад так работало

сдохнет у тебя под, ты пойдешь изменять конфиг подключения?

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

так для этого сервис создать нужно

в деплойменте поднимается один под spec: hostname: nginx containers: - image: nginx:1.13.5-alpine name: nginx и точно так же второй (пхп) из пода пхп не резолвится нгинкс резолвится только по имени пода (типа "nginx-3238736888-t0g6b") хотя я ему в конфиге явно указываю name: nginx - вот по этому имени он и должен резолвиться... наверное)))... по крайней мере два года назад так работало

да и недолжен, делай сервис nginx

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

https://kubernetes.io/docs/concepts/services-networking/service/

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

А нафига тебе php и nginx в разных подах? Засунь их в один под, и пусть по localhost общаются

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

ссылка выше, первое предложение.

А нафига тебе php и nginx в разных подах? Засунь их в один под, и пусть по localhost общаются

это просто пример... пусть будет пхп и мемкэш

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

да нафиг тут сервис не нужен. Тут нужно просто деплоймент сделать с одним подом и двумя контейнерами

да нафиг тут сервис не нужен. Тут нужно просто деплоймент сделать с одним подом и двумя контейнерами

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

по имени - болт

по айпишнику или имени пода - они при редеплое меняются

из пода к поду через сервис. Из контейнера пода к контейнеру того же пода по 127.0.0.1

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

покажи когда есть сервис пинги и ресолвы из контейнеров, ну и да подебаж днс в кубе на общую работоспособность

root@rasc-3732246749-h813n:/# nslookup nginx-svc Server: 10.3.0.254 Address: 10.3.0.254#53 ** server can't find nginx-svc: SERVFAIL

root@rasc-3732246749-h813n:/# nslookup nginx-svc.cluster.local Server: 10.3.0.254 Address: 10.3.0.254#53 ** server can't find nginx-svc.cluster.local: NXDOMAIN

nginx-svc.NAMESPACE.cluster.local:

root@rasc-3732246749-h813n:/# nslookup nginx-svc.nginx.cluster.local Server: 10.3.0.254 Address: 10.3.0.254#53 ** server can't find nginx-svc.nginx.cluster.local: NXDOMAIN

root@rasc-3732246749-h813n:/# nslookup nginx-svc.nginx.svc.cluster.local Server: 10.3.0.254 Address: 10.3.0.254#53 Name: nginx-svc.nginx.svc.cluster.local Address: 10.3.222.29

kubectl -n nginx get svc

вот такой длинный вариант корявый работает. остальные - нет

почему корявый?

отлучусь на 30 мин )))

так и формирует днс кубер внутри себя

так а у тебя nginx и пых в разных неймспейсах ?

*имясервиса*.*имяспейса*.svc\pod.domain.local

вот такой длинный вариант корявый работает. остальные - нет

если в одном NS, то достаточно имени сервиса, если в разных, то полный адрес, вот как Михаил выше написал