11-kubernetes入门学习之网络设计实现方案

~$ kubectl get pod --all-namespaces -o json | jq '.items[] | select(.metadata.name=="kubernetes-dashboard-7448ffc97b-sd9bt")' | jq .status.podIP
"172.16.182.203"

~$ kubectl get endpoints --all-namespaces
kubernetes-dashboard   dashboard-metrics-scraper        172.16.24.198:8000                                                       59d
kubernetes-dashboard   kubernetes-dashboard             172.16.182.203:8443                                                      59d

# 方式1
$ ip addr
....
3: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
    inet 172.16.0.192/32 scope global tunl0  # 运行在该节点上的Pod的网关地址
       valid_lft forever preferred_lft forever
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:e3:83:5e:a1 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:e3ff:fe83:5ea1/64 scope link
       valid_lft forever preferred_lft forever
....
97: veth09836f7@if96: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
    link/ether 6e:e4:02:db:75:57 brd ff:ff:ff:ff:ff:ff link-netnsid 2
    inet6 fe80::6ce4:2ff:fedb:7557/64 scope link
       valid_lft forever preferred_lft forever
117: veth867869c@if116: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
    link/ether 4a:62:4c:ba:c6:91 brd ff:ff:ff:ff:ff:ff link-netnsid 3
    inet6 fe80::4862:4cff:feba:c691/64 scope link
       valid_lft forever preferred_lft forever
# 方式2
$ bridge -d link
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master docker0 docker0
97: veth09836f7@if96: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master docker0 state forwarding priority 32 cost 2
    hairpin off guard off root_block off fastleave off learning on flood on mcast_flood on mcast_to_unicast off neigh_suppress off vlan_tunnel off isolated off veth09836f7
117: veth867869c@if116: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master docker0 state forwarding priority 32 cost 2
    hairpin off guard off root_block off fastleave off learning on flood on mcast_flood on mcast_to_unicast off neigh_suppress off vlan_tunnel off isolated off veth867869c

# 例如本机的corednsPod
~$ kubectl get pod -n kube-system  -o wide | grep "coredns"
coredns-6c76c8bb89-hr9b7                   1/1     Running   2          61d   172.16.0.198     weiyigeek-107  
coredns-6c76c8bb89-kgbdb                   1/1     Running   2          61d   172.16.0.199     weiyigeek-107 
# coredns 的端点情况
~$ kubectl get endpoints -n kube-system kube-dns
NAME       ENDPOINTS                                                     AGE
kube-dns   172.16.0.198:53,172.16.0.199:53,172.16.0.198:53 + 3 more...   61d

# 路由跟踪就是本机
~$ tracepath  -4 172.16.0.199
 1?: [LOCALHOST]                      pmtu 1480
 1:  172.16.0.199                                          0.063ms reached
 1:  172.16.0.199                                          0.034ms reached
     Resume: pmtu 1480 hops 1 back 1

# 例如 jenkins-844756cf77-nvhmj pod 运行在weiyigeek-226节点的 172.16.182.205 中
~$ kubectl get pod -n devops -o wide
NAME                                 READY   STATUS    RESTARTS   AGE   IP               NODE      
jenkins-844756cf77-nvhmj             1/1     Running   0          12d   172.16.182.205   weiyigeek-226   

# 其次我们在宿主机上进行路由跟踪
~$ tracepath  -4 172.16.182.205
 1?: [LOCALHOST]                      pmtu 1480
 1:  172.16.182.192                    0.353ms  # 实际上是weiyigeek-226节点的tunl0虚拟网卡;
 1:  172.16.182.192                    0.305ms
 2:  172.16.182.205                    0.304ms reached

# 验证结论
weiyigeek@weiyigeek-226:~$ ip addr | grep "172.16.182.192" -B 2
7: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
    inet 172.16.182.192/32 scope global tunl0

# (1) 获取ClusterIP与Endpoint端点可知 10.107.122.223 代理了后端 172.16.182.200:8080,172.16.183.89:8080,172.16.24.230:8080
~$ kubectl get endpoints deploy-maven-svc
  # NAME               ENDPOINTS                                                   AGE
  # deploy-maven-svc   172.16.182.200:8080,172.16.183.89:8080,172.16.24.230:8080   9d  # 

