共计 6528 个字符，预计需要花费 17 分钟才能阅读完成。
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 多平台公布