作者： imliuda

kubernetes网络 – 云控制器

发布于 by imliuda
https://kubernetes.io/zh/docs/concepts/architecture/cloud-controller/ 使用云基础设施技术，你可以在公有云、私有云或者混合云环境中运行 Kubernetes。 Kubernetes 的信条是基于自动化的、API 驱动的基础设施，同时避免组件间紧密耦合。 组件 cloud-controller-manager 是指云控制器管理器， 云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件。 云控制器管理器使得你可以将你的集群连接到云提供商的 API 之上， 并将与该云平台交互的组件同与你的集群交互的组件分离开来。 通过分离 Kubernetes 和底层云基础设置之间的互操作性逻辑， 云控制器管理器组件使云提供商能够以不同于 Kubernetes 主项目的 步调发布新特征。 cloud-controller-manager 组件是基于一种插件机制来构造的， 这种机制使得不同的云厂商都能将其平台与 Kubernetes 集成。 设计 云控制器管理器以一组多副本的进程集合的形式运行在控制面中，通常表现为 Pod 中的容器。每个 cloud-controller-manager 在同一进程中实现多个 控制器。 说明： 你也可以用 Kubernetes 插件 的形式而不是控制面中的一部分来运行云控制器管理器。 云控制器管理器的功能 云控制器管理器中的控制器包括： 节点控制器 节点控制器负责在云基础设施中创建了新服务器时为之 创建 节点（Node）对象。 节点控制器从云提供商获取当前租户中主机的信息。节点控制器执行以下功能： 针对控制器通过云平台驱动的 API 所发现的每个服务器初始化一个 Node 对象； 利用特定云平台的信息为 Node 对象添加注解和标签，例如节点所在的 区域（Region）和所具有的资源（CPU、内存等等）； 获取节点的网络地址和主机名；否则是由kubelet获取设置这些信息。 检查节点的健康状况。如果节点无响应，控制器通过云平台 API 查看该节点是否 已从云中禁用、删除或终止。如果节点已从云中删除，则控制器从 Kubernetes 集群 中删除 Node 对象。 某些云驱动实现中，这些任务被划分到一个节点控制器和一个节点生命周期控制器中。 路由控制器 Route 控制器负责适当地配置云平台中的路由，以便 Kubernetes…

kubernetes网络 – 网络插件 – calico

发布于 by imliuda
calico支持host-gateway，vxlan，ipip和bgp网络模式。calico网络插件支持下列功能 基于vxlan，ipip的overlay集群网络方案。 基于bgp的路由网络方案，以及将podIP，服务的clusterIP，externalIP和LoadBalancerIP路由到集群外的能力。 kubernetes cni插件，calico和calico-ipam kubernetes原生网络策略和扩展网络策略 基于eBPF的数据面，实现网络策略和kubernetes服务功能 和其他系统（如openstack）的集成 istio网络策略扩展 架构与组件 https://docs.projectcalico.org/reference/architecture/overview Calico组件 Felix BIRD confd Dikastes CNI plugin Datastore plugin IPAM plugin kube-controllers Typha calicoctl Felix 管理主机上的路由规则，数据面访问控制等，提供访问该主机上服务的能力。比如： 接口管理管理网络接口设备，比如vxlan，ipip隧道接口设备，arp表信息，配置ip地址转发等。 配置路由配置子网和端点的路由信息。 配置访问控制如网络策略。 状态报告节点上的网络健康数据，错误信息等。 BIRD 获取路由信息，并分发到BGP peers，基于开源的bird软件。 路由分发当Felix修改系统路由后（FIB），bird感知到将其分发到其他节点。 路由反射传统bgp网络各个节点之间组成mesh，节点数量很多时，会有大量连接，有性能影响。通过使用reflector，将其作为中心节点，所有peer都和他建链接，它想每个peer分发整个集群的路由信息。 confd 检测calico的datastore数据变化以便及时修改bgp配置，如AS编号，日志级别等。它通过修改bird的配置文件并重新加载bird实现这些功能。 Dikastes 执行istio服务网格的网络策略，作为sidecar运行在集群中。 CNI plugin kubernetes的cni插件的实现，在每个节点上都要部署。 Datastore plugin 存储插件，减轻各个节点对存储引擎的影响。支持kubernetes和etcd。 IPAM plugin 结合calico cni插件使用，使用calico的ippool下分配ip地址。 kube-controllers 检测kubernetes集群资源变化，执行相关动作，包含下列控制器： 策略控制器 命名空间控制器 服务账户控制器 工作负载控制器 节点控制器 Typha 减轻各个节点对存储中心的影响。目的是争取和存储中心保持一个链接。像Felix和confd都是连接Typha。 calicoctl 客户端工具，可以用来对calico的各种资源执行增删改查等操作。 安装部署 calico的网路配置，网络策略都是通过datastore组件进行存储的。datastore后端存储支持kubernetes和etcd。如果是单独针对kubernetes使用，推荐使用默认的kuberentes后端，如果要和openstack这样的系统进行集成，那么推荐使用etcd后端。我们使用kubernetes后端存储。 快速部署： curl https://docs.projectcalico.org/manifests/calico.yaml -O # 修改CALICO_IPV4POOL_CIDR为集群的pod网段，并安装 kubectl…

