https://imroc.cc/post/202105/431-status-code/

介绍 istio 中响应 431 状态码原因及其解决方案

https://imroc.cc/post/202105/why-enable-bridge-nf-call-iptables/

介绍 bridge-nf-call-iptables 内核参数的原理以及在 k8s 环境中往往需要开启此参数的原因

https://imroc.cc/post/202105/partially-enable-accesslog/

介绍如何在 istio 环境为部分 workload 启用 accesslog 而非全局启用

https://imroc.cc/post/202105/kubecm/

教你用 kubecm 轻松导入和管理多个集群 kubeconfig

https://imroc.cc/post/202105/capture-packets-with-ksniff/

介绍如何使用 kubectl 的 sniff 插件快速抓包

https://imroc.cc/post/202106/graceful-shutdown/

介绍在 k8s 环境实现优雅终止的最佳实践

https://imroc.cc/post/202105/using-istio-reserved-port-causes-pod-start-failed/

记一次使用 istio 时 Service 用到 istio 保留端口导致 sidecar 启动失败的问题排查

https://imroc.cc/post/202105/deleting-namespace-from-rancher-causes-node-to-disappear/

记一次因勿删 rancher 生成的 namespace 导致集群 node 清空而瘫痪的问题排查

https://imroc.cc/post/202105/apollo-on-istio/

排查 java 应用使用 apollo 插件启动报错的问题

https://imroc.cc/post/202106/isito-init-crash/

介绍 istio 场景可能会遇到的 istio-init crash 问题原因与解决方案

https://imroc.cc/post/202009/nginx-ingress-high-concurrency/

目录 概述 内核参数调优 调大连接队列的大小 扩大源端口范围 TIME_WAIT 复用 调大最大文件句柄数 配置示例 全局配置调优 调高 keepalive 连接最大请求数 调高 keepalive 最大空闲连接数 调高单个 worker 最大连接数 配置示例 总结 参考资料 概述 Nginx Ingress Controller 基于 Nginx 实现了 Kubernetes Ingress API，Nginx 是公认的高性能网关，但如果不对其进行一些参数调优，就不能充分发挥出高性能的优势。之前我们在 Nginx Ingress on TKE 部署最佳实践 一文中讲了 Nginx Ingress 在 TKE 上部署最佳实践，涉及的部署 YAML 其实已经包含了一些性能方面的参数优化，只是没有提及，本文将继续展开介绍针对 Nginx Ingress 的一些全局配置与内核参数调优的建议，可用于支撑我们的高并发业务。

https://imroc.cc/post/202105/the-case-of-http-header/

介绍使用 istio 时 http header 被自动转换为小写导致的问题及其解决方案

https://imroc.cc/post/202006/kubernetes-app-deployment-best-practice-2/

目录 引言 如何避免单点故障？ 如何避免节点维护或升级时导致服务不可用？ 如何让服务进行平滑更新？ 健康检查怎么配才好？ 参考资料 引言 上一篇 文章我们围绕如何合理利用资源的主题做了一些最佳实践的分享，这一次我们就如何提高服务可用性的主题来展开探讨。
怎样提高我们部署服务的可用性呢？K8S 设计本身就考虑到了各种故障的可能性，并提供了一些自愈机制以提高系统的容错性，但有些情况还是可能导致较长时间不可用，拉低服务可用性的指标。本文将结合生产实践经验，为大家提供一些最佳实践来最大化的提高服务可用性。
如何避免单点故障？ K8S 的设计就是假设节点是不可靠的。节点越多，发生软硬件故障导致节点不可用的几率就越高，所以我们通常需要给服务部署多个副本，根据实际情况调整 replicas 的值，如果值为 1 就必然存在单点故障，如果大于 1 但所有副本都调度到同一个节点了，那还是有单点故障，有时候还要考虑到灾难，比如整个机房不可用。
所以我们不仅要有合理的副本数量，还需要让这些不同副本调度到不同的拓扑域(节点、可用区)，打散调度以避免单点故障，这个可以利用 Pod 反亲和性来做到，反亲和主要分强反亲和与弱反亲和两种。
先来看个强反亲和的示例，将 dns 服务强制打散调度到不同节点上:

https://imroc.cc/post/202105/grpc-not-loadbalancing/

配置问题导致 istio 将 grpc 当成普通 tcp 长连接，引发负载不均

https://imroc.cc/post/202105/locality-lb/

介绍 istio 启用地域感知不生效问题常见原因及其解决方案

https://imroc.cc/post/202105/propagating-signals-in-shell/

介绍容器通过脚本启动进程时如何传递SIGTERM信号以实现优雅终止

https://imroc.cc/post/202105/ipvs-conn-reuse-mode/

介绍在 k8s 中使用 ipvs 模式可能会踩到的连接复用内核 bug 及其解决方案

https://imroc.cc/post/202106/cert-manager-webhook-dnspod/

教你使用 cert-manager 为 dnspod 管理的域名自动签发免费证书并续期