05、Pod网络

4.1 Pod网络

在K8s集群中，多个节点上的Pod相互通信，要通过网络插件来完成，比如Calico网络插件。

使用kubeadm初始化K8s集群时，有指定一个参数 --pod-network-cidr=10.18.0.0/16 它是用来定义Pod的网段。

而我们在配置Calico的时候，同样也定义了一个CALICO_IPV4POOL_CIDR的参数，它的值同样也是Pod的网段。

容器网络尤其是在跨主机容器间的网络是非常复杂的。目前主流的容器网络模型主要有Docker公司提出的Container Network Model（CNM）模型和CoreOS公司提出的Container Network Interface（CNI）模型，而Kubernetes采用了由CoreOS公司提出的CNI模型。

全称 Container Network Interface 即容器网络的 API 接口

CNI本身并不能提供网络服务，他只是定义了对容器网络进行操作和配置的规范。

CNI 仅关注创建容器时分配网络资源，和在销毁容器时删除网络资源，这使得CNI 规范非常轻巧、易于实现，得到了广泛的支持。

而真正实现和落地这些规范的是CNI插件。常见的插件包括Calico、flannel、Terway、Weave Net 以及 Contiv。

K8s如何使用CNI插件

K8s通过 CNI 配置文件来决定使用什么 CNI

基本使用方法为：

首先在每个节点上配置 CNI 配置文件（/etc/cni/net.d/xxnet.conf）

其中xxnet.conf 是某一个网络配置文件的名称

安装CNI 配置文件中所对应的二进制插件
在这个节点上创建Pod之后，kubelet就会根据CNI 配置文件执行前两步所安装的 CNI 插件

创建流程如下如所示：

1722241263441

在集群里面创建一个Pod的时候，首先会通过apiserver将Pod的配置写入

apiserver的一些管控组件（比如Scheduler）会调度到某个具体的节点上去

kubelet监听到这个Pod的创建之后，会在本地进行一些创建的操作

当执行到创建网络这一步骤时，它首先会读取刚才我们所说的配置目录中的配置文件，配置文件里面会声明所使用的是哪一个插件，然后去执行具体的CNI插件的二进制文件，再由CNI插件进入Pod的网络空间去配置Pod的网络

配置完成之后，kubelet也就完成了整个Pod的创建过程，这个Pod就在线了

基于Calico的Pod网络

1722308567452

1722308574296

4.2 Service网络

在介绍Service这个api资源对象时，我们已经汇总过Service的几个type：

ClusterIP、NodePort、LoadeBalancer，除了这三个还有其它的类型，在本章

节我们暂且不去讨论。

这三种类型的Service，LoadBalancer依赖NodePort，而NodePort通常要和

ClusterIP一起使用，如果在Service的yaml文件里定义type为LoadBalancer，

则它会自动创建NodePort，而NodePort也会自动创建ClusterIP。

1722308673528

下面展示一下从Pod到Service的网络变化情况：

单个Pod之间通信

单个Pod和Pod之间通信只能通过Pod的IP和Port来通信，如下图

1722308799486

多个Pod

当引入了Deployment，并为Pod设置多个副本时，那么提供某一个服务（如

Nginx服务）的Pod就不止一个了，此时即使知道了这些Pod的IP，那访问起来

也并不方便。所以，这里需要有一个统一入口，其它Pod通过这个统一入口去请

求该服务（Nginx）对应的所有Pod。这时就有了Service这个资源对象，它主

要作用就是用来提供统一入口，也就是说只需要一个IP就能访问所有的Pod，而

这个入口IP就是ClusterIP，也就是Service的IP。

1722310063119

外部资源访问内部Pod

有了Service，的确可以很方便为内部的Pod提供入口，但是在集群外面访问这个内部的资源就没办法了。

于是，就有了这个NodePort，使用service的NodePort类型，可以将Service的ClusterIP对应的Port映射到每一个Node的IP上，映射出去的Port范围30000~32767

