① kubernetes pod设置静态IP或者IP池
Pod一般不建议设置静态IP地址，若想要实现设置静态IP，可以参考下面的方法。像亚马逊、阿里云等厂家是支持静态IP的，但如果是自己的私有云，可以参考下面的方法。这里使用的是calico网络方案，其他的网络方案，好像并不支持，更详细的操作，可以看看calico的官方文档。
IP Pool资源定义
IPPool资源yaml定义
字段说明
metadata:
spec:
blockSize说明
请在 V3.3.0 版本后使用blockSize
IPv4 26和IPv6 122的默认块大小为64个地址的块。这允许将地址按组分配给在同一主机上运行的工作负载。通过对地址进行分组，主机之间以及与其他BGP对等方之间交换的路由更少。如果主机在一个块中分配所有地址，则将为其分配一个附加块。如果没有更多可用的块，则主机可以从分配给其他主机的块中获取地址。为借用的地址添加了特定的路由，这会影响路由表的大小。
将块大小从默认值增加（例如，使用24IPv4为每个块提供256个地址）意味着每个主机更少的块，并且可能会减少路由。但是，请尝试确保池中至少有与主机一样多的块。
从默认值减小块大小（例如，使用28IPv4为每个块提供16个地址）意味着每个主机有更多块，因此可能有更多路由。如果它允许块在主机之间更公平地分布，那么这将是有益的。
关于cidr和blockSize设置
比如你新增一个IPPool,cidr设置为192.169.0.0/29，在没有设置blockSize情况下，默认是/26的blockSize，这样是不允许的，192.169.0.0/29可用地址为8个，而默认blockSize为26将会把IP段分为64块，没有足够的IP，所以是无效的，所以blockSize应该等于大于子网掩码。
新创建的IPPool，可以在原有的IPPool中某一子网，比如
nodeSelector说明
以下所有的语法，都可以使用&&或||进行组合
kubernetes设置指定IP的场景及方法：
主要通过annotations指定。
基于namespace或者每个pod指定IP池
指定静态IP地址
说明：cni.projectcalico.org/ipAddrsNoIpam：绕过IPAM分配给Pod的IPv4和/或IPv6地址的列表。任何IP冲突和路由都必须手动或由其他系统来处理。Calico仅在其IP地址属于Calico IP池内时才将路由分配到Pod。如果分配的IP地址不在Calico IP池中，则必须确保通过另一种机制来处理到该IP地址的路由。
申请浮动IP
基于node节点标签分配IP
IPPool生效优先顺序
如果将这些方法中的一种以上用于IP地址分配，则它们将具有以下优先级，其中1为最高优先级：
基于namespace指定IP池
查看当前存在的IP池
创建新的IP池
创建新的namespace，并指定IP池
创建应用测试
注意namespace设置test-ippool
为pod指定静态IP地址或地址范围
指定地址范围
创建IP地址池
创建应用测试
注意spec.template.metadata.annotations指定了使用的IPPool
Pod设置静态IP
创建应用
虽然官方说名cni.projectcalico.org/ipAddrs：后面是IPv4或IPv6列表，实际并不支持，仅可以设置一个IP地址。所以Pod副本数超过1个是不行的。
设置的IP地址必须包含在已存在的IPPool中
根据节点标签分配IP
删除或禁用已存在的IPPool
如果不禁用或删除，创建的Pod也有可能分配到其他IPPool中的地址段
禁用IPPool
删除IPPool
给节点打上标签
创建IPPool
创建应用测试
② K8S 容器之间通讯方式
首先k8s里面容器是存在于pod里面的，所以容器之间通讯，一般分为三种类型：
1. pod内部容器之间
2. pod 与 pod 容器之间
3. pod 访问service服务
这种情况下容器通讯比较简单，因为k8s pod内部容器是共享网络空间的，所以容器直接可以使用localhost访问其他容器。
k8s在启动容器的时候会先启动一个pause容器，这个容器就是实现这个功能的。
这种类型又可以分为两种情况：
1. 两个pod在一台主机上面
2. 两个pod分布在不同主机之上
针对第一种情况，就比较简单了，就是docker默认的docker网桥互连容器。
第二种情况需要更为复杂的网络模型了，k8s官方推荐的是使用flannel组建一个大二层扁平网络，pod的ip分配由flannel统一分配，通讯过程也是走flannel的网桥。
docker --daemon --bip=172.17.18.1/24
注意其中的“--bip=172.17.18.1/24”这个参数，它限制了所在节点容器获得的IP范围。
每个node上面都会创建一个flannel0虚拟网卡，用于跨node之间通讯。所以容器直接可以直接使用pod id进行通讯。
跨节点通讯时，发送端数据会从docker0路由到flannel0虚拟网卡，接收端数据会从flannel0路由到docker0，这是因为flannel会添加一个路由
发送端：
route -n
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 flannel0
172.17.13.0 0.0.0.0 255.255.255.0 U 0 0 0 docker0
接收端：
172.18.0.0 0.0.0.0 255.255.0.0 U 0 0 0 flannel0
172.17.12.0 0.0.0.0 255.255.255.0 U 0 0 0 docker0
例如现在有一个数据包要从IP为172.17.13.2的容器发到IP为172.17.12.2的容器。根据数据发送节点的路由表，它只与172.17.0.0/16匹配这条记录匹配，因此数据从docker0出来以后就被投递到了flannel0。同理在目标节点，由于投递的地址是一个容器，因此目的地址一定会落在docker0对于的172.17.12.0/24这个记录上，自然的被投递到了docker0网卡。
flannel的原理是将网络包封装在udp里面，所以发送端和接收端需要装包和解包，对性能有一定的影响。
k8s也支持其他的网络模型，比较有名的还有calico，不过我并没有使用过。
这里涉及到k8s里面一个重要的概念service。它是一个服务的抽象，通过label（k8s会根据service和pod直接的关系创建endpoint，可以通过kubectl get ep查看）关联到后端的pod容器。
Service分配的ip叫cluster ip是一个虚拟ip（相对固定，除非删除service），这个ip只能在k8s集群内部使用，如果service需要对外提供，只能使用Nodeport方式映射到主机上，使用主机的ip和端口对外提供服务。（另外还可以使用LoadBalance方式，但这种方式是在gce这样的云环境里面使用的 ）。
节点上面有个kube-proxy进程，这个进程从master apiserver获取信息，感知service和endpoint的创建，然后做两个事：
1. 为每个service 在集群中每个节点上面创建一个随机端口，任何该端口上面的连接会代理到相应的pod
2. 集群中每个节点安装iptables规则，用于clusterip + port路由到上一步定义的随机端口上面，所以集群中每个node上面都有service的转发规则：
KUBE-PORTALS-CONTAINER 从容器中通过service cluster ip和端口访问service的请求
KUBE-PORTALS-HOST 从主机中通过service cluster ip和端口访问service的请求
KUBE-NODEPORT-CONTAINER 从容器中通过service nodeport端口访问service的请求
KUBE-NODEPORT-HOST 从主机中通过service nodeport端口访问service的请求。
见下面测试环境的内容：
-A KUBE-NODEPORT-CONTAINER -p tcp -m comment --comment "smart/ccdb:port1521" -m tcp --dport 50171 -j REDIRECT --to-ports 52244
-A KUBE-NODEPORT-HOST -p tcp -m comment --comment "smart/ccdb:port1521" -m tcp --dport 50171 -j DNAT --to-destination 10.45.25.227:52244
-A KUBE-PORTALS-CONTAINER -d 10.254.120.169/32 -p tcp -m comment --comment "smart/ccdb:port1521" -m tcp --dport 1521 -j REDIRECT --to-ports 52244
-A KUBE-PORTALS-HOST -d 10.254.120.169/32 -p tcp -m comment --comment "smart/ccdb:port1521" -m tcp --dport 1521 -j DNAT --to-destination 10.45.25.227:52244
52244就是kube-proxy针对service “"smart/ccdb:port1521"” 在节点上面监听的端口。
参考：
1. http://www.open-open.com/news/view/1aa473a
2. 《kubernetes权威指南》
③ k8s网络原理-ipvs
一、背景知识
本文主要介绍k8s网络中service 的两种模式(clusterIp、nodeport)，数据是如何通过ipvs&iptables流转的。在学习上述知识的同时，还需要了解一下ipset、conntrack的相关知识。 往期回顾文章
1.1、ipset
ipset是什么？ipset其实是iptables的扩展，可以定义一些列地址的集合。拿黑名单来举例，我想让黑名单里面的ip拒绝访问网站(黑名单有很多个)，按照传统iptables做法，需要在filter表添加很多规则匹配时一条一条匹配效率很低(严重影响性能)，而有了ipset，则只用添加一条规则即可，使用hash结构效率很高。
而使用ipset命令如下
当然，ipset还支持 hash:ip，hash:ip,port,ip等多种hash key的组成，具体可以通过 ipset -h 查看。接下来说明一下 -m set 后面 src 和 dst 两个的含义。src 指来源，dst 指目标，此规则的意思是来自192.178.113.100 ip 访问本机8410端口的流量给DROP掉。
ipset使用hash结构，比iptables的链表遍历效率要高很多。ipset还有很多更加高级的玩法，本文就不在阐述了。
1.2、ipvs
lvs是什么？全称是Linux Virtual Server，是由章文嵩博士主导的开源负载均衡项目，目前已经集成到linux内核中。lvs提供了丰富的负载均衡能力，接收到用户请求后根据具体的负载均衡算法在内核态把请求转发到后端的某个server上，也就是说lvs不需要监听具体的端口。接下来我们看一下lvs的一些基本概念。
ipvs的原理如下。ipvs工作在iptables 的 input链上，VIP一般定义在DS节点上的一个虚拟ip，拿nat模式举例如下。
① : 当请求数据包到DS上最先经过iptables 的PREROUTING链，判断目标ip (VIP) 是本机的ip，于是把请求转发到INPUT链上。
② : 因为lvs工作在INPUT链上，数据到达INPUT链上后lvs会将用户请求和定义的后端服务做对比，如果是请求的后端服务，则使用某种负载均衡算法找到一个后端RIP，修改数据包的目的ip和端口为某个RIP的(DNAT转换)。
③ : 此时数据到达POSTROUTING链(不会做SNAT)，数据包的源ip 为CIP，目的ip为RIP，数据包发往RIP上。
lvs提供了三种包转发模式，如下所示
由于k8s使用的是NAT模式，接下来看下 NAT模式下的数据包流向 。如下图所示
①:请求数据包到达DS，数据包经过PREROUTING链，此时ip 包 src ip为CIP，dst ip 为VIP
②:由于请求的VIP是DS上的虚拟ip，数据包发往INPUT链。
③:数据包到INPUT链上后，ipvs发现数据包请求是定义的集群服务，于是使用定义好的负载均衡算法找到一个具体的RS节点，做DNAT，修改数据包dst ip为RIP，数据包到达POSTROUTING链，发送给RS。
④:RS收到数据包后对比dst ip 发现是自己，接收数据包做处理，处理完成后ip 数据包 src ip 为RIP，dst ip 为CIP，把数据包发给DS。
⑤:DS 接收到RS的响应包，修改src ip 为自身的VIP，dst ip 为CIP，把数据包发送给client端。
三种模式对比&优缺点
接下来在简单聊一下ipvs的负载均衡策略，简单介绍下面四种。
上面介绍完了ipvs内核态的基本原理，接下来介绍一下如何使用 ipvsadm 用户态命令来操作ipvs。说明:此次试验是在四个虚拟机上，ipvs的模式使用的nat模式，RS的网关没有指向DS的ip(没办法做到)在DS节点上手动创建SNAT命令，下文有详细介绍。创建一个vip，在ip为192.168.113.101上
为vip添加RS
添加完成RS后，查看ipvs规则，如下图所示
client端的ip地址为192.168.113.102，client端要想直接访问vip的话，需要在client端添加静态路由，添加命令如下
添加完命令后，在client端curl 10.10.0.1:8410 发现不通，此时去某个RS上抓包如下
上图抓包显示，client 直接访问的vip，而数据包的目的ip 变为了rs的ip，因此可以看出ipvs做了DNAT转换。因为做了DNAT，RS发送响应数据直接发给client，client收到RS的数据包。client给vip发的包却收到了RS的响应包(client 想我从来没有给RS发过数据)，因此client端会把此数据包丢弃。
因为ipvs没有做SNAT，接下来在DS上添加iptables规则自己实现SNAT的功能，添加完SNAT后， RS就看不到真实的CIP了 。
此时还是不通，查找资料后发现ipvs 的 conntrack 没有开，手动打开，后续文章介绍conntrack是什么，设置完成后可以愉快的访问了。
总结:通过ipvs提供的DNAT功能和负载均衡功能，很容易实现外部用户访问内网的需求。但是还要考虑高可用层面，比如主DS宕机VIP要漂移到备DS上，后端RS重启或宕机，ipvs负载均衡列表中要及时把有问题的RS剔除，这样才能真正的实现高可用。
1.3、conntrack
大家在家上网时用到的都是192.168.x.x的ip地址，这是私网ip地址。那么大家是如何能够成功的访问外网的呢？答案是路由器帮我们做了SNAT的功能，使我们发出的数据包的src ip变为路由器的公网ip，这样数据包就能在互联网上愉快的转发了。从而实现了对内网的保护。
那么问题来了，既然做了SNAT转换，那响应数据包回来以后路由器怎么知道转到哪台PC上呢？路由器可能链接了很多PC，不可能都给每一个PC转发吧。。。答案就是conntrack实现的。
接下来我拿上面ipvs的例子举例，我们手动实现了在DS上SNAT转换，在client上curl vip:8410，这时候查看DS上和client上的conntrack表如下
先从client上的连接跟踪分析起:主要看 src、dst、sport、dport这几个字段。
client发送数据包
client端发出数据包的src ip 为192.168.113.102，dst ip 为10.10.0.1 (VIP)， sport 为35562这个端口，dport为8410(VIP 定义端口)。
client端接收响应数据包
期望src ip 为vip(10.10.0.1)，dst ip 为CIP(192.168.113.102)，sport为8410，dport为35562
DS接收数据包
DS接收到src ip 为CIP(192.168.113.102)，dst ip 为vip(10.10.0.1)，sport为35562，dport为8410的数据包
DS接收响应数据包
由于在DS侧做了DNAT转换，根据负载均衡策略找到了一个RS(RIP 192.168.113.99)，同时也做了SNAT转换(判断是否是VIP和端口)，转换为DS的DIP。所以当DS收到src ip 为192.168.113.99(RIP)，dst ip 为192.168.113.101(DIP)，sport为8080，dport为35562，会根据连接跟踪表找到这个包是192.168.113.102这个client发过来的，因此把数据包在转发给192.168.113.102:35562 上。
conntrack各个字段的含义
总结:
本文只是简单的说明了一下conntrack，并没有具体说明数据流经netfilter时何时创建记录，数据存储的数据结构啥样，底层比较复杂，感兴趣的大佬可以自行研究~
二、k8s网络通信
介绍完了ipset、ipvs、conntrack，接下来进入正题，看一下ipvs模式下k8s的网络通信。kube-proxy 的主要作用是watch apiserver，当监听到pod 或service变化时，修改本地的iptables规则或ipvs规则。
2.1、clusterIp模式
clusterIp模式为一个集群内部可访问的ip，集群外部没办法访问这个ip，试验环境如下：
创建完deployment和service后，查看一下service的ip如下。
接下来看下宿主机网卡、ipvs规则、ipset规则有什么变化
查看iptables 的nat表和filter表，看一下k8s创建了哪些规则以及经过哪些链
接下来分析一下curl 10.108.113.237 数据是如何走的，只讨论在nat表和filter表的流向，因为在mangle和raw都没有规则。
1、nat表PREROUTING链
①:数据首先进入PREROUTING链，所有请求都会进入KUBE-SERVICES链。
②:进入KUBE-SERVICES后，查看对应在此链上的规则，发现请求的目的ip和port在KUBE-CLUSTER-IP 对应的ipset里面(上面已有展示)，匹配上了则跳往KUBE-MARK-MASQ链。
③:数据流向KUBE-MARK-MASQ链，主要做了mark 打标记的功能，iptables命令如下
④:之后走向KUBE-NODE-PORT链，因为没有定义nodepode 类型的service，此处先略过。 2、filter表的INPUT链
⑤:首先进入INPUT链，所有数据转向KUBE-FIREWALL链。
⑥:进入KUBE-FIREWALL链，如果发现数据包打了0x8000/0x8000，DROP掉。因为ipvs工作在INPUT链上，做完DNAT之后直接转发到POSTROUTING链上。
3、nat表POSTROUTING链
⑦:进入POSTROUTING链，所有数据转向KUBE-POSTROUTING链
⑧:进入KUBE-POSTROUTING链，对有0x4000/0x4000标记的数据包做SNAT转换，因为ipvs只有DNAT功能。
4、数据转发给flannel网卡，进行转发
⑨:flannel 根据具体的backend模式，对数据做封包等操作，然后发出去。flannel的网络模式比较复杂，之后会专门文章进行说明。
2.2、nodeport模式
要想把集群内部的服务可以让集群外部访问，可以使用nodeport模式在物理机上开一个端口，这样外部就能访问集群内部的服务了。说明:还是使用上面创建的deployment。
查看创建service的信息，发现也创建了集群内部的一个ip。
iptables规则如下
接下来看下ipset规则有什么变化，发现KUBE-NODE-PORT-TCP下的一个成员是刚才我们指定的那个nodePort的值。
接下来看一下iptables规则，nat表和filter表
1、nat表PREROUTING链
①:数据首先进入PREROUTING链，所有请求都会进入KUBE-SERVICES链。
②:ip和port匹配不上KUBE-CLUSTER-IP 的ipset，判断是访问的本地地址，进入KUBE-NODE-PORT链。
③:进入KUBE-NODE-PORT链后，判断访问端口在 KUBE-NODE-PORT-TCP ipset规则中，因此进入KUBE-MARK-MASQ链。
④:进入KUBE-MARK-MASQ链，对数据做mark标记
后续流程跟clusterIp一样，此处就不在阐述。
2.3、dns相关
k8s中的dns默认使用的是coredns，通过以下命令查看。k8s中定义的service是有域名的，访问域名要通过dns解析，此时coredns就发挥它的作用了。
上面的试验时我们创建了一个my-service 的nodePort的service，此时查看一下此域名对应的ip，如下图所示，域名解析出来的ip与service对应的ip相同，大功告成。
参考:
以上相关内容介绍了k8s service ipvs的相关实现，如有错误欢迎指出~
④ k8s 网络基础
author：sufei
说明：本文主要记录在学习k8s网络方面的相关知识
Linux在内核网络栈中引入网络命名空间，将 独立的网络协议栈隔离 到不同的命令空间中，彼此间无法通信；
1、Linux操作系统，解析和封装网络包是通过一个网络协议栈完成，下层为上层服务，这个 协议栈中即包括如软件也包括硬件网络设 备。网络命名空间就是以软件方式隔离出单独的网络栈信息；
2、不同network namespace的软硬件资源相互不可见，好像处在物理隔离的不同物理机上一样，彼此隔离；
3、不同的网络命名空间会有自己独立的网卡、路由表、ARP 表、iptables 等和网络相关的资源
4、实验：可以借助 ip netns 命令来完成对 Network Namespace 的各种操作，如：
问题 ：什么是转移设备？
可以在不同的 Network Namespace 之间转移设备（如veth）。由于一个设备只能属于一个 Network Namespace ，所以转移后在这个 Network Namespace 内就看不到这个设备了。 veth设备属于可转移设备 ，而很多其它设备（如lo、bridge等）是不可以转移的。
veth pair 全称是 Virtual Ethernet Pair，是一个成对的端口，所有从这对端口一 端进入的数据包都将从另一端出来，反之也是一样。而veth pair就是为了在不同的 Network Namespace 直接进行通信，利用它可以直接将两个 Network Namespace 连接起来。
实验
veth pair打破了 Network Namespace 的限制，实现了不同 Network Namespace 之间的通信。但veth pair有一个明显的缺陷，就是只能实现两个网络接口之间的通信。如果我们想实现多个网络接口之间的通信，就可以使用下面介绍的网桥（Bridge）技术（ 类似于物理交换机 ）。
简单来说，网桥就是把一台机器上的若干个网络接口“连接”起来。其结果是，其中一个网口收到的报文会被复制给其他网口并发送出去。以使得网口之间的报文能够互相转发。
网桥是一个二层网络设备，通过网桥可以将linux支持的不同的端口连接起来,并实现类似交换机那样的多对多的通信。
实验：
Netfilter负责在内核中执行各种挂接的规则(过滤、修改、丢弃等)，运行在内核 模式中；Iptables模式是在用户模式下运行的进程，负责协助维护内核中Netfilter的各种规则表；通过二者的配合来实现整个Linux网络协议栈中灵活的数据包处理机制。
iptables/netfilter(简称iptables)组成了Linux平台下的包过滤防火墙，可以完成封包过滤、封包重定向和网络地址转换（NAT）等功能。这部分主要了解两部分知识：
应用层不管是要发送还是接收网络消息，都需要通过linux内核提供的一系列关卡。每个”关卡“担负着不同的工作。这里的”关卡“被称为”链“。如下图：
Docker启动一个容器时会根据Docker网桥的网段分配给容器一个IP地址，称为Container-IP，同时Docker网桥是每个容器的默认网关(如上面的172.17.0.1)。因为在同一宿主机内的容器都接入同一个网桥，这样容器之间就能够通过容器的Container-IP直接通信。
Docker网桥是宿主机虚拟出来的，并不是真实存在的网络设备，外部网络是无法寻址到的，这也意味着外部网络无法通过直接Container-IP访问到容器。如果容器希望外部访问能够访问到，可以通过映射容器端口到宿主主机（端口映射），即docker run创建容器时候通过 -p 或 -P 参数来启用，访问容器的时候就通过[宿主机IP]:[容器端口]访问容器。
下面具体来说说docker容器的几种网络模式，以便后续学习k8s网络。
在host模式下（ –net=host），容器不会去建立新的网络命名空间，而直接使用宿主机的网络设备以及网络协议栈。这样自然不会虚拟出自己的网卡，配置自己的IP等。其特点如下：
这个模式就是在创建容器时，指定网络（–net=container:NAME_or_ID）与之前容器在同一个网络命名空间中，而不是和宿主机共享（这也就是k8s中pod内各容器的一种网络模式）。下面说明几点：
none模式(–net=none)Docker容器拥有自己的Network Namespace，但是，并不为Docker容器进行任何网络配置。也就是说，这个Docker容器没有网卡、IP、路由等信息。需要我们自己为Docker容器添加网卡、配置IP等。
bridge模式是docker容器的默认模式，当Docker进程启动时，会在主机上创建一个名为docker0的虚拟网桥，此主机上启动的Docker容器在bridge模式下会连接到这个虚拟网桥上，并由网桥自动分配ip。虚拟网桥的工作方式和物理交换机类似，这样主机上的所有容器就通过交换机连在了一个二层网络中。
下面说明这个模式下的工作方式：
首先我们来看看k8s想要一个什么样的网络，也就是k8s网络设计的要求，具体如下：
下面简单从几中不同的通信要求来看看k8s网络实现。
在 Kubernetes 的世界里，IP 是以 Pod 为单位进行分配的。一个 Pod 内部的所有容器共享一个网络堆栈。实际上就是docker container网络模式。可以直接通过本地localhost进行网络访问。这个模式在mysql容器化中就是agent容器与mysql容器的网络通信方式。
Pod1和Pod2都是通信veth pair连接到同一个docker0网桥上，它们的IP地址都是从docker0网段上动态获取的，它们和网桥本身的IP是同一个网段的。可以通过docker0作为交换机进行通信，也就是采用的docker bridge网络模式进行通信。
由于在同一个网桥docker0上即可以保证分配的pod IP不会冲突，且可以相互通信，而如果需要跨Node物理节点，则无法通过docker网络直接满足要求了，那这些要求具体有哪些呢？
解决方案
方法一：k8s中通过在etcd中记录正在运行中pod的IP分配信息，这样我们就可以满足Pod IP与Node IP之间映射关系的记录；
方法二：可以在etcd中规划配置好所有主机docker0网桥的子网范围，从而满足Pod IP不冲突的要求；如：
方法三：要实现Pod跨Node通信，以k8s默认网络Flannel为例，就是采用overlay（覆盖网络）实现。具体下面说明：
问题：什么是覆盖网络？
覆盖网络就是应用层网络，是指建立在另一个网络上的网络。怎么理解呢？简单理解就是将TCP数据包装在另一种网络包里面进行路由转发和通信，另一种网络包目前可以是UDP、VxLAN、AWS VPC和GCE路由等数据转发方式。默认以UDP为例来说明flannel工作方式。
下面看看具体实现
问题 ：为保证各node内docker容器分配的ip地址不冲突，每个节点上的Docker会使用不同的IP地址段？如何实现的呢？
问题 ：为什么在发送节点上的数据会从docker0路由到flannel0虚拟网卡，在目的节点会从flannel0路由到docker0虚拟网卡？
⑤ 超全K8s集群构建指南，建议收藏
1. 什么是kubernetes
Kubernetes(k8s)是Google开源的容器集群管理系统（谷歌内部:Borg）。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。
2. kubernetes核心组件说明
Kubernetes 集群中主要存在两种类型的节点，分别是 master 节点 ，以及 minion 节点 。
Minion 节点是实际运行 Docker 容器的节点，负责和节点上运行的 Docker 进行交互，并且提供了代理功能。
Master 节点负责对外提供一系列管理集群的 API 接口，并且通过和 Minion 节点交互来实现对集群的操作管理。
apiserver ：用户和 kubernetes 集群交互的入口，封装了核心对象的增删改查操作，提供了 RESTFul 风格的 API 接口，通过 etcd 来实现持久化并维护对象的一致性。
scheler ：负责集群资源的调度和管理，例如当有 pod 异常退出需要重新分配机器时，scheler 通过一定的调度算法从而找到最合适的节点。
controller-manager ：主要是用于保证 replicationController 定义的复制数量和实际运行的 pod 数量一致，另外还保证了从 service 到 pod 的映射关系总是最新的。
kubelet ：运行在 minion 节点，负责和节点上的 Docker 交互，例如启停容器，监控运行状态等。
proxy ：运行在 minion 节点，负责为 pod 提供代理功能，会定期从 etcd 获取 service 信息，并根据 service 信息通过修改 iptables 来实现流量转发（最初的版本是直接通过程序提供转发功能，效率较低。），将流量转发到要访问的 pod 所在的节点上去。
etcd ：key-value键值存储数据库，用来存储kubernetes的信息的。
flannel ：Flannel 是 CoreOS 团队针对 Kubernetes 设计的一个覆盖网络（Overlay Network）工具，需要另外下载部署。
我们知道当我们启动 Docker 后会有一个用于和容器进行交互的 IP 地址，如果不去管理的话可能这个 IP 地址在各个机器上是一样的，并且仅限于在本机上进行通信，无法访问到其他机器上的 Docker 容器。
Flannel 的目的就是为集群中的所有节点重新规划 IP 地址的使用规则，从而使得不同节点上的容器能够获得同属一个内网且不重复的 IP 地址，并让属于不同节点上的容器能够直接通过内网 IP 通信。
3. Kubernetes的核心概念
Pod
运行于Node节点上，若干相关容器的组合。Pod内包含的容器运行在同一宿主机上，使用相同的网络命名空间、IP地址和端口，能够通过localhost进行通。
Pod是Kurbernetes进行创建、调度和管理的最小单位，它提供了比容器更高层次的抽象，使得部署和管理更加灵活。一个Pod可以包含一个容器或者多个相关容器。
Replication Controller
Replication Controller用来管理Pod的副本，保证集群中存在指定数量的Pod副本。
集群中副本的数量大于指定数量，则会停止指定数量之外的多余容器数量，反之，则会启动少于指定数量个数的容器，保证数量不变。
Replication Controller是实现弹性伸缩、动态扩容和滚动升级的核心。
Service
Service定义了Pod的逻辑集合和访问该集合的策略，是真实服务的抽象。
Service提供了一个统一的服务访问入口以及服务代理和发现机制，用户不需要了解后台Pod是如何运行。
Label
Kubernetes中的任意API对象都是通过Label进行标识，Label的实质是一系列的K/V键值对。Label是Replication Controller和Service运行的基础，二者通过Label来进行关联Node上运行的Pod。
Node
Node是Kubernetes集群架构中运行Pod的服务节点（或agent）。
Node是Kubernetes集群操作的单元，用来承载被分配Pod的运行，是Pod运行的宿主机。
4. 前置条件设置
三台Centos7系统的虚拟机（1个master+2个node）,三台机器上的防火墙，SELINUX全部关掉。我的实验坏境可以上网，默认的YUM源就可以用。
5. 部署规划
192.168.10.1 # master节点(etcd,kubernetes-master)
192.168.10.2 # node1节点(etcd,kubernetes-node,docker,flannel)
192.168.10.3 # node2节点(etcd,kubernetes-node,docker,flannel)
6. 开始安装
step1：在master上安装
yum install kubernetes-master etcd flannel -y
step2：在node上安装
yum install kubernetes-node etcd flannel -y
step3：etcd集群配置
在master节点上编辑etcd配置文件
在node1节点上编辑etcd配置文件
在node2节点上编辑etcd配置文件
到此etcd集群就部署完了，然后每个节点上启动
systemctl start etcd
step4：验证
step6：启动Master上的三个服务
step7：kubernetes node安装
node2 节点重复上述操作
step8：分别启动kubernetes node服务
7. 网络配置
因为kubernetes集群中网络部分是插件形式安装的，我们这里选用flannel
上述安装步骤已经install 了
为flannel创建分配的网络
8. 执行kubectl 命令检查
在master上执行下面，检查kubernetes的状态
9. 常用排错命令如下