摘要:自从起便号称可以承载个以上的节点,但是从数十到的路上,难免会遇到问题。本片文章即分享在之路上的经验,包括遇到的问题尝试解决问题以及找到真正的问题。
Kubernetes自从1.6起便号称可以承载5000个以上的节点,但是从数十到5000的路上,难免会遇到问题。
本片文章即分享Open API在kubernetes 5000之路上的经验,包括遇到的问题、尝试解决问题以及找到真正的问题。
遇到的问题以及如何解决 问题一:1 ~ 500个节点之后问题:
kubectl 有时会出现 timeout(p.s. kubectl -v=6 可以显示所有API细节指令)
尝试解决:
一开始以为是kube-apiserver服务器负载的问题,尝试增加proxy做replica协助进行负载均衡
但是超过10个备份master的时候,发现问题不是因为kube-apiserver无法承受负载,GKE通过一台32-core VM就可以承载500个节点
原因:
排除以上原因,开始排查master上剩下的几个服务(etcd、kube-proxy)
开始尝试调整etcd
通过使用datadog查看etcd吞吐量,发现有异常延迟(latency spiking ~100 ms)
通过Fio工具做性能评估,发现只用到10%的IOPS(Input/Output Per Second),由于写入延迟(write latency 2ms)降低了性能
尝试把SSD从网络硬盘变为每台机器有个local temp drive(SSD)
结果从~100ms —> 200us
问题二:~1000个节点的时候问题:
发现kube-apiserver每秒从etcd上读取500mb
尝试解决:
通过Prometheus查看container之间的网络流量
原因:
发现Fluentd和Datadog抓取每个节点上资料过于频繁
调低两个服务的抓取频率,网络性能从500mb/s降低到几乎没有
etcd小技巧:通过--etcd-servers-overrides可以将Kubernetes Event的资料写入作为切割,分不同机器处理,如下所示
--etcd-servers-overrides=/events#https://0.example.com:2381;https://1.example.com:2381;https://2.example.com:2381问题三:1000 ~ 2000个节点
问题:
无法再写入数据,报错cascading failure
kubernetes-ec2-autoscaler在全部的etcd都停掉以后才回传问题,并且关闭所有的etcd
尝试解决:
猜测是etcd硬盘满了,但是检查SSD依旧有很多空间
检查是否有预设的空间限制,发现有2GB大小限制
解決方法:
在etcd启动参数中加入--quota-backend-bytes
修改kubernetes-ec2-autoscaler逻辑——如果超过50%出现问题,关闭集群
各种服务的优化 Kube masters 的高可用一般来说,我们的架构是一个kube-master(主要的 Kubernetes 服务提供组件,上面有kube-apiserver、kube-scheduler 和kube-control-manager)加上多個slave。但是要达到高可用,要参考一下方式实现:
kube-apiserver要设置多个服务,并且通过参数--apiserver-count重启并且设定
kubernetes-ec2-autoscaler可以帮助我们自动关闭idle的资源,但是这跟Kubernetes scheduler的原则相悖,不过通过这些设定,可以帮助我们尽量集中资源。
{ "kind" : "Policy", "apiVersion" : "v1", "predicates" : [ {"name" : "GeneralPredicates"}, {"name" : "MatchInterPodAffinity"}, {"name" : "NoDiskConflict"}, {"name" : "NoVolumeZoneConflict"}, {"name" : "PodToleratesNodeTaints"} ], "priorities" : [ {"name" : "MostRequestedPriority", "weight" : 1}, {"name" : "InterPodAffinityPriority", "weight" : 2} ] }
以上为调整kubernetes scheduler范例,通过调高InterPodAffinityPriority的权重,达到我们的目的。更多示范参考范例.
需要注意的是,目前Kubernetes Scheduler Policy并不支持动态切换,需要重启kube-apiserver(issue: 41600)
调整scheduler policy造成的影响OpenAI使用了KubeDNS ,但不久后发现——
问题:
经常出现DNS查询不到的情况(随机发生)
超过 ~200QPS domain lookup
尝试解决:
尝试查看为何有这种状态,发现有些node上跑了超过10个KuberDNS
解决方法:
由于scheduler policy造成了许多POD的集中
KubeDNS很轻量,容易被分配到同一节点上,造成domain lookup的集中
需要修改POD affinity(相关介绍),尽量让KubeDNS分配到不同的node之上
affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - weight: 100 labelSelector: matchExpressions: - key: k8s-app operator: In values: - kube-dns topologyKey: kubernetes.io/hostname新建节点时Docker image pulls缓慢的问题
问题:
每次新节点建立起来,docker image pull都要花30分钟
尝试解决:
有一个很大的container image Dota,差不多17GB,影响了整个节点的image pulling
开始检查kubelet是否有其他image pull选项
解决方法:
在kubelet增加选项--serialize-image-pulls=false来启动image pulling,让其他服务可以更早地pull(参考:kubelet启动选项)
这个选项需要docker storgae切换到overlay2(可以参考docker教学文章)
并且把docker image存放到SSD,可以让image pull更快一些
补充:source trace
// serializeImagePulls when enabled, tells the Kubelet to pull images one // at a time. We recommend *not* changing the default value on nodes that // run docker daemon with version < 1.9 or an Aufs storage backend. // Issue #10959 has more details. SerializeImagePulls *bool `json:"serializeImagePulls"`提高docker image pull的速度
此外,还可以通过以下方式来提高pull的速度
kubelet参数--image-pull-progress-deadline要提高到30mins
docker daemon参数max-concurrent-download调整到10才能多线程下载
Flannel性能限制
OpenAI节点间的网络流量,可以达到10-15GBit/s,但是由于Flannel所以导致流量会降到 ~2GBit/s
解决方式是拿掉Flannel,使用实际的网络
hostNetwork: true
dnsPolicy: ClusterFirstWithHostNet
这里还有一些注意事项需要详细阅读
想要简单易用、生产就绪的Kubernetes?试试好雨Rainbond——以应用的方式包装Kubernetes,理解和使用更简单,各种管理流程开箱即用!
好雨Rainbond(云帮)是一款以应用为中心的开源PaaS,深度整合基于Kubernetes的容器管理、Service Mesh微服务架构最佳实践、多类型CI/CD应用构建与交付、多数据中心资源管理等技术,为用户提供云原生应用全生命周期解决方案,构建应用与基础设施、应用与应用、基础设施与基础设施之间互联互通的生态体系,满足支撑业务高速发展所需的敏捷开发、高效运维和精益管理需求。
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/32659.html
摘要:下需要为每个单独进行采集配置采集日志目录,采集规则,存储目标等,不易维护。日志服务的日志架构实践我们提出基于阿里云日志服务的日志处理架构,用以补充社区的方案,来尝试解决场景下日志处理的一些细节体验问题。 摘要: 在Kubernetes服务化、日志处理实时化以及日志集中式存储趋势下,Kubernetes日志处理上也遇到的新挑战,包括:容器动态采集、大流量性能瓶颈、日志路由管理等问题。本文...
摘要:是如何工作的这是最近我们经常被问到的一个问题。是一个控制循环,用于监视和缩放部署中的。最早版本仅支持作为可监控的度量标准。是版本以上的首选方法。 Kubernetes Autoscaling是如何工作的?这是最近我们经常被问到的一个问题。 所以本文将从Kubernetes Autoscaling功能的工作原理以及缩放集群时可以提供的优势等方面进行解释。 什么是Autoscaling 想...
摘要:其次,青云的负载均衡器能感知到容器网络,而传统的方案在内部还需要再做一层虚拟网络,层的负载均衡器无法感知容器网络。 前言 容器技术目前的市场现状是一家独大、百花齐放。 关于容器技术,看看青云QingCloud 王渊命(老王)是如何看待它的,本文来自他在青云QingCloud 深圳站实践课堂的演讲。全文 2780字,阅读时长约为 11 分钟。 容器是什么 容器的概念外延比较广,讨论的时候...
摘要:在这种情况下,以防干扰其他集群租户,调度器可能会考虑将作为驱逐的候选对象。其结果是负载均衡和调度之间交互作用。 每当谈及Kubernetes,我们经常听到诸如资源管理、调度和负载均衡等术语。虽然Kubernetes提供了许多功能,但更关键的还是要了解这些概念,只有这样才能更好地理解如何放置、管理并恢复工作负载。在这篇文章中,我提供了每个功能的概述,并解释了它们是如何在Kubernete...
阅读 1304·2021-11-11 11:00
阅读 2994·2021-09-24 09:47
阅读 4897·2021-09-22 15:53
阅读 927·2021-09-10 10:50
阅读 3186·2021-09-01 11:40
阅读 1141·2019-08-30 15:55
阅读 454·2019-08-30 12:49
阅读 1017·2019-08-29 17:12