kubernetes网络 – 网络插件 – flannel

发布于 by imliuda
flannel支持host-gw，vxlan，ipip，ipsec模式和VPC路由模式。 部署 使用下面命令对部署flannel到集群中，会在集群中创建flannel的daemonset和一个flannel的配置文件。 kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml 其中默认配置文件内容如下，主要包含了cni配置和网络配置。其中cni配置为采用flannel cni，指定网桥名称为cbr0，打开网桥接口的haripin模式，并将网桥设置为默认的网关。这些参数的含义可参考后面cni部分。 默认也指定了集群的网络模式为vxlan，使用flannel cni，并配置了整个网络的网段。 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.248.0.0/13", "Backend": { "Type": "vxlan" } } cni插件 cni要解决的问题是本机如何访问pod以及外部主机进来的数据包怎么进入pod。使用flannel作为网络插件的话，可选两种cni插件，其一是flannel…

kubernetes网络 – ingress资源

发布于 by imliuda
ingress主要用来将集群内的http服务暴露到集群外。ingress提供负载均衡，ssl/tls终结和基于名称的虚拟服务器功能。 下图是ingress架构图： ingress用来暴露http和https服务，如果是其他的服务协议，无法通过ingress进行暴露，需要使用nodeport或者loadbalancer类型的服务。 ingress控制器 要使用配置ingress，需要集群内存在ingress控制器，ingress控制器负责将ingress的定义配置到具体的控制器服务上。kubernetes支持的ingress控制器参考： https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/ 此处我们使用nginx-ingress进行配置和演示，参考下面文档进行安装配置： https://github.com/kubernetes/ingress-nginx/tree/main/charts/ingress-nginx kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.0.3/deploy/static/provider/baremetal/deploy.yaml kubectl annotate ingressclasses nginx ingressclass.kubernetes.io/is-default-class=true # 改成LoadBalancer类型 kubectl edit svc -n ingress-nginx ingress-nginx-controller # 修改deployment # - --publish-service=$(POD_NAMESPACE)/ingress-nginx-controller # - --enable-ssl-passthrough kubectl edit deployments.apps -n ingress-nginx ingress-nginx-controller # 创建测试应用 kubectl apply -f https://github.com/istio/istio/blob/1.11.3/samples/helloworld/helloworld.yaml ingress 创建ingress资源进行测试。 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: minimal-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - http: paths: - path: /hello pathType: Prefix backend: service: name:…

kubernetes网路 – 服务与DNS

