Архив метки: Kubernetes

90+ полезных инструментов для Kubernetes: развертывание, управление, мониторинг, безопасность и не только

Осенью 2018 года мы опубликовали список из 25 полезных инструментов Kubernetes. С тех популярность платформы сильно выросла. Экосистема оркестрации контейнеров бурно развивается, можно найти вспомогательные инструменты практически для любой задачи.




Поэтому команда Kubernetes aaS от Mail.ru обновила и дополнила подборку. Предлагаем вашему вниманию список с почти сотней полезных инструментов, упрощающих жизнь тем, кто работает с Kubernetes.










Инструменты развертывания кластера




1. Keel




Оператор Kubernetes, который автоматизирует обновления DaemonSet, StatefulSet, Helm и Deployment. Одна команда, никаких зависимостей, конфигурационных файлов и блокировок.




2. Kube-prod-runtime




Набор служб Kubernetes, который упрощает работу в продакшене под серьезной нагрузкой. Обеспечивает мониторинг производительности в кластере, ведение журналов, управление сертификацией и автоматическое обнаружение ресурсов в K8s через общедоступные DNS-серверы. Это полезный набор сервисов и для других инфраструктурных нужд.




3. K3sup




После установки k3sup (произносится как ketchup) вы можете за считанные секунды сгенерировать kubeconfig на любой локальной или удаленной виртуальной машине.







4. Mail.Ru Cloud Solutions: Cloud Containers




На платформе можно развернуть кластеры Kubernetes в виде облачного сервиса: за несколько минут вы получите готовый к работе кластер без необходимости в настройке и обновите его до нужной версии. Также кластеры просто масштабировать — они работают на инфраструктуре Mail.Ru, рассчитанной на высоконагруженные сервисы.







5. Kubeadm




Средство для инициализации кластеров Kubernetes в оптимальной конфигурации на вашей инфраструктуре. Главное преимущество — возможность запускать минимально жизнеспособные кластеры Kubernetes в любой среде. Надстройки и сетевые настройки не входят в конфигурацию из коробки, все придется настроить вручную. 




6. Kubespray




Набор ролей Ansible для развертывания и конфигурации Kubernetes. Работает на разных облачных платформах: AWS, GCE, Azure, Mail.Ru Cloud Solutions, OpenStack и bare metal IaaS. Это open source проект, построен на kubeadm. Подходит тем, кто хорошо знаком с Ansible — с этим инструментом вам ничего не нужно больше знать, чтобы развернуть все нужные ресурсы. 




7. Conjure-up 




Позволяет развертывать Kubernetes с помощью нескольких команд, поддерживает развертывания на локальном хосте, bare metal, в облачных средах, в том числе OpenStack.




8. Minikube




Хорошее начало для тех, кто только знакомится с Kubernetes. Инструмент позволяет пользователям легко запускать одноузловой кластер локально внутри виртуальной машины на ноутбуке пользователя. Поддерживается в Mac OS X, Windows и Linux.




9. MicroK8s 




Инструмент для пользователей Kubernetes, позволяющий развернуть автономный кластер на сервере Linux, хорошо подходит для Edge и IoT.




10. Bootkube 




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




11. RKE от Rancher




Сертифицированный CNCF дистрибутив Kubernetes, работающий внутри контейнеров. Позволяет упростить и автоматизировать установку Kubernetes, не зависеть от операционной системы и платформы, на которой вы работаете.




Инструменты мониторинга




12. Kube-state-metrics




Простая утилита для прослушивания сервера Kubernetes API, помогает в генерации метрик о состоянии объектов. Фокусируется на работоспособности различных объектов внутри кластера, включая узлы, поды и развертывания.




13. Kubebox




Терминальная консоль, позволяющая управлять кластером Kubernetes и отслеживать его статус в режиме реального времени. Мониторит кластер, показывает, что происходит с ресурсами подов, журналы контейнеров и другие параметры. Позволяет легко перейти к нужному пространству имен и выполнить команду в нужном контейнере. Это помогает быстро справляться с неполадками и восстанавливать работу.  







14. Rakess




Плагин Rakess (Review Access) показывает все права доступа к кластеру Kubernetes. Конечно, для отдельных ресурсов можно выполнить проверку командой kubectl auth can-i list deployments, но она не дает полную информацию обо всех ресурсах на сервере.




15. Kubetail




Bash-скрипт, позволяющий агрегировать журналы многих подов в один поток. В исходной версии не умеет фильтровать или выделять, но на Github есть отдельный форк, позволяющий раскрашивает логи с помощью MultiTail.




16. Stern




Еще один инструмент из категории «tail для подов в Kubernetes». Особенности: использование регулярных выражений для удобной фильтрации подов (не нужно знать конкретные ID), аналогично можно фильтровать отдельные контейнеры для запрашиваемых подов, есть стандартные и кастомные Go-шаблоны для выводимых логов, ограничение вывода логов по периоду времени или количеству строк и много чего еще.




17. Prometheus




Не можем снова не упомянуть этот опенсорсный инструмент для мониторинга и уведомлений, который давно стал стандартом для мониторинга Kubernetes. Он интегрирован со всеми популярными языками программирования, помогает создавать собственные метрики и содержит много готовых интеграций с популярными технологиями, например: PostgreSQL, MySQL, ETCD.




С помощью Prometheus Operator можно создавать экземпляры Prometheus в кластерах Kubernetes, в том числе тесную интеграцию с Grafana и Alertmanager.




18. Jaeger




Инструмент трассировки с открытым исходным кодом. Умеет мониторить транзакции и сервисные зависимости в распределенных системах, выявлять и устранять неполадки. Один из способов начать работу с ним в Kubernetes — использовать специальный оператор Jaeger




19. Searchlight




Оператор Kubernetes для Icinga. Умеет запускать периодические проверки на кластерах Kubernetes, а потом отправлять уведомления по электронной почте, СМС или в чат, если что-то идет не так. В инструмент по дефолту включен комплект проверок специально для Kubernetes. С его помощью можно расширить возможности мониторинга Prometheus, также он станет резервной системой, если внутренние системы мониторинга полностью откажут.




20. Kubernetes Operational View (Kube-ops-view)




Read-only системная панель, способная работать со многими кластерами Kubernetes. Позволяет удобно перемещаться между кластерами, отслеживать ноды и состояние подов. Визуализирует ряд процессов, таких как создание и уничтожение подов. 







21. Kubewatch 




Запускается в подах в кластере Kubernetes, отслеживает системные изменения, после запуска вы будете получать уведомления через веб-хуки. Можно настроить свои уведомления, просто отредактировав файл конфигурации.




22. Weave Scope 




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







23. Turbonomic/Kubeturbo 




Обеспечивает видимость всего вашего стека, позволяет контролировать эффективность базовой инфраструктуры и производительность запущенных микросервисов в Kubernetes.




Тестирование




24. Kubeval




Инструмент для проверки конфигурационного файла Kubernetes YAML или JSON. Проверка осуществляется с использованием схем, сгенерированных из Kubernetes OpenAPI. Это позволяет производить валидацию схем для разных версий Kubernetes.




25. Helm-kubeval




Плагин Helm, используемый для валидации диаграмм на соответствие схемам Kubernetes. Для проверки диаграмм можете выбрать определенные версии Kubernetes.




26. BotKube




BotKube может отслеживать, отлаживать и запускать проверки в кластерах Kubernetes. Инструмент также интегрируется в различные платформы для обмена сообщениями, такие как Slack и Mattermost. Преимущества — открытый исходный код и простота настройки.







27. Sonobuoy




Sonobuoy — диагностический инструмент для проверки на соответствие нормативам, отладки рабочей нагрузки и проведения пользовательских тестов, которые помогают определить состояние кластера. Тесты выполняются неразрушающим образом, при этом генерируются четкие информативные отчеты.




28. Snyk Container




Snyk позволяет быстро находить и исправлять уязвимости в контейнерах и приложениях Kubernetes на протяжении всего жизненного цикла разработки.







29. Kube-monkey




Следуя принципам хаос-инжиниринг, Kube-monkey случайным образом удалит модули Kubernetes в кластере и проверит разработку отказоустойчивых сервисов.




30. K8s-testsuite 




Состоит из двух диаграмм Helm для тестирования пропускной способности сети и нагрузочного тестирования кластеров Kubernetes. Это поможет убедиться в правильности их конфигурации, а также в работоспособности служб и правильном распределении нагрузки.




31. PowerfulSeal 




Инструмент специфичен для Kubernetes и также следует принципам хаос-инжиниринг, позволяя проверить объекты, работающие в контейнерах. Также его можно использовать для проверки выбранных компонентов кластера вручную через интерактивный режим. После развертывания инструмент работает автономно.







Безопасность




32. Harbor




Реестры Harbor защищают образы с контейнерами путем внедрения системы управления доступом на основе ролей. Инструмент также проверяет образы на наличие уязвимостей и подписывает их как надежные.




33. Kubesec




Инструмент с открытым исходным кодом для анализа рисков безопасности ресурсов Kubernetes. С ним вы сможете контролировать систему и получите полный список рекомендаций по повышению ее общей безопасности. 




34. Permission-Manager




