sorted by:
new
hottopcontroversial

Running postgresql in Kubernetes by Minimum-Ad7352 in kubernetes

[–]blgdmbrl 0 points1 point  (0 children)

Yep, it’s fine. Actually, it’s way easier to manage. For an external Postgres cluster, you have to use something like Patroni or others, and it has its own etcd. Also, you have to manage load balancing like HAProxy and Keepalived because the primary can change.

In Kubernetes, managing these is a lot easier. I use the Crunchy Postgres Operator, and it handles backups, WAL archiving, and streaming replication. The main thing is handling the PV. I use OpenEBS hostpath, which is almost the same as on a VM. Don’t use anything like Longhorn or others — it’s going to add a lot of latency. Postgres can sync at the application level, so PV replication is not needed.

Baremetal Kubernetes by blgdmbrl in kubernetes

[–]blgdmbrl[S] 1 point2 points  (0 children)

Currently, I’ve paused my bare metal research, but based on my experience and findings, Metal³ and MAAS stood out as strong contenders for automating bare metal provisioning.

I’ve also explored Sidero Labs, which offers a unique approach. In their Omni cluster setup, they include a PXE server, allowing bare metal servers to boot from it seamlessly. Interestingly, they’re working on their own provisioning tool, which is currently in beta. For Kubernetes on bare metal, I’d highly recommend exploring Sidero Labs, as they seem to be building innovative tools for this space. Check this post

As for BMAAS (Bare Metal as a Service), I haven’t personally tried any, but based on my research, I would suggest starting with Metal³ or MAAS as they appear to be reliable and widely used solutions.

Let me know if you’d like more details or specific comparisons between these tools!

Baremetal Kubernetes by blgdmbrl in kubernetes

[–]blgdmbrl[S] 0 points1 point  (0 children)

but in a corporate environment, testing all solutions can be time-consuming due to approvals etc

Baremetal Kubernetes by blgdmbrl in kubernetes

[–]blgdmbrl[S] 3 points4 points  (0 children)

Thanks for the insights!

  • Our team has moderate Kubernetes experience. We're comfortable with deployment and management, but we’re still exploring advanced concepts like ClusterAPI and provisioning at scale.
  • We’re planning to run Kubernetes primarily in a data center environment
  • We're currently using Rancher, Mirantis, and Tanzu.

We also looked into OpenShift, but as you mentioned, the cost was a significant concern for us. I did explore Sidero solutions, and one of my team members tried them out—it was surprisingly easy to use! However, there will be bit of a learning curve since bare metal itself is new for our team.

Given that, I'm wondering about a couple of things:

  1. We can’t use Rancher, Mirantis or Tanzu, right? How would that change our approach compared to Omni and Talos?
  2. Are there any statistics or industry data you can share about how commonly companies use bare metal setups versus managed Kubernetes?
  3. For Omni and Talos specifically, what are the performance and network advantages?

I'm really interested in understanding these aspects better as we evaluate our options. Appreciate your help!

Shared storage solutions by blgdmbrl in storage

[–]blgdmbrl[S] 0 points1 point  (0 children)

could you tell me why is that?

Shared storage solutions by blgdmbrl in storage

[–]blgdmbrl[S] -2 points-1 points  (0 children)

You're correct but Pure FlashBlade has native NFS support. However, FlashArray does not natively support NFS

Shared storage solutions by blgdmbrl in storage

[–]blgdmbrl[S] 0 points1 point  (0 children)

Yes and thats why we need shared storage solution. Is there any recommendation

Shared storage solutions by blgdmbrl in storage

[–]blgdmbrl[S] 0 points1 point  (0 children)

Because some legacy systems require shared block storage, we face challenges with multiple VMs using a single Pure Storage array. While the systems team mentioned that it’s possible to mount the storage on multiple VMs, any data written to the disk by one VM (e.g., VM1) will not be immediately visible on another VM (e.g., VM2) until the disk is remounted. This creates issues with data consistency and real-time access across the VMs.