~$ kubectl get svc deploy-maven-svc
  # NAME               TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
  # deploy-maven-svc   NodePort   10.107.122.223   <none>        8080:30089/TCP   9d

# (2) 内核中 iptables 转发列表查看
~$ sudo iptables -S -t nat
  # -A KUBE-FIREWALL -j KUBE-MARK-DROP
  # -A KUBE-LOAD-BALANCER -j KUBE-MARK-MASQ
  # -A KUBE-MARK-MASQ -j MARK --set-xmark 0x4000/0x4000
  # -A KUBE-NODE-PORT -p tcp -m comment --comment "Kubernetes nodeport TCP port for masquerade purpose" -m set --match-set KUBE-NODE-PORT-TCP dst -j KUBE-MARK-MASQ
  # -A KUBE-POSTROUTING -m comment --comment "Kubernetes endpoints dst ip:port, source ip for solving hairpin purpose" -m set --match-set KUBE-LOOP-BACK dst,dst,src -j MASQUERADE
  # -A KUBE-POSTROUTING -m mark ! --mark 0x4000/0x4000 -j RETURN
  # -A KUBE-POSTROUTING -j MARK --set-xmark 0x4000/0x0
  # -A KUBE-POSTROUTING -m comment --comment "kubernetes service traffic requiring SNAT" -j MASQUERADE --random-fully
  # # 此为 Pod 运行的的网段指向`KUBE-CLUSTER-IP`ClusterIP
  # -A KUBE-SERVICES ! -s 172.16.0.0/16 -m comment --comment "Kubernetes service cluster ip + port for masquerade purpose" -m set --match-set KUBE-CLUSTER-IP dst,dst -j KUBE-MARK-MASQ  
  # -A KUBE-SERVICES -m addrtype --dst-type LOCAL -j KUBE-NODE-PORT
  # # 转发到 KUBE-SERVICES 链中匹配CLUSTER-IP地址进行通信
  # -A KUBE-SERVICES -m set --match-set KUBE-CLUSTER-IP dst,dst -j ACCEPT

# 查看 Flannel 为 Docker 分配的地址段：
~$ cat /run/flannel/subnet.env
FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.1.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=true

~$ kubectl get pod -o wide | grep "Running"
  # deploy-blog-html-0                        1/1     Running       2          79d   10.244.1.19    weiyigeek-ubuntu
  # deploy-java-maven-0                       1/1     Running       2          40d   10.244.1.15    weiyigeek-ubuntu
  # nfs-client-provisioner-58b5dc958d-pxhb7   1/1     Running       1          11d   10.244.1.20    weiyigeek-ubuntu
  # nginx-app                                 1/1     Running       2          38d   10.244.1.14    weiyigeek-ubuntu
  # web-0                                     1/1     Running       2          38d   10.244.1.16    weiyigeek-ubuntu

~$ route -n
  # Kernel IP routing table
  # Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
  # 0.0.0.0         10.10.107.1     0.0.0.0         UG    0      0        0 ens160
  # 10.10.107.0     0.0.0.0         255.255.255.0   U     0      0        0 ens160
  # 10.244.0.0      0.0.0.0         255.255.255.0   U     0      0        0 cni0
  # 10.244.1.0      10.244.1.0      255.255.255.0   UG    0      0        0 flannel.1
  # 10.244.2.0      10.244.2.0      255.255.255.0   UG    0      0        0 flannel.1
  # 172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
  # 172.18.0.0      0.0.0.0         255.255.0.0     U     0      0        0 br-26a32f4b83c1

~$ route -n
  # Kernel IP routing table
  # Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
  # 10.244.0.0      0.0.0.0         255.255.255.0   U     0      0        0 cni0

1.Web APP3 发生请求记录目标的IP为10.1.20.3和请求地址的数据包
2.Docker0网桥收到数据包后发现是在同一个子网里`利用UDP`直接转发给10.1.20.3的Backend服务
3.Backend接收到Web App3的请求后将反馈的数据通过原路返回

