ACK容器的应用交付网络设计

简介

本文致力于为Kubernetes（简称k8s）集群提供一份详尽的网络入口设计指南，特别关注Service与Ingress这两大核心组件的设计策略。在网络配置中，确保Kubernetes集群内服务间及外部对服务访问的高效性和安全性至关重要。正确理解和实施Service与Ingress的设计原则，不仅能显著提高应用的可访问性，还能大幅增强系统的整体性能和稳定性。

基本概念

Kubernetes：Kubernetes 是一个开源容器编排引擎，用于自动化容器化应用程序的部署、扩展和管理。该开源项目由云原生计算基金会（ CNCF ）托管。

ACK：阿里云容器服务 Kubernetes 版 ACK（Container Service for Kubernetes）是全球首批通过Kubernetes一致性认证的容器服务平台，提供高性能的容器应用管理服务，支持企业级Kubernetes容器化应用的生命周期管理，让您轻松高效地在云端运行Kubernetes容器化应用。

Service：Kubernetes 中 Service 是将运行在一个或一组 Pod 上的网络应用程序公开为网络服务的方法。Service 通过标签选择器识别一组目标 Pod，并根据 Service 的类型（如 ClusterIP、NodePort、LoadBalancer 或 ExternalName）来管理这些 Pod 之间的流量分配，有效解决了直接访问 Pod 存在的问题，保证了应用的高可用性和运行效率。Service 的默认协议是 TCP ，你还可以使用其他受支持的任何协议。Service主要负责处理东西向流量。

Ingress：使用一种能感知协议配置的机制来解析 URI、主机名称、路径等 Web 概念， 让你的 HTTP（或 HTTPS）网络服务可被访问。 Ingress 概念允许你通过 Kubernetes API 定义的规则将流量映射到不同后端。Ingress 可以提供负载均衡、SSL 终结以及基于名称的虚拟托管功能。Ingress 控制器 负责完成 Ingress 的工作，具体实现上通常会使用某个负载均衡器， 不过也可以配置边缘路由器或其他前端来帮助处理流量。Ingress主要负责处理南北向流量。

容器网络插件：容器网络插件（CNI Plugins）负责容器网络的具体实现。容器网络插件决定了Pod IP地址分配的机制、是否使用Overlay网络、集群内流量的转发链路、对Pod的访问控制机制等容器网络特性。目前已经有很多知名的开源容器网络插件，如Calico、Flannel、Cilium等。容器服务 Kubernetes 版支持两种容器网络插件：Terway与Flannel。这两种插件拥有不同的特性，请参照下方的介绍以及Terway与Flannel的对比，在创建集群前完成容器网络插件的选型。

Terway：Terway网络插件是阿里云自研的容器网络插件。在容器服务 Kubernetes 版中作为节点的ECS实例使用ENI（弹性网卡）进行网络通信，Terway将节点的ENI分配给Pod，为Pod提供了网络互联能力。因此，在使用Terway时，Pod直接接入VPC网络。由于不需要使用VXLAN等隧道技术封装报文，Terway模式网络具有较高的通信性能。Terway适用于大规模集群、对网络性能和访问控制能力有较高需求的场景。

Flannel：Flannel是一个经典的开源容器网络插件，它使用VXLAN等虚拟化网络技术为Pod构建了一个Overlay网络。Flannel的配置简单、易于使用，但是网络性能会受到NAT损失的影响，访问控制能力相较于Terway也更弱，并且集群的节点数量上限较低。Flannel适用于节点数量不超过1000的小规模集群，以及对网络性能和访问控制能力需求较低，希望快速搭建、使用集群的场景。

NLB：网络型负载均衡NLB（Network Load Balancer ）是阿里云面向万物互联时代推出的新一代四层负载均衡，支持超高性能和自动弹性能力，单实例可以达到1亿并发连接，帮您轻松应对高并发业务。

ALB：应用型负载均衡ALB（Application Load Balancer）是阿里云推出的专门面向HTTP、HTTPS和QUIC等应用层负载场景的负载均衡服务，具备超强弹性及大规模应用层流量处理能力。ALB具备处理复杂业务路由的能力，与云原生相关服务深度集成，是阿里云官方提供的云原生Ingress网关。

EIP：弹性公网 IP EIP（Elastic IP Address）是可以独立购买和持有的公网IP地址资源。目前，EIP支持绑定到专有网络类型的云服务器 ECS（Elastic Compute Service）实例、辅助弹性网卡、负载均衡 SLB（Server Load Balancer）实例、NAT 网关（NAT Gateway）和高可用虚拟IP上。

高可靠性

• 跨区域/多可用区部署：

  • Service: 实现跨多个可用区（AZs）的部署，确保单个AZ故障不会影响服务的整体可用性。

  • Ingress: 配置 Ingress 控制器以支持多区域或多可用区部署，确保即使某个区域或可用区发生故障，也能维持服务的连续性和高可用性。

