Как работает Statefulset и Headless Service - K8s

Прежде чем попытаться ответить на некоторые из ваших вопросов, я должен добавить отказ от ответственности: есть разные способы снять шкуру с кошки. И поскольку мы обсуждаем здесь StatefulSets, обратите внимание, что не все подходы лучше всего подходят для всех приложений с отслеживанием состояния. В случае, если вам нужен один модуль базы данных с одним PV, у вас может быть один подход, если вашему api-модулю нужен общий и отдельный PV, затем другой и т. Д.

Постоянное хранилище в приложениях - почему я должен рассмотреть возможность развертывания postgress (например) как StatefulSet? Я могу определить PV и PVC в Deployement для хранения данных в PV.

Это верно, если все ваши поды используют одно и то же требование постоянного тома для всех реплик (и провайдер позволяет это). Если вы попытаетесь увеличить количество реплик на основе развертывания, все ваши поды будут использовать один и тот же PVC. С другой стороны, StatefulSet, как определено в api документация volumeClaimTemplates позволяет каждой реплике иметь собственный сгенерированный PVC, защищая отдельно подготовленный PV для каждого модуля в наборе реплик.

Теперь почему я должен рассматривать Headless Service для приложений StatefulSet?

Из-за простоты обнаружения. Опять же, вам не нужно знать, сколько реплик у вас есть в Headless Service, проверяя DNS службы, вы получите ВСЕ реплики (предостережение - которые работают в этот момент). Вы можете сделать это вручную, но в этом случае вы полагаетесь на другой механизм подсчета / хранения вкладок на репликах (например, реплики самостоятельно регистрируются в мастере). Вот хороший пример обнаружения модулей с помощью nslookup, который может пролить свет на то, почему headless может быть хорошей идеей.

Почему эти (или некоторые другие) важны для развертывания как StatefulSet

Насколько я понимаю, перечисленные вами операторы развертываются с помощью самого развертывания. Однако они обрабатывают StatefulSets, поэтому давайте рассмотрим, например, ElasticSearch. Если бы он не был развернут как StatefulSet, вы бы получили два модуля, нацеленных на один и тот же PV (если провайдер позволяет это), и это сильно испортило бы ситуацию. С помощью StatefulSet каждый модуль получает свое собственное утверждение постоянного тома (из шаблона) и, следовательно, отделяет постоянный том от других модулей ElasticSearch в том же StatefulSet. Это лишь верхушка айсберга, поскольку ElasticSearch более сложен в настройке / использовании, и операторы помогают с этим.

Почему / когда мне следует заботиться о StatefulSet и Headless Serivice?

• Набор с отслеживанием состояния, который следует использовать в любом случае, когда реплицированные модули должны иметь отдельный PV друг от друга (созданный из шаблона PVC и автоматически подготовленный).

• Безголовый сервис, который вы должны использовать в любом случае, когда вы хотите автоматически обнаруживать все модули в рамках сервиса, в отличие от обычного сервиса, где вместо этого вы получаете ClusterIP. В качестве иллюстрации из вышеупомянутого примера приведена разница между записями DNS для службы (с ClusterIP ) и Headless Service (без ClusterIP):

  • Стандартный сервис - вы получите значение clusterIP:

    kubectl exec zookeeper-0 -- nslookup zookeeper
    Server:        10.0.0.10
    Address:    10.0.0.10#53
    
    Name:    zookeeper.default.svc.cluster.local
    Address: 10.0.0.213
    

  • Безголовый сервис - вы получите IP каждого модуля:

    kubectl exec zookeeper-0 -- nslookup zookeeper
    Server:        10.0.0.10
    Address:    10.0.0.10#53
    
    Name:    zookeeper.default.svc.cluster.local
    Address: 172.17.0.6
    Name:    zookeeper.default.svc.cluster.local
    Address: 172.17.0.7
    Name:    zookeeper.default.svc.cluster.local
    Address: 172.17.0.8