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

Magistr
17.10.2017
09:48:03

Maksim
17.10.2017
09:49:18

Zon
17.10.2017
09:49:56

Paul
17.10.2017
09:50:22
щьто????

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.

Алексей
17.10.2017
10:05:03

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

Алексей
17.10.2017
10:09:24

Paul
17.10.2017
10:10:00

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

Magistr
17.10.2017
10:12:09

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

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

Алексей
17.10.2017
10:16:11

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
так для этого сервис создать нужно

Magistr
17.10.2017
10:18:35

Anton
17.10.2017
10:19:03

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

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

Ivan
17.10.2017
10:19:29

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

Ivan
17.10.2017
10:31:47
пока не могу найти, что именно

Ivan
17.10.2017
10:34:26

Alexander
17.10.2017
10:49:43

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

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)

Ivan
17.10.2017
11:08:33

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

Ivan
17.10.2017
11:10:18

Google

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

Ivan
17.10.2017
11:12:07
и резолв внутри пода
root@rasc-3732246749-h813n:/# cat /etc/resolv.conf
nameserver 10.3.0.254
options ndots:5
айпишник сответствует сервисному айпи куб-днс
—cluster-domain = cluster.local


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

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