Это приложение разработки компании SIGHUP позволяет легко управлять ролями доступа для Kubernetes через систему Role-Based Access Control. Создайте пользователей, назначьте пространство имен/разрешения, а также распространите файлы Kubeconfig YAML.







35. Kube-scan




Инструмент от компании Octarine фокусируется на оценке рисков в рабочих нагрузках Kubernetes. Kube-scan запускается как под в кластерах и оценивает 30 параметров безопасности, чтобы вывести максимально приемлемый уровень риска. Затем инструмент анализирует, какие параметры работают в тандеме, чтобы понять, какие комбинации уменьшат уровень угроз.







36. K-rail




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




37. KeyCloak




KeyCloak — опенсорсный инструмент управления доступом и идентификационной информацией пользователей. Он добавляет функцию аутентификации приложений и помогает минимальными усилиями обеспечить безопасность служб. Устраняет необходимость детально разбираться с ведением списка пользователей и их аутентификацией. Всё это теперь работает прямо из коробки.




38. Aquasec




Инструмент предназначен для защиты инсталляций Kubernetes на протяжении всего жизненного цикла. Он развертывает на каждом контейнере выделенный агент, работающий как межсетевой экран и устраняющий возможные уязвимости. Управлять ограничениями безопасности вы сможете через центральную консоль. Кроме того, инструмент позволяет использовать гибкие настройки безопасности в локальных и облачных средах. 




С ним связан еще один open source инструмент  — Kube-Bench, проверяющий среду Kubernetes по тестам из документа CIS Kubernetes Benchmark.




39. Tigera




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




40. Klum




Klum, или Kubernetes Lazy User Manager, выполняет простые задачи, такие как создать/удалить/изменить пользователей. Он выдает файлы kubeconfig и управляет ролями юзеров.




41. StrongDM




StrongDM — это плоскость управления для проверки безопасности и доступа к вашим серверам и/или базам данных. Состоит из API аутентификации, прокси-сервера, поддерживающего протокол, и хранилища журналов. 




42. Falco




Инструмент для обеспечения безопасности с открытым исходным кодом для облачных вычислений, обнаруживает риски для Kubernetes. Замечает неожиданное поведение приложения и оповещает об угрозах во время его выполнения.




43. Sysdig Secure 




Платформа, обеспечивающая мониторинг безопасности микросервисов и контейнеров. Поддерживаются Kubernetes и Docker. Может быть использована в облаке и локально.




Полезные утилиты




44. Krew




Krew помогает разработчикам находить полезные плагины kubectl для программ и устанавливать, а потом управлять ими. Этот инструмент похож на APTDNF или Homebrew.




45. Ksniff




Плагин для kubectl, который эффективно использует Wireshark и tcpdump для удаленного захвата трафика с любого пода в кластере Kubernetes.







46. Kube-ps1




Скрипт Kube-ps1 добавляет текущий контекст Kubernetes и сконфигурированное пространство имен из kubectl в консоль Bash/Zsh, никаких команд не требуется.




47. Kubefwd




Если вы запускаете службы Kubernetes на удаленном кластере, то Kubefwd поможет перенаправить их на локальную рабочую станцию. Никаких модификаций не требуется: если вы используете kubectl, вы уже соответствуете всем требованиям.







48. Kubeterminal




Это скорее вспомогательный инструмент, который дополняет kubectl и вашу консоль в Kubernetes.







49. Skaffold




Skaffold — консольная утилита, помогающая обеспечить процесс непрерывной разработки приложений Kubernetes. Инструмент очень легкий и не требует компонентов на стороне кластера.




50. Kubectl-aliases




Простой и очень мощный генератор алиасов для kubectl. С его помощью вы сможете очень быстро писать команды для повседневного администрирования Kubernetes, так как он предоставляет более 800 коротких алиасов на все случаи жизни.




51. Kubectx/Kubens




Опенсорсная утилита, дополняет Kubectl, позволяет переключать контекст и подключаться одновременно к нескольким кластерам Kubernetes, а также перемещаться между пространствами имен. Есть поддержка автозаполнения в оболочках bash/zsh/fish.




kubectx помогает переключаться между кластерами вперед и назад:







kubens помогает плавно переключаться между пространствами имен Kubernetes:







52. Kube-shell




Инструмент, ускоряющий работу с kubectl. Автодополняет команды, предлагает разные варианты, ищет и исправляет команды, которые введены неправильно, отображает in-line справку о выполняемых командах.







53. Tilt




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





https://embedd.srv.habr.com/iframe/5f9a63672c0608e1441a4051




54. Kail (Kubernetes Tail)




Инструмент позволяет отслеживать логи Docker для нужных подов. Он фильтрует поды по службам, развертываниям, меткам и иным параметрам. В соответствии с критериями фильтрации поды после запуска будут автоматически добавлены в журнал или удалены из него.




Инструменты разработки




55. Helm 




Пакетный менеджер, помогает управлять приложениями Kubernetes с помощью Helm Charts. Это позволяет пользователям создавать воспроизводимые сборки, которыми можно делиться.




56. Helm-2to3




Этот плагин помогает разработчикам перенести конфигурацию из Helm v2 в Helm v3 с соответствующей очисткой конфигурации.







57. Rook




Rook помогает автоматизировать различные задачи для хранилища данных, такие как развертывание, загрузка, масштабирование, обновление и так далее. Это гарантирует, что на Kubernetes будет стабильно работать решение любого поставщика (Ceph, EdgeFS, CockroachDB, Cassandra, NFS, Yugabyte DB).




58. Contour




Contour — ingress-контроллер Kubernetes, обеспечивает плоскость управления для Ingress и служебного прокси.




59. Shell-operator




Shell Operator упрощает создание операторов Kubernetes. Он обеспечивает интеграцию между событиями кластера Kubernetes и сценариями оболочки. Упрощает управление кластером. 




60. Helm-operator-get-started




Помогает управлять вашими релизами Helm.







61. Helmfile




Инструмент для управления релизами helm-чартов. Позволяет в одном месте описывать множество helm релизов, задавать порядок их деплоя и делать другие полезные вещи.




62. Kudo




Kudo упрощает создание операторов Kubernetes, в основном используя YAML. Он предоставляет готовые операторы, которые можно настроить из коробки.




63. Helm-docs




Этот инструмент автоматически генерирует документацию из диаграмм Helm в файл markdown. Данный файл содержит метаданные, включая таблицу со всеми значениями диаграммы и значениями по умолчанию.




64. Telepresence 




Позволяет локально отлаживать службу Kubernetes, упрощая процесс разработки.




65. Kubectl-debug




Позволяет запускать дополнительный контейнер в интересующем вас поде. Новый контейнер будет использовать пространство имен совместно с целевым контейнером/контейнерами. 




66. Ksync 




Почти мгновенно синхронизирует файлы вашей локальной системы с кластером Kubernetes. Подходит, если вы используете сценарии, в которых основной проблемой является доставка кода в работающий контейнер. 




67. Squash 




Используют для отладки процессов во время их работы в кластере. Простой в использовании, вы можете в интерактивном режиме выбрать нужный отладчик и пространство имен/под интересующего процесса. 




Конвейер CI/CD




68. Rafay




Rafay — программный инструмент, который упрощает для компании или отдельного разработчика создание собственной платформы, системы автоматизации и управления жизненным циклом приложений. Rafay также способен запускать кластеры Kubernetes.




69. Rancher




Rancher — полноценная программная платформа, которая легко развертывает контейнерные среды, выходящие за рамки инсталляторов Kubernetes, таких как Kops и Kubespray. Предоставляет множество функций, включая управление инфраструктурой, планирование и оркестровку контейнеров, мониторинг, проверку работоспособности, ведение журналов, а также мощную систему управления доступом на основе ролей.




70. Draft




Утилита от разработчиков Helm. Ее цель — упростить приложения, которые разрабатываются для работы в Kubernetes. С помощью двух простых команд вы можете работать с контейнерными приложениями, даже не нуждаясь в установке Docker или Kubernetes.




71. Jenkins




Пожалуй, наиболее популярный open source CI/CD-сервер в мире. К нему есть бесплатный плагин, помогающий развертывать приложения в Kubernetes, обновлять их с минимальным простоем и обеспечивать Green/Blue-развертывание обновлений. 







72. TeamCity




Известный CI/CD сервис от JetBrains. Есть плагин, с которым можно использовать инфраструктуру кластера Kubernetes для запуска билд-агентов TeamCity (в версии 2017.1.x и новее). 




73. Apollo 




Решение для непрерывного развертывания (CD), предоставляющее интерфейс самообслуживания для команд. Может интегрироваться с существующими процессами сборки. Это позволяет управлять кластерами Kubernetes, предоставляя каждому пользователю определенные разрешения для обеспечения безопасности развертывания.







74. Werf




CLI-инструмент с открытым исходным кодом, написанный на Go, предназначен для упрощения и ускорения доставки приложений. Werf создает образы Docker с использованием Dockerfiles или альтернативного быстрого встроенного компоновщика на основе собственного синтаксиса. Он также удаляет неиспользуемые образы из реестра Docker. Потом Werf развертывает ваше приложение в Kubernetes, используя диаграмму в формате, совместимом с Helm, с удобными настройками и улучшенным механизмом отслеживания развертывания, обнаружения ошибок и вывода журнала.




