关于云计算:Kubernetes-中数据包的生命周期-第-4-部分

3次阅读

共计 5811 个字符，预计需要花费 15 分钟才能阅读完成。

本文翻译自：[Life of a Packet in Kubernetes — Part 4 [1]](https://dramasamy.medium.com/…)
作者：Dinesh Kumar Ramasamy
本文在原文的根底上做了适当的批改，如有疑问请查阅原文。

本文是 Kubernetes 中数据包的生命周期系列文章的第 4 局部，咱们将会介绍 Kubernetes 中的 Ingress 资源对象和 Ingress Controller。Ingress Controller 是一个控制器，它监督 Kubernetes API Server 对 Ingress 资源的变更并相应地更新负载均衡器的配置。

## 1 Nginx Controller 和 LoadBalancer/Proxy

Ingress Controller 通常是以 Pod 的模式运行在 Kubernetes 集群中，它依据 Ingress 资源配置负载均衡器。负载均衡器能够是运行在集群中的软件负载均衡器，也能够是在内部运行的硬件或云负载均衡器。不同的负载均衡器须要应用不同的 Ingress Controller。

Ingress 实质上是 Kubernetes 对反向代理的一个高级形象，形容了一系列流量治理的办法，特地是针对 HTTP(S)。通过 Ingress，咱们能够定义路由转发的规定，而无需创立一堆负载均衡器或在每个节点上裸露服务。能够为服务提供内部可拜访的 URLs，流量的负载平衡，SSL/TLS 终结，并提供基于名称的虚拟主机和基于内容的路由。

## 2 配置选项
在 Kubernetes 中应用 Ingress Class 标记 Ingress 资源对象所属的 Ingress Controller。这容许多个 Ingress Controller 在同一个 Kubernetes 集群中共存，每个 Ingress Controller 只会解决属于它的配置。

基于前缀的路由

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: prefix-based
 annotations:
   kubernetes.io/ingress.class: "nginx-ingress-inst-1" # 标记所属的 Ingress Controller
spec:
 rules:
 - http:
     paths:
     - path: /video
       pathType: Prefix
       backend:
         service:
           name: video
           port:
             number: 80
     - path: /store
       pathType: Prefix
       backend:
         service:
           name: store
           port:
             number: 80

在 Kubernetes 1.18 版本引入 IngressClass 资源和 ingressClassName 字段之前，Ingress Class 是通过 Ingress 中的一个 kubernetes.io/ingress.class 注解来指定的。这个注解从未被正式定义过，然而失去了 Ingress Controller 的广泛支持。

Ingress 中新的 ingressClassName 字段是该注解的替代品，但并非齐全等价。该注解通常用于援用实现该 Ingress 的控制器的名称，而这个新的字段则是对一个蕴含额定 Ingress 配置的 IngressClass 资源的援用，包含 Ingress Controller 的名称。

# IngressClass 资源
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
labels:
  app.kubernetes.io/component: controller
name: nginx-ingress-inst-1 # IngressClass 名字
annotations:
  ingressclass.kubernetes.io/is-default-class: "true" # 设置为默认的 IngressClass，当 Ingress 中没有设置 ingressClassName 字段或者 kubernetes.io/ingress.class 注解时将会应用这个 IngressClass
spec:
controller: k8s.io/ingress-nginx
---
# 在 Ingress 中指定 ingressClassName
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: prefix-based
spec:
ingressClassName: "nginx-ingress-inst-1" # 标记所属的 Ingress，援用 IngressClass 资源
rules:
- http:
    paths:
    - path: /video
      pathType: Prefix
      backend:
        service:
          name: video
          port:
            number: 80
    - path: /store
      pathType: Prefix
      backend:
        service:
          name: store
          port:
            number: 80

基于主机的路由

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: host-based
 annotations:
   kubernetes.io/ingress.class: "nginx-ingress-inst-1"
spec:
 rules:
 - host: "video.example.com" # 域名
   http:
     paths:
     - pathType: Prefix
       path: "/"
       backend:
         service:
           name: video
           port:
             number: 80
 - host: "store.example.com"
   http:
     paths:
     - pathType: Prefix
       path: "/"
       backend:
         service:
           name: store
           port:
             number: 80

基于主机 + 前缀的路由

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 name: host-prefix-based
 annotations:
   kubernetes.io/ingress.class: "nginx-ingress-inst-1"
spec:
 rules:
 - host: foo.com
   http:
     paths:
     - backend:
         serviceName: foovideo
         servicePort: 80
       path: /video
     - backend:
         serviceName: foostore
         servicePort: 80
       path: /store
 - host: bar.com
   http:
     paths:
     - backend:
         serviceName: barvideo
         servicePort: 80
       path: /video
     - backend:
         serviceName: barstore
         servicePort: 80
       path: /store

Ingres 是 Kubernetes 的内置对象，为了让 Ingress 资源工作，集群中必须有一个正在运行的 Ingress Controller。Ingress Controller 须要实现 Ingress API 的相干接口。社区中有很多 Ingress Controller 的实现，本文将会介绍 Nginx 和 Contour。

前文提到，Kubernetes Ingress 是一个 API 对象，它形容了如何对外公布部署在 Kubernetes 集群中的服务。因而，要使 Ingress Controller 可能工作，你须要实现 Ingress API 来读取和解决 Ingress 资源的信息。

Ingress API 对象只是元数据信息，真正的工作是由 Ingress Controller 来实现的。有许多 [Ingress Controller [2]](https://kubernetes.io/docs/co…) 可供使用，重要是依据具体场景抉择适合的 Ingress Controller。

也能够在同一个集群中部署多个 Ingress Controller，并为每个 Ingress 设置所属的 Ingress Controller。通常，咱们会针对同一集群中的不同场景组合应用这些控制器。例如，咱们可能有一个控制器用于解决进入集群的内部流量，其中包含与 SSL 证书的绑定，而另一个没有 SSL 绑定的控制器用于解决集群内的流量。

## 3 部署选项
### 3.1 Contour + Envoy

Contour Ingress Controller 蕴含以下两局部：

Envoy（数据立体），提供高性能反向代理。
Contour（管制立体），读取 Ingress 资源信息并对 Envoy 进行配置。

Contour 和 Envoy 容器是离开部署的，Contour 以 Deployment 的形式运行，Envoy 以 Daemonset 的形式运行，当然其余形式部署也是能够的。Contour 是调用 Kubernetes API 的客户端。Contour 监督 Ingress，HTTPProxy, Secret, Service 和 Endpoint 对象，并转换为 Envoy 的相干配置：例如，Service 对应 CDS，Ingress 对应 RDS，Endpoint 对应 EDS 等等。

下图显示了启用主机网络（hostNetwork: true）的 EnvoyProxy (0.0.0.0:80)。

Nginx Ingress Controller 的指标是组装一个配置文件（nginx.conf）。当配置文件产生任何更改时须要从新加载 Nginx。须要留神的是，如果只有 upstream（应用程序的 Endpoint）变动的话，此时无需从新加载 Nginx。咱们能够应用 [lua-nginx-module [3]](https://github.com/openresty/…) 来实现这一点。

每当 Endpoint 更改时，控制器都会从 Service 中获取 Endpoint 并生成相应的后端对象。而后将这些对象发送到在 Nginx 中运行的 Lua 处理程序。Lua 代码将这些后端对象存储在共享内存区域中。对于在 [balancer_by_lua [4]](https://github.com/openresty/…) 上下文中的申请，Lua 代码会检测到有哪些上游 Enpdoint，并利用配置的负载平衡算法来抉择 Endpoint。其余的工作由 Nginx 负责。这样咱们能够防止在 Endpoint 更改时从新加载 Nginx。在频繁部署应用程序的绝对较大的集群中，此性能能够节俭 Nginx 大量的从新加载，从而防止影响响应提早、负载平衡品质（每次从新加载后 Nginx 都会重置负载平衡状态）等问题。

[keepalived [5]](https://keepalived.readthedoc…) 守护过程可用于监控服务或零碎，并在呈现问题时主动实现故障转移。咱们配置一个能够在工作节点之间漂移的[浮动 IP [6]](https://www.digitalocean.com/…)。当工作节点宕机时，浮动 IP 会主动漂移到另一个工作节点上，新的工作节点接管拜访流量。

MetalLB 是裸机 Kubernetes 集群中负载均衡器的实现。简略来说，它容许你在非云提供商提供的 Kubernetes 集群中创立类型为 LoadBalancer 的 Kubernetes Service。在云提供商提供的 Kubernetes 集群中，由云提供商负责调配 LoadBalancer Service 的 IP 地址，并在云提供商的负载平衡设施上公布服务（例如 AWS 的 ELB，阿里云的 SLB 等）。在裸机 Kubernetes 集群中，MetalLB 负责调配 IP 地址。一旦 MetalLB 为服务调配了内部 IP 地址，它须要让集群内部的网络晓得这个 IP“存在“于集群中。MetalLB 应用规范的路由协定实现这一点：ARP，NDP 或者 BGP。

在 Layer 2 模式下，集群中的一台机器取得 IP 地址的所有权并应用规范地址发现协定（IPv4 应用 [ARP [7]](https://en.wikipedia.org/wiki…)，IPv6 应用 [NDP [8]](https://en.wikipedia.org/wiki…)）。在 Layer 2 模式下，所有 LoadBalancer 类型的 Service 的 IP 同一时间都是绑定在同一台节点的网卡上，存在单点网络瓶颈。

在 BGP 模式下，集群中的所有机器都与内部路由器建设 [BGP [9]](https://en.wikipedia.org/wiki…) 街坊关系，并通知路由器如何将流量转发到 Service IP。基于 BGP 的策略机制，应用 BGP 能够实现跨多个节点真正的负载平衡，以及细粒度的流量管制。

MetalLB 运行时有两种工作负载：