k8s网络通信

一、通信模式一、k8s通过CNI接口接入其他插件来实现网络通讯。目前比较流行的插件有flannel，calico等。CNI插件存放位置：# cat/etc/cni/net.d/10-flannel.conflist插件使用的解决方案如下：虚拟网桥，虚拟网卡，多个容器共用一个虚拟网卡进行通信。多路复用：MacVLAN，多个容器共用一个物理网卡进行通信。硬件交换：SR-LOV，一个物理网卡可以虚拟出

Sun__s

822人浏览 · 2021-03-01 14:34:42

Sun__s · 2021-03-01 14:34:42 发布

一、通信模式

一、k8s通过CNI接口接入其他插件来实现网络通讯。目前比较流行的插件有flannel，calico等。
CNI插件存放位置：# cat /etc/cni/net.d/10-flannel.conflist
插件使用的解决方案如下：

虚拟网桥，虚拟网卡，多个容器共用一个虚拟网卡进行通信。
多路复用：MacVLAN，多个容器共用一个物理网卡进行通信。
硬件交换：SR-LOV，一个物理网卡可以虚拟出多个接口，这个性能最好。

二、容器间通信：同一个pod内的多个容器间的通信，通过lo即可实现；

三、pod之间的通信：

同一节点的pod之间通过cni网桥转发数据包。
不同节点的pod之间的通信需要网络插件支持。

四、pod和service通信: 通过iptables或ipvs实现通信，ipvs取代不了iptables，因为ipvs只能做负载均衡，而做不了nat转换。

五、pod和外网通信：iptables的MASQUERADE。

六、Service与集群外部客户端的通信；（ingress、nodeport、loadbalancer）

二、service

1 k8s提供的dns服务插件

[root@server2 ~]# kubectl describe svc myservice

在这里插入图片描述

[root@server2 ~]# kubectl run demo1 --image=busyboxplus -it
If you don't see a command prompt, try pressing enter.
/ # nslookup myservice
/ # curl myservice
[root@server2 ~]# kubectl get service kube-dns --namespace=kube-system

在这里插入图片描述

[root@server2 ~]# dig myservice.default.svc.cluster.local. @10.96.0.10

在这里插入图片描述

2 Headless Service “无头服务”

Headless Service不需要分配一个VIP，而是直接以DNS记录的方式解析出被代理Pod的IP地址。
域名格式： $(s e r v i c e n a m e) .$ (namespace).svc.cluster.local

[root@server2 ~]# vim demo.yml   #clusterIP: None  #无头服务
---
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  selector:
    app: myapp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  clusterIP: None   #无头服务

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo2
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:v2

[root@server2 ~]# kubectl apply -f demo.yml
[root@server2 ~]# kubectl get svc

从下图看到没有分配固定ip,而是直接以DNS记录的方式解析出被代理Pod的IP地址。
在这里插入图片描述

[root@server2 ~]#  dig myservice.default.svc.cluster.local. @10.96.0.10

在这里插入图片描述

3 创建service（NodePort方式）

[root@server2 ~]# vim demo.yml 
---
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  selector:
    app: myapp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  #clusterIP: None
  type: NodePort

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo2
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:v2

[root@server2 ~]# kubectl delete -f demo.yml
[root@server2 ~]# kubectl apply -f demo.yml
[root@server2 ~]# kubectl get svc

在ip的基础上又加了一个端口
在这里插入图片描述

4. LoadBalancer 类型的 Service

从外部访问 Service 的第二种方式，适用于公有云上的 Kubernetes 服务。这时候，你可以指定一个 LoadBalancer 类型的 Service。
在service提交后，Kubernetes就会调用 CloudProvider 在公有云上为你创建一个负载均衡服务，并且把被代理的 Pod 的 IP地址配置给负载均衡服务做后端。

将刚才的demo.yml中的类型变成LoadBalancer即可
由于我们使用的不是共有云，所以暂时不能实现，EXTERNAL-IP显示的是pending等待分配ip状态
在这里插入图片描述

5 service允许为其分配一个公有IP

在ClusterIP的基础上，给绑定了一个外部地址，在外部可以直接访问

[root@server2 ~]# vim demo.yml
externalIPs:
  - 172.25.1.10

在这里插入图片描述

在外部主机可以通过这个ip进行访问

6 ExternalName

从外部访问的第三种方式叫做ExternalName

[root@server2 ~]# vim my-service.yml 
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type:  ExternalName
  externalName: www.baidu.com