Инструмент позволяет создавать конвейеры, которые можно встроить в любую существующую систему CI/CD. 




75. Garden




Garden — инструмент для разработчиков, который автоматизирует ваши рабочие процессы и делает разработку и тестирование приложений Kubernetes быстрее и проще. Подходит для совместной разработки в удаленном кластере.







Сервисные сетки




76. Kiali




Kiali помогает создавать определения, проверять и наблюдать за работой микросервисов и соединений в сервисной сетке Istio. Инструмент создает визуальное графическое представление топологии сервисной сетки и дает представление о таких функциях, как разрыв цепи (circuit breaker), маршрутизация запросов, задержка и других. 




77. Kuma




Универсальная панель управления для сервисных сеток и микросервисов. Может нативно работать и в виртуальной среде, и в Kubernetes. Легко вводится в арсенал инструментов любой команды в организации.







78. Tenkai




Tenkai — это менеджер микросервисов, основанный на диаграммах Helm. Инструмент с графическим веб-интерфейсом позволяет вызывать репозитории из диаграмм Helm, легко их настраивать и деплоить.







Обнаружение служб




79. Обнаружение cлужб Vert.X




Репозиторий с множеством инструментов для обнаружения служб, которые видны из ваших приложений с микросервисами. Службы можно импортировать и из Kubernetes (а также из Docker и Consul).




Визуализация и управление




80. Octant




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




81. Kubernetic




Kubernetic помогает легко и быстро развертывать общедоступные или приватные диаграммы, видеть все связанные объекты кластера и их зависимости на одном экране. Отличается такими функциями, как визуализация в реальном времени, а также поддержка нескольких кластеров.







82. Kubernetes Dashboard




Универсальный веб-интерфейс кластеров Kubernetes. С помощью этой нативной панели управления проще устранять неполадки и мониторить кластеры. 







83. Kubeapps




Веб-интерфейс для каталога приложений в кластерах Kubernetes. Позволяет устанавливать, обновлять и удалять Helm-чарты нажатием одной кнопки, без использования командной строки.





https://embedd.srv.habr.com/iframe/5f9a6367d4323713fd415876




84. Lens




Приложение для рабочего стола, работает в Windows, Mac и Linux. Может подключаться к локальному кластеру K8s, подходит для небольшого количества кластеров.







85. Kubevious




Программное обеспечение с открытым исходным кодом, удобный графический интерфейс. Отображает все конфигурации, относящиеся к приложению, в одном месте. Это экономит время, избавляя от необходимости искать настройки и копаться в селекторах и метках. Один из недостатков инструмента — он работает непосредственно на кластере K8s. Значит, вам придется развертывать Kubevious на каждом кластере, а не просто указывать на существующий.





https://embedd.srv.habr.com/iframe/5f9a6368905dc4e15aeed79b




86. Kubelive




Основанный на терминалах пользовательский интерфейс, использующий Node.js. Довольно прост в использовании, но в настоящее время ограничен несколькими командами kubectl. Позволяет легко перемещаться по различным пространствам имен кластера K8s и быстро отображать состояние заданного набора подов.







87. K9s




Еще один удобный пользовательский интерфейс, упрощает навигацию, наблюдение и управление вашими приложениями.




Инструменты для бессерверных вычислений/функций




88. Kubeless




Безсерверная инфраструктура Kubernetes с открытым исходным кодом, которая позволяет вам развертывать небольшие фрагменты кода. Поддерживает большинство популярных языков, позволяет редактировать и развертывать функции в режиме реального времени.




89. Fission




Еще один открытый серверный фреймворк Kubernetes с открытым исходным кодом. Поддерживает все языки программирования. Напишите недолговечные функции на любом языке и сопоставьте их с HTTP-запросами (или другими триггерами событий) — инструмент позволяет развернуть функции мгновенно с помощью одной команды. Нет контейнеров для сборки и нет реестров Docker для управления.







90. Funktion




Это модель программирования лямбда-стиля с открытым исходным кодом для Kubernetes. Позволяет разработчикам сосредоточиться на написании функций, в то время как Kubernetes позаботится обо всем остальном.




91. IronFunction




Серверная вычислительная платформа с открытым исходным кодом для любого облака — частного, общедоступного или гибридного. Используя этот инструмент, разработчики могут просто загрузить свой код, пока платформа работает с инфраструктурой. 




92. OpenFaaS




Упрощает развертывание как функций, так и существующего кода в Kubernetes. Работает в публичных и частных облаках. Позволяет создавать микросервисы и функции на любом языке. 




93. Nuclio




Cерверный проект, который позволяет использовать его в качестве автономного контейнера Docker или даже поверх другого кластера Kubernetes. Предназначен для работы с высокопроизводительными событиями и большими объемами данных. Также обеспечивает обработку данных в режиме реального времени с минимальными издержками.




94. Virtual-Kubelet




Является открытой реализацией Kubernetes Kubelet. Запускается внутри контейнера в вашем текущем кластере и маскируется под узел. Оттуда он контролирует запланированные пакеты так, как это делает настоящий Kubelet.




На этом всё. Пишите в комментариях, если знаете другие полезные инструменты.




Источник: https://habr.com/ru/company/vk/blog/499676/



2022-08-31T19:40:06
DevOps

Как диагностировать проблемы соединения в Kubernetes при помощи Mizu

Стоит попробовать Mizu – это ПО для мониторинга Kubernetes-трафика. Программа может сильно упростить ежедневную диагностику сетей, да и жизнь в целом.




Одна из наиболее частых задач, с которыми сталкиваются администраторы Kubernetes по ходу тестирования и дебаггинга – проверка коммуникаций между компонентами внутри сети. 




Если вы хоть как-то взаимодействуете c Kubernetes по работе, то наверняка частенько проверяете входящий трафик, чтобы изучить входящие запросы и т.п. Обычно задачи подобного рода решаются при помощи утилиты tcpdump, установленной в конкретный контейнер. Таким образом, проверяются некоторые сетевые аспекты вне контейнеров, но иногда такой подход оказывается довольно сложным из-за специфики окружения или конфигурации системы. 




Чтобы не натыкаться на кучу проблем по ходу мониторинга сети, советую использовать утилиту Mizu. Многие программисты, работающие с Kubernetes, мечтали бы найти подобный инструмент раньше.




Mizu можно описать как простой, но при этом мощный инструмент для отслеживания трафика в Kubernetes. Он позволяет отслеживать все API-коммуникации между микросервисами независимо от используемого протокола и упрощает процесс дебаггинга соединений.




Установка Mizu




Процесс установки довольно простой. Все что нужно – загрузить бинарный файл Mizu и настроить соответствующие разрешения в системе. Выбор бинарного файла (установщика) зависит от архитектуры устройства. Например, чтобы установить Mizu на компьютер Apple с чипом Intel нужно ввести в терминал команду:




‌curl -Lo mizu github.com/up9inc/mizu/releases/latest/download/mizu_darwin_amd64 && chmod 755 mizu && mv mizu /usr/local/bin




Обычно этого достаточно. Загруженный бинарный файл теперь можно использовать для подключения к кластеру Kubernetes и работы с Kubernetes API, но для этого нужно внести несколько изменений в настройки Докера. 




Вот как это может выглядеть в случае с базовым nginx-сервером. Начать стоит с команды:




‌kubectl run simple-app --image=nginx --port 3000




После развертки базового приложения на основе nginx переходим непосредственно к запуску Mizu. Делается это всего одной командой:




mizu tap




Через пару секунд на экране появится веб-страница с интерфейсом Mizu. Здесь и отображается весь трафик на выбранном сервере. Но для настройки такого поведения необходимо внести изменения в параметры портов. К примеру, если ваше приложение называется ‘my-app’, команда будет выглядеть так:




kubectl expose pod/my-app




После этого деплоим еще один временный сервер, используя готовый образ (при помощи следующей команды):




kubectl run -it --rm --image=curlimages/curl curly -- sh




Теперь можно использовать утилиту curl для отправки запросов непосредственно на nginx-сервер. Например, так:




curl -vvv http://my-app:3000




Уже после первых нескольких запросов вы увидите большой объем полезной информации, отображающейся в интерфейсе Mizu. В первую очередь стоит отметить то, насколько детально описываются все процессы, происходящие внутри Kubernetes. Но что еще важнее, в Mizu есть диаграммы, наглядно показывающие зависимости между запросами с учетом используемого протокола и другой полезной информации. 




Конечно, Mizu не сможет заменить более сложные продукты и полноценные системы наблюдения за сетью. Но это довольно удобный инструмент, который поможет вам исправить немало багов по ходу работы с Kubernetes, и его точно стоит иметь под рукой.




Источник: https://te.legra.ph/Kak-diagnostirovat-problemy-soedineniya-v-Kubernetes-pri-pomoshchi-Mizu-07-09



2022-08-07T23:59:02
DevOps

Как настроить удобный терминал Kubernetes

Kubernetes поставляется в комплекте с выдающимся CLI.




Для основных операций это работает чудесно.




Увы, когда нужно что-то сделать быстро, сложность возрастает.