1.Web APP3 发生请求生成数据包其中包括目标的IP(`10.1.20.3`)和源IP(10.1.15.2)以及自身的Mac
2.Docker0 (10.1.15.1/24) 网桥对该数据封包进行解析发现目标地址非本局域网内填上自身的源转发给Flannel0
3.在Dlannel0接收到后会通过Flanneld进程服务从etcd数据库中取出到该目标IP的路由
4.然后通过Iptable转发封装OuterIP的Src地址192.168.66.11和Dest地址为192.168.66.12, 其InnerIP 记录实际的请求源地址以及目标地址在加上Playload的数据包实体;
5.当Pod网络接口接收到该数据包时候转发给Flanneld服务
6.Flanneld服务获得InnerIP数据包的请求的目标地址并在etc中进行查询获得路由表信息
7.转发给Flannel0在发送Docker0网桥其发现访问的地址为10.1.20.3则将请求进行重新封装后转发
8.Backend获得请求的数据包

~$ mkdir -vp /usr/lib/systemd/system/docker.service.d/
~$ tee -a /usr/lib/systemd/system/docker.service.d/flannel.conf <<'EOF'
[Service]
environmentFile=-/run/flannel/docker
EOF

~$ cat /run/flannel/subnet.env
FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.0.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=true

# 虚拟接口
~$ ip addr | egrep -v "^\s"
  # 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
  # 2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
  # 3: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN group default qlen 1000
  # 4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
  # 5: kube-ipvs0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default
  # 6: calib6c39f0a1d5@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc noqueue state UP group default
  # 7: calic77cbbaf4da@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc noqueue state UP group default
  # 97: veth09836f7@if96: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
  # 117: veth867869c@if116: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default

# NAT 转发表以及五条链
# PREROUTING:数据包进入路由表之前
# INPUT:通过路由表后目的地为本机
# FORWARDING:通过路由表后，目的地不为本机
# OUTPUT:由本机产生，向外转发
# POSTROUTIONG:发送到网卡接口之前。
~$ sudo iptables -S -t nat | grep "cali"
  # -N cali-OUTPUT
  # -N cali-POSTROUTING
  # -N cali-PREROUTING
  # -N cali-fip-dnat
  # -N cali-fip-snat
  # -N cali-nat-outgoing
  # -A PREROUTING -m comment --comment "cali:6gwbT8clXdHdC1b1" -j cali-PREROUTING
  # -A OUTPUT -m comment --comment "cali:tVnHkvAo15HuiPy0" -j cali-OUTPUT
  # -A POSTROUTING -m comment --comment "cali:O3lYWMrLQYEMJtB5" -j cali-POSTROUTING
  # -A cali-OUTPUT -m comment --comment "cali:GBTAv2p5CwevEyJm" -j cali-fip-dnat
  # -A cali-POSTROUTING -m comment --comment "cali:Z-c7XtVd2Bq7s_hA" -j cali-fip-snat
  # -A cali-POSTROUTING -m comment --comment "cali:nYKhEzDlr11Jccal" -j cali-nat-outgoing
  # -A cali-POSTROUTING -o tunl0 -m comment --comment "cali:SXWvdsbh4Mw7wOln" -m addrtype ! --src-type LOCAL --limit-iface-out -m addrtype --src-type LOCAL -j MASQUERADE --random-fully
  # -A cali-PREROUTING -m comment --comment "cali:r6XmIziWUJsdOK6Z" -j cali-fip-dnat
  # -A cali-nat-outgoing -m comment --comment "cali:flqWnvo8yq4ULQLa" -m set --match-set cali40masq-ipam-pools src -m set ! --match-set cali40all-ipam-pools dst -j MASQUERADE --random-fully

# 1) 例如 我们设置 /etc/resolv.conf 如下
# nameserver 192.168.12.254
# search weiyigeek.top weiyigeek.cn
nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
# ndots:5 是指少于 5 个 dots 的域名，都首先当作非 FQDN 看待优先在搜索域里面查找;
options ndots:5