在这里插入图片描述
两种验证方式：

[root@server2 ~]# dig -t A my-service.default.svc.cluster.local. @10.96.0.10   #dig
[root@server2 ~]# kubectl attach demo1 -it    #进入交互测试

在这里插入图片描述

三、（pod间通信）Flannel 网络

Flannel vxlan模式跨主机通信原理
在这里插入图片描述
（1）VXLAN，即Virtual Extensible LAN（虚拟可扩展局域网），是Linux本身支持的一网种网络虚拟化技术。VXLAN可以完全在内核态实现封装和解封装工作，从而通过“隧道”机制，构建出覆盖网络（Overlay Network）。

（2）VTEP：VXLAN Tunnel End Point（虚拟隧道端点），在Flannel中 VNI的默认值是1，这也是为什么宿主机的VTEP设备都叫flannel.1的原因。

（3）Cni0: 网桥设备，每创建一个pod都会创建一对 veth pair。其中一端是pod中的eth0，另一端是Cni0网桥中的端口（网卡）。

（4）Flannel.1: TUN设备(虚拟网卡)，用来进行 vxlan 报文的处理（封包和解包）。不同node之间的pod数据流量都从overlay设备以隧道的形式发送到对端。

（5）Flanneld：flannel在每个主机中运行flanneld作为agent，它会为所在主机从集群的网络地址空间中，获取一个小的网段subnet，本主机内所有容器的IP地址都将从中分配。同时Flanneld监听K8s集群数据库，为flannel.1设备提供封装数据时必要的mac、ip等网络数据信息。

flannel网络原理

当容器发送IP包，通过veth pair 发往cni网桥，再路由到本机的flannel.1设备进行处理。
VTEP设备之间通过二层数据帧进行通信，源VTEP设备收到原始IP包后，在上面加上一个目的MAC地址，封装成一个内部数据帧，发送给目的VTEP设备。
内部数据桢，并不能在宿主机的二层网络传输，Linux内核还需要把它进一步封装成为宿主机的一个普通的数据帧，承载着内部数据帧通过宿主机的eth0进行传输。
Linux会在内部数据帧前面，加上一个VXLAN头，VXLAN头里有一个重要的标志叫VNI，它是VTEP识别某个数据桢是不是应该归自己处理的重要标识。
flannel.1设备只知道另一端flannel.1设备的MAC地址，却不知道对应的宿主机地址是什么。在linux内核里面，网络设备进行转发的依据，来自FDB的转发数据库，这个flannel.1网桥对应的FDB信息，是由flanneld进程维护的。
linux内核在IP包前面再加上二层数据帧头，把目标节点的MAC地址填进去，MAC地址从宿主机的ARP表获取。
此时flannel.1设备就可以把这个数据帧从eth0发出去，再经过宿主机网络来到目标节点的eth0设备。目标主机内核网络栈会发现这个数据帧有VXLAN Header，并且VNI为1，Linux内核会对它进行拆包，拿到内部数据帧，根据VNI的值，交给本机flannel.1设备处理,flannel.1拆包，根据路由表发往cni网桥，最后到达目标容器。

[root@server2 ~]# kubectl get pod -n  kube-system

在这里插入图片描述

相同主机之间的pod通过cni通信

在server3上要先知道目标主机(server4)eth0的IP和mac地址

arp -n 可以查看到有server4的ip信息。

flannel支持多种后端

Vxlan

vxlan //报文封装，默认
Directrouting //直接路由，跨网段使用vxlan，同网段使用host-gw模式。
host-gw：//主机网关，性能好，但只能在二层网络中，不支持跨网络，如果有成千上万的Pod，容易产生广播风暴，不推荐
UDP： //性能差，不推荐

host-gw主机网关

修改配置flannel：

[root@server2 ~]# kubectl -n kube-system edit cm kube-flannel-cfg

在这里插入图片描述
生效：

[root@server2 ~]# kubectl get pod -n kube-system |grep flannel | awk '{system("kubectl delete pod "$1" -n kube-system")}'

在这里插入图片描述
从下图我们可以看出本地的话直接走cni，如果是1,0网段的直接走网关etho

vxlan

[root@server2 ~]# kubectl -n kube-system edit cm kube-flannel-cfg
"Type": "vxlan",
        "Directrouting": true
[root@server2 ~]# kubectl get pod -n kube-system |grep flannel | awk '{system("kubectl delete pod "$1" -n kube-system")}'

在这里插入图片描述

