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模型。

1）CNI
首先我们介绍一下什么是 CNI，它的全称是 Container Network Interface，即容器网络的 API 接口。 CNI本身并不能提供网络服务，它只是定义了对容器网络进行操作和配置的规范。CNI仅关注在创建容器时分配网络资源，和在销毁容器时删除网络资源，这使得CNI规范非常轻巧、易于实现，得到了广泛的支持。而真正实现和落地这些规范的是CNI插件。常见的CNI插件包括Calico、flannel、Terway、Weave Net 以及 Contiv。
2）K8S如何使用CNI插件 K8s 通过 CNI 配置文件来决定使用什么 CNI。基本的使用方法为：
- 首先在每个节点上配置 CNI 配置文件(/etc/cni/net.d/xxnet.conf)，其中 xxnet.conf 是某一个网络配置文件的名称；
- 安装 CNI 配置文件中所对应的二进制插件；
- 在这个节点上创建 Pod 之后，Kubelet 就会根据 CNI 配置文件执行前两步所安装的 CNI 插件；
  具体的流程如下图所示：
  
  在集群里面创建一个 Pod 的时候，首先会通过 apiserver 将 Pod 的配置写入。apiserver 的一些管控组件（比如 Scheduler）会调度到某个具体的节点上去。Kubelet 监听到这个 Pod 的创建之后，会在本地进行一些创建的操作。当执行到创建网络这一步骤时，它首先会读取刚才我们所说的配置目录中的配置文件，配置文件里面会声明所使用的是哪一个插件，然后去执行具体的 CNI 插件的二进制文件，再由 CNI 插件进入 Pod 的网络空间去配置 Pod 的网络。配置完成之后，Kuberlet 也就完成了整个 Pod 的创建过程，这个 Pod 就在线了。
3）基于Calico的Pod网络

tunl0会将容器的源IP和目标IP进行封装，当数据包到达ens33时又会将宿主机的源IP和目标IP进行封装。

2、Service网络

在介绍Service这个api资源对象时，我们已经汇总过Service的几个type：ClusterIP、NodePort、LoadeBalancer，除了这三个还有其它的类型，在本章节我们暂且不去讨论。

这三种类型的Service，LoadBalancer依赖NodePort，而NodePort通常要和ClusterIP一起使用，如果在Service的yaml文件里定义type为LoadBalancer，则它会自动创建NodePort，而NodePort也会自动创建ClusterIP。
Kubernetes网络

下面，再来演绎一下从Pod到Service的网络变化情况：

1）单个Pod之间通信单个Pod和Pod之间通信只能通过Pod的IP和Port来通信，如下图
2）Pod有多个当引入了Deployment，并为Pod设置多个副本时，那么提供某一个服务（如Nginx服务）的Pod就不止一个了，此时即使知道了这些Pod的IP，那访问起来也并不方便。所以，这里需要有一个统一入口，其它Pod通过这个统一入口去请求该服务（Nginx）对应的所有Pod。这时就有了Service这个资源对象，它主要作用就是用来提供统一入口，也就是说只需要一个IP就能访问所有的Pod，而这个入口IP就是ClusterIP，也就是Service的IP。
3）外部资源访问内部Pod 有了Service，的确可以很方便为内部的Pod提供入口，但是在集群外面访问这个内部的资源就没办法了。于是，就有了这个NodePort，使用Service的NodePort类型，可以将Service的ClusterIP对应的Port映射到每一个Node的IP上，映射出去的Port范围为30000~32767
4）借助公有云的负载均衡器使用这个NodePort并不方便，毕竟它带着一个长长的端口号，而且还有一个非常尴尬的问题，就是访问时还得带着Node的IP，如果这个Node挂掉，那么就无法访问此资源，虽然可以通过另外一个Node去访问，但这样太麻烦了！所以，此时的解决方案是：借助三方的负载均衡器，将请求分发到所有的Node上，其底层还是NodePort。

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

3、网络插件Calico

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