1722310240332

借助公有云的负载均衡器

使用这个NodePort并不方便，毕竟它是带着一个长长的端口号，而且还有一个非常尴尬的问题，就是访问时还得带着Node的IP，如果这个Node挂掉，那么就无法访问此资源，虽然可以通过另外一个Node去访问，但这样太麻烦了

所以，此时的解决方案是：借助三方的负载均衡器，将请求分发到所有的Node上，其底层还是NodePort。

1722318790835

总结：

Service为内部Pod的统一入口，内部资源之间可以通过最简单的ClusterIP进行通信，而外部资源访问需要借助NodePort的形式，但是带着长长端口不方便，于是有衍生了LoadBalancer的形式，这种形式需要借助三方的负载均衡器，将请求分发到每一个NodePort上。

4.3 网络插件Calico

参考：https://www.cnblogs.com/goldsunshine/p/10701242.html

Calico是什么

Calico是一个用于容器、虚拟机和主机的开源网络安全解决方案

它是一个纯三层（L3）解决方案，利用BGP（BorderGatewayProtocol）协议为容器或虚拟机提供IP地址，并提供网络安全功能，包括网络策略和加密

Calico通过将网络策略应用于标签和选择器，提供了一种简单而强大的方法来保护容器或虚拟机之间的通信，并限制容器或虚拟机可以访问的网络资源。

它还支持基于Kubernetes和OpenStack等平台的网络自动化和集成。

Calico的另一个重要特点是其可扩展性。它使用了基于BGP的路由技术，这使得他能够轻松地扩展到非常大规模的网络中，而不会降低性能。

由于Calico是一种纯三层的方案，因此可以避免与二层方案相关的数据包封装的操作，中间没有任何的NAT，没有任何的overlay，所以它的转发效率是所有方案中最高的，因为它的包直接走原生TCP/IP的协议栈，它的隔离也因为这个栈而变得好做。因为TCP/IP的协议栈提供了一整套的防火墙的规则，所以它可以通过IPTABLES的规则达到比较复杂的隔离逻辑。

Calico架构

1722328724275

组件介绍：

Felix：Calico Agent ，跑在K8s集群中的每台节点上，主要负责管理和维护该节点上的网络和安全策略，如网络接口管理和监听、路由、ARP管理、ACL管理和同步、状态上报等；
ETCD：分布式键值存储，用来存储网络元数据、安全策略以及节点的状态信息，确保Calico网络状态的一致性和准确性，可以和K8s的etcd合用；
BGP Route Reflector （BIRD）：在大型网络规模中，如果仅仅使用BGP Client 形成mesh 全网互联的方案就会导致规模限制，因为所有节点之间两两互联，需要N^2 个连接，为了解决这个规模问题，可以采用BGP的Route Reflector 的方法，使所有BGP Clinet 仅与特定RR节点互联并做路由同步，从而大大减少连接数大规模部署时使用。

关键点：

Felix会定期查询Etcd数据库，从而获取到IP变化信息，比如说用户在这台机器上创建了一个容器，增加了一个IP等。当它发现数据变更后，比如用户创建pod后，Felix负责将其网卡、IP、MAC都设置好，然后在内核的路由表里面写一条，注明这个IP应该到这张网卡。同样如果用户制定了隔离策略，Felix同样会将该策略创建到ACL中，以实现隔离。
BIRD是一个标准的路由程序，它会从内核里面获取哪一些IP的路由发生了变化，然后通过标准BGP的路由协议扩散到整个其他的宿主机上，让外界都知道这个IP在这里，你们路由的时候得到这里来。

Calico三种网络工作模式

IPIP模式说明

BGP模式说明

4.4 网络插件Flannel

Flannel简介

flannel也是一个CNI插件，它的功能和Calico一样，为K8s集群中的Pod提供网络支撑。

Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务

