Kubernetes是古代容器化利用不可或缺的弱小、牢靠的根底平台。本文将介绍Kubernetes中与网络相干的组件，正是这些组件撑持Kubernetes成为云原生利用的首选基础设施。原文: Networking in Kubernetes
网络是Kubernetes中十分值得了解的重要主题，它帮忙Kubernetes集群上的利用可能互相通信，以及反对利用与内部服务的通信。
在Kubernetes集群中，每个pod都有本人惟一的IP地址，该IP地址在集群内可路由。这个IP地址通常由Kubernetes网络插件调配，该插件负责配置集群网络。网络插件是Kubernetes网络架构的要害组件，有多种抉择，如Calico、Flannel和Weave Net。
除了网络插件，Kubernetes还包含许多与网络相干的组件，如负责跨多个pod均衡网络流量的kube-proxy，以及为一组pod提供稳固的IP地址和DNS名称的Service对象。
网络对集群上运行的应用程序性能和可靠性有重要影响，因而对于任何应用Kubernetes的人来说，理解网络在Kubernetes中的工作形式十分重要。
Ingress
在Kubernetes中，Ingress是一类API对象，提供了从内部拜访集群内服务的配置形式。Ingress资源通常定义一组规定，指定如何依据传入申请的主机和门路将传入流量路由到适当的服务，从而将来自集群外的HTTP和HTTPS路由给集群内的服务。
当申请进入Kubernetes集群时，首先达到Ingress控制器，该控制器负责依据Ingress资源中定义的规定治理和路由流量。Ingress控制器基于Ingress资源中定义的一组规定来确定流量应该路由到哪里。为了使Ingres无效工作，须要应用Nginx，AWS之类的Ingress控制器。
一旦Ingress控制器确定了要将流量路由到哪个服务，就会将申请转发到服务的ClusterIP(这是由Kubernetes网络插件调配给服务的外部IP地址)，而后该服务基于本人的规定来确定将流量转发到哪个pod。
流量达到指标pod后，由pod内运行的利用程序处理。而后，响应通过雷同的门路(通过服务和Ingress控制器)发送回原始申请发送方。
须要留神的是，Ingress资源只负责将流量路由到集群内的服务，而不解决任何身份验证或安全性。因而，通常须要与其余安全措施(如TLS终端或Web应用程序防火墙(WAF))联合应用，以提供安全可靠的服务。
DNS
DNS(Domain Name System)是服务和pod之间互相发现和通信的一种形式，是一种负责将服务名称转换或解析为IP地址的服务。Kubernetes集群中的每个pod都被调配了惟一的主机名，该主机名由pod名及其命名空间组成。默认状况下，每个主机名都能够在集群DNS命名空间中解析。
当在Kubernetes中创立服务时，会调配一个稳固的DNS名称，用于从集群内的其余pod和服务拜访该服务。
DNS名称的格局通常为servicename.namspace.svc.cluster.local，其中servicename是服务名，namespace为服务所在的Kubernetes命名空间，cluster.local为集群默认的DNS域。
当pod想要与服务通信时，能够简略的通过服务的DNS名称连贯。Kubernetes DNS服务将把DNS名称解析为调配给该服务的相应ClusterIP，并将流量路由到适当的pod。
除了解析服务的DNS名称外，Kubernetes还反对自定义DNS配置，容许指定解析DNS查问时应应用的其余DNS服务器或搜寻域。如果须要在Kubernetes集群之外解析DNS名称，例如拜访内部服务或API，就会十分有用。
总之，DNS是Kubernetes网络的要害组件，容许服务和pod互相发现和通信，并且是在Kubernetes集群上部署牢靠和可扩大应用程序的基础设施的重要组成部分。
Core DNS
CoreDNS是Kubernetes中用于服务发现和DNS解析的风行的DNS服务实现，是Kubernetes的默认DNS服务，并确保pod和服务都有FQDN(Fully Qualified Domain Name)。CoreDNS是灵便、可扩大的DNS服务，能够很容易被集成到Kubernetes集群中，并且能够自定义以反对宽泛用例。没有CoreDNS，集群通信将无奈工作。
在Kubernetes中，CoreDNS通常作为pod部署在集群中，负责解析服务和pod的DNS查问。CoreDNS应用Kubernetes API检索无关服务和pod的信息，并主动为每个服务和pod生成DNS记录。
在Kubernetes中应用CoreDNS的益处之一是它是高度可配置的，并且能够扩大以反对自定义插件和DNS供应商。例如，能够应用CoreDNS插件来增加对自定义DNS域的反对，或者与内部DNS供应商集成。
CoreDNS的另一个益处是，它提供了比Kubernetes中以前的默认DNS服务kube-dns更好的性能和可伸缩性。CoreDNS由Go语言编写，其设计更轻量、高效，非常适合在高流量的Kubernetes环境中解决大量DNS查问。
要在Kubernetes集群中应用CoreDNS，能够通过Kubernetes manifest文件或Helm chart将其部署为pod。部署后，能够配置CoreDNS服务以满足特定需要，例如增加自定义DNS供应商、定义自定义DNS域，或与其余Kubernetes组件(如Ingress或ExternalDNS)集成。
总之，CoreDNS是弱小灵便的DNS服务实现，非常适合利用在Kubernetes集群中，并为古代云原生利用的服务发现和DNS解析提供了松软的根底。
探针(Probes)
在Kubernetes中，探针用于确定pod中运行的容器健康状况，是Kubernetes自我修复和主动扩容性能的要害局部，为集群提供了一种自动检测和从不衰弱的容器中复原的办法，可用于检测容器状态。
Kubernetes提供了三种类型的探针:
存活状态探针(Liveness Probe)
此类型探针用于确定容器是否仍在运行并且运行失常。该探针定期向容器发送申请，如果容器没有响应或响应谬误，探针将把容器标记为不衰弱并触发重启。
如果利用正在运行但无奈实现任何工作，存活状态探针能够捕捉死锁，重新启动容器，从而在容错的前提下进步利用的可用性。
就绪状态探针(Readiness Probe)
这种类型的探针用于确定容器是否筹备好开始接管流量。就绪探针定期向容器发送申请，如果容器胜利响应，则将其标记为筹备好接管流量。如果容器响应失败或谬误，将被标记为未筹备好，并且在再次筹备好之前不会接管任何流量。
启动探针(Startup Probe)
这种类型的探针用于确定容器是否处于启动过程中。启动探针定期向容器发送申请，如果容器响应胜利，将被标记为筹备好接管流量。如果容器响应失败或谬误，启动探针将持续发送申请，直到容器筹备好，或者达到可配置的超时工夫。
Kubernetes的探针定义在pod标准中，通过YAML进行配置，每个探针都由一组参数定义，例如探针类型、要探测的端点、超时工夫、周期以及胜利和失败阈值。
总之，探针是Kubernetes的弱小性能，使容器可能在产生故障或无响应的状况下收到监控并重新启动，有助于进步在Kubernetes集群上运行的应用程序的可靠性和可用性。
Netfilter
在Kubernetes中，Netfilter用于实现网络策略，以管制集群中pod之间的网络流量。网络策略是Kubernetes对象，定义了流量如何在pod之间流动的规定，并通过Netfilter规定来执行这些策略。
当Kubernetes集群利用了网络策略后，Kubernetes API服务与网络插件通信，网络插件负责在底层网络基础设施中配置网络规定，并生成Netfilter规定来执行网络策略。
网络插件生成的Netfilter规定基于网络策略中指定的选择器，用于确定哪些pod应该受到策略的影响，抉择能够基于宽泛的规范，例如pod标签、命名空间或IP地址。网络插件生成与指定选择器匹配的Netfilter规定，对匹配的报文执行策略中指定的动作。
例如，能够定义一个网络策略，容许流量仅在具备特定标签的pod之间流动。网络插件将生成Netfilter规定来匹配带有该标签的pod之间的数据包，而后容许这些数据包通过网络。相似的，能够定义网络策略回绝两个特定pod之间的流量，在这种状况下，网络插件将生成Netfilter规定抛弃这些pod之间的数据包。
总之，Netfilter是Kubernetes中网络策略实现的要害组件，容许对集群中pod之间的网络流量进行细粒度管制，并提供弱小机制来执行平安和拜访控制策略。
IPTables
IPTables是基于linux的防火墙工具，提供配置和管理网络过滤规定的性能。在Kubernetes中，IPTables用于实现网络策略，管制pod和服务之间的流量。
在Kubernetes中创立网络策略时，kube-proxy组件创立IPTables规定强制执行该策略。当网络流量通过pod或服务所在的节点时，这些将被规定利用于网络流量。
Kubernetes基于网络策略选择器和规定生成IPTables规定，选择器确定策略利用于哪些pod，而规定定义容许或回绝哪些流量。例如，能够创立只容许流量发送到带有特定标签的pod上的特定端口的规定。
Kubernetes生成的IPTables规定被插入到内核的IPTables链中，从而用于决定如何解决网络流量。这些链以特定程序进行匹配，第一个匹配的规定将决定对数据包采取的操作。
Kubernetes还通过IPTables实现Kubernetes服务，为拜访一组pod提供稳固的IP地址和DNS名称。当在Kubernetes中创立服务时，kube-proxy会创立一个IPTables规定，依据服务选择器将流量转发到适当的pod。
总之，IPTables是在Kubernetes中实现网络策略和服务的重要工具，容许对网络流量进行细粒度管制，并为负载平衡和服务发现提供牢靠且可扩大的机制。
IPVS
IPVS(IP Virtual Server)是提供网络负载平衡性能的Linux内核模块。在Kubernetes中，IPVS被用作kube-proxy和IPTables的替代品来实现服务。
当在Kubernetes中创立服务并且服务类型设置为"LoadBalancer"时，就会通过IPVS为服务创立虚构IP地址(VIP)。VIP用作客户端流量的指标地址，并与一组提供理论服务的pod相关联。
IPVS的工作原理是拦挡进入VIP的流量，并通过负载平衡算法将其调配到可用pod。在IPVS中有几种可用的负载平衡算法，包含轮询、最小连贯和加权最小连贯。
IPVS还提供健康检查，以确保流量只发送到衰弱的pod。当pod通过健康检查失败时，IPVS将其从可用pod列表中删除，并在残余的衰弱pod之间重新分配流量。
与kube-proxy和IPTables相比，IPVS有几个长处，包含更好的可伸缩性和性能，以及更灵便的负载平衡算法。IPVS能够解决大量连贯，并针对高吞吐量和低提早进行了优化，还反对更高级的负载平衡个性，例如会话长久化和连贯排放(connection draining)。
然而，与kube-proxy和IPTables相比，IPVS须要额定的配置，并且可能与网络环境有兼容性问题。IPVS须要内核的反对，并不是在所有Linux发行版上都可用。
Proxy
代理是一个服务端利用，充当申请资源的客户机和提供资源的服务器之间的中介。
Kubectl Proxy
Kubectl Proxy是一个命令行工具，容许用户在本地机器和Kubernetes API服务之间创立平安隧道，通过这种形式拜访Kubernetes API服务器，能够防止拜访网络以及简单的身份验证配置。Kubectl Proxy可用于各种场景，例如拜访Kubernetes Dashboard或对近程集群应用Kubectl命令。
例如，假如用户想要拜访运行在近程集群上的Kubernetes Dashboard，能够应用Kubectl Proxy创立平安隧道，通过本地web浏览器拜访Dashboard。
Kube-Proxy
Kube-Proxy是运行在Kubernetes集群中的每个节点上的组件，负责实现Kubernetes服务。Kube-Proxy侦听对Services的更改，更新本地IPTables或IPVS规定，确保将流量正确路由到集群中适当的pod。
例如，假如在Kubernetes中创立了一个服务，映射到一组标签为“app=myapp”的pod。Kube-Proxy将创立IPTables或IPVS规定，依据服务选择器将流量疏导到适当的pod。
Kubectl Proxy和Kube-Proxy有各自的长处和局限性。Kubectl Proxy设置简略，并提供对Kubernetes API服务的平安拜访，但可能很慢，不适宜生产环境。
Kube-Proxy是牢靠、可伸缩的，然而配置比较复杂，并且不适宜所有网络环境。
Envoy
除了Kube-Proxy，Kubernetes中另一个风行的代理是Envoy。Envoy是一种高性能代理，提供高级流量治理和负载平衡性能，能够作为Kube-Proxy的替代品来实现Kubernetes服务，也能够作为独立组件提供高级流量治理性能。
Envoy能够利用于许多生产环境，提供诸如高级负载平衡算法、断路、分布式跟踪等性能。
然而，与Kube-Proxy相比，Envoy须要额定的配置，并且可能与网络环境不兼容。此外，Envoy通常用于更简单的场景，例如多集群或多云环境，对于简略用例可能过于简单。
容器网络接口(Container Networking Interface)
容器网络接口(Container Networking Interface, CNI)是一组标准和工具，用于在容器化环境(如Kubernetes提供的环境)中配置网络。CNI的指标是为网络插件提供通用规范，以便容器运行时和编排零碎能够与任何反对CNI API的网络解决方案一起工作。
CNI为容器运行时(如Docker或CRI-O)定义了一种调用网络插件来配置容器网络接口的规范办法。插件负责为容器创立和配置网络接口、配置网络命名空间和路由表。
在Kubernetes中，kubelet应用CNI来配置pod的网络接口。创立pod时，kubelet调用CNI插件来配置pod的网络。而后，CNI插件为pod创立并配置网络接口，设置必要的路由规定，并将pod的IP地址增加到对应的网络命名空间中。
CNI插件既能够内置于容器运行时，也能够作为独立的二进制文件提供。有许多可用的CNI插件，每个插件都有本人的优缺点，风行的CNI插件包含Calico、Flannel和Weave Net。
在容器化环境中应用CNI有如下益处。首先，CNI提供了能够被多个容器运行时和编排零碎应用的通用规范，因而能够独立于容器运行时或编排零碎进行开发，从而进步灵活性和兼容性。
其次，CNI提供了模块化和可扩大的体系架构，容许与其余网络解决方案轻松集成，使用户可能为特定用例抉择最佳网络解决方案，并防止供应商锁定。
最初，CNI为配置容器网络提供了简略而灵便的API，开发人员能够轻松依据本人的需要创立和部署定制的网络解决方案。
你好，我是俞凡，在Motorola做过研发，当初在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓重的趣味，平时喜爱浏览、思考，置信继续学习、一生成长，欢送一起交流学习。微信公众号：DeepNoMind
本文由mdnice多平台公布