1）Calico是什么
Calico 是一个用于容器、虚拟机和主机的开源网络和网络安全解决方案。它是一个纯三层（L3）解决方案，利用 BGP（Border Gateway Protocol）协议为容器或虚拟机提供 IP 地址，并提供网络安全功能，包括网络策略和加密。 Calico 通过将网络策略应用于标签和选择器，提供了一种简单而强大的方法来保护容器或虚拟机之间的通信，并限制容器或虚拟机可以访问的网络资源。它还支持基于 Kubernetes 和 OpenStack 等平台的网络自动化和集成。 Calico 的另一个重要特点是其可扩展性。它使用了基于 BGP 的路由技术，这使得它能够轻松地扩展到非常大规模的网络中，而不会降低性能。由于Calico是一种纯三层的方案，因此可以避免与二层方案相关的数据包封装的操作，中间没有任何的NAT，没有任何的overlay，所以它的转发效率是所有方案中最高的，因为它的包直接走原生TCP/IP的协议栈，它的隔离也因为这个栈而变得好做。因为TCP/IP的协议栈提供了一整套的防火墙的规则，所以它可以通过IPTABLES的规则达到比较复杂的隔离逻辑。
2）Calico架构各组件介绍：
- Felix：Calico Agent，跑在K8S集群中的每台节点上，主要负责管理和维护该节点上的网络和安全策略，如网络接口管理和监听、路由、ARP 管理、ACL 管理和同步、状态上报等；
- Etcd：分布式键值存储，用来存储网络元数据、安全策略以及节点的状态信息，确保Calico网络状态的一致性和准确性，可以和K8S的etcd合用；
- BGP Client（BIRD）：跟Felix一样，每一个节点上都会部署BGP Client，主要负责把Felix写入Kernel的路由信息分发到当前Calico网络，确保各节点间的通信的有效性；
- BGP Route Reflector（BIRD）：在大型网络规模中，如果仅仅使用BGP Client 形成mesh全网互联的方案就会导致规模限制，因为所有节点之间俩俩互联，需要 N^2 个连接，为了解决这个规模问题，可以采用 BGP 的 Router Reflector 的方法，使所有BGP Client仅与特定RR节点互联并做路由同步，从而大大减少连接数大规模部署时使用。
关键点：
- Felix会定期查询Etcd数据库，从而获取到IP变化信息，比如说用户在这台机器上创建了一个容器，增加了一个IP等。当它发现数据变更后，比如用户创建pod后，Felix负责将其网卡、IP、MAC都设置好，然后在内核的路由表里面写一条，注明这个IP应该到这张网卡。同样如果用户制定了隔离策略，Felix同样会将该策略创建到ACL中，以实现隔离。
- BIRD是一个标准的路由程序，它会从内核里面获取哪一些IP的路由发生了变化，然后通过标准BGP的路由协议扩散到整个其他的宿主机上，让外界都知道这个IP在这里，你们路由的时候得到这里来。
3）calico三种网络工作模式模式说明特点 VXLAN 封包，在vxlan设备上将pod发来的数据包源、目的mac替换为本机vxlan网卡和对端节点vxlan网卡的mac。外层udp目的ip地址根据路由和对端vxlan的mac查fdb表获取只要k8s节点间三层互通，可以跨网段，对主机网关路由没有特殊要求。各个node节点通过vxlan设备实现基于三层的“二层”互通, 三层即vxlan包封装在udp数据包中，要求udp在k8s节点间三层可达；二层即vxlan封包的源mac地址和目的mac地址是自己的vxlan设备mac和对端vxlan设备mac。 IPIP 封包，在tunl0设备上将pod发来的数据包的mac层去掉，留下ip层封包。外层数据包目的ip地址根据路由得到。相当于建立了隧道，把两个本来不通的节点网络通过点对点连接起来。只要k8s节点间三层互通，可以跨网段，对主机网关路由没有特殊要求。解包、封包都会造成一定的资源损耗。适用于互相访问的pod不在同一个网段中、跨网段访问的场景。外层封装的ip能够解决跨网段的路由问题。 BGP 边界网关协议（Border Gateway Protocol, BGP）是互联网上一个核心的去中心化自治路由协议。通俗的讲就是讲接入到机房的多条线路（如电信、联通、移动等）融合为一体，实现多线单IP 不用封包解包，通过bgp协议可实现pod网络在主机间的三层可达， k8s节点不跨网段时和flannel的host-gw相似，支持跨网段，跨网段时，需要主机网关路由也充当BGP Speaker能够学习到pod子网路由并实现pod子网路由的转发。总之bgp适用于大规模网络场景。
4）IPIP模式说明默认网络模式即IPIP模式，在所有节点上查看网卡，会有tunl0网卡。
aminglinux02

aminglinux03

查看路由
aminglinux02

aminglinux03

查看Pod