# 2) 输入一个不存在的域名查看尝试过程
~$ host -v weiyigeek
  # Trying "weiyigeek.default.svc.cluster.local"
  # Trying "weiyigeek.svc.cluster.local"
  # Trying "weiyigeek.cluster.local"
  # Trying "weiyigeek"
  # Host weiyigeek not found: 3(NXDOMAIN)
  # Received 102 bytes from 10.96.0.10#53 in 47 ms

.:53 {
    errors  # 启用错误日志
    health  # 启用健康检查 api
    ready  # 启用 readiness 就绪 api

    # 启用 kubernetes 集群支持，详见 https://coredns.io/plugins/kubernetes/
    # 此插件只处理 cluster.local 域，以及 PTR 解析
    kubernetes cluster.local in-addr.arpa ip6.arpa {
      pods insecure
      upstream  # 
      fallthrough in-addr.arpa ip6.arpa  # 向下传递 DNS 反向查询
      ttl 30  # 过期时间
    }
    prometheus :9153  # 启用 prometheus metrics 支持
    forward . 114.114.114.114 19.29.29.29 # 将非集群域名的 DNS 请求，转发给公网 DNS 服务器。
    cache 30  # 启用前端缓存，缓存的 TTL 设为 30
    loop    # 检测并停止死循环解析
    reload  # 支持动态更新 Corefile

    # 随机化 A/AAAA/MX 记录的顺序以实现负载均衡。
    #   因为 DNS resolver 通常使用第一条记录，而第一条记录是随机的。这样客户端的请求就能被随机分配到多个后端。
    loadbalance
}

# 定义可复用 Block
(common) {
    log
    errors
    cache
    loop    # 检测并停止死循环解析
}

# 本地开发环境的 DNS 解析
dev-env.local:53 {
    import common  # 导入 Block
    file dev-env.local { # 从文件 `dev-env.local` 中读取 DNS 数据
        reload 30s  # 每 30s 检查一次配置的 Serial，若该值有变更则重载整个 Zone 的配置。
    }
}

# 本地测试环境
test-env.local:53 {
    import common
    file test-env.local {
        reload 30s
    }
}

# 其他
.:53 {
    forward . 114.114.114.114  # 解析公网域名
    log
    errors
    cache
}

;; 與整個領域相關性較高的設定包括 NS, A, MX, SOA 等標誌的設定處！
$TTL    30
@                       IN SOA   dev-env.local. devops.dev-env.local. (
                                     20200202 ; SERIAL，每次修改此文件，都应该同步修改这个“版本号”，可将它设为修改时间。
                                     7200     ; REFRESH
                                     600      ; RETRY
                                     3600000  ; EXPIRE
                                     60)      ; MINIMUM
@                       IN NS    dns1.dev-env.local.   ; DNS 伺服器名稱
dns1.dev-env.local.    IN A     192.168.23.2         ; DNS 伺服器 IP


redis.dev-env.local.         IN A     192.168.23.21
mysql.dev-env.local.         IN A     192.168.23.22
elasticsearch.dev-env.local. IN A     192.168.23.23
ftp                          IN A     192.168.23.25  ;

root@test-ubuntu:~/dns-server# tree
.
├── coredns  # coredns binary
├── Corefile
├── dev-env.local
└── test-env.local

A：这里说的A和B应当是指Service，A Service中Pod与B Service Pod之间的通信，可以在其容器的环境变量中定义Service IP或是Service Name来实现；由于Service IP提前不知道，使用引入kube-dns做服务发现，它的作用就是监听Service变化并更新DNS，即Pod通过服务名称可以查询DNS；kube-proxy是一个简单的网络代理和负载均衡器，它的作用主要是负责service的实现，具体来说，就是实现了内部从Pod到Service和外部的从NodePort向Service的访问，可以说kube-dns和kube-proxy都是为Service服务的。

A：Docker实现跨主机通信可以通过桥接和路由的方式，桥接的方式是将docker0桥接在主机的网卡上，而路由直接通过主机网口转发出去；Kubernetes网络有Pod和Server，Pod网络实现的方式很多，可以参考CNI网络模型，Flannel实质上是一种`“覆盖网络（Overlay Network）”`，也就是`将TCP数据包装在另一种网络包里面进行路由转发和通信`。

