3.2.3 K8S进阶

主机(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该如何转发请求

K8S/Kubernetes

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

更多推荐

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

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

K8S/Kubernetes

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

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