Сообщество Kubernetes создало все виды веб-инструментов для мониторинга вашего кластера – kube ops, grafana и т. д.




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




Это основная часть вашего швейцарского армейского ножа.




Ниже приведен очень короткий список инструментов с открытым исходным кодом, которые можно применить в своем терминале.




При совместном использовании они позволяют управлять кластером kubernetes, быстро устранять неполадки и отслеживать поведение.




 Предпосылки




Прежде чем приступить к изучению этих инструментов, я настоятельно рекомендую установить zsh.




Это выдающаяся оболочка с открытым исходным кодом для стандартного терминала OSX.




Он более многофункциональный и интуитивно понятный, а плагины, которые вы можете установить, просто фантастические.




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




Лучшие инструменты для управления Kubernetes




k9s







Я начинаю с самого мощного.




K9s –  это основа CLI для кластера kubernetes.




Вы можете проваливаться по SSH прямо в поды одним нажатием клавиши, просматривать журналы, удалять ресурсы и многое другое.




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




Это основной продукт для любого инженера, использующего kubernetes.







kubectx




Очень редко у нас будет только один кластер.




Переключение между ними можно так же просто осуществлять:




kubectl config use-context my-context




Но при этом есть некоторые предпосылки:




  • Вам нужно знать имя кластера, прежде чем запускать команду.
  • Есть другая, похожая команда set-context, которая может сбить вас с толку.




kubectx представляет более простую альтернативу этому варианту.




Если вы запустите kubectx самостоятельно, он перечислит все контексты в вашем файле .kube/config.




Затем вы можете указать название интересующего вас контекста:




kubectx my-context




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




Красиво и просто.




В сочетании с K9s, этот набор обеспечивает классную навигацию из вашего CLI с минимальными нажатиями клавиш.







kubens




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




Еще раз, очень часто в вашем кластере имеется несколько пространств имен.




Короче, в двух словах это то же самое, что kubectx, только для пространств имен.




kubens kube-system




Теперь все ваши команды по умолчанию выполняются в пространстве имен системы kube-system.




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




kube-ps1




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




Но как узнать, на кого вы сейчас нацелены?




Каждый раз постоянно это проверять?




На данный момент, чтобы узнать, вам нужно запустить:




kubens
kubectx
kubectl <my-command>




Чтобы не делать этого, ps1 является плагином zsh, который автоматически покажет вам ваш текущий контекст и пространство имен:







Теперь вы можете увидеть, на какое пространство имен и контекст вы указываете, не выполняя ни одной команды.




Он также очень настраиваемый – вы можете отключить пространство имен или контекст, если вас интересует только что-то одно из них, или вы можете использовать kubeoff, чтобы полностью отключить все это.




popeye




Popeye запускает автоматическое сканирование ресурсов в вашем хранилище и выявляет очевидные проблемы.




Это новый инструмент, который я нашел очень полезным.




Если вы затеяли генеральную уборку в кластере, начните с popeye, и вы получите четкие указания о том, что нужно исправить.







Stern




Вы когда-нибудь использовали логи kubectl?




Заметили, что вы можете следить только за журналами с одного пода одновременно?




Не беспокойтесь больше об этом!




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




Источник: https://itisgood.ru/2020/01/22/kak-nastroit-udobnyj-terminal-kubernetes/



2022-08-07T23:52:21
DevOps

Обзор k9s — продвинутого терминального интерфейса для Kubernetes

K9s предоставляет пользовательский интерфейс терминала для взаимодействия с кластерами Kubernetes. Цель этого Open Source-проекта — облегчить удобную навигацию по приложениям в K8s, наблюдение за ними и управление ими. K9s постоянно следит за изменениями в Kubernetes и предлагает быстрые команды для работы с наблюдаемыми ресурсами.




Проект написан на Go, существует уже более полутора лет: первый коммит был сделан 1 февраля 2019 года. На момент написания статьи насчитывается 9000+ звезд на GitHub и около 80 контрибьюторов. Посмотрим, что умеет k9s?




Установка и запуск




Это клиентское (по отношению к кластеру Kubernetes) приложение, которое проще всего запустить как Docker-образ:




docker run --rm -it -v $KUBECONFIG:/root/.kube/config quay.io/derailed/k9s




Для некоторых Linux-дистрибутивов и других ОС также есть готовые для установки пакеты. В общем случае для Linux-систем можно установить бинарный файл:




sudo wget -qO- https://github.com/derailed/k9s/releases/download/v0.22.0/k9s_Linux_x86_64.tar.gz | tar zxvf -  -C /tmp/
sudo mv /tmp/k9s /usr/local/bin




Каких-то специфических требований к самому кластеру K8s нет. Судя по отзывам, приложение работает и с такими старыми версиями Kubernetes, как 1.12.




Приложение запускается, используя стандартный конфиг .kube/config — аналогичному тому, как это делает kubectl.




Навигация




По умолчанию открывается окно со стандартным namespace, который указан для контекста. То есть, если вы прописали kubectl config set-context --current --namespace=test, то и откроется namespace test(О смене контекстов/пространств имён см. ниже.)







Переход в режим команд осуществляется нажатием на «:». После этого можно управлять работой k9s с помощью команд — например, для просмотра списка StatefulSets (в текущем пространстве имен) можно ввести :sts.







Для некоторых других ресурсов Kubernetes:




  • :ns — Namespaces;
  • :deploy — Deployments;
  • :ing — Ingresses;
  • :svc — Services.




Чтобы вывести полный список типов ресурсов, доступных для просмотра, есть команда :aliases.




Удобно просматривать и список команд, доступных по горячим комбинациям клавиш в рамках текущего окна: для этого достаточно нажать на «?».







Также в k9s есть режим поиска, для перехода в который достаточно ввести «/». С ним осуществляется поиск по содержимому текущего «окна». Допустим, если вы до этого ввели :ns, у вас открыт список пространств имён. Если их слишком много, то, чтобы не скроллить долго вниз, достаточно в окне с namespaces ввести /mynamespace.




Для поиска по лейблам можно выбрать все pod’ы в нужном пространстве имён, после чего ввести, например, / -l app=whoami. Мы получим список pod’ов с этим лейблом:







Поиск работает во всех видах окон, включая логи, просмотр YAML-манифестов и describe для ресурсов — подробнее об этих возможностях см. ниже.




Как в целом выглядит последовательность действий для навигации?




С помощью команды :ctx можно выбрать контекст:







Для выбора namespace’а есть уже упоминавшаяся команда :ns, а далее можно воспользоваться поиском для нужного пространства: /test.




Если теперь выбрать интересующий нас ресурс (например, всё тот же StatefulSet), для него покажется соответствующая информация: сколько запущено pod’ов с краткими сведениями о них.







Могут быть интересны только pod’ы — тогда достаточно ввести :pod. В случае с ConfigMap’ами (:cm — для списка этих ресурсов) можно выбрать интересующий объект и нажать на «u», после чего K9s подскажет, кто конкретно его (этот CM) использует.




Ещё одна удобная фича для просмотра ресурсов — их «рентген» (XRay view). Такой режим вызывается командой :xray RESOURCE и… проще показать, как он работает, чем объяснять. Вот иллюстрация для StatefulSets:







(Каждый из этих ресурсов можно редактировать, изменять, делать describe.)




А вот Deployment с Ingress:







Работа с ресурсами




О каждом ресурсе можно получить информацию в YAML или его describe нажатием на соответствующие клавиатурные сочетания («y» и «d» соответственно). Базовых операций, конечно, ещё больше: их список и клавиатурные сочетания всегда на виду благодаря удобной «шапке» в интерфейсе (скрывается нажатием на Ctrl + e).







При редактировании любого ресурса («e» после его выбора) открывается текстовый редактор, определённый в переменных окружения (export EDITOR=vim).




А вот как выглядит подробное описание ресурса (describe):







Такой вывод (или вывод просмотр YAML-манифеста ресурса) можно сохранить с помощью привычного сочетания клавиш Ctrl + s. Куда он сохранится, будет известно из сообщения K9s:




Log /tmp/k9s-screens-root/kubernetes/Describe-1601244920104133900.yml saved successfully!




Из созданных файлов-бэкапов можно и восстанавливать ресурсы, предварительно убрав системные лейблы и аннотации. Для этого потребуется перейти в директорию с ними (:dir /tmp), после чего выбрать нужный файл и применить apply.




К слову, в любой момент можно откатиться и на прошлый ReplicaSet, если с текущим есть проблемы. Для этого надо выбрать нужный RS (:rs для их списка):







… и выполнить rollback с помощью Ctrl + l. Мы должны получить уведомление, что все прошло успешно:




k9s/whoami-5cfbdbb469 successfully rolled back




А чтобы масштабировать реплики, достаточно нажать на «s» (scale) и выбрать нужное количество экземпляров:







В любой из контейнеров можно зайти с помощью shell: для этого перейдите к нужному pod’у, нажмите на «s» (shell) и выберите контейнер.




Другие возможности




Конечно, поддерживается и просмотр логов («l» для выбранного ресурса). А чтобы смотреть новые логи, нет необходимости постоянно нажимать Enter: достаточно сделать маркировку («m»), после чего отслеживать только новые сообщения.







