之所以斗胆将此文叫优化指南,主要参考的官方 链接 , 本文是基于 openshift 3.5 说的。
本指南提供了如何提高 OpenShift 容器平台的集群性能和生产环境下的最佳实践。 主要包括建立,扩展和调优 OpenShift 集群的推荐做法。
个人看法,其实性能这个东西是个权衡的过程,根据自身硬件条件和实际需求,选择适合自己的调优手段。
首先安装自然要选择官方的 openshift-ansible 项目 , 默认是 rpm 安装方式,需要依赖网络,比如要去联网下载
包依赖,
- atomic-openshift-*, iptables, 和 docker
如果有不能联网的节点,可以参考我之前写的 离线安装 openshift 。
官方推荐使用 ansible 安装,这里说下针对 ansible 的优化,以提高安装效率,主要参考 ansible 官方 blog ,
如果参考上文离线安装的话,不建议跨外网连接 rpm 仓或者镜像仓,下面是推荐的 ansible 配置
- # cat /etc/ansible/ansible.cfg
- # config file for ansible -- http://ansible.com/
- # ==============================================
- [defaults]
- forks = 20 # 20个并发是理想值,太高的话中间会有概率出错
- host_key_checking = False
- remote_user = root
- roles_path = roles/
- gathering = smart
- fact_caching = jsonfile
- fact_caching_connection = $HOME/ansible/facts
- fact_caching_timeout = 600
- log_path = $HOME/ansible.log
- nocows = 1
- callback_whitelist = profile_tasks
- [privilege_escalation]
- become = False
- [ssh_connection]
- ssh_args = -o ControlMaster=auto -o ControlPersist=600s
- control_path = %(directory)s/%%h-%%r
- pipelining = True # 多路复用,减少了控制机和目标间的连接次数,加速了性能。
- timeout = 10
这里必须要提下,一定要安装前做好网络规划,不然后面改起来很麻烦,
默认是每个 node 上最多可跑 110 个 pods,这个要看自身硬件条件,比如说我的环境全是高配物理机,我就改成了,每个节点可以跑 1024 个 pods,这个主要改下面的地方。
- openshift_node_kubelet_args={'pods-per-core': ['0'], 'max-pods': ['1024'], 'image-gc-high-threshold': ['90'], 'image-gc-low-threshold': ['80']}
- osm_host_subnet_length=10
- osm_cluster_network_cidr=12.1.0.0/12
关于网络的更多优化项,后面有单独介绍。
openhshift 集群里,除了 pod 间的网络通信外,最大的开销就是 master 和 etcd 间的通信了,openshift 的 master 集成了 k8s 里的 api-server, master 主要通过 etcd 来交互 node 状态,网络配置,secrets 和卷挂载等等信息
主要优化点包括:
node 节点的配置主要在 **/etc/origin/node/node-config.yaml** 里, 优化点视具体情况定,主要可以优化的点有:
配合自文件里还可以配置 kubelet 的启动参数,主要关注两点
,这两个决定了 node 节点的 pod 数,两者不一致时,取值小的。如果数值过大(严重超卖)会导致:
- pods-per-core 和 max-pods
有一点要注意,k8s 体系的平台,跑一个 pod,实际会启动两个容器,一个 pause 先于业务容器启动,主要负责网络事项,所以跑 10 个 pods,实际上会运行 20 个容器
etcd 是一个分布式的 key-value 存储,所以有条件的话,存储读写性能的提升,上 ssd 最好了。
其次是网络的优化,比如和 masters 部署在一起,或者提供专网连接。
etcd 实际使用中,最好的提升手段,是关注内存,这个官网有个换算公式的,多少 pods 推荐多大内存的使用
上面的所有节点,内核层面都需要做些优化,这里推荐使用 tuned 工具来做,这点属于常规运维优化了,具体可以参考 这里 来做, 不想明白原理的,可以如下 快速操作,redhat 的人已经自动化了。
- yum install tuned
- systemctl start tune
- systemctl enable tuned
- tuned-adm profile throughput-performance)来做
主要是资源管理这块儿的注意点, 我以前有 blog 专门介绍过,主要值得一提的是,这里有个隐形的 QoS 级别
Guaranteed 类型的 pod 是优先级最高的,是有保证的,只会在程序本身 "异常" 超出 limits(一般的应用在 pod 层设置了 limits,就不会超过该限制的,除非是 java 系的,其需要用环境变量来控制),才会被杀掉,其他类型的配额在集群资源紧张时会被 kill 掉的。
这块儿更多的细节也可以参考 官文
这里需要注意的是,可以提前把需要的基础镜像先 pull 到 node 节点上,比如 origin-pod 镜像等,还有其他自定义的 Gold 镜像,这样可以减少应用部署时间。
如果是采用镜像方式部署集群的话,也可以采取提前 pull 镜像的方式,当然有私有镜像仓的,可以忽略。
主要是现在默认的镜像拉取策略就是 IfNotPresent,才能完成加速部署的效果
线上容器环境可能很干净, 如何调试一个线上正在运行的容器,估计困扰过很多开发人员,这个其实利用 docker 原生特性,可以很 easy 的做到
比如你自己 build 一个工具包镜像 tools,里面装有
等等 debug 工具,如下可以很方便的动态的嵌入到运行的线上容器中。
- tcpdump,perf,strace
- docker run -t --pid=container:production \
- --net=container:production \
- --cap-add sys_admin \
- --cap-add sys_ptrace \
- tools
当然万能的日志调式,也是 OK 的。
这里的存储说的是 docker 的 graph 驱动( Device Mapper, Overlay, 和 Btrfs),首先 overlay 在启停容器速度方面要优于 devicemapper,其还能带来更优良的页面缓存共享,但存在 POSIX 兼容性问题,比如不支持 SELinux。
官方是推荐使用 thin devicemapper 的,但需要额外的独立块盘才能搞定。如果系统是 7.2 的话,使用 overlay 亦可,关闭 selinux 的代价就是牺牲部分容器安全。
openshift 里的 Router 是基于 haproxy 做的,等价于 k8s 里的 nginx ingress 服务,提供集群内的 service 供外访问能力。
一般一个 4 vCPU/16GB RAM 的虚机,可以提供 7000-32000 HTTP keep-alive 连接请求,这取决于连接是否加密和页面大小,如果是物理机的话,性能会翻倍。
可通过 Router sharding 的技术来扩展性能。下图各种配置是统计性能(默认 100 个 routes)
默认 openshift 提供了一个基于 ovs 的 sdn 方案,其中涉及到了 vxlan, OpenFlow 和 iptables,当然这些相关的优化项社区已经有很成熟的优化点和方法了,比如增大 MTU,UDP-offload,多路复用等等,
这里重点说下 vxlan, 基于二层网络,vxlan 从 4096 提升到了 16 百万多个,vxlan 就是把原报文封装进 UDP 报文,以提供所有 pods 间通信的能力,自然这样会增加 cpu 解封包的开销,具体网络吞吐取决于 cpu 的性能,另外还会额外增加延时响应。
直白的说,现在云主机或物理机的 cpu 都可以打满千兆网卡,如果是万兆网卡,那 vxlan 网络的吞吐带宽会卡在 CPU 上,这是所有 overlay 网络的现状。
如果你的主机用用万兆或者 40Gbps, 那就要考虑网络的性能优化了:
值得注意点是,及时使用了 udp-offload 的网卡,和非 overlay 网络比,延迟是不会减少的,只是减少了 cpu 开销,从而提高了带宽吞吐。
现在 openshift-ansible 项目默认的安装出来的配置是:
比如我要搞一个 8192 个节点的集群,每个节点允许 510 个 pods 运行:
- [OSE3:vars]
- osm_cluster_network_cidr=10.128.0.0/10
都知道 k8s 里的弹性伸缩,依赖于 Heapster, 而 openshift 内置的监控系统又是用的自家的 Haw 系列,导致监控镜像相当的大
在 opneshift 里有两点要提的是 METRICS_RESOLUTION 和 METRICS_DURATION 变量,前者是默认是 30s, 指的是监控时间间隔,后者默认是 7 天,指的是监控数据保留时长(过期就会删掉)。
默认的监控体系 (Cassandra/Hawkular/Heapster) 可以监控 25000 个 pods。
其实 openshift 基于 k8s 提供了一站式解决方案, 如果公司不具备 k8s 二次开发能力,openshift 足矣。
来源: https://juejin.im/entry/5a37681051882515945aae27