Возник вопрос по обработке соединений при апдейте сервиса. Как k8s себя ведет с активными соединеняими? Допустим есть http сервис в 2х репликах. Пошло задание на обновление. Поднялось 1 новое приложение, осталось 2 старых (на которых висят активные коннекты). Куда сейчас пойдут новые коннекты? на 1 новый экземпляр или и на старые и на новый? Что будет, если коннект не успеет отработать на старом приложении, когда k8s начнет гасить эти старые экземпляры? Оборвет его?

на новый, все же в документации описано

т.е. при апгрейде будет некий период времени, когда вместо 2х-3х-10 реплик одного приложения будет трудиться лишь 1?

все это настраивается в rolling update strategy

И по логике: перед тем как старому приложению пойдет сигнал "выключайся" k8s прекратит заворачивать на него трафик, что бы приложение спокойно дожевало уже имеющиеся запросы и погасилось?

да, именно так

встречался кто?

попробуй просто удали SA

раньше были такие баги с дефолтным SA

попробуй просто удали SA

пробовал, не помогло

хмм ну тогда надо разбираться

угу

а какая команда приводит к такой ошибке?

может не тот неймспейс?

проблема в том что не создаются автоматически секреты. Вот кластер с kubeadm # kubectl get secrets --all-namespaces | grep 'default' default default-token-2jpgf kubernetes.io/service-account-token 3 2d kube-public default-token-p7qbl kubernetes.io/service-account-token 3 2d kube-system default-token-4tvmg kubernetes.io/service-account-token 3 2d

а вот мой вручную поднятый # kubectl get secrets --all-namespaces | grep 'default' default gitlab kubernetes.io/dockerconfigjson 1 4h

интересно, чтобы секреты не создавались автоматом для дефолтного SA я пока не встречал

возможно это какой-то флаг который можно переключить?

может быть, но пока я не знаю какой )

смотря в доку я вроде делаю все верно

надо создать clusterrole и clusterrolebinding для этого SA с соотв. пермишшнами

Ага, уже завёл. Спасибо!

смотря в доку я вроде делаю все верно

помогло грохнуть префикс кубера в etcd и запустить заново

а как прокруить сетевой доступ из пода во внешний мир? (хранилище вне кубов, а app внутри)

сетка weave

Поставить dnsmasq агент

Поставить dnsmasq агент

а dns чем поможешь?

я по ip хожу

и не попадаю

Это я описался, не DNS а ip

kubectl create -f https://raw.githubusercontent.com/kubernetes-incubator/ip-masq-agent/master/ip-masq-agent.yaml

Этот агент фактически просто добавляет правила для маскарада на ноды

Ему ещё можно в конфиг мапе прописать настройки, если надо нестандартные

Спс

все полетело без этого

command: ["curl", "http://pmf-service:8080/gc/services.csv", ">", "/home/vsftpd/services_$(date +%Y-%m-%d).csv"]

а как заставить такой трюк работать? сейчас валит тупо в stdout.

command: sh args: | -c "curl ..."

command: sh args: | -c "curl ..."

спс, ща попробую

супер, спасибо!

1 node(s) had disk pressure,

k8s сделит за диском, и на каких-то дефалтовых отсечках прибивает под?

а не, тупее. забивается / в контейнере, при этом du не показывает чем забито. Наверно это логи, валящие в stdout.

сам nginx стучится на ClusterIP:порт сервисов

Это интересно. С GKE ingress должен обязательно стучаться на NodePort сервиса и никак иначе: https://github.com/kubernetes/ingress-gce#l7-load-balancing-on-kubernetes "For this to work, the Kubernetes Service must have Type=NodePort" Т.е. с nginx ingess'ом по другому и можно использовать type=ClusterIP ?

Вообще, коллеги, кто на GKE использует их нативный ingess? Или все на nginx'е? И правильно я понимаю, что для нормальной работы в проде нужно nginx plus покупать?

