非常抱歉，今天下午 16:30-17:15 期间，由于出现突发故障，造成园子无法正常访问，由此给您带来麻烦，请您谅解。
故障经过如下：
16:30 开始，Kubernetes 集群上博客站点的部分 pod 出现请求执行时间慢（5-10秒）的问题。
16:43 开始，请求执行时间慢的问题更加严重，开始出现执行时间超过10秒的请求。
16:50 开始，出现大量数据库连接超时的日志：
System.Data.SqlClient.SqlException (0x80131904): Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
同时数据库服务器的 CPU 从正常时期的 30% 以下飙升至 45% 多。
这时我们判断数据库服务器可能会超载，于是做了一个艰难的决定——按下“高速中换轮胎”的紧急按钮，启动了数据库的主备切换。
16:55 左右完成主备切换，但数据库的主备切换会造成 pod 因健康检查失败而重启，在访问高峰的高并发请求下，重启后的 pod 很容易出现不堪重负的无奈情况。
直到 17:10 左右才基本恢复。
最后剩下一款体质较差的 pod，重启后一接入负载总是不堪重负，落到它上面的请求就响应缓慢，拿它一点办法没有。
后来，急中生笨方法，既然体质弱的现实无法改变，那就接受这个现实，不让它干活就行，怎么让它不干活呢？在旧 pod 被删除之后与新 pod 启动完成健康检查之前，这个阶段 pod 是不干活的，只要让它一直处在这个阶段就行。于是盯着这款 pod，一等它完成健康检查有负载进来就删除它，用这个笨方法熬过访问高峰，体质弱的 pod 就能继续干活了。
（故障完）
标签：10,16,数据库,周五,突发,故障,主备,pod 来源： https://www.cnblogs.com/cmt/p/15910907.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。