发布于 by imliuda
kubernetes会为每个service对象创建dns记录，这个操作是由dns插件完成的，基本上所有集群都会使用coredns作为dns插件。 kubernetes中的服务是区分命名空间的，nginx这个域名在默认情况下是使用本pod所在namespace解析的，如pod所在的namespace为default，则默认解析为nginx.default。下列是一个示例pod的resolv文件配置 [root@master1 ~]# kubectl exec -it nginx-deployment-66b6c48dd5-95c7f -- cat /etc/resolv.confnameserver 172.17.0.10search default.svc.cluster.local svc.cluster.local cluster.localoptions ndots:5 服务对象分为普通服务和无头服务，无头服务是指spec.clusterIP=None的，其他服务则为普通服务。 如果service是一个普通服务对象，则会为其创建一个dns A记录（ipv6则为AAAA记录），该记录的ip地址是在kube-controller-manager的--service-cluster-ip-range参数指定的网段内，该网段和pod网段以及节点网段都不在一个网段内。 如果service是一个无头服务，则会创建一些列dns A记录，记录的ip地址是pod的ip。 k8s还会为服务对象的每个命名端口创建srv记录。如_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example。对于普通服务，解析到my-svc.my-namespace.svc.cluster-domain.exampl加端口号。对于无头服务会为每个pod创建一个类似的记录。auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example加端口号。 通常情况下，会为所有pod创建如下类型的dns解析： pod-ip-address.my-namespace.pod.cluster-domain.example -> pod-ip kubectl run aaaa --image=nginx [root@master1 ~]# nslookup 10-248-5-2.default.pod.cluster.local 172.17.0.10 Server: 172.17.0.10 Address: 172.17.0.10#53 ​ Name: 10-248-5-2.default.pod.cluster.local Address: 10.248.5.2 通常情况下，会为deployment和daemonset的pod，且通过service进行暴露的话，则会创建下列dns解析： pod-ip-address.deployment.my-namespace.svc.cluster.local -> pod-ip 针对deployment进行测试 kubectl create deployment nginx --image=nginx kubectl expose deployment nginx --port 80 [root@master3 ~]# nslookup nginx.default.svc.cluster.local 172.17.0.10 Server: 172.17.0.10 Address: 172.17.0.10#53 ​…

kubernetes网络 – 服务概念

发布于 by imliuda
kubernetes中服务主要用来进行服务发现和负载均衡。 在集群中我们的工作负载是不稳定的，ip地址可能随着pod重启，升级和扩容等不断发生变化，为了能够让其他工作负载可以稳定访问到这个工作负载，我们需要为其创建一个服务对象。 服务对象也是一个api资源对象，和其他api对象定义方法相同，下面是一个服务对象的定义： apiVersion: v1 kind: Service metadata: name: nginx spec: selector: # 根据标签选择pod app: nginx # type: ClusterIP # clusterIP: 192.168.3.251 ports: # TCP, UDP, SCTP - protocol: TCP appProtocol: http name: nginx-http port: 80 targetPort: 80 # 支持多个端口配置 - name: https protocol: TCP port: 443 targetPort: 9377 externalTrafficPolicy: Cluster 这个服务对象会创建一个service资源，服务控制器会根据我们的selector选择对应的pod，创建endpoint后endpointslice资源关联到这个服务。服务控制器还会为我们的服务自动创建一个虚拟ip地址，其他工作负载使用这个虚拟ip地址访问这个服务。endpoint资源代表后端真正的服务实例，它关联到pod，访问到虚拟ip的流量会转到对应的后端pod对应的端口上。 通过selector可以让kunbernetes根据标签自动选择pod并创建endpoint关联到service。有些场景我们也可以不使用selector，例如： 引用已有服务的ip列表 apiVersion: v1 kind: Service metadata: name: my-service spec: ports: - protocol: TCP port: 443 targetPort: 6443…

kubernetes网络 – 集群网络原理分析

