Andor
"готовые плейбуки" это как "стейбл чарты"
𝚔𝚟𝚊𝚙𝚜
в каждой избушке свои погремушки :)
Andor
Andrey
𝚔𝚟𝚊𝚙𝚜
Михаил
G72K
Значит есть куда копать :)
Михаил
Михаил
Это перебор)
Andor
G72K
Сложно придумать запись лаконичнее
Andor
Сделаю .deep_merge
G72K
А если надо перезаписать в глубине список? Или обработать?
Andor
Берёшь и обрабатываешь, не понял в чём сложность
G72K
Сложности нет, просто больше писать придется
Andor
Покажи пример
G72K
Перезапись: { a: {b: [1,2,3]} }
Andor
Как удалить 2 из массива внутри?
G72K
Обработать: { a: {b: procesFunc(super.b) } }
Andor
Что такое super?
G72K
Пройдите jsonnet.org туториал
Andor
Пройти туториал по рубям
Andor
Уровень нашей дискуссии мне уже нравится
Andor
Давай продолжать
G72K
Не могу, потом
Михаил
Andor
Вроде на крестах реализация от гугла
Andor
Всё ещё не вижу где это фичастей тех же рубей
G72K
У меня нет цели вас переубедить )
Andor
Мы с тобой на "вы" не переходили! :)
Alexander
всем привет!
есть проблема с дисконнектом для kubectl exec -it pod bash
так kubectl exec -it pod -- ping 8.8.8.8 тоже со временем вылетает и при этом пинг работает в контейнере после дисконнекта
ещё заметил, что на удалённых кластерах (в облаках) такая проблема гораздо чаще проявляется - например, через 30 сек повисает терминал и не восстанавливает коннект
вопрос: как лечить?
устроит решение, при котором запущенные из сессии процессы прерывались бы после дисконнекта
аргумент --request-timeout как написано в доке по умолчанию 0, что равно бесконечной сессии
Andrei
не погу поставить cert-manager пишет
failed: customresourcedefinitions.apiextensions.k8s.io "certificates.certmanager.k8s.io" already exists
удаляю
kubectl delete customresourcedefinitions.apiextensions.k8s.io certificates.certmanager.k8s.io clusterissuers.certmanager.k8s.io issuers.certmanager.k8s.io
пытаюсь установить тоже самое
Rainbow
kubectl get customresourcedefinitions
что показывает после удаления?
Andrei
пусто
Rainbow
а ставили через helm?
Rainbow
может там tiller пытается судурожно восстановить что вы удаляете через kubectl delete
Andrei
может , он у меня был установлен так
helm install stable/cert-manager \
--namespace test \
--tiller-namespace=test \
--set ingressShim.defaultIssuerName=letsencrypt-prod \
--set ingressShim.defaultIssuerKind=ClusterIssuer \
--set rbac.create=false \
--set serviceAccount.create=false
потом удалил helm --tiller-namespace=test delete cert-manager
и не могу поставить
Rainbow
helm delete --purge может, я не helmетовод
Andrei
да там были старые что удалял и тот что не деплоиться но после чистки не помогло
Rainbow
kubectl get --all-namespaces
ищите
Andrei
kubectl get customresourcedefinitions --all-namespaces ни где нет, такое ощущение что он перед деплоем себя ставит их и сам же на них ругаеться может нужно удалить сертификаты которые он уже успел раздать перед удалением
Andrei
похоже проблема новая https://github.com/helm/charts/issues/9289
G72K
Alexander
Anonymous
nodeagent падает с казалось бы очевидной ошибкой но как ее пофиксить? ставил istio с cni из helm конфигов
Stas
а цитадель поднялась?
Anonymous
Stas
ну вы посмотрите, что нод агент ее сервис вообще видет
Stas
https://istio.io/docs/reference/commands/node_agent/
Stas
ему все нормально в конфиг подставилось?
Stas
это и есть цитадель
Stas
посмотри ссылку выше про конфиги нод агента
Anonymous
я чтото посмотрел в дефолтном конфиге он вырублен вообще, он сильно нужен? я просто хочу траффик между сервисами мониторить но графана почему то везде пишет N/A
Anonymous
но судя по kubectl describe у всех подов есть istio proxy
Mikhail
Гайс, где можно за магию роутинга в кубере почитать? Очень интересует следующий вопрос: я распылил через kubespray с calico на 3 машины трёхмастеровый кластер, на 2 машины всё хорошо встало, на одну - нет. Системные поды падают с ошибкой (пример из дашборда) Error while initializing connection to Kubernetes apiserver.... Reason: Get https://10.233.0.1:443/version: dial tcp 10.233.0.1:443: getsockopt: connection refused. На рабочих машинах ни в ss -nltp, ни в iptables -S нет упоминания ни о 443 порту, ни об интерфейсе kube-ipvs0, ни о 10.233.0.1. На рабочих машинах если курлить https://10.233.0.1:443/version, то норм отвечает. Как туда прилетает трафик - большая загадка. Почему на 2 машинах всё хорошо, а на третьей не хочет - загадка ещё большая. Вангую, что что-то осталось с прошлых инсталляций, но найти что - не могу
Puma
Удали и разверни заново
Mikhail
Раз 6 уже так делал. До этого тут тоже были попытки что-то сделать, какие-то файлы оставались. Причём то на той, то на этой машине. То /etc/ssl/etcd/ и /var/lib/etcd/ хранили старые IP адреса, то в /etc/systemd/system/kubelet.service.d/ настройки kubelet перешибались и из kubelet.env инфа не подгребалась. Теперь ещё что-то. Систему всю переставлять не вариант
Puma
Почему не вариант нынче это просто и быстро
Никита
Гайс, где можно за магию роутинга в кубере почитать? Очень интересует следующий вопрос: я распылил через kubespray с calico на 3 машины трёхмастеровый кластер, на 2 машины всё хорошо встало, на одну - нет. Системные поды падают с ошибкой (пример из дашборда) Error while initializing connection to Kubernetes apiserver.... Reason: Get https://10.233.0.1:443/version: dial tcp 10.233.0.1:443: getsockopt: connection refused. На рабочих машинах ни в ss -nltp, ни в iptables -S нет упоминания ни о 443 порту, ни об интерфейсе kube-ipvs0, ни о 10.233.0.1. На рабочих машинах если курлить https://10.233.0.1:443/version, то норм отвечает. Как туда прилетает трафик - большая загадка. Почему на 2 машинах всё хорошо, а на третьей не хочет - загадка ещё большая. Вангую, что что-то осталось с прошлых инсталляций, но найти что - не могу
На каждой ноде кубспрей поднимает под с балансером на nginx, где в качестве апстримов аписерверы. Посмотри поды в kube-system, посмотри логи этих балансеров.
Никита
Гайс, где можно за магию роутинга в кубере почитать? Очень интересует следующий вопрос: я распылил через kubespray с calico на 3 машины трёхмастеровый кластер, на 2 машины всё хорошо встало, на одну - нет. Системные поды падают с ошибкой (пример из дашборда) Error while initializing connection to Kubernetes apiserver.... Reason: Get https://10.233.0.1:443/version: dial tcp 10.233.0.1:443: getsockopt: connection refused. На рабочих машинах ни в ss -nltp, ни в iptables -S нет упоминания ни о 443 порту, ни об интерфейсе kube-ipvs0, ни о 10.233.0.1. На рабочих машинах если курлить https://10.233.0.1:443/version, то норм отвечает. Как туда прилетает трафик - большая загадка. Почему на 2 машинах всё хорошо, а на третьей не хочет - загадка ещё большая. Вангую, что что-то осталось с прошлых инсталляций, но найти что - не могу
>https://10.233.0.1:443/version
Всю жизнь же 6443 было.
Mikhail
Mikhail
Mikhail
Причём, чёрт побери, отвечает на 443. При этом его никто не слушает, судя по утилитам линукса. ПРИ ЭТОМ там же засетаплен ingress-nginx (конфигом kubespray), но его портов тоже не видно. ПРИ ЭТОМ этот же nginx на битой машине тоже крашится от недоступности KubeAPI
Никита
Так, я затупил чёт. Там всё правильно, это он у тебя в сервис ходит, там трансляция портов.
Mikhail
Никита
Mikhail
Ах вот оно как... И всё же, где можно про это НОРМАЛЬНО почитать? А то как-то отрывками по конференциям и всё что-то не то
Никита
Кажется, что-то опять изменилось, ну ок.
Кароч, сейчас у тебя все поды коннектятся к сервису kubernetes в default неймспейсе. Если ты ему сделаешь describe, то увидишь эндпоинты. Покурли их.
Никита
Если эндпоинты доступны — проблема с сервисами. Наверняка какие-нить iptables-правила либо от предыдущих установок остались, либо это какой-нить firewalld считает себя самым умным и привозит говна.