并没有经过flannel.1

四、Service与集群外部客户端的通信（Ingress 服务）

一种全局的、为了代理不同后端 Service 而设置的负载均衡服务，就是 Kubernetes 里的Ingress 服务。
Ingress由两部分组成：Ingress controller和Ingress服务。
Ingress Controller 会根据你定义的 Ingress 对象，提供对应的代理能力。业界常用的各种反向代理项目，比如 Nginx、HAProxy、Envoy、Traefik 等，都已经为Kubernetes 专门维护了对应的 Ingress Controller。

在这里插入图片描述
官网：ingress-nginx
下载镜像并上传到本地仓库,镜像下载需要翻墙
所需的资源链接: yaml文件和镜像提取码: nbvc

Ingress 服务部署：

[root@server1 ~]# docker load -i ingress-nginx.tar 
[root@server1 ~]# docker tag quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.33.0 reg.westos.org/library/nginx-ingress-controller:0.33.0
[root@server1 ~]# docker tag jettech/kube-webhook-certgen:v1.2.0 reg.westos.org/library/kube-webhook-certgen:v1.2.0
[root@server1 ~]# docker push reg.westos.org/library/nginx-ingress-controller:0.33.0
[root@server1 ~]# docker push reg.westos.org/library/kube-webhook-certgen:v1.2.0


[root@server2 ~]# mkdir ingress-nginx/
[root@server2 ~]# cd  ingress-nginx/
[root@server2 ingress-nginx]# kubectl apply -f deploy.yaml
[root@server2 ingress-nginx]# kubectl get ns
[root@server2 ingress-nginx]# kubectl get all -n ingress-nginx

在这里插入图片描述

创建Ingress服务

[root@server2 ~]# vim nginx.yml
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: ingress-demo
spec:
  rules:
  - host: www1.westos.org
    http:
      paths:
      - path: /
        backend:
          serviceName: myservice
          servicePort: 80
[root@server2 ~]# kubectl apply -f nginx.yml

在这里插入图片描述
做好地址解析：

用DaemonSet结合nodeselector来部署ingress-controller到特定的node上，然后使用HostNetwork直接把该pod与宿主机node的网络打通，直接使用宿主机的80/443端口就能访问服务。

优点是整个请求链路最简单，性能相对NodePort模式更好。
缺点是由于直接利用宿主机节点的网络和端口，一个node只能部署一个ingress-controller pod。
比较适合大并发的生产环境使用。

Ingress TLS 加密配置

生成证书：
[root@server2 ingress-nginx]# openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=nginxsvc/O=nginxsvc"
导入证书：
[root@server2 ingress-nginx]# kubectl create secret tls tls-secret --key tls.key --cert tls.crt
查看证书：
[root@server2 ingress-nginx]# kubectl get secrets

在这里插入图片描述
生效：

[root@server2 ingress-nginx]# vim tls.yml 
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: nginx-test
spec:
  tls:
    - hosts:
      - www1.westos.org
      secretName: tls-secret
  rules:
    - host: www1.westos.org
      http:
        paths:
        - path: /
          backend:
            serviceName: myservice
            servicePort: 80
[root@server2 ingress-nginx]# kubectl apply -f tls.yml
[root@server2 ingress-nginx]# kubectl describe ingress nginx-test
[root@server2 ingress-nginx]# kubectl get ingress

在这里插入图片描述

认证

[root@server2 ingress-nginx]# yum install httpd-tools.x86_64 -y
[root@server2 ingress-nginx]# htpasswd -c auth sun
[root@server2 ingress-nginx]# kubectl create secret generic basic-auth --from-file=auth

在这里插入图片描述

[root@server2 ingress-nginx]# vim tls.yml
  annotations:
    nginx.ingress.kubernetes.io/auth-type: basic
    nginx.ingress.kubernetes.io/auth-secret: basic-auth
[root@server2 ingress-nginx]# kubectl apply -f tls.yml
[root@server2 ingress-nginx]# kubectl apply -f nginx.yml

在这里插入图片描述

Ingress地址重写

vim tls.yml
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: nginx-test
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
    - host: www1.westos.org
      http:
        paths:
        - backend:
            serviceName: myservice
            servicePort: 80
          path: /westos(/|$)(.*)

kubectl apply -f tls.yml
curl www1.westos.org == curl www1.westos.org/westos

annotations参数

K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 | 韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。长夜有穷，真水无香。领略过了 K8s“身在江

K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub