да

я против ухода в личку для обсуждения кубернетисов :)

У кого-нибудь есть опыт публикации сервисов на кубернетисе в bare-metal конфиге? Без gcloud/aws. Есть тонна вопросов по ингрессу и тому, как обойтись без внешнего днса, что используется в указанных сервисах

У нас перед куб кластерами на баре метал стоят haproxy. Раз в минуту самописная поделка на питоне ходит в кубы через апи, получает список сервисов и генерит конфиг для haproxy из темплейта. Сервисы nodeport. ingress не используем. Где-то выше уже описывал.

У нас перед куб кластерами на баре метал стоят haproxy. Раз в минуту самописная поделка на питоне ходит в кубы через апи, получает список сервисов и генерит конфиг для haproxy из темплейта. Сервисы nodeport. ingress не используем. Где-то выше уже описывал.

Поищу. Интересно!

@zigmundkz а в чем плюсы? Кроме того, что это позволяет творить дичь, вместо подгонки проекта под стандарты.

Поищу. Интересно!

Да искать нечего, почти то же самое сейчас и написал.

@zigmundkz а в чем плюсы? Кроме того, что это позволяет творить дичь, вместо подгонки проекта под стандарты.

Фэйл домен = кластер.

Кластера в разных дц

Дц могут отъебнуть

почему не использовать haproxy -> ingress?

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

То есть в нашем случае это было бы haproxy - ingress - service

ingress удобно роутит трафик внутри кластера. Просто снаружи выставить haproxy, чтобы править особенности руками, а базовые штуки отдать ingress

В нашем случае это лишняя сущность

То есть в нашем случае это было бы haproxy - ingress - service

да, я и спрашивал почему не так. Просто интересно.

чтобы новый сервис развернуть нужно идти к админу?

Нет

С ingress нужно дописать ресурс, а у вас как? К примеру новый сервс хочу замапить на /private/test/service

Через лейблы и аннотации сервис автоматом паблишится на хапрокси

Питонокостыль выбирает соответствующие сервисы по лейблам и берет настройки из аннотаций.

кажется этот костыль просто повторяет работу ингресса

тоже самое же делает ingress... 1 в 1. Только в виде ресурса ingress, а не демона сверху.

Да, по сути так и есть. По этому ингресс и не используем в данный момент. Возможно в даньшейм логику переложим на ингресс, а на внешних балансировщиках костыль уберем. Сейчас устраивает такой вариант.

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

У ingress только один минус - он жутко простой для пользователя. Можно забыться и так же просто наломать дров https://habr.com/company/southbridge/blog/340238/

ingress интегрируется с cert manager выпускать сертификаты letsencrypt становится так же просто, как и сам ingress. Один из самых жирных плюсов для меня.

Для кучи вкуснях типа service worker нужен https. для staging, test поддоменов и тп.

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

Чтобы часть подов переехала на ноый нод?

поды не перескедулятся сами без пинка

replicas можно поменять если сильно хочется увидеть

Ещё проблемка

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

но она Ready,SchedulingDisabled

У ingress только один минус - он жутко простой для пользователя. Можно забыться и так же просто наломать дров https://habr.com/company/southbridge/blog/340238/

Жесть какая, там такие детские проблемы, я думал все это уже в коммон классах ансиблей сидит у всех

но она Ready,SchedulingDisabled

kubectl describe node и посмотри в taints

ну или kubectl uncordon, если c кондишенами все норм

Жесть какая, там такие детские проблемы, я думал все это уже в коммон классах ансиблей сидит у всех

ну так не корректно говорить. То же самое что "хаха ansible", мы давно на "Amasow EKS нищеброды". Это абстракная фраза EKS крайне дорог =)

ну так не корректно говорить. То же самое что "хаха ansible", мы давно на "Amasow EKS нищеброды". Это абстракная фраза EKS крайне дорог =)

Непонял

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

Народ, кто подскажет, если rbd поддерживает ReadWriteOnce и ReadOnlyMany, это значит я могу писать с одного контейнера и читать с многих или выбирать нужно только одно?! По логике понятно что первое, но на всякий случай уточняю.

Народ, кто подскажет, если rbd поддерживает ReadWriteOnce и ReadOnlyMany, это значит я могу писать с одного контейнера и читать с многих или выбирать нужно только одно?! По логике понятно что первое, но на всякий случай уточняю.

только одно

только одно

печаль-беда, спс

почему может не резолвиться имя сервиса по service_name.namespace.svc.cluster.local, в то время как резолвится по service_name.namespace.svc.имя_кластера_которое_указал_при_установке_в_kubespray?

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

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

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

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

Не всегда. В случаае, если под, в котором ты хочешь зарезолвить сервис, находится в том же namespace что и сервис, который ты резолвиш, то можно использовать просто <имя_сервиса>, вместо полного <имя_сервиса>. <имя_namespace>. <имя_кластера>.local

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

короткие имена ж работают

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

так в search /etc/resolv.conf нету cluster.local в случаем когда указывавешь другое при установке

а кто то kubespray'ем катал node_labels ? делаю вроде бы all: hosts: knode1: node_labels: cpuint: true а не работает

Не всегда. В случаае, если под, в котором ты хочешь зарезолвить сервис, находится в том же namespace что и сервис, который ты резолвиш, то можно использовать просто <имя_сервиса>, вместо полного <имя_сервиса>. <имя_namespace>. <имя_кластера>.local

а если нет?

так в search /etc/resolv.conf нету cluster.local в случаем когда указывавешь другое при установке

