Pull to refresh

Comments 13

А зачем создавали PV и PVC?
Если локальная папка, то можно и сразу указать в описании контейнера
С папкой в описании контейнера не будет персистентности. Можно сделать через VolumeClaimTemplate в описании StatefulSet, но путь с отдельным объявлением PVC показался немного логичнее. А PV в любом случае необходимо создавать отдельно.
Практика показала, что эти readiness/liveness Probe очень плохие, так как всегда возвращают exit code = 0 и может таймаутить без причины.
Пока пришли к таким пробам:
        livenessProbe:
          httpGet:
            path: /api/whoami
            port: 15672
            httpHeaders:
              - name: Authorization
                value: {{ printf "Basic %s" ( printf "%s:%s" $rmq_user $rmq_pass | b64enc) | quote }}
          initialDelaySeconds: 120
          timeoutSeconds: 5
          failureThreshold: 6
        readinessProbe:
          httpGet:
            path: /api/whoami
            port: 15672
            httpHeaders:
              - name: Authorization
                value: {{ printf "Basic %s" ( printf "%s:%s" $rmq_user $rmq_pass | b64enc) | quote }}
          initialDelaySeconds: 10
          timeoutSeconds: 3
          periodSeconds: 5


Конечно, стоит не забывать и про rabbitmq exporter.
Спасибо, изучим. Пока с дефолтными Probes проблем не было, но будем обязательно иметь ваш опыт в виду.
ReadWriteMany бессмысленен, если используете hostPath. А так спасибо, не знал что кролик уже умеет в кубер из коробки.
Да, конечно, для hostPath неактуально, просочилось в пример из боевой конфигурации. Здесь — физического смысла не несёт, вреда, впрочем, тоже :)
Сразу уточним, что мы устанавливали RabbitMQ в K8s как StatefulSet. На каждой ноде кластера K8s будет всегда функционировать один экземпляр RabbitMQ


По какой причине было решено использовать StatefulSet с affinity для гарантирования того, что на каждом узле будет один под. Почему не использовали для этого DaemonSet, ведь этот примитив изначально был создан для обеспечения наличия на каждой доступной ноде одного пода приложения?
А StatefulSet изначально был создан для Stateful-приложений :)
Основные причины: персистентные ID контейнеров и упорядоченный запуск.

Нод в кластере может быть и более 50, такое количество подов rabbitmq никому не нужен, а с daemonset придется городить лейблы, селекторы. Поэтому statefulset хорошо подходит под данный кейс.

Да, этот чарт в принципе качественный и хорош для случаев «нет времени объяснять, нужен кролик здесь и сейчас». Когда мы используем инструмент, то хотим понять, как он работает. Решения вроде «включи рубильник и иди домой» нам не подходят, потому что если что-то пойдёт не так, мы хотим понять, в чём проблема, а для этого нужно понимание, как это работает.
Как коррелирует «мы хотим разобраться как это работает прежде чем использовать» и «мы изобрели свой велосипед»? В чем проблема посмотреть исходный код чарта/Dockerfile и понять как оно работает? Велосипед нужно еще и поддерживать, в отличии от helm charta
Полезная статья, но на текущий момент по крайней мере один фрагмент устарел.
В rabbitmq_statefulset.yaml следует заменить фрагмент с annotations: scheduler.alpha.kubernetes.io/affinity на:
     affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: app
                    operator: In
                    values:
                      - rabbitmq
              topologyKey: kubernetes.io/hostname

Подробнее можно прочитать тут.
Sign up to leave a comment.