Так приложения у меня не ломаются, как раз инфраструктура и ломается

потом один за одним на мастерах запускаешь kubeadm upgrade apply, попутно проверяя доступность обновленного мастера

Так приложения у меня не ломаются, как раз инфраструктура и ломается

а ты не ломай

Все апдейты тестируются в стейджинге сначала изучаются возможные проблемы и как их избежать при апгрейде прода

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

завалить при апдейте

если кластер старый и какой-нить кубспрей, то проще простого

Да у меня свежий и кубеспрей тоже легко

выкидывайте его в окно

kubeadm. точка.

Ну оно достаточно неплохо работает

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

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

Ну оно достаточно неплохо работает

нене — в окно

с кубеадм все просто, т.к. почти все что он делает - это генерит серты и статик поды, все предельно просто

Ну оно достаточно неплохо работает

ради разнообразия, попробуйте снести мастер ноду, ну вот просто выключить. Он накатит новую?

нене — в окно

может про окно и была речь

Все апдейты тестируются в стейджинге сначала изучаются возможные проблемы и как их избежать при апгрейде прода

А вы обновляете между версиями? Ну например 1.13 до 1.14. Или берёте какой-то релиз и обновляетесь в рамках него пока не настанет EOL?

А вы обновляете между версиями? Ну например 1.13 до 1.14. Или берёте какой-то релиз и обновляетесь в рамках него пока не настанет EOL?

обновляем, v1.14.1 сейчас

если кластер старый и какой-нить кубспрей, то проще простого

ну вот именно поэтому я сторонник рядом что-то подымать и переключаться( вот игрался однажды с кластером, сугубо для тестов поднял засетапил его с weave cni, потом ну-ка попробую я заменить на kube-router, рестарт кластера даже не нужен был, так эта срань не удалила старый демонсет вива, и начало накатывать демонсет куб роутера... и куб роутер не засетапился не знаю, может косячит копс, но после такого, больше не хочется на горячую кластер обновлять

ну вот именно поэтому я сторонник рядом что-то подымать и переключаться( вот игрался однажды с кластером, сугубо для тестов поднял засетапил его с weave cni, потом ну-ка попробую я заменить на kube-router, рестарт кластера даже не нужен был, так эта срань не удалила старый демонсет вива, и начало накатывать демонсет куб роутера... и куб роутер не засетапился не знаю, может косячит копс, но после такого, больше не хочется на горячую кластер обновлять

ну что-то совсем новое делать, такое конечно. Можно потестить на стэнде для начала, выловить все проблемы, потом уже

я кластеров 200 установил/обновил, тестил разные фейловер сценарии с заменой всех мастер и воркер нод на трех разных осях

после этого уж можно прод на месте обновить

я кластеров 200 установил/обновил, тестил разные фейловер сценарии с заменой всех мастер и воркер нод на трех разных осях

а да, и на трех разных провайдерах (vagrant/vsphere/packet)

kubeadm. точка.

если есть кластеры, поднятые собственным плейбуком (грубо говоря hard way) и которые обновляются этим же плейбуком - имеет ли смысл переходить на kubeadm?

если есть кластеры, поднятые собственным плейбуком (грубо говоря hard way) и которые обновляются этим же плейбуком - имеет ли смысл переходить на kubeadm?

всё от цели зависит, если ваш плейбук работает и нет проблем, почему бы не оставить его в покое

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

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

Интересно а возможен ли такой сценарий, что hard way/from scratch вариант станет неработоспособным и единственным способом установки/обновления кластера станет kubeadm? 🤔

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

День добрый, Не подскажете каким образом можно пофиксать ситуацию, с jenkins'ом, который коннектится к AWS EKS кластеру через kubernetes-plugin. Так как аутентификация идет через aws-iam-authenticator, то получается при старте jenkins'а он нормально поднимает slave агенты в кубере, но через минут 15, этого уже не может сделать, так как протухает токен и в логах кидает ошибку io.fabric8.kubernetes.client.KubernetesClientException: Failure executing: GET at: https://xxx.us-east-1.eks.amazonaws.com/api/v1/namespaces/kubernetes-plugin/pods?labelSelector=jenkins%3Dslave. Message: Unauthorized! Token may have expired! Please log-in again. Unauthorized. Можно как-то подружить работу jenkins'а с EKS cluster'ом не используя aws-iam-authenticator?

боюсь спросить почему такой вопрос

если есть возможность подружить jenkins с aws-iam-authenticator'ом правильно, т.е. чтоб при каждом выполнении коннекта к eks он перезапрашивал токен, был бы рад. Но пока такого способа не нашел. поэтому и вопрос возник, можно ли аутентификацию сделать другим способом

https://geekflare.com/google-cloud-latency/ чот неочень ништяк

кстати, спасибо — не сразу заметил. Вот еще по этой теме: https://kinsta.com/blog/google-cloud-vs-aws/#network

по поводу работы с AWS EKS из Jenkins'а, посмотрев в код kubernetes-plugin'а для jenkins нашел, что можно добавить token expiration https://github.com/jenkinsci/kubernetes-plugin/blob/master/src/main/java/org/csanchez/jenkins/plugins/kubernetes/KubernetesClientProvider.java#L51 По умолчанию он равен 1 суткам, а токен AWS EKS выдается на 14 минут, поэтому добавив в jenkins параметр -Dorg.csanchez.jenkins.plugins.kubernetes.clients.cacheExpiration=60 (в секундах) получил решение своей проблемы 😊

kubeadm init --pod-network-cidr=192.168.0.0/16 --apiserver-advertise-address=$PUBLIC_IP [wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s и ошибка Unfortunately, an error has occurred: timed out waiting for the condition This error is likely caused by: - The kubelet is not running - The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled) If you are on a systemd-powered system, you can try to troubleshoot the error with the following commands: - 'systemctl status kubelet' - 'journalctl -xeu kubelet' Кто-нибудь с таким сталкивался, как решили?

логи кублета?

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

логи кублета?

May 03 18:11:02 scw-amsterdam1 kubelet[1534]: E0503 18:11:02.312381 1534 kubelet.go:2244] node "scw-amsterdam1" not found May 03 18:11:02 scw-amsterdam1 kubelet[1534]: E0503 18:11:02.344211 1534 reflector.go:126] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:47: Failed to list *v1.Pod: Get https://PUBLIC_IP:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dscw-a May 03 18:11:02 scw-amsterdam1 kubelet[1534]: E0503 18:11:02.413138 1534 kubelet.go:2244] node "scw-amsterdam1" not found May 03 18:11:02 scw-amsterdam1 kubelet[1534]: E0503 18:11:02.429888 1534 reflector.go:126] k8s.io/client-go/informers/factory.go:133: Failed to list *v1beta1.CSIDriver: Get https://PUBLIC_IP:6443/apis/storage.k8s.io/v