Вообще, коллеги, кто на GKE использует их нативный ingess? Или все на nginx'е? И правильно я понимаю, что для нормальной работы в проде нужно nginx plus покупать?

Ну что значит "нормальной"? У nginx plus есть некоторые плюшки, если они необходимы - покупай.

у меня сейчас задача по доставке приложения в кластер. Вначале это был один deployment ресурс, сейчас их уже несколько и для каждого надо будет делать kubectl patch/rollout status/rollout undo и накручивать логику по откату в случае чего. Ситуация ухудшается тем, что всё это делается через CI/CD в vsts и на каждый вызов kubectl там нужен сконфигурированный шаг. Всё это грозит скатится в малопонятное уродливое решение с кучей флагов. Я правильно понимаю, что для выката такой штуки лучше уже helm использовать? Я долго пытался его избегать, но, похоже, всё таки придётся использовать.

Вообще, коллеги, кто на GKE использует их нативный ingess? Или все на nginx'е? И правильно я понимаю, что для нормальной работы в проде нужно nginx plus покупать?

пробовал их ингрес, перешёл на nginx (обычный), потому что нужны были rewrite target аннотации

Это интересно. С GKE ingress должен обязательно стучаться на NodePort сервиса и никак иначе: https://github.com/kubernetes/ingress-gce#l7-load-balancing-on-kubernetes "For this to work, the Kubernetes Service must have Type=NodePort" Т.е. с nginx ingess'ом по другому и можно использовать type=ClusterIP ?

не можно, а нужно, наверное.

Доброе утро коллеги! У меня вопрос касательно Helm. Helm поддерживает в плане версионности чартов SemVer 2 стандарт. В моем понимани версии чартов могут быть к примеру: version: 1.2.3-dev+365 version: 1.2.3-dev+366 и т.д И естевственно все версии этих чартов будут перечислены в индексных файлах?

у меня сейчас задача по доставке приложения в кластер. Вначале это был один deployment ресурс, сейчас их уже несколько и для каждого надо будет делать kubectl patch/rollout status/rollout undo и накручивать логику по откату в случае чего. Ситуация ухудшается тем, что всё это делается через CI/CD в vsts и на каждый вызов kubectl там нужен сконфигурированный шаг. Всё это грозит скатится в малопонятное уродливое решение с кучей флагов. Я правильно понимаю, что для выката такой штуки лучше уже helm использовать? Я долго пытался его избегать, но, похоже, всё таки придётся использовать.

Да, уже лучше helm. Сам поначалу оттягивал его использование, но жить с ним в принципе вполне можно.

А почему избегать? Я пользуюсь (не админю) и мне совсем норм

потому что он поначалу воспринимается как шаблонизатор, которому зачем-то нужен какой-то тиллер в кластере и тд. Это как если бы yum свой собственный сервис в systemd

Не

Это как говорить зачем ему репка )

У юма собственный сервер в редхате ;) или где

Это как говорить зачем ему репка )

я ж про тиллер

Ну да, наверно плохое сравнение

Купил я своим програмерам 3 одинаковых макбука. Два для работы и один запасной для командировок. Специфика нашего разработческого процесса требует установки и калибровки огромного количества разного софта и скриптов и занимает часов 12 на свежем компе. Алексею так хотелось скорее начать пользовать новую машинку, что сразу после окончания рабочего дня он засел за конфигурацию новой игрушки. Просидел он, видимо, всю ночь, его обнаружили спящим в кресле перед готовым к использованию ноутом. Ребята долго не думали, забрали компьютер и поставили перед ним "запасной" макбук, на экране которого светилось сообщение: "Форматирование диска окончено. Можно начать установку операционной системы", ну или примерно так. Когда Леша проснулся, сказать, что он удивился - ничего не сказать.

Хуйня, у мака не надо ставить систему и что-то там форматировать

Вся настройка мака сводится к установке xcode + homebrew

