k8s实战小技巧

实践是检验配置的唯一标准

1. 存储

主要就是etcd了,至少有两处需要etcd,apiservercalico网络插件。也没啥注意事项,保证2N+1个节点即可,小规模N=1,大规模N=2或者N=3N也是可同时挂的节点数量。

1.1. 配置

这两处可以共用一套etcd集群,也可以分别使用,calico网络插件对etcd的更新较少,小集群可以与apiserver共用,大了还是分开吧,自行取舍。

推荐开启证书双向认证,共包含1套CA以及三套证书,分别用于:

  • etcd服务端

  • etcd集群通信

  • etcd客户端

如果偷懒,可以共用证书秘钥对,只要ca相同即可。

像用于etcd集群通信的证书只能使用IP,所以必须签发携带IP信息的证书,比较麻烦。

1.2. 维护

1.2.1. 增减节点

2N+1的N不是手动配置的,而是根据成员动态调整的,所以在添加member的时候,需要注意member的可用性。

1.2.2. 迁移节点

这也是常用的运维操作,比如故障节点迁移,比如单机房变多机房等,具体步骤如下:

  1. 变更证书,支持新机器域名以及IP访问

  2. (假设满足2N+1个节点的集群)停止待迁移原节点

  3. 拷贝数据到目标节点

  4. 检查参数,集群状态设置为existing

  5. 命令修改原节点对应的member信息peer-urls为新节点endpoint

  6. 启动目标节点etcd

  7. 确认状态

1.3. 监控

  • 磁盘性能

  • 选主/切主频率

  • 网络性能

  • proposal以及本地提交性能

  • ...

1.4. 最后一点话

像这种需要满足“大多数”的分布式集群,高可用部署是个挑战。这里的高可用其实是相对的,可以是机器隔离,可以是机柜隔离,可以是机房隔离,可以是城市隔离...主要看你需要干什么,更高的可用性意味着更糟糕的性能,在于取舍。

  • 物理机,有冗余电源,UPS等可用性保证

  • 网络设备有主备或者双活

  • 应用层面也有对应的可用性保证方法

    • 基于一致性协议的,比如raft等

    • 基于vip漂来漂去的keepalived等

而现在普遍认为,跨可用区的才算真正高可用。。。应该是云宣传导致的思维定式。

凡事都得量力而行,辩证看待!

1.4.1. 举例

比如某A云只有A和B可用区,为了满足ETCD的高可用,非要使用某U云的A可用区作为第三个节点的部署位置,而A-->CB-->C都是通过VPN打通(非专线)。

想法是不错,三个用区,三实例,挂一个机房都不会影响集群状态。可是毕竟经过了公网,集群的性能完全交给了稳定性相对较差的公网。

2. 主节点

k8s的心脏,大脑,负责与etcd存储通信,负责控制与调度,主节点单独部署,不作为Master节点。

一大堆参数,添加就好了,为了方便维护,使用systemd启动,日志落地文件,滚动管理。

  • apiserver通过负载均衡暴露

  • apiserver一定要把localhost签到证书中,方便本地调用

  • controller-manager以及scheduler直连本地apiserver地址(通过负载均衡连接会影响leader-elect

  • controller-manager的参数较多,需要按照实际情况配置

    • 几台算large-size,(节点数小于large-size,切可用区unhealthy,那么驱逐速度将为0!!)

    • 多可用区部署时,不可能节点超过多少就认为可用区unhealthy

    • pod驱逐超时设置为多少?(默认5分钟)

    • 一级驱节点逐速率是多少

    • 二级驱节点逐速率是多少

3. 工作节点

真正负载所在地,涉及配置包括docker、kubelet、kube-proxy。kube-proxy基本不动,基本就是前两者的配置。

3.1. docker

容器相关的配置,版本当然越高越好啦,只要兼容CRI即可。

  • 控制台日志大小限制

  • 关闭iptables

  • 设置网桥IP,防止与其他网段冲突

  • 关闭NAT,需要出网单独配置

  • 开启live-reload功能,方便docker维护

  • 稍微加大push&pull进行并发量

3.2. kubelet

这个参数就比较多了,日志规范好,预留资源保留好,docker对应的资源管理好即可

  • 自动清理imagefs的上下限

  • 系统保留内存/CPU的量以及kube保留量

  • 日志相关

  • 节点标签