目录

3.2.3.1 搭建K8S高可用集群及K8S网络方案详解

1、docker网络的4种模式

2、docker的网络基础

    2.1、linux网络名词解释

   2.2、Docker网络在整个Docker生态技术栈中的位置

3、docker的网络实现

    3.1、单机网络模式

    3.2、多机网络模式

    3.3、4种网络模式

4、k8s网络要解决的问题

    4.1、网络架构图

3.2.3.2 内置的负载均衡机制及自定义拓展

1、Flannel容器网络

2、k8s的4种负载均衡机制

    2.1、service

    2.2、service load balancer

    2.3、custom load balancer

    2.4、ingress


参考老师的文档写的学习笔记:专题三-Kubernetes_学习文档-N.docx

3.2.3.1 搭建K8S高可用集群及K8S网络方案详解

1、docker网络的4种模式

    主机(host):与宿主机共享网络(与宿主机ip地址一样)
    桥接(bridge):与宿主机是一台机器
    (none):有网卡,但没连网(eg:有线网卡没插网线、无线网卡没连WIFI),只能ping自己(localhost、127.0.0.1)
    容器(container):与其他容器共享命名空间(namespace),共享网络【根容器会创建一个网络,其他容器就共享这一个网络】

2、docker的网络基础

    2.1、linux网络名词解释

        1、Network Namespace
            不同的网络命名空间中,协议栈是独立的,完全隔离,彼此之间无法通信。
            同一个网络命名空间有独立的路由表、独立的Iptables/Netfilter,
                    来提供包的转发、NAT、IP包过滤等功能。
        2、网络命名空间的实现
            将与网络协议栈相关的全局变量变成一个Net Namespace变量的成员,然后在调用协议栈函数,加入一个Namespace参数。
        3、常用用的操作
            1、创建网络命名空间:ip netns add
            2、在命名空间内执行命令:ip netns exec
            3、进入命名空间:ip netns exec bash
        4、veth设备对
            是为了实现在不同网络命名空间的通信
        5、Iptable/Netfilter
            Netfilter:负责在内核中执行各种挂接的规则(过滤、修改、丢弃),运行在内核模式中
            Iptables:负责协助维护内核中Netfilter的各种规则表,是在用户模式下运行的进程
            通过二者的配合来实现整个linux网络协议栈中灵活的数据包处理机制
        6、网桥
            是一个二层网络设备,通过网桥可以将linux支持的不同端口连接起来,并实现类似交换机那样的多对的的通信。
        7、路由
            linux系统包含一个完整的路由功能,当IP层在处理数据发送或转发的时候,会使用路由表来决定发往哪里。

   2.2、Docker网络在整个Docker生态技术栈中的位置

3、docker的网络实现

    3.1、单机网络模式

birdge、host、container、none

    3.2、多机网络模式

            1、docker在1.9版本中引入libnetwork项目,对跨节点网络的原生支持
            2、通过插件plugin方式引入的第三方实现方案,eg:flannel、calico

容器网络

    3.3、4种网络模式

Docker网络模式

配置

说明

host模式

–net=host

容器和宿主机共享Network namespace。

container模式

–net=container:

NAME_or_ID

容器和另外一个容器共享Network namespace。 kubernetes中的pod就是多个容器共享一个Network namespace。

none模式

–net=none

容器有独立的Network namespace,但并没有对其进行任何网络设置,如分配veth pair 和网桥连接,配置IP等。

bridge模式

–net=bridge

(默认)

 

4、k8s网络要解决的问题

    1、保证每个Pod拥有一个集群内唯一的IP地址
    2、保证不同节点的IP地址划分不会重复
    3、保证跨节点的Pod可以互相通信
    4、保证不同节点的Pod可以与跨节点的主机互相通信
    为解决这些问题,出现的网络插件有:flannel、calico、contiv、weave net、cilium、canal

    4.1、网络架构图

图中的flannel的作用:保证当前节点所有容器的IP地址唯一,与其他节点的IP地址不会出现重复
node之间的Pod通信时,工作流程:pod的eth0找docker0,docker0找flannel,flannel向api server发请求,api server从etcd中查找目标pod的IP地址、及pod所在的node的物理地址;找到后,flannel将信息给当前node1的物理网卡eth0,node1的物理网卡eth0根据信息向目标网卡(node2的eth0)发请求:在它上面对应的pod地址

3.2.3.2 内置的负载均衡机制及自定义拓展

1、Flannel容器网络

