本文是关于深入理解Kubernetes网络原理系列第2章 深入理解Kubernetes Pod网络原理 - 网络名称空间 深入理解Kubernetes Pod网络原理 - Linux虚拟网络技术 深入理解Kubernetes Pod网络原理 - CNI 深入理解Kubernetes Pod网络原理 - 跟随 flannel 学习CNI原理 深入理解Kubernetes Pod网络原理 - 跟随 flannel + multus 剖析 Chained Plugins 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 1 (Shell) 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 2 (libcni) 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 1 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 2 深入理解Kubernetes Pod网络原理 - Pod网络排错思路 Overview 本文将介绍Kubernetes中使用的相关虚拟网络功能，目的是为了任何无相关网络背景经历的人都可以了解这些技术在kubernetes中式如何应用的。 VLAN VLAN (Virtual local area networks)是逻辑上的LAN而不受限于同一物理网络交换机上。同样的VLAN也可以将同一台交换机/网桥下的设备/划分为不同的子网。...

在因特网中，网络连接设备用来控制网络流量和保证网络数据传输质量。常见的网络连接设备有集线器（Hub）、网桥（Bridge）、交换机（Switch）和路由器（Router）。 路由器是一种典型的网络连接设备，用来进行路由选择和报文转发。路由器根据收到报文的目的地址选择一条合适的路径（包含一个或多个路由器的网络），然后将报文传送到下一个路由器，路径终端的路由器负责将报文送交目的主机。 路由（routing）就是报文从源地址传输到目的地址的活动。路由发生在OSI网络参考模型中的第三层即网络层。当报文从路由器到目的网段有多条路由可达时，路由器可以根据路由表中最佳路由进行转发。最佳路由的选取与发现此路由的路由协议的优先级、路由的度量有关。当多条路由的协议优先级。 路由是数据通信网络中最基本的要素。路由信息就是指导报文发送的路径信息，路由的过程就是报文转发的过程。 根据路由目的地的不同，路由可划分为： 网段路由：目的地为网段，IPv4地址子网掩码长度小于32位或IPv6地址前缀长度小于128位。 主机路由：目的地为主机，IPv4地址子网掩码长度为32位或IPv6地址前缀长度为128位。 根据目的地与该路由器是否直接相连，路由又可划分为： 直连路由：目的地所在网络与路由器直接相连。 间接路由：目的地所在网络与路由器非直接相连。 根据目的地址类型的不同，路由还可以分为： 单播路由：表示将报文转发的目的地址是一个单播地址。 组播路由：表示将报文转发的目的地址是一个组播地址。 路由的优先级 对于相同的目的地，不同的路由协议（包括静态路由）可能会发现不同的路由，但这些路由并不都是最优的。事实上，在某一时刻，到某一目的地的当前路由仅能由唯一的路由协议来决定。为了判断最优路由，各路由协议（包括静态路由）都被赋予了一个优先级，当存在多个路由信息源时，具有较高优先级（取值较小）的路由协议发现的路由将成为最优路由，并将最优路由放入本地路由表中。 路由协议 优先级 DIRECT 0 OSPF 10 IS-IS IS-IS Level1 15 IS-IS Level 2 由网关加入的路由 50 路由器发现的路由 55 静态路由 60 UNR（User Network Route） DHCP（Dynamic Host Configuration Protocol）：60AAA-Download：60IP Pool：61Frame：62Host：63NAT（Network Address Translation）：64IPSec（IP Security）：65NHRP（Next Hop Resolution Protocol）：65PPPoE（Point-to-Point Protocol over Ethernet）：65 Berkeley RIP 100 点对点接口聚集的路由 110 OSPF的扩展路由 140 OSPF ASE 150 OSPF NSSA 150 BGP 170 EGP 200 IBGP 255 EBGP 255 其中，0表示直接连接的路由，255表示任何来自不可信源端的路由；数值越小表明优先级越高。 除直连路由（DIRECT）外，各种路由协议的优先级都可由用户手工进行配置。另外，每条静态路由的优先级都可以不相同。 路由器根据路由转发数据包，路由可通过手动配置和使用动态路由算法计算产生，其中手动配置的路由就是静态路由。...

Calico针对容器、虚拟机的开源网络和网络安全解决方案。是纯三层的数据中心网络方案。 Calico在每一个计算节点利用Linux Kernel实现了一个高效的虚拟路由器vRouter来负责数据转发，而每个vRouter通过BGP协议负责把自己上运行的workload的路由信息向整个Calico网络内传播。（小规模部署可以直接互联 BGP full mesh，大规模下可通过指定的BGP route reflector来完成）。 这样保证最终所有的workload之间的数据流量都是通过IP路由的方式完成互联的。Calico节点组网可以直接利用数据中心的网络结构（无论是L2或者L3），不需要额外的NAT，隧道或者Overlay Network。 Calico还基于iptables还提供了丰富而灵活的网络Policy，保证通过各个节点上的ACLs来提供Workload的多租户隔离、安全组以及其他可达性限制等功能。 calico组件 在Kubernetes平台之上calico/node容器会通过DaemonSet部署到每个节点，并运行三个守护程序： Felix：用于管理路由规则，负责状态上报。 BIRD：BGP的客户端，用于将Felix的路由信息加载到内核中，同时负责路由信息在集群中的分发。 confd：用于监视Calico存储（etcd）中的配置变更并更新BIRD的配置文件。 calicoctl使用问题 text 1 Failed to create Calico API client: invalid configuration: no configuration has been provided 默认情况下，calicoctl 将使用位于的默认KUBECONFIG从 Kubernetes APIServer 读取$(HOME)/.kube/config 。 如果默认的 KUBECONFIG 不存在，或者想从指定的存储访问信息，则需要单独配置。 bash 1 2 3 export DATASTORE_TYPE=kubernetes export DATASTORE_TYPE=etcdv3 export KUBECONFIG=~/.kube/config reference for calico 安装配置 开始前准备 确定calico数据存储 Calico同时支持kubernetes api和etcd数据存储。官方给出的建议是在本地部署中使用K8S API，仅支持Kubernetes模式。而官方给出的etcd则是混合部署（Calico作为Kubernetes和OpenStack的网络插件运行）的最佳数据存储。 使用kubernetes api作为数据存储的安装 text 1 2 curl https://docs.projectcalico.org/manifests/calico.yaml -O kubectl apply -f calico....

