夯实基础篇--k8s网络理解

0 整体概括

k8s四层网络抽象：

每一层都建立在上一层网络之上

1 pod网络

01 同一节点上的pod网络

eth0:节点上的网卡，支持机器的流量出入，也是用来支持各节点之间寻址和网络互通
docker0：虚拟网桥，简单理解为虚拟交换机，用来支持同一节点上pod之间进行寻址和网络互通的设备
veth0：pod自身的虚拟网卡，支持pod内不同容器之间进行网络互通的一个设备。pause容器唯一的作用就是用来创建veth0的网络接口

veth0的IP是由docker0这个虚拟网桥来分配的

02 不同节点之间的pod通信

1. 路由方案
   没听懂，依赖于底层网络设备

2. 覆盖网络方案
   
   flannel网络插件

03 CNI介绍

(Container Network Interface)
容器网络接口
与kubelet相联系

2 service网络（ClusterIP–virtual IP:VIP）

有了Pod网络，K8s集群内的所有Pods在逻辑上都可以看作在一个平面网络内，可以正常IP寻址和互通。但是Pod仅仅是K8s云平台中的虚拟机抽象，最终，我们需要在K8s集群中运行的是应用或者说是服务(Service)，而一个Service背后一般由多个Pods组成集群，这时候就引入了服务发现(Service Discovery)和负载均衡(Load Balancing)等问题，这就是第2层Service网络要解决的问题

1. 服务发现(Service Discovery)： Client Pod如何发现定位Account-App集群中Pod的IP？Account-Service提供统一的ClusterIP来解决服务发现问题，Client只需通过ClusterIP就可以访问Account-App的Pod集群，不需要关心集群中的具体Pod数量和PodIP，即使是PodIP发生变化也会被ClusterIP所屏蔽。注意，这里的ClusterIP实际是个虚拟IP，也称Virtual IP(VIP)。
2. 负载均衡(Load Balancing)：Client Pod如何以某种负载均衡策略去访问Account-App集群中的不同Pod实例？以实现负载分摊和HA高可用。

什么是负载均衡（SLB）？

互联网早期，业务流量比较小并且业务逻辑比较简单，单台服务器便可以满足基本的需求；但随着互联网的发展，业务流量越来越大并且业务逻辑也越来越复杂，单台机器的性能问题以及单点问题凸显了出来，因此需要多台机器来进行性能的水平扩展以及避免单点故障。但是要如何将不同的用户的流量分发到不同的服务器上面呢？负载均衡！

3 外部接入网络（NodePort&LoadBalancer&Ingress）

有了Service网络，K8s集群内的应用可以通过服务名/ClusterIP进行统一寻址和访问，而不需要关心应用集群中到底有多少个Pods，Pod的IP是什么，会不会变化，以及如何以负载均衡方式去访问等问题。但是，K8s的Service网络只是一个集群内部网络，集群外部是无法直接访问的。而我们发布的应用，有些是需要暴露出去，要让外网甚至公网能够访问的，这样才能对外输出业务价值。

01 NodePort

NodePort是K8s将内部服务对外暴露的基础，后面的LoadBalancer底层有赖于NodePort。

通过Kube-Proxy在节点上暴露一个监听端口，将K8s内部服务通过Kube-Proxy暴露出去的方式，术语就叫NodePort(顾名思义，端口暴露在节点上)

02 LoadBalancer

既然是集群，就会涉及负载均衡问题，谁负责对这个服务的负载均衡访问？答案是需要引入负载均衡器(Load Balancer)

假设我们有一套阿里云K8s环境，要将K8s内部的一个服务通过LoadBalancer方式暴露出去，可以将服务发布(Kind: Service)的type设定为LoadBalancer。服务发布后，阿里云K8s不仅会自动创建服务的NodePort端口转发，同时会自动帮我们申请一个SLB，有独立公网IP，并且阿里云K8s会帮我们自动把SLB映射到后台K8s集群的对应NodePort上。这样，通过SLB的公网IP，我们就可以访问到K8s内部服务，阿里云SLB负载均衡器会在背后做负载均衡。

03 Ingress

有了前面的NodePort + LoadBalancer，将K8s内部服务暴露到外网甚至公网的需求就已经实现了，那么为啥还要引入Ingress这样一个概念呢？它起什么作用？

7层反向代理

有了这个Ingress Service，我们可以做到只需购买一个LB+IP，就可以通过Ingress将内部多个(甚至全部)服务暴露出去，Ingress会帮忙做代理转发。

我有个疑问？

现在三台服务器的网段都是相同的，是必须的吗？
因为CNI插件不就是用来解决不同网段的节点之间的通信问题吗？
我目前还不是很清楚

2021.12.2我的理解：是必须的，网段相同只能保证这两台服务器之间可以通信，里边运行的pod由于docker网卡IP网段的不同，仍然无法通信

我来总结一下

node节点网络

首先，最底层就是要保证两台服务器（node）在同一个网段，以保证node之间的网络互通

pod网络

1. 就是保证单个node内各个容器之间网络互通，这个是由虚拟网桥docker0分配的同一网段的虚拟IP来实现的。
2. 要保证多个node之间各个容器之间也要网络互通，采用的方法是安装CNI插件（flannel）来覆盖网络，即创建一个新的共同的虚拟网络，以此实现。

service网络

然后，由于每个pod都有自己的IP，况且一个服务通常是由多个pod组成，因此需要一个统一的虚拟IP进行访问，这是通过创建一个service来实现，并且可同时实现负载均衡。
相当于，统一了所有pod的IP

外部接入网络

最后，需要外部接入网络来实现公网访问。

1. NodePort
   通过kube-proxy在每个节点上暴露一个相同监听端口，以供外部访问
   但无法实现负载均衡
2. LoadBalancer
   本质上就是NodePort+一个负载均衡器来实现。会自动创建SLB公网IP并自动映射到NodePort上，实现只要通过公网IP便可以访问。
   相当于，统一了所有node的IP
3. Ingress
   有了Ingress Service，我们可以做到只需购买一个LB+IP，就可以通过Ingress将内部多个(甚至全部)服务暴露出去，Ingress会帮忙做代理转发。
   本质上，是为了减少开支。