Хуйня, у мака не надо ставить систему и что-то там форматировать

мат офф плиз

смотрите, нежный инженер в чяте

Вся настройка мака сводится к установке xcode + homebrew

Iterm2 + brew

Ну поставь brew без xcode)) сделай видос для общественности

iTerm ставится через brew cask

Вся настройка мака сводится к установке xcode + homebrew

Ага а если корпоративный прокси и своя artifactory и смарт карты для логина

Ууу, корпорейт) обычно помогает подготовленный образ диска

AutoDMG в помощь, ну если хочется все руками

Кто ж запрещает

ansible?)

AutoDMG в помощь, ну если хочется все руками

brew cask же

Вообще, коллеги, кто на GKE использует их нативный ingess? Или все на nginx'е? И правильно я понимаю, что для нормальной работы в проде нужно nginx plus покупать?

Их ingress не даёт необходимой гибкости

Это интересно. С GKE ingress должен обязательно стучаться на NodePort сервиса и никак иначе: https://github.com/kubernetes/ingress-gce#l7-load-balancing-on-kubernetes "For this to work, the Kubernetes Service must have Type=NodePort" Т.е. с nginx ingess'ом по другому и можно использовать type=ClusterIP ?

Верно пишут. Мой nginx выставлен через nodeport

потому что он поначалу воспринимается как шаблонизатор, которому зачем-то нужен какой-то тиллер в кластере и тд. Это как если бы yum свой собственный сервис в systemd

а разве это не так? какие фичи кроме шаблонизатора, реально используете? в каких сценариях?

я пока никакие. вопрос был, почему его все не хотят и я дал свою версию.

какие фичи планирую использовать - деплой

продвинутый аналог kubectl rollout и вокруг

просто как шаблонизатор он мне не нужен совсем

Верно пишут. Мой nginx выставлен через nodeport

Я про то, что вы писали, что nginx у вас стучится на ClusterIP сервисов, т.е. сервисы выставлены не через NodePort, а через ClusterIP и в статье про это. Так как всё-таки? :)

Nginx находится внутри кластера. Поэтому он ходит на ClusterIP внутренних сервисов. Для наружных запросов в кластер он выставлен через NodePort. Надеюсь, понятно объяснил?

Еше раз всем привет! Подскажите плес, что не так Через gitlab-ci делаю деплой и получаю ошибку rror from server (Forbidden): pods "helm-deploy-0" is forbidden: User "system:serviceaccount:deploy:gitlab-serviceaccount" cannot get pods in the namespace "deploy" Мой RBAC --- apiVersion: v1 kind: ServiceAccount metadata: name: gitlab-serviceaccount namespace: deploy --- kind: Role apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: gitlab-role namespace: deploy rules: - apiGroups: [""] resources: ["pods/exec"] verbs: ["get", "list"] --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: gitlab-rolebinding namespace: deploy subjects: - kind: ServiceAccount name: gitlab-serviceaccount namespace: deploy roleRef: kind: Role name: gitlab-role apiGroup: rbac.authorization.k8s.io

- resources: ["pods/exec"] + resources: ["pods"] ?

в init я могу скачать, но я не смогу залить дамп до запуска самого engine или можно делать дамп через копирование /var/lib - но это такое себе занятие

Мы тут решили подробнее рассказать про это. https://habr.com/company/flant/blog/417509/

Nginx находится внутри кластера. Поэтому он ходит на ClusterIP внутренних сервисов. Для наружных запросов в кластер он выставлен через NodePort. Надеюсь, понятно объяснил?

Я это понял. Так в статье и цитате, которую я привёл про Сервисы, у которых должен быть type: NodePort обязательно, если их выстпвлять наружу, через GKE ingress. А у вас, получается, сервисы имеют type:ClusterIP и ingress Nginx. И тот и тот ingress в кластере, но с GKE ingress сервисы должны быть type: NodePort. Надеюсь я тоже понятно объяснил :)