廊坊网站建设报价,哈尔滨网站建设咨询,招聘网站内容建设,企业建设网站的意义上一篇《 01 | 健康之路 kubernetes(k8s) 实践之路 : 开篇及概况 》我们介绍了我们的大体情况#xff0c;也算迈出了第一步。今天我们主要介绍下我们生产可用的集群架设方案。涉及了整体拓补图#xff0c;和我们采用的硬件配置#xff0c;目前存在的问题等内容。遵循上一篇提… 上一篇《 01 | 健康之路 kubernetes(k8s) 实践之路 : 开篇及概况 》我们介绍了我们的大体情况也算迈出了第一步。今天我们主要介绍下我们生产可用的集群架设方案。涉及了整体拓补图和我们采用的硬件配置目前存在的问题等内容。遵循上一篇提到的系列风格这边不涉及基础的内容这些基础的内容大家可以通过官方文档或其它渠道进行补充主要还是分享实践经验及注意点。LVSHAProxyHarborEtcdKubernetes (master、node)以上就是我们目前在生产线的整体拓补图隐去了IP除了 K8S Node块其它实例数与图中一致LVS 、HAProxy 被规划为基础层主要提供了一个高可用的7层负载均衡器。由LVS keepalived 提供一个高可用的VIP虚拟IP。这个VIP反代到后端的两台HAProxy服务器。HAProxy反代了K8S Master和Harbor服务器提供了K8S Master API和Harbor的高可用和负载均衡能力。为什么不使用Nginx这个使用nginx也完全没问题根据自己的喜好选择这边选择HAProxy的主要原因是k8s官方文档中出现了HAProxy而不是Nginx。能否不使用HAProxy直接从LVS转发到Master理论上可行我们没有试验。如果不缺两台机器推荐还是架设一层具有7层代理能力的服务。k8s apiserver、harbor、etcd都是以HTTP的方式提供的api如果有7层代理能力的服务后续会更容易维护和扩展。硬件配置用途数量CPU内存Keepalived224GBHAProxy224GBkubernetes集群主要有两种类型的节点master和node。master则是集群领导。node是工作者节点。可以看出这边主要的工作在master节点node节点根据具体需求随意增减就好了。master节点的高可用拓补官方给出了两种方案。Stacked etcd topology堆叠etcdExternal etcd topology外部etcd可以看出最主要的区别在于etcd。第一种方案是所有k8s master节点都运行一个etcd在本机组成一个etcd集群。第二种方案则是使用外部的etcd集群额外搭建etcd集群。我们采用的是第二种外部etcd拓补图如下如果采用堆叠的etcd拓补图则是这边大家可以根据具体的情况选择推荐使用第二种外部的etcd。参考来源https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/Master节点的组件apiservercontroller-managerscheduler一个master节点主要含有上面3个组件 ( 像cloud-controller-manager这边就不多做说明了正常基本不会用到 )。apiserver: 一个api服务器所有外部与k8s集群的交互都需要经过它。可水平扩展controller-manager: 执行控制器逻辑循环通过apiserver监控集群状态做出相应的处理一个master集群中只会有一个节点处于激活状态scheduler: 将pod调度到具体的节点上一个master集群中只会有一个节点处于激活状态可以看到除了apiserver外都只允许一个 实例处于激活状态类HBase运行于其它节点上的实例属于待命状态只有当激活状态的实例不可用时才会尝试将自己设为激活状态。这边牵扯到了领导选举zookeeper、consul等分布式集群系统也是需要领导选举Master高可用需要几个节点失败容忍度是多少k8s依赖etcd所以不存在数据一致性的问题把数据一致性压到了etcd上所以k8s master不需要采取投票的机制来进行选举而只需节点健康就可以成为leader。所以这边master并不要求奇数偶数也是可以的。那么master高可用至少需要2个节点失败容忍度是(n/0)1也就是只要有一个是健康的k8s master集群就属于可用状态。这边需要注意的是master依赖etcd如果etcd不可用那么master也将不可用Master组件说明: https://kubernetes.io/docs/concepts/overview/components/部署文档: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/硬件配置etcd是一个采用了raft算法的分布式键值存储系统。这不是k8s专属的是一个独立的分布式系统具体的介绍大家可以参考官网这边不多做介绍。我们采用了 static pod的方式部署了etcd集群。失败容忍度最小可用节点数(n/2)1总数健康数失败数110220321431532642743853954硬件配置官网: https://etcd.io/官方硬件建议: https://etcd.io/docs/v3.3.12/op-guide/hardware/部署文档: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/harbor是一个开源的docker镜像库系统。眼尖的人可以看出拓补图中的harbor拓补的高可用其实是存在问题的。我们目前采用的是双主模式可以发现如果复制过程中出现了问题那么就可能会造成间歇性pull镜像失败。真正推荐的做法是共享后端存储将harbor实例做成无状态的由于我们刚起步还没有搭建分布式存储系统后面当搭建了Ceph集群后会转成这种模式。如果大家现状允许可以直接采用共享存储的方式搭建harbor。至此生产可用的k8s集群已“搭建完成”。为什么打引号因为我们还没有进行测试和验证下面给出我们列出的上线前的验证清单。其中harbor由于我们采用的是双主所以目前还标记为警告状态。还有涉及的BGP相关的验证不在此次文章内容中后续会为大家说明。还有一点需要注意的是物理机的可用性如果这些虚拟机全部在一台物理机上那么还是存在“单点问题”。这边建议至少3台物理机以上。为什么需要3台物理机以上主要是考虑到了etcd的问题如果只有两台物理机部署了5个etcd节点那么部署了3个etcd的那台物理机故障了则不满足etcd失败容忍度而导致etcd集群宕机从而导致k8s集群宕机。下一篇大概会是什么内容应该会写k8s master、node的一些可选配置调优和推荐。原文链接https://www.cnblogs.com/ants/p/11273805.html.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
