Kubernetes 高可用API Server
API Serverd的一些硬核原理其实前面说的差不多了,就是认证,鉴权,准入,限流。这是API server里面最核心的能力,还有一些watch的缓存,因为apiserver除了承担之前的那些职责之外,它还承担了一些角色是保护etcd,apiserver是唯一可以访问etcd这样一个组件,可以有效的收敛外面过来的请求,从apiserver通过同一个客户端,以长连接连到etcd里面,有效的减小etcd的压力。
同时它在这边有基于内存的缓存机制,有些读操作你直接到apiserver。
启动APIServer示例
构建高可用的多副本 apiserver
高可用模式其实就是冗余部署和负载均衡,冗余部署其实就是任何的硬件是不可靠的,我们不能相信基础架构这个层面是完全可靠的,我们就要为这种可能出现的故障做准备,冗余部署多个节点。
我们可以通过冗余部署来实现apiserver的高可用,但是apiserver本身是无状态的rest server,从宏观上面不看它的技术细节,它就是简单的rest server,接受请求然后将请求存下来,这是apiserver唯一要做的事情,所以它是无状态的,无状态的服务管理就会变得非常的简单。
apiserver是无状态的Rest Server,无状态所以方便Scale Up/down 负载均衡。
在多个 apiserver 实例之上,配置负载均衡·,证书可能需要加上LoadbalancerVIP重新生成·
预留充足的CPU、内存资源
如果是通过kubeadm这种方式部署,通过kubelet将apiserver拉起来的,好处是可以为每个apiserver将其封装为k8s的pod,那么就可以探活了,因为支持探测,我要去get一个真正的url,看它这个url还能不能正常返回,如果不正常返回那么就认为这个服务出错了,那么kubelet就会重启。
第二点,既然使用pod方式运行,那么就可以做资源限制的配置,可以限制你的cpu,限制你的资源。
随着集群中节点数量不断增多,APIServer对CPU和内存的开销也不断增大。过少的CPU资源会降低其处理效率,过少的内存资源会导致 Pod 被 OOMKilled,直接导致服务不可用。在规划APIServer资源时,不能仅看当下需求,也要为未来预留充分。
在早期的时候,运行生产化集群,集群规模很小,所以给apiserver留的cpu memory都很小,跑着跑着集群规模越来越大,内存就爆了,天天oom,这个时候我要去变更,将内存扩容出来,跑着跑着发现集群越来越慢,因为cpu有限制了,就给了它两个cpu,不能高效的跑,所以这个时候要去调cpu。
所以在生产化部署的时候,一定要预留好我将来我这个集群规模有多大。他会用多少cpu,多少内存,预留出来,这里面就不要想着省钱了,因为apiserver是如此重要。
善用速率限制(RateLimit)
还要确保我的apiserver不会被oom-kill掉,确保它性能基础之上还要限流。我们要用"--max-requests-inflight"和"--max-mutating-requests-inflight"用来保护我的apiserver的一个总体并发的request,确保它不会被压死。同时配合APF,priority and fairness,通过这种方式来确保我做了一个精细化的限流,当然初始阶段使用默认的配置就好了,之后随着业务的变更再去做调整。
APIServer的参数"--max-requests-inflight"和"--max-mutating-requests-inflight"支持在给定时间内限制并行处理读请求(包括Get、List和Watch操作)和写请求(包括Create、Delete、Update和Patch操作)的最大数量。
当APIServer接收到的请求超过这两个参数设定的值时,再接收到的请求将会被直接拒绝。通过速率限制机制,可以有效地控制APIServer内存的使用。
如果该值配置过低,会经常出现请求超过限制的错误,如果配置过高,则APIServer可能会因为占用过多内存而被强制终止,因此需要根据实际的运行环境,结合实时用户请求数量和APIServer的资源配置进行调优。
客户端在接收到拒绝请求的返回值后,应等待一段时间再发起重试,无间隔的重试会加重APIServer的压力,导致性能进一步降低。
针对并行处理请求数的过滤颗粒度太大,在请求数量比较多的场景,重要的消息可能会被拒绝掉,自1.18版本开始,社区引入了优先级和公平保证(Priority and Fairness)功能,以提供更细粒度地客户端请求控制。
该功能支持将不同用户或不同类型的请求进行优先级归类,保证高优先级的请求总是能够更快得到处理,从而不受低优先级请求的影响。
设置合适的缓存大小
apiserver本身它还是一个缓存,在apiserver去get etcd对象的时候,它会有一个本地cache,watch-cache,它本身是一个ringbuffer,也就是它从etcd拿的那些数据会存在自己的ringbuffer,只要这个ringbuffer没有满,你就可以理解所有的信息都会被缓存掉。如果ringbuffer满了,那么它之前存下的信息就会被覆盖掉。所以ringbuffer就是环状的内存结构。
设置适合的缓存大小,比如--watch-cache-sizes,是apiserver的一个参数,通过这个参数来调节apiserver这边缓存设置多大。集群越大这个值也建议设置的越大,这样apiserver多拿缓存数据减少对etcd的压力,只要本地有就不去查了。
API Server与etcd之间基于 gRPC 协议进行通信,gRPC协议保证了二者在大规模集群中的数据高速传输。gRPC基于连接复用的HTTP/2协议,即针对相同分组的对象,APIServer和etcd之间共享相同的TCP连接,不同请求由不同的stream传输。
一个HTTP/2连接有其stream配额,配额的大小限制了能支持的并发请求。
APIServer提供了集群对象的缓存机制,当客户端发起查询请求时,APIServer默认会将其缓存直接返回给客户端。缓存区大小可以通过参数"--watch-cache-sizes"设置。
针对访问请求比较多的对象,适当设置缓存的大小,极大降低对etcd的访问频率,节省了网络调
用,降低了对 etcd 集群的读写压力,从而提高对象访问的性能。
但是APIServer也是允许客户端忽略缓存的,例如客户端请求中ListOption中没有设置resourceVersion,这时API Server 直接从etcd拉取最新数据返回给客户端。
客户端应尽量避免此操作,应在ListOption中设置resourceVersion为0,APIServer则将从缓存里面读取数据,而不会直接访问etcd。(apiserver是允许客户端忽略缓存的,比如说你要list一个对象,这个对象里面又没有家resourceversion,客户端其实是告诉apiserver说我是不信任你的缓存的,我要的是最新的数据,这个适时候apiserver是穿透的,他要从etcd里面拉取最新的数据,客户端尽量写resource version,这样的话有效的利用了apiserver的缓存)
客户端尽量使用长连接
在架构设计上,优先使用监听,而少用轮询,后端是一个分布式存储,分布式存储支持的并发很弱的,然后你又不相信我apiserver的缓存,你要一直来list数据,我要将这个请求丢到etcd,etcd很累,它会跟不上。
既然etcd apiservre都支持长连接,支持监听机制,那么就建议客户端使用监听机制来获取最新的数据,而不要一直来轮询,一直轮询就会导致我这边压力过大。
监听的话还ok,最多支持长连接,比如单实例支持不了那么多的长连接,比如几十万,上百万,那我还可以横向扩展。通过横向扩展来分散这种并发连接的压力,通过这种机制有效的减少了对服务器端的压力。
当查询请求的返回数据较大且此类请求并发量较大时,容易引发TCP链路的阻塞,导致其他查询操作超时。
因此基于Kubernetes开发组件时,例如某些DaemonSet和Controller,如果要查询某类对象,应尽量通过长连接List Watch监听对象变更,避免全量从APIServer获取资源。
如果在同一应用程序中,如果有多个Informer 监听 API Server 资源变化,可以将这些Informer
合并,减少和APIServer的长连接数,从而降低对APIServer的压力。
Kubernetes 高可用API Server相关推荐
- 容器编排——Kubeadm在线或离线搭建kubernetes高可用集群
目录 1.架构简介: 2.集群架构图: 3.集群服务器: 4.修改主机名称: 5.修改hosts配置文件: 6.关闭selinux: 7.关闭防火墙: 8.关闭swap: 9.设置iptables网桥 ...
- 使用kubeadm安装kubernetes高可用集群
kubeadm安装kubernetes高可用集群搭建 第一步:首先搭建etcd集群 yum install -y etcd 配置文件 /etc/etcd/etcd.confETCD_NAME=inf ...
- 《构建高可用VMware vSphere 5.X虚拟化架构》——第2章 构建高可用vCenter Server 2.1vCenter Server版本以及运行环境的选择...
本节书摘来自异步社区<构建高可用VMware vSphere 5.X虚拟化架构>一书中的第2章,第2.1节,作者:何坤源著,更多章节内容可以访问云栖社区"异步社区"公众 ...
- 二进制方式搭建Kubernetes高可用集群(超丰富的组件概念理论总结)
二进制方式部署Kubernetes高可用集群 文章目录 二进制方式部署Kubernetes高可用集群 1.环境准备 1.1.Kubernetes高可用集群部署方式 1.2.Kubernetes集群弃用 ...
- 二进制安装Kubernetes 高可用集群
一.集群规划 k8s-master1 10.0.19.127 kube-apiserver,kube-controller-manager,kube-scheduler,etcd k8s-master ...
- docker 如何加入kubernetes_使用 Kind 在 5 分钟内快速部署一个 Kubernetes 高可用集群...
什么是 Kind Kind(Kubernetes in Docker) 是一个Kubernetes孵化项目,Kind是一套开箱即用的Kubernetes环境搭建方案.顾名思义,就是将Kubernete ...
- kubespray容器化部署kubernetes高可用集群
一.基础环境 docker版本1.12.6 CentOS 7 1.准备好要部署的机器 IP ROLE 172.30.33.89 k8s-registry-lb 172.30.33.90 k8s-mas ...
- sql server高可用_SQL Server 2019常规可用性和安装概述
sql server高可用 介绍 (Introduction) On November 4th, 2019, during the Ignite conference at Orlando, Micr ...
- k8s实践(6)--Kubernetes安全:API Server访问控制
Kubernetes安全 安全永远是一个重大的话题,特别是云计算平台,更需要设计出一套完善的安全方案,以应对复杂的场景. Kubernetes主要使用Docker作为应用承载环境,Kubernetes ...
最新文章
- 5.7 echo:显示一行文本
- MTV: Django眼中的MVC
- 如何分析 StackOverflow 异常 ?
- Linux 启动顺序
- 洛谷P1141 01迷宫
- 【随机信号分析】实验(十三)窄带信号分析——随机信号的DSB分析
- Python-Selenium自动化登陆QQ空间
- Unreal Engine 4 —— GAS系统学习 (二十八) 创建Lazer招式与GameplayEffect
- [ 习题 ] 句子简化题 细节题 排除题
- 计算广告CTR预估系列(十)--AFM模型理论与实践
- 介绍Jackson JsonNode和ObjectNode(*)
- vsCode安装使用教程和插件安装
- (小技巧) 如何让Linux 机器CPU使用率变高
- Concurrency != Parallelism
- 解决gif 透明度问题
- ArcGIS-创建企业级数据库相关问题
- Knowledge Distillation 知识蒸馏详解
- AEJoy——使用 JS 脚本添加动作及关键帧(二)
- packetix ***连不上问题解决方法
- pom文件依赖范围(来自Maven实战(书籍)-许晓斌)