Обзор операторов PostgreSQL для Kubernetes. Часть 2: дополнения и итоговое сравнение

[dnbstd]

n_bogdanov Коля Привет. Хотелось бы немного дополнить твою статью личным опытом использования KubeDB. Про кастомизацию подов в KubeDB — отчасти можно.Указав в crd к примеру:

Код

podTemplate:
    spec: 
      imagePullSecrets:
      - name: registry-secret
      resources:
        requests:
          memory: "512Mi"
          cpu: "500m"
        limits:
          memory: "4096Mi"
          cpu: "2"

По поводу Лицензии и бекапа через Appscode Stash — на эту бизнес модель они перешли в новой версии, что на мое мнение большой шаг назад для них. В версии 0.13rc-1 по прежнему можно бэкапить без stash и там не используется лицензия. Так же мне понравилось что там без танцев с бубном можно бэкапить в minio, в zolando у меня к сожалению не получилось это завести, не все живут в облаках. Так же хотелось обратить внимание что KubeDB использует отключаемую функцию Google Analytics.

P.S: Спасибо за обзор stackgres, в связи с переходом KubeDB на новую модель лицензирования и бекапов, посмотрю в его сторону. В связи с небольшим количеством времени на доскональное разбирательство и отвратительную документацию Zolando нам не зашел.

[n_bogdanov]

Спасибо

[n_bogdanov]

Стоит заметить, что под кастопизацией пода в первую очередь подразумевается подключение дополнительных контейнеров.

[dnbstd]

Очень бы хотелось увидеть аналогичную статью по Mysql операторам, на основе вашего опыта.

[ahachete]

Thank you for including StackGres in your review, and my apologies for leaving a comment in English.

FYI, some of the missing items that you mentioned are being worked on, and can be tracked on our public issue tracker. You are more than welcome to leave your comments there and in our Community Slack (https://slack.stackgres.io):

• Node Selectors are implemented in the evaluated version (so this is not 100% accurate in the comparison table).
• Node Tolerations are being implemented for 1.0: https://gitlab.com/ongresinc/stackgres/-/issues/538
• Node Affinity is also coming in 1.0: https://gitlab.com/ongresinc/stackgres/-/issues/598
• Custom sidecars is also planned, possibly 1.1: https://gitlab.com/ongresinc/stackgres/-/issues/599 Feedback is specially appreciated here. Unless I got lost in translation, I didn't quite get why you need your SFTP as a sidecar. You can easily import CSV files via psql connection, which can obviously operate over network connections. Putting the DBA hat on, sidecars may be a threat to database stability, we want to be wary of what sidecars we run alongside with the database. We should cherry-pick them carefully, and I'd only consider those that really need to have direct access to either the database files ($PGDATA) or logs or similar use cases, but I'd not consider it for data-related operations which you can comfortably run over the network. What's your use case here if you can elaborate?

As for the items you consider missing, and which are not currently planned to be developed, I have some comments too:

• kubectl plugin: I don't see it as an advantage to build plugins. I'd love to understand why you think it is. StackGres is designed to be fully operated and managed via the CRDs, which have well-defined specs and convey back well-defined information on the status fields. This is truly Kubernetes native, and allows any Kubernetes user well versed into Kubernetes administration to easily operate it. However, when you require users to download external cli tools (and plugins are in reality nothing much different from that) you force the user to acquire additional, and different knowledge (than the regular K8s administration knowledge). So it adds cognitive burden. It also limits the ability to perform GitOps approach, since now you require those cli tools and/or plugins everywhere, including the CI/CD pipeline. What's your take on this, why would you rather consider a plugin a good thing in this case?
• Custom postgres images. This is not as easy as it sounds like. There are some coupling among the sidecars and other elements of the infrastructure, that may break if the postgres container is replaced at will. Or worse, compatibility problems with tools compiled with different versions of dependencies (say glibc) may appear. Issues that may even lead to data corruption. One of StackGres goals is to make Postgres simple to operate for anyone, and these kind of problems require a high level of expertise to deal with --or to make sure you will not be bitten. What is your need, why would you want to bring your own Postgres container image?

Thank you if you can provide your thoughts, feel free to reach us out in Slack, we'd really appreciate the feedback. Спасибо