Pull to refresh
0
0
Send message

лПодход

опечатка.

при использовании kube-virt как-то проводили тестирование на сети, не упираетесь в пропускную способность свича гипервизора ?

да, а rbac легко можно описывать в репе. в helm chart есть для этого параметр

argo-cd:
  configs:
    rbac:
      policy.csv:

соотвественно сразу видно история изменений рбака.

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

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

можно это расшифровать, просто не совсем понятно, какие варианты использования имеются ввиду. Можно через kubectl увидеть те же данные, что и в гуй. можно через argocd cli провалидировать права на ресурс, все так же, как нативный рбак

кто-то решил хабр использовать как свой сервер заметок )

Так это, а где соурс код для СДЕКа?)))

а почему нет сравнения с rust, но при этом есть сравнение с c++?

Так появился сайт "ChatGPT Me" (ссылки на Хабре нельзя, но название легко гуглится).

Загуглил, открыл...Я не дизайнер, но у меня от такого чет кровь полилась из глаз)

добавьте ваш манифест с прометеем в статью тогда уж )

это хорошо, только прометея нет в чарте с графаной, потому с 0 этот мега чарт не сможет развернуться

helm repo add grafana https://grafana.github.io/helm-charts 
helm repo update grafana
helm search repo grafana/prometheus
> No results found

Не используйте ключи с неограниченным TTL, желательно ограничить размер TTL минимально необходимым сроком жизни ключа;
Используйте политику вытеснения чтобы не засорять Redis и подбирайте параметр maxmemory-policy в зависимости от структуры базы и частоты обращения к ключам;

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

Старайтесь снимать RDB дампы с боевой базы как можно реже, если объем
базы более нескольких гигабайт. Для создания RDB используется операция
fork в основном потоке, что может вызвать заметную задержку в работе
инстанса Redis. Лучшее решение —  поднятие мастер - слейв репликации и
снятие бэкапа со слейва.

но если очень хочется и нет слейва, то только через команду `BGSAVE` , чтобы не блокировать работу редиса в момент снятия дампа. Так же сам редис просит включить механизм copy-on-write, для снижения потребления памяти.

RedisInsight - не умирает на больших размерах БД(от 50Гб) и ключах( от 100 млн)?

А так, интересная статья, добавлю в закладки, чтобы кидать тем, кто хочет познать дивный мир редиски

любой курс линукс администратор. В каждом есть описание работы с файловой системой

https://habr.com/ru/articles/471038/
на мой взгляд лучшее описание, что я встречал

там выше было предложено отключить BGREWRITEAOF и BGSAVE ,SAVE поэтому про персистентность можно забыть)
В статье так же не сказано, что при перезапуске мы теряем все данные, что будет неприятным сюрпризом для новичков, что по этой статье запустят редиску в прод ( и такое бывает)

Если указать версию чарта через вайлдкарт типа 1.0.*

То арго сд проверит чарт на наличие новой минорной версии и сделает приложение OutOfSync если такая имеется

А чем вы в кубере раскатываете кейдб? где-то можно посмотреть манифест из Истории2?

мы используем в проде уже год, с версии 0,5.*, ни одного ложного срабатывания.

про шелл-оператора не понял.

А что делать, если мы не хотим использовать секреты в качестве объектов K8s

и ниже

как только в кластере появляется секрет с аннотацией lockbox=yes оператор создает новый секрет или заменяет его, а после удаляет ненужные секреты

то есть секрет все равно надо создавать, но с определенной аннотацией. Тогда в чем смысл?

Далее

  if ! kubectl get -f - <<< "$object" >/dev/null 2>/dev/null; then
    kubectl create -f - <<< "$object" >/dev/null
  else
    kubectl replace --force -f - <<< "$object" >/dev/null
  fi

почему б не заменить на kubectl apply ... ?

сам недавно развлекался с мультимастером, итог примерно тот же, если инстансов 2, то мультимастер худо бедно работает, при увеличении инстансов начинаются чудеса. в итоге так и остался на схеме keydb + sentinel

Кстати, не увидел описание фичи мультимастера:
если одна из реплик отвалилась и подключилась, то она запрашивает у остальных набор ключей, что вроде бы логично, но самое интересное, что потом старые реплики запрашивают у "поднявшейся" реплики ее набор ключей и синхронизируют со своими, и в этот момент становятся недоступны для клиентов.( с ошибкой Database loading)

есть три узла Redis, Standalone и две реплики

это как? мастер и 2 слейва? а если мастер упадет?

hugepages включены?
tcp стек тюнили?

Information

Rating
Does not participate
Registered
Activity