Также в этом же окне можно выбрать временной диапазон для вывода логов:




  • клавиша «1» — за 1 минуту;
  • «2» — 5 минут;
  • «3» — 15 минут;
  • «4» — 30 минут;
  • «5» — 1 час;
  • «0» — за все время жизни pod’а.




Специальный режим работы Pulse (команда :pulse) показывает общие сведения о Kubernetes-кластере:







В нем можно увидеть количество ресурсов и их состояние (зеленым показываются те, что имеют статус Running).




Еще одна интересная функция K9s называется Popeye. Она проверяет все ресурсы на определённые критерии корректности и выводит получившийся «рейтинг» с пояснениями. Например, можно увидеть, что не хватает проб или лимитов, а какой-то контейнер может запускаться под root…







Имеется базовая поддержка Helm. Например, так можно посмотреть релизы, задеплоенные в кластер:




:helm all # все
:helm $namespace # в конкретном пространстве имен




Benchmark




В K9s встроили даже hey — это простой генератор нагрузки на HTTP-сервер, альтернатива более известному ab (ApacheBench).




Чтобы включить его, потребуется активация port-forward в pod’е. Для этого выбираем pod и нажимаем на Shift + f, переходим в подменю port-forward с помощью алиаса «pf».







После выбора порта и нажатия на Ctrl + b запустится сам benchmark. Результаты его работы сохраняются в /tmp и доступны для последующего просмотра в K9s.










Для изменения конфигурации benchmark’а нужно создать файл $HOME/.k9s/bench-<my_context>.yml (определяется для каждого кластера).




NB: Важно, чтобы расширение всех YAML-файлов в директории .k9s было именно .yml (.yaml не работает корректно).




Пример конфигурации:




benchmarks:
  defaults:
    # Количество потоков
    concurrency: 2
    # Количество запросов
    requests: 1000
  containers:
    # Настройки для контейнера с бенчмарком
    # Контейнер определяется как namespace/pod-name:container-name
    default/nginx:nginx:
      concurrency: 2
      requests: 10000
      http:
        path: /
        method: POST
        body:
          {"foo":"bar"}
        header:
          Accept:
            - text/html
          Content-Type:
            - application/json
 services:
    # Можно проводить бенчмарк на сервисах типа NodePort и LoadBalancer
    # Синтаксис: namespace/service-name
    default/nginx:
      concurrency: 5
      requests: 500
      http:
        method: GET
        path: /auth
      auth:
        user: flant
        password: s3cr3tp455w0rd




Интерфейс




Вид столбцов для списков ресурсов модифицируется созданием файла $HOME/.k9s/views.yml. Пример его содержимого:




k9s:
 views:
   v1/pods:
     columns:
       - AGE
       - NAMESPACE
       - NAME
       - IP
       - NODE
       - STATUS
       - READY
   v1/services:
     columns:
       - AGE
       - NAMESPACE
       - NAME
       - TYPE
       - CLUSTER-IP




Правда, не хватает колонки по лейблам, на что есть issue в проекте.




Сортировка по столбцам осуществляется клавиатурными сочетаниями:




  • Shift + n — по имени;
  • Shift + o — по узлам;
  • Shift + i — по IP;
  • Shift + a — по времени жизни контейнера;
  • Shift + t — по количеству рестартов;
  • Shift + r — по статусу готовности;
  • Shift + c — по потреблению CPU;
  • Shift + m — по потреблению памяти.




Если же кому-то не нравится цветовое оформление по умолчанию, в K9s даже поддерживаются скины. Готовые примеры (7 штук) доступны здесь. Вот пример одного из таких скинов (in the navy):







Плагины




Наконец, плагины позволяют расширять возможности K9s. Сам я в работе использовал только один из них — kubectl get all -n $namespace.




Выглядит это следующим образом. Создаем файл $HOME/.k9s/plugin.yml с таким содержимым:




plugin:
 get-all:
   shortCut: g    
   confirm: false    
   description: get all
   scopes:
   - all
   command: sh
   background: false
   args:
   - -c
   - "kubectl -n $NAMESPACE get all -o wide | less"




Теперь можно перейти в пространство имён и нажать на «g» для выполнения с соответствующей команды:







Среди плагинов есть, например, интеграции с kubectl-jq и утилитой для просмотра логов stern.




Заключение




На мой вкус, K9s оказалась очень удобна в работе: с ней довольно быстро привыкнуть искать всё нужное без использования kubectl. Порадовал просмотр логов и их сохранение, быстрое редактирование ресурсов, скорость работы в целом*, оказался полезным режим Popeye. Отдельного упоминания стоят возможности создавать плагины и дорабатывать приложение под свои нужды.




* Хотя при большом объеме логов замечал также медленную работу K9s. В такие моменты утилита «съедала» 2 ядра у Intel Xeon E312xx и могла даже зависать.




Чего не хватает в настоящий момент? Быстрого отката на предыдущую версию (речь не про RS) без перехода в директорию. К тому же, восстановление происходит только для всего ресурса: если вы удалили аннотацию или лейбл, придется удалить и восстановить весь ресурс (здесь и понадобится переходить в директорию). Другая мелочь — не хватает даты таких сохраненных «бэкапов».




Источник: https://habr.com/ru/company/flant/blog/524196/



2022-07-28T23:48:08
DevOps

Принудительное удаление зависших подов в Kubernetes

В этом коротком руководстве мы рассмотрим, как удалить удаленные или завершенные поды в кластере Kubernetes.Есть много причин, по которым вы можете обнаружить, что некоторые поды находятся в состоянии Evicted и Terminated.В случае eviction это часто происходит в результате нехватки ресурсов на рабочих нодах или ошибки приложения.Terminated может быть результатом уменьшения масштаба приложения или развертывания новой версии приложения, после которой прекращается работа старых подов.Служба kubelet, которая работает на каждом узле кластера, отвечает за состояние eviction подов.Вы можете получить список подов в пространстве имен, застрявших в состоянии Evicted и Terminated, выполнив следующую команду:




kubectl get pods -n namespace | egrep -i 'Terminated|Evicted'




Как удалить поды в Kubernetes




Вы можете удалить эти поды разными способами.




Использование собственных команд kubectl и Bash




Это команды bash с фильтрацией, которые вы можете запустить для принудительного удаления подов в пространстве имен, которые застряли в завершенном состоянии.




# Определение неймспейса
namespace="mynamespace"

# Получаем поды
epods=$(kubectl get pods -n ${namespace} | egrep -i 'Terminated|Evicted' | awk '{print $1 }')

# Удаляем их
for i in ${epods[@]}; do
  kubectl delete pod --force=true --wait=false --grace-period=0 $i -n ${namespace}
done




Подтвердите, есть ли еще контейнеры в этом состоянии.




kubectl get pods -n ${namespace} | egrep -i 'Terminated|Evicted'




Удаление всех исключенных и завершенных модулей из всех пространств имен:




kubectl get pods --all-namespaces | egrep -i  'Evicted|Terminated' | awk '{print $2 " --namespace=" $1}' | xargs kubectl delete pod --force=true --wait=false --grace-period=0




Удалите все контейнеры в состоянии ImagePullBackOff из всех пространств имен – Бонус:




kubectl get pods --all-namespaces | grep -E 'ImagePullBackOff|ErrImagePull|Evicted' | awk '{print $2 " --namespace=" $1}' | xargs kubectl delete pod




Использование фильтров kubectl и jq




Вы также можете отфильтровать вывод команды kubectl и перенаправить в jq для получения определенных столбцов.




Сначала установите команду jq:




--- Ubuntu / Debian ---
$ sudo apt update && sudo apt install jq

--- CentOS/Fedora ---
$ sudo yum -y install epel-release
$ sudo yum -y install jq

--- RHEL ---
wget https://github.com/stedolan/jq/releases/download/jq-1.6/jq-linux64 -O jq
chmod +x jq
sudo mv jq /usr/local/bin




Затем удалите застрявшие поды с помощью команды:




kubectl get pods --all-namespaces -o json | jq '.items[] | select(.status.reason!=null) | select(.status.reason | contains("Evicted")) | "kubectl delete pods (.metadata.name) -n (.metadata.namespace)"' | xargs -n 1 bash -c




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



2022-04-14T17:43:08
DevOps

Установка и настройка кластера Kubernetes на Ubuntu Server

Есть различные готовые реализации кластера Kubernetes, например:




  • Minikube — готовый кластер, который разворачивается на один компьютер. Хороший способ познакомиться с Kubernetes.
  • Kubespray — набор Ansible ролей.
  • Готовые кластеры в облаке, например AWS, Google Cloud, Yandex Cloud и так далее.




Использовать одну из готовых реализаций — быстрый и надежный способ развертывания системы оркестрации контейнеров Docker. Однако, мы рассмотрим ручное создание кластера Kubernetes из 3-х нод — один мастер (управление) и две рабочие ноды (запуск контейнеров).




Подготовка системы




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




Настройка системы




1. Задаем имена узлам. Для этого выполняем команды на соответствующих серверах:




hostnamectl set-hostname k8s-master1.dmosk.local




hostnamectl set-hostname k8s-worker1.dmosk.local