при установке я указываю имя кластера, которое отражает его предназначение. Сейчас я еще раз прочитал там комент https://github.com/kubernetes-incubator/kubespray/blob/master/inventory/sample/group_vars/k8s-cluster.yml#L121 написано, что также будет использоваться как DNS domain

но непонятно, как мне иметь и имя кластера вменяемое, и cluster.local, чтобы резолвился. Или я не должен этого хотеть?

укажите в конфиге спрея другое имя или вам жестко нужно cluster.local ?

ко мне пришел разработчик, показывает документацию вот эту https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/ и говорит, почему у меня в поде не резолвится "my-svc.my-namespace.svc.cluster.local" как там написано

А он не жаловался что IP не сходятся?

он еще добавил, что "а вот в том кластере у нас работает, поэтому мы это зашили в чарт"

лично мне не совсем ясна ситуация с подстрокой "cluster.local". Это просто пример, или это руководство к действию?

У меня это домен моей компании

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

Это разве не внутренний домен?

поидее ты можешь указать его как домен компании, а у себя в основном DNS сказать что всё что svc.cluster.local форвардить на kube-dns. не ?

ERROR: S client not available

и дальше уже из одного dns доступаться. и обеспечивать роутинг и т д

поидее ты можешь указать его как домен компании, а у себя в основном DNS сказать что всё что svc.cluster.local форвардить на kube-dns. не ?

я это не понял

где указать, где у себя и что такое основной DNS

если правильно понял https://kubernetes.io/blog/2017/04/configuring-private-dns-zones-upstream-nameservers-kubernetes/

Эм, это внутренние dns для контейнеров, смысл зашивать FQDN, когда обращаться можно в сервис по названию сервиса или по комбинации названия сервиса и namespace?

если правильно понял https://kubernetes.io/blog/2017/04/configuring-private-dns-zones-upstream-nameservers-kubernetes/

да, я примерно такое и имел ввиду.

Эм, это внутренние dns для контейнеров, смысл зашивать FQDN, когда обращаться можно в сервис по названию сервиса или по комбинации названия сервиса и namespace?

Думаю, просто чтобы разрабы не приходили. И не потому что они достают, а чтобы им удобно было.

Ну так себе решение игнорировать best practices

где указать, где у себя и что такое основной DNS

DNS policies can be set on a per-pod basis. Currently Kubernetes supports the following pod-specific DNS policies. These policies are specified in the dnsPolicy field of a Pod Spec.

я таки не совсем уловил этот ответ и эту статью относительно моего вопроса. Мне не нужно резолвить существующую доменную зону. Мне нужно резолвить cluster.local. Как в документации: my-svc.my-namespace.svc.cluster.local

Кто нибудь пользовался longhorn от rancher?

есть отзывы?)

а если нет?

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

я таки не совсем уловил этот ответ и эту статью относительно моего вопроса. Мне не нужно резолвить существующую доменную зону. Мне нужно резолвить cluster.local. Как в документации: my-svc.my-namespace.svc.cluster.local

Так же в документации написано, что можно задать зону отличную от имени кластера, за это отвечает переменная domain_name, судя по всему. https://github.com/kubernetes-incubator/kubespray/blob/master/docs/vars.md

ага "default is cluster.local"

видимо имеется ввиду "default is cluster.local because default cluster name is cluster.local" :)

выходит, если поменял cluster_name, но хочешь оставить domain_name=cluster.local, то укажи это явно

Ага, судя по документации

ну как раз таки из документации это никак не вытекает

нигде же не написано, что если поменять cluster_name, то это повлечет и смену domain_name

Согласен, документация не до конца ясна, пока не начнешь попой чуять такие места. :)

нигде же не написано, что если поменять cluster_name, то это повлечет и смену domain_name

Что мешает поверить на что влияет ваше изменение параметра? Сам просто делаю так всегда

https://blog.alexellis.io/introducing-the-openfaas-operator/amp/?__twitter_impression=true

привет всем. кто-то обновлял куб на 1.11?

Всем привет. пыта.сь создать кластер кубернетес и получаю оишбку на ноде, с которой хочу добавиться: [discovery] Trying to connect to API Server "192.168.0.9:6443" [discovery] Created cluster-info discovery client, requesting info from "https://192.168.0.9:6443" [discovery] Failed to request cluster info, will try again: [configmaps "cluster-info" is forbidden: User "system:anonymous" cannot get configmaps in the namespace "kube-public"] мастер нода доступна со слэйва, iptables выключен. вот такие поды запущены на мастере. в чем проблема может быть? root@us1:~# kubectl get po -n kube-system NAME READY STATUS RESTARTS AGE etcd-us1 1/1 Running 2 1d kube-apiserver-us1 1/1 Running 5 1d kube-controller-manager-us1 1/1 Running 2 1d kube-flannel-ds-g5wtg 1/1 Running 21 1d kube-scheduler-us1 1/1 Running 2 1d куб ставлю версии 1.11

https://github.com/kubeflow/pytorch-operator С пополнением

https://github.com/kubeflow/pytorch-operator С пополнением

Для чего эта штука?

Для чего эта штука?

Для дата сайнетистов, нейроночки

Для дата сайнетистов, нейроночки

Спс.Крутяк

Всем привет! А кто нибудь настраивал для куба в liveness probe два или более портов для отслеживания? В доке непонятно. Такое ощущение, что больше одного нельзя https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

свой костылек можешь подсадить, который будет в оба порта тыкать