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

Вот некоторые меры безопасности, которые мы можем принять:

✍🏻 Ограничить доступ к ETCD
✍🏻 Внедрить сегментацию сети
✍🏻 Определить квоту источника
✍🏻 Обеспечьте ограниченный доступ к узлам Kubernetes

Что будет если на сервере LA = 100?

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

Каким образом мы можем улучшить стабильность работы приложения в k8s?

Прежде всего необходимо описать probe для контейнеров в PODе, а также указать ресурсы запросов / лимиты. Затем целесообразно описать антиаффинити для PODов наших приложений, чтобы упростить обработку сбоев на конкретных узлах.

Если в нашем кластере работают как продуктовые, так и тестовые среды, хорошей практикой будет указать node selector и taints/tolerations, чтобы запускать продуктовые приложения на отдельных узлах.

Если нет возможности выделить узлы под продакшн или мы можем выделить особо важные (ядреные) сервисы в рамках продакшн, рекомендуется установить priority classes для них. Также стоит описать бюджет нарушения работы POD для особо важных приложений. В случае использования многопользовательской модели (multitenant) в пространствах имен пользователей следует указывать resourceQuotas и limitRanges.

Можем ли мы опубликовать приложение, работающее по бинарному протоколу, например postgresql, через ingress?

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

Если нам всё равно нужно описывать Kubernetes service для публикации ingress, то зачем нам ingress?

Преимущество использования ingress-контроллера заключается в том, что после его настройки мы можем направлять трафик ко всем нашим приложениям внутри кластера k8s, которые работают по протоколу HTTP и используют маршрутизацию на основе URL/locations, HTTP headers и cookie. Кроме того, при необходимости мы можем использовать несколько ingress-контроллеров в кластере, разделяя их по ingress class.

Какие существуют хорошие практики для создания проб?

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

Пробы должны быть легкими и не нагружать инфраструктуру приложения, а также не запускаться слишком часто. Им следует избегать проверки функционала, зависящего от внешних сервисов, чтобы избежать каскадных сбоев. Особенно внимательно нужно относиться к liveness-пробам, которые могут вызвать дополнительные проблемы, особенно в периоды высокой нагрузки. Рекомендуется выделить отдельный пул воркеров для прохождения liveness-пробы. Для readiness-пробы лучше создавать сквозные проверки, например, проверять только location nginx, который проксирует php-fpm, одним запросом проверяя оба сервиса.

Допустим, у нас postgresql в кластере k8s, и разработчики просят к ней доступ. Каким образом мы можем решить этот вопрос?

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

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

Если разработчикам требуется прямой сетевой доступ к базе данных (например, для использования своего любимого инструмента для работы с БД), мы можем создать аккаунт для разработчиков в кластере и использовать kubectl proxy для публикации порта базы данных на локальной машине разработчика. Также можно установить сервер VPN в кластере.

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

Что такое priority classes?

Этот механизм в Kubernetes позволяет определить приоритет PODов для наших процессов. Например, если у нас есть продакшн и тестовые окружения в одном кластере Kubernetes, мы можем установить более высокий приоритет для PODов продакшн с помощью priority class. Таким образом, если возникнет нехватка ресурсов на узле, в первую очередь будут удалены PODы тестовых окружений.

Что такое POD eviction?

Этот механизм позволяет удалить ноду от избыточных PODов. Существуют evict'ы по ресурсам (когда нода не имеет достаточно памяти, дискового пространства или PID для процессов) и вызов API - когда мы запускаем kubectl drain node.

Каким образом мы можем вывести ноду из работы для обслуживания?

Мы можем остановить запуск PODов на узле с помощью команды kubectl cordon и высвободить узел от PODов при помощи команды kubectl drain.

Самые полезные каналы для программистов в одной подборке!

Сохраняйте себе, чтобы не потерять 💾

🔥Для всех

Библиотека программиста — новости, статьи, досуг, фундаментальные темы
Книги для программистов
IT-мемы
Proglib Academy — тут мы рассказываем про обучение и курсы

🤖Про нейросети
Библиотека робототехники и беспилотников | Роботы, ИИ, интернет вещей
Библиотека нейрозвука | Транскрибация, синтез речи, ИИ-музыка
Библиотека нейротекста | ChatGPT, Gemini, Bing
Библиотека нейровидео | Sora AI, Runway ML, дипфейки
Библиотека нейрокартинок | Midjourney, DALL-E, Stable Diffusion

#️⃣C#

Книги для шарпистов | C#, .NET, F#
Библиотека шарписта — полезные статьи, новости и обучающие материалы по C#
Библиотека задач по C# — код, квизы и тесты
Библиотека собеса по C# — тренируемся отвечать на каверзные вопросы во время интервью и технического собеседования
Вакансии по C#, .NET, Unity Вакансии по PHP, Symfony, Laravel

☁️DevOps

Библиотека devops’а — полезные статьи, новости и обучающие материалы по DevOps
Вакансии по DevOps & SRE
Библиотека задач по DevOps — код, квизы и тесты
Библиотека собеса по DevOps — тренируемся отвечать на каверзные вопросы во время интервью и технического собеседования

