点击联系发帖人
时间：2022-05-17 03:34
Kubernetes网络开源组件 摘要：在本章主要了解支持Kubernetes的开源第三方的网络组件，了解这其中的网络原理和工作流程，同时掌握基本的网络术语。 关键字：Docker；CentOS；版本； 1 技术术语 1.1 IPAM IP地址管理；这个IP地址管理并不是容器所特有的，传统的网络比如说DHCP其实也是一种IPAM，到了容器时代我们谈IPAM，主流的两种方法： 基于CIDR的IP地址段分配地或者精确为每一个容器分配IP。但总之一旦形成一个容器主机集群之后，上面的容器都要给它分配一个全局唯一的IP地址，这就涉及到IPAM的话题。 1.2 Overlay 在现有二层或三层网络之上再构建起来一个独立的网络，这个网络通常会有自己独立的IP地址空间、交换或者路由的实现。 1.3 IPSesc 一个点对点的一个加密通信协议，一般会用到Overlay网络的数据通道里。 1.4 vxLAN 由VMware、Cisco、RedHat等联合提出的这么一个解决方案，这个解决方案最主要是解决VLAN支持虚拟网络数量（4096）过少的问题。因为在公有云上每一个租户都有不同的VPC，4096明显不够用。就有了vxLAN，它可以支持1600万个虚拟网络，基本上公有云是够用的。 1.5 网桥Bridge 连接两个对等网络之间的网络设备，但在今天的语境里指的是Linux Bridge，就是大名鼎鼎的Docker0这个网桥。 1.6 BGP 主干网自治网络的路由协议，今天有了互联网，互联网由很多小的自治网络构成的，自治网络之间的三层路由是由BGP实现的。 1.7 SDN、Openflow 软件定义网络里面的一个术语，比如说我们经常听到的流表、控制平面，或者转发平面都是Openflow里的术语。 2 容器网络方案 2.1 隧道方案（ Overlay Networking ） 隧道方案在IaaS层的网络中应用也比较多，大家共识是随着节点规模的增长复杂度会提升，而且出了网络问题跟踪起来比较麻烦，大规模集群情况下这是需要考虑的一个点。 2.1.1 Weave 基于BGP协议的路由方案，支持很细致的ACL控制，对混合云亲和度比较高。 2.2.2 Macvlan 从逻辑和Kernel层来看隔离性和性能最优的方案，基于二层隔离，所以需要二层路由器支持，大多数云服务商不支持，所以混合云上比较难以实现。 3 Flannel容器网络 Flannel之所以可以搭建kubernets依赖的底层网络，是因为它可以实现以下两点： 它给每个node上的docker容器分配相互不想冲突的IP地址； 它能给这些IP地址之间建立一个覆盖网络，同过覆盖网络，将数据包原封不动的传递到目标容器内。 3.1 Flannel介绍 Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。 在默认的Docker配置中，每个节点上的Docker服务会分别负责所在节点容器的IP分配。这样导致的一个问题是，不同节点上容器可能获得相同的内外IP地址。并使这些容器之间能够之间通过IP地址相互找到，也就是相互ping通。 Flannel的设计目的就是为集群中的所有节点重新规划IP地址的使用规则，从而使得不同节点上的容器能够获得“同属一个内网”且”不重复的”IP地址，并让属于不同节点上的容器能够直接通过内网IP通信。 Flannel实质上是一种“覆盖网络(overlaynetwork)”，也就是将TCP数据包装在另一种网络包里面进行路由转发和通信，目前已经支持udp、vxlan、host-gw、aws-vpc、gce和alloc路由等数据转发方式，默认的节点间数据通信方式是UDP转发。 4 Calico容器网络 4.1 Calico介绍 Calico是一个纯3层的数据中心网络方案，而且无缝集成像OpenStack这种IaaS云架构，能够提供可控的VM、容器、裸机之间的IP通信。Calico不使用重叠网络比如flannel和libnetwork重叠网络驱动，它是一个纯三层的方法，使用虚拟路由代替虚拟交换，每一台虚拟路由通过BGP协议传播可达信息（路由）到剩余数据中心。 Calico在每一个计算节点利用Linux
本项目致力于提供快速部署高可用k8s集群的工具，并且也努力成为k8s实践、使用的参考书；基于二进制方式部署和利用ansible-playbook实现自动化：既提供一键安装脚本，也可以分步执行安装各个组件，同时讲解每一步主要参数配置和注意事项；二进制方式部署有助于理解系统各组件的交互原理和熟悉组件启动参数，有助于快速排查解决实际问题。
请阅读和，欢迎提和参与维护项目。
DaemonSet Pod方式运行网络插件，目前支持Calicoflannel可选
单机快速体验k8s集群的测试、开发环境--
badtobone，请备注（城市-github用户名），验证通过会加入群聊。
感谢所有为项目提交 Issues和PRs 的贡献者！
Kubenetes是一个针对容器应用，进行自动部署，弹性伸缩和管理的开源系统。主要功能是生产环境中的容器编排。
K8S是Google公司推出的，它来源于由Google公司内部使用了15年的Borg系统，集结了Borg的精华。
k8s是一个docker集群的管理工具
k8s是容器的编排工具
master节点运行时会报错
在 master 节点上执行这个命令时，预计会出现下面这个错误，该错误是可以安全忽略的（因为 master 节点上有 static pod 运行）：
在对集群中所有节点的 kubelet 进行升级之后，请执行以下命令，以确认所有节点又重新变为可用状态
如果 kubeadm upgrade 因某些原因失败并且不能回退（例如：执行过程中意外的关闭了节点实例），您可以再次运行 kubeadm upgrade，因为其具有幂等性，所以最终应该能够保证集群的实际状态就是您声明的所需状态。
您可以在使用 kubeadm upgrade 命令时带上 –force 来忽略某些启动时候的错误 参集群，使其从故障状态恢复。
由于Nginx的普及使用，在将应用迁移到K8S后，该Ingress控制器是最容易上手的控制器，而且学习成本相对较低，如果你对控制器的能力要求不高，建议使用。
不过当配置文件太多的时候，Reload是很慢的，而且虽然可用插件很多，但插件扩展能力非常弱。
Nginx Ingress是NGINX开发的官方版本，它基于NGINX Plus商业版本，NGINX控制器具有很高的稳定性，持续的向后兼容性，没有任何第三方模块，并且由于消除了Lua代码而保证了较高的速度（与官方控制器相比）。
相比官方控制器，它支持TCP/UDP的流量转发，付费版有很广泛的附加功能，主要缺点就是缺失了鉴权方式、流量调度等其他功能。
kong在之前是专注于API网关，现在已经成为了成熟的Ingress控制器，相较于官方控制器，在路由匹配规则、upstream探针、鉴权上做了提升，并且支持大量的模块插件，并且便与配置。
它具有许多有用的功能：连续更新配置（不重新启动），支持多种负载平衡算法，Web UI，指标导出，支持各种协议，REST API，Canary版本等。开箱即用的“Let's Encrypt”支持是另一个不错的功能。而且在2.0版本已经支持了TCP / SSL，金丝雀部署和流量镜像/阴影等功能，社区非常活跃。
Istio是IBM，Google和Lyft（Envoy的原始作者）的联合项目，它是一个全面的服务网格解决方案。它不仅可以管理所有传入的外部流量（作为Ingress控制器），还可以控制集群内部的所有流量。在幕后，Istio将Envoy用作每种服务的辅助代理。从本质上讲，它是一个可以执行几乎所有操作的大型处理器。其中心思想是最大程度的控制，可扩展性，安全性和透明性。
借助Istio Ingress，您可以微调流量路由，服务之间的访问授权，平衡，监控，金丝雀发布等.
HAProxy作为王牌的负载均衡器，在众多控制器中最大的优势还在负载均衡上。
它提供了“软”配置更新（无流量丢失），基于DNS的服务发现，通过API的动态配置。HAProxy还支持完全自定义配置文件模板（通过替换ConfigMap）以及在其中使用Spring Boot函数。
它具有非常强大的路由能力、灵活的插件拓展能力，在性能上表现也非常优秀。同时，它的缺点也非常明显，尽管APISIX开源后有非常多的功能，但是缺少落地案例，没有相关的文档指引大家如何使用这些功能。
二进制只是为了方便了解架构，一般公司不会使用
问这个问题主要是想试试你到底有没有工作经验
原因：是由于系统交换内存导致，关闭即可：swapoff -a，重新启动就好了。
重启后，机器仍不断打出该log。但free查看内存，发现内存有空闲。
