精华内容
下载资源
问答
  • docker网络 bridge(桥接网络) joined (联盟式网络 共享使用另外容器的网络) opened(开放式网络 直接共享宿主机网络) none bridge网络 ...kubernetes网络通信 容器间通信: 同一个pod内的多个容器间通信...

    https://kubernetes.io/docs/concepts/cluster-administration/networking/

    docker网络

    • bridge(桥接网络)
    • joined (联盟式网络 共享使用另外容器的网络)
    • opened(开放式网络 直接共享宿主机网络)
    • none

    bridge网络

    在这里插入图片描述

    在这里插入图片描述

    kubernetes网络通信

    kubernetes设计了网络模型,却将它的实现交给了网络插件,CNI网络插件最主要的功能就是实现pod资源能够跨宿主机进行通信

    • 容器间通信: 同一个pod内的多个容器间通信,lo
    • pod通信: pod IP <------> pod IP
    • pod与service通信: pod IP <------> clusterIP
    • service与集群外部客户端通信

    CNI插件

    • flannel
    • calico
    • canel
    • kube-router
    • contiv
    • opencontrail
    • NSX-T

    网络解决方案

    • 虚拟网桥
    • 多路复用(macvlan)
    • 硬件交换(SR-IOV(单根io虚拟化))

    flannel支持多种后端

    • VxLAN
      • directrouting
        如果节点在同一网络中,使用host-gw
        如果节点不在同一网络中,则降级使用vxlan
      • vxlan
        在这里插入图片描述

    在这里插入图片描述

    • host-gw (host gateway)

    在这里插入图片描述

    在这里插入图片描述

    • UDP

    flannel网络配置

    https://github.com/coreos/flannel#flannel

    使用CIDR格式的网络地址,用于为pod配置网络功能

    • 10.254.0.0/16
      • master: 10.254.0.0/24
      • node1: 10.254.1.0/24
      • node255: 10.254.255.0/24

    SubnetLen: 把network切分子网供各节点使用时,使用多长的掩码进行切分,默认为24位
    SubnetMin: 10.254.10.0/24
    SubnetMax: 10.254.100.0/24
    Backend: vxlan, host-gw, udp

    {
     "Network": "10.254.0.0/16",
     "Backend": {
        "Type": "vxlan",
        "Directrouting": true
     }
    }
    

    https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

    ---
    apiVersion: policy/v1beta1
    kind: PodSecurityPolicy
    metadata:
      name: psp.flannel.unprivileged
      annotations:
        seccomp.security.alpha.kubernetes.io/allowedProfileNames: docker/default
        seccomp.security.alpha.kubernetes.io/defaultProfileName: docker/default
        apparmor.security.beta.kubernetes.io/allowedProfileNames: runtime/default
        apparmor.security.beta.kubernetes.io/defaultProfileName: runtime/default
    spec:
      privileged: false
      volumes:
        - configMap
        - secret
        - emptyDir
        - hostPath
      allowedHostPaths:
        - pathPrefix: "/etc/cni/net.d"
        - pathPrefix: "/etc/kube-flannel"
        - pathPrefix: "/run/flannel"
      readOnlyRootFilesystem: false
      # Users and groups
      runAsUser:
        rule: RunAsAny
      supplementalGroups:
        rule: RunAsAny
      fsGroup:
        rule: RunAsAny
      # Privilege Escalation
      allowPrivilegeEscalation: false
      defaultAllowPrivilegeEscalation: false
      # Capabilities
      allowedCapabilities: ['NET_ADMIN']
      defaultAddCapabilities: []
      requiredDropCapabilities: []
      # Host namespaces
      hostPID: false
      hostIPC: false
      hostNetwork: true
      hostPorts:
      - min: 0
        max: 65535
      # SELinux
      seLinux:
        # SELinux is unused in CaaSP
        rule: 'RunAsAny'
    ---
    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: flannel
    rules:
      - apiGroups: ['extensions']
        resources: ['podsecuritypolicies']
        verbs: ['use']
        resourceNames: ['psp.flannel.unprivileged']
      - apiGroups:
          - ""
        resources:
          - pods
        verbs:
          - get
      - apiGroups:
          - ""
        resources:
          - nodes
        verbs:
          - list
          - watch
      - apiGroups:
          - ""
        resources:
          - nodes/status
        verbs:
          - patch
    ---
    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: flannel
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: flannel
    subjects:
    - kind: ServiceAccount
      name: flannel
      namespace: kube-system
    ---
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: flannel
      namespace: kube-system
    ---
    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: kube-flannel-cfg
      namespace: kube-system
      labels:
        tier: node
        app: flannel
    data:
      cni-conf.json: |
        {
          "name": "cbr0",
          "cniVersion": "0.3.1",
          "plugins": [
            {
              "type": "flannel",
              "delegate": {
                "hairpinMode": true,
                "isDefaultGateway": true
              }
            },
            {
              "type": "portmap",
              "capabilities": {
                "portMappings": true
              }
            }
          ]
        }
      net-conf.json: |
        {
          "Network": "10.244.0.0/16",
          "Backend": {
            "Type": "vxlan",
            "Directrouting": true
          }
        }
    ---
    apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      name: kube-flannel-ds-amd64
      namespace: kube-system
      labels:
        tier: node
        app: flannel
    spec:
      selector:
        matchLabels:
          app: flannel
      template:
        metadata:
          labels:
            tier: node
            app: flannel
        spec:
          affinity:
            nodeAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                nodeSelectorTerms:
                  - matchExpressions:
                      - key: beta.kubernetes.io/os
                        operator: In
                        values:
                          - linux
                      - key: beta.kubernetes.io/arch
                        operator: In
                        values:
                          - amd64
          hostNetwork: true
          tolerations:
          - operator: Exists
            effect: NoSchedule
          serviceAccountName: flannel
          initContainers:
          - name: install-cni
            image: quay.io/coreos/flannel:v0.11.0-amd64
            command:
            - cp
            args:
            - -f
            - /etc/kube-flannel/cni-conf.json
            - /etc/cni/net.d/10-flannel.conflist
            volumeMounts:
            - name: cni
              mountPath: /etc/cni/net.d
            - name: flannel-cfg
              mountPath: /etc/kube-flannel/
          containers:
          - name: kube-flannel
            image: quay.io/coreos/flannel:v0.11.0-amd64
            command:
            - /opt/bin/flanneld
            args:
            - --ip-masq
            - --kube-subnet-mgr
            resources:
              requests:
                cpu: "100m"
                memory: "50Mi"
              limits:
                cpu: "100m"
                memory: "50Mi"
            securityContext:
              privileged: false
              capabilities:
                add: ["NET_ADMIN"]
            env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
            volumeMounts:
            - name: run
              mountPath: /run/flannel
            - name: flannel-cfg
              mountPath: /etc/kube-flannel/
          volumes:
            - name: run
              hostPath:
                path: /run/flannel
            - name: cni
              hostPath:
                path: /etc/cni/net.d
            - name: flannel-cfg
              configMap:
                name: kube-flannel-cfg
    ---
    apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      name: kube-flannel-ds-arm64
      namespace: kube-system
      labels:
        tier: node
        app: flannel
    spec:
      selector:
        matchLabels:
          app: flannel
      template:
        metadata:
          labels:
            tier: node
            app: flannel
        spec:
          affinity:
            nodeAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                nodeSelectorTerms:
                  - matchExpressions:
                      - key: beta.kubernetes.io/os
                        operator: In
                        values:
                          - linux
                      - key: beta.kubernetes.io/arch
                        operator: In
                        values:
                          - arm64
          hostNetwork: true
          tolerations:
          - operator: Exists
            effect: NoSchedule
          serviceAccountName: flannel
          initContainers:
          - name: install-cni
            image: quay.io/coreos/flannel:v0.11.0-arm64
            command:
            - cp
            args:
            - -f
            - /etc/kube-flannel/cni-conf.json
            - /etc/cni/net.d/10-flannel.conflist
            volumeMounts:
            - name: cni
              mountPath: /etc/cni/net.d
            - name: flannel-cfg
              mountPath: /etc/kube-flannel/
          containers:
          - name: kube-flannel
            image: quay.io/coreos/flannel:v0.11.0-arm64
            command:
            - /opt/bin/flanneld
            args:
            - --ip-masq
            - --kube-subnet-mgr
            resources:
              requests:
                cpu: "100m"
                memory: "50Mi"
              limits:
                cpu: "100m"
                memory: "50Mi"
            securityContext:
              privileged: false
              capabilities:
                 add: ["NET_ADMIN"]
            env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
            volumeMounts:
            - name: run
              mountPath: /run/flannel
            - name: flannel-cfg
              mountPath: /etc/kube-flannel/
          volumes:
            - name: run
              hostPath:
                path: /run/flannel
            - name: cni
              hostPath:
                path: /etc/cni/net.d
            - name: flannel-cfg
              configMap:
                name: kube-flannel-cfg
    ---
    apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      name: kube-flannel-ds-arm
      namespace: kube-system
      labels:
        tier: node
        app: flannel
    spec:
      selector:
        matchLabels:
          app: flannel
      template:
        metadata:
          labels:
            tier: node
            app: flannel
        spec:
          affinity:
            nodeAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                nodeSelectorTerms:
                  - matchExpressions:
                      - key: beta.kubernetes.io/os
                        operator: In
                        values:
                          - linux
                      - key: beta.kubernetes.io/arch
                        operator: In
                        values:
                          - arm
          hostNetwork: true
          tolerations:
          - operator: Exists
            effect: NoSchedule
          serviceAccountName: flannel
          initContainers:
          - name: install-cni
            image: quay.io/coreos/flannel:v0.11.0-arm
            command:
            - cp
            args:
            - -f
            - /etc/kube-flannel/cni-conf.json
            - /etc/cni/net.d/10-flannel.conflist
            volumeMounts:
            - name: cni
              mountPath: /etc/cni/net.d
            - name: flannel-cfg
              mountPath: /etc/kube-flannel/
          containers:
          - name: kube-flannel
            image: quay.io/coreos/flannel:v0.11.0-arm
            command:
            - /opt/bin/flanneld
            args:
            - --ip-masq
            - --kube-subnet-mgr
            resources:
              requests:
                cpu: "100m"
                memory: "50Mi"
              limits:
                cpu: "100m"
                memory: "50Mi"
            securityContext:
              privileged: false
              capabilities:
                 add: ["NET_ADMIN"]
            env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
            volumeMounts:
            - name: run
              mountPath: /run/flannel
            - name: flannel-cfg
              mountPath: /etc/kube-flannel/
          volumes:
            - name: run
              hostPath:
                path: /run/flannel
            - name: cni
              hostPath:
                path: /etc/cni/net.d
            - name: flannel-cfg
              configMap:
                name: kube-flannel-cfg
    ---
    apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      name: kube-flannel-ds-ppc64le
      namespace: kube-system
      labels:
        tier: node
        app: flannel
    spec:
      selector:
        matchLabels:
          app: flannel
      template:
        metadata:
          labels:
            tier: node
            app: flannel
        spec:
          affinity:
            nodeAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                nodeSelectorTerms:
                  - matchExpressions:
                      - key: beta.kubernetes.io/os
                        operator: In
                        values:
                          - linux
                      - key: beta.kubernetes.io/arch
                        operator: In
                        values:
                          - ppc64le
          hostNetwork: true
          tolerations:
          - operator: Exists
            effect: NoSchedule
          serviceAccountName: flannel
          initContainers:
          - name: install-cni
            image: quay.io/coreos/flannel:v0.11.0-ppc64le
            command:
            - cp
            args:
            - -f
            - /etc/kube-flannel/cni-conf.json
            - /etc/cni/net.d/10-flannel.conflist
            volumeMounts:
            - name: cni
              mountPath: /etc/cni/net.d
            - name: flannel-cfg
              mountPath: /etc/kube-flannel/
          containers:
          - name: kube-flannel
            image: quay.io/coreos/flannel:v0.11.0-ppc64le
            command:
            - /opt/bin/flanneld
            args:
            - --ip-masq
            - --kube-subnet-mgr
            resources:
              requests:
                cpu: "100m"
                memory: "50Mi"
              limits:
                cpu: "100m"
                memory: "50Mi"
            securityContext:
              privileged: false
              capabilities:
                 add: ["NET_ADMIN"]
            env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
            volumeMounts:
            - name: run
              mountPath: /run/flannel
            - name: flannel-cfg
              mountPath: /etc/kube-flannel/
          volumes:
            - name: run
              hostPath:
                path: /run/flannel
            - name: cni
              hostPath:
                path: /etc/cni/net.d
            - name: flannel-cfg
              configMap:
                name: kube-flannel-cfg
    ---
    apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      name: kube-flannel-ds-s390x
      namespace: kube-system
      labels:
        tier: node
        app: flannel
    spec:
      selector:
        matchLabels:
          app: flannel
      template:
        metadata:
          labels:
            tier: node
            app: flannel
        spec:
          affinity:
            nodeAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                nodeSelectorTerms:
                  - matchExpressions:
                      - key: beta.kubernetes.io/os
                        operator: In
                        values:
                          - linux
                      - key: beta.kubernetes.io/arch
                        operator: In
                        values:
                          - s390x
          hostNetwork: true
          tolerations:
          - operator: Exists
            effect: NoSchedule
          serviceAccountName: flannel
          initContainers:
          - name: install-cni
            image: quay.io/coreos/flannel:v0.11.0-s390x
            command:
            - cp
            args:
            - -f
            - /etc/kube-flannel/cni-conf.json
            - /etc/cni/net.d/10-flannel.conflist
            volumeMounts:
            - name: cni
              mountPath: /etc/cni/net.d
            - name: flannel-cfg
              mountPath: /etc/kube-flannel/
          containers:
          - name: kube-flannel
            image: quay.io/coreos/flannel:v0.11.0-s390x
            command:
            - /opt/bin/flanneld
            args:
            - --ip-masq
            - --kube-subnet-mgr
            resources:
              requests:
                cpu: "100m"
                memory: "50Mi"
              limits:
                cpu: "100m"
                memory: "50Mi"
            securityContext:
              privileged: false
              capabilities:
                 add: ["NET_ADMIN"]
            env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
            volumeMounts:
            - name: run
              mountPath: /run/flannel
            - name: flannel-cfg
              mountPath: /etc/kube-flannel/
          volumes:
            - name: run
              hostPath:
                path: /run/flannel
            - name: cni
              hostPath:
                path: /etc/cni/net.d
            - name: flannel-cfg
              configMap:
                name: kube-flannel-cfg
    
    展开全文
  • 1.Kubernetes网络通信 (1) 容器间通信 同一个Pod内的多个容器间的通信, lo (2)Pod通信 Pod IP <-(直达)-> Pod IP 意思就是pod和pod之间使用自己的IP不经过任何转换直达,通信双方所见的地址就是双方的地址 ...

    1.Kubernetes网络通信

    (1) 容器间通信
    同一个Pod内的多个容器间的通信, lo
    (2)Pod通信
    Pod IP <-(直达)-> Pod IP 意思就是pod和pod之间使用自己的IP不经过任何转换直达,通信双方所见的地址就是双方的地址
    (3)Pod与Service通信
    PodIP <–> ClusterIP IPVS和iptables规则可以实现,ipvs可以做负载但是无法取代iptables,因为很多功能ipvs做不到
    (4)Service与集群外部客户端的通信
    Nodeport,ingress等等

    2.K8s网络解决方案

    (1)方案介绍
    ①k8s网络实现要靠网络插件–CNI(容器Container 网络Network 接口Interface)
    ②K8s本身不提供网络解决方案,允许托管去使用第三方的任何解决方案来代为解决k8s集群中这4种通信模型当中的需要执行的通信问题任何一种程序都可以(简单来说就是用第三方插件解决4中k8s集群的通信模型,能解决就可以用)
    ③CNI:flannel、calico、canel、cube-router
    (2)方案所涉及的技术
    ①虚拟网桥
    隧道or叠加网络,可以实现更强的控制功能但是开销会比较大
    能保证pod和容器有专用的网络接口,一半留在pod或者容器上,一半留在宿主机上接入到网桥中去使用,类似于docker的bridge
    ② 多路复用
    MacVLAN----基于Mac的方式去创建VLAN(为每个虚拟接口配置一个独有的Mac,让一个物理网卡可以承载多个容器去使用,这样子直接使用物理网卡,并基于物理网卡中的MacVLAN去跨节点通信)
    ③ 硬件交换
    SR-IOV-----单根IO虚拟化(一个物理网卡可以直接虚拟多个网卡,直接给容器使用)

    3.加载配置文件
    Kubelet在启动时直接通过路径去加载配置文件 /etc/cni/net.d
    任何其他网络插件部署完以后,也要把配置文件仍在这个路径下,从而被kubelet所加载,从而可以被kubelet作为必要时创建一个pod,pod要有网络,那么kubelet就调用这个目录下的配置文件,由网络插件代为实现地址分配,网络创建,接口创建等各种功能这叫CNI
    [root@k8s-master net.d]# pwd
    /etc/cni/net.d
    [root@k8s-master net.d]# cat 10-flannel.conflist

    {
      "name": "cbr0",               
      "plugins": [                 #插件类型
        {
          "type": "flannel",        
          "delegate": {             #授权使用方式
            "hairpinMode": true,
            "isDefaultGateway": true
          }
        },
        {
          "type": "portmap",       #类型
          "capabilities": {
            "portMappings": true  #支持端口映射(叠加网络)
          }
        }
      ]
    }
    

    4.网络插件功能介绍

    (1)flannel简介
    网络插件flannel最为简单,但是缺点是在k8s集群上网络插件不仅仅要实现网络地址分配,网络管理等功能,还要实现网络策略,flannel不支持网络策略
    (2)策略的重要性
    虽然k8s有命名空间管理隔离,和所谓管理隔离就是说rolebinding的user是无法对其他命名空间的资源做管控,但是他可以控制自己的pod去访问别的命名空间的pod的,比如两个项目之间互相不认识,但是pod访问pod万一出事,容易背锅,那么我们继续要一些网络插件进行设置pod与pod访问策略之类的
    (3)解决方案
    基本解决方案可以先使用flannel然后需要策略的时候去加calico,虽然加calico但是不让他做网络地址分配等等的工作,只让他做策略,这样就没必要用canel这种合起来的

    5.flannel的三种模式

    后端传输方式:下面的长条封装报文守护分别是 以太网、IP、UDP、VxLAN (额外的开销)所以说基于VxLAN性能可能会低,但是可以独立管理一个网络跟物理不冲突
    flannel:
    支持多种后端:
    (1)VxLAN (扩展的虚拟局域网)
    在这里插入图片描述
    (1) vxlan
    (2) Directrouting
    支持同一网段我们使用直接路由通信(源和目标在同意网络),如果不在同一网段我们就使用VxLAN

    后端传输方式:下面的长条封装报文守护分别是 以太网、IP、UDP、VxLAN (额外的开销)所以说基于VxLAN性能可能会低,但是可以独立管理一个网络跟物理不冲突

    (2)host-gw: Host Gateway (主机网关
    在这里插入图片描述

    在node节点上虚拟一个虚拟网卡,所有pod都是虚拟网卡所属网段,那么通过路由条目,路由转发可以送达至其他node节点,虽然这种方式性能高,但是面临的就是说如果node节点数量过多,路由条目会非常大,并且一旦有广播报文所有都会受到波及,而且所有node节点必须工作再同一个2层或3层网络

    (3)UDP(性能极差)

    6.配置flannel的模式

    (1)configmap配置参数介绍
    flannel的配置参数:
    Network:flannel使用的CIDR格式的网络地址,用于为Pod配置网络功能;
    10.244.0.0/16 ->
    master: 10.244.0.0/24
    node01: 10.244.1.0/24

    node255: 10.244.255.0/24
    10.0.0.0/8
    10.0.0.0/24

    10.255.255.0/24
    SubnetLen:把Network切分子网供各节点使用时,使用多长的掩码进行切分,默认为24位;
    SubnetMin:10.244.10.0/24
    SubnetMax: 10.244.100.0/24
    Backend:vxlan, host-gw, udp
    vxlan:
    (2)修改VxLAN改为Directrouting
    因为我们把flannel封装为容器运行了,所以修改flannel的configmap
    方法1(不推荐)
    kubectl edit configmaps -n kube-system kube-flannel-cfg

      net-conf.json: |
        {
          "Network": "10.244.0.0/16",
          "Backend": {
            "Type": "vxlan",
            "Directrouting": true            #修改这个参数切记  vxlan后面会有个逗号
          }
        }
    

    修改完以后需要重启所有节点的flannel
    方法2(推荐)
    准备好flannel的yaml文件,直接修改yaml文件

      net-conf.json: |
        {
          "Network": "10.244.0.0/16",
          "Backend": {
            "Type": "vxlan",           #注意这里有个逗号
            "Directrouting": true
          }
        }
    

    kubectl apply -f kube-flannel.yml
    如果你的flannel没有作过其他的改动可以直接应用,如果作过网段之间的什么修改的话,需要查看是否一致,然后再进行应用,前面提到过就是说apply和edit或者create之间不要混着用,所以既然我们apply声明的flannel,那么我们最好也是apply应用一下
    测试方法(测试是否修改成功)
    修改之前
    在这里插入图片描述
    改完以后

    在这里插入图片描述
    可以在node节点分别来一个pod,用节点1的pod去ping节点2的 然后在node1上抓包
    在这里插入图片描述
    在这里插入图片描述

    如果他还是隧道的话 我们在ens33上面是抓不到icmp的因为已经封装为udp了
    注意:需要注意的是就是说这个网络策略应该是在装好k8s集群以后就该有的策略,而不是半途改的,因为修改需要重启flannel,可能会导致服务出现问题,所以我们需要提前想到这个问题,而且这个配置仅是为了可能集群内node节点过多,网络性能出现瓶颈

    展开全文
  • 微信公众号搜索 DevOps和k8s全栈技术 ,即可关注,也可扫描文章最后的二维码关注公众号,每天会分享技术文章供大家参考阅读哈~docker的四种网络类型(1)bridge:这是Doc...

    微信公众号搜索 DevOps和k8s全栈技术 ,即可关注,也可扫描文章最后的二维码关注公众号,每天会分享技术文章供大家参考阅读哈~

    docker的四种网络类型

    (1)bridge:这是Docker默认的网络驱动,此模式会为每一个容器分配NetworkNamespace和设置IP等,并将容器连接到一个虚拟网桥上,如果未指定网络驱动,就默认使用此驱动。

    (2)host:此网络驱动直接使用宿主机的网络。

    (3)none:此驱动不构造网络环境,如果采用了none网络驱动,那么就只能使用loopback网络设备,容器只能使用127.0.0.1的本机网络。

    (4)overlay:可以实现容器跨主机通信

    Bridge网络介绍

    1.网络模型图

    2.Bridge网络的构建过程,对上图的各个网络名称做解释说明

    (1)安装Docker时,创建一个名为docke0的虚拟网桥,虚拟网桥使用“10.0.0.0-10.255.255.255 “、”172.16.0.0-172.31.255.255″和“192.168.0.0——192.168.255.255”这三个私有网络的地址范围。

    通过 ifconfig命令可以查看docker0网桥的信息:

      通过 docker network inspect bridge 可以查看网桥的子网网络范围和网关:

    2)运行容器时,会在宿主机上创建虚拟网卡vethpair设备,vethpair设备是成对出现的,从而组成一个数据通道,数据从一个设备进入,就会从另一个设备出来。将vethpair设备的一端放在新创建的容器中,命名为eth0;另一端放在宿主机的docker0中,以veth为前缀的名字命名。通过brctlshow 命令查看放在docker0中的veth pair设备

    ifconfig

    brctl show

    3.外部访问

    bridgedocker0是虚拟出来的网桥,因此无法被外部的网络访问。因此需要在运行容器时通过-p-P参数将容器的端口映射到宿主机上相应的端口。实际上Docker是采用NAT的方式,将容器内部的服务监听端口与宿主机的某一个端口port 进行绑定,使得宿主机外部可以将网络报文发送至容器。

    1)通过-P参数,将容器的端口映射到宿主机的随机端口:

    docker run -P {images}

    2)通过-p参数,将容器的端口映射到宿主机的制定端口:

    docker run -p {hostPort}:{containerPort} {images}

    kubernetes常见的网络通信方式

    1.pod内部容器间的通信:同一个pod内的多个容器间的通信

    2.pod和pod之间的通信:从一个pod Ip到另一个pod Ip

    3.pod与service通信:pod ip到serviceip

    (1)pod内部容器之间通信

    pod内部的容器是共享网络名称空间的,所以容器直接可以使用localhost访问其他容器;k8s在启动容器的时候会先启动一个Pause容器,这个容器就是实现这个功能的。

    pause:

    每个Pod里运行着一个特殊的被称之为Pause的容器,其他容器则为业务容器,这些业务容器共享Pause容器的网络栈和Volume存储卷,因此他们之间通信和数据交换更为高效,在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中。

    (2)pod与pod之间的通信

    此种类型又分为两种情况:

     两个pod在同一台节点上:此时是利用docker默认的网桥bridge方式互连容器的。
    
    两个pod在不同节点上:这种情况k8s官方推荐的是使用flannel网络,pod的ip分配由flannel统一分配,通讯过程也是走flannel的网桥方式。
    

    (3)pod与service服务之间的通信

    通过暴露主机IP和端口的形式进行通讯

    要解决上面的几种通信问题,需要靠CNI网络插件实现

    要解决上面四种通信的问题,需要靠CNI插件接口:

    kubernetes中的网络插件

    Kubernetes中常见的网络插件有哪些?

    1.flannel:能提供ip地址,但不支持网络策略

    2.calico:既提供ip地址,又支持网络策略

    3.canalflannelcalico结合,通过flannel提供ip地址,calico提供网络策略

    什么叫做网络策略?

    网络策略:可以达到多租户网络隔离,可以控制入网和出网流量,入网和出网ip访问的一种策略

    flannel

    一、flannel介绍

    FlannelCoreOS团队针对Kubernetes设计的一个网络服务,它的功能是让集群中的不同节点创建的Docker容器都具有全集群唯一的虚拟IP地址,Flannel的设计目的就是为集群中的所有节点重新规划IP地址,从而使得不同节点上的容器能够获得“同属一个内网”且”不重复的”IP地址,并让属于不同节点上的容器能够直接通过内网IP通信,Flannel实质上是一种“覆盖网络(overlaynetwork)”,也就是将TCP数据包装在另一种网络包里面进行路由转发和通信,目前已经支持udpvxlanhost-gwaws-vpcgce路由等数据转发方式。

    二、flannel支持的路由转发方式

    1.vxlan,包含以下两种模式

     (1) vxlan:叠加网络模式,利用内核级别的VXLAN来封装host之间传送的包;

     (2) Directrouting:直接路由模式,当主机位于同一子网时,启用直接路由(类似host-gw),通过宿主机的物理网卡通信;

    2.host-gw:直接路由模式,要求所有pod在同一个网段中,host-gw性能好,依赖少,并且易于设置

    3.UDP: 不可用于生产环境,仅在内核或网络无法使用VXLANhost-gw时,用 UDP 进行调试。

    三、flannel网络原理图

    原理图解释说明

    1.网卡和组件说明

    安装flannel时会创建一个名为flannel0的网桥,这个网桥的一端连接docker0的网桥,另一端连接一个名为flanneld的服务进程。

    Flanneld守护进程:它需要连etcd,利用etcd来管理可分配的IP资源,同时监控etcd中每个Pod的实际地址,将docker0发给它的数据包装起来,利用物理网络的连接将数据包投递到目标flanneld上,从而完成podpod之间的通信

    2.ping包走向

    1)数据从源容器中发出后,经由所在主机的docker0虚拟网卡转发到flannel0虚拟网卡,flanneld服务监听在网卡的另外一端。

    2)源主机的flanneld服务将原本的数据内容封装成一个数据包,然后根据自己的路由表投递给目的节点的flanneld服务,数据到达以后被解包,然后直接进入目的节点的flannel0虚拟网卡,然后被转发到目的主机的docker0虚拟网卡,最后就像本机容器通信一样由docker0路由到达目标容器。

    注:

    flannel通过Etcd分配了每个节点可用的IP地址段后,可以保证每个结点上容器分配的地址不冲突。

    四、flannel的原理

    flannel旨在解决不同节点上的容器网络互联问题,大致原理是为每个 host 分配一个子网,容器从此子网中分配IP,这些 IP可以在 host间路由,容器间无需 NAT 转发就可以跨主机通信,为了在各个主机间共享信息,flannel etcd(如果是k8s集群会直接调用k8s api)存放网络配置、已分配的子网、主机ip等信息。

    通过具体例子解释容器跨节点通信时数据包走向

    假设容器1nginx,容器2tomcat

    1)在发送端的node1节点上,数据请求从nginx容器(10.0.46.2:2379)发出后,首先经由所在主机的docker0虚拟网卡(10.0.46.1)转发到flannel0虚拟网卡(10.0.46.0)。

    2)接着flannel服务将原本的数据内容UDP封装后根据自己的路由表投递给目的节点的flanneld服务。在此包中,包含有router-ip(宿主机源ip192.168.8.227 ;宿主机目的ip192.168.8.228),还有容器ipsource10.0.46.2:2379dest10.0.90.2:8080)等数据信息。

    3)然后在接收端node2节点上,数据到达以后被解包,直接进入目的节点的flannel0虚拟网卡中(10.0.90.0),且被转发到目的主机的docker0虚拟网卡(10.0.90.1),最后就像本机容器通信一样由docker0路由到达目标 tomcat 容器(10.0.90.2:8080)。

    五、flannel部署及参数配置

    1.部署

    kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
    

    kubectl get pods -n kube-system -o  wide 显示如下:

    kubectl get configmap  -n  kube-system 显示如下:

    这个kube-flannel-cfg用来设置上面看到的flannel是怎么运行的,它可以把相关的变量注入到flannelpod中。

    kubectl get configmap kube-flannel-cfg -n  kube-system -o  yaml可显示configmapyaml文件内容,具体内容在备注列出

    net-conf.json: |
    {
    "Network": "10.244.0.0/16",
    "Backend": {
    "Type": "vxlan"
    }
    }
    上面可以看到使用的后端网络模型是vxlan,为pod分配的网段是10.244.0.0/16
    

    2.把flannel后端的通信类型修改成Directrouting

    重新修改flannelyaml文件

    cd/root/manifests/

    mkdir flannel

    cd flannel

    修改kube-flannel.yml文件

    kube-flannel.yaml这个文件里在net-conf.json字段增加了”Directrouting”: true,表示是使用直接路由模式,如果没有这个字段就表示使用的是vxlan这种叠加网络模式通信。

    kubectl delete -f  kube-flannel.yml

    等到上面关于flannelpod都删除之后再重新执行:

    kubectl apply  -f  kube-flannel.yml

    kubectl get pods -n kube-system 显示如下,说明重新生成了flannel这个pod,这时后端通信类型使用的就是directrouting

    验证是否是通过Directrouting(直接路由模式)通信

    cd  /root/manifests

    kubectl  apply -f  deploy-myapp.yaml  

    cat deploy-myapp.yaml

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: myapp-deploy
      namespace: default
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: myapp
          release: canary
      template:
        metadata:
          labels:
            app: myapp
            release: canary
        spec:
          containers:
          - name: myapp
            image: ikubernetes/myapp:v1
            ports:
            - name: http
              containerPort: 80
    

    kubectl get pods -o wide 显示如下,说明pod创建成功:

    窗口1

    kubectl exec -itmyapp-deploy-69b47bc96d-7s7zs -- /bin/sh

    窗口2

    kubectl exec -itmyapp-deploy-69b47bc96d-lm4m4 -- /bin/sh

    ping10.244.0.6

    窗口3:抓包

    tcpdump -i ens160 -nnhost 172.21.0.100 显示如下:

    上面可以看到两个pod之间的通信是通过ens160,而不是overlay(覆盖网络),这样就提高了网络传输性能;如果两个节点是跨网段的,那么就会降级到vxlan(叠加网络)模式,否则就可以使用直接路由模式。

    3.把flannel的后端通信方式改成host-gw

    修改kube-flannel.yml文件的如下部分

    net-conf.json: |

    {

    "Network":"10.244.0.0/16",

    "Backend":{

    "Type":"host-gw"

    }

    }

    注:上面修改flannel的网络模式,一般在刚开始安装flannel的时候修改,不要在线上直接修改

    4.flannelvxlanhost-gw的区别

    vxlan模式下的的vxlan是一种覆盖网络;host-gw是直接路由模式,将主机作为网关,依赖于纯三层的ip转发。

    不同网络模型的性能分析

    1.vxlan的Directrouting模式和host-gw模式性能一样,都是通过宿主机的物理网络进行通信,效率高于vxlan的vxlan模式,但是不能实现跨网段通信;
    2.如果要跨网段通信vxlan的Directrouting模式会自动降级到vxlan的vxlan这种叠加网络模式
    

    5.Flannel网络优点:

    1)集群中的不同Node主机创建的Docker容器都具有全集群唯一的虚拟IP地址。

    2)etcd保证了所有nodeflanned所看到的配置是一致的,同时每个node上的flanned监听etcd上的数据变化,实时感知集群中node的变化

    6.Flannel网络缺点:

    不支持pod之间的网络隔离,不支持网路策略

    技术交流群

    为了大家更快速的学习知识,掌握技术,随时沟通交流问题,特组建了技术交流群,大家在群里可以分享自己的技术栈,抛出日常问题,群里会有很多大佬及时解答,这样我们就会结识很多志同道合的人,长按下图可加我微信,备注运维或者k8s或者devops即可进群,让我们共同努力,向着美好的未来出发吧~~~想要免费获取各个版本的k8s高可用集群的安装视频或者其他的免费视频,也可进群获取哈~~     

                  

                                  扫码加群????

    微信:luckylucky421302

    微信公众号

                                         长按指纹关注公众号????

    往期精彩文章

    kubernetes全栈技术+企业案例演示【带你快速掌握和使用k8s】

    kubernetes面试题汇总

    DevOps视频和资料免费领取

    kubernetes技术分享-可用于企业内部培训

    谈谈我的IT发展之路

    kubernetes系列文章第一篇-k8s基本介绍

    kubernetes系列文章第二篇-kubectl

    了解pod和pod的生命周期-这一篇文章就够了

    kubernetes集群中部署EFK日志管理系统

    Kubernetes中部署MySQL高可用集群

    Prometheus+Grafana+Alertmanager搭建全方位的监控告警系统-超详细文档

    k8s1.18多master节点高可用集群安装-超详细中文官方文档

    Kubernetes Pod健康检查-livenessProbe和readinessProbe

    kubernetes pod生命周期管理-postStart和preStop

    k8s中蓝绿部署、金丝雀发布、滚动更新汇总

    运维常见问题汇总-tomcat篇

    运维常见问题汇总-tomcat部署java项目大量close_wait解决方案

    关于linux内核参数的调优,你需要知道

    kubernetes持久化存储volume

    kubernetes挂载ceph rbd和cephfs

    报警神器Alertmanager发送报警到多个渠道

    jenkins+kubernetes+harbor+gitlab构建企业级devops平台

    kubernetes调度器性能调优

                                

                                           点击在看少个 bug????

    展开全文
  • kubernetes网络插件-calico篇

    千次阅读 2020-07-06 07:10:28
    微信公众号搜索 DevOps和k8s全栈技术 ,即可关注,也可扫描文章最后的二维码... 往期精彩文章 kubernetes全栈技术+企业案例演示【带你快速掌握和使用k8s】 kubernetes面试题汇总 DevOps视频和资料免费领取 kubernetes...

    微信公众号搜索 DevOps和k8s全栈技术 ,即可关注,也可扫描文章最后的二维码关注公众号,每天会分享技术文章供大家参考阅读哈~

    calico的核心组件

    1FelixCalico的客户端,跑在每台node节点上,主要负责配置路由及ACLs等信息来确保各pod之间的连通状态

    2etcd:分布式键值存储,主要负责网络元数据一致性,确保Calico网络状态的准确性;

    3BGPClient:主要负责把Felix写入kernel的路由信息分发到当前Calico网络,确保节点间通信的有效性;

    4BGPRoute Reflector(BIRDBGP路由反射器):大规模部署时使用,通过一个或者多个BGPRoute Reflector来完成集中式的路由分发。

    calico原理

    calico是一个纯三层的虚拟网络,它没有复用dockerdocker0网桥,而是自己实现的, calico网络不对数据包进行额外封装,不需要NAT和端口映射,扩展性和性能都很好。Calico网络提供了DockerDNS服务, 容器之间可以通过hostname访问,Calico在每一个计算节点利用LinuxKernel实现了一个高效的vRouter(虚拟路由)来负责数据转发,它会为每个容器分配一个ip,每个节点都是路由,把不同host的容器连接起来,从而实现跨主机间容器通信。而每个vRouter通过BGP协议(边界网关协议)负责把自己节点的路由信息向整个Calico网络内传播——小规模部署可以直接互联,大规模下可通过指定的BGProute reflector来完成;Calico基于iptables还提供了丰富而灵活的网络策略,保证通过各个节点上的ACLs来提供多租户隔离、安全组以及其他可达性限制等功能。

    Calico网络模式

    1.IPIP

    把一个IP数据包又套在一个IP包里,即把IP层封装到IP层的一个 tunnel,它的作用其实基本上就相当于一个基于IP层的网桥,一般来说,普通的网桥是基于mac层的,根本不需要IP,而这个ipip则是通过两端的路由做一个tunnel,把两个本来不通的网络通过点对点连接起来。

    2.BGP

    边界网关协议(BorderGateway Protocol, BGP)是互联网上一个核心的去中心化的自治路由协议。它通过维护IP路由表或‘前缀’表来实现自治系统(AS)之间的可达性,属于矢量路由协议。BGP不使用传统的内部网关协议(IGP)的指标,而是基于路径、网络策略或规则集来决定路由。因此,它更适合被称为矢量性协议,而不是路由协议,通俗的说就是将接入到机房的多条线路(如电信、联通、移动等)融合为一体,实现多线单IP

    BGP 机房的优点:服务器只需要设置一个IP地址,最佳访问路由是由网络上的骨干路由器根据路由跳数与其它技术指标来确定的,不会占用服务器的任何系统。

    calico的ip-ip网络模式

    1.ip-ip模式的特点

    calicoipip模式部署完毕后,node上会有一个tunl0的网卡设备,这是ipip做隧道封装用的,也是一种overlay模式的网络。当我们把节点下线,calico容器都停止后,这个设备依然还在,执行 rmmodipip命令可以将它删除。

    2.开启/禁用ip-ip

    官方提供的calico.yaml模板里,默认打开了ip-ip功能,该功能会在node上创建一个设备tunl0,容器的网络数据会经过该设备被封装一个ip头再转发。这里,calico.yaml中通过修改calico-node的环境变量:CALICO_IPV4POOL_IPIP来实现ipip功能的开关:默认是Always,表示开启;Off表示关闭ipip;calico.yaml文件的部分内容参考备注。

    3.演示calico的ipip模式的ping包走向

    1)测试环境

    master1:172.16.0.1
    node1:172.16.0.4
    node2:172.16.0.5
    

    master1节点执行如下命令,查看宿主机创建的pod有哪些

    master1节点的窗口1

    kubectl  get pods  -o wide  显示如下

    node1节点上的pod(nfs-provisioner-8d6dbc584-cdfxz)ping node2节点上的pod(fierce-body-redis-metrics-6cf79f9d64-v6zs2)

    master1节点操作:

    kubectl exec -it  nfs-provisioner-8d6dbc584-cdfxz -- /bin/sh

    #ping 10.244.4.188

    2)ping包的旅程

    查看node1节点pod上的路由信息

    master1节点新打开一个窗口2

    kubectl exec -it nfs-provisioner-8d6dbc584-cdfxz -- /bin/sh

    #route  -n

    根据路由信息,ping  10.244.4.188,会匹配到第一条路由,第一条的路由意思是:去往任何网段的数据包都发往网关169.254.1.1,然后从eth0网卡发送出去。

    路由表中Flags标志的含义:

    Uup                  表示当前为启动状态

    Hhost               表示该路由是到一个主机

    GGateway       表示该路由是到一个网关,如果没有说明目的地是直连的

    DDynamicaly 表示该路由是由重定向报文创建的

    M                      表示该路由已被重定向报文修改

    node1节点上的路由信息

    node1节点操作:route  -n

    ping包来到node1节点上,会匹配到路由tunl0。该路由的意思是:去往10.244.4.0/24的网段的数据包都发往网关172.16.0.5。因为pod1nfs-provisioner-8d6dbc584-cdfxz )在172.16.0.4上,pod2fierce-body-redis-metrics-6cf79f9d64-v6zs2 )在172.16.0.5上。所以数据包就通过设备tunl0发往到node2节点上。

    node2节点上的路由信息

    node2节点操作:

    route  -n

    node2节点网卡收到数据包之后,发现发往的目的ip10.244.4.188,于是匹配到蓝线的路由。该路由的意思是:10.244.4.188是本机直连设备,去往设备的数据包发往cali52e15d97942

    那么该设备是什么呢?如果到这里你能猜出来是什么,那说明你的网络功底是不错的。这个设备就是vethpair的一端,在创建pod2fierce-body-redis-metrics-6cf79f9d64-v6zs2 )时calico会给pod2创建一个veth pair设备。一端是pod2的网卡,另一端就是我们看到的cali52e15d97942。下面我们验证一下,在pod2中安装ethtool工具,然后使用ethtool -S eth0,查看veth pair另一端的设备号。

    master1节点新打开一个窗口3

    kubectl exec -it fierce-body-redis-metrics-6cf79f9d64-v6zs2 -- /bin/sh

    #ethtool -S eth0

    pod2网卡另一端的设备好号是193,在node2上查看编号为193的网络设备,可以发现该网络设备就是cali52e15d97942

    node2上操作 #ipaddr  显示如下

    所以,node2上的路由,发送cali52e15d97942的数据其实就是发送到pod2的网卡中。ping包的旅行到这里就到了目的地

    查看一下pod2中的路由信息,发现该路由信息和pod1中是一样的。

    master1节点新打开一个窗口4

    kubectl exec -it fierce-body-redis-metrics-6cf79f9d64-v6zs2 -- /bin/sh

    #route -n

    顾名思义,IPIP网络就是将IP网络封装在IP网络里,IPIP网络的特点是所有pod的数据流量都从隧道tunl0发送,并且在tunl0这增加了一层传输层的封包。

    node1节点上抓包分析该过程:

    node1节点操作:tcpdump  -i ens160  -vvv–w ipip.pcap

    node1节点操作:把ipip.pcap上传到桌面上,用wireshark打开分析数据包

    10.244.3.14pod1nfs-provisioner-8d6dbc584-cdfxz

    10.244.4.188pod2fierce-body-redis-metrics-6cf79f9d64-v6zs2

    打开ICMP 32pod1  ping  pod2的数据包,能够看到该数据包一共5层,其中IP所在的网络层有两个,分别是pod之间的网络和主机之间的网络封装。

    根据数据包的封装顺序,应该是在pod1 ping pod2ICMP包外面多封装了一层主机之间的数据包。

    之所以要这样做是因为tunl0是一个隧道端点设备,在数据到达时要加上一层封装,便于发送到对端隧道设备中。 

    两层IP封装的具体内容

    IPIP的连接方式:

    calico的BGP网络模式

    1.BGP网络模式

    边界网关协议(Border Gateway Protocol, BGP)是互联网上一个核心的去中心化自治路由协议。它通过维护IP路由表或‘前缀’表来实现自治系统(AS)之间的可达性,属于矢量路由协议。BGP不使用传统的内部网关协议(IGP)的指标,而使用基于路径、网络策略或规则集来决定路由。因此,它更适合被称为矢量性协议,而不是路由协议;BGP,通俗的讲就是将接入到机房的多条线路(如电信、联通、移动等)融合为一体,实现多线单IP

    BGP机房的优点:服务器只需要设置一个IP地址,最佳访问路由是由网络上的骨干路由器根据路由跳数与其它技术指标来确定的,不会占用服务器的任何系统。世纪互联BGP技术具备动态优选路由的能力,一点接入,轻松部署,创造无界的互联网络;并可多线互备,智能选路,线路互为冗余,具有较高的可靠性;随着客户业务的不断增加,可方便扩充线路,保障客户业务持续需求。

    1)开启BGP网络模式

    修改calico.yaml文件,把IPIP模式禁用即可

    -name: CALICO_IPV4POOL_IPIP

              value: off

    2)对比

    BGP网络相比较IPIP网络,最大的不同之处就是没有了隧道设备 tunl0。前面介绍过IPIP网络pod之间的流量发送tunl0,然后tunl0发送对端设备。BGP网络中,pod之间的流量直接从网卡发送目的地,减少了tunl0这个环节。 

    node1节点上路由信息。从路由信息来看,没有tunl0设备

    2.测试环境

    master1:172.16.0.1
    node1:172.16.0.4
    node2:172.16.0.5
    

    master1节点执行如下命令,查看宿主机创建的pod有哪些

    master1节点的窗口1

    kubectl  get pods  -o wide  显示如下

    node1节点上的pod(nfs-provisioner-8d6dbc584-cdfxz)ping node2节点上的pod(fierce-body-redis-metrics-6cf79f9d64-v6zs2)

    master1节点操作:

    kubectl exec -it  nfs-provisioner-8d6dbc584-cdfxz -- /bin/sh

    #ping  10.244.4.188

    1)ping包的走向

    查看node1节点pod上的路由信息

    master1节点新打开一个窗口2

    kubectl exec -it nfs-provisioner-8d6dbc584-cdfxz -- /bin/sh

    #route  -n

    根据node1节点上pod的路由信息,ping包通过eth0网卡发送到node1节点上。

    node1节点操作:route  -n      显示如下

    上面是node1节点上的路由信息。根据匹配到的10.244.4.0路由,该路由的意思是:去往网段10.244.4.0/24 的数据包都发往网关172.16.0.5。而172.16.0.5就是node2节点。所以,该数据包直接发送到了node2节点。

    node2上操作: route–n    显示如下

    上面是node2节点上的路由信息。根据匹配到的10.244.4.188的路由,数据将发送给 cali52e15d97942设备,该设备和上面分析的是一样,为node2节点上的pod2fierce-body-redis-metrics-6cf79f9d64-v6zs2 )的vethpair 的一端。数据就直接发送给pod2的网卡。

    pod2ping包做出回应之后,数据到达node2节点上,匹配到10.244.3.0的路由,该路由说的是:去往网段10.244.3.0/24 的数据,发送给网关 172.16.0.4。数据包就直接通过网卡ens160,发送到node1节点上。

    通过在node1节点上抓包,查看经过的流量,筛选出ICMP,找到pod1 ping pod2的数据包。

    node1节点上操作:

    tcpdump -i ens160  -vvv-wbgp.pcap

    把上面的bgp.pcap上传到桌面

    可以看到BGP网络下,没有使用IPIP模式,数据包是正常的封装。

    值得注意的是mac地址的封装。10.244.3.14pod1ip10.244.4.188pod2ip。而源mac地址是node1节点网卡的mac,目的macnode2节点的网卡的mac。这说明,在node1节点的路由接收到数据,重新构建数据包时,使用arp请求,将node2节点的mac拿到,然后封装到数据链路层。

    2)BGP的连接方式:

    3.calico的两种网络模式对比

    IPIP网络

    流量:tunlo设备封装数据,形成隧道,承载流量。

    适用网络类型:适用于互相访问的pod不在同一个网段中,跨网段访问的场景,外层封装的ip能够解决跨网段的路由问题。

    效率:流量需要tunl0设备封装,效率略低

    BGP网络

    流量:使用路由信息导向流量

    适用网络类型:适用于互相访问的pod在同一个网段,适用于大型网络。

    效率:原生host-gw,效率高

    4.Calico网络优点

    1)在网络连接过程中性能高:

    Calico配置第3层网络,该网络使用BGP路由协议在主机之间路由数据包,不需要将数据包包装在额外的封装层中。

    2)支持网络策略:

    网络策略是其最受追捧的功能之一。此外,Calico还可以与服务网格Istio集成,以便在服务网格层和网络基础架构层中解释和实施集群内工作负载的策略,这意味着用户可以配置强大的规则,描述Pod应如何发送和接受流量,提高安全性并控制网络环境。

    5.Calico网络缺点

    (1) 缺点租户隔离问题

    Calico 的三层方案是直接在 host 上进行路由寻址,那么对于多租户如果使用同一个pod网络就面临着地址冲突的问题。

     (2) 路由规模问题

    通过路由规则可以看出,路由规模和 pod 分布有关,如果 pod离散分布在host 集群中,势必会产生较多的路由项。

     (3) iptables 规则规模问题

    1Host 上可能虚拟化十几或几十个容器实例,过多的 iptables 规则造成复杂性和不可调试性,同时也存在性能损耗。

    6.flannel和calico网络性能分析,官方指标如下

    flannel host-gw = flannel  vxlan-directrouting = calico bgp> calico ipip > flannel vxlan-vxlan>flannel-udp

    官方推荐使用的网络方案:

    所有节点在同一个网段推荐使用calicobgp模式和flannelhost-gw模式

    性能总结分析:

    Flannelvxlan模式:封包解包采用的是内置在linux内核里的标准协议,虽然它的封包结构比UDP模式复杂,但由于所有数据封包、解包过程均在内核中完成,实际的传输速度要比UDP模式快许多

    Flannelhost-gw模式:Flannel通过在各个节点上的Agent进程,将容器网络的路由信息刷到主机的路由表上,这样一来所有的主机就都有整个容器网络的路由数据了;Host-gw的方式没有引入像Overlay中的额外装包解包操作,完全是普通的网络路由机制,它的效率与虚拟机直接的通信相差无几,但是要求所有host在二层互联

    技术交流群

                                           扫码加群????

    微信:luckylucky421302

    微信公众号

                                         长按指纹关注公众号????

    往期精彩文章

    kubernetes全栈技术+企业案例演示【带你快速掌握和使用k8s】

    kubernetes面试题汇总

    DevOps视频和资料免费领取

    kubernetes技术分享-可用于企业内部培训

    谈谈我的IT发展之路

    kubernetes系列文章第一篇-k8s基本介绍

    kubernetes系列文章第二篇-kubectl

    了解pod和pod的生命周期-这一篇文章就够了

    kubernetes集群中部署EFK日志管理系统

    Kubernetes中部署MySQL高可用集群

    Prometheus+Grafana+Alertmanager搭建全方位的监控告警系统-超详细文档

    k8s1.18多master节点高可用集群安装-超详细中文官方文档

    Kubernetes Pod健康检查-livenessProbe和readinessProbe

    kubernetes pod生命周期管理-postStart和preStop

    k8s中蓝绿部署、金丝雀发布、滚动更新汇总

    运维常见问题汇总-tomcat篇

    运维常见问题汇总-tomcat部署java项目大量close_wait解决方案

    关于linux内核参数的调优,你需要知道

    kubernetes持久化存储volume

    kubernetes挂载ceph rbd和cephfs

    报警神器Alertmanager发送报警到多个渠道

    jenkins+kubernetes+harbor+gitlab构建企业级devops平台

    kubernetes调度器性能调优

                                

                                           点击在看少个 bug????

    展开全文
  • Kubernetes网络插件CNI学习整理

    千次阅读 2017-12-14 10:49:20
    而基于overlay方式等网络性能和延时比较差,网络架构又比较复杂。并且银行对于IP网络管理需要简单可控。SR-IOV是基于硬件实现虚拟网卡,性能损失少,接近宿主机,此外有支持QOS,vlan等特性也是客户需要的。即要根据...
  • Kubernetes网络模型本身对某些特定的网络功能有一定要求,但在实现方面也具有一定的灵活性。因此,业界已有不少不同的网络方案,来满足特定的环境和要求。CNI意为容器网络接口,它是一种标准的设计,为了让用户...
  • 在现有的三层网络之上,“覆盖”一层虚拟的、由内核VXLAN模块负责维护的二层网络,使得连接在这个VXLAN二nfcu网络上的“主机”(虚拟机或容器都可以),可以像在同一个局域网(LAN)里那样自由通信。 为了能够在二...
  • 本文翻译自Alexis Ducastel的文章“Benchmark results of Kubernetes network plugins (CNI) over 10...
  • Kubernetes(k8s)是自动化容器操作的开源平台,这些操作包括部署,调度和节点集群间扩展。 Kubernetes不仅支持Docker,还支持Rocket,这是另一种容器技术。 使用Kubernetes可以实现如下功能: 自动化容器的部署和...
  • 文章目录一、前言二、测试环境三、 ...众所周知,虽然容器提供了应用程序打包,Kubernetes 提供了用简单的容器化组件编写大型复杂应用程序的能力,但这两种技术缺乏在其特定堆栈之外进行通信的常用方法。 在部署 Kuber
  • 春节假期在家维护「家庭级 Kubernetes 集群」时,萌生了写一个网络插件的想法,于是基于 cni/plugin 仓库已有的轮子,写了 Village Net( github.com/zwwhdls/vil… )。以这个网络插件为例,本文着重介绍如何实现一...
  • 一、 原理简介 关于 Kubernetes 网络插件,要从其初始化配置讲起, 即 /etc/systemd/system/kubelet.service.d/10-kubeadm.conf , 该配置文件定义了 Kubernetes 系统启用的网络模式,默认网络参数是: --...
  • kubernetes cni 网络插件调试

    千次阅读 2019-07-29 14:45:32
    kubernetes cni 网络插件调试 最近搭建k8s集群的时候使用的网络插件是 bridge + host-local 关于cni插件 安装kubelet的时候会有一个kubernetes-cni-version-0.x86_64.rpm的依赖文件,安装了之后会在/opt/cni/bin下面...
  • kubernetes 安装网络插件 https://github.com/coreos/flannel wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml # GitHub Start 192.30.253.112 github.com ...
  • Kubernetes CNI网络插件

    2019-06-01 17:08:00
    容器网络接口,就是在网络解决方案由网络插件提供,这些插件配置容器网络则通过CNI定义的接口来完成,也就是CNI定义的是容器运行环境与网络插件之间的接口规范。这个接口只关心容器的网络连接,在创建容器是分配网络...
  • 部署kubernetes相关插件

    2020-06-03 15:39:01
    前言 在上一篇中我们完成了...集群网络并没打通,本文我们将接着上文继续往下中,完成我们的集群网络插件的安装与部署。 ➜ kubectl get cs NAME STATUS MESSAGE ERROR controller-manager Healthy ok scheduler
  • Calico作为Kubernetes的CNI插件可以支持underlay和overlay模式的网络互联;在BGP信息的交互方式上也同时支持中心服务方式和grid mesh方式;但是Calico的基于underlay路由的网络模式要求网络基础设施对于BGP协议要有...
  • 部署CNI网络插件
  • 在学习docker时知道docker有四种常用的网络模型 bridge:桥接式网络 joined:联盟式网络,共享使用另外一个容器的网络名称空间 opened:容器直接共享使用宿主机的网络名称空间 none:不使用任何网络名称空间 ...
  • CNI容器网络接口,就是在网络解决方案由网络插件提供,这些插件配置容器网络则通过CNI定义的接口来完成,也就是CNI定义的是容器运行环境与网络插件之间的接口规范。这个接口只关心容器的网络连接,在创建容器是分配...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 796
精华内容 318
关键字:

kubernetes网络插件