一、简介
对于许多软件应用程序，必须与外部服务通信才能完成它们的任务。 无论是发送消息还是使用 API，大多数应用程序都依赖其他系统才能正常运行。
然而，随着越来越多的用户将他们的应用程序迁移到 Kubernetes 中，为它们提供安全可靠的访问变得更具挑战性。 浏览各种部署和服务会使网络流量难以到达正确的位置。
幸运的是，有许多不同的机制可以帮助管理网络流量并确保请求到达集群内所需的目的地。 在本教程中，我们将研究其中两种机制：入口和负载均衡器。
2. 工作负载和服务
在我们讨论其中任何一个之前，我们必须先退后一步，看看应用程序是如何在 Kubernetes 中部署和管理的。
2.1。 工作负载和Pod
我们首先将我们的应用程序打包到 docker 镜像中。 然后使用这些 docker 映像创建预定义的工作负载类型之一，例如：
ReplicaSet：确保始终有最少数量的可用podsStatefulSet：在增加或减少数量时提供可预测且唯一的排序podsDameonSet：确保始终在某些或所有上运行特定数量的nodespods
所有这些任务负载都会创建一个或多个部署在集群中的pods 。 是我们可以在 Kubernetes 中使用的最小可部署单元。 它本质上表示在集群中某处运行的应用程序。pod
默认情况下，每个都有一个唯一的 IP，可供集群的其他成员访问。 但是，出于多种原因，使用其 IP 地址访问pod并不是一个好习惯。pod
首先，要提前知道会为分配什么 IP 并不容易。 这使得几乎不可能将 IP 信息存储在其他应用程序可以访问的配置中。 其次，许多工作负载会创建多个Pod——在某些情况下是动态的。 这意味着，在任何时候，我们都可能不知道给定应用程序正在运行多少个 pod。pod
最后， 是非永久性资源。 它们会随着时间的推移而开始和停止，每次发生这种情况时，它们很可能会获得一个新的 IP 地址。pods
由于所有这些原因，使用它们的 IP 地址与 pod 通信是一个坏主意。 相反，我们应该使用 。services
2.2.服务
Kubernetes service是一种将一组 pod 公开为网络服务的抽象。 该处理识别正在运行的 pod 及其 IP 地址的所有复杂性。 每个都有一个唯一的 URL，可以跨集群访问。 因此，Pod 无需使用 IP 进行通信，只需使用提供的服务 URL。serviceservice
让我们看一个示例服务定义：
apiVersion: v1 kind: Service metadata: name: api-service spec: selector: app: api-app ports: - protocol: TCP port: 80 targetPort: 8080
这将在集群中创建一个名为 此绑定到任何运行应用程序的 pod，无论这些存在多少或它们在哪里运行。 而且，随着这种类型的新启动， 会自动发现它们。api-serviceserviceserviceapi-apppodspodsservice
使用service是将 pod 与使用它们的应用程序分离的良好开端。 但是，就其本身而言，它们并不总能达到我们期望的目标。 这就是入口和负载均衡器的用武之地。
3.入口
默认情况下，Kubernetes 是集群私有的。 这意味着只有集群内的应用程序才能访问它们。 有很多方法可以解决这个问题，最好的方法之一是 。serviceingress
在 Kubernetes 中， ingress 允许我们将来自集群外部的流量路由到集群内部的一个或多个services 。 通常，入口作为所有传入流量的单一入口点。
一个入口接收一个公共IP，这意味着它可以在集群外部访问。 然后，使用一组规则，它将所有流量转发到适当的 。 反过来，该会将请求发送到可以实际处理请求的 。serviceservicepod
创建首先，它们旨在处理网络流量（http 或 HTTPS） 。 虽然可以将与其他类型的协议一起使用，但它通常需要额外的配置。ingress.ingress
其次， 可以做的不仅仅是路由。 其他一些用例包括负载平衡和 SSL 终止。ingress
最重要的是， ingress对象本身实际上并没有做任何事情。 所以，为了让真正做任何事情，我们需要有一个可用。ingressingress controller
3.1。 入口控制器
与大多数 Kubernetes 对象一样， 需要关联的控制器来管理它。 然而，虽然 Kubernetes 为大多数对象（如和 ）提供** ，但默认情况下它不包括控制器**。 因此，由集群管理员来确保适当的控制器可用。ingressdeploymentsservicescontrolleringress
大多数云平台都提供自己的 ，但也有很多开源选项可供选择。 也许最流行的是nginx 入口控制器，它建立在流行的同名 Web 服务器之上。ingress controllers
让我们看看使用 nginx 的示例配置：ingress controller
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ingress-example annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: ingressClassName: nginx-example rules: - http: paths: - path: /api pathType: Prefix backend: service: name: api-service port: number: 80
在此示例中，我们创建了一个，它将任何以开头的请求路由到名为的 Kubernetes 。ingress/apiapi-serviceservice
请注意， 字段包含特定于 nginx 的值。 因为所有都使用相同的 API 对象，所以我们通常使用 annotations 字段将特定配置传递给 。annotationsingress controllersingress controller
Kubernetes 生态系统中有几十个可用的ingress controllers ，涵盖所有这些控制器远远超出了本文的范围。 但是，因为它们使用相同的 API 对象，所以它们有一些共同的特点：
入口规则：定义如何将流量路由到特定服务的一组规则（通常基于 URL 或主机名）
默认后端：处理不匹配任何规则的流量的默认资源
TLS：定义私钥和证书以允许 TLS 终止的秘密
不同的入口控制器建立在这些概念之上，并添加了自己的功能和特性。
4.负载均衡器
Kubernetes 中的负载均衡器与有相当多的重叠。 这是因为它们主要用于向互联网公开 ，正如我们在上面看到的，这也是的一个特性。ingressesservicesingresses
但是，负载均衡器具有与ingresses不同的特性。 负载均衡器不是像这样的独立对象，而是的扩展。ingressservice
让我们看一个带有负载均衡器的服务的简单示例：
apiVersion: v1 kind: Service metadata: name: api-service spec: selector: app: api-app ports: - protocol: TCP port: 80 targetPort: 8080 type: LoadBalancer
就像我们之前的服务示例一样，在这里，我们正在创建一个，将流量路由到运行我们的 API 应用程序的任何 。 在本例中，我们包含了一个配置。servicepodLoadBalancer
为此，集群必须在支持外部负载均衡器的提供程序上运行。 所有主要的云提供商都支持使用自己的资源类型的外部负载均衡器：
AWS 使用网络负载均衡器
GKE 还使用网络负载均衡器
Azure 使用公共负载均衡器
就像我们看到不同的一样，不同的负载均衡器提供商有自己的设置。 通常，我们使用CLI或特定于基础架构的工具直接管理这些设置，而不是使用YAML。 不同的负载均衡器实现还将提供额外的功能，例如 SSL 终止。ingress controllers
因为负载平衡器是按定义的，所以它们只能路由到单个service 。 这与不同，它能够路由到集群内的多个 。serviceingressservices
此外，请记住，无论供应商如何，使用外部负载平衡器通常都会带来额外费用。 这是因为，与入口及其控制器不同，外部负载均衡器存在于 Kubernetes 集群之外正因为如此，大多数云提供商将对集群本身之外的额外资源使用收费。ingresses
5.结论
在本文中，我们研究了的一些核心概念，包括 、 和入口。 这些对象中的每一个都在各种ingressesdeploymentsservicespods.
虽然和负载均衡器在功能上有很多重叠，但它们的行为不同。 主要区别在于ingresses是集群内的本机对象，可以路由到多个services ，而负载均衡器位于集群外部，只能路由到单个service.ingresses
0 评论