kubernetes - k8 内部的流量如何流动？

Question

我有 LB 的入口和服务。当来自外部的流量首先到达入口，然后使用入口 LB 直接进入 Pod，或者它进入服务并通过选择器获取 Pod ip，然后进入 Pod？如果是第一种方式，服务有什么用？以及哪种服务或入口在部署中使用了 readinessProbe？

所有设置都在 GCP 中

我是 K8 网络的新手。

Answer 1

一种服务类型LoadBalancer是您的云提供的外部源，不在 Kubernetes 集群中。他们可以使用节点选择器将请求转发到您的 pod，但您不能例如制定路径规则或重定向、重写，因为这是由 Ingress 提供的。

Service is an abstraction which defines a logical set of Pods and a policy by which to access them (sometimes this pattern is called a micro-service). The set of Pods targeted by a Service is usually determined by a selector (see below for why you might want a Service without a selector).

        Internet
            |
     [ LoadBalancer ]
       --|-----|--
       [ Services ]
       --|      |--
    [ Pod1 ]  [ Pod2 ]

当您使用 入口 , 是一个由入口 Controller 组成的组件 Controller ，它基本上是一个配置为处理您定义的规则的 pod。
要使用 ingress，您需要为您的路径配置一个服务，然后该服务将通过配置选择器到达 pod。您可以根据路径、主机名配置一些规则，并将它们重定向到您想要的服务。像这样:

        Internet
            |
       [ Ingress ]
       --|-----|--
       [ Services ]
       --|      |--
    [ Pod1 ]  [ Pod2 ]

Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the Ingress resource.

This article在所有公开服务的方式之间都有很好的解释。

readnessProbe在您的 pod/部署规范中配置， kubelet 负责评估您的容器是否健康。

The kubelet uses readiness probes to know when a Container is ready to start accepting traffic. A Pod is considered ready when all of its Containers are ready. One use of this signal is to control which Pods are used as backends for Services. When a Pod is not ready, it is removed from Service load balancers.

kube-proxy负责转发对 pod 的请求。

例如，如果您在不同的节点中有 2 个 pod，kube-proxy 将处理防火墙规则(iptables)并在您的节点之间分配流量。集群中的每个节点都有一个运行的 kube-proxy。

kube-proxy 可以通过 3 种方式配置:userspace mode , iptables mode和 ipvs mode .

If kube-proxy is running in iptables mode and the first Pod that’s selected does not respond, the connection fails. This is different from userspace mode: in that scenario, kube-proxy would detect that the connection to the first Pod had failed and would automatically retry with a different backend Pod.

引用文献:

https://kubernetes.io/docs/concepts/services-networking/service/

https://kubernetes.io/docs/concepts/services-networking/ingress/