hostnamectl set-hostname k8s-worker2.dmosk.local




* в данном примере мы зададим имя k8s-master1 для мастера и, соответственно, k8s-worker1 и k8s-worker2 — для первого и второго рабочих нод. Каждая команда выполняется на своем сервере.




Необходимо, чтобы наши серверы были доступны по заданным именам. Для этого необходимо на сервере DNS добавить соответствующие А-записи. Или на каждом сервере открываем hosts:




vi /etc/hosts




И добавляем записи на подобие: 




192.168.0.15     k8s-master1.dmosk.local k8s-master1

192.168.0.20     k8s-worker1.dmosk.local k8s-worker1

192.168.0.25     k8s-worker2.dmosk.local k8s-worker2




* где, 192.168.0.15, 192.168.0.20, 192.168.0.25 — IP-адреса наших серверов, k8s-master1, k8s-worker1, k8s-worker2 — имена серверов, dmosk.local — наш внутренний домен.




2. Устанавливаем необходимые компоненты — дополнительные пакеты и утилиты. Для начала, обновим список пакетов и саму систему:




apt-get update && apt-get upgrade




Выполняем установку пакетов:




apt-get install curl apt-transport-https git iptables-persistent




* где:




  • git — утилита для работы с GIT. Понадобиться для загрузки файлов из репозитория git.
  • curl — утилита для отправки GET, POST и других запросов на http-сервер. Понадобиться для загрузки ключа репозитория Kubernetes.
  • apt-transport-https — позволяет получить доступ к APT-репозиториям по протоколу https.
  • iptables-persistent — утилита для сохранения правил, созданных в iptables (не обязательна, но повышает удобство).




В процессе установки iptables-persistent может запросить подтверждение сохранить правила брандмауэра — отказываемся.




3. Отключаем файл подкачки. С ним Kubernetes не запустится.




Выполняем команду для разового отключения:




swapoff -a




Чтобы swap не появился после перезагрузки сервера, открываем на редактирование файл:




vi /etc/fstab




И комментируем строку: 




#/swap.img      none    swap    sw      0       0




4. Загружаем дополнительные модули ядра.




vi /etc/modules-load.d/k8s.conf




br_netfilter

overlay




* модуль br_netfilter расширяет возможности netfilter (подробнее); overlay необходим для Docker.




Загрузим модули в ядро:




modprobe br_netfilter




modprobe overlay




Проверяем, что данные модули работают:




lsmod | egrep "br_netfilter|overlay"




Мы должны увидеть что-то на подобие:




overlay               114688  10

br_netfilter           28672  0

bridge                176128  1 br_netfilter




5. Изменим параметры ядра.




Создаем конфигурационный файл:




vi /etc/sysctl.d/k8s.conf 




net.bridge.bridge-nf-call-ip6tables = 1

net.bridge.bridge-nf-call-iptables = 1




net.bridge.bridge-nf-call-iptables контролирует возможность обработки трафика через bridge в netfilter. В нашем примере мы разрешаем данную обработку для IPv4 и IPv6.




Применяем параметры командой:




sysctl --system




Брандмауэр




Для мастер-ноды и рабочей создаем разные наборы правил.




По умолчанию, в Ubuntu брандмауэр настроен на разрешение любого трафика. Если мы настраиваем наш кластер в тестовой среде, настройка брандмауэра не обязательна.




1. На мастер-ноде (Control-plane)




Выполняем команду:




iptables -I INPUT 1 -p tcp --match multiport --dports 6443,2379:2380,10250:10252 -j ACCEPT




* в данном примере мы открываем следующие порты:




  • 6443 — подключение для управления (Kubernetes API).
  • 2379:2380 — порты для взаимодействия мастера с воркерами (etcd server client API).
  • 10250:10252 — работа с kubelet (соответственно API, scheduler, controller-manager).




Для сохранения правил выполняем команду:




netfilter-persistent save




2. На рабочей ноде (Worker):




На нодах для контейнеров открываем такие порты:




iptables -I INPUT 1 -p tcp --match multiport --dports 10250,30000:32767 -j ACCEPT




* где:




  • 10250 — подключение к kubelet API.
  • 30000:32767 — рабочие порты по умолчанию для подключения к подам (NodePort Services).




Сохраняем правила командой:




netfilter-persistent save




Установка и настройка Docker




На все узлы кластера выполняем установку Docker следующей командой:




apt-get install docker docker.io




После установки разрешаем автозапуск сервиса docker:




systemctl enable docker




Создаем файл:




vi /etc/docker/daemon.json




{

  "exec-opts": ["native.cgroupdriver=systemd"],

  "log-driver": "json-file",

  "log-opts": {

    "max-size": "100m"

  },

  "storage-driver": "overlay2",

  "storage-opts": [

    "overlay2.override_kernel_check=true"

  ]

}




* для нас является важной настройкой cgroupdriver — она должна быть выставлена в значение systemd. В противном случае, при создании кластера Kubernetes выдаст предупреждение. Хоть на возможность работы последнего это не влияет, но мы постараемся выполнить развертывание без ошибок и предупреждений со стороны системы.




И перезапускаем docker:




systemctl restart docker




Установка Kubernetes




Установку необходимых компонентов выполним из репозитория. Добавим его ключ для цифровой подписи:




curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -




Создадим файл с настройкой репозитория:




vi /etc/apt/sources.list.d/kubernetes.list




deb https://apt.kubernetes.io/ kubernetes-xenial main




Обновим список пакетов:




apt-get update




Устанавливаем пакеты: 




apt-get install kubelet kubeadm kubectl




* где:




  • kubelet — сервис, который запускается и работает на каждом узле кластера. Следит за работоспособностью подов.
  • kubeadm — утилита для управления кластером Kubernetes.
  • kubectl — утилита для отправки команд кластеру Kubernetes.




Нормальная работа кластера сильно зависит от версии установленных пакетов. Поэтому бесконтрольное их обновление может привести к потере работоспособности всей системы. Чтобы этого не произошло, запрещаем обновление установленных компонентов:




apt-mark hold kubelet kubeadm kubectl




Установка завершена — можно запустить команду:




kubectl version --client




… и увидеть установленную версию программы: 




Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.2", GitCommit:"faecb196815e248d3ecfb03c680a4507229c2a56", GitTreeState:"clean", BuildDate:"2021-01-13T13:28:09Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}




Наши серверы готовы к созданию кластера.




Создание кластера




По-отдельности, рассмотрим процесс настройки мастер ноды (control-plane) и присоединения к ней двух рабочих нод (worker).




Настройка control-plane (мастер ноды)




Выполняем команду на мастер ноде:




kubeadm init --pod-network-cidr=10.244.0.0/16




* данная команда выполнит начальную настройку и подготовку основного узла кластера. Ключ —pod-network-cidr задает адрес внутренней подсети для нашего кластера.




Выполнение займет несколько минут, после чего мы увидим что-то на подобие:




...

Then you can join any number of worker nodes by running the following on each as root:



kubeadm join 192.168.0.15:6443 --token f7sihu.wmgzwxkvbr8500al 

    --discovery-token-ca-cert-hash sha256:6746f66b2197ef496192c9e240b31275747734cf74057e04409c33b1ad280321




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




В окружении пользователя создаем переменную KUBECONFIG, с помощью которой будет указан путь до файла конфигурации kubernetes:




export KUBECONFIG=/etc/kubernetes/admin.conf




Чтобы каждый раз при входе в систему не приходилось повторять данную команду, открываем файл: 




vi /etc/environment




И добавляем в него строку: 




export KUBECONFIG=/etc/kubernetes/admin.conf




Посмотреть список узлов кластера можно командой:




kubectl get nodes




На данном этапе мы должны увидеть только мастер ноду:




NAME                      STATUS     ROLES                  AGE   VERSION

k8s-master.dmosk.local    NotReady   <none>                 10m   v1.20.2




Чтобы завершить настройку, необходимо установить CNI (Container Networking Interface) — в моем примере это flannel:




kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml




* краткий обзор и сравнение производительности CNI можно почитать в статье на хабре.




Узел управления кластером готов к работе.




Настройка worker (рабочей ноды)




Мы можем использовать команду для присоединения рабочего узла, которую мы получили после инициализации мастер ноды или вводим (на первом узле):




kubeadm token create --print-join-command




Данная команда покажет нам запрос на присоединения новой ноды к кластеру, например:




kubeadm join 192.168.0.15:6443 --token f7sihu.wmgzwxkvbr8500al 

    --discovery-token-ca-cert-hash sha256:6746f66b2197ef496192c9e240b31275747734cf74057e04409c33b1ad280321




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




Run 'kubectl get nodes' on the control-plane to see this node join the cluster.




На мастер ноде вводим:




kubectl get nodes




Мы должны увидеть: 




NAME                      STATUS   ROLES                  AGE   VERSION

k8s-master1.dmosk.local   Ready    control-plane,master   18m   v1.20.2

k8s-worker1.dmosk.local   Ready    <none>                 79s   v1.20.2

k8s-worker2.dmosk.local   Ready    <none>                 77s   v1.20.2




Наш кластер готов к работе. Теперь можно создавать поды, развертывания и службы. Рассмотрим эти процессы подробнее.




