The objective is to create a highly available redis cluster using kubernetes for a nodeJS client. I have already created the architecture as below:
Created a Kubernetes cluster of Kmaster with 3 nodes (slaves).
Then I created statefulsets and persistent volumes (6 - one for each POD).
Then created Redis pods 2 on each node (3 Master, 3 replicas of respective master).
I need to understand the role of Redis Sentinel hereafter, how does it manage the monitoring, scaling, HA for the redis-cluster PODs across the nodes. I understand Sentinel should be on each node and doing its job but what should be the right architecture here?
P.S. I have created a local setup for now, but ultimately this goes on Azure so any suggestions w.r.to az is also welcome.
Thanks!
From an Azure perspective, you have two options and if you are very specific to option two but are looking for the Sentinel architecture piece, there is business continuity and high availability options in both IaaS (Linux VM scale sets) and PaaS services that go beyond the Sentinel component.
Azure Cache for Redis (PaaS) where you choose & deploy your desired service tier (Premium Tier required for HA) and connect your client applications. Please see: Azure Cache for Redis FAQ and Caching Best Practice.
The second option is to deploy a solution (as you have detailed) as an IaaS solution built from Azure VMs. There are a number of Redis Linux VM images to choose from the Azure Marketplace or there is the option to create a Linux VM OS image from your on-premise solution and migrate that to Azure. The Sentinel component is enabled on each server (master, slavea, and slaveb, ...). There are networking and other considerations too. For building a system from scratch, please see: How to Setup Redis Replication (with Cluster-Mode Disabled) in CentOS 8 – Part 1 and How to Setup Redis For High Availability with Sentinel in CentOS 8 – Part 2
Related
I am new to Azure and was trying to understand if I could use Azure Redis in my application.
Assuming, the application to run at a decent scale(currently don't have the exact numbers), my main point to ask this question is, as per the pricing tier of Azure, it says Premium supports upto 40k client connections. Now, is this connection count per node of the cluster or for the total cluster itself?
It is per node, by default you get no cluster and to have more nodes you will enable clustering when you are creating your premium Azure Redis cache instance. Please take a look here for a detailed look per shard or per node in a cluster in the premium tier. If you are expecting load but you do not have one right now then I would recommend to start with Standard tier now and when the need arises upgrade to Premium but remember you cannot scale back to Standard then and you get clustering only if you create the Azure Redis cache resource with Premium and enable clustering while creating it. But you get HA built with both Standard and Premium tiers but Redis Enterprise features are only available with the Premium tier.
From whatever i read, i could not find a way to connect to master node in Azure kubernetes Service. I have a requirement to read some parameters like 'enable-admission-plugins' which is possible from master node. Is there any third party api available to get this info.
More specific i need to read the files 'kube-apiserver.yaml', 'kube-controller-manager.yaml'
No, this is not possible. Masters are managed by Microsoft and you dont have access to them. All the configurations are to be done through the AKS api (mostly when you create it).
Azure Kubernetes Service (AKS) makes it simple to deploy a managed
Kubernetes cluster in Azure. AKS reduces the complexity and
operational overhead of managing Kubernetes by offloading much of that
responsibility to Azure. As a hosted Kubernetes service, Azure handles
critical tasks like health monitoring and maintenance for you. The
Kubernetes masters are managed by Azure. You only manage and maintain
the agent nodes.
problem statement.
as per my understanding, we can run an elastic search, kibana and logstash etc as a pod in kubernates cluster for log management. but it is also memory heavy intensive application. AWS provides various managed services like Cloudwatch, cloud trail and ELK stack for log management.
do we have a similar substitute in Azure as well i.e. some managed service?
you can use AKS with Azure Monitor (reading). I'm not sure you can apply this to not AKS cluster (at least not in a straight forward fashion).
Onboarding (for AKS clusters) is really simple and can be done using various methods (portal included).
You can read more on the docs I've linked (for example, about capabilities).
Azure Monitor for Containers is available now and once integrated some cluster metrics as well as the logs will be automatically collected and made available through log analytics.
I see advantages of Kubernetes which include Rolling Deployments, Automatic Health check monitoring, and swinging a new server to action when an existing one fails. I also do understand that Kubernetes is not just for Docker.
So, that brings a couple of questions!
When Azure, and Service Fabric could provide all that I said (and beyond), why would I need Kubernetes?
Would it make sense for one to use Kubernetes along with Service Fabric for large scale deployments on Azure?
Let's look first at the similarities between Kubernetes and Service Fabric.
They are both cloud-agnostic clustering, orchestration, and scheduling software.
They can both be deployed manually, by you, to any set of VMs, anywhere.
There are "managed" offerings for both, meaning a cloud provider like Azure or Google Cloud will host a cluster for you, but generally you still own the VMs.
They both deploy and manage containers.
They both have rich management operations, such as rolling upgrades, health checks, and self-healing capabilities.
That's a fairly high-level view but should give you an idea of what and where you can run with each.
Now let's look where they're different. There are a ton of small differences, but I want to focus on two of the really big conceptual differences:
Application model:
Service Fabric allows you to orchestrate any arbitrary container or EXE (whether that's a small node.js app or a giant legacy application), and in that sense it is similar to Kubernetes. But overall it is more focused on application development specifically, with programming models that are integrated with the platform. In this respect, it is more closely comparable to Cloud Foundry than Kubernetes.
Kubernetes is focused more on orchestrating infrastructure for an application. It doesn't really focus on how you write your application. That's up to you to figure out; Kubernetes just wants a container to run, doesn't matter what's in it.
State management
Kubernetes allows you to deploy stateful software to it, by providing persistent disk storage volumes to containers and assigning unique identifiers to pods. This lets you deploy things like ZooKeeper or MySQL.
Service Fabric is stateful software. Service Fabric is designed as a stateful, data-aware platform. It provides HA state and scale-out primitives. So while Kubernetes allows you to deploy stateful things, Service Fabric allows you to build stateful things. This is one of the key differences that's often overlooked. For example:
On Kubernetes, you can deploy ZooKeeper.
On Service Fabric, you can actually build ZooKeeper yourself using Service Fabric's replication and leader election primitives.
Kubernetes uses etcd for distributed, reliable storage about the state of the cluster.
Service Fabric doesn't need etcd, because Service Fabric itself is a distributed, reliable storage platform. The system services in Service Fabric make use of this to reliably store the state of the cluster. This makes Service Fabric entirely self-contained.
The fact that Service Fabric is a stateful platform is key to understanding it and how it differs from other major orchestrators. Everything it does - scheduling, health checking, rolling upgrades, application versioning, failover, self-healing, etc - are all designed around the fact that it is managing replicated and distributed data that needs to be consistent and highly available at all times.
Please find below a good comparaison article about the difference between ACS and Azure Service Fabric:
https://blogs.msdn.microsoft.com/maheshkshirsagar/2016/11/21/choosing-between-azure-container-service-azure-service-fabric-and-azure-functions/
Could you please clarify what you refer to when you talk mentionne "AWS" ?
From a "developer level" solution could be statefull in both cases but it have a major difference from an Infrastructure point of view:
Docker + Kuberest is a "IaaS" oriented solution
Azure Service Fabric (if you are using Azure service) is a PaaS solution.
IaaS is, in general, more costly and have a more significant maintenance cost.
From a support point of view:
Azure Service Fabric is supported by Microsoft
Docker and Kubernetest are more open source oriented
Hope this help.
Best regards
I recently got a trial version of Windows Azure and wanted to know if there is any way I can deploy an application using Cassandra.
I can't speak specifically to Cassandra working or not in Azure unfortuantly. That's likely a question for that product's development team.
But the challenge you'll face with this, mySQL, or any other role hosted database is persistence. Azure Roles are in and of themselves not persistent so whatever back end store Cassandra is using would need to be placed onto soemthing like an Azure Drive (which is persisted to Azure Blob Storage). However, this would limit the scalability of the solution.
Basically, you run Cassandra as a worker role in Azure. Then, you can mount an Azure drive when a worker starts up and unmount when it shuts down.
This provides some insight re: how to use Cassandra on Azure: http://things.smarx.com/#Run Cassandra
Some help w/ Azure drives: http://azurescope.cloudapp.net/CodeSamples/cs/792ce345-256b-4230-a62f-903f79c63a67/
This should not limit your scalability at all. Just spin up another Cassandra instance whenever processing throughput or contiguous storage become an issue.
You might want to check out AppHarbor. AppHarbor is a .Net PaaS built on top of Amazon. It gives users the portability and infrastructure of Amazon and they provide a number of the rich services that Azure offers such as background tasks & load balancing plus some that it doesn't like 3rd party add-ons, dead-simple deployment and more. They already have add-ons for CouchDB, MongoDB and Redis if Cassandra got high enough on the requested features I'm sure they could set it up.