容器云平台的高可用设计

容器云平台的高可用设计Ⅱ目录Ⅱ1111133457778889PAGE08PAGE08

绪论虽然大部分情况下，我们的系统都能够很好的运行。但绝对不会故障的系统是不存在的。无论代码写的多好，硬件如何的可靠，也无法保证整个系统的稳定。因为故障总是会发生在意想不到的地方。比如2015年5月27日支付宝在杭州的一个机房光纤被挖断，导致部分用户无法正常使用支付宝，直到当日晚上7点20分，支付宝才宣布用户服务恢复正常。1029支付系统宕机近30分钟，使得近两千万笔订单无法正常的完成。阿里腾讯的技术水平不可谓不强，而支付业务又是其中的重中之重。尽管如此，还是会有一些揪心的时刻。为了能够尽可能的减少服务的不可用时间，最大降低损失，我们可以通过架构设计的手段为服务提供强的可用性，即高可用架构设计。N对于高可用架构还应当考虑服务分级与降级，灾难恢复与异地多中心等等机制或场景。随着服务规模的不断扩张，保持或提高可用性的成本会以一种夸张的方式上涨。由于篇幅有限，对于很多知识点都难以面面俱到的深入探讨，在实际应用中还是需要更多的参考实际场景来进行规划。通过前一节的介绍我们可以知道，如果想要保证整个云平台的高可用，对于云平台各个部分自然是需要一定程度了解的。接下来让我们看看常见的容器云平台架构：IO应用在容器这一新秀刚刚发展起来的那段时间里，曾经出现过大量的容器编排系统。其中以Swarm、构建的容器生态体系已经成为了容器领域中的事实标准。安装一个高可用的Kubernetes集群是保障容器云平台高可用的第一步。尽管我们可以通过诸如Kubeadm、RKE或Kops之类的工具轻松的安装一个Kubernetes集群，但是了解一下常见的Kubernetes高可用的实现方法才可以帮助我们更好的维护集群。etcd节点的是◎节点上部署◎时，为工作负载中各个的部署提供推荐的节点。如果我们在配置中加入了亲和性、反亲和性、选择器、资源配额等配置的话，Schedule在调度也是化在用的集群进行任何变更。是通信/raft/在中，数据的同步和n-1)/2（向下取整）。由这个算式我们可以发现，偶数个节点并不能为集群提供更多的冗余，所以通常情况357一个集群只能有一个或中也有(election-timeout)的时长来尽可虽然我们可以通过--consistency=s在linux上，我们可以通过ionice来配置磁盘优先级：$sudoionice-c2-n0-p`pgrepetcd`$sudoionice-c2-n0-p`pgrepetcd`如果可以的话，给etcd挂载ssd盘可以显著的提升etcd的性能。的才会＃命令行参数：$etcd--snapshot-count=5000＃环境变量：$ETCD_SNAPSHOT_COUNT=5000占用过多的内存，甚至达到触发＃命令行参数：$etcd--snapshot-count=5000＃环境变量：$ETCD_SNAPSHOT_COUNT=5000由于Etcd集群中数据会保持一致，所以当我们发现某一个Etcd节点内存紧张的时候，往往整个Etcd集群的节点内存都以及处于比较紧张的状态了。为Etcd的内存状态专门设置监控和告警是很有必要的。即等对象确保这些◎：可以配置为模式与模式都会依赖于同时◎在后面的内容中，我们会重点讲解如何为集群中的应用配置高可用性，使其能够更加灵活的面对诸如worker节点不可用、网络故障等种种问题高可用性是ITIT动变得高可用。为了能够让我们部署在上面的应用（包括容器云平台这个应用）在这张图中我们罗列了常见的5个潜在的故障点。通过认识这些故障点，可以帮助我们通过冗余和反亲和性的方式为应用带来更高的可用性。Worker节点通常都是运行在物理机上的虚拟机，其可用性可能会受到其宿主机的硬件故障，网络故障等故障的影响。为了避免单个Worker节点故障带来的不可用，应该要创建更多的Worker节点。服务器是从pod，以确保可用性和故障恢复。如果Worker节点未跨请使用)或服务的公共IPIPIPIPIP再将流量发送到此IP地址。但是有了多个集群就会存在多个集群打通的问题，直接的方法是通过手工或者工具将镜像拷贝实现交付物流转，或者是引入CICD实现交付物在不同集群中的流转和发布。数据丢失接下来我们从Kubernetes中提供的功能下手，了解如何通过Kubernetes集群创建一个在集群中高可用的应用。是对象的子集，其功能主要是维持某一个Pod的副本数量，通过这个功能我们可以实现/为多个和或者的io为AB如果在一定时间内业务需求上下波动较多，可能会导致过多的扩展与收缩，这种行为被称为抖动我们希望应用总是可用，又希望应用能始终维护到最新的版本。对于这种情况，我们就需要滚动更新功能。滚动更新允许通过用新的Pod实例增量更新Pod实例。如果我们是通过Service的方式访问的该Deployment，那么通过滚动更新就能做到无感知的更新服务。的修改的下一个版本出现了导致不可用的异常，或者写了一个不存在镜像。那么在更新时，旧的可用的在很多时候，服务可能不可用了，但是进程仍然存在与机器中。或者服务可用，但是响应时间超出我们的限制。又或者接口返回异常之类的其他我们认为服务以及不可用的场景。这些情况下我们都需要进行故障转移。所以我们需要一种检查服务是否健康的组件，这个组件可能需要预设一个目标操作，响应时间，响应周期，正常响应内容等。然后这个组件就会周期性的检查服务是否可用，并为故障转移服务提供相应的结果。在Kubernetes中，为健康状态的检查准备以下几种探针：◎◎通过灵活的配置探针，我们可以让应用及时的发现问题，并决定是否重启。这样由Kubernetes管理应用的可用性与健康状态后，可以减少很多额外的运维工作。在Kubernetes集群中，我们通过CMO（Cluster-MonitoringOperator）来一键部署高可用监控，并且评估告警规则，触发告警后，会将告警推送到AlertManager中。因此，原生的监控系统高可用体现在Prometheus的高可用和AlertManager的高可用。Prometheus高可用◎服务高可用：Prometheus通过Pull的模式去采集目标的监控数据，这样可以很容易的实现Prometheus的服务高可用，我们只需要部署多个Prometheus实例，配置相同的采集目标即可。◎数据高可用：Prometheus内置了时序数据库TSDB，默认会将监控指标数据以自定义格式保存在以PV挂载的本地磁盘中。AlertManager高可用是+的简称负责数据的展示。在集群中，我们可以通过进行高可用部署。当然，在实际情况中，我们可以将ES集群和Kibana部署在Kubernetes集群之外，同时引入Kafka等高性能消息队列，可以有效避免采集端日志量过大，日志存储无法及时落盘，避免日志的延迟和丢失；同时解耦采集端和存储端，增加架构的灵活性和扩展性；可以有多个消费者同时处理日志，提升日志处理效率。的抽象，为他们提供一个统一的内部访问入口。主Service的负载均衡可以有多个方式实现，目前Kubernetes提供三种模式：userspace，iptables以及ipvs。我们就可以在集群内部通过Service轻松的建立起Pods之间的连接，但是在集群之外是无法访问这些Service的，为了能够从集群外访问集群内的服务，我们需要用Ingress将Service暴露出来。不过，虽然对象在对象是无法实现让IngressController可以在更多节点上扩展使得具有更多副本，提供高可用性。在多个ingresscontroller的环境中，我们借助外部硬件或者软件负载均衡器来实现，采用负载均衡的方式，和前面提到的APIServer接入的高可用方式一致，在实际的生产环境中，我们建议将南北向的IngressLB和东西向的APILB进行分离，以保证高可用和性能的实现。的可用性，在一组时A公司的流量使用一个中的每个◎Pod具有唯一网络名称：Pod具有唯一的名称，而且在重启后会保持不变。通过Headless服务，基于主机名，每个Pod都有独立的网络地址，这个网域由一个Headless服务所控制。这样每个Pod会保持稳定的唯一的域名，使得集群就不会将重新创建出的Pod作为新成员。中的每个可以有其自己独立的◎有序的，优雅的部署和缩放◎有序的，自动的滚动更新团队提出了概念。Srme，CRD扩展了K8SAPI。其基本模式如下图所示：V4或第三方的或开发的各种，用来部署和维护相应的服务。可以说，有状态应用上云，Operator可以很简单，比如只负责软件安装，也可以很复杂，比如软件更新、完整生命周期管理、监控告警甚至自动伸缩等等。中如何创建高可容器云平台本质上可以视为一个无状态的组件，平台中的数据存储在Kubernetes的Etcd中。我们将容器云平台的通过的方式部署在集群中，并将其设置为一个不小于1暴露在同一个访问到这个流量会走向其他的中。整N。”和”或者其他配置方式挂载多个镜像仓库的上，就可deRedis高可用设计镜像扫描也是企业级镜像仓库必不可少的的功能之一。但由于镜像数量往往非常的多，不论是jfrog的xray还是coreos的clair都会将需要扫描的镜像层压入一个队列中。这里我们以Redis为例，讲解如何为非关系型数据库实现高可用。其他ip之间始终需要互相通信，进而就需要为每一个配置服务发现。然而要为每一个配置Service，我们需要用到其Podname。所以我们需要有一组稳定的标识符（Label）来帮助我们发现RedisPod。在送到上，就会发生异常。为了保证能够通过一个地址始终访问到可用的s的4所有的不管是还是集群时都为了这些将是一个企业级的分发，以提高分布式开发站点之间的性能，并提高灾难恢复的弹性和冗余性。你可以使用在线的，也可以使用的Quay作为企业级镜像仓库，可以提供充足的功能，在高可用相关方面，包括了：◎地域复制：连续的地理分布可提高性能，确保您的内容始终在最需要的地方可用。◎安全漏洞检测集成：RedHatQuay漏洞检测器（例如Clair）集成在一起，并扫描您的容器镜像识别已知漏洞。◎持久存储：支持多种存储后端来存储您的容器。◎高可用性：可以运行RedHatQuay的多个实例以实现冗余，多个实例可以同时运行，互相备份以共同分担负载，提高可用性，防止单点故障。◎dt，和开放式ID连接◎指标：内置的Prometheus指标导出可在每个实例上启用临时和批处理作业指标，以便于监视和