解决k8sMysqlCluster无故重启问题

　　前言
　　使用 bitpoke的mysql-operator 作为k8s的mysql服务，使用的版本v0.4.0,
　　github地址：https://github.com/bitpoke/mysql-operator 介绍
　　MysqlCluster operator主要支持如下功能 数据自动备份/还原 主从模式 支持Prometheus 数据监控 问题产生
　　建立的mysql服务每隔一段时间就重启，事件的报错信息如下 Readiness probe failed: ERROR 2003 (HY000): Can＂t connect to MySQL server on ＂127.0.0.1＂ (111) /bin/sh: line 0: test: -eq: unary operator expected  Liveness probe failed: Get ＂http://172.31.210.72:9125/metrics＂: dial tcp 172.31.210.72:9125: connect: connection refused 定位问题
　　为什么心跳不通过？
　　貌似心跳机制不通过，查看pod信息
　　pod 探针设置
　　心跳默认20秒不通过，就重启，看源码也没有心跳配置项，坑啊，不过这只是表象，到底是什么导致心跳不通过？
　　mysqlCluster启动时，会启动4个容器metrices-exporter, mysql, pt-heartbeat, sidecar。看这4个容器的cpu, 内存使用情况，发现mysql内存超过，如下：
　　mysql内存使用情况
　　看最后状态，OOMKilled，而且当前内存使用率3.9G 接近limit 4G的设置。 找到产生的问题原因了，是因为内存超了，被容器杀掉，导致心跳不通过报错重启
　　为什么内存使用这么高？
　　思考mysql使用内存高，可能跟mysql自身缓存有关系，查内存相关参数 show variables where variable_name in (＂innodb_buffer_pool_size＂,＂innodb_log_buffer_size＂,＂innodb_additional_mem_pool_size＂,＂key_buffer_size＂,＂query_cache_size＂);
　　mysql配置信息
　　看到 innodb_buffer_pool_size 设置得值特别大，这个参数设置只有主要缓存innodb表的索引，数据，插入数据时的缓冲，但默认是8M。
　　为什么 innodb_buffer_pool_size 设置变得这么大？
　　翻翻mysqlCluster源码，跟innodb_buffer_pool_size 有关代码
　　default.go // 没有设置innodb-buffer-pool-size ,通过cluster.Spec.PodSpec.Resources.Requests.Memory 配置项计算一个 // set innodb-buffer-pool-size if not set 	innodbBufferPoolSize := 128 * mb // MySQL default value 	if mem := cluster.Spec.PodSpec.Resources.Requests.Memory(); mem != nil && !mem.IsZero() { 		var cErr error 		if innodbBufferPoolSize, cErr = computeInnodbBufferPoolSize(mem); cErr == nil { 			setConfigIfNotSet(cluster.Spec.MysqlConf, ＂innodb-buffer-pool-size＂, humanizeSize(innodbBufferPoolSize)) 		} 	} 	 // 计算大小 func computeInnodbBufferPoolSize(mem *resource.Quantity) (int64, error) { 	availableMem := mem.Copy() 	percentRAM := 0.75  	if mem.Value() <= 512*mb { 		// don＂t set innodb-buffer-pool-size leave it to mysql default (128M) 		return 0, fmt.Errorf(＂memory too small to compute innodb-buffer-pool-size: %s＂, mem) 	} else if mem.Value() <= 1*gb { 		// RAM <= 1gb => buffer size set to RAM * 0.5 		availableMem.Sub(resource.MustParse(＂256Mi＂)) 		percentRAM = 0.5 	} else if mem.Value() <= 4*gb { 		// RAM <= 4gb => buffer size set to RAM * 0.75 		availableMem.Sub(resource.MustParse(＂256Mi＂)) 		percentRAM = 0.75 	} else if mem.Value() > 4*gb { 		// RAM > 4gb => buffer size set to RAM * 0.8 		availableMem.Sub(resource.MustParse(＂512Mi＂)) 		percentRAM = 0.8 	}  	return int64(float64(availableMem.Value()) * percentRAM), nil }
　　源码解析：没有设置innodb-buffer-pool-size， 则通过cluster.Spec.PodSpec.Resources.Requests.Memory 大小的参数乘以系数，这里是0.75，所以是3G。
　　问题就在这里，为了保证资源独占，mysql设置时是request = limit，因为自动计算导致 innodb-buffer-pool-size过大，最终导致oom，需要手动设置innodb-buffer-pool-size，就手动设置2G吧 mysqlConf：  innodb-buffer-pool-size: 2147483648
　　设置 innodb-buffer-pool-size 不生效？
　　设置后，pod不重启？ 参数没有生效设置。设另一个512M就生效了。尝试加入引号，作为字符串处理，配置开始生效。难道跟类型有关系？ 继续看相关源码
　　default.go innodbBufferPoolSize := 128 * mb // MySQL default value if mem := cluster.Spec.PodSpec.Resources.Requests.Memory(); mem != nil && !mem.IsZero() { 	var cErr error 	if innodbBufferPoolSize, cErr = computeInnodbBufferPoolSize(mem); cErr == nil { 		setConfigIfNotSet(cluster.Spec.MysqlConf, ＂innodb-buffer-pool-size＂, humanizeSize(innodbBufferPoolSize)) 	} }
　　看这个类型定义cluster.Spec.MysqlConf
　　MysqlClusterSpec type MysqlConf map[string]intstr.IntOrString
　　intstr type IntOrString struct { 	Type   Type   `protobuf:＂varint,1,opt,name=type,casttype=Type＂` 	IntVal int32  `protobuf:＂varint,2,opt,name=intVal＂` 	StrVal string `protobuf:＂bytes,3,opt,name=strVal＂` }
　　如果设置成数字，则整数是int32位
　　看int32位的长度
　　int32 the set of all signed 32-bit integers (-2147483648 to 2147483647)
　　2147483647 < 2147483648 = 2g 所以应该是配置报错，但没有抛出来而已
　　至此内存使用过大的问题，解决了，内存使用也降下来了 结论mysqlCluster 自动设置了 innodb-buffer-pool-size 导致内存过高，超过Limit限制，被容器kill，反复重启，事件日志就是心跳连不上了，导致重启。 k8s 上有状态的服务。优点：操作快捷方便，普通开发人员都可以操作。缺点：刚起步，很多方面不够完善，包括文档。碰见问题，需要下源码查具体问题。