分析：
- ① ng-deploy-7f9cb667d5-v69sn 在aminglinux03上，它的IP为10.18.68.139
- ② 如果68.139要访问另外一个pod ng-deploy-7f9cb667d5-xcmnd，其IP为10.18.206.211
- ③ 它会找路由 10.18.206.192/26 via 192.168.222.102 dev tunl0 proto bird onlink，这条路由对应着aminglinux02的节点IP 192.168.222.102,所以它通过这个IP就能找到10.18.206.211
以上可以说明，IPIP模式就是将节点与节点之间建立了一条隧道，并且建立了对应的路由信息，Pod之间通信时只需要知道目标IP所对应的路由就可以直接访问到对应的节点IP，从而达到对方的Pod。
5）BGP模式说明
将IPIP模式改为BGP
更改calico-node配置

kubectl edit ds calico-node -n kube-system  #会进入vim编辑模式
搜索下面两行
        - name: CALICO_IPV4POOL_IPIP
          value: Always

在它的下面增加：
        - name: CALICO_AUTODETECTION_METHOD
          value: interface=eth0

保存即可生效
更改ippool，保存即可生效

kubectl edit ippool  #会进入vim编辑模式
搜索ipipMode
将ipipMode: Always 改为 ipipMode: Never

查看ip，会发现三台机器的tunl0都没有IP地址了
Kubernetes网络
再查看route，使用BGP模式不再显示tunl0

使用IPIP模式时，是有tunl0的

同样还是ng-deploy的两个Pod，对比之前Pod的IP已经发生了变化，因为我重启过机器，但IP段依然是68和206

如果使用BGP模式，68.188访问206.193时，它的路由是10.18.206.192/26 via 192.168.222.102 dev ens33 proto bird
但此时并不需要借助tunl0了，而是直接通过ens33来。
Kubernetes网络

4、网络插件Flannel

参考 https://blog.yingchi.io/posts/2020/8/k8s-flannel.html，https://juejin.cn/post/6994825163757846565

1）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 这样的中间设备，直接宿主机当作子网的下一跳地址，性能最强；
2）Flannel架构
Flannel在底层实现上要比Calico简单。
Flannel 最主要的两个组件是flanneld跟 flannel.1：
- flanneld：控制面，运行在用户态，负责为宿主机分配子网，并监听Etcd，维护宿主机的FDB/ARP跟路由表
- flannel.1：数据面，运行在内核态，作为VTEP，VXLAN 数据包的封包跟解包
3）VxLAN模式：
VxLAN的设计思想是：在现有的三层网络之上，“覆盖”一层虚拟的、由内核VxLAN模块负责维护的二层网络，使得连接在这个VxLAN二层网络上的“主机”（虚拟机或容器都可以），可以像在同一个局域网（LAN）里那样自由通信。为了能够在二层网络上打通“隧道”，VxLAN会在宿主机上设置一个特殊的网络设备作为“隧道”的两端，叫VTEP：VxLAN Tunnel End Point（虚拟隧道端点）
VXLAN是Flannel默认和推荐的模式。当我们使用默认配置安装Flannel时，它会为每个节点分配一个24位子网，并在每个节点上创建两张虚机网卡： cni0 和 flannel.1 。
- cni0 是一个网桥设备，节点上所有的Pod都通过veth pair的形式与cni0相连。
- flannel.1 则是一个VXLAN类型的设备，充当VTEP的角色，实现对VXLAN报文的封包解包。
同一个节点内的Pod之间通信，只需要通过cni0即可，而我们要讨论的重点是跨节点通信。
假设两个节点Node1和Node2，两个节点上分别有两个Pod：PodA和PodB，现在Node1上的PodA要和Node2上的PodB通信，通信过程如下：

大致概括一下整个过程：
- 发送端：在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 网桥处理。

