clusterip,K8s的网络详解

clusterip,K8s的网络详解详细介绍

本文目录一览：

• 1、
• 2、

K8s的网络详解

深入探索K8s的奥秘，了解其网络运行机制和基本结构显得尤为重要。面对实际的问题时，对于K8s的初步了解可能会让你感到捉襟见肘。那么，我们首先需要明确K8s的核心职责是什么？其实，它的主要作用在于对容器进行编排和管理。其中，Pod是K8s的基础单元而非容器本身。无论是物理机还是虚拟机，它们在K8s中被称作Node。一个Pod内可以包含多个容器，或者只有一个容器。特别的是，同一个Pod中的容器是共享网络和主机配置的，它们之间的通信就像在同一台机器上一样简单直接，可以通过localhost进行通信。在这样的环境下，我们通常不需要过多考虑隔离和安全问题，因为它们被视为一个整体业务环境。

那么，让我们来解答第一个问题：同一个Pod的不同容器能否位于不同的Node上？答案是否定的。因为它们需要共享主机和网络。至于如何知道一个Pod中有多个容器，以及在使用kubectl exec时是否可以指定要运行的容器，答案是完全可以的。具体操作可以参考相关指令。

在K8s的世界里，我们可以简化对容器的思考，更多地关注Pod。因为Pod是K8s最小的调度单元。那么，Pod与Pod之间是如何通信的呢？这离不开K8s的网络模型——flannel。Flannel构建了一个大二层的扁平网络，为Pod分配IP地址，并通过其网桥实现Pod间的通信。每个Node上都会创建一个flannel0虚拟网卡，以实现跨Node之间的通信。因此，容器可以直接使用podid进行通信。

当涉及到跨节点通信时，发送端的数据将从docker0路由到flannel0虚拟网卡，而接收端的数据则会从flannel0路由回到docker0。这时，也许你会问：如果Pod是一组应用容器的集合，那么Service的存在意义又是什么呢？Service是一个抽象的概念，它在应用服务需要进行负载、全生命周期跟踪和管理时显得尤为重要。Service定义了Pod逻辑集合以及访问这些Pod的策略。

让我们通过一个常见的场景来进一步理解Service的运行原理。当一个Pod因某种原因停止运行时，Kubelet会根据deployment的需求启动一个新的Pod来接替之前的功能。但要注意的是，Flannel会为这个新的Pod分配一个新的IP，这可能会带来一定的挑战。然而，如果有了Service的存在，这个问题就迎刃而解了。Service的运行机制是如何工作的呢？当创建一个ServiceA时，ServiceController和EndPointsController会协同工作，更新相关资源。基于Service中配置的Pod选择器，为每个Pod创建一个EndPoint资源并存入etcd。同时，kube-proxy还会更新iptables的chain规则，生成基于Service的ClusterIP到对应Pod的链路规则。这样，集群内的任何Pod想要访问某个服务时，只需使用clusterip:port即可，基于iptables的链路将请求发送到对应的Pod。这一层有两种挑选Pod的算法：轮询(RoundRobin)和亲和度匹配(SessionAffinity)。

除了iptables模式外，还有一种用户态的转发方式。Kube-Proxy会为每个Service随机监听一个端口(ProxyPort)，并增加一条IPtables规则。所有发往ClusterIP:Port的报文都会被重定向到ProxyPort。Kube-Proxy收到报文后，会通过RoundRobin或SessionAffinity将请求分发给对应的Pod。值得一提的是，新版本的k8s已经开始使用ipvs来替代iptables作为其负载均衡解决方案。IPVS是LVS项目的一部分，是一款运行在LinuxKernel中的4层负载均衡器，性能卓越。经过调优的内核可以轻松处理每秒十万次以上的转发请求。在中大型互联网项目中，IPVS被广泛用于承接网站入口处的流量。

k8s 服务发现原理整理

《Kubernetes服务注册与发现机制详解》

在Kubernetes的运作中，服务注册与发现机制扮演着至关重要的角色。这一过程主要源自权威资料《The Kubernetes Book》。

服务注册的过程大致如下：当服务配置文件被上传至API服务器后，相应的服务对象随即生成，同时自动生成endpoints对象，进行网络配置及服务注册。Kubernetes会为每个服务自动创建一个Endpoints对象（或Endpointslices）。这些对象内含与标签选择器相匹配的Pod列表，并负责接收来自服务的流量。

在Kubernetes的架构中，有几个关键点值得注意：

1. **内部DNS服务**：Kubernetes使用内部DNS服务作为其服务注册表。这一服务注册机制主要通过DNS实现，而非针对单个Pod。

2. **服务名称与信息**：每个服务的名称、IP地址及网络端口都会被注册。这一切的信息管理都依赖于一个众所周知的内部DNS服务，我们通常称之为“集群DNS”。

3. **集群DNS的运行**：集群DNS在集群中每个Pod和容器的已知地址上运行，作为kube-system命名空间中的一个Pod集群进行管理，该Pod集群由名为coredns的部署进行管理。此技术基于CoreDNS的DNS技术，作为Kubernetes的原生应用程序运行。

DNS通过controller监控Service对象的变化，并在内部修改服务名称和IP。每当观察到新的Service对象时，集群DNS都会创建相应的DNS记录，使得服务名称能够被解析为其ClusterIP。这意味着应用程序和服务无需进行手动注册——集群DNS会不断发现新的服务并自动注册其详细信息。

重要的是要理解，注册的服务名称实际上存储在其元数据中的.name属性里。ClusterIP则由Kubernetes动态分配。

关于服务发现，Kubernetes集群内的每个容器都被自动配置，使其能够利用集群DNS将服务名称转换为IP地址。这一过程通过填充每个容器的/etc/resolv.conf文件完成，其中包含了集群DNS服务的IP地址以及任何相关的搜索域。

当Pod需要发送流量到服务的ClusterIP时，由于该地址位于特殊的服务网络上，并没有路由可达。因此，流量会被发送到容器的默认网关，然后到达运行的节点。节点同样没有服务网络的路由，所以流量会被发送到自己的默认网关。在这一系列的操作中，每个Kubernetes节点上的kube-proxy进程扮演了关键角色。

kube-proxy是一个Pod基础的Kubernetes原生应用，它实现了对API服务器上新服务和Endpoints对象的监控。当它检测到这些对象时，它会创建本地的IPVS规则，指导节点拦截目标为服务ClusterIP的流量，并将其重定向到匹配服务标签选择器的健康Pod的IP地址。这一系列的操作确保了流量能够被准确地发送到正确的Pod。

总结起来，新的服务对象会自动注册到集群DNS，而所有的容器都被配置为知道如何与集群DNS进行交互。当容器需要将服务名称解析为IP地址时，它会与集群DNS进行交流。集群DNS将服务名称解析为ClusterIP，而这个IP地址虽在特殊的服务网络上但因kube-proxy的存在而被准确无误地转发至正确的Pod进行处理。