Comments 21
При всех достоинствах K8s эта система управления контейнерными кластерами имеет следующие недостатки, которые значительно усложняют ее использование на практике
· большое число специфических понятий и взаимозависимых сущностей (под, сервис, кубелет, контроллер и т.д.);
· скудная документация, которая недостаточно подробно описывает систему;
· добавление дополнительного уровня абстракции увеличивает сложность и хрупкость системы;
· недостаток и высокая стоимость опытных специалистов, в совершенстве владеющих этой DevOps-технологией.
Это да - система действительно очень сложна, но как говорится: "хочешь быть в высшей лиге, играй как в высшей лиге".
Для честной высокой зарплаты нужны и честные высокие знания.
Ваш комментарий — это скопированный фрагмент этой статьи 4-летней давности. Зачем?
Специфические понятия не является недостатком, это скорее необходимость (докер он попроще, но тем не менее тоже присутствует своя терминология)
Про скудную документацию - не соглашусь.
Единственный серьезный недостаток - изменения API ломающие обратную совместимость, но это вызвано бурным ростом продукта.
День добрый! На распишете подроблее про балансировщик? 172.30.0.210:8888 кто он, где он его надо настраивать отдельно или он создатся при инициализации? у меня инициализация заканчивается неудачей:
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'
но при этом kubelet имеет статус запущен, но сыпет ошибки что API недоступен,
Unable to register node with API server" err="Post "https://172.30.0.210:8888
upd. Всё, разобрался, это я слепой, не заметил имя интерфейса в конфиге keepalived
Можно ещё вопрос? Всё рботает, всё красиво. тесты проходят. Можно ли как то получить данные с nginx непосредственно с хостовой машины? или это влечёт за собой допнастройки?
ЗЫ. я вообще ansible плейбук пилю для воспроизводства всей статьи, можно потом оформить статьеё и сослаться на вас как на основной источник вдохновения?)
Красиво получить доступ с хостовой машины, равно как и с любой другой сетевой машины в текущем конфиге невозможно. Нужна доп. настройка. Думаю запилить вторую часть статьи, где будет это рассмотрено, но когда время будет не знаю.
Если хотите можете самостоятельно поковыряться. Нужно пилить в сторону ingress и Load Balancer.
Ссылка на статью приветствуются)
Большое спасибо за статью, тоже пилю плейбук, одновременно изучая и ансибл, и кубер)
Подскажите, плз, зачем в п.6.2.B ставятся сетевые плагины в /opt/cni/bin? Не нашел, чтобы они где-то использовались в конфигах.
Еще момент - для проведения выборов keepalived проверяет доступность управляющих нод выполнением скрипта с опросом порта 8888, где находится контролплейн кубера. Но по сценарию на момент настройки keppalived и haproxy контролплейна еще нет, скрипт выдает ошибку и выборы для назначения виртуального ИП не проходят.
Решит добавлением в конфиг хапрокси /etc/haproxy/haproxy.cfg:
#---------------------------------------------------------------------
# keepalived frontend for reply HTTP/200
#---------------------------------------------------------------------
frontend http_200
bind *:1200
mode tcp
option tcplog
default_backend http_200
backend http_200
http-request return status 200 content-type "text/plain" lf-string "OK"
И в скрипте /etc/keepalived/check_apiserver.sh
APISERVER_DEST_PORT=1200
@imbasoft, я понимаю, что статья уже старая, но, всё же, у Вас есть такой текст в статье.
# Настройка deb-репозитория Kubernetescurl -fsSLo /etc/apt/trusted.gpg.d/kubernetes-archive-keyring.gpghttps://packages.cloud.google.com/apt/doc/apt-key.gpg
echo "deb [signed-by=/etc/apt/trusted.gpg.d/kubernetes-archive-keyring.gpg]https://apt.kubernetes.io/kubernetes-xenial main" | tee /etc/apt/sources.list.d/kubernetes.list
Но дело в том, что https://apt.kubernetes.io/ официально устарел и следует использовать другой репозиторий https://pkgs.k8s.io/core. Подробно описано тут: https://kubernetes.io/blog/2023/08/15/pkgs-k8s-io-introduction/
У меня, например, с https://apt.kubernetes.io/ ничего не получилось поставить. Добавьте, пожалуйста, пояснение в статью. Я думаю, что по ней не один я kubernetes настраиваю.
автор, при всем уважении к вашему труду в написании неплохой статьи, вот это " Упростим себе жизнь и разрешим SSH сразу пускать нас под root/ " - очень вас принижает. слабо верится что вы не знаете о таких инструментах как sudo & ssh-keygen и так далее. не стоит учить плохому...
Да, я знаю про sudo и авторизацию по ключам. Приведена эта фраза именно для упрощения материала. Debian, в отличии от Ubuntu, не содержит (по умолчанию) в себе sudo. Эту утилиту нужно ставить дополнительно, и кроме того настраивать пользователю на неё использование. Поэтому про sudo было решено не писать.
С точки зрения безопаности. Debian, по умолчанию, использует парадигму "su", то есть вы входите под юзером, а потом перепрыгиваете на root. По факту подобная схема при двойной нагрузке на пользователя (нужно помнить два пароля) дает очень маленький выхлоп безопасности, с точки зрения подбора паролей можно просто увеличить пароль root на один символ и будет безопасней (математика не даст соврать).
Теперь к sudo. Сам по себе sudo дает только два положительных эффекта: 1 - он позволяет логгировать действия суперпользователей когда их несколько и они не читят типа (sudo -i или sudo bash); 2 - он (как и su) позволяет держать в секрете логин администратора (пользователя с правами sudo), что может быть актуально если у вас настроена блокировка авторизации при входе (интерактивно или ssh). Все, больше она ничего не дает. Хотя конечно можно придумать про случайный запуск вредоноса сразу root'ом, но это фэнтази при работе на серверах.
Резюмируя все сказанное, для учебных машин, на которых будет работать только один человек с правами администратора использование sudo не имеет ни малейшего смысла, равно как и su. Поскольку блокировка аккаунта не используется и вся безопасность держится на конфиденциальности пароля.
Заметьте я не говорю, что sudo - это бесполезная вещь. Просто все должно использоваться под задачу и с учетом специфики (модели актуальных угроз), а не просто, из-за того, что кто-то сказал что так правильно.
Карго культ must die.
по sudo. скажем так, ваше мнение по sudo слегка занижено. sudo - это прежде всего возможность ограничения прав пользователей и выдача им разрешений на выполнение каких либо действий от имени суперпользователя.
по паролям. я не зря вам указал про ssh и ключи. если уж вам так хочется ходить под рутом - бога ради, это только ваши проблемы. запретите парольный вход и ходите с ключом. это сильно безопасней чем пароль.
учебная/боевая машина - нет разницы. сегодня вы научите человека ходить под рутом - ну так же легче/проще, завтра ему сломают сервак и у него и массы других людей будет куча неприятностей. зачем?
Гайд для новичков по установке Kubernetes (версия 03.2025)