Flannel的设计目的就是为集群中的所有节点重新规划IP地址的使用规则，从而使得不同节点上的Pod能够获得“同属一个内网”且“不重复的”IP地址，并让属于不同节点上的Pod能够直接通过内网IP通信。

简单来说，它的功能是让集群中不同节点主机创建的Pod都具有全集群唯一的虚拟IP地址。

Flannel实质上是一种“覆盖网络（overlaynetwork）”，也就是将TCP数据包装在另一个网络包里面进行路由转发和通信，目前已经支持udp、vxlan、host-gw、aws-vpc、gce和alloc路由等数据转发方式。

核心关键点：

网络配置：Flannel配置存储在etcd中。Flannel节点会从etcd中读取这些配置信息，并根据配置创建和管理网络
子网分配：Flannel会为每个节点分配一个不重叠的子网，以便在节点上运行的Pod可以使用该子网内的IP。这样，集群内的每个Pod都将具有唯一的IP地址。
数据包封装与转发：Flannel使用数据包封装技术（例如VXLAN \ UDP 等）将Pod之间的通信封装为跨节点的通信。当一个节点上的Pod需要与另一个节点上的Pod通信时，源节点上的Flannel程序会将数据包封装，添加上目标子网信息，并将封装后的数据包发送到目标节点。目标节点上的Flannel程序会解封装数据包，并将其转发给目标Pod。
兼容性：Flannel可以与K8s中的其他网络插件（如 Calico）一起使用，以实现更复杂的网络功能。这使得Flannel可以很好的适应不同的集群环境和需求。

工作模式：

UDP模式：使用设备flannel.0进行封包解包，不是内核原生支持，频繁地内核态用户态切换，性能非常差，目前官方不建议使用。
VxLAN 模式：使用flannel.1 进行封包解包，内核原生支持，性能较强；
host-gw模式：无需 flannel.1 这样的中间设备，直接宿主机当作子网的下一跳地址，性能最强；

flannel架构

Flannel在底层实现上要比Calico简单

flannel最主要的两个组件是flanneld和flannel.1

flanneld：控制面，运行在用户态，负责宿主机分配子网，并监听Etcd，维护宿主机的FDB/ARP跟路由表
flannel.1：数据面，运行在内核态，作为VTEP，VXLAN 数据包的封包跟解包

1722331940217

VxLAN模式：

VxLAN的设计思想是：在现有的三层网络之上，“覆盖”一层虚拟的、由内核VxLAN模块负责维护的二层网络，使得连接在这个VxLAN二层网络上的“主机”（虚拟机或容器都可以），可以像在同一个局域网（LAN）里那样自由通信。为了能够在二层网络上打通隧道，VxLAN会在宿主机上设置一个特殊的网络设备作为“隧道”的两端，叫做VTEP：VxLAN Tunnel End Point（虚拟隧道端点）

VxLAN是Flannel默认和推荐的模式。当我们使用默认配置安装Flannel时，它会为每个节点分配一个24位子网，并在每个节点上创建两张虚拟机网卡：cni0 和 flannel.1

cni0 是一个网桥设备，节点上所有的Pod都通过veth pari 的形式与cni0 相连
flannel.1 是一个VXLAN类型的设备，充当VTEP的角色，实现对VXLAN报文的封包解包。

同一个节点内的Pod之间通信，只需要通过 cni0 即可，而我们要讨论的重点是跨节点通信。

假设两个节点node1 和 node2 ，两个节点上分别有两个Pod：PodA 、 PodB

现在node1上的PodA要和node2上的PodB通信，通信过程如下：

1722412809862

1722412815508

大致描述下过程：

发送端：在PodA中发起 ping 10.244.1.21 ， ICMP报文经过cni0网桥后，交由 flannel.1 设备处理。flannel.1 设备是一个VXLAN类型的设备，负责VXLAN封包解包。因此，在发送端，flannel.1 将原始L2报文封装成VXLAN UDP 报文，然后从 eth0 发送。
接收端：node2收到UDP报文，发现是一个VXLAN类型报文，交由flannel.1 进行解包。根据解包后得到原始报文中的目的IP，将原始报文经由 cni0 网桥发送给PodB