sidecar 介绍 在istio的流量管理等功能，都需要通过下发的配置应用到应用运行环境执行后生效，负责执行配置规则的组件在service mesh中承载应用代理的实体被称为side-car Istio对流量策略管理等功能无须对应用程序做变动， 这种对应用服务完全非侵入的方式完全依赖于Side-car，应用的流量有Sidecar拦截并进行认证、鉴权、策略执行等治理功能。在Kubernetes平台中，Side-car容器于应用容器在同一个Pod中并共享网络名词控件，因此Side-car容易可以通过iptables规则拦截进出流量进行管理。 sidecar的注入 sidecar是service mesh无侵入式架构的应用模式，在使用sidecar部署服务网格时，无需再每个应用节点运行服务代理，但是需要在每个应用程序中部署一个sidecar容器，来接管所有进出流量。 Sidecar会将额外容器注入到 Pod 模板中。Istio中的数据平面组件所需的容器有： istio-init 用于设置容器的iptables规则，目的是为了接管进出流量。在应用容器前启动并运行完成其生命周期，多个init容器按顺序依次完成。 istio-proxy 基于envoy的sidecar的代理。 sidecar被注入的方式 手动注入，使用 istioctl 修改容器模板并添加前面提到的两个容器的配置。不论是手动注入还是自动注入，Istio 都从 istio-sidecar-injector 和的 istio 两个 Configmap 对象中获取配置。 refer-istio-sidecar-injector 自动注入，在部署应用是，istio自动将sidecar注入到pod。这是istio推荐的方法，Istio在基于Kubernetes平台之上，需要在部署应用之前，对要标记部署应用程序的名称空间标记 kubectl label namespace default istio-injection=enabled 这个操作是对名称空间级别生效的。而后所部署的Pod中会注入sidecar执行上面sidecar容器的操作。 istio injector 注入原理 Sidecar Injector是Istio中实现自动注入Sidecar的组件，它是以Kubernetes准入控制器 AdmissionController 的形式运行的。Admission Controller 的基本工作原理是拦截Kube-apiserver的请求，在对象持久化之前、认证鉴权之后进行拦截。 Admission Controller有两种：一种是内置的，另一种是用户自定义的。 Kubernetes允许用户以Webhook的方式自定义准入控制器，Sidecar Injector就是这样一种特殊的MutatingAdmissionWebhook。 Sidecar Injector只在创建Pod时进行Sidecar容器注入，在Pod的创建请求到达 Kube-apiserver 后，首先进行认证鉴权，然后在准入控制阶段，Kube-apiserver以REST的方式同步调用Sidecar Injector Webhook服务进行init与istio-proxy容器的注入，最后将Pod对象持久化存储到etcd中。 sidecar容器 sidecar容器内部运行着 pilot-agent 与 envoy Pilot-agent：基于kubernetesAPI资源对象为envoy初始化可用的bootstrap配置进行启动，在运行后管理envoy运行状态，如配置变更，出错重启等。 envoy：数据平面的执行层，由 pilot-agent 所启动的，从xDS API动态获取配置信息。Envoy并通过流量拦截机制处理入栈及出栈的流量。 envoy的listener 在运行在Kubernetes平台之上的istio，Envoy是通过Pilot将Kubernetes CRD资源 DestnationRule VirtualService Gateway等资源提供的配置，生成对应的Envoy配置。...

端口绑定无权限 创建Gateway，提示绑定端口无权限。 text 1 2 3 2020-12-27T12:25:30.974288Z warning envoy config gRPC config for type.googleapis.com/envoy.config.listener.v3.Listener rejected: Error adding/updating listener(s) 0.0.0.0_90: cannot bind '0.0.0.0:90': Permission denied 问题原因：容器内默认权限不能使用非特权端口（<1024 导出部署清单部署失败 bash 1 istioctl manifest generate > generated-manifest.yaml 如果尝试使用来安装和管理Istio istioctl manifest generate，请注意以下警告： Istio名称空间（istio-system默认情况下）必须手动创建。 istioctl install 会从Kubernetes上下文中自动检测特定于环境的设置。如需手动安装需要执行如下步骤： --set values.global.jwtPolicy=third-party-jwt --set values.global.jwtPolicy=first-party-jwt refer token Generate a manifest