• 健康检查与故障转移：

  • Service: 使用 Kubernetes 的内置健康检查机制来监控 Pod 的状态，自动移除不健康的实例。

  • Ingress: 利用 Ingress 控制器的健康检查特性，定期检查后端服务的健康状况，并在检测到故障时自动将流量重定向到其他健康节点。

扩展性

• 细粒度水平扩展策略：

  • Service: 支持基于可用区的细粒度水平扩展策略。

  • Ingress: 设计支持复杂路由规则的 Ingress，包括路径匹配、主机名匹配等，以便根据不同的业务需求灵活分配流量。

性能与弹性

• 动态流量管理与自动伸缩：

  • Service & Ingress: 集成智能流量管理策略，如会话保持、加权轮询等，优化用户体验并提升系统整体性能。同时，为 Ingress 控制器和服务配置自动伸缩策略，确保在不同时间段内能够高效处理变化的流量压力。

• 保障高峰时段性能：

  • Service & Ingress: 集成自动伸缩功能，依据实时流量数据动态调整负载能力，保证在高峰时段的服务性能不受影响，同时在低峰期节省成本。

可观测

• 性能指标收集与展示：

  • Service & Ingress: 进行性能指标的收集与展示，提供全面的服务运行状态视图。

• 异常检测与告警：

  • Service & Ingress: 自动化异常检测和告警系统，快速响应潜在问题，减少故障恢复时间。

自服务能力

• 原生兼容与自动化部署：

  • Service & Ingress: 原生兼容 Kubernetes YAML 文件定义和管理服务及 Ingress。支持通过 Terraform、ROS 等基础设施即代码（IaC）工具进行自动化部署，提高运维效率。

安全性

• 网络通信限制与加密：

  • Service & Ingress: 支持网络安全组，限制不必要的网络通信，增强服务安全。默认启用 TLS 终止，保护数据传输的安全性，防止中间人攻击。

高可靠性

• 跨区域/多可用区部署：

  • Service: NLB采用多层次容灾架构设计，通过集群容灾、会话保持、可用区多活等机制保障实例的可用性。

  • Ingress: ALB单实例至少两可用区部署，各可用区之间可以实现故障隔离，即如果一个可用区出现故障，不会影响其他可用区的正常运行。

• 健康检查与故障转移：

  • Service: 网络型负载均衡NLB通过健康检查来判断后端服务器业务的可用性。开启健康检查功能后，当某台后端服务器健康检查出现异常时，负载均衡会自动将新的请求分发到其他健康检查正常的后端服务器上。当该后端服务器恢复正常运行时，负载均衡会自动将其重新纳入服务并进行流量转发。健康检查机制是保证业务高可用的关键要素之一。它提高了用户业务的整体可用性，避免了局部后端服务器异常对整体服务造成的影响。

  • Ingress: 为确保ALB后端服务器的业务可用性，您可以通过为ALB服务器组配置健康检查来检查服务器组的运行状况，以避免后端服务器异常对业务的影响，并提升业务可靠性。在开启健康检查时，默认情况下，ALB会自动将客户端请求路由至健康检查状态正常的服务器，并将持续对该服务器组的所有后端服务器的运行状况进行监控。服务器必须通过连续n次的健康检查才会被视为正常（n为配置的健康检查健康阈值，多次健康检查是为了避免网络抖动的影响）。

扩展性

• 细粒度水平扩展策略：

  • Service&Ingress: NLB、ALB支持通过手动横向扩展可用区，用户可以将流量分发到不同地理位置的多个可用区，从而提高系统的可靠性和性能。

性能与弹性

• 动态流量管理与自动伸缩：

  • Service & Ingress: NLB、ALB提供域名与VIP，多级分发承载海量请求。支持通过流量分发扩展应用系统的服务能力，消除单点故障提升应用系统的可用性。允许自定义可用区组合和在可用区间弹性伸缩，避免单可用区资源瓶颈。

可观测

• 性能指标收集与展示：

  • Service & Ingress: 您可以利用云监控功能查看ALB、NLB资源的运行状态和各个指标的使用情况，方便快速定位问题。您可以通过控制台、API、SDK方式来查看ALB、NLB的监控信息。同时，ALB、NLB支持对接Prometheus监控。

• 异常检测与告警：

  • Service & Ingress: 开通云监控服务后，您可以通过云监控控制台、API和SDK为应用型负载均衡ALB、NLB实例配置监控报警规则。

自服务能力

