« Rev
@kubernetes_ru   1734
Fwd »


Rainbow
Но как давать человеку ссылку на образ тогда?
сразу видно человек спамеры не писал
Andor
А пока придётся ждать
Rainbow
Кстати "adwords" сделали уже для для tg? никто не сталкивался?
Dmytro
С какой целью интересуетесь?
Vladimir
кто еще со мной на вебинаре по кубернетесу сейчас? )
Vladimir
немного инсайда
Andor
это вообще-то из документации табличка
Sergey
😂
Gabriel
Тут наверное имелось в виду, что инсайд вебинара, а не таблички
Gabriel
Потому что я сперва тоже не уловил
Евгений
немного инсайда
Без этого инсайда я бы никогда не узнал, что в etcd raft
Andor
а ещё что он написан на голанге
Vladimir
😂разумеется инсайд вебинара. пока ничего нового, вы и так все тут знаете)
Andrey
как переставить helm в кластере без удаления релизов?
Andor
тебе нужен ранчер для этого
Andrey
мне интересно helm reset --force и потом helm init подхватит существующие релизы или нет
Dmytro
Не знаю как сейчас, раньше удаление тиллера и установка заново ничего не ломала
Dmytro
Там же в конфигмапе хранится все
Andrey
я тиллеру хочу ns поменять, придётся конфигмапы переносить тогда?
Dmytro
Может быть конечно сейчас при reset —force трется конфигмп
Dmytro
Но тогда это наверняка в документации дорлжно быть описано
Andrey
пытался найти в доках, увидел только загадочную фразу что --force удаляет даже есть релизы
Andrey
перенести в другой ns и выключить tls
Andrey
Не совсем твой кейс, наверное, но недавно интересную статью про извращения с Helm постили. Про УСЫНОВЛЕНИЕ. https://habr.com/ru/company/flant/blog/441964/
Vadim
Не совсем твой кейс, наверное, но недавно интересную статью про извращения с Helm постили. Про УСЫНОВЛЕНИЕ. https://habr.com/ru/company/flant/blog/441964/
То есть что-то установленное потом переводится под управление Helm, чтобы оператор кластера мог управлять?
Andrey
То есть что-то установленное потом переводится под управление Helm, чтобы оператор кластера мог управлять?
Ну и просто в релиз любой любые объекты можно впихнуть. Примения разные можно найти.
Vadim
Да.
А покажите сырцы, а то я только addons operator нашел :)
Andrey
А покажите сырцы, а то я только addons operator нашел :)
А, это не на поток поставлено. Мы просто таким образом "съедаем" объекты, которые команды насоздавали в отдельных проектах, если обобщаем всё в addon-operator наш. https://gist.github.com/alexey-igrychev/06a8a9705b7cb122b24cc5a620e5e4d6
Andrey
Боже, как его лицо расфигачило-то.
Alex
Сделал голый кластер, проинитил хелм, установил релиз. Удалил хелм, перенёс тиллер в другой неймспейс, сделал хелм инит туда. После этого клиент тиллер тупо не видит, даже с --tiller-namespace.
Alex
Ну, и вот такое ещё
Alex
helm list —tiller-namespace helm
Alex
Error: configmaps is forbidden: User "system:serviceaccount:helm:default" cannot list resource "configmaps" in API group "" in the namespace "helm"
Alex
Если опять делаю helm reset и helm init с установкой в kube-system - встаёт нормально и видит ранее установленный релиз
Antlar
там надо в рбак конфиг дописать какую-то шляпу, не помню уже
Alex
эта шляпа
Alex
kubectl create serviceaccount --namespace helmns tiller kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=helmns:tiller helm init --service-account tiller --upgrade
Alex
Шляпа ошибку указанную выше убирает, но старый релиз новый тиллер не видит
Alex
Просмотрел ресурсы - тиллер своих конфигмапов не создаёт
Alex
Как заставить новый тиллер видеть старые релизы - для меня сейчас загадка
Alex
Because Tiller stores its data in Kubernetes ConfigMaps, you can safely delete and re-install Tiller without worrying about losing any data.
Alex
Но я этих конфигмапов в упор не вижу!
Alex
Или имеются в виду конфигмапы релизов?
Andrey
kubectl get configmap -l "OWNER=TILLER" --all-namespaces
Artyom
Коллеги, день добрый, подскажите пожалуйста! С кубером знакомство только начинаю. Стоит задача-собрать кластер высокой доступности, с возможностью запуска подов на мастер-нодах. Для теста взял два сервера, повесил на них общий ip с помощью keepalived, через kubeadm поднял на них два мастера, для cni использовал flannel. Вроде всё поднялось, работает, раздеплоил под. Уронил одного мастера, под был на втором, всё выжило. Но после поднятия, при попытке обратиться через kubectl ловлб ошибку: "Unable to connect to the server: proxyconnect tcp: tls: first record does not look like a TLS handshake". Понимания, что произошло нету. Если кто-то может что-то подсказать-буду крайне признателен!
Artyom
Конфиг kubeadm file в студию, при помощи которого сетапили кластер
apiVersion: kubeadm.k8s.io/v1beta1 kind: ClusterConfiguration kubernetesVersion: stable apiServer: certSANs: - "172.28.70.25" networking: podSubnet: 10.244.0.0/16 controlPlaneEndpoint: "172.28.70.25:6443"
Artyom
Покажи вывод kubectl get endpoint
Unable to connect to the server: proxyconnect tcp: tls: first record does not look like a TLS handshake
Artyom
Кипалайвд на мертвой ноде айпишник вывесил?
После поднятия сервера да, вывесил
𝚔𝚟𝚊𝚙𝚜
Смотрите логи api-server на ней, через docker logs
Artyom
Оба кипелайва настроены как мастеры, к слову
Denis
Unable to connect to the server: proxyconnect tcp: tls: first record does not look like a TLS handshake
c keepalived похоже проблем.Там вначале посмотри
𝚔𝚟𝚊𝚙𝚜
Кипалайвд на мертвой ноде айпишник вывесил?
Лучше добавить haproxy под ним чтобы избежать такой ситуации в будущем.
𝚔𝚟𝚊𝚙𝚜
А проблема с api-server, на ноде, на которой висит айпишник в данный момент
Denis
Haproxy внутри кубера?
Снаружи конечно
𝚔𝚟𝚊𝚙𝚜
Haproxy внутри кубера?
Нет, снаружи, на все ноды с keepalived. Keepalived будет следить за IP'шником, а haproxy за доступностью api-серверов, и в случае чего на другую ноду перенаправлять
𝚔𝚟𝚊𝚙𝚜
спасибо, попробую такой подход. С haproxy до сего момента дел не имел
держи конфиг: frontend k8s-api bind 0.0.0.0:8443 bind 127.0.0.1:8443 mode tcp option tcplog default_backend k8s-api backend k8s-api mode tcp option tcplog option tcp-check balance roundrobin default-server inter 10s downinter 5s rise 2 fall 2 slowstart 60s maxconn 250 maxqueue 256 weight 100 server k8s-api-1 192.168.0.147:6443 check server k8s-api-2 192.168.0.148:6443 check server k8s-api-3 192.168.0.149:6443 checkпри этом обращаться к api-server нужно будет через порт 8443, а не на 6443
𝚔𝚟𝚊𝚙𝚜
А keepalived так и оставить в режим мастер-мастер, или лучше использовать мастер-бэкап?
если поставишь haproxy то все равно, если без него - то лучше мастер-мастер, чтобы айпишник всегда на живой ноде оставался только
Alex
kubectl get configmap -l "OWNER=TILLER" --all-namespaces
Спасибо за наводку, теперь я их вижу! Но как им удаётся прятаться от меня при вызове get configmaps без указания лейбла?
Alex
--all-namespaces
Этот параметр я сразу ставил, причина - на большом кластере много релизов, и там мапы создаются под каждую его версию, а на новом - один релиз в одной версии, поэтому я его и не заметил.
Alex
если поставишь haproxy то все равно, если без него - то лучше мастер-мастер, чтобы айпишник всегда на живой ноде оставался только
Мне тоже кажется что лучше reverse proxy перенаправлять запросы. Опыт с keepalived разочаровал.
𝚔𝚟𝚊𝚙𝚜
Мне тоже кажется что лучше reverse proxy перенаправлять запросы. Опыт с keepalived разочаровал.
Так от keepalived никто и не отказывается, я предложил haproxy вместе с keepalived а не вместо него
Alex
Так от keepalived никто и не отказывается, я предложил haproxy вместе с keepalived а не вместо него
А смысл? 7Если адрес одновременно может быть только у одной машины! Всё равно ведь трафик пойдёт в одну точку
« Rev
@kubernetes_ru   1734
Fwd »