CODEWITHSUNDEEP
kubernetes.net-coreazure-service-fabric
Nathan A
Nathan A

Reputation: 11339

Migrate Service Fabric Reliable Collections to Kubernetes

We are in the process of migrating our Service Fabric services to Kubernetes. Most of them were "stateless" services and were easy to migrate. However, we have one "stateful" service that uses SF's Reliable Collections pretty heavily.

K8s has Statefulsets, but that's not really comparable to SF's reliable collections.

Is there a .NET library or other solution to implement something similar to SF's Reliable Collections in K8s?

Upvotes: 4

Views: 683

Answers (2)

Frank Q.
Frank Q.

Reputation: 6612

AFAIK this cannot be done by using a .Net library. K8 is all about orchestration. SF on the other hand is both an orchestrator + rich programming /application model + state management. If you want to do something like reliable collection in K8 then you have to either

A) built your own replication solution with leader election and all.

B) use private etcd/cockroachdb etc. store

This article is pretty good in terms of differences.

https://learn.microsoft.com/en-us/archive/blogs/azuredev/service-fabric-and-kubernetes-comparison-part-1-distributed-systems-architecture#split-brain-and-other-stateful-disasters

"Existing systems provide varying levels of support for microservices, the most prominent being Nirmata, Akka, Bluemix, Kubernetes, Mesos, and AWS Lambda [there’s a mixed bag!!]. SF is more powerful: it is the only data-ware orchestration system today for stateful microservices"

Upvotes: 5

mozello
mozello

Reputation: 1244

However, they don't solve the coordination problem (saving data on the primary instance will automatically replicate to the others for recovery when the primary instance dies). That's what SF reliable collections does out of the box.

StatefulSets are valuable for applications that require one or more of the following.

  • Stable (persistent), unique network identifiers.
  • Stable, persistent storage.
  • Ordered, graceful deployment and scaling.
  • Ordered, automated rolling updates.

If your application doesn't require any of these, you should deploy your application using a Deployment.

There is a good Kubernetes guide on how to Run a Replicated Stateful Application here.

This page shows how to run a replicated stateful application using a StatefulSet controller. This application is a replicated MySQL database. The example topology has a single primary server and multiple replicas, using asynchronous row-based replication.

The StatefulSet controller starts Pods one at a time, in order by their ordinal index. It waits until each Pod reports being Ready before starting the next one. And it is used to perform orderly startup of MySQL replication by running Init Containers.

Operators can help

While operators are not necessary, they can help run stateful apps on Kubernetes with features like application-level HA management, backups, and restore.

You can use existing Operators or develop your own. The operator package includes all the configurations needed to deploy and manage the application from a Kubernetes point of view – from a StatefulSet to be used to any required storage, rollout strategies, persistence and affinity configuration, and more. Kubernetes will then rely on the operator to validate instances of the application against the specification to ensure it runs in the same way across instances in all clusters it is deployed in.

Some DB operators:

You can find ready-made operators on OperatorHub.io to suit your use case.

Upvotes: 1

Related Questions