@kubernetes_ru

Страница 295 из 958
Zon
17.10.2017
08:13:09


Maksim
17.10.2017
08:14:07
ессено, учитывая что туда влили кучу бабла гугл и ред хат

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

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

Google
Ivan
17.10.2017
09:35:28
точно так же. просто потом образы едут в кубер

Oleg
17.10.2017
09:38:11
Есть вариант развернуть реальный кубер удаленно, но дебажить свои сервисы локально?

Ivan
17.10.2017
09:39:02
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) резолвятся, а поды по вышеописанной схеме - нет(( как это починить?

Zon
17.10.2017
09:49:56
При локальной разработке использую docker-compose. Как локально разрабатывать с кубером?
Подписывайся на новый докер бету который сразу с кубером :)

Zon
17.10.2017
09:50:47
Вот что :)

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

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

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

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

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

Ivan
17.10.2017
10:06:29
вот я хочу понять. это устаревшая тема или у меня что-то поломано

Алексей
17.10.2017
10:09:24
Ivan
17.10.2017
10:10:48
да, и так тоже не работает. я вчера находил в документации, что это больше не поддерживается... а тут написано, что должно работать. видимо документация не согласована

Ivan
17.10.2017
10:14:37
service_name.namespace.cluster.local попробуй
вообще для второго пода, к которому не нужен доступ снаружи, а нужен только из соседнего пода логично было бы вообще не создавать привязки к сервису. в голом докере это работает - под резолвится по имени пода и всё ок. в старой версии кубера это работало (которая поднималась два года назад). а сейчас, в 1.6.1 у меня какие то траблы.

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

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

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

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

Anton
17.10.2017
10:18:33
так для этого сервис создать нужно

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

Алексей
17.10.2017
10:19:07
А нафига тебе php и nginx в разных подах? Засунь их в один под, и пусть по localhost общаются

Google
Ivan
17.10.2017
10:19:35
вообще микросервисная архитектура подразумевает более одного контейнера и они между собой должны как то общаться...

Алексей
17.10.2017
10:20:09
да нафиг тут сервис не нужен. Тут нужно просто деплоймент сделать с одним подом и двумя контейнерами

Ivan
17.10.2017
10:20:43
по имени - болт

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

Алексей
17.10.2017
10:21:17
из пода к поду через сервис. Из контейнера пода к контейнеру того же пода по 127.0.0.1

Magistr
17.10.2017
10:21:46
только вот мне кажется, тут можно обойтись без сервиса.... но если нет - то ок. я готорв создавать сервисы для всех подов... только ведь и с сервисами та же херня
покажи когда есть сервис пинги и ресолвы из контейнеров, ну и да подебаж днс в кубе на общую работоспособность

Ivan
17.10.2017
10:22:55
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

Алексей
17.10.2017
10:23:28
nginx-svc.NAMESPACE.cluster.local:

Ivan
17.10.2017
10:23:32
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

Алексей
17.10.2017
10:23:59
kubectl -n nginx get svc

Ivan
17.10.2017
10:24:03
вот такой длинный вариант корявый работает. остальные - нет

Mikhail
17.10.2017
10:24:22
почему корявый?

Ivan
17.10.2017
10:24:25
отлучусь на 30 мин )))

Mikhail
17.10.2017
10:24:28
так и формирует днс кубер внутри себя

Magistr
17.10.2017
10:24:43
так а у тебя nginx и пых в разных неймспейсах ?

Mikhail
17.10.2017
10:24:56
*имясервиса*.*имяспейса*.svc\pod.domain.local

Google
Алексей
17.10.2017
10:27:44
вот такой длинный вариант корявый работает. остальные - нет
если в одном NS, то достаточно имени сервиса, если в разных, то полный адрес, вот как Михаил выше написал

Ivan
17.10.2017
10:34:26
пока не могу найти, что именно
внимательно посмотри на то что ты скинул и найди отличия

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

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

Alexander
17.10.2017
11:03:21
резолв конф внутри глянуть

Maksim
17.10.2017
11:03:24
--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)

Maksim
17.10.2017
11:09:06
видимо да
Сразу так бы и написал) что работает только fqdn, а вот short names не канает

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

Ivan
17.10.2017
11:09:21
Maksim
17.10.2017
11:09:56
проверяй ключи kubelet —cluster-dns и —cluster-domain

Google
Ivan
17.10.2017
11:10:29
посмотрел. отличия в днс-имени
Вот, второй лукап у тебя по полному имени, а теперь попробуй короткий по service-name.namespace. В твоем примере nginx-svc.nginx

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

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

Ivan
17.10.2017
11:18:14
не то=)

Maksim
17.10.2017
11:20:27
да нет то

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

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

vladget
17.10.2017
12:10:29
делаю нагрузоное, микросервисы, синхронный 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 Сталкивались? Перегрузка по сети?

Anton
17.10.2017
12:15:25
нагрузочное в сторону kube-api?

Ivan
17.10.2017
12:16:45
сделай 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)

Maksim
17.10.2017
12:17:44
не вижу search....попробуй перезапустит кублет, и пересоздать под

Страница 295 из 958