I need to know how does AKS create its Kubernetes clusters from HA perspective. Specifically, I need to know what is the default number of availability zones when an Azure AKS clusters is created.
Currently AKS does not support Availability Zones.
EDIT: this is no longer true.
AKS already supports Availability Zones in many regions, see https://learn.microsoft.com/en-us/azure/aks/availability-zones.
It uses the zones you pass as --zones when you create the cluster. It will use only one (single AZ) by default if you don't set anything.
Related
we run a AKS Cluster with about 35 Microservices and now need a HiveMQ.
We are unsure on how to proceed. We could just deploy a HiveMQ on our AKS cluster over helm as we did on the dev cluster.
But we are unsure if this is a good idea. Our concerns are, that the scaling of the services and the HiveMQ are not independent if we do so.
But of course to setup a hole ci/cd process for a AKS cluster for each stage and market comes with some work and costs.
We have around 20 Million end devices using our backend and scaling is a big issue. But I found nothing that explicitly says that we need a different Cluster to justify the planning of the work.
What is your opinion?
Thanks!
Robin
The decision is based on your resources, if you have a big cluster composed of reliable multiple nodes with reliable CPU/MEM do it on the same cluster but in a dedicated namespace.
Having it to another cluster will be the same, you will just have other nodes, are they more reliable than the one from the first cluster? DTS, but it will not be a bad idea, mainly if you deploy the cluster on another AKS region, one could say that this will be more "safe"
So it is absolutely up to you, personally if my first cluster is well managed and have a good support, I would have deployed it there.
I have a question on inter-zone egress charges on Google Cloud Run (managed). As I understand there is no control over which zones Cloud Run chooses. So potentially when deploying several microservices talking to each other, there could be significant charges.
In kubernetes this can be alleviated via service topology (preferring same zone or even same host if available). Is there anyway to achieve this with Cloud Run?
https://kubernetes.io/docs/concepts/services-networking/service-topology/
According to Cloud Run pricing and internet egress pricing cost stays the same
independent if apps are within the same zone or not.
Now if you plan to have heavy traffic between your apps you should consider using different setup. Either GKE or Cloud Run for Anthos will allow you to setup communication between your apps through internal IP addresses which is free of charge assuming they are in the same zone. Refer to this table.
I have a AWS EKS cluster 1.12 version for my applications, We have deployed 6 apps in the cluster everything is working fine, while creating nodes I have added an autoscaling node group which spans across availability zones with minimum 3 and max 6 nodes, so desired 3 nodes are running fine.
I have scenario like this:
when some memory spike happens I need to get more nodes as I mentioned in auto scaling group max nodes, so at the time of cluster set up I didn't add Cluster auto scale.
Can somebody please address following doubts
As per AWS documentation cluster auto scale won't support if our node group in multiple AZs
If at all we require to create multiple node groups as per the aws doc, how to mention min max nodes, is it like for entire cluster ?
How can I achieve auto scale on memory metric since this won't come by default like cpu metric
You should create one node group for every AZ. So if your cluster size is 6 nodes then create 2 instance node groups in one AZ each. You can also spread the pods across AZ for High Availability. If you look at cluster autoscaler documentation, it recommends:
Cluster autoscaler does not support Auto Scaling Groups which span
multiple Availability Zones; instead you should use an Auto Scaling
Group for each Availability Zone and enable the
--balance-similar-node-groups feature. If you do use a single Auto Scaling Group that spans multiple Availability Zones you will find
that AWS unexpectedly terminates nodes without them being drained
because of the rebalancing feature.
I am assuming you want to scale the pods based on memory. For that you will have to use metric server or Prometheus and create a HPA which scaled based on memory. You can find a working example here.
Google App Engine flexible allows you to deploy docker containers... how does scaling manifest itself?
Will a new VM be spun up each time the application needs to scale or can it spin up new container instances on an existing VM?
Can individual containers scale independent of each other? e.g. product container is under load but customer is not so only a new product container is spun up?
I realize GKE would be a better option for scaling containers, but I need to understand how this works on GAE for a multitude of reasons.
App Engine flex will only run one of your app container per VM instance. If it needs to scale up, it'll always create a new VM to run the new container.
As per your example, if you want to scale "product" and "customer" containers separately, you'll need to define them as separate App Engine services. Each service will have its own scaling set up and act independently.
If you have containers, you can have a look to Cloud Run, which scale to 0 and can scale up very quickly (there is no new VM to proviion, that can take several seconds on AppEngine Flex).
However, long run aren't supported (limited to 15 minutes). All depends you requirement in term of feature, portability, scalability.
Provide more details if you want more advices.
Google App Engine is a fully managed serverless platform, where you basically submit a code and GAE will manage the underlying infrastructure and the runtime environment (for example the version of a python interpreter). You can also customize the runtime environment with Dockerfiles.
In contrast, GKE provides more fine-grained control on your cluster infrastructure. You can configure your computer resources, network, security, how the services are exposed, custom scaling policies, etc. GKE can be considered a managed container orchestration plaform.
An alternative to GKE that can provide even more control is creating the resources you need in GCE and configuring Kubernetes by yourself.
Both GKE and GAE are based and priced on compute engine instances. Google Cloud Functions, however, is a more recent event-driven serverless service. GCF is great if you want to execute code on an event-driven basis (for example, sending a confirmation email after a user registers).
In terms of complexity and control over your code's environment I would order the different Google services as:
GCE(Compute Engine) > GKE(Kubernetes Engine) > GAE(App Engine) > GCF(Cloud Functions)
One point to consider is that the more low-level you go the easier it is to migrate your service to another platform.
Given that you seem to be deploying only containerized applications, I would recommend giving GKE a try, specially if you want to have a cluster of multiple services that interact with each other.
In terms of scaling, GAE will scale only VM instances and you have only one app per VM instance.
In GKE you have two types of scaling: container scaling and VM instance scaling. You can have multiple containers in one instance and those containers can be different apps. Based on limits you define (such as the CPU used in an app) GKE will try to efficiently allocate the containers across the instances of your cluster.
Is it possible to failover the traffic from a mysql k8s deployment running in one datacenter to a deployment running in another datacenter along with its storage?
If yes , Do we need to spread the same k8s cluster on multiple datacenters or we have to run separate k8s clusters in each datacenter?
How k8s will ship or manage the storage volume across the datacenters? Do we need a special type of cloud storage for that purpose?
note: I just qouted mysql as an example of application that needs to store some data , it can be anything stateful that needs to carry over its data volumes. it is not that kind of HA like mysql-HA , it is just starting serving the application as it is from somewhere else automatically along with its data. any application that stores data to volume.
How can we achieve HA for our stateful application across the datacenters using k8s.
Thanks
You don't need to use Kubernetes to achieve HA.
I would recommend using MySQL Replication(i.e. Master/Slave configuration) to achieve HA. More info in the docs on how to set replication up.
In one data center, you would have a Master, and in your other data center, you would have the slave. You can even have multiple slaves in multiple data centers.
If problems arise on the master, you can automatically failover to a slave using the mysqlfailover utility. This way you have your data in 2 data centers that is in sync.
I'm not sure if this exactly fits your use cases, but it is one option for enabling HA on your MySQL database.