发布于 by imliuda
vxlan网络 vxlan是一种基于3层网络实现的2层overlay网络。vxlan网络可以使用VNI划分出多个彼此隔离的网络，可应用于多租户场景。 vxlan可以结合bridge一起来使用，相当于使用vxlan将多个主机上的bridge连接起来形成一个大的逻辑上的bridge设备。也可以不使用bridge，而是结合路由使用。下图是结合路由或bridge使用的场景示例： 在kubernetes环境中，可以使用简单的路由方式。内核在vxlan数据包解包后将原始二层数据给到了vxlan设备去接收，vxlan设备将数据包送入到上层网络协议栈。网络协议栈根据主机上的路由表配置，将包发给相应pod的网卡。 在这种路由模式下，节点上不需要知道其他所有pod的mac地址，只需要节点上对应的网关的地址的mac。数据包通过vxlan设备发送和接收的大致流程如下： 数据发送： 数据包从pod1发出，进入peer网卡的接收队列，然后到达node1的协议栈，经过路由判决，走node1的forward链。 forward时，要去的pod2的IP为172.16.2.1，主机路由匹配到应该走vxlan设备，下一跳为172.16.2.0。 数据包到达vxlan设备，查询路由表得知网关地址为172.16.2.0，于是通过arp协议查找网关的mac地址，在arp表中找到了匹配的记录后完成mac头封装，准备发送。 vxlan设备发送数据包并不是提交到发送队列，而是调用udp隧道相关接口将数据包封装成一个udp数据包，接着会查询fdb表查找要将数据从那个VTEP接口发出，经过查找后得到的VTEP接口为192.168.56.2，从而将数据包发送node2节点 。 数据接收： node2接收后，走主机协议栈，判断这是发往本机的udp包，于是走INPUT方向，最终发到UDP隧道层处理。 当创建vxlan创建udp隧道时，会将其接收数据包方法覆盖为vxlan的接收方法，所以在收到vxlan的UDP数据包后，进行对vxlan包解包，之后调用网卡的接收数据包方法进行接收原始二层数据包，此时如果vxlan设备被加入到了bridge设备，那么这个数据包会由bridge设备收到，bridge设备决定进行二层抓发或是送入上层网络协议栈。如果没有加入bridge中，那么如果目的mac地址是自己的也会送入上层网络协议栈。 进入上层网络协议栈后，就会根据主机的路由判断是入站还是转发，发现目标地址是172.16.2.1，经过路由判决时，发现不是本机地址，进行转发，找到相应的路由通过veth-pairhost端发出，从而进入pod。 下面，我们通过一些列命令手动创建和管理vxlan设备，进行测试vxlan相关功能，此处我们采用纯路由方式。 首先在第一台主机上先创建vxlan设备，配置路由： set -ux sysctl -w net.ipv4.ip_forward=1 sysctl -w net.ipv4.conf.all.proxy_arp=1 sysctl -w net.ipv4.conf.all.rp_filter=0 iptables -A FORWARD -d 172.16.0.0/16 -j ACCEPT iptables -A FORWARD -s 172.16.0.0/16 -j ACCEPT ​ ip link add vxlan.1 type vxlan vni 1 ip link set vxlan.1 up ip addr add 172.16.1.0/32 dev vxlan.1 ip route add 172.16.2.0/24 via 172.16.2.0 dev vxlan.1…

kubernetes网络 – kube-proxy详解

发布于 by imliuda
kube-proxy是kubernetes中网络核心组件，实现了服务暴露和转发等网络功能。如前面章节讲到，kube-proxy支持用户空间模式，ipvs和iptables三种代理模式。用户空间模式性能问题较严重，基本不再使用，应用最多的是iptables和ipvs模式。如果启动时不指定具体使用哪种模式，当前版本kube-proxy会优先使用iptables模式，如果探测到系统不支持则回滚到用户空间模式。当然，如果指定了ipvs模式，但是系统不支持的话也会回滚到iptables模式。 kube-proxy通过apiserver监听service和endpoint资源的变化，并动态更新网络配置规则。当前iptables应该是应用较多的模式，因此本节主要针对iptables规则进行分析。对于ipvs模式来说也并不是不需要iptables规则，在下列情况的时候还是会依赖iptables的规则实现相关功能：参考这里。在本节对iptables规则进行分析之后，可以按照这种方式再去分析ipvs相关规则配置，在分析ipvs规则时也需要要求我们熟悉ipvs和ipset等。 在kubernetes网络中，还有其他网络插件实现了和kube-proxy相同的功能，若kube-router，cilium，他们都支持kube-proxy实现的功能，因此在使用上述网络插件时，集群里可以不部署kube-proxy。 kube-proxy在同步iptables规则时是通过iptables-save方式获取当前的规则，然后根据集群内的service状态动态对已有规则进行更新，最后使用iptables-save将规则在配置到系统上。kube-proxy重启不会影响到新建链接和已有链接的状态。在删除已有service，kube-proxy还会释放相关的链接，以及对不同协议的额外处理操作，这里不做太多分析。 下面是一个固定nginx的service的来进行分析iptables规则。 [root@master1 ~]# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 172.17.0.1 <none> 443/TCP 79d nginx LoadBalancer 172.17.45.122 192.168.64.1,4.3.2.1 80:30935/TCP 3d5h [root@master1 ~]# kubectl edit svc nginx Edit cancelled, no changes made. [root@master1 ~]# kubectl get svc nginx -oyaml apiVersion: v1 kind: Service metadata: creationTimestamp: "2021-10-16T05:55:09Z" labels: app: nginx name: nginx namespace: default resourceVersion: "619828" uid: 58ad25b5-6ee0-4a10-8c60-3a4371db1bbc spec: clusterIP: 172.17.45.122 clusterIPs: - 172.17.45.122…

kubernetes网络 – iptables讲解

