Cilium官方文档翻译proxy

　　快速开始
　　通过kubeadminit初始化控制平面节点，并跳过kubeproxy插件的安装：
　　根据您使用的CRI实现，您可能需要在kubeadminit命令中使用crisocket选项定制CRI。例如：如果您使用的是DockerCRI，您将使用crisocketunix：varruncridockerd。sock。kubeadminitskipphasesaddonkubeproxy
　　然后，通过指定控制平面节点IP地址和kubeadminit返回的令牌来加入工作节点（对于本教程，至少要向集群添加一个工作节点）：kubeadmjoin。。
　　如果您有多个网络接口，请确保在每个worker上正确设置kubelet的nodeip。否则，Cilium的kubeproxy替换可能无法正常工作。您可以通过运行kubectlgetnodesowide来验证这一点，以查看每个节点是否具有分配给每个节点上具有相同名称的设备的InternalIP。
　　对于已经通过DaemonSet安装了kubeproxy的集群，请使用以下命令将kubeproxy其删除。注意：该操作断开现有的服务连接，停止与服务相关的通信，直到安装了cilium替换：kubectlnkubesystemdeletedskubeproxyDeletetheconfigmapaswelltoavoidkubeproxybeingreinstalledduringaKubeadmupgrade（worksonlyforK8s1。19andnewer）kubectlnkubesystemdeletecmkubeproxyRunoneachnodewithrootpermissions：iptablessavegrepvKUBEiptablesrestore
　　注意请使用helm3完成本教程的安装操作，helm2是不兼容的。
　　设置helm仓库：helmrepoaddciliumhttps：helm。cilium。io
　　接下来，生成所需的YAML文件并部署它们。重要：请通过kubeadminit报告的kubeapiserverIP地址和端口号确认你设置的APISERVERIP和APISERVERPORT正确（kubeadm默认使用端口6443）。
　　因为kubeadminit是在没有kubeproxy的情况下直接运行，所以必须要设置这两个环境变量。尽管kubeadm将KUBERNETESSERVICEHOST和KUBERNETESSERVICEPORT使用ClusterIP的模式导出到环境变量中。但没有kubeproxy，网络是不通的。因此，需要通过以下配置使cilium了解该信息：APISERVERIPyourapiserveripKubeadmdefaultis6443APISERVERPORTyourapiserverporthelminstallciliumciliumciliumversion1。12。1namespacekubesystemsetkubeProxyReplacementstrictsetk8sServiceHost｛APISERVERIP｝setk8sServicePort｛APISERVERPORT｝
　　Cilium将自动在默认路径路径runciliumcgroupv2上挂载附加BPFcgroupv2程序所需的cgroup2文件系统。为此，它需要daemonset的init容器挂载主机proc路径。通过setcgroup。autoMount。enabledfalse可禁用自动挂载，并通过使用setcgroup。hostRoot设置一个已经在主机挂载的cgroupv2文件系统。例如，如果尚未安装，可以通过在主机上运行mounttcgroup2nonesysfscgroup命令来安装cgroupv2文件系统，然后找helm安装命令设置参数setcgroup。hostRootsysfscgroup。
　　helm最终将cilium安装为一个CNI插件，并使用eBPFkubeproxyreplacement来实现实现对ClusterIP、NodePort、LoadBalancer类型的Kubernetes服务和具有ExternalIP的服务的处理。此外，eBPFkubeproxyreplacement还支持容器的hostPort，因此不再需要使用portmap插件。
　　最后，验证cilium正确地在集群中安装，并准备好提供网络服务。kubectlnkubesystemgetpodslk8sappciliumNAMEREADYSTATUSRESTARTSAGEciliumfmh8d11Running010mciliummkcmb11Running010m
　　注意，在上述Helm配置中，kubeProxyReplacement已设置为严格（strict）模式。这意味着，如果缺少底层Linux内核支持，Ciliumagent将直接退出。
　　默认情况下，Helm将kubeProxyReplacement设置为disabled，这意味着cilium仅对集群内的ClusterIP服务启用的负载平衡。
　　Cilium在直接路由和隧道模式中都支持eBPFkubeproxyreplacement。验证设置
　　在使用上述快速入门指南部署Cilium之后，我们可以首先验证Cilium代理是否以所需模式运行：kubectlnkubesystemexecdsciliumciliumstatusgrepKubeProxyReplacementKubeProxyReplacement：Strict〔eth0（DirectRouting），eth1〕
　　使用verbose选项可以查看更多详细信息。kubectlnkubesystemexecdsciliumciliumstatusverbose〔。。。〕KubeProxyReplacementDetails：Status：StrictSocketLB：EnabledProtocols：TCP，UDPDevices：eth0（DirectRouting），eth1Mode：SNATBackendSelection：RandomSessionAffinity：EnabledGracefulTermination：EnabledNAT4664Support：EnabledXDPAcceleration：DisabledServices：ClusterIP：EnabledNodePort：Enabled（Range：3000032767）LoadBalancer：EnabledexternalIPs：EnabledHostPort：Enabled〔。。。〕
　　下一步，我们将创建一个Nginx部署。然后，我们将创建一个新的NodePort服务，并验证Cilium是否能正确处理网络服务。
　　以下yaml用于创建后端Pod：apiVersion：appsv1kind：Deploymentmetadata：name：mynginxspec：selector：matchLabels：run：mynginxreplicas：2template：metadata：labels：run：mynginxspec：containers：name：mynginximage：nginxports：containerPort：80
　　验证nginxpod启动并进入running阶段。kubectlgetpodslrunmynginxowideNAMEREADYSTATUSRESTARTSAGEIPNODENOMINATEDNODEREADINESSGATESmynginx756fb87568gmp8c11Running062m10。217。0。149apocnonenonemynginx756fb87568n5scv11Running062m10。217。0。107apocnonenone
　　接下来，为两个pod创建NodePort类型的service。kubectlexposedeploymentmynginxtypeNodePortport80servicemynginxexposed
　　验证NodePort类型的service是否创建成功。kubectlgetsvcmynginxNAMETYPECLUSTERIPEXTERNALIPPORT（S）AGEmynginxNodePort10。104。239。135none80：31940TCP24m
　　通过ciliumservicelist命令，我们可以验证cilium的eBPFkubeproxyreplacement创建了新的NodePort服务。在本例中，创建了具有端口31940的服务（设备eth0和eth1各一个）：kubectlnkubesystemexecdsciliumciliumservicelistIDFrontendServiceTypeBackend〔。。。〕410。104。239。135：80ClusterIP110。217。0。107：80210。217。0。149：8050。0。0。0：31940NodePort110。217。0。107：80210。217。0。149：806192。168。178。29：31940NodePort110。217。0。107：80210。217。0。149：807172。16。0。29：31940NodePort110。217。0。107：80210。217。0。149：80
　　创建一个用于nodeport测试的变量：nodeport（kubectlgetsvcmynginxojsonpath｛。spec。ports〔0〕。nodePort｝）
　　同时我们可以验证，宿主机上iptables应该查不到相关规则。iptablessavegrepKUBESVC〔emptyline〕
　　最后通过一个简单的curl测试显示暴露的NodePort和ClusterIP的连通性。curl127。0。0。1：nodeport！DOCTYPEhtmlhtmlheadtitleWelcometonginx！title〔。。。。〕curl192。168。178。29：nodeport！doctypehtmlhtmlheadtitlewelcometonginx！title〔。。。。〕curl172。16。0。29：nodeport！doctypehtmlhtmlheadtitlewelcometonginx！title〔。。。。〕curl10。104。239。135：80！DOCTYPEhtmlhtmlheadtitleWelcometonginx！title〔。。。。〕
　　如上，eBPFkubeproxyreplacement就正确设置并验证完成了。更多设置客户端源IP保留
　　ciliumeBPFkubeproxyreplacement可以通过多个选项来禁止访问NodePort时执行SNAT，避免数据发到对端时源IP地址丢失。externalTrafficPolicyLocal：eBPF支持Local策略。对于设置了externalTrafficPolicyLocal的service，集群内所有节点都可以对后端的节点发起连接。externalTrafficPolicyCluster：Cluster是创建service的默认策略。仅需要暴露TCP服务时这种策略下有多个选项可以实现保留外部流量源IP的能力：可以使用kubeproxyreplacement的DSR或者混合模式来保留源地址。MaglevConsistentHash
　　ciliumeBPFkubeproxyreplacement使用了TheMaglevpaper论文介绍的变种hash算法来实现在负载均衡后端endpoint一致性hash。这种算法提高了更好的负载平衡和故障恢复能力。集群中的某个节点在不用考虑同步其它节点的状态时就可以对某个5元组做出一致的后端选择。而在某个后端被删除后，后端查找表重新排列时对不相关的后端实例影响最小（重新分配后的一致性hash差异率约为1）。
　　通过下面的选项可以开启Maglevhash。loadBalancer。algorithmmaglev
　　Maglev是来自于google的负载均衡软件helminstallciliumciliumciliumversion1。12。1namespacekubesystemsetkubeProxyReplacementstrictsetloadBalancer。algorithmmaglevsetk8sServiceHost｛APISERVERIP｝setk8sServicePort｛APISERVERPORT｝
　　请注意，Maglevhash仅适用于外部（NS）流量。对于集群内服务连接（EW），套接字直接分配给服务后端，例如在TCP连接时，没有任何中间跳，因此不受Maglev的影响。Cilium的XDP加速也支持Maglevhash。
　　使用Maglevhash时有两个额外的配置：maglev。tableSize和maglev。hashSeed。maglev。tableSize为每个service定义了Maglev查找表，Maglev推荐将表空间（M）设置的要比后端实例数量（N）的最大值要大。在实践中，这意味着M应该大于100N，以保证后端更改的重新分配中最多有1的差异。M必须是素数。Cilium使用M的默认大小16381。以下M可以作为cilium支持为Maglev表大小选项：
　　maglev。tableSize
　　251hr509hr1021hr2039hr4093hr8191hr16381hr32749hr65521hr131071hr例如大小16381适用于集群任意一个服务最多有160个后端实例。如果服务有更多的后端，则后端更改的重新分配差异将增加。maglev。hashSeed设置该参数后cilium将不再依赖固定的种子（推荐设置该值），种子是一个base64编码的12字节随机数，可以通过headc12devurandombase64w0生成一个种子，集群中所有的ciliumagent必须使用相同的Maglev种子才能正常工作。
　　下面的部署示例生成种子后传递给Helm，同时将Maglev表大小设置为65521，允许给定服务的最大后端数为650（后端重新分配的属性差异最多为1）：SEED（headc12devurandombase64w0）helminstallciliumciliumciliumversion1。12。1namespacekubesystemsetkubeProxyReplacementstrictsetloadBalancer。algorithmmaglevsetmaglev。tableSize65521setmaglev。hashSeedSEEDsetk8sServiceHost｛APISERVERIP｝setk8sServicePort｛APISERVERPORT｝
　　注意相对于默认的负载均衡算法（loadBalancer。algorithmrandom），Maglev一致性算法会消耗更多的内存。DirectServerReturn（DSR）
　　默认情况下，CiliumeBPFNodePort的实现使用SNAT模式。也就是说，当节点外部流量到达并且节点确定负LoadBalancer、NodePort或具有externalIP的服务的后端位于其它节点时，则执行SNAT伪装源地址其将请求重定向到远程后端。这不需要对数据包的内容更改。但是来自后端的响应需要在将数据包直接返回到外部客户端之前，额外跳回到该童工负载均衡器的节点以在执行反向SNAT转换。
　　Helm选项loadBalancer。modedsr可以设置Cilium的eBPFNodePort在dsr模式下运行。在这种模式下，后端直接回复外部客户端，而不需要额外的跃点，这意味着后端通过使用serviceIPport作为源进行回复。DSR只在NativeRouting模式下工作，隧道模式下无法工作。
　　DSR模式的另一个优点是保留了客户端的源IP，因此可以在后端节点上对其进行策略匹配如果一个特定的后端可以被多个服务使用，那么后端需要知道它们回复数据包时应使用的serviceIPport。因此，cilium在定制了专属的IPv4选项（IPv6目的地选项），并把service的IPport信息编码在扩展报头中，代价是MTU值变小。对于TCP服务，Cilium仅对SYN数据包的serviceIPport进行编码，而不对后续数据包进行编码。如果想避免MTU减少，后面还介绍了混合DSR模式。如下一小节所述，其中DSR用于TCP，SNAT用于UDP。
　　请注意，DSR模式的使用在某些公共云提供商环境中可能不起作用，因为Cilium特定的IP选项可能会被底层网络结构丢弃。如果通过NodePort服务请求的远程节点上的服务存在连接问题，请首先检查数据包是否实际到达NodePortservice包含的后端节点。如果数据包无法传递，建议将切换回默认SNAT模式。
　　此外，在一些实现源目的地IP地址检查（例如AWS）的公共云提供商环境中，为了使DSR模式工作，必须禁用该检查。
　　启用DSR模式的配置如下：helminstallciliumciliumciliumversion1。12。1namespacekubesystemsettunneldisabledsetautoDirectNodeRoutestruesetkubeProxyReplacementstrictsetloadBalancer。modedsrsetk8sServiceHost｛APISERVERIP｝setk8sServicePort｛APISERVERPORT｝DSR与SNAT混合模式
　　Cilium还支持混合DSR和SNAT模式，例如对TCP连接执行DSR，对UDP执行SNAT。这样就不影响网络的MTU了，同时通过减少了额外的应答跃点（尤其是当TCP是工作负载的主要传输时），获得改进延迟收益。
　　loadBalancer。mode选项可以有三个可选值：snat（默认值）、dsr和hybrid。
　　下面是一个通过helm配置混合模式的示例：helminstallciliumciliumciliumversion1。12。1namespacekubesystemsettunneldisabledsetautoDirectNodeRoutestruesetkubeProxyReplacementstrictsetloadBalancer。modehybridsetk8sServiceHost｛APISERVERIP｝setk8sServicePort｛APISERVERPORT｝绕过直接在pod命名空间中执行SocketLoadBalancer
　　套接字级负载均衡器对cilium的下层数据路径透明，因为在应用程序发起connect（TCP或连接的UDP），sendmsg（UDP）或者recvmsg（UDP）系统调用时，会检查目标IP是否在现有的serviceIP中，并会从对应的Endpoint中选择一个后端作为实际目标。这意味着虽然应用程序假设它连接到服务地址，但相应的内核套接字实际上连接到的是后端的地址，因此不需要额外的底层NAT。
　　当应用自定义的重定向或流量操作依赖了pod命名空间中的原始ClusterIP时，或者由于pod的性质导致套接字级负载均衡器无法生效（如在KubeVirt，Kata容器环境下）时，cilium会自动降级为在veth接口上使用tc负载均衡器。
　　socketLB。hostNamespaceOnlytrue选项可以开启绕过模式。这将绕过bpf钩子对connect（）和sendmsg（）系统调用套接字重写，并将原始数据包传递到下一个操作阶段（例如，perendpointrouting下的堆栈），并重新启用tcbpf程序中的服务查找。
　　下面示例展示了如何配置在kubeproxyfree环境中绕过SocketLB：helminstallciliumciliumciliumversion1。12。1namespacekubesystemsettunneldisabledsetautoDirectNodeRoutestruesetkubeProxyReplacementstrictsetsocketLB。hostNamespaceOnlytrueLoadBalancerNodePortXDP加速
　　cilium1。8引入了XDP（eXpressDataPath），当cilium需要转发请求，且后端位于远端节点时，cilium内置了对NodePort、LoadBlancer和ExternalIP服务加速的功能。XDP的eBPF程序直接在网卡上运行，而不是在更高层运行。
　　选项loadBalancer。acceleration值为native可以开启加速，默认使用disable禁用加速。大多数10GB或更高速率的网卡驱动程序都在新版的内核上支持了nativeXDP。在云上大多数驱动程序都支持SRIOV变体，也支持nativeXDP。对于私有化部署，ciliumXDP加速可以与kubernetes负载均衡器（如MetalLB）配合使用。加速器仅能在支持直接路由的单个设备上使用。
　　在大规模的集群环境，应该注意考虑调整eBPF默认Map的大小。例如通过config。bpfMapDynamicSizeRatio可以在ciliumagent启动时根据系统内存来动态设置几个占用空间较大的eBPFMap的大小。
　　loadBalancer。acceleration选项支持与DSR、SNAT和混合模式配合使用。下面是结合混合模式负载均衡器使用的例子：helminstallciliumciliumciliumversion1。12。1namespacekubesystemsettunneldisabledsetautoDirectNodeRoutestruesetkubeProxyReplacementstrictsetloadBalancer。accelerationnativesetloadBalancer。modehybridsetk8sServiceHost｛APISERVERIP｝setk8sServicePort｛APISERVERPORT｝
　　在多个设备的环境中，可以通过指定设备或者通过cilium设备自动检测机制选择多个设备来暴露节点端口，所有被选中的设备都会执行XDP加速。这意味着需要每个设备的驱动都支持nativeXDP，此外处于性能的原因，推荐在使用多设备加速环境的内核版本5。5。
　　下表给出了支持nativeXDP加速的驱动列表。通过ethtoolieth0可以查看设备使用的驱动。ethtoolieth0driver：nfp〔。。。〕
　　Vendor
　　Driver
　　XDPSupport
　　Amazon
　　ena
　　5。6
　　Broadcom
　　bnxten
　　4。11
　　Cavium
　　thunderx
　　4。12
　　Freescale
　　dpaa2
　　5。0
　　Intel
　　ixgbe
　　4。12
　　ixgbevf
　　4。17
　　i40e
　　4。13
　　ice
　　5。5
　　Marvell
　　mvneta
　　5。5
　　Mellanox
　　mlx4
　　4。8
　　mlx5
　　4。9
　　Microsoft
　　hvnetvsc
　　5。6
　　Netronome
　　nfp
　　4。10
　　Others
　　virtionet
　　4。10
　　tuntap
　　4。14
　　Qlogic
　　qede
　　4。10
　　Socionext
　　netsec
　　5。3
　　Solarflare
　　sfc
　　5。5
　　TexasInstruments
　　cpsw
　　5。3
　　通过ciliumstatus命令可以反映出ciliumkubeproxyXDP模式。kubectlnkubesystemexecdsciliumciliumstatusverbosegrepXDPXDPAcceleration：Native
　　注意，由于数据包的处理在网络堆栈的更底层，所以在XDP层处理NodePort服务并推回设备的数据包通过tcpdump不可见。通过cilium的监视器命令和度量计数器可用于观察XDP处理的数据包。NodePort设备、端口和绑定设置
　　当运行CiliumeBPFkubeproxyreplacement时，NodePort、LoadBalancer和externalIPservice通过主机默认路由和kubernetes已分配InternalIP或ExternalIP的本地IP地址是可以访问的（InternalIP优于ExternalIP）。要更改绑定的设备，可以通过Helmdevices选项。例如：devices｛eth0，eth1，eth2｝。列出的设备名必须在每个cilium管理的节点都存在。如果设备在不同节点之间不一直，则可以使用通配符选项，例如，deviceseth，这将匹配以前缀eth开头的任何设备。如果没有设备可以匹配，cilium将尝试执行自动检测。
　　当使用多个设备时，只有一个设备可以用于cilium节点之间的直接路由。默认情况下，如果通过设备检测到或指定了单个设备，则Cilium将使用该设备进行直接路由。否则，Cilium将使用设置了KubernetesInternalIP或ExternalIP的设备。如果两者都存在，则内部IP优先于外部IP。要更改直接路由设备，请设置nodePort。directRoutingDeviceHelm选项，例如：directRoutingDeviceeth。如果有多个设备匹配通配符选项，Cilium将按照字母数字递增的顺序对它们进行排序，并选择第一个。如果设备中不存在直接路由设备，Cilium会将该设备添加到后一个列表中。直接路由设备也用于NodePortXDP加速（如果启用）。
　　此外，基于SocketLB功能，可以从集群内的主机或pod通过其公共、本地（docker前缀名称除外）或环回地址（例如127。0。0。1：NODEPORT）访问NodePort服务。
　　如果kubeapiserver配置为使用非默认NodePort范围（3000032766），则必须通过nodePort。range选项将相同范围传递给Cilium。例如，作为节点端口。范围为1000032767的范围nodePort。range10000，32767。
　　如果节点端口范围与临时端口范围（net。ipv4。iplocalportrange）重叠，Cilium会将节点端口范围附加到保留端口（net。ipv4。iplocalreservedports）。这是为了防止节点端口服务劫持源端口与服务端口匹配的主机本地应用程序的流量。要禁用保留端口，请设置nodePort。autoProtectPortRangesfalse。
　　默认情况下，NodePort实现防止应用程序bind（2）对NodePort服务端口的请求。在这种情况下，应用程序通常会看到bind：Operationnotpermitted的错误。默认情况下，对于较旧的内核，或者从v5。7内核开始，只针对主机名称空间，因此不再影响任何应用程序podbind（2）请求。专家用户可以通过nodePort。bindProtectionfalse来更改此设置。NodePort对FHRP和VPC的支持
　　CiliumeBPFkubeproxyreplacement与FHRP（如VRRP）或Cisco的HSRP和VPC（也称为多机箱以太网通道）结合使用时，Cilium默认的FIB优化配置将绕过对FIB表的查找，使用目的地为NodePort的ingress向的源IP地址对应的mac地址作为应答时转发L2帧的目的地址，导致数据路径出现问题。这种环境中，最好关闭Cilium对FIB查找优化。确保应答数据包能在忽略来源地址，始终转发到当前活动的对端FHRP对应的mac地址。
　　通过设置bpf。lbBypassFIBLookupfalse可以禁用优化：helminstallciliumciliumciliumversion1。12。1namespacekubesystemsetkubeProxyReplacementstrictsetbpf。lbBypassFIBLookupfalse配置BPFMap容量
　　在大规模的集群环境，应该注意考虑调整eBPF默认Map的大小。使用Helm选项可以调节这些配置。
　　bpf。lbMapMax默认大小是65535，调节该参数可以增加BPFLBservice条目，后端和关联的映射的大小。helminstallciliumciliumciliumversion1。12。1namespacekubesystemsetkubeProxyReplacementstrictsetbpf。lbMapMax131072支持ContainerHostPort
　　尽管主机端口映射不是kubeproxy的能力，但CiliumeBPFkubeproxyreplacement还是选择了在无需配置HelmCNIcni。chainingModeportmap选项时，原生的支持主机端口映射。
　　kubeProxyReplacementstrict模式下，将自动启用主机端口映射支持能力。如果不在此模式下，则需要通过hostPort。enabledtrue启用该功能。
　　如果指定的hostPort没有额外的hostIP，则Pod将同NodePort类型的service一样自动发现主机的地址暴露给外部，例如使用KubernetesInternalIP或ExternalIP暴露服务地址（如果设置）。此外，还可以通过节点上的环回地址（例如127。0。0。1：hostPort）访问Pod。如果除了hostPort之外，还为Pod指定了hostIP，则Pod将仅在给定的hostIP上公开。0。0。0。0的hostIP与未指定hostIP行为相同。注意hostPort不应在NodePort端口范围内，以避免冲突。
　　下面在没有kubeproxy的环境下使用deployment工作负载展示一个示例：helminstallciliumciliumciliumversion1。12。1namespacekubesystemsetkubeProxyReplacementstrictsetk8sServiceHost｛APISERVERIP｝setk8sServicePort｛APISERVERPORT｝
　　确认每个节点都通过INTERNALIP或EXTERNALIP知道自身的ip地址。kubectlgetnodesowideNAMESTATUSROLESAGEVERSIONINTERNALIPEXTERNALIP〔。。。〕apocReadymaster6h15mv1。17。3192。168。178。29none〔。。。〕tankReadynone6h13mv1。17。3192。168。178。28none〔。。。〕
　　如果没有发现nodeip，则可以通过kubelet启动参数nodeip来指定。假设eth0是默认网卡名，下面脚本可以用于发现nodeip。echoKUBELETEXTRAARGSnodeip（ip4oashoweth0awk｛print4｝cutdf1）teeaetcdefaultkubelet
　　然后更新etcdefaultkubelet文件，重启kubelet。
　　为了验证是否已在Cilium中启用HostPort功能，通过ciliumstatusCLI命令的KubeProxyReplacement信息行可以观察到相关信息。如果已成功启用，HostPort将显示为已启用，例如：kubectlnkubesystemexecdsciliumciliumstatusverbosegrepHostPortHostPort：Enabled
　　下面的yaml指定hostPort：8080验证端口映射。apiVersion：appsv1kind：Deploymentmetadata：name：mynginxspec：selector：matchLabels：run：mynginxreplicas：1template：metadata：labels：run：mynginxspec：containers：name：mynginximage：nginxports：containerPort：80hostPort：8080
　　部署后，我们可以验证CiliumeBPFkubeproxyreplacement是否为容器暴露HostPort8080端口。kubectlexecitnkubesystemciliumfmh8dciliumservicelistIDFrontendServiceTypeBackend〔。。。〕5192。168。178。29：8080HostPort110。29。207。199：80
　　类似地，我们可以通过主机名称空间中的iptables检查主机端口服务是否存在iptables规则：iptablessavegrepHOSTPORT〔emptyline〕
　　最后使用curl测试联通性：curl192。168。178。29：8080！DOCTYPEhtmlhtmlheadtitleWelcometonginx！title〔。。。。〕
　　删除deployment后，对应的HostPort也被删除。kubectldeletedeploymentmynginxkubeproxy混合模式
　　CiliumeBPFkubeproxyreplacement支持多种配置模式。它可以完全替换kubeproxy，当linux内核不支持完整的kubeproxyreplacement时也可以与kubeproxy共存。
　　注意：在使用kubeproxyreplacement和kubeproxy共存时，这两个组件各自独立运行。这意味着如果需要在集群中添加或删除kubeproxyreplacement，如果需要将服务流量委托给kubeproxy，则现有的服务流量会中断。这是因为两个NAT表彼此之间数据并不一样。
　　下面详述kubeproxyreplacement的选项：kubeProxyReplacementstrict：此选项期望CiliumeBPFkubeproxyreplacement完全替代kubeproxy运行。ciliumagnet启动后将负责处理ClusterIP、NodePort、LoadBalancer类型的Kubernetes服务，以及带有externalIPs和HostPort的服务。如果未满足底层内核版本要求，则ciliumagent将在启动时打印错误消息。kubeProxyReplacementpartial：此选项为混合模式，即kubeproxy正常在集群中运行，kubeproxyreplacement替换并优化部分kubeproxy的能力。partial选项需要用户手动指定需要eBPFkubeproxyreplacement替换的功能。当kubeProxyReplacement设置为partial时，请确保还将enableHealthCheckNodeport设置为false，以便ciliumagnet不会启动对NodePort健康检查。与strict模式类似，如果不满足最低内核要求，ciliumagent将在启动时发出错误消息。socketLB。enabled，nodePort。enabled，externalIPs。enabled和hostPort。enabled四个细粒度配置默认都是false。下面提供了部分选项的一些示例配置。
　　下面的Helm选项相当于kubeProxyReplacementstrict：helminstallciliumciliumciliumversion1。12。1namespacekubesystemsetkubeProxyReplacementpartialsetsocketLB。enabledtruesetnodePort。enabledtruesetexternalIPs。enabledtruesethostPort。enabledtruesetk8sServiceHost｛APISERVERIP｝setk8sServicePort｛APISERVERPORT｝
　　下面的Helm选项相当于kubeproxy环境中使用v1。6或更早版本Cilium处理service，即为Pod提供ClusterIP：helminstallciliumciliumciliumversion1。12。1namespacekubesystemsetkubeProxyReplacementpartial
　　以下Helm选项将优化Cilium的NodePort、LoadBalancer和externalIPsservice，并在kubeproxy环境中处理外部ingress到cilium管理的节点的流量：helminstallciliumciliumciliumversion1。12。1namespacekubesystemsetkubeProxyReplacementpartialsetnodePort。enabledtruesetexternalIPs。enabledtruekubeProxyReplacementdisabled：完全禁用kubeproxyreplacement，但从pod内访问ClusterIP服务除外。这是CiliumHelm部署的默认模式。
　　通过命令行工具查看当前ciliumkubeproxyreplacement的模式：kubectlnkubesystemexecdsciliumciliumstatusgrepKubeProxyReplacementKubeProxyReplacement：Strict〔eth0（DR）〕优雅退出
　　ciliumkubeproxyreplacement支持服务后端pod优雅退出，该功能需要kubernetes版本大于等于1。20，且开启了EndpointSliceTerminatingCondition特性。ciliumagent默认会检测pod的Terminating状态，如果不需要可以通过选项enablek8sterminatingendpoint来关闭该特性。
　　ciliumstatus命令可以查看cilium的特性标识：kubectlnkubesystemexecdsciliumciliumstatusverbose〔。。。〕KubeProxyReplacementDetails：〔。。。〕GracefulTermination：Enabled〔。。。〕
　　当ciliumagent接收到端点Terminating的Kubernetes更新事件时，该端点的数据路径状态将被删除，这样它将不会为新连接提供服务，但端点已有的活动连接要能正常终止。当agent收到端点的Kubernetes删除事件时，端点状态被完全删除。Kubernetespodtermination文档包含terminationGracePeriodSeconds的行为和配置的更多信息。SessionAffinity
　　CiliumeBPFkubeproxyreplacement支持kubernetesServiceSession亲和。从同一pod或主机到配置了sessionAffinity：ClusterIP的服务的每个连接，将始终选择相同的服务端点。亲和性的默认超时时间为三小时（根据服务的每个请求更新）。如果有需要，可以通过Kubernetes的sessionAffinityConfig进行配置。
　　亲和关联取决于请求的来源。如果从集群外部向服务发送请求，则该请求的源IP地址用于确定端点关联。如果请求是从集群内部发送的，则源取决于使用使用socketLB特性用于ClusterIP服务的负载均衡。如果是，则客户端的网络名称空间cookie用作源。后者是在5。7Linux内核中引入的，用于在套接字层实现亲和性，socketLB在该层运行（不能使用源IP，因为端点选择发生在内核构建网络包之前）。如果未使用socketLB（即在pod网络接口上对每个数据包实现负载均衡），则将请求的源IP地址用作源。
　　cilium默认启用了Session亲和特性支持，对于不支持网络名称空间cookie的旧内核，将在集群内场景中降级为基于固定cookie值的。主机上的所有应用程序为访问配置了Session亲和服务选择的服务端点相同。要禁用该功能，请将config。sessionAffinity设置为false。
　　当不使用固定cookie值时，具有多个端口的服务Session亲和的依据是每个服务IP和端口。这意味着从相同源发送到相同服务端口的给定服务的所有请求都将路由到相同的服务端点，从相同源发送到不同服务端口的相同服务的两个请求可以路由到不同的服务端点。
　　对于使用kubeproxy运行的用户（即，禁用Cilium的kubeproxyreplacement），当从在非主机网络命名空间中运行的pod发送请求时，ClusterIP服务负载平衡仍在pod网络接口上执行（直到修复GH16197）。在这种情况下，默认情况下禁用Session亲和支持。要启用该功能，请设置config。sessionAffinitytrue。kubeproxyReplacement健康检查服务
　　要为kubeproxyReplacement启用健康检查服务，必须设置kubeProxyReplacementHealthzBindAddr选项（默认情况下禁用）。该选项接受健康检查服务器服务的IP地址和端口。例如，要启用IPv4设置kubeproxyReplacementHealthzBindR0。0。0。0：10256，IPv6则设置为kubeProxyReplacementHealthzBindAddr〔：：〕：10256。可以通过HTTPhealthz端点访问健康检查服务器。LoadBlancer源地址范围检查
　　当使用spec。loadBalancerSourceRanges配置LoadBalancer服务时，Cilium的eBPFkubeproxyReplacement将从外部（例如集群外流量）对该服务的访问限制为该字段中指定的白名单CIDR。如果该字段为空，则不会配置访问限制。
　　当从集群内部访问服务时，kubeproxyReplacement将忽略该字段，无论是否设置。这意味着集群中的任何pod或任何主机进程都将能够在内部访问LoadBalancer服务。
　　默认情况下，负载平衡器源地址范围检查功能已启用，可以通过设置config。svcSourceRangeCheckfalse来禁用。在某些特殊云环境下禁用检查是有意义的，例如AmazonNLB原生支持源地址范围检查，因此可以禁用cilium的功能。Service代理名字配置
　　kubeproxy都支持配置service。kubernetes。ioserviceproxyname选项，代表该kubeproxy只管理匹配serviceproxyname的service。Cilium通过Helmk8s。serviceProxyName选项也能做到同样的功能。该选项默认为空字符串，代表Cilium不处理任何带有service。kubernetes。ioserviceproxyname标签的service。
　　关于service。kubernetes。ioserviceproxyname标签和其工作流程，请参阅https：github。comkubernetesenhancementsblob3ad891202dab1fd5211946f10f31b48003bf8113kepssignetwork2447MakekubeproxyserviceabstractionoptionalREADME。md。
　　如果Cilium设置了服务代理名字，请确认kubedns和kubernetes这种必须的service设置了代理标签。TopologyAwareHints
　　CiliumeBPFkubeproxyreplacement支持kubernetesservice拓扑逻辑感应提示，要开启该特性请配置选项loadBalancer。serviceTopologytrue。NeighborDiscovery
　　当启用kubeproxy替换时，Cilium会主动对集群中的节点进行L2邻居发现。这是因为负载均衡器需要为后端填充L2地址，而快速数据路径中不支持动态按需解析邻居。
　　在Cilium1。10或更早版本中，agent本身包含一个ARP解析库，它在其中定时触发发现并刷新加入集群的新节点。解析后的邻居条目被推入内核并刷新为永久条目。在某些少见的场景下，Cilium1。10或更早版本可能会在邻居表中留下过期的条目，导致某些节点之间的数据包丢失。要跳过Cilium邻居发现回退到依赖Linux内核来发现邻居，可以将enablel2neighdiscoveryfalse选项传递给ciliumagent。
　　请注意，依赖Linux内核也可能导致某些数据包丢失。例如，在中继节点上可能发生的丢弃NodePort请求（中继节点即接收到服务分组并将其转发到服务端点的节点）。如果内核中没有L2邻居条目（由于该条目被垃圾收集，或者由于内核没有执行邻居解析），则可能会发生丢包的情况。这是因为在BPF快速路径程序中不支持解析L2地址，例如在XDP层。
　　从Cilium1。11开始，完全重新设计了邻居发现，并且Cilium内部ARP解析库已从agnet中删除。agent现在完全依赖Linux内核来发现同一L2网络上的网关或主机。ciliumagent中支持IPv4和IPv6邻居发现。根据我们最近在Plumbers上介绍的内核工作，managed邻居条目提案已被接受，并将在Linux内核v5。16或更高版本中可用，Ciliumagent将检测并透明使用托管邻居。在这种情况下，agnet将加入集群的新节点的L3地址向下推，作为外部学习的托管邻居条目。在状态展示方面，iproute2将托管邻居显示为managedexternlearn。externlearn属性防止内核的相邻子系统对条目进行垃圾收集。如果在一段时间内没有活动流量，Linux内核会动态解析并定期刷新这些受管理邻居条目。也就是说，内核试图始终将它们保持在可达状态。对于不存在托管邻居条目的Linux内核v5。15或更早版本，Ciliumagent将新节点的L3地址推送到内核中进行动态解析，使用agnet触发的定期刷新。在状态展示上，iproute2仅显示为externlearn。如果在某一段时间内没有活动流量，则Ciliumagent控制器会触发基于Linux内核的重新解析，以尝试将它们保持在可访问状态。如果需要，可以通过ciliumagent的arpingrefreshperiod30s选项来改变刷新间隔。默认周期为30秒，对应内核的可达性管理时间周期。
　　邻居发现支持多设备环境，其中每个节点具有多个设备和到另一节点的下一跳。Ciliumagent会管理推送所有目标设备（包括直接路由设备）的邻居条目。目前，它支持为每个设备都配置一个nexthops下一跳信息。以下示例说明了邻居发现如何在多设备环境中工作。每个节点都有两个设备连接到不同的L3网络（10。69。0。6426和10。69。0。12826两个不同的子网），全局范围地址分别是10。69。0。126和10。69。0。226。从node1到node2的下一跳是10。69。0。66deveno1或10。69。0。130deveno2。在这种情况下，ciliumagent推送10。69。0。66deveno1和10。69。0。130deveno2的邻居条目。node1node210。69。0。12610。69。0。226eno1eno110。69。0。652610。69。0。6626eno2eno210。69。0。1292610。69。0。13026
　　在node1上：iprouteshow10。69。0。2nexthopvia10。69。0。66deveno1weight1nexthopvia10。69。0。130deveno2weight1ipneighshow10。69。0。66deveno1lladdr96：eb：75：fd：89：fdexternlearnREACHABLE10。69。0。130deveno2lladdr52：54：00：a6：62：56externlearnREACHABLE外部访问ClusterIPService
　　Cilium默认禁止从集群外部访问ClusterIP类型的service，通过bpf。lbExternalClusterIPtrue选项可以关闭该限制。常见问题验证eBPFcgroup程序注入
　　Cilium连接BPFcgroup程序以实现基于socket的负载均衡（也被称为hostreachable服务）。如果你的ClusterIP服务连接出现连接问题，请检查操BPF程序是否连接到了主机cgroup根目录。默认的cgrouproot路径为runciliumcgroupv2。注意如果容器运行时以cgroupnamespace模式运行，ciliumagentpod可能将BPFcgroup程序附加到virtualizedcgrouproot。在这种情况下，基于CiliumeBPFkubeproxyreplacement的负载均衡可能失效，导致连接问题。有关详细信息，请确保您有修复拉取请求。在运行ciliumagentpod的kubernetes节点上运行以下命令可以查看cgroup的状态。mountgrepcgroup2noneonrunciliumcgroupv2typecgroup2（rw，relatime）bpftoolcgrouptreerunciliumcgroupv2CgroupPathIDAttachTypeAttachFlagsNamerunciliumcgroupv210613devicemulti48497connect448493connect648499sendmsg448495sendmsg648500recvmsg448496recvmsg648498getpeername448494getpeername6限制CiliumeBPFkubeproxyreplacement不能与IPsec或WireGuard传输加密混用。CiliumeBPFkubeproxyreplacement依赖socketLB特性，该特性基于BPFcgrouphook实现服务转换。如果需要部署libceph，最少需要5。8版本支持getpeername（2）地址转换hook的内核。Cilium的DSRNodePort模式目前不兼容TCPFastOpen（TFO）的环境。在这种场景，建议切换到snat模式。CiliumeBPFkubeproxyreplacement不支持SCTP协议，仅支持TCPUDP协议。CiliumeBPFkubeproxyreplacement不允许Pod的hostPort配置与NodePort范围重叠。如果配置错误，hostPort设置将被忽略，Ciliumagent日志会发出警告。不支持将主机IP显式绑定到主机命名空间中的环回地址，Ciliumagent同样会在日志中发出警告。当CiliumeBPFkubeproxyreplacement与Kubernetes（1。19）但支持EndpointSlices的版本一起使用时，没有selector选择器和后端EndpointSlices的服务将无法工作。因为Cilium仅监听对EndpointSlices对象所做的更改（如果存在），并在这些情况下忽略Endpoints。Kubernetes1。19版本引入了EndpointSliceMirroring控制器，该控制器将自定义Endpoints资源关联相应的EndpointSlices，从而允许支持Endpoints工作。有关更详细的讨论，请参阅GitHubissue12438。小于5。7版本的内核不支持networknamespacecookie，cilium无法区分主机和pod的命名空间。所以在pod内通过回环地址可以访问k8s的服务。多设备环境中的邻居发现与运行时设备检测无法同时使用，也就是说邻居发现的目标设备不跟随设备变化而动态修改。
　　更多资料
　　下面的资料更详细的说明了CiliumeBPFkubeproxyreplacement内部工作流程：《从kubeproxy和iptables中解放kubernetes》（KubeConNorthAmerica2019，slides，video）《使用BPF和XDP实现大规模Kubernetes服务负载平衡》（LinuxPlumbers2020，slides，video）《容器的革命性技术eBPF》（Fosdem2020，slides，video）《ciliumsocketLB的内核改进》（LSFMMBPF2020，slides）