и всё?

hostname этот резолвится?

и всё?

Там вот это всё повторяется

hostname этот резолвится?

Резолвится

а до того как это в кублете начало повторяться, что было?

а до того как это в кублете начало повторяться, что было?

У меня уже не осталось логов, начал по другому эксперементировать, но помойму там ничего особенного не было, только рестарты(как обычно перед инитом, когда конфигов не хватает)

Второй вариант делал: kubeadm init --pod-network-cidr=192.168.0.0/16 --apiserver-cert-extra-sans=PUBLIC_IP Потом join kubeadm join MASTER_PUBLIC_IP:6443 --token 123 --discovery-token-ca-cert-hash sha256:452401 И выпадает такое: [preflight] Reading configuration from the cluster... [preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml' error execution phase kubelet-start: unable to fetch the kubeadm-config ConfigMap: failed to get config map: Get https://MASTER_PRIVATE_IP:6443/api/v1/namespaces/kube-system/configmaps/kubeadm-config: dial tcp MASTER_PRIVATE_IP:6443: i/o timeout

Неужели нужно руками патчить приватный ip на публичный ip на мастере?

мож лучше с конфигфайлом?

Неужели нужно руками патчить приватный ip на публичный ip на мастере?

не нужно

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

--apiserver-advertise-address — вот этот ключ намекает мастеру, где надо слушать

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

В моём случае мастер и на приватном и на публичном слушает. А у вот той ноды что коннектится нет доступа к приватному ip мастера. Она этот адрес как я понял по ошибке достаёт из configmap

мож лучше с конфигфайлом?

Что-то на bootstrapToken жалуется с конфиг файлом. https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-join/#turning-off-public-access-to-the-cluster-info-configmap ты же про этот способ?

Что-то на bootstrapToken жалуется с конфиг файлом. https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-join/#turning-off-public-access-to-the-cluster-info-configmap ты же про этот способ?

не, я имел ввиду конфиг при ините, но потом прочитал внимательно, что ошибка при джойне

https://helm.sh/blog/helm-3-preview-pt4/ видали статейки?

https://helm.sh/blog/helm-3-preview-pt4/ видали статейки?

https://blog.bacongobbler.com/post/2019-01-25-distributing-with-distribution/index.html была самая шизанутая имхо

хорошо что я туда не глядел сначала

плохо что теперь поглядел

не нужно

Отредактировал приватный IP на публичный в одном месте и всё заработало: kubectl edit cm -nkube-public cluster-info

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

лень, очевидно. Зачем мне 10 кластеров, если можно 1

etcd уже на 7 нодах будет грустить, а Вы хотите 11

etcd уже на 7 нодах будет грустить, а Вы хотите 11

почему оно грустит?

Количество пакетов при реилекшоне растёт квадратично, вероятность элекшона падает

Рафт же

какое отношение илекшон имеет к воркер нодам?

А вы хотите etcd в одном регионе, а воркеры в нескольких?

да

Если уж растягивать, то и etcd и мастера, иначе смысла в ваших действиях никакого

смысл есть, потому что VPN сервер (ворклоад воркер ноды) будет там, где клиент. Клиенту нужен VPN сервер, а не мастер нода, в которую ходит воркер нода, на которой стоит VPN сервер.

А IP адреса vpn-серверов вы харкодить будете или как?

на стороне сервера?

На стороне клиента, конечно

клиенту сертификат же отправляется с адресом

вернее конфиг

эта часть ещё в проработке, я пока не знаю как именно будет реализована выдача сертификатов с конфигами

С адресом ингреса? Не понимаю откуда у вас отказоустойчивость берётся

С адресом ингреса? Не понимаю откуда у вас отказоустойчивость берётся

как вариант

Если отвалится регион с etcd, то у вас грохнется просто возможность не по ip адресу пода рассылать трафик на сервера

Отказоустойчивость вашего кластера всегда практически равна отказоустойчивости etcd

Если отвалится регион с etcd, то у вас грохнется просто возможность не по ip адресу пода рассылать трафик на сервера

можно поподробнее,пожалуйста, почему?

Потому что etcd это датаплейн, ингресу, coredns и т.д. неоткуда будет получить инфу о том где у вас поды и какие ip адреса они имеют

Отказоустойчивость вашего кластера всегда практически равна отказоустойчивости etcd

Да, но если кроме etcd все пройдет, то тоже погоды не сделает особо)