🐘PHP

Библиотека пхпшника — полезные статьи, новости и обучающие материалы по PHP
Вакансии по PHP, Symfony, Laravel
Библиотека PHP для собеса — тренируемся отвечать на каверзные вопросы во время интервью и технического собеседования
Библиотека задач по PHP — код, квизы и тесты

🐍Python

Библиотека питониста — полезные статьи, новости и обучающие материалы по Python
Вакансии по питону, Django, Flask
Библиотека Python для собеса — тренируемся отвечать на каверзные вопросы во время интервью и технического собеседования
Библиотека задач по Python — код, квизы и тесты

☕Java

Книги для джавистов | Java
Библиотека джависта — полезные статьи по Java, новости и обучающие материалы
Библиотека Java для собеса — тренируемся отвечать на каверзные вопросы во время интервью и технического собеседования
Библиотека задач по Java — код, квизы и тесты
Вакансии для java-разработчиков

👾Data Science

Книги для дата сайентистов | Data Science
Библиотека Data Science — полезные статьи, новости и обучающие материалы по Data Science
Библиотека Data Science для собеса — тренируемся отвечать на каверзные вопросы во время интервью и технического собеседования
Библиотека задач по Data Science — код, квизы и тесты
Вакансии по Data Science, анализу данных, аналитике, искусственному интеллекту

🦫Go

Книги для Go разработчиков
Библиотека Go разработчика — полезные статьи, новости и обучающие материалы по Go
Библиотека Go для собеса — тренируемся отвечать на каверзные вопросы во время интервью и технического собеседования
Библиотека задач по Go — код, квизы и тесты
Вакансии по Go

🧠C++

Книги для C/C++ разработчиков
Библиотека C/C++ разработчика — полезные статьи, новости и обучающие материалы по C++
Библиотека C++ для собеса — тренируемся отвечать на каверзные вопросы во время интервью и технического собеседования
Библиотека задач по C++ — код, квизы и тесты
Вакансии по C++

💻Другие каналы

Библиотека фронтендера
Библиотека мобильного разработчика
Библиотека хакера
Библиотека тестировщика
Вакансии по фронтенду, джаваскрипт, React, Angular, Vue
Вакансии для мобильных разработчиков
Вакансии по QA тестированию
InfoSec Jobs — вакансии по информационной безопасности

📁Чтобы добавить папку с нашими каналами, нажмите 👉сюда👈

Также у нас есть боты:
Бот с IT-вакансиями
Бот с мероприятиями в сфере IT

Мы в других соцсетях:
🔸VK
🔸YouTube
🔸Дзен
🔸Facebook *
🔸Instagram *

* Организация Meta запрещена на территории РФ

Каким образом мы можем управлять размещением PODов на конкретных нодах кластера k8s?

Есть несколько вариантов.

NodeSelector/node affinity — это механизм, который позволяет запускать PODы на узлах с определенным набором меток. Это может быть полезно, если, например, PODы требуют специфического оборудования, например, у нас есть группа узлов с GPU для задач машинного обучения.