• 原生兼容与自动化部署：

  • Service：支持通过 Terraform、ROS 等基础设施即代码（IaC）工具进行自动化部署NLB，通过Annotation配置网络型负载均衡NLB作为service。

    apiVersion: v1
    kind: Service
    metadata:
      annotations:
        service.beta.kubernetes.io/alibaba-cloud-loadbalancer-zone-maps: "${zone-A}:${vsw-A},${zone-B}:${vsw-B}" # 例如cn-hangzhou-k:vsw-i123456,cn-hangzhou-j:vsw-j654321。
      name: nginx
      namespace: default
    spec:
      externalTrafficPolicy: Local
      ports:
      - name: tcp
        port: 80
        protocol: TCP
        targetPort: 80
      - name: https
        port: 443
        protocol: TCP
        targetPort: 443
      selector:
        app: nginx
      loadBalancerClass: "alibabacloud.com/nlb"
      type: LoadBalancer

  • Ingress: 支持通过 Terraform、ROS 等基础设施即代码（IaC）工具进行自动化部署ALB。支持K8s集群中kubectl，负责监听API Server中AlbConfig/Ingress/Service等资源的变化，动态地转换为ALB所需的配置，原生兼容Nginx Ingress。

    

安全性

• 网络通信限制与加密：

  • Service & Ingress: ALB、NLB默认支持加入安全组，可以进行基于协议/端口/IP的访问控制。

  • Ingress：ALB支持HTTP、HTTPS、WebSocket、TLS等多种协议。

Service设计

场景介绍

用阿里云上容器ACK的POD做Web Server，即：Application安装在ACK的POD中、Service服务以IP+Port形式暴露。

Service类型选择

LoadBalancer型Service，基于NodePort增加了一个外部负载均衡器，使外部流量能够平滑地分发到集群中的多个Pod上。Service会自动提供一个外部IP，客户端可通过此IP访问服务。该服务既支持在OSI模型的第四层（传输层）处理TCP/UDP类型的流量，也可以扩展至第七层（应用层），进行HTTP/HTTPS流量管理。

创建或关联NLB

• 可以选择已有NLB实例，也可以自动创建新的NLB作为LoadBalancer

• 可以通过ACK控制台或kubectl（YAML脚本）创建或关联NLB，并配置服务关联（相当于NLB挂载服务器组）和端口映射（相当于NLB配置监听）

• 通过Service YAML文件中的Annotation（注解）可以实现丰富的负载均衡NLB。

NLB配额限制

请关注NLB配额限制。

Ingress设计

ALB云原生Ingress

场景介绍

采用ALB Ingress为集群中的Service提供统一的入口。与Nginx Ingress相比，ALB Ingress的特点是全托管服务，您无需进行维护操作。它能自动检测Kubernetes集群中Ingress资源的变化，并根据预设规则将流量分配至后端服务。此外，ALB Ingress设计有较强的弹性伸缩机制，能够自动适应流量的动态变化，确保系统稳定运行。

工作原理

ALB Ingress涉及到以下基本概念：

• ALB Ingress Controller：负责管理Ingress资源的组件。它通过API Server动态地获取Ingress资源和AlbConfig资源的变化，然后更新ALB实例。与Nginx Ingress Controller不同，ALB Ingress Controller 是 ALB 实例的控制面，负责管理 ALB 实例，但不直接处理用户流量。用户流量的转发由 ALB 实例来实现。ALB Ingress Controller会通过集群API Server动态地获取Ingress资源的变化，并依照Ingress所描述的转发规则动态地更新ALB实例。

• AlbConfig（CRD）：AlbConfig是由ALB Ingress Controller创建的一种CRD (Custom Resource Definition) 。AlbConfig中的参数决定了ALB实例的配置。一个AlbConfig对应一个ALB实例。ALB实例是用户请求流量的入口，负责将用户请求转发到后端Service中。它由ALB完全托管。相比起Nginx Ingress Controller，ALB Ingress免于运维，并且拥有更强大的弹性。

• IngressClass：IngressClass定义了某一个Ingress与某一个AlbConfig的关联。

• Ingress：Ingress是Kubernetes中用于定义外部流量路由规则和访问规则的资源对象，ALB Ingress Controller通过监测Ingress资源的变化并更新ALB实例以实现流量转发。

• Service：在Kubernetes中，Pod被认为是临时资源，是不稳定而多变的。Service为具有相同功能的Pod提供了一个稳定、统一的入口。其他应用程序或服务可以通过访问Service的虚拟IP和端口来与后端Pod进行通信，而无需关注Pod可能发生的变化。关于Service的详细介绍，请参见Service快速入门。

配额限制

请关注ALB Ingress配额限制。

NLB+Nginx Ingress

场景介绍

采用开源的 Nginx 作为 Ingress 控制器，并将其部署在 Kubernetes 的 Pod 中。前端则使用网络负载均衡器（NLB）来实现对这些 Pod 的流量分发。通过这种架构，NLB 和 Nginx 共同构成了一个高效且可靠的七层流量入口系统。

配额限制

请关注NLB配额限制。

ALB Ingress对比Nginx Ingress