路由：

Flanneld 从 etcd 中可以获取所有节点的子网情况，以此为依据为各节点配置路由，将属于非本节点的子网IP都路由到 flannel.1 处理，本节点的子网路由到 cni0 网桥处理。

ip route
[root@Node1 ~]# ip route
10.244.0.0/24 dev cni0 proto kernel scope link src 10.244.0.1
# Node1子网为10.224.0.0/24， 本机PodIP都交由cni0处理
10.244.1.0/24 via 10.244.1.0 dev flannel.1 onlink # Node2子网
为10.224.1.0/24，Node2的PodID都交由flannel.1处理

host-gw网络模式

跟VxLAN不同，host-gw模式下没有flannel.1 虚拟网卡，无需建立VxLAN隧道。但它有个缺点，必须要保证各node在同一个网段。

1722413660207

1722413663894

Flanneld 模式的工作原理，就是将每个Flannel子网的下一跳，设置成了该子网对应的宿主机的 IP 地址，也就是说，宿主机（host）充当了这条容器通信路径的“网关”（Gateway），这正是 host-gw 的含义。所有的子网和主机的信息，都保存在 Etcd 中，flanneld 只需要 watch 这些数据的变化，实时更新路由表就行了。核心是IP包在封装成桢的时候，使用路由表的“下一跳”设置上的MAC地址，这样可以经过二层网络到达目的宿主机

[root@Node1 ~]# ip r
...
10.244.0.0/24 dev cni0 proto kernel scope link src 10.244.0.1
10.244.1.0/24 via 192.168.50.3 dev eth0
# Node2子网的下一跳地址指向Node2的public ip。
...

由于没有封包解包带来的消耗，host-gw是性能最好的。不过一般在云环境下，都不支持使用host-gw的模式，在私有化部署的场景下，可以考虑。

4.5 Kubernetes里的DNS

K8s集群里面有一个DNS服务：

kubectl get svc -n kube-system | grep dns

1722413973807

测试：

## 在aminglinux01上安装bind-utils,目的是安装dig命令
yum install -y bind-utils
## 解析外网域名
dig @10.15.0.10 www.baidu.com

1722414011864

## 解析内部域名
dig @10.15.0.10 ngx-svc.default.svc.cluster.local

1722414050370

说明： ngx-svc为service name，service完整域名为

service.namespace.svc.cluster.local

还可以解析Pod，Pod的域名有点特殊，格式为<pod-ip>.<namespace>.pod.<clusterdomain>，例如10-18-37-66.default.pod.cluster.local

1722414113269

## 对应的Pod为coredns：
kubectl get po coredns -n kube-system

1722414137601

查看defalut命名空间Pod里的/etc/resolv.conf

1722414147710

查看aming命名空间Pod里的/etc/resolv.conf

1722414158642

解释：

nameserver: 定义DNS服务器的IP，其实就是kube-dns那个service的IP。
search: 定义域名的查找后缀规则，查找配置越多，说明域名解析查找匹配次数越多。集群匹配有 default.svc.cluster.local、svc.cluster.local、cluster.local 3个后缀，最多进行8次查询 (IPV4和IPV6查询各四次) 才能得到正确解析结果。不同命名空间，这个参数的值也不同。
option: 定义域名解析配置文件选项，支持多个KV值。例如该参数设置成ndots:5，说明如果访问的域名字符串内的点字符数量超过ndots值，则认为是完整域名，并被直接解析；如果不足ndots值，则追加search段后缀再进行查询。

DNS配置

## 可以通过查看coredns的configmap来获取DNS的配置信息：
 kubectl describe cm coredns -n kube-system

1722823089675

说明：

