Kubernetes HTTP 请求之旅

Kubernetes 服务创建期间会发生什么？

为了使我们的部署可以通过 Internet 访问，我们通过使用以下配置在 K8s 中创建负载均衡器类型的服务资源来公开我们的应用程序。

kind: Service
 apiVersion: v1
 metadata:
  name:  nginx
 spec:
  selector:
    app:  nginx
  type:  LoadBalancer
  ports:
  - name:  http
    port:  8080
    targetPort:  80

运行kubectl apply -f service.yaml以创建服务类型负载均衡器。

 

任何创建的 K8s 资源都会通过api-server组件持久化在 ETCD 存储中。该api-server组件通知负责处理服务资源的其他系统组件。

收到通知的其他系统组件是：

• Kube 控制器管理器
• 云控制器管理器
• Kube 代理

上述组件决定了我们的 HTTP 请求的命运。为了简化我们的技术旅程，让我们分阶段逐步结束我们的旅程。我在下图中表示了我们的 HTTP 请求的过程；我们有来源、目的地和中途停留地。

服务类型负载均衡器有什么作用？

1. 当我们在云中运行的任何 Kubernetes 集群上创建服务型负载均衡器时，负载均衡器由云提供商提供。如 所代表stop-over-1。

   众所周知，在创建负载均衡器时，云提供商也会提供一个域名。该域可用于访问我们的应用程序。

2. 在 K8s 中，Load Balancer 服务类型是 NodePort 和 ClusterIP 服务的超集；这意味着负载均衡器服务同时包含 NodePort 和 ClusterIP 服务的功能。

   该服务的特点是什么，您可能会问：

   • Node Port服务在worker节点上开放一些端口，供外部流量进入集群，stop-over-2如上图所示。
   • ClusterIP服务提供了一个静态IP地址，可以在K8s内部进行通信，stop-over-3如上图所示。

Stop-Over-2 和 Stop-Over-3 的创建

当 kube controller manager我们收到关于服务资源的通知时，正如我们从上一篇文章中知道的那样，KCM 包含许多控制器，其中一个控制器是服务控制器，它对服务资源采取适当的行动。

下面是服务控制器对服务类型负载均衡器所做的事情：

1. 首先，它获取与服务资源中指定的选择器字段匹配的 pod 列表（例如 where app: nginx）；之后，它会遍历 pod 列表并记下 pod 的 IP 地址。

2. 然后它会创建一个内部静态 IP 地址，称为clusterIP.

3. 现在它创建了一个名为Endpoint的新 K8s 资源，它基本上将单个 IP 映射到多个 IP。这里的单个IP就是clusterIP，多个IP对应pod的IP。

   每当在 K8s 中创建/销毁 Pod 时，服务控制器都有责任更新端点资源中相应的 Pod IP 地址。以便集群 IP 始终解析为最新的 Pod IP 地址。

4. 最后，它在工作节点上公开一个随机端口（范围从 30000-32768）。

而已; 这就是服务控制器对负载平衡器服务类型所做的事情。

Stop-Over-1 的创建

现在的问题是，谁在云上配置负载均衡器？创建服务型负载均衡器时。确实，它不是服务控制器。

想一想，要提供负载均衡器，您需要与云提供商的 API 进行交互，并且没有 Kubernetes 组件直接与云提供商对话，对吧？

这就是cloud controller manager图片的来源。CCM 是 K8s 架构中的可插拔组件，用于与云提供商进行深度集成。

关于 CCM 需要注意的一点是，每个云提供商都有自己的 CCM 实现，因此当您在云上配置托管 K8s 时。提供者运行自己的 CCM 实现。

通知 CCM 负载均衡器api-server服务，然后 CCM 开始行动并开始使用云提供商 API 配置负载均衡器。

KCM和CCM之间的区别

在我们之前的文章中，我们了解到 KCM 也适用于 CCM；围绕控制循环的操作原则适用，领导选举功能也适用。

CCM 也是控制回路的集合；区别只是控制器地址的关注点。

KCM 包含与核心 K8s 功能相关的控制循环。

不会在每个集群中都找到 CCM；这些控制器关注与云提供商的集成；您可能没有在本地集群中运行此组件；CCM 关注于协调现有状态与云提供商基础设施以实现所需状态，它们与云提供商 API 集成并经常解决供应商特定的问题，

例如配置负载均衡器、持久存储、虚拟机等。