2、k8s的4种负载均衡机制

    2.1、service

        直接用service提供cluster内部的负载均衡,并借助cloud provider提供的LB,来提供外部访问
            Service是对一组提供相同功能的Pods的抽象,并为它们提供一个统一的入口。借助Service,应用可以方便的实现服务发现与负载均衡,并实现应用的零宕机升级。Service通过标签来选取服务后端,一般配合Replication Controller或者Deployment来保证后端容器的正常运行
        1、Service目前有三种类型:
            ClusterIP:默认类型,自动分配一个仅cluster内部可以访问的虚拟IP
            NodePort:在ClusterIP基础上为Service在每台机器上绑定一个端口,这样就可以通过<NodeIP>:NodePort来访问该服务
            LoadBalancer:在NodePort的基础上,借助cloud provider创建一个外部的负载均衡器,并将请求转发到<NodeIP>:NodePort

        2、Service中常见的三种端口的含义:
            port:Service暴露在Cluster IP上的端口,也就是虚拟IP要绑定的端口。port是提供给集群内部客户访问Service的入口。
            nodePort:是Kubernetes提供给集群外部客户访问Service的入口。
            targetPort:是Pod里容器的端口,从port和nodePort上进入的数据最终会经过Kube-Proxy流入到后端Pod里容器的端口。如果targetPort没有被显式声明,那么会默认转发到Service接受请求的端口(和port端口的值一样)。
总的来说,port和nodePort都是Service的端口,前者暴露给集群内客户访问服务,后者暴露给集群外客户访问服务。从这两个端口到来的数据都需要经过反向代理Kube-Proxy流入后端Pod里容器的端口,从而到达Pod上的容器内。
另外,也可以将已有的服务以Service的形式加入到Kubernetes集群中来,只需要在创建Service的时候不指定Label selector,而是在Service创建好后手动为其添加endpoint。 
service的限制:对外访问的时候,NodePort类型需要在外部搭建额外的负载均衡,而LoadBalancer要求kubernetes必须跑在支持的cloud provider上面。

    2.2、service load balancer

        把load balancer直接跑在容器中,实现bare metal的service load balancer
Service Load Balancer是解决Service局限性的方式。Service Load Balancer将haproxy跑在容器中,并监控service和endpoint的变化,通过容器IP对外提供4层和7层负载均衡服务。
社区提供的Service Load Balancer支持四种负载均衡协议:TCP、HTTP、HTTPS、SSL TERMINATION,并支持ACL访问控制。
像阿里云、aws、azure、openstack、gce都提供了loadbalance服务。

    2.3、custom load balancer

        自定义负载均衡,并替代kube-proxy,一般在物理部署k8s时使用,方便接入公司已有的外部服务
虽然Kubernetes提供了丰富的负载均衡机制,但在实际使用的时候,还是会碰到一些复杂的场景是它不能支持的,eg:
    1、接入已有的负载均衡设备
    2、多租户网络情况下,容器网络和主机网络是隔离的,这样kube-proxy就不能正常工作

这个时候就可以自定义组件,并代替kube-proxy来做负载均衡。基本的思路是监控kubernetes中service和endpoints的变化,并根据这些变化来配置负载均衡器。eg:weave flux、nginx plus、kube2haproxy等
 

    2.4、ingress

        用service提供cluster内部的负载均衡,通过自定义的LB,来提供外部访问
ingress是一套接口,nginx是ingress的一种实现。
官方文档:https://kubernetes.github.io/ingress-nginx/
ingress解决了service的限制,用来将服务暴露到cluster外面,可以自定义服务的访问策略。
ingress规则是很灵活的,可以根据不同域名、不同path转发请求到不同的service,并且支持https/http。

1、Ingress组成
    1、将nginx的配置抽象成一个ingress对象,没添加一个服务只需写一个新的ingress的yaml文件即可
    2、将新加入的ingress转换成nginx的配置文件并使之生效
    3、ingress controller
    4、ingress服务
2、Ingress工作原理
    1、ingress controller通过与kubernetes api交互,动态的去感知集群中ingress规则变化
    2、然后读取它,按照自定义的规则,规则就是写明哪个域名对应哪个service,生成一段nginx配置
    3、再写到nginx-ingress-controller的pod里,这个ingress controller的pod里运行着一个nginx服务,控制器会把生成的nginx配置写入/etc/nginx.conf文件中
    4、然后reload一下,使配置生效。以此达到域名分配置和动态更新的问题
3、ingress可以解决的2个问题
    1、动态配置服务
    2、减少不必要的端口暴露
4、区分ingress与ingress-controller
    1、ingress
        ingress对象:指的是k8s中的一个api对象,一般用yaml配置。作用是定义请求如何转发到service的规则,可以理解为配置模板。
        eg:nginx-ingress就是动态生成nginx配置,动态更新upstream
    2、ingress-controller
        具体实现反向代理及负载均衡的程序,对ingress定义的规则进行解析,根据配置的规则来实现请求转发。
    ingress-controller是负责具体转发的组件,ingress是用来告诉ingress-controller该如何转发请求

Logo

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

更多推荐