发布于 by imliuda
iptables命令用来管理ip数据包的过滤。iptables由命令行工具和一系列内核模块组成，iptables命令行工具用来管理规则配置，内核模块负责执行具体的规则。iptables内核模块依托于linux的netfilter网络框架，netfilter框架提供了一系列的网络钩子，ip数据包在经过网络协议栈的时候会触发这些钩子以执行注册到这些钩子上的函数。iptables内核模块会在这些钩子上注册处理函数来实现对ip数据包的过滤等。 netfilter中提供了ip钩子，ipv6钩子，arp钩子和bridge钩子等，都有对应的命令行工具和内核模块，如ip6tables，ebtables等，可以为不同网络层提供过滤功能，关于这些不同的功能，可以参考对应的文档查看。我们主要关心iptables，来看下netfilter中包含的ip钩子： NF_IP_PRE_ROUTING ip数据包达到网络协议栈后最先触发的是这个钩子，在还未执行路由决策之前触发。 NF_IP_LOCAL_IN 在linux对ip数据包执行了路由之后，如果目的地是给本地系统时触发。 NF_IP_FORWARD 在linux对ip数据包执行了路由之后，如果需要转发给其他主机时触发。 NF_IP_LOCAL_OUT 本地数据包将要从本地发出时触发。 NF_IP_POST_ROUTING 在任何本地发出的或本地进行转发的数据包将要在网络设备发发出时触发。 ip数据包在netfilter框架中会经过上面的钩子进行处理，iptables内核模块在这些钩子上注册了不同的处理函数，可以对数据包进行处理。iptables中包含这几种对数据包的处理功能： 包过滤，主要用来实现防火墙功能 包修改，修改数据包中的信息 网络地址转换，实现网络地址转换功能 表、链和目标 iptables中有不同类型的表：默认的filter表，nat表，mangle表raw表，每张表里存放不同类型的规则。 不同的表中还包含不同的链，可以是内置的链或用户自定义的链，内置的链包括：INPUT，PREROUTING，FORWARD，POSTROUTING，OUTPUT，这些是和netfilter中的钩子相对应的，是执行我们规则的入口。 每个链中又包含不同的规则，规则定义如何对数据包进行匹配，以及匹配之后要执行的目标动作，这些动作可以是跳转到用户的自定义链或者是内置的ACCEPT，DROP，RETURN，还可以是扩展模块中的，如REJECT，MARK等。这些目标可以分为终结和非终结型，终结型规则在执行完之后不会再匹配接下来规则，如ACCEPT，DROP，REJECT，MASQUERADE（nat的都是），而非终结类型再执行完当前规则后还会继续匹配后面的规则，如MARK，LOG。链中的规则匹配是按照顺序机型匹配执行的，如果当前规则不匹配则会一直匹配下一条规则，直到终结或匹配结束。 ACCEPT是允许数据包通过。DROP是丢弃数据包。RETURN是从当前链返回到调用该链的上层链中的下一条继续匹配。如果是内置链，则当匹配结束，或有规则使用了RETURN作为目标动作时，则使用这个内置链的策略决定是否允许通过。 关注Network Layer，以及注意图中包的路径，表的先后顺序。 命令行工具 iptables规则表，链和规则的关系为：table <-> chain -> rule。 指定表 -t, --table table 指定要操作的表，如果不指定这个参数则操作默认的filter表，针对所有命令生效。 默认策略 -P, --policy chain target 指定内置表的默认策略，target必须是ACCEPT或DROP。 链操作 -L, --list [chain]列出指定链内的规则，如果chain未指定，则列出该表下的所有规则。可以和-n选项结合使用，来讲ip地址和端口以数字形式显示。可以和--line-numbers结合使用，显示行号。 -S, --list-rules [chain]列出指定链内的规则，如果chain未指定，则列出该表下的所有规则。该命令以定义规则所使用的命令方式展示。 -F, --flush [chain]清空指定链内的规则（链仍然保留），如果chain未指定，则清空该表下的所有规则。 -N, --new-chain chain创建新的链。 -X, --delete-chain [chain]删除用户自定义链。被删除的链不能有其他链引用，被删除的链必须为空，即里面没有规则。如果不指定chain的话将会尝试删除所有的用户自定义链。 -E, --rename-chain old-chain new-chain修改链的名称。 规则操作 -A, --append chain rule-specification添加规则到链中。 -C, --check chain rule-specification测试指定规则是否存在 -D,…