容器云平台的集群高可用及运维方案.docx

? ? ? ? ? ? ? 容器云平台的集群高可用及运维方案 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  1 高可用保障机制 1.1 容器平台高可用设计概览 高可用HA（High Availability）通常是描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。容器平台作为容器应用部署和发布的基础性平台，高可用是其架构设计中必须考虑的因素之一。 (1）高可用设计范畴 从容器平台高可用设计范畴来看，高可用需要从? “平台管理集群高可用”和“平台纳管应用高可用”两个方面进行设计。“平台管理集群高可用”是指容器平台本身的高可用性，“平台纳管应用高可用”是指通过容器平台部署和纳管的容器应用的高可用性。 (2）常见的高可用设计模式 主流容器调度框架的高可用机制一般都是通过集群的高可用来实现的。集群是指一组相互独立的节点服务器在网络中表现为单一的系统，以单一系统的模式加以管理，并且可以为用户提供高可用性的服务。目前常用的高可用集群架构有自选举模式集群、主从模式集群、负载均衡模式集群这几种，通过自选举模式集群和主从模式集群，容器平台可以实现自身管理组件的高可用，通过负载均衡模式集群，容器平台可以实现纳管应用的高可用。 Kubernetes的高可用也是基于上述集群高可用，文中后续将对这种容器调度框架的高可用设计架构和原理进行简要介绍。 (3）高可用基础设计要求 容器平台高可用基础设计要求如下： ◎ 支持平台组件本身的高可用，能够在部分节点出现故障时，通过自选举Leader或主备切换的方式恢复服务。 ◎ 支持集群化部署多个应用容器实例，如果部分容器实例出现故障，其余的容器实例仍然能够对外正常提供服务 ◎ 支持通过负载均衡对上述集群中多个容器实例进行引流，当出现故障实例时，能够实时调整负载均衡配置从而避免引流到故障实例 ◎ 支持对容器实例进行健康检查，如果出现了故障实例，可以对实例进行自愈、告警等措施，保证正常的服务实例能够维持在既定的数量上。 ◎ 能够根据服务负载情况调整实例数量，避免因为负载过大影响集群整体可用性。 1.2 容器平台高可用机制介绍 上一节讲述了容器平台高可用是通过集群的高可用来实现的，下面对常见的高可用机制进行简要介绍。 (1）自选举模式集群 该模式搭建集群的时候节点具有对等性，由集群自己根据特定的共识算法选举出集群的Leader节点。集群搭建比较简单，但是Leader节点宕机之后需要一定的时间选举出新的Leader，一般情况下，集群中宕机的节点数不超过总结点数的一半时，集群可以维持正常服务。典型软件包括：zookeeper，etcd，redis5等。 (2）主从模式集群 主机工作，从机处于监控准备状态；当主机宕机时，从机可以切换为主机，并接管主机的一切工作。 (3）负载均衡模式集群 集群的多个服务节点通过负载均衡代理的方式同时对外提供服务。负载均衡模式具有容错功能，当一台服务器宕机后，负载均衡器能发现这台服务器，并且避免将后续流量导入该服务器直至服务器恢复正常。 1.3 容器平台高可用机制的问题 容器平台基础的高可用机制存在如下问题： (1）集群高可用受限于物理资源高可用 目前容器平台的高可用机制只能在集群节点不完全宕机的情况下提供高可用性，一旦集群节点全部不可用（例如集群节点全部部署在相同的物理载体：同一个机柜、同一个机房、同一个数据中心等，当物理载体出现系统性故障时，可能导致集群所有节点全部宕机），集群服务也会随之不可用。这方面的风险在核心和重要应用系统的高可用设计上也是必须考虑的因素之一。 (2）不能处理容器平台管理集群和计算集群之间网络故障带来的风险 在企业实际网络搭建架构中，一般会将网络划分为不同的安全域，各安全域之间通过防火墙进行隔离，这种情况下可能会造成容器平台管理集群和计算集群分布在不同的安全域里，一旦防火墙策略出现错误，或者跨域防火墙/网关出现故障或网络变更的时候，管理集群和计算集群之间的网络就会发生中断，此时会造成容器平台无法对目标计算集群进行容器调度。如果网络中断时间过长，还可能造成管理集群认为业务容器已失联从而导致业务容器重启等问题。 (3）不能全面保障纳管应用的业务层面高可用 主流容器调度框架在纳管应用高可用机制方面提供了基础的应用健康检查机制，在某些复杂场景下，并不能真实检查出应用业务的实际健康状态。举个例子：应用采用HTTP的方式做健康检查，可能应用业务的web请求仍然可以正常访问，但是业务处理逻辑已发生了错误，此时的“健康状态”并不能反映应用的真实情况。 针对这个问题本文将在案例里介绍一种 “自定义的健康检查”方案来实现对于应用实际业务的检查。（请见2.2 自定义的应用健康检查和故障处理方案） (4）无法在应用出现故障时做出最优化处