Pods




Поды — неделимая сущность объекта в Kubernetes. Каждый Pod может включать в себя несколько контейнеров (минимум, 1). Рассмотрим несколько примеров, как работать с подами. Все команды выполняем на мастере.




Создание




Поды создаются командой kubectl, например:




kubectl run nginx --image=nginx:latest --port=80




* в данном примере мы создаем под с названием nginx, который в качестве образа Docker будет использовать nginx (последнюю версию); также наш под будет слушать запросы на порту 80.




Чтобы получить сетевой доступ к созданному поду, создаем port-forward следующей командой:




kubectl port-forward nginx --address 0.0.0.0 8888:80




* в данном примере запросы к кластеру kubernetes на порт 8888 будут вести на порт 80 (который мы использовали для нашего пода).




Команда kubectl port-forward является интерактивной. Ее мы используем только для тестирования. Чтобы пробросить нужные порты в Kubernetes используются Services — об этом будет сказано ниже.




Можно открыть браузер и ввести адрес http://<IP-адрес мастера>:8888 — должна открыться страница приветствия для NGINX.




Просмотр




Получить список всех подов в кластере можно командой:




kubectl get pods




Например, в нашем примере мы должны увидеть что-то на подобие:




NAME    READY   STATUS    RESTARTS   AGE

nginx   1/1     Running   0          3m26s




Посмотреть подробную информацию о конкретном поде можно командой:




kubectl describe pods nginx




Запуск команд внутри контейнера




Мы можем запустить одну команду в контейнере, например, такой командой:




kubectl exec nginx -- date




* в данном примере будет запущена команда date внутри контейнера nginx.




Также мы можем подключиться к командной строке контейнера командой:




kubectl exec --tty --stdin nginx -- /bin/bash




Удаление




Для удаления пода вводим:




kubectl delete pods nginx




Использование манифестов




В продуктивной среде управление подами выполняется с помощью специальных файлов с описанием того, как должен создаваться и настраиваться под — манифестов. Рассмотрим пример создания и применения такого манифеста.




Создадим файл формата yml:




vi manifest_pod.yaml




apiVersion: v1

kind: Pod

metadata: 

  name: web-srv

  labels:

    app: web_server

    owner: dmosk

    description: web_server_for_site

spec:

  containers: 

    - name: nginx

      image: nginx:latest

      ports:

        - containerPort: 80

        - containerPort: 443



    - name: php-fpm

      image: php-fpm:latest

      ports:

        - containerPort: 9000



    - name: mariadb

      image: mariadb:latest

      ports:

        - containerPort: 3306




* в данном примере будет создан под с названием web-srv; в данном поде будет развернуто 3 контейнера — nginxphp-fpm и mariadb на основе одноименных образов.




Для объектов Kubernetes очень важное значение имеют метки или labels. Необходимо всегда их описывать. Далее, данные метки могут использоваться для настройки сервисов и развертываний.




Чтобы применить манифест выполняем команду:




kubectl apply -f manifest_pod.yaml




Мы должны увидеть ответ:




pod/web-srv created




Смотрим поды командой:




kubectl get pods




Мы должны увидеть:




NAME      READY   STATUS    RESTARTS   AGE

web-srv   3/3     Ready     0          3m11s




* для Ready мы можем увидеть 0/3 или 1/3 — это значит, что контейнеры внутри пода еще создаются и нужно подождать.




Deployments




Развертывания позволяют управлять экземплярами подов. С их помощью контролируется их восстановление, а также балансировка нагрузки. Рассмотрим пример использования Deployments в Kubernetes.




Создание




Deployment создаем командой со следующим синтаксисом:




kubectl create deploy <название для развертывания> --image <образ, который должен использоваться>




Например:




kubectl create deploy web-set --image nginx:latest




* данной командой мы создадим deployment с именем web-set; в качестве образа будем использовать nginx:latest.




Просмотр




Посмотреть список развертываний можно командой:




kubectl get deploy




Подробное описание для конкретного развертывания мы можем посмотреть так:




kubectl describe deploy web-set




* в данном примере мы посмотрим описание deployment с названием web-set.




Scaling




Как было написано выше, deployment может балансировать нагрузкой. Это контролируется параметром scaling:




kubectl scale deploy web-set --replicas 3




* в данном примере мы указываем для нашего созданного ранее deployment использовать 3 реплики — то есть Kubernetes создаст 3 экземпляра контейнеров.




Также мы можем настроить автоматическую балансировку:




kubectl autoscale deploy web-set --min=5 --max=10 --cpu-percent=75




В данном примере Kubernetes будет создавать от 5 до 10 экземпляров контейнеров — добавление нового экземпляра будет происходить при превышении нагрузки на процессор до 75% и более.




Посмотреть созданные параметры балансировки можно командой:




kubectl get hpa




Редактирование




Для нашего развертывания мы можем изменить используемый образ, например:




kubectl set image deploy/web-set nginx=httpd:latest --record




* данной командой для deployment web-set мы заменим образ nginx на httpd; ключ record позволит нам записать действие в историю изменений.




Если мы использовали ключ record, то историю изменений можно посмотреть командой:




kubectl rollout history deploy/web-set




Перезапустить deployment можно командой:




kubectl rollout restart deploy web-set




Манифест




Как в случае с подами, для создания развертываний мы можем использовать манифесты. Попробуем рассмотреть конкретный пример.




Создаем новый файл:




vi manifest_deploy.yaml




apiVersion: apps/v1

kind: Deployment

metadata:

  name: web-deploy

  labels:

    app: web_server

    owner: dmosk

    description: web_server_for_site

spec:

  replicas: 5

  selector:

    matchLabels:

      project: myweb

  template:

    metadata:

      labels:

        project: myweb

        owner: dmosk

        description: web_server_pod

    spec:

      containers:

        - name: myweb-httpd

          image: httpd:latest

          ports:

            - containerPort: 80

            - containerPort: 443

            

---

apiVersion: autoscaling/v2beta2

kind: HorizontalPodAutoscaler

metadata:

  name: web-deploy-autoscaling

spec:

  scaleTargetRef:

    apiVersion: apps/v1

    kind: Deployment

    name: myweb-autoscaling

  minReplicas: 5

  maxReplicas: 10

  metrics:

  - type: Resource

    resource:

      name: cpu

      target:

        type: Utilization

        averageUtilization: 75

  - type: Resource

    resource:

      name: memory

      target:

        type: Utilization

        averageUtilization: 80




* в данном манифесте мы создадим deployment и autoscaling. Итого, мы получим 5 экземпляров подов для развертывания web-deploy, которые могут быть расширены до 10 экземпляров. Добавление нового будет происходить при превышении нагрузки на процессор более чем на 75% или потреблением оперативной памяти более чем на 80%.




Чтобы создать объекты с помощью нашего манифеста вводим:




kubectl apply -f manifest_deploy.yaml




Мы должны увидеть:




deployment.apps/web-deploy created

horizontalpodautoscaler.autoscaling/web-deploy-autoscaling created




Объекты web-deploy и web-deploy-autoscaling созданы.




Удаление




Для удаления конкретного развертывания используем команду:




kubectl delete deploy web-set




Для удаления всех развертываний вместо названия deployment указываем ключ —all:




kubectl delete deploy --all




Удалить критерии autoscaling для конкретного развертывания можно командой:




kubectl delete hpa web-set




Удалить все критерии autoscaling можно командой:




kubectl delete hpa --all




Удалить объекты, созданные с помощью манифеста можно командой:




kubectl delete -f manifest_deploy.yaml




Services




Службы позволяют обеспечить сетевую доступность для развертываний. Существует несколько типов сервисов:




  • ClusterIP — сопоставление адреса с deployments для подключений внутри кластера Kubernetes.
  • NodePort — для внешней публикации развертывания.
  • LoadBalancer — сопоставление через внешний балансировщик.
  • ExternalName — сопоставляет службу по имени (возвращает значение записи CNAME).




Мы рассмотрим первые два варианта.




Привязка к Deployments




Попробуем создать сопоставления для ранее созданного развертывания:




kubectl expose deploy web-deploy --type=ClusterIP --port=80




* где web-deploy — deployment, который мы развернули с помощью манифеста. Публикация ресурса происходит на внутреннем порту 80. Обращаться к контейнерам можно внутри кластера Kubernetes.




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




kubectl expose deploy web-deploy --type=NodePort --port=80




* данная команда отличается от команды выше только типом NodePort — для данному deployment будет сопоставлен порт для внешнего подключения, который будет вести на внутренний (в нашем примере, 80).




Просмотр




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




kubectl get services




Мы можем увидеть что-то на подобие:




NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE

web-deploy   NodePort    10.111.229.132   <none>        80:30929/TCP   21s




* в данном примере указано, что у нас есть служба типа NodePort, а к сервису можно подключиться по порту 30929.




Можно попробовать открыть браузер и ввести http://<IP-адрес мастера>:30929 — мы должны увидеть нужную нам страницу (в наших примерах, либо NGINX, либо Apache).




Посмотреть список сервисов с указанием селектором можно командой:




kubectl get services -o wide




Удаление




Удаляем созданную службу командой:




kubectl delete services web-deploy




