Answers: <p>Your application requirements really do influence your options here, maybe add more detail about the app because this subject is very much about your application architecture too.</p>
  
  <p>The application state is fixed, pod's are rebuilt as per the spec or source container that defines them and the replication sets take care of the deployment so I'd say the application from a Kubernetes perspective is already highly available by design and the reason why the documentation contains little coverage if any with regard to application level HA.</p>
  
  <p>It's worth noting too that Kubernetes High Availability with kubeadm is still in its experimental stage and your clusters need to be running Kubernetes version 1.12 or later.</p>
  
  <p>Google's Kubernetes Engine for instance; offers 'Regional Clusters' and these are spread over many zones in a region. This certainly increases your cluster availability. <a href="https://cloud.google.com/kubernetes-engine/docs/concepts/regional-clusters" rel="nofollow noreferrer">More here in GKE regions</a></p>
  
  <p>The official word on the current state of Kubernetes HA cluster options are well documented here. <a href="https://kubernetes.io/docs/setup/independent/ha-topology/" rel="nofollow noreferrer">https://kubernetes.io/docs/setup/independent/ha-topology/</a> </p>
  
Answers: CC BY-SA 4.0
Answers: 2019-01-28T17:51:26.143Z
Answers: 2019-01-29T00:11:11.520Z
Answers: 2019-01-29T00:11:11.520Z
Answers: spaceshipdev
Body: <p>Is this something that's going to be covered at the application level with pod autoscaling? Or should we implement both horizontal pod autoscaling and infrastructure high availability within our cloud provider? The goal is for us to see minimal downtime. </p>
  
Comments: CC BY-SA 4.0
Comments: 2019-01-29T08:02:20.200Z
Comments: You might want to look at the reference architectures that come with sample configuration for openshift kubernetes on public cloud. there are ones for Azure and AWS for example but also openstack for on-prem https://blog.openshift.com/openshift-container-platform-reference-architecture-implementation-guides/ for example to learn I setup a cluster on AWS using their cloudformation templates in only a few hours. that has full ha of the VMs and of close any VMs dies k8s starts replacement containers on another VM. Kill a VMs and AWS restarts it as using its vm ha features.
Comments: simbo1905
Tags: <kubernetes><infrastructure><high-availability><gcp><minikube>
Title: If we are using Kubernetes do we need to implement HA on both the infrastructure and application level?
UserDisplayName: Wunderbread
ThreadText: # If we are using Kubernetes do we need to implement HA on both the infrastructure and application level?
  
  (Asked by: username_0 on 2019-01-28)
  
  Is this something that's going to be covered at the application level with pod autoscaling? Or should we implement both horizontal pod autoscaling and infrastructure high availability within our cloud provider? The goal is for us to see minimal downtime.
  
  **Tags:** kubernetes, infrastructure, high-availability, gcp, minikube
  
  > **Comments:**
  > **username_1**: You might want to look at the reference architectures that come with sample configuration for openshift kubernetes on public cloud. there are ones for Azure and AWS for example but also openstack for on-prem https://blog.openshift.com/openshift-container-platform-reference-architecture-implementation-guides/ for example to learn I setup a cluster on AWS using their cloudformation templates in only a few hours. that has full ha of the VMs and of close any VMs dies k8s starts replacement containers on another VM. Kill a VMs and AWS restarts it as using its vm ha features.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2019-01-28. Score: 2 | Accepted answer
  
  Your application requirements really do influence your options here, maybe add more detail about the app because this subject is very much about your application architecture too.
  
  The application state is fixed, pod's are rebuilt as per the spec or source container that defines them and the replication sets take care of the deployment so I'd say the application from a Kubernetes perspective is already highly available by design and the reason why the documentation contains little coverage if any with regard to application level HA.
  
  It's worth noting too that Kubernetes High Availability with kubeadm is still in its experimental stage and your clusters need to be running Kubernetes version 1.12 or later.
  
  Google's Kubernetes Engine for instance; offers 'Regional Clusters' and these are spread over many zones in a region. This certainly increases your cluster availability. [More here in GKE regions](https://cloud.google.com/kubernetes-engine/docs/concepts/regional-clusters)
  
  The official word on the current state of Kubernetes HA cluster options are well documented here. <https://kubernetes.io/docs/setup/independent/ha-topology/>
  
  
  ---
  
  