Боюсь, если всё описывать подробно, как я пытался это делать в этой статье (и при этом, всё равно пришлось вырезать десяток нюансов), то для описании правильной настройки RBAC ролей, придется писать целую книгу)
Я сейчас работаю над продолжением этой статьи, как раз примерно по этой теме, но мне предстоит ещё очень много протестировать, и понять, как это всё преподнести в формате статьи.
Тогда стоит почитать документацию по kubeadm init. Для начала, стоит обратить внимание на флаг --apiserver-advertise-address и --control-plane-endpoint. Возможно, дефолтные значения присваиваются неправильно. В качестве обеих этих значений, присваиваем адрес первой мастер ноды:
Где 192.168.1.23 является адрес первой мастер ноды на которой мы инициализируем кластер. При добавлении воркера через команду с токеном, дополнительно указывать эти два флага (--apiserver-advertise-address и --control-plane-endpoint), думаю, тоже не помешает.
Сперва, наверное стоит проверить самые элементарные вещи. Выполняем команду ip a на одной VM, получаем IP адрес, пингуем этот адрес с другой машины при помощи ping 192.168.1.23 где 192.168.1.23 является адрес первой машины. Если не пингуется, разбираемся почему сеть между двумя VM неправильно настроена.
Надеюсь, проблема только в этом, иначе придётся разбираться глубже)
Привет, Павел. Действительно, почему-то в последние дни ключ от репозитория кубера отвалился. Причем, если следовать инструкции установки на уже мною поднятых узлах месяц назад, скаченный ключ отваливается, пришлось его вручную подменять уже скаченным и работающим ключом. Пока не до конца разобрался в чём дело. Как вариант, можно установить необходимые компоненты без пакетного менеджера.
А второе с чем я столкнулся - файла нет /etc/kubernetes/admin.conf
Файл /etc/kubernetes/admin.conf должен генерироваться при успешном выполнении kubeadm init. Стоит проверить, если инициализация первой ноды кластера прошла успешно.
Не совсем. Tmux и starship это совсем разные вещи. Tmux — это терминальный оконный менеджер. Starship — это конфигуратор самой строки в терминале. Он, например, позволяет превратить вот эту унылую строку:
user@ubuntu: ~/#
В вот такие красивые и полезные штуки:
Или вот такую:
То есть, starship это аналог Oh My Zsh для Zsh shell и ohmybash для Bash. Но у starship есть одно явное преимущество: он совместим с Bash, Fish, Zsh, Powershell, Elvish, Tcsh и со многими другими терминальными средами. То есть, один конфиг будет работать во всех этих средах. Плюс, starship написан на языке Rust, что делает его гораздо шустрее при генерации всех этих "красивых и полезных штук", в отличие от ohmyzsh и ohmybash, которые написаны на ответствующих терминальных средах.
"You MUST disable swap in order for the kubelet to work properly."
Если цель нашей дискуссии просто пофилософствовать от том, является ли бредом отключение swap памяти при настройки Kubernetes кластера, то можно хоть обфилософствоваться целами томами, на подобии софистов в Древней Греции. С практической же точки зрения, особенно в случаях, когда приходится настраивать Kubernetes в проде (таким, как мне), наверное, стоит придерживаться совету "вы ДОЛЖНЫ отключить swap память", который, в официальной документации, озвучивается соответствующим жирным шрифтом. Нет так ли?)
Спасибо за это лаконичнoe разъяснение. Думаю это стоит закрепить, так как тема про отключение swap при настройки kubeadm вызвало комичное количество недоумений)
Ну тогда напишите гид, который объясняет почему не стоит отключать файл подкачки и я с удовольствием включу это в статью ;)
Потом про необоснованность отключения файла подкачки при настройки Kubernetes можно будет написать вот на эти ресурсы. Уверен, что там будет кому удивится:
Дело в том, что Kubernetes — это прежде всего контейнрный оркестратор и на этом его, так скажем, "ответственность", почти заканчивается. Боллее того, сам Kubernetes отдаляется от поддержки отдельных компонентов, которые не связаны с его основной должностью. Например, с версии 1.24, Kubernetes больше не поддерживает dockershim официально. Это означает, что выбор контейнерного рантайма (containerd, cri-o, Docker Engine и другие) теперь стоит за Kubernetes администратором и kubeadm теперь делает гораздо меньше за тебя. С другой стороны, kubeadm делает достаточно проверок настроек перед созданием кластера.
Более того, сам Kubernetes кластер может быть настроен по разному, в зависимости от технических требований. Например, БД etcd может быть настроена вне нод мастеров, а сами мастера могут быть настроены через Load Balancer, которые осуществляют бесперебойность кластера. Это всё усложняет количество возможных конфигураций Kubernetes кластера. Поэтому, включать шаги настройки Kubernetes в утилиту kubeadm было бы достаточно трудно и кропотливо. С другой стороны, есть не мало утилит, которые упрощают настройку Kubernetes. Я думаю, всё зависит от требований.
Если не вдаваться сильно в детали, которые под копотом, то основные детали это конфигурация tmux через пакетный мемеджер tpm и плагин dracula, и настройщик командной строки starship.
https://www.jamf.com/
А можно сбросить ещё 60% при помощи
upx:upx --best --lzma my_rust_binaryДа, всё верно. "dry-run", это обычно универсальный флаг у многих команд, который, на человеческий язык, можно перевести примерно так:
"Пожалуйста, команда, покажи, что ты собираешься сделать и ничего при этом не сломай":)
Боюсь, если всё описывать подробно, как я пытался это делать в этой статье (и при этом, всё равно пришлось вырезать десяток нюансов), то для описании правильной настройки RBAC ролей, придется писать целую книгу)
Я сейчас работаю над продолжением этой статьи, как раз примерно по этой теме, но мне предстоит ещё очень много протестировать, и понять, как это всё преподнести в формате статьи.
Тогда стоит почитать документацию по
kubeadm init. Для начала, стоит обратить внимание на флаг--apiserver-advertise-addressи--control-plane-endpoint. Возможно, дефолтные значения присваиваются неправильно. В качестве обеих этих значений, присваиваем адрес первой мастер ноды:kubeadm init --pod-network-cidr=10.100.0.0/16 --dry-run --apiserver-advertise-address 192.168.1.23 --control-plane-endpoint 192.168.1.23Где 192.168.1.23 является адрес первой мастер ноды на которой мы инициализируем кластер. При добавлении воркера через команду с токеном, дополнительно указывать эти два флага (
--apiserver-advertise-addressи--control-plane-endpoint), думаю, тоже не помешает.Спасибо, рад, что статья оказалась полезной.
Сперва, наверное стоит проверить самые элементарные вещи. Выполняем команду
ip aна одной VM, получаем IP адрес, пингуем этот адрес с другой машины при помощиping 192.168.1.23где 192.168.1.23 является адрес первой машины. Если не пингуется, разбираемся почему сеть между двумя VM неправильно настроена.Надеюсь, проблема только в этом, иначе придётся разбираться глубже)
Привет, Павел. Действительно, почему-то в последние дни ключ от репозитория кубера отвалился. Причем, если следовать инструкции установки на уже мною поднятых узлах месяц назад, скаченный ключ отваливается, пришлось его вручную подменять уже скаченным и работающим ключом. Пока не до конца разобрался в чём дело. Как вариант, можно установить необходимые компоненты без пакетного менеджера.
Файл
/etc/kubernetes/admin.confдолжен генерироваться при успешном выполненииkubeadm init. Стоит проверить, если инициализация первой ноды кластера прошла успешно.Не совсем. Tmux и starship это совсем разные вещи. Tmux — это терминальный оконный менеджер. Starship — это конфигуратор самой строки в терминале. Он, например, позволяет превратить вот эту унылую строку:
user@ubuntu: ~/#В вот такие красивые и полезные штуки:
Или вот такую:
То есть, starship это аналог Oh My Zsh для Zsh shell и ohmybash для Bash. Но у starship есть одно явное преимущество: он совместим с Bash, Fish, Zsh, Powershell, Elvish, Tcsh и со многими другими терминальными средами. То есть, один конфиг будет работать во всех этих средах. Плюс, starship написан на языке Rust, что делает его гораздо шустрее при генерации всех этих "красивых и полезных штук", в отличие от ohmyzsh и ohmybash, которые написаны на ответствующих терминальных средах.
Тем не менее, в официальной документации (редакция 23 апреля, 2023 года ) твердится в жирном шрифте следующее:
"You MUST disable swap in order for the kubelet to work properly."
Если цель нашей дискуссии просто пофилософствовать от том, является ли бредом отключение swap памяти при настройки Kubernetes кластера, то можно хоть обфилософствоваться целами томами, на подобии софистов в Древней Греции. С практической же точки зрения, особенно в случаях, когда приходится настраивать Kubernetes в проде (таким, как мне), наверное, стоит придерживаться совету "вы ДОЛЖНЫ отключить swap память", который, в официальной документации, озвучивается соответствующим жирным шрифтом. Нет так ли?)
Спасибо за это лаконичнoe разъяснение. Думаю это стоит закрепить, так как тема про отключение swap при настройки kubeadm вызвало комичное количество недоумений)
Ну тогда напишите гид, который объясняет почему не стоит отключать файл подкачки и я с удовольствием включу это в статью ;)
Потом про необоснованность отключения файла подкачки при настройки Kubernetes можно будет написать вот на эти ресурсы. Уверен, что там будет кому удивится:
Installing kubeadm: Before you begin
Swap Off - why is it necessary?
Why disable swap on kubernetes
How to Disable Swap in Linux for Kubernetes
Why Kubernetes Hates Linux Swap?
Как настроить кластер Kubernetes с Kubeadm в Debian 11
Дело в том, что Kubernetes — это прежде всего контейнрный оркестратор и на этом его, так скажем, "ответственность", почти заканчивается. Боллее того, сам Kubernetes отдаляется от поддержки отдельных компонентов, которые не связаны с его основной должностью. Например, с версии 1.24, Kubernetes больше не поддерживает dockershim официально. Это означает, что выбор контейнерного рантайма (containerd, cri-o, Docker Engine и другие) теперь стоит за Kubernetes администратором и kubeadm теперь делает гораздо меньше за тебя. С другой стороны, kubeadm делает достаточно проверок настроек перед созданием кластера.
Более того, сам Kubernetes кластер может быть настроен по разному, в зависимости от технических требований. Например, БД etcd может быть настроена вне нод мастеров, а сами мастера могут быть настроены через Load Balancer, которые осуществляют бесперебойность кластера. Это всё усложняет количество возможных конфигураций Kubernetes кластера. Поэтому, включать шаги настройки Kubernetes в утилиту kubeadm было бы достаточно трудно и кропотливо. С другой стороны, есть не мало утилит, которые упрощают настройку Kubernetes. Я думаю, всё зависит от требований.
Если не вдаваться сильно в детали, которые под копотом, то основные детали это конфигурация tmux через пакетный мемеджер tpm и плагин dracula, и настройщик командной строки starship.
Так что вот этапы:
Устанавливаем tmux, устанавливаем tpm и заносим мой tmux.conf в
~/.config/tmux/tmux.confУстанавливаем starship и не забываем добавить в
~/.bashrc(или .zshrc, config.fish, тд). Заносим мой starship.conf в~/.config/starship.tomlОстальные подробности придется как-нибудь описать в отдельном посте)
Потому что тут очень сильно обижаются, когда начинают говорить про Rust)