Pull to refresh
99
0
Андрей Сидоров @Wimbo

Engineer

Send message

Пока нет, но думаем об этом.

Или можете наложить патч для grafana с добавлением interval_rv
Конечно! Вот gist.

Там нужны минимальные правки для того чтобы оно стало рабочим (поменять datasource, исправить interval_rv на interval, возможно что-то еще)

Пока поделиться особо нечем. Прода с istio в данный момент нет.
Мы планируем катнуть возможность использования Istio в 70+ кластеров до конца месяца и где-то в апреле/мае у нас будет первый реальный продакшен опыт на реальных кейсах.
Мы обязательно поделимся полученным опытом, так как будет большое количество различных кейсов на различных нагрузках и конфигурациях.

Общие пулы могут быть под конкретные задачи и это нормально. Общий пул не значит, что он под абсолютно все задачи. Нам не имеет смысла гонять простые приложения, на GPU нодах — верно?
С одной стороны да, маленькие отдельные кластера под задачи — это удобно. с полной изоляцией, но с другой стороны приводит к лишней работе. Тут нужно иметь некий баланс адекватности и необходимости.
У нас есть и те и другие варианты в обслуживании.
Да, доступ есть во все части дашборды, но она запущена из под сервис аккаунта, которому разрешено только «смотреть», но не редактировать.
Нет. С помощью oauth2 proxy

И пары аннотаций:
ingress.kubernetes.io/auth-signin: https://$host/oauth2/sign_in
ingress.kubernetes.io/auth-url: http://dashboard-oauth2-proxy.kube-system.svc.cluster.local:4180/oauth2/auth


Если интересно, то можем рассказать в следующей статье более подробно о данном кейсе.
Чаще всего хватает доступов к Kubernetes Dashboard с авторизацией в gitlab.
Иногда даем доступ с помощью kubectl (конфиг подключения) с юзером, которому доступны только те действия, что определили с помощью RBAC.

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

Практика показала, что эти 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.
На самом деле ничего не мешает :) Как ничего не мешает, и обойтись без инит контейнеров.
Просто тут каждый контейнер выполняет свою отдельную функцию, мы можем смотреть логи отдельных контейнеров, выделять ресурсы на отдельные стадии (CPU, RAM).
Все очень просто
variables:
  DAPP_VERSION: "0.31"

.base_deploy: &base_deploy
  stage: deploy
  script:
    - source dapp_use ${DAPP_VERSION}
    - dapp --version; set -x; pwd
    - dapp kube deploy
      --tag-ci
      --namespace ${CI_ENVIRONMENT_SLUG}
      --set "global.env=${CI_ENVIRONMENT_SLUG}"
      --set "global.reload_db=${DB:-false}"
      ${CI_REGISTRY_IMAGE}

stages:
  - build
  - deploy

Build:
  stage: build
  script:
    - source dapp_use ${DAPP_VERSION}
    - dapp --version; set -x; pwd
    - dapp dimg bp ${CI_REGISTRY_IMAGE} --tag-ci --use-system-tar
  tags:
    - build
  except:
    - schedules

To test:
  <<: *base_deploy
  except:
    - schedules
  tags:
    - deploy
  when: manual

To test (Reload DB):
  <<: *base_deploy
  except:
    - schedules
  variables:
    DB_RELOAD: "true"
  tags:
    - deploy
  when: manual

Как таковых «минимальных» требований нет. Те лимиты, которые мы считаем минимальными (requests) описаны в value, но это не значит, что оно будет потреблять именно столько ресурсов, все зависит от количества логов.
Добрый день…
Спасибо большое за интерес к нашему проекту и мы очень рады, что есть люди, которые испытывают те же потребности, что и мы.
Это все баги, связанные с тем, что это PoC. Мы будем очень рады, если вы пришлете PR или создадите Issue по любым улучшениям или вопросам.
У нас в планах миграция бекенда на Go
В данный момент loghouse не обработает миллион строчек логов в секунду.
В таком случае мы получим дикую нагрузку на диск, так как лог пишется в логи, а после чего fluentd их пишет в clickhouse. Сколько эти логи занимают места — столько они и будут занимать.
Зависит от того, сколько эти логи занимают пространства.
Мы протестировали несколько вариантов, но они оказалось либо очень ресурсоемкими (как CPU, RAM так и дисковое пространство), либо крайне не удобными и не соответствовали нашим требованиям.
Elasticsearch оказался слишком «толстым».

Information

Rating
Does not participate
Location
Симферополь, Республика Крым, Россия
Date of birth
Registered
Activity