k8s网络通信

k8s网络通信

(一)k8s通过CNI接口接入其他插件来实现网络通讯。目前比较流行的插件有flannel,calico等
CNI插件存放位置:# cat /etc/cni/net.d/10-flannel.conflist
(二)插件使用的解决方案如下:
虚拟网桥,虚拟网卡,多个容器共用一个虚拟网卡进行通信。
多路复用:MacVLAN,多个容器共用一个物理网卡进行通信。
硬件交换:SR-LOV,一个物理网卡可以虚拟出多个接口,这个性能最好。
(三)各个节点网络通信
1.容器间通信:同一个pod内的多个容器间的通信,通过lo即可实现;
2.pod之间的通信:
(1)同一节点的pod之间通过cni网桥转发数据包
(2)不同节点的pod之间的通信需要网络插件支持
3.pod和service通信: 通过iptables或ipvs实现通信,ipvs取代不了iptables,因为ipvs只能做负载均衡,而做不了nat转换。
4.pod和外网通信:iptables的MASQUERADE。
5.Service与集群外部客户端的通信;(ingress、nodeport、loadbalancer)

(四)Service与集群外部客户端的通信
kubectl get services kube-dns --namespace=kube-system #Kubernetes 提供了一个 DNS 插件 Service
1.仅集群内部访问
(1).ClusterIP方式(默认方式)

接上面建立的
kubectl describe svc myservice1
dig myservice1.default.svc.cluster.local. @10.96.0.10

在这里插入图片描述
在这里插入图片描述
(2).Headless Service “无头服务”
Headless Service不需要分配一个VIP,而是直接以DNS记录的方式解析出被代理Pod的IP地址

域名格式:$(servicename).$(namespace).svc.cluster.local=myservice.default.svc.cluster.local.
vim demo.yml
---
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  selector:
    app: myapp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  #externalIPs:  #下面的2(3)
  #- 172.25.2.100
  clusterIP: None
  #type: NodePort  #下面的2(1)
  #type: LoadBalancer  #下面的2(2)
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:v1

kubectl apply -f demo.yml
kubectl get svc
kubectl run test --image=busyboxplus -it
# Pod滚动更新后,依然可以解析

在这里插入图片描述
在这里插入图片描述
2.从外部访问 Service
(1).NodePort方式
在这里插入图片描述
在这里插入图片描述
(2)LoadBalancer
适用于公有云上的 Kubernetes 服务,在service提交后,Kubernetes就会调用 CloudProvider 在公有云上为你创建一个负载均衡服务,并且把被代理的 Pod 的 IP地址配置给负载均衡服务做后端
在这里插入图片描述
(3)service允许为其分配一个公有IP
在这里插入图片描述
(4)ExternalName

vim ex-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type:  ExternalName
  externalName: www.baidu.com
  
kubectl apply -f ex-service.yaml
kubectl get svc

kubectl attach test -it  #两种测试方法
dig -t A my-service.default.svc.cluster.local. @10.96.0.10

在这里插入图片描述
在这里插入图片描述
(五)Flannel vxlan模式跨主机通信原理
在这里插入图片描述
1.flannel网络
VXLAN,即Virtual Extensible LAN(虚拟可扩展局域网),是Linux本身支持的一网种网络虚拟化技术。VXLAN可以完全在内核态实现封装和解封装工作,从而通过“隧道”机制,构建出覆盖网络(Overlay Network)。
VTEP:VXLAN Tunnel End Point(虚拟隧道端点),在Flannel中 VNI的默认值是1,这也是为什么宿主机的VTEP设备都叫flannel.1的原因。
Cni0: 网桥设备,每创建一个pod都会创建一对 veth pair。其中一端是pod中的eth0,另一端是Cni0网桥中的端口(网卡)。
Flannel.1: TUN设备(虚拟网卡),用来进行 vxlan 报文的处理(封包和解包)。不同node之间的pod数据流量都从overlay设备以隧道的形式发送到对端。
Flanneld:flannel在每个主机中运行flanneld作为agent,它会为所在主机从集群的网络地址空间中,获取一个小的网段subnet,本主机内所有容器的IP地址都将从中分配。同时Flanneld监听K8s集群数据库,为flannel.1设备提供封装数据时必要的mac、ip等网络数据信息。
2.flannel网络原理
(1)当容器发送IP包,通过veth pair 发往cni网桥,再路由到本机的flannel.1设备进行处理。
(2)VTEP设备之间通过二层数据帧进行通信,源VTEP设备收到原始IP包后,在上面加上一个目的MAC地址,封装成一个内部数据帧,发送给目的VTEP设备。
(3)内部数据桢,并不能在宿主机的二层网络传输,Linux内核还需要把它进一步封装成为宿主机的一个普通的数据帧,承载着内部数据帧通过宿主机的eth0进行传输。
(4)Linux会在内部数据帧前面,加上一个VXLAN头,VXLAN头里有一个重要的标志叫VNI,它是VTEP识别某个数据桢是不是应该归自己处理的重要标识。
(5)flannel.1设备只知道另一端flannel.1设备的MAC地址,却不知道对应的宿主机地址是什么。在linux内核里面,网络设备进行转发的依据,来自FDB的转发数据库,这个flannel.1网桥对应的FDB信息,是由flanneld进程维护的。
(6)linux内核在IP包前面再加上二层数据帧头,把目标节点的MAC地址填进去,MAC地址从宿主机的ARP表获取。
(7)此时flannel.1设备就可以把这个数据帧从eth0发出去,再经过宿主机网络来到目标节点的eth0设备。目标主机内核网络栈会发现这个数据帧有VXLAN Header,并且VNI为1,Linux内核会对它进行拆包,拿到内部数据帧,根据VNI的值,交给本机flannel.1设备处理,flannel.1拆包,根据路由表发往cni网桥,最后到达目标容器
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

