比如因为种种原因，nginx并不能监听在80端口，或者外部通过NAT方式将请求丢给nginx，外部地址并不是标准>我国有关IPv6体系标准的研究情况
目前，在国际上IETF是IPv6标准的主要推动者，已经制定出了多个关于IPv6技术、协议的RFC。相比而言，我国的IPv6技术标准的制定起步较晚。我国从2001年开始了IPv6标准的制定，在制定过程中，主要是从国内的实际情况出发，围绕着以下几个方面开展工作：
1．IPv6协议类标准
该方面IETF已经制定了相当数量的协议类标准。因此，我国在制定IPv6协议标准时遵循了以下的原则：以国际标准为基础，与国内的实际情况相结合制定国家或行业标准。国内的IPv6协议标准可以是对应某个IETF标准来制定，也可以是几个IETF标准的综合。具体内容包括IPv6基本协议、地址结构协议、邻居发现协议、路由协议、安全协议等几个方面。
目前已经完成的规范包括：IPv6基本协议――IPv6协议，IPv6邻居发现协议――基于IPv6的邻居发现，IPv6地址结构协议――IPv6无状态地址自动配置，IPv6路由协议――支持IPv6的边界网关协议（BGP4），支持IPv6的路由协议技术要求――开放最短路径优先协议（OSPF），IPv6路由协议测试方法――支持IPv6的边界网关协议（BGP4），IPv6路由协议测试方法――支持IPv6的开放最短路径优先协议（OSPF），IPv6路由协议――支持IPv6的中间系统到中间系统路由交换协议（IS－IS）。目前正在进行制定的标准包括：IPv6路由协议测试方法――支持IPv6的中间系统到中间系统路由交换协议（IS－IS），IPv6组播及泛播技术要求，IPv6技术要求－路径MTU发现协议，IPv6技术要求－反向邻居发现协议，IPv6技术要求－路由器重编号协议等。
2．IPv6网络的体系结构
这类的标准是国内标准化的重点之一，在网络体系结构方面的标准的内容主要包括：双栈演进机制、双栈路由器技术、双栈主机技术、IPv6隧道技术、网络地址翻译一协议翻译（NAT-PT）、IPv6DNS、IPv6演进中的路由、IPv6主机和路由器的演进机制等。对于国内的标准化工作，将从IPv6商用网的网络体系结构着手来做，结合国际标准，根据国内对IPv6商用网的实际需求，制定相应的中国标准。在这方面将会有相当数量的创新内容。
目前已经完成的规范包括：IPv6网络技术要求－地址、过渡及服务质量。正在进行制定的标准包括：面向NAT用户的IPv6隧道技术要求，基于IPv6网络的IPv4网络互联，IPv4－IPv6过渡中互连互通的技术要求，IPv6技术要求，支持IPv6的多协议标记交换（MPLS）组网技术要求。
3．网络的评估标准和测试方法
IPv6网将是下一代互联网（NGI）的核心，它不但是下一代Internet的主体网络（NGI），也是下一代电信网的主要承载网络，因而对网络的评估和测试将极为重要。传统的IPv4网络在设计之初只是为了数据传输应用，而现有的IP网络则还要承担起流媒体信息传输的重任。要完成这一目标，就需要在本质上探索和研究新的网络体系结构。在新建IPv6网络的过程中，可以参考吸收IPv4网络建设的经验和教训，在网络建设初期就应重点考虑网络的可管理性、可维护性、网络提供的端到端服务质量（QoS）和承载多业务能力，也应关心网络的生存能力和信息传送的公平性。因而，IP网络与IPv4网络相比，评估和测试要复杂和困难得多，这方面的工作目前已有的成果不多，国际上对该领域的研究也是刚刚起步，国内标准化工作可以以此为契机，加快与国际标准的接轨。
目前正在进行制定的标准包括：IPv6QoS技术要求。
4．网络设备技术要求和测试方法
IPv6网络设备可以分为两大类：一类是纯IPv6网的网络设备：路由器、主机、认证与计费设备、网络安全设备和基本的应用系统设备等；另一类是与IPv4／IPv6网络的演进有关的设备：它们包括双栈路由器、双栈主机、IPv4／IPv6的DNS、网络地址转换器（NAT）、双栈网络安全设备等。特别指出的是：IPv6网将是下一代网络（NGN）的核心及下一代电信网的主要承载网络，考虑到这一重要的因素，IPv6网络设备将与IPv4网络设备有很大的区别，而不是简单的将IPv4网络设备规范搬过来就行的，不但有大量工作要做而且将会有大量的获取基础知识产权的机会。国内IP标准研究组将投入相当大的力量，从事这方面的工作。
目前已经完成的标准包括：IPv6网络设备技术要求――支持IPv6的核心路由器，IPv6网络设备技术要求――边缘路由器，IPv6网络设备测试方法――支持IPv6的核心路由器，IPv6网络设备测试方法――支持IPv6的边缘路由器，具有IPv6路由功能的以太网交换机技术要求。目前正在进行制定的标准包括：具有IPv6路由功能的以太网交换机测试方法，支持IPv6的宽带网络接入服务器技术要求等。
5．移动通信类标准
IPv6在移动IP方面是有特色的，特别是处理实时业务上，IPv6的移动IP技术有着IPv4不可取代的优势，在第三代移动通信中，已经提出全IP解决方案，随着3G全IP解决方案的提出，IPv6已成为互联网和移动通信网的共用基本协议。MobileIPv6使互联网和移动通信网融合，可以提供无处不在和“永远在线”的连接，第三代移动通信网络将可能最早全面应用IPv6，有关的国际标准也正在迅速形成。3GPP与IETF合作制定与IPv6相关的移动通信标准。中国作为3GPP的主要参加方之一，理应有中国提出的IPv6相关的移动通信标准。
目前正在制定标准包括：IPv6技术要求――支持计算机移动部分（MobileIPv6），移动IPv6快速切换技术要求等。
6．IPv6业务和应用的标准
要支持IPv6网的商业化运作，业务和应用的开发是极为重要的工作；为了顺利完成IPv4到IPv6网的平稳演进，需十分重视原有IPv4已成熟的业务和在IPv6环境中的应用；目前与第三代通信网络有关的IPv6国际标准主要在IP多媒体领域。从标准研究的进程上看，国内这类标准的制定滞后于IPv6协议、设备方面的标准进程，但是随着国家CNGI项目的进行，IPv6业务和应用的标准的制定工作也变得越来越重要，因此这也是我国IPv6标准制定工作的下一步的工作重点。在此领域取得的成果将会直接促进在我国IPv6网络的商业化进程。
kubernetes集群中的master节点是集群的控制节点， 负责整个集群的管理和控制。执行的控制命令都是发送给master节点。 Master节点上运行的主要组件如下：
Node节点时kubernetes集群中的工作负责节点，Node上的工作负载由master分配， 当某个Node宕机时，Master会将上面的工作负载转移到其他节点上去， Node节点上运行的主要组件如下：
上图为kubernetes中所有组件一起工作时的示意图，由此我们可以得出以下几个通信流程，
根据上面节点通信的介绍我们会产生一个疑问， 这个看起来好复杂的样子。 臣妾看不懂呀。 如果想进一步了解集群中详细的工作流程请移驾 kubectl创建pod背后发生了什么 探索背后的秘密
要求结果为所有的 Kubernetes Master 服务器没有单点故障，任何一台服务器当机均不影响Kubernetes的正常工作。
为了实现没有单点故障的目标，需要为以下几个组件建立高可用方案：
etcd是Kubernetes当中唯一带状态的服务，也是高可用的难点。Kubernetes选用etcd作为它的后端数据存储仓库正是看重了其使用分布式架构，没有单点故障的特性。
虽然单节点的etcd也可以正常运行。但是推荐的部署方案均是采用3个或者5个节点组成etcd集群，供Kubernetes使用。
etcd的高可用基本有三种思路：
一是使用独立的etcd集群，使用3台或者5台服务器只运行etcd，独立维护和升级。甚至可以使用CoreOS的 update-engine 和 locksmith ，让服务器完全自主的完成升级。这个etcd集群将作为基石用于构建整个集群。 采用这项策略的主要动机是etcd集群的节点增减都需要显式的通知集群，保证etcd集群节点稳定可以更方便的用程序完成集群滚动升级，减轻维护负担。
二是在Kubernetes Master上用static pod的形式来运行etcd，并将多台Kubernetes Master上的etcd组成集群。 在这一模式下，各个服务器的etcd实例被注册进了Kubernetes当中，虽然无法直接使用 kubectl 来管理这部分实例，但是监控以及日志搜集组件均可正常工作。在这一模式运行下的etcd可管理性更强。
三是使用CoreOS提出的 self-hosted etcd方案 ，将本应在底层为Kubernetes提供服务的etcd运行在Kubernetes之上。 实现Kubernetes对自身依赖组件的管理。在这一模式下的etcd集群可以直接使用 etcd-operator 来自动化运维，最符合Kubernetes的使用习惯。
这三种思路均可以实现etcd高可用的目标，但是在选择过程中却要根据实际情况做出一些判断。简单来讲预算充足但保守的项目选方案一， 想一步到位并愿意承担一定风险的项目选方案三。折中一点选方案二。各个方案的优劣以及做选择过程中的取舍在这里就不详细展开了，对这块有疑问的朋友可以私下联系交流。
apiserver本身是一个无状态服务，要实现其高可用相对要容易一些，难点在于如何将运行在多台服务器上的apiserver用一个统一的外部入口暴露给所有Node节点。
说是难点，其实对于这种无状态服务的高可用，我们在设计业务系统的高可用方案时已经有了相当多的经验积累。需要注意的是apiserver所使用的SSL证书要包含外部入口的地址，不然Node节点无法正常访问apiserver。
apiserver的高可用也有三种基本思路：
一是使用外部负载均衡器，不管是使用公有云提供的负载均衡器服务或是在私有云中使用 LVS 或者 HaProxy 自建负载均衡器都可以归到这一类。 负载均衡器是非常成熟的方案，在这里略过不做过多介绍。如何保证负载均衡器的高可用，则是选择这一方案需要考虑的新问题。
二是在网络层做负载均衡。比如在Master节点上用 BGP 做 ECMP ，或者在Node节点上用 iptables 做NAT都可以实现。采用这一方案不需要额外的外部服务，但是对网络配置有一定的要求。
三是在Node节点上使用反向代理对多个Master做负载均衡。这一方案同样不需要依赖外部的组件，但是当Master节点有增减时，如何动态配置Node节点上的负载均衡器成为了另外一个需要解决的问题。
从目前各个集群管理工具的选择来看，这三种模式都有被使用，目前还没有明确的推荐方案产生。建议在公有云上的集群多考虑第一种模式，在私有云环境中由于维护额外的负载均衡器也是一项负担，建议考虑第二种或是第三种方案。
这两项服务是Master节点的一部分，他们的高可用相对容易，仅需要运行多份实例即可。这些实例会通过向apiserver中的 Endpoint 加锁的方式来进行leader election， 当目前拿到leader的实例无法正常工作时，别的实例会拿到锁，变为新的leader。
严格来说kube-dns并不算是Master组件的一部分，因为它是可以跑在Node节点上，并用 Service 向集群内部提供服务的。但在实际环境中， 由于默认配置只运行了一份kube-dns实例，在其升级或是所在节点当机时，会出现集群内部dns服务不可用的情况，严重时会影响到线上服务的正常运行。
为了避免故障，请将kube-dns的 replicas 值设为2或者更多，并用 anti-affinity 将他们部署在不同的Node节点上。这项 *** 作比较容易被疏忽，直到出现故障时才发现原来是kube-dns只运行了一份实例导致的故障。
上面介绍了Kubernetes Master各个组件高可用可以采用的策略。其中etcd和kube-apiserver的高可用是整个方案的重点。由于存在多种高可用方案，集群管理员应当根据集群所处环境以及其他限制条件选择适合的方案。
这种没有绝对的通用方案，需要集群建设者根据不同的现状在多个方案中做选择的情况在Kubernetes集群建设过程中频频出现， 也是整个建设过程中最有挑战的一部分。容器网络方案的选型作为Kubernetes建设过程中需要面对的另外一个大问题也属于这种情况，今后有机会再来分享这个话题。
在实际建设过程中，在完成了上述四个组件的高可用之后，最好采取实际关机检验的方式来验证高可用方案的可靠性，并根据检验的结果不断调整和优化整个方案。
此外将高可用方案与系统自动化升级方案结合在一起考虑，实现高可用下的系统自动升级，将大大减轻集群的日常运维负担，值得投入精力去研究。
虽然本篇主要在讲Kubernetes Master高可用的方案，但需要指出的是，高可用也并不是必须的，为了实现高可用所付出的代价并不低， 需要有相应的收益来平衡。对于大量的小规模集群来说，业务系统并没有实现高可用，贸然去做集群的高可用收益有限。这时采用单Master节点的方案，做好etcd的数据备份，不失为理性的选择。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）