Taints/tolerations — это механизм, который позволяет запрещать запуск PODов на узле (taint — описывается на узле), если они не имеют соответствующего разрешения (toleration — описывается на POD'е). Это может быть полезно, если у нас в кластере есть несколько окружений — мы можем выделить узлы для production и с помощью taint запретить запуск PODов тестовых окружений на них.

Pod affinity/antiAffinity — это механизм, который позволяет группировать PODы различных приложений на общих узлах (если им важен быстрый сетевой доступ) или, наоборот, заставлять их запускаться на разных узлах (например, для распределения PODов одного приложения по узлам кластера для повышения отказоустойчивости в случае сбоя на узле).

Каким образом мы можем управлять вычислительными ресурсами в k8s?

Для эффективного управления ресурсами в кластере k8s используются resources requests / limits. Они могут быть настроены для CPU, памяти и, в последних версиях k8s, для GPU.

Requests используются для определения типичного потребления ресурсов нашим приложением. На основе этих данных Kubernetes scheduler выбирает ноды для запуска PODов (сумма всех request'ов контейнеров во всех PODах не должна превышать доступные ресурсы на ноде).

Limits служат как механизм предотвращения, ограничивая потребление ресурсов контейнером в PODе. При превышении лимита процессорного времени применяется thermal throttling, а при превышении лимита памяти — механизм OOM.

Модель, при которой requests меньше limits, называется burstable QoS, а когда requests равны limits — guaranteed QoS.

Кроме того, можно установить квоты ресурсов на namespace (CPU, память, количество запущенных PODов, размер диска persistent volume) и указать требования к resources requests на PODах в namespace с помощью limit ranges.

Для управления ресурсами приложений также можно использовать автоскейлеры. В k8s доступны HPA (horizontal pod autoscaler), который регулирует количество PODов в зависимости от потребления CPU и/или памяти, и VPA (vertical pod autoscaler), который управляет resources requests / limits.

Существуют также реализации автоскейлеров, которые могут использовать внешние метрики (например, длину очереди), такие как carpenter или KEDA. В облачном окружении можно использовать cluster autoscaler для добавления или удаления нод в зависимости от общей загрузки кластера.

Что такое Kubernetes probes?

Эти проверки выполняются в течение жизненного цикла PODа и описываются для каждого контейнера в PODе. Существует три типа проверок.

Startup probe запускается сразу после запуска PODа и используется для приложений с длительной процедурой инициализации. Другие проверки не запускаются, пока эта не завершится.

Readiness probe проверяет готовность PODа обрабатывать трафик (POD не добавляется в маршрутизацию трафика в сервисе, пока эта проверка не будет пройдена).

Liveness probe проверяет, работает ли приложение (в случае неудачной проверки процесс в контейнере PODа перезапускается). Readiness и Liveness — независимые и запускаются после прохождения Startup probe.

Существуют exec-, http-, tcp- и grpc-проверки. Проверки выполняются сервисом kubelet на узле, на котором запущен целевой POD.

Для чего при старте PODа создаётся контейнер с процессом pause?

Для PODа необходимо создать как минимум два контейнера. Один из них используется с pause для обеспечения общей сети (для этого создается network namespace в linux), что позволяет размещать все контейнеры PODа на одной ноде.

Что такое POD?

Группа контейнеров, соединенных общей сетью (общий localhost, общий внешний IP), может быть необходима для запуска взаимозависимых сервисов, которые используют общие файловые ресурсы или взаимодействуют друг с другом по сети (например, nginx + php-fpm).

Каким образом мы можем запустить в Kubernetes приложение (варианты: рабочую нагрузку, workload)?

Запускать PODы поодиночке можно, но обычно для этого используются более функциональные сущности в Kubernetes, такие как:

— Deployment, который используется для развертывания необходимого количества PODов на основе общего шаблона.
— StatefulSet, похожий на Deployment, но оптимизированный для работы с stateful-приложениями.
— DaemonSet, позволяющий развернуть один экземпляр приложения на каждом доступном узле и обычно используется для обслуживания узлов.
— Job, для запуска конечного процесса в контейнере и ожидания его успешного завершения с заданием политик запуска, таких как длительность и количество рестартов в случае сбоя.
— CronJob, аналогичный Job, но с возможностью запуска по расписанию и ведением логов успешных запусков.

ReplicationController считается устаревшим и практически не используется, на его место пришел Deployment.

Каким образом мы можем предоставить приложение, которое работает в нашем кластере, k8s нашим пользователям?

Если наше приложение работает через HTTP, мы можем использовать ingress-контроллер, который является реверс-прокси, интегрированным с Kubernetes API. Этот контроллер позволяет на основе custom resources маршрутизировать трафик по HTTP.

— Для ряда задач мы можем использовать Kubernetes service. Мы можем использовать тип externalIp, чтобы опубликовать порт сервиса на определенных IP-адресах наших нод. Тип nodePort позволяет опубликовать порт сервиса на всех нодах на произвольных портах в определенном диапазоне. Также есть опция trafficPriority: local, которая позволяет предпочитать PODы приложения, находящегося на локальной ноде при маршрутизации трафика.

— Для работы в облаке мы можем использовать тип loadBalancer. Это создает сервис, аналогичный nodePort, но с добавлением load balancer, который маршрутизирует трафик на ноды кластера через порты, выбранные для nodePort.

— Мы также можем использовать kubectl proxy для проброса порта сервиса локально на нашу машину, что может быть полезно для разработки.

— Используя nodeNetwork: true (нужно проверить, когда будет доступ в интернет), мы можем разрешить приложению, работающему в контейнере, использовать сеть ноды и занимать сетевые порты непосредственно на интерфейсах ноды.

Каким образом организована сеть в k8s?

В Kubernetes существуют три типа сетей:

1. Сеть узлов (node network) — это сеть, в которую объединены узлы кластера. В зависимости от используемого CNI-плагина, узлы могут работать либо в одной подсети, либо в нескольких.

2. Сеть POD-ов (pod network) — это сеть, в которой получают IP-адреса запускаемые POD-ы.

3. Сеть сервисов (service network) — это сеть, в которой получают адреса сервисы Kubernetes. Сети POD-ов и сервисов организуются с помощью CNI-плагинов.

Что такое CNI-плагин и для чего он нужен?

Аббревиатура CNI расшифровывается как Container Network Interface. Это представляет собой уровень абстракции над реализацией сети, позволяя работать с верхнеуровневыми абстракциями, такими как IP-адрес PODа и Endpoint. CNI-плагин отвечает за то, как это будет реализовано на физическом уровне. Существует множество CNI-плагинов (например, Flannel, Calico, Cilium), которые предлагают различный функционал и сетевую производительность. Они могут быть простыми, использующими L3-маршрутизацию, iptables и IPVS, а также достаточно сложными, обеспечивающими шифрование внутреннего трафика, поддержку VLAN, маршрутизацию на основе IBGP, поддержку EGRESS и другие функции.

Что такое CRI?

CRI означает интерфейс выполнения контейнера. Это спецификация, описывающая определенный уровень абстракции, позволяющая унифицированно использовать различные версии программного обеспечения для работы с контейнерами, такими как Containerd или CRI-O.