errors：错误信息到标准输出
health：CoreDNS自身健康状态报告，默认监听端口8080，一般用来做健康检查。可以通过 http://10.18.81.167:8080/health 获取健康状态。（10.18.81.167为coredns 其中一个Pod的IP）
ready：CoreDNS插件状态报告，默认监听端口8181，一般用来做可读性检查。可以通过 http://10.18.81.167:9153/ready 获取可读状态。当所有插件都运行后，ready状态为200.
kubernetes：CoreDNS kubernetes插件，提供集群内服务解析能力。
prometheus：CoreDNS自身metrics数据接口。可以通过 http://10.15.0.10:9153/metrics 获取Prometheus格式的监控数据（10.15.0.10 为 kube-dns service 的IP）
forward（或proxy）：将域名查询请求转到预定义的DNS服务器。默认配置中，当域名不在kubernetes域时，将请求转发到预定义的解析器（宿主机的/etc/resolv.conf）中，这是默认配置。
cache：DNS缓存时长，单位秒
loop：环路检测，如果检测到环路，则停止CoreDNS。
reload：允许自动重新加载已更改的Corefile。编辑ConfigMap配置后，请等待两分钟以使更改生效。
loadbalance：循环DNS负载均衡器，可以在答案中随机A、AAAA、MX记录的顺序。

4.6 API资源对象 ingress

有了service之后，我们可以访问这个service的IP（clusterIP）来请求对应的Pod，但是这只能是在集群内部访问。

要想让外部用户访问此资源，可以使用NodePort，即在node节点上暴漏一个端口出来，但是这个非常不灵活。为了解决此类问题，K8s引入了一个新的资源对象Ingress，它是一个七层的负载均衡器，类似于Nginx。

1722824503481

三个概念：Ingress、Ingress Controller、IngressClass

Ingress：用来定义具体的路由规则，要实现什么样的访问规则；
Ingress Controller：是实现Ingress定义具体规则的工具或者叫做服务，在K8s里就是具体的Pod；
IngressClass：是介于Ingress和Ingress Controller之间的一个协调者，它存在的意义在于，当有多个Ingress Controller时，可以让Ingress和Ingress Controller彼此独立，不直接关联，而是通过IngressClass实现关联。

Ingress YAML示例：

vim mying.yaml

apiVersion: networking.k8s.io/v1  # 指定使用的 Kubernetes API 版本
kind: Ingress  # 定义资源类型为 Ingress
metadata:
  name: mying  # 指定 Ingress 资源的名字
spec:
  ingressClassName: myingc  # 指定关联的 IngressClass 名称
  rules:  # 定义具体的路由规则
  - host: giornolinux.com  # 指定访问的目标域名
    http:  # 指定 HTTP 规则
      paths:
      - path: /  # 定义路径
        pathType: Exact  # 指定路径类型为精确匹配
        backend:  # 定义后端服务service对象
          service:
            name: ngx-svc  # 指定后端服务的名称
            port:
              number: 80  # 指定服务的端口号

## 查看ingress
kubectl get ing
kubectl describe ing mying

IngressClass 的 YAML 示例

vim myingc.yaml

apiVersion: networking.k8s.io/v1  # 指定使用的 Kubernetes API 版本
kind: IngressClass  # 定义资源类型为 IngressClass
metadata:
  name: myingc  # 指定 IngressClass 的名称
spec:
  controller: nginx.org/ingress-controller  # 指定要使用的 Ingress 控制器

## 查看IngressClass
kubectl get ingressclass

安装ingress-controller

（使用Nginx官方提供的 https://github.com/nginxinc/kubernetes-ingress ）

## 安装前准备
curl -O 'https://gitee.com/aminglinux/linux_study/raw/master/k8s/ingress.tar.gz'
tar zxf ingress.tar.gz
cd ingress
./setup.sh 
## 说明，执行这个脚本会部署几个ingress相关资源，包括namespace、configmap、secrect等

