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

за одно с 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, то достаточно имени сервиса, если в разных, то полный адрес, вот как Михаил выше написал

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

в одном

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

вот видимо у меня поломано что то.

пока не могу найти, что именно

пока не могу найти, что именно

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

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

не понял о чем речь

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

Сорри отвлёкся. Так что не так? Тут написано что сервис имеет запись my-service.my-ns, поды в my-ns должны найти его по my-service, поды в других ns находят его по my-service.my-ns. Тут не говорится что lookup резолвит ip подов

Если ковырнуть механизмы работы DNS и кублета то всё ещё проще становится

пока не могу найти, что именно

Я кажись понял. У тебя не работают коротный dns имена, но работает fqdn?

резолв конф внутри глянуть

--cluster-dns stringSlice Comma-separated list of DNS server IP address. This value is used for containers DNS server in case of Pods with "dnsPolicy=ClusterFirst". Note: all DNS servers appearing in the list MUST serve the same set of records otherwise name resolution within the cluster may not work correctly. There is no guarantee as to which DNS server may be contacted for name resolution. —cluster-domain string Domain for this cluster. If set, kubelet will configure all containers to search this domain in addition to the host's search domains

Всё проще

Ключи от kubelet

первый отвечает за прописывание nameserver в resolv.conf второй за search в resolv.conf (второе формирует short names)

Я кажись понял. У тебя не работают коротный dns имена, но работает fqdn?

видимо да

видимо да

Сразу так бы и написал) что работает только fqdn, а вот short names не канает

Вон выше пилюля

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

посмотрел. отличия в днс-имени

проверяй ключи kubelet —cluster-dns и —cluster-domain

Сорри отвлёкся. Так что не так? Тут написано что сервис имеет запись my-service.my-ns, поды в my-ns должны найти его по my-service, поды в других ns находят его по my-service.my-ns. Тут не говорится что lookup резолвит ip подов

как так? написано же - The result of these name lookups is the cluster IP.

посмотрел. отличия в днс-имени

Вот, второй лукап у тебя по полному имени, а теперь попробуй короткий по service-name.namespace. В твоем примере nginx-svc.nginx

если не работает, как выше писали смотри настройки

и резолв внутри пода

Сразу так бы и написал) что работает только fqdn, а вот short names не канает

я не знал, что это так называется

Вот, второй лукап у тебя по полному имени, а теперь попробуй короткий по service-name.namespace. В твоем примере nginx-svc.nginx

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

и резолв внутри пода

root@rasc-3732246749-h813n:/# cat /etc/resolv.conf nameserver 10.3.0.254 options ndots:5

айпишник сответствует сервисному айпи куб-днс

--cluster-dns stringSlice Comma-separated list of DNS server IP address. This value is used for containers DNS server in case of Pods with "dnsPolicy=ClusterFirst". Note: all DNS servers appearing in the list MUST serve the same set of records otherwise name resolution within the cluster may not work correctly. There is no guarantee as to which DNS server may be contacted for name resolution. —cluster-domain string Domain for this cluster. If set, kubelet will configure all containers to search this domain in addition to the host's search domains

--cluster-dns сответствует сервисному айпи куб-днс

—cluster-domain = cluster.local

не то=)

да нет то

этого должно быть достаточно, что бы кубелет делал нужные записи в resolv.conf

сделай kubectl exec rasc-3732246749-h813n — cat /etc/resolv.conf

делаю нагрузоное, микросервисы, синхронный REST http: TLS handshake error from 172.20.3.3:31861: EOF Error syncing deployment stage/my-microservice: Operation cannot be fulfilled on deployments.extensions "my-microservice": the object has been modified; please apply your changes to the latest version and try again Сталкивались? Перегрузка по сети?

нагрузочное в сторону kube-api?

сделай kubectl exec rasc-3732246749-h813n — cat /etc/resolv.conf

root@rasc-3732246749-h813n:/# cat /etc/resolv.conf nameserver 10.3.0.254 options ndots:5 уже было выше ))) (14,14)

не вижу search....попробуй перезапустит кублет, и пересоздать под