* в данном примере будет удалена служба для развертывания web-deploy.




Удалить все службы можно командой:




kubectl delete services --all




Манифест




Как в случае с подами и развертываниями, мы можем использовать манифест-файлы. Рассмотрим небольшой пример.




vi manifest_service.yaml




apiVersion: v1

kind: Service

metadata:

  name: web-service

  labels:

    app: web_server

    owner: dmosk

    description: web_server_for_site

spec:

  selector:

    project: myweb

  type: NodePort

  ports:

    - name: app-http

      protocol: TCP

      port: 80

      targetPort: 80



    - name: app-smtp

      protocol: TCP

      port: 25

      targetPort: 25




* в данном примере мы создадим службу, которая будем связываться с развертыванием по лейболу project: myweb.




Ingress Controller




В данной инструкции не будет рассказано о работе с Ingress Controller. Оставляем данный пункт для самостоятельного изучения.




Данное приложение позволяет создать балансировщик, распределяющий сетевые запросы между нашими сервисами. Порядок обработки сетевого трафика определяем с помощью Ingress Rules.




Существует не маленькое количество реализаций Ingress Controller — их сравнение можно найти в документе по ссылке в Google Docs.




Для установки Ingress Controller Contour (среди множества контроллеров, он легко устанавливается и на момент обновления данной инструкции полностью поддерживает последнюю версию кластера Kubernetes) вводим:




kubectl apply -f https://projectcontour.io/quickstart/contour.yaml




Установка веб-интерфейса




Веб-интерфейс позволяет получить информацию о работе кластера в удобном для просмотра виде.




В большинстве инструкций рассказано, как получить доступ к веб-интерфейсу с того же компьютера, на котором находится кластер (по адресу 127.0.0.1 или localhost). Но мы рассмотрим настройку для удаленного подключения, так как это более актуально для серверной инфраструктуры.




Переходим на страницу веб-интерфейса в GitHub и копируем ссылку на последнюю версию файла yaml:







* на момент обновления инструкции, последняя версия интерфейса была 2.1.0.




Скачиваем yaml-файл командой:




wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.1.0/aio/deploy/recommended.yaml




* где https://raw.githubusercontent.com/kubernetes/dashboard/v2.1.0/aio/deploy/recommended.yaml — ссылка, которую мы скопировали на портале GitHub.




Открываем на редактирование скачанный файл:




vi recommended.yaml




Комментируем строки для kind: Namespace и kind: Secret (в файле несколько блоков с kind: Secret — нам нужен тот, что с name: kubernetes-dashboard-certs):




...

#apiVersion: v1

#kind: Namespace

#metadata:

#  name: kubernetes-dashboard

...

#apiVersion: v1

#kind: Secret

#metadata:

#  labels:

#    k8s-app: kubernetes-dashboard

#  name: kubernetes-dashboard-certs

#  namespace: kubernetes-dashboard

#type: Opaque




* нам необходимо закомментировать эти блоки, так как данные настройки в Kubernetes мы должны будем сделать вручную.




Теперь в том же файле находим kind: Service (который с name: kubernetes-dashboard) и добавляем строки type: NodePort и nodePort: 30001 (выделены красным):




kind: Service

apiVersion: v1

metadata:

  labels:

    k8s-app: kubernetes-dashboard

  name: kubernetes-dashboard

  namespace: kubernetes-dashboard

spec:

  type: NodePort

  ports:

    - port: 443

      targetPort: 8443

      nodePort: 30001

  selector:

    k8s-app: kubernetes-dashboard




* таким образом, мы публикуем наш сервис на внешнем адресе и порту 30001.




Для подключения к веб-интерфейсу не через локальный адрес, начиная с версии 1.17, обязательно необходимо использовать зашифрованное подключение (https). Для этого нужен сертификат. В данной инструкции мы сгенерируем самоподписанный сертификат — данный подход удобен для тестовой среды, но в продуктивной среде необходимо купить сертификат или получить его бесплатно в Let’s Encrypt.




И так, создаем каталог, куда разместим наши сертификаты:




mkdir -p /etc/ssl/kubernetes




Сгенерируем сертификаты командой:




openssl req -new -x509 -days 1461 -nodes -out /etc/ssl/kubernetes/cert.pem -keyout /etc/ssl/kubernetes/cert.key -subj "/C=RU/ST=SPb/L=SPb/O=Global Security/OU=IT Department/CN=kubernetes.dmosk.local/CN=kubernetes"




* можно не менять параметры команды, а так их и оставить. Браузер все-равно будет выдавать предупреждение о неправильном сертификате, так как он самоподписанный.




Создаем namespace:




kubectl create namespace kubernetes-dashboard




* это та первая настройка, которую мы комментировали в скачанном файле recommended.yaml.




Теперь создаем настройку для secret с использованием наших сертификатов:




kubectl create secret generic kubernetes-dashboard-certs --from-file=/etc/ssl/kubernetes/cert.key --from-file=/etc/ssl/kubernetes/cert.pem -n kubernetes-dashboard




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




Теперь создаем остальные настройки с помощью скачанного файла:




kubectl create -f recommended.yaml




Мы увидим что-то на подобие:




serviceaccount/kubernetes-dashboard created

service/kubernetes-dashboard created

secret/kubernetes-dashboard-csrf created

secret/kubernetes-dashboard-key-holder created

configmap/kubernetes-dashboard-settings created

role.rbac.authorization.k8s.io/kubernetes-dashboard created

clusterrole.rbac.authorization.k8s.io/kubernetes-dashboard created

rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created

clusterrolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created

deployment.apps/kubernetes-dashboard created

service/dashboard-metrics-scraper created

deployment.apps/dashboard-metrics-scraper created




Создадим настройку для админского подключения:




vi dashboard-admin.yaml




apiVersion: v1

kind: ServiceAccount

metadata:

  labels:

    k8s-app: kubernetes-dashboard

  name: dashboard-admin

  namespace: kubernetes-dashboard



---

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRoleBinding

metadata:

  name: dashboard-admin-bind-cluster-role

  labels:

    k8s-app: kubernetes-dashboard

roleRef:

  apiGroup: rbac.authorization.k8s.io

  kind: ClusterRole

  name: cluster-admin

subjects:

- kind: ServiceAccount

  name: dashboard-admin

  namespace: kubernetes-dashboard




Создаем настройку с применением созданного файла:




kubectl create -f dashboard-admin.yaml




Теперь открываем браузер и переходим по ссылке https://<IP-адрес мастера>:30001 — браузер покажет ошибку сертификата (если мы настраиваем по инструкции и сгенерировали самоподписанный сертификат). Игнорируем ошибку и продолжаем загрузку.




Kubernetes Dashboard потребует пройти проверку подлинности. Для этого можно использовать токен или конфигурационный файл:







На сервере вводим команду для создания сервисной учетной записи:




kubectl create serviceaccount dashboard-admin -n kube-system




Создадим привязку нашего сервисного аккаунта с Kubernetes Dashboard:




kubectl create clusterrolebinding dashboard-admin --clusterrole=cluster-admin --serviceaccount=kube-system:dashboard-admin




Теперь камандой:




kubectl describe secrets -n kube-system $(kubectl -n kube-system get secret | awk '/dashboard-admin/{print $1}')




… получаем токен для подключения (выделен красным): 




Data

====

ca.crt:     1066 bytes

namespace:  11 bytes

token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IkpCT0J5TWF2VWxWQUotdHZYclFUaWwza2NfTW1IZVNuSlZSN3hWUzFrNTAifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJkYXNoYm9hcmQtYWRtaW4tdG9rZW4tbnRqNmYiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZGFzaGJvYXJkLWFkbWluIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQudWlkIjoiMzIwNjVhYmQtNzAwYy00Yzk5LThmZjktZjc0YjM5MTU0Y2VhIiwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50Omt1YmUtc3lzdGVtOmRhc2hib2FyZC1hZG1pbiJ9.wvDGeNiTCRBakDplO6PbdqvPH_W2EsBgJjZnTDflneP3cdXQv6VgBkI8NalplXDRF-lF36KbbC2hpRjbkblrLW7BemIVWYOznmc8kmrgCSxO2FVi93NK3biE9TkDlj1BbdiyfOO86L56vteXGP20X0Xs1h3cjAshs-70bsnJl6z3MY5GbRVejOyVzq_PWMVYsqvQhssExsJM2tKJWG0DnXCW687XHistbYUolhxSRoRpMZk-JrguuwgLH5FYIIU-ZdTZA6mz-_hqrx8PoDvqEfWrsniM6Q0k8U3TMaDLlduzA7rwLRJBQt3C0aD6XfR9wHUqUWd5y953u67wpFPrSA




Используя полученный токен, вводим его в панели авторизации:







Мы должны увидеть стартовое окно системы управления:







Удаление нод




При необходимости удалить ноду из нашего кластера, вводим 2 команды:




kubectl drain k8s-worker2.dmosk.local --ignore-daemonsets




kubectl delete node k8s-worker2.dmosk.local




* в данном примере мы удаляем ноду k8s-worker2.dmosk.local.







Источник: https://www.dmosk.ru/instruktions.php?object=kubernetes-ubuntu



2021-06-16T00:10:08
Software