vim ingress-controller.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ngx-ing
  namespace: nginx-ingress
  
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ngx-ing
      
  template:
    metadata:
      labels:
        app: ngx-ing
      #annotations:
      #  prometheus.io/scrape: "true"
      #  prometheus.io/port: "9113"
      #  prometheus.io/scheme: http
      
    spec:
      serviceAccountName: nginx-ingress
      containers:
      - image: nginx/nginx-ingress:2.2-alpine
        imagePullPolicy: IfNotPresent
        name: ngx-ing
        ports:
        - name: http
          containerPort: 80
        - name: https
          containerPort: 443
        - name: readiness-port
          containerPort: 8081
        - name: prometheus
          containerPort: 9113
        readinessProbe:
          httpGet:
            path: /nginx-ready
            port: readiness-port
          periodSeconds: 1
        securityContext:
          allowPrivilegeEscalation: true
          runAsUser: 101 #nginx
          capabilities:
            drop:
            - ALL
            add:
            - NET_BIND_SERVICE
        env:
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        args:
          - -ingress-class=myingc
          - -health-status
          - -ready-status
          - -nginx-status
          - -nginx-configmaps=$(POD_NAMESPACE)/nginx-config
          - -default-server-tls-secret=$(POD_NAMESPACE)/default-server-secret

## 应用YAML
kubectl apply -f ingress-controller.yaml
## 查看pod、deployment
kubectl get po -n nginx-ingress
kubectl get deploy -n nginx-ingress

##将ingress对应的pod端口映射到master上临时测试
kubectl port-forward -n nginx-ingress ngx-ing-547d6575c7-fhdtt 8888:80 &
## 这个命令用于将本地端口转发到集群中的 Pod 上的端口。这使得你可以从本地机器访问集群中的服务。

## 测试
## 测试前，可以修改ng-deploy对应的两个pod里的/usr/share/nginx/html/index.html文件内容，用于区分两个pod
curl -x127.0.0.1:8888 giornolinux.com
## 或者
curl -H 'Host:giornolinux.com' http://127.0.0.1:8888

1722827314300

应用时候出现错误，未验证

上面对ingress做端口映射，然后通过其中一个节点的IP来访问ingress只是一种临时方案。那么正常如何做呢？有三种常用的方案：

Deployment+LoadBalancer模式的Service

如果要把ingress部署在公有云，那用这种方式比较合适。用Deployment部署ingress-controller，创建一个type为LoadBalancer的service关联这组pod。大部分公有云，都会为LoadBalancer的service自动创建一个负载均衡器，通常还绑定了公网地址。只要把域名解析指向该地址，就实现了集群服务的对外暴露。

Deployment+NodePort模式的Service

同样用deployment模式部署ingress-controller，并创建对应的服务，但是type为NodePort。这样，ingress就会暴露在集群节点ip的特定端口上。由于nodeport暴露的端口是随机端口，一会在前面再搭建一套负载均衡器来转发请求。该方式一般用于宿主机是相对固定的环境ip地址不变的场景。NodePort方式暴露ingress虽然简单方便，但是NodePort多了一层NAT，在请求量级很大时可能对性能会有一定影响。

DaemonSet+HostNetwork+nodeSelector

用DaemonSet结合nodeselector来部署ingress-controller到特定的node上，然后使用HostNetwork直接把该pod与宿主机node的网络打通（如，上面的临时方案kubectl port-forward），直接使用宿主机的80/433端口就能访问服务。这时，ingress-controller所在的node机器就很类似传统架构的边缘节点，比如机房入口的nginx服务器。该方式整个请求链路最简单，性能相对NodePort模式更好。缺点是由于直接利用宿主机节点的网络和端口，一个node只能部署一个ingress-controller pod。比较适合大并发的生产环境使用。

标签：ingress,插件,05,IP,网络,Pod,节点
From： https://www.cnblogs.com/wangand/p/18342929