下面是我在kubernetes使用中碰到的一些问题，偶然间想起来做个总结，给新手一些建议，不当之处请批评指正
- pod内应用日志过大的问题，导致节点不可调度，资源闲置。尽量做好应用日志大小监控阈值等
- 为deployment添加反亲和性，避免同一应用多个副本调度到同一节点，尤其是coredns、应用中间件等。
- 一定要添加request和limit属性，且QoS最好是Guaranteed
- 中间件等重要核心组件不要和业务pod放在同一work节点
- 做好kubelet、kube-proxy监控，如pleg状态、节点流量等，在节点异常的情况下可以及时发现问题
- 做好节点资源预留，驱逐措施策略
- 定期升级集群，以免版本跨度变化太大，给后面升级带来困难
- ingress按需更改或添加超时、IP白名单、client_max_body、登录验证等配置
- etcd和master相关组件资源充足，以免调度延迟高、集群操作响应慢和其他一些问题
- service可以不定义selector，此时可以自定义endpoint关联，可适当用于访问外部服务。ExternalName服务类型返回CNAME记录
- 应用发布后502，nginx-ingress不会自动reload，如下图
server_name 哈希表存储桶太小，增大server-name-hash-bucket-size的值解决，可参见nginx官网 - nginx-ingress加密协议已不支持老的sslv2以下的版本，有些比较老的Android客户端只支持ssl版本。另外如果出现加密套件不匹配的情况ssl握手失败，点击这里参考官网尝试解决，相关类似问题都可以通过抓包分析处理
- 就绪探针超时时间设置要合理。探测时间太短情况下，服务器压力在某些情况下过大，导致探针检测超时，触发应用重启，应用启动消耗更多资源，使得节点负载增大，恶性循环，在我测试环境最开始ingress-controller和应用没有区分开部署，出现此情况导致各个请求响应特别的慢
- 打了taint的节点，所有没有对应tolerations的应用都不会调度到此节点，特别是NoExecute，立刻驱逐不满足容忍条件的pod，包括kube-proxy、node-export等以pod形式运行的服务，很危险，要慎重考虑
- 集群dns解析失败
kubectl logs -f -n kube-system coredns-dc8bbbcf9-2n89j E0424 14:06:54.050824 1 reflector.go:205] github.com/coredns/coredns/plugin/kubernetes/controller.go:313: Failed to list *v1.Endpoints: Unauthorized查看了俩coredns节点日志，一台正常，一台报异常，异常的pod在新加的节点上
查看calico-node日志如下
bird: Mesh_172_21_11_50: Socket error: bind: Address not available
bird: Mesh_172_21_11_51: Socket error: bind: Address not available
bird: Mesh_172_21_11_52: Socket error: bind: Address not available
bird: Mesh_172_21_11_52: Socket error: bind: Address not available
原因：安装前必须确保各节点主机名不重复 ，calico node name 由节点主机名决定，如果重复，那么重复节点在etcd中只存储一份配置，BGP 邻居也不会建立。