[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处理

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

host-gw模式的工作原理，就是将每个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的模式，在私有化部署的场景下，可以考虑。

5、Kubernetes里的DNS

K8s集群内有一个DNS服务：

$ kubectl get svc -n kube-system |grep dns

kube-dns         ClusterIP   10.96.0.10    10.0.1.201    53/UDP,53/TCP,9153/TCP   22d

测试：

在aminglinux01上安装bind-utils,目的是安装dig命令
yum install -y bind-utils

解析外网域名
$ dig @10.96.0.10 www.baidu.com

; <<>> DiG 9.11.36-RedHat-9.11.36-8.el8_8.1 <<>> @10.96.0.10 www.baidu.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53640
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 13, ADDITIONAL: 27

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 8094822d82b894ca (echoed)
;; QUESTION SECTION:
;www.baidu.com.            IN  A

;; ANSWER SECTION:
www.baidu.com.        30  IN  CNAME   www.a.shifen.com.
www.a.shifen.com.    30  IN  A   14.119.104.254
www.a.shifen.com.    30  IN  A   14.119.104.189

解析内部域名
$ dig @10.96.0.10 redis-svc.default.svc.cluster.local

; <<>> DiG 9.11.36-RedHat-9.11.36-8.el8_8.1 <<>> @10.96.0.10 redis-svc.default.svc.cluster.local
; (1 server found)
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35621
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 64a805f1035b42b7 (echoed)
;; QUESTION SECTION:
;redis-svc.default.svc.cluster.local. IN    A

;; ANSWER SECTION:
redis-svc.default.svc.cluster.local. 30    IN A    10.108.51.179

;; Query time: 0 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: Thu Oct 19 22:39:47 CST 2023
;; MSG SIZE  rcvd: 127

说明：redis-svc为service name，service完整域名为service.namespace.svc.cluster.local

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

对应的Pod为coredns：

$ kubectl get po -n kube-system | grep coredns

coredns-5bbd96d687-dpgfn                 1/1     Running   1 (67m ago)    10d
coredns-5bbd96d687-mjrks                 1/1     Running   3 (67m ago)    22d

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

$  kubectl exec -it redis-sts-0 -- cat /etc/resolv.conf 

search default.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.96.0.10
options ndots:5

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

$ kubectl exec -it ng-deploy-5dc667896b-wb9pz -n chemex -- cat /etc/resolv.conf 

search chemex.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.96.0.10
options ndots:5

解释：

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段后缀再进行查询。

跨命名空间使用域名是需要补全域名到命名空间部分，例如: kube-dns.kube-system

DNS配置
可以通过查看coredns的configmap来获取DNS的配置信息：

$ kubectl describe cm coredns -n kube-system

Name:         coredns
Namespace:    kube-system
Labels:       <none>
Annotations:  <none>

Data
====
Corefile:
----
.:53 {
    errors
    health {
       lameduck 5s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
       pods insecure
       fallthrough in-addr.arpa ip6.arpa
       ttl 30
    }
    prometheus :9153
    forward . /etc/resolv.conf {
       max_concurrent 1000
    }
    cache 30
    loop
    reload
    loadbalance
}


BinaryData
====

Events:  <none>

说明：

errors：错误信息到标准输出。
health：CoreDNS自身健康状态报告，默认监听端口8080，一般用来做健康检查。您可以通过http://10.18.206.207:8080/health获取健康状态。（10.18.206.207为coredns其中一个Pod的IP）
ready：CoreDNS插件状态报告，默认监听端口8181，一般用来做可读性检查。可以通过http://10.18.206.207:8181/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记录的顺序。

6、API资源对象ingress

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

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

三个概念：Ingress、Ingress Controller、IngressClass

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

Ingress YAML示例：

$ vi  mying.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: mying  ##ingress名字

spec:
  ingressClassName: myingc  ##定义关联的IngressClass

  rules:  ##定义具体的规则
  - host: aminglinux.com  ##访问的目标域名
    http:
      paths:
      - path: /
        pathType: Exact
        backend:  ##定义后端的service对象
          service:
            name: ngx-svc
            port:
              number: 80

查看ingress

$ kubectl get ing
$ kubectl describe ing mying

IngressClassYAML示例：

$ vi myingc.yaml

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: myingc

spec:
  controller: nginx.org/ingress-controller  ##定义要使用哪个controller

查看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等

$ vi  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 &

测试前，可以修改ng-deploy对应的两个pod里的/usr/share/nginx/html/index.html文件内容，用于区分两个pod

测试

$ curl -x127.0.0.1:8888 aminglinux.com
或者：
$ curl -H 'Host:aminglinux.com' http://127.0.0.1:8888

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

1）Deployment+LoadBalancer模式的Service
如果要把ingress部署在公有云，那用这种方式比较合适。用Deployment部署ingress-controller，创建一个type为LoadBalancer的service关联这组pod。
大部分公有云，都会为LoadBalancer的service自动创建一个负载均衡器，通常还绑定了公网地址。
只要把域名解析指向该地址，就实现了集群服务的对外暴露。
2）Deployment+NodePort模式的Service
同样用deployment模式部署ingress-controller，并创建对应的服务，但是type为NodePort。这样，ingress就会暴露在集群节点ip的特定端口上。
由于nodeport暴露的端口是随机端口，一般会在前面再搭建一套负载均衡器来转发请求。该方式一般用于宿主机是相对固定的环境ip地址不变的场景。
NodePort方式暴露ingress虽然简单方便，但是NodePort多了一层NAT，在请求量级很大时可能对性能会有一定影响。
3）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。比较适合大并发的生产环境使用。

7、动态云原生网关 APISIX

APISIX也是一种访问K8S集群内部资源的解决方案，相比Ingress，APISIX功能更加强大，可以满足更多复杂应用场景。

1）APISIX介绍
Apache APISIX是一个高性能、动态、可扩展的 API 网关，由 Apache 基金会孵化并管理。它基于 Nginx 和 etcd 开发，提供了丰富的流量管理功能，如负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等。APISIX 旨在为微服务和 API 管理提供统一的入口，同时支持各种插件来满足不同的业务需求。
APISIX架构

上图为 APISIX 产品中控制⾯（简称 CP）与数据⾯（简称 DP）的架构⽰意图：
- 数据面：数据平⾯⽤于接收并处理调⽤⽅请求，使⽤Lua与Nginx动态控制请求流量。当请求进⼊时，将根据预设路由规则进⾏匹配，匹配到的请求将被⽹关转发⾄对应上游服务。在此过程中，⽹关有能⼒根据预设规则中不同插件的配置，使⽤⼀系列插件对请求从进⼊到离开的各个阶段进⾏操作。例如：请求可能会经过⾝份认证（避免重放攻击、参数篡改等）、请求审计（请求来源信息、上游处理时⻓等）、路由处理（根据预设规则获取最终上游服务地址）、请求转发（⽹关将请求转发⾄上游⽬标节点）、请求响应（上游处理完成后，⽹关将结果返回给调⽤⽅）等⼏个步骤。
- 控制面：控制平⾯包含了Admin API与默认配置中⼼ETCD。管理员在访问并操作控制台时，控制台将调⽤Admin API下发配置到ETCD，借助ETCD Watch机制，配置将在⽹关中实时⽣效。例如：管理员可增加⼀条路由，并配置限速插件，当触发到限速阈值后，⽹关将会暂时阻⽌后续匹配到该路由的请求进⼊。借助ETCD的Watch机制，当管理员在控制⾯板更新配置后，APISIX将在毫秒级别内通知到各个⽹关节点。。
APISIX采⽤了数据平⾯与控制平⾯分离的架构⽅式，通过配置中⼼接收、下发配置，使得数据平⾯不会受到控制平⾯影响。配置中⼼默认为 ETCD，但也⽀持 Consul、Nacos、Eureka 等，可根据您的实际情况进⾏选择。此外，企业⽤⼾只需关注业务本⾝，与业务⽆关的⼤部分功能交给 APISIX 内置插件即可实现，如⾝份验证、性能分析等。
APISIX特点
- ⾼可⽤： APISIX 默认选⽤ ETCD 作为配置中⼼，ETCD 天然⽀持分布式、⾼可⽤，并且在 K8s 等领域有⼤量实践经验，使得 APISIX 可以轻松⽀持毫秒级配置更新、⽀撑数千⽹关节点；⽹关节点⽆状态，可任意扩容或缩容；
- 协议转换：⽀持丰富的协议类型，如 TCP/UDP、Dubbo、MQTT、gRPC、SOAP、WebSocket 等；
- 安全防护：内置多种⾝份验证与安全防护能⼒，如 Basic Auth、JSON Web Token、IP ⿊⽩名单、OAuth 等；
- 性能极⾼： APISIX使⽤Radixtree算法实现⾼性能、灵活路由，在 AWS 8 核⼼服务器中，QPS 约为 140K，延迟约为 0.2 ms；
- 全动态能⼒：修改⽹关配置、增加或修改插件等，⽆需重启⽹关服务即可实时⽣效；⽀持动态加载 SSL 证书；
- 扩展能⼒强：借助灵活的插件机制，可针对内部业务完成功能定制；⽀持⾃定义负载均衡算法与路由算法，不受限于API⽹关实现；通过运⾏时动态执⾏⽤⼾⾃定义函数⽅式来实现Serverless，使⽹关边缘节点更加灵活；
- 治理能⼒丰富：如故障隔离、熔断降级、限流限速等；在启⽤主动健康检查后，⽹关将⽀持智能跟踪不健康上游节点的能⼒，并⾃动过滤不健康节点，以提⾼整体服务稳定性。
2）APISIX部署
官方文档： https://apisix.apache.org/zh/docs/apisix/installation-guide/

声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。

{{userData.name}}已认证

Kubernetes网络