A：内部从Pod到Service的实现是由kube-proxy（简单的网络代理和负载均衡器）来完成，kube-proxy默认采用轮询方法进行分配，也可以通过将service.spec.sessionAffinity设置为“ClientIP”（默认为“无”）来选择基于客户端IP的会话关联，目前还不能进行网段的指定。

A：由于微服务架构以及Docker技术和Kubernetes编排工具最近几年才开始逐渐流行，所以一开始的反向代理服务器比如Nginx/HAProxy并未提供其支持，毕竟他们也不是先知，所以才会出现IngressController这种东西来做Kubernetes和前端负载均衡器如Nginx/HAProxy之间做衔接，即Ingress Controller的存在就是为了能跟Kubernetes交互，又能写 Nginx/HAProxy配置，还能 reload 它，这是一种折中方案；而最近开始出现的Traefik天生就是提供了对Kubernetes的支持，也就是说Traefik本身就能跟Kubernetes API交互，感知后端变化，因此在使用Traefik时就不需要Ingress Controller，此方案当然可行。

A：Pod是Kubernetes的基本操作单元，Pod包含一个或者多个相关的容器，Pod可以认为是容器的一种延伸扩展，一个Pod也是一个隔离体，而Pod内部包含的一组容器又是共享的（包括PID、Network、IPC、UTS）；Service是Pod的路由代理抽象，能解决Pod之间的服务发现问题；Flannel的设计目的就是为集群中的所有节点重新规划IP地址的使用规则，从而使得不同节点上的容器能够获得“同属一个内网”且”不重复的”IP地址，并让属于不同节点上的容器能够直接通过内网IP通信；Kubernetes kube-proxy实现的是内部L4层轮询机制的负载均衡，要支持L4、L7负载均衡，Kubernetes也提供了Ingress组件，通过反向代理负载均衡器（Nginx/HAProxy）+Ingress Controller+Ingress可以实现对外服务暴露，另外使用Traefik方案来实现Service的负载均衡也是一种不错的选择。

A：kube-proxy有2个模式实现负载均衡，一种是userspace，通过Iptables重定向到kube-proxy对应的端口上，然后由kube-proxy进一步把数据发送到其中的一个Pod上，另一种是Iptables，纯采用Iptables来实现负载均衡，kube-proxy默认采用轮询方法进行分配，也可以通过将service.spec.sessionAffinity设置为“ClientIP”（默认为“无”）来选择基于客户端IP的会话关联；Service Cluster IP它是一个虚拟IP，是由kube-proxy使用Iptables规则重新定向到其本地端口，再均衡到后端Pod的，通过 apiserver的启动参数--service-cluster-ip-range来设置，由kubernetes集群内部维护。

A：Kubernetes网络这块采用的是CNI规范，网络插件化，非常灵活，不同的网络插件调试的方法也是不一样的；端口映射方式的最大隐患就是很容易造成端口冲突。

A：Kubernetes Service到Pod的通信是由kube-proxy代理分发，而Pod中容器的通信是通过端口，不同Service间通信可以通过DNS，不一定要使用虚拟IP。

A：Canal不是很了解；CNI并不是网络实现，它是网络规范和网络体系，从研发的角度它就是一堆接口，关心的是网络管理的问题，CNI的实现依赖于两种Plugin，一种是CNI Plugin负责将容器connect/disconnect到host中的vbridge/vswitch，另一种是IPAM Plugin负责配置容器Namespace中的网络参数；Calico 的policy是基于Iptables，保证通过各个节点上的 ACLs 来提供workload 的多租户隔离、安全组以及其他可达性限制等功能。

A：CNI并不是网络实现，它是网络规范和网络体系，从研发的角度它就是一堆接口，你底层是用Flannel也好、用Calico也好，它并不关心，它关心的是网络管理的问题，CNI的实现依赖于两种plugin，一种是CNI Plugin负责将容器connect/disconnect到host中的vbridge/vswitch，另一种是IPAM Plugin负责配置容器Namespace中的网络参数。

A：Services是Kubernetes的基本操作单元，是真实应用服务的抽象，Service IP范围在配置kube-apiserver服务的时候通过--service-cluster-ip-range参数指定，由Kubernetes集群自身维护。