server3 src:10.244.1.67 -> server4 dst:10.244.2.67

a.yml文件接上面配置,service使用默认ClusterIP,在server3上要先知道目标主机(server4)eth0的IP和mac地址
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
b.在server3上是有server4的eth0的IP和mac地址的
在这里插入图片描述
在这里插入图片描述
c.在server4上抓包,查看
在这里插入图片描述
在这里插入图片描述
3.flannel支持多种后端:
(1)Vxlan
vxlan #报文封装,默认
Directrouting #直接路由,跨网段使用vxlan,同网段使用host-gw模式。
(2)host-gw #主机网关,性能好,但只能在二层网络中,不支持跨网络,如果有成千上万的Pod,容易产生广播风暴,不推荐
(3)UDP #性能差,不推荐

# host-gw
kubectl -n kube-system edit cm kube-flannel-cfg
kubectl get pod -n kube-system |grep kube-flannel| awk '{system("kubectl delete pod "$1" -n kube-system")}'

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

# vxlan
# Directrouting
kubectl -n kube-system edit cm kube-flannel-cfg
kubectl get pod -n kube-system |grep kube-flannel| awk '{system("kubectl delete pod "$1" -n kube-system")}'

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

ingress实质在ingress-nginx命名空间创建ingress-nginx-controller-456pj (pod),通过Ingress服务(yaml)文件控制ingress-nginx-controller-456pj,实则修改了pod内的nginx配置文件,也可以创建多个虚拟主机,通过nginx服务对后端服务实现调度
在这里插入图片描述
NGINX Ingress Controller
1.部署

# 下载镜像并上传到本地仓库,镜像下载需要翻墙
server1
docker load -i ingress-nginx.tar
docker tag quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.33.0 reg.westos.org/library/nginx-ingress-controller:0.33.0
docker tag jettech/kube-webhook-certgen:v1.2.0 reg.westos.org/library/kube-webhook-certgen:v1.2.0
docker push reg.westos.org/library/nginx-ingress-controller:0.33.0
docker push reg.westos.org/library/kube-webhook-certgen:v1.2.0

server2
mkdir /root/ingress
cd /root/ingress
# Ingress controlle
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/mandatory.yaml  #下载参考文件,并修改

kubectl apply -f deploy.yaml
kubectl get ns
kubectl -n ingress-nginx get pod

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

# Ingress服务
cd /root/ingress
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

kubectl apply -f nginx.yml

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
用DaemonSet结合nodeselector来部署ingress-controller到特定的node上,这块ingress控制器在server4上,然后使用HostNetwork直接把该pod与宿主机node的网络打通,直接使用宿主机的80/443端口就能访问服务。
优点是整个请求链路最简单,性能相对NodePort模式更好。
缺点是由于直接利用宿主机节点的网络和端口,一个node只能部署一个ingress-controller pod。
比较适合大并发的生产环境使用
在这里插入图片描述
2.Ingress TLS 配置

openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=nginxsvc/O=nginxsvc"  #/CN/O写成自己定义的域名,不然会导致使用默认加密认证
kubectl create secret tls tls-secret --key tls.key --cert tls.crt
kubectl get secrets 

在这里插入图片描述

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

kubectl apply -f tls.yml
kubectl describe ingress nginx-test
kubectl get ingress

在这里插入图片描述
在这里插入图片描述
3.身份验证

yum install httpd-tools -y
htpasswd -c auth wxh
kubectl create secret generic basic-auth --from-file=auth

在这里插入图片描述

vim tls.yml
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: nginx-test
  annotations:
    nginx.ingress.kubernetes.io/auth-type: basic
    nginx.ingress.kubernetes.io/auth-secret: basic-auth
spec:
  tls:
    - hosts:
      - www1.westos.org
      secretName: tls-secret
  rules:
    - host: www1.westos.org
      http:
        paths:
        - path: /
          backend:
            serviceName: myservice
            servicePort: 80

kubectl apply -f tls.yml

在这里插入图片描述
4.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

在这里插入图片描述
在这里插入图片描述

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值