为什么需要MCI 在传统的Kubernetes集群中，每个集群都有其负载均衡器和Ingress，这使得在多个集群之间进行负载均衡和流量路由变得困难。U CS 为多集群提供了统一的流量入口MCI（Multi Cluster Ingress），帮助您更加简单高效地跨集群、跨区域进行负载均衡和流量路由，进而提高应用程序的可用性和可靠性。 MCI是一种多集群Ingress资源对象，可以根据指定规则将外部流量路由到多个集群内的Pod。使用MCI，用户可自定义转发规则，完成对访问流量的细粒度划分。图1展示了流量如何从MCI流向集群：从 域名 foo.example.com 流入的流量流向了两个集群中带有标签 app:foo 的 Pod，从域名goo.example.com 流入的流量流向了两个集群中具有标签 app:goo的 Pod。 图1 MCI示意图 具体来说，MCI的优势在于： 多集群负载均衡：MCI为用户提供统一入口，将流量分发到多个Kubernetes集群中，与集群所处位置无关。 流量路由：使用MCI，用户可根据不同条件（URL、HTTP头、源IP等）自定义转发规则，将流量路由到不同集群，实现更灵活的流量控制。 高可用：MCI通过健康检查和流量自动切换，实现多集群、多区域的高可用性。 可扩展性：MCI发现和管理多个Kubernetes集群上的应用程序资源，实现应用程序自动扩展和部署。 安全性：MCI支持TLS安全策略和证书管理，保障应用程序的安全性。

MCI的工作原理 MCI的功能主要通过请求转发执行器MCI Controller实现。MCI Controller部署在集群联邦控制面，实时监控资源对象的变化，解析MCI对象定义的规则并负责将请求转发到相应的后端Service。 图2 MCI Controller工作原理 MCI Controller支持在同一个ELB实例（即同一IP）下设置不同域名、端口和转发规则，其工作原理如图2，实现流程如下： 部署人员在集群联邦控制面创建工作负载，并为其配置Service对象。 部署人员在集群联邦控制面创建MCI对象，并在MCI中配置流量访问规则，包括关联的负载均衡器、URL以及访问的后端Service及端口等。 MCI Controller监控到MCI对象发生变化，会根据MCI中定义的规则，在ELB侧重新配置监听器以及后端服务器路由。 当用户进行访问时，流量根据ELB中配置的转发策略被转发到对应的后端Service关联的各个工作负载。

注意事项 建议其他资源不要使用Ingress自动创建的ELB实例，否则在删除Ingress时，ELB实例会被占用，导致资源残留。 添加Ingress后请在CCE页面对所选ELB实例进行配置升级和维护，不可在ELB页面对配置进行更改，否则可能导致Ingress服务异常。 Ingress转发策略中注册的URL需与后端应用提供访问的URL一致，否则将返回404错误。 独享型ELB规格必须支持应用型（HTTP/HTTPS），且网络类型必须支持私网（有私有IP地址）。 同集群使用多个Ingress对接同一个ELB端口时，监听器的配置项（例如监听器关联的证书、监听器HTTP2属性等）均以第一个Ingress配置为准。

添加Nginx Ingress 本节以Nginx作为工作负载并添加Nginx Ingress为例进行说明。 登录CCE控制台，单击集群名称进入集群。 选择左侧导航栏的“服务”，在右侧选择“路由”页签，单击右上角“创建路由”。 设置Ingress参数。 名称：自定义Ingress名称，例如nginx-ingress-demo。 命名空间：选择需要添加Ingress的命名空间。 对接Nginx：集群中已安装NGINX Ingress控制器插件后显示此选项，未安装该插件时本选项不显示。 前端协议：支持HTTP和HTTPS，安装NGINX Ingress控制器插件时预留的监听端口，默认HTTP为80，HTTPS为443。使用HTTPS需要配置相关证书。 证书来源：使用证书以支持HTTPS数据传输加密认证。 如果您选择“TLS密钥”，需要提前创建IngressTLS或kubernetes.io/tls类型的密钥证书，创建密钥的方法请参见创建密钥。 如果您选择“默认证书”，NGINX Ingress控制器会使用插件默认证书进行加密认证。选择“默认证书”将使用NGINX Ingress控制器自带证书。 SNI：SNI（Server Name Indication）是TLS的扩展协议，在该协议下允许同一个IP地址和端口号下对外提供多个基于TLS的访问域名，且不同的域名可以使用不同的安全证书。开启SNI后，允许客户端在发起TLS握手请求时就提交请求的域名信息。负载均衡收到TLS请求后，会根据请求的域名去查找证书：若找到域名对应的证书，则返回该证书认证鉴权；否则，返回缺省证书（服务器证书）认证鉴权。 转发策略配置：请求的访问地址与转发规则匹配时（转发规则由域名、URL组成），此请求将被转发到对应的目标Service处理。单击“添加转发策略”按钮可添加多条转发策略。 域名：实际访问的域名地址。请确保所填写的域名已注册并备案，在Ingress创建完成后，将域名与自动创建的负载均衡实例的IP（即Ingress访问地址的IP部分）绑定。一旦配置了域名规则，则必须使用域名访问。 URL匹配规则： 默认：默认为前缀匹配。 前缀匹配：例如映射URL为/healthz，只要符合此前缀的URL均可访问。例如/healthz/v1，/healthz/v2。 精确匹配：表示只有URL完全匹配时，访问才能生效。例如映射URL为/healthz，则必须为此URL才能访问。 URL：需要注册的访问路径，例如：/healthz。 Nginx Ingress的访问路径匹配规则是基于“/”符号分隔的路径前缀匹配，并区分大小写。只要访问路径以“/”符号分隔后的子路径匹配此前缀，均可正常访问，但如果该前缀仅是子路径中的部分字符串，则不会匹配。例如URL设置为/healthz，则匹配/healthz/v1，但不匹配/healthzv1。 此处添加的访问路径要求后端应用内存在相同的路径，否则转发无法生效。 例如，Nginx应用默认的Web访问路径为“/usr/share/nginx/html”，在为Ingress转发策略添加“/test”路径时，需要应用的Web访问路径下也包含相同路径，即“/usr/share/nginx/html/test”，否则将返回404。 目标服务名称：请选择已有Service或新建Service。页面列表中的查询结果已自动过滤不符合要求的Service。 目标服务访问端口：可选择目标Service的访问端口。 操作：可单击“删除”按钮删除该配置。 注解：以“key: value”形式设置，可通过Annotations查询nginx-ingress支持的配置。 配置完成后，单击“确定”。 创建完成后，在Ingress列表可查看到已添加的Ingress。

URI GET /apis/extensions/v1beta1/namespaces/{namespace}/ingresses 表1 路径参数 参数 是否必选 参数类型 描述 namespace 是 String object name and auth scope, such as for teams and projects 表2 Query参数 参数 是否必选 参数类型 描述 allowWatchBookmarks 否 Boolean allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored. continue 否 String The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key". This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications. fieldSelector 否 String A selector to restrict the list of returned objects by their fields. Defaults to everything. labelSelector 否 String A selector to restrict the list of returned objects by their labels. Defaults to everything. limit 否 Integer limit is a maximum number of responses to return for a list call. If more items exist, the server will set the continue field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true. The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned. resourceVersion 否 String resourceVersion sets a constraint on what resource versions a request may be served from. See https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-versions for details. Defaults to unset resourceVersionMatch 否 String resourceVersionMatch determines how resourceVersion is applied to list calls. It is highly recommended that resourceVersionMatch be set for list calls where resourceVersion is set See https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-versions for details. Defaults to unset timeoutSeconds 否 Integer Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity. watch 否 Boolean Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion. pretty 否 String If 'true', then the output is pretty printed.

响应示例 状态码： 200 OK { "apiVersion" : "extensions/v1beta1", "items" : [ { "metadata" : { "annotations" : { "kubernetes.io/elb.id" : "xxx-xxx-xxx-xxx-xxx", "kubernetes.io/elb.ip" : "192.168.137.182", "kubernetes.io/elb.port" : "6071" }, "creationTimestamp" : "2018-09-04T02:16:14Z", "generation" : 1, "labels" : { "app" : "redis", "isExternal" : "true", "zone" : "data" }, "name" : "redis", "namespace" : "namespace-test", "resourceVersion" : "5161128", "selfLink" : "/apis/extensions/v1beta1/namespaces/namespace-test/ingresses/redis", "uid" : "7f86c310-afe8-11e8-b6ef-f898ef6c78b4" }, "spec" : { "rules" : [ { "http" : { "paths" : [ { "backend" : { "serviceName" : "redis", "servicePort" : 8080 }, "path" : "/" } ] } } ] }, "status" : { "loadBalancer" : { "ingress" : [ { "ip" : "192.168.137.182" } ] } } } ], "kind" : "IngressList", "metadata" : { "resourceVersion" : "5161998", "selfLink" : "/apis/extensions/v1beta1/namespaces/namespace-test/ingresses" } }

状态码 状态码 描述 200 OK 400 BadRequest 401 Unauthorized 403 Forbidden 404 NotFound 405 MethodNotAllowed 406 NotAcceptable 409 Conflict 415 UnsupportedMediaType 422 Invalid 429 TooManyRequests 500 InternalError 503 ServiceUnavailable 504 ServerTimeout

networking.k8s.io/v1版本Ingress说明 CCE在v1.23版本集群开始Ingress切换到networking.k8s.io/v1版本。 v1版本参数相较v1beta1参数有如下区别。 ingress类型由annotations中kubernetes.io/ingress.class变为使用spec.ingressClassName字段。 backend的写法变化。 每个路径下必须指定路径类型pathType，支持如下类型。 ImplementationSpecific: 对于这种路径类型，匹配方法取决于具体Ingress Controller的实现。在CCE中会使用ingress.beta.kubernetes.io/url-match-mode指定的匹配方式，这与v1beta1方式相同。 Exact：精确匹配 URL 路径，且区分大小写。 Prefix：基于以 / 分隔的 URL 路径前缀匹配。匹配区分大小写，并且对路径中的元素逐个匹配。 路径元素指的是由 / 分隔符分隔的路径中的标签列表。

前提条件 集群必须已安装NGINX Ingress 控制器，具体操作可参考安装插件。 Ingress为后端工作负载提供网络访问，因此集群中需提前部署可用的工作负载。若您无可用工作负载，可参考创建无状态负载（Deployment）、创建有状态负载（StatefulSet）或创建守护进程集（DaemonSet）部署工作负载。 为上述工作负载配置ClusterIP类型或NodePort类型的Service，可参考集群内访问（ClusterIP）或节点访问（NodePort）配置示例Service。

场景示例 下图场景为例。某企业在华为云使用CCE集群，并通过自建Nginx Ingress Controller配置Ingress转发规则，配置域名和路径的转发策略，且对外通过DNS域名提供服务。客户端访问域名example.com时，Nginx Ingress接收到请求会根据对应的转发策略将流量转发至对应Service的Pod上。 由于业务发展需要，该企业需要将自建Nginx Ingress迁移到ELB Ingress上。为了保持业务稳定，希望不改变对外提供服务的DNS域名及后端服务器的IP地址。您可以通过在 CCE集群上配置 ELB Ingress 规则，使ELB提供的转发策略与之前一致，然后利用DNS域名解析的权重设置完成流量的迁移。 建议在业务低谷期进行流量的切换。 使用ELB会产生计费信息，具体计费详情请参见计费概述。

切流至ELB Ingress 流量切换前，假设您已将业务域名通过A记录解析的方式指向了自建Nginx Ingress的公网地址。您可以使用DNS的流量权重分配，逐步将访问原Nginx Ingress的流量切换至新的ELB Ingress。 图1 使用DNS切流 您可以通过以下步骤完成流量的切换。 进入公网域名列表页面。 在“公网域名”页面的域名列表中，单击域名example.com的名称。 进入“解析记录”页面。此时已存在一个A记录，对应Nginx Ingress的公网IP。修改Nginx Ingress的A记录的权重为9。 单击“添加记录集”，添加A记录，地址为待迁移的ELB公网IP，并将权重设置为1。 图2 修改DNS记录集 在观察业务没有影响的情况下，逐步调整ELB实例解析记录的权重值至100%。

通过控制台创建 登录CCE控制台，单击集群名称进入集群。 在左侧导航栏中选择“服务”，切换至“路由”页签，在右上角单击“创建路由”。 设置Ingress参数。本示例中仅列举必选参数，其余参数可根据需求参考通过控制台创建ELB Ingress进行设置。 名称：自定义服务名称，可与工作负载名称保持一致。 负载均衡器：选择弹性负载均衡的类型、创建方式。 类型：本例中仅支持选择“独享型”。 创建方式：本文中以选择已有ELB为例进行说明，关于自动创建的配置参数请参见负载均衡器。 监听器配置： 前端协议：支持HTTP和HTTPS。本文以HTTP协议为例。 对外端口：开放在负载均衡服务地址的端口，可任意指定。 高级配置： 配置 说明 使用限制 获取监听器端口号 开启后可以将ELB实例的监听端口从报文的HTTP头中带到后端云服务器。 独享型ELB实例支持配置。 获取客户端请求端口号 开启后可以将客户端的源端口从报文的HTTP头中带到后端云服务器。 独享型ELB实例支持配置。 重写X-Forwarded-Host 开启后将以客户端请求头的Host重写X-Forwarded-Host传递到后端云服务器。 独享型ELB实例支持配置。 图1 配置HTTP/HTTPS头字段 转发策略配置：填写域名匹配规则及需要访问的目标Service。请求的访问地址与转发规则匹配时（转发规则由域名、URL组成，例如：10.117.117.117:80/helloworld），此请求将被转发到对应的目标Service处理。 单击“确定”，创建Ingress。

Ingress支持的Service类型 ELB Ingress支持的Service类型如表1所示。 表1 ELB Ingress支持的Service类型 集群类型 ELB类型 集群内访问（ClusterIP） 节点访问（NodePort） CCE Standard集群 共享型负载均衡 不支持 支持 独享型负载均衡 不支持（集群内访问服务关联实例未绑定eni网卡，独享型负载均衡无法对接） 支持 CCE Turbo 集群 共享型负载均衡 不支持 支持 独享型负载均衡 支持 不支持（节点访问服务关联实例已绑定eni网卡，独享型负载均衡无法对接） Nginx Ingress支持的Service类型如表2所示。 表2 Nginx Ingress支持的Service类型 集群类型 ELB类型 集群内访问（ClusterIP） 节点访问（NodePort） CCE Standard集群 共享型负载均衡 支持 支持 独享型负载均衡 支持 支持 CCE Turbo集群 共享型负载均衡 支持 支持 独享型负载均衡 支持 支持

为什么需要Ingress Service基于TCP和UDP协议进行访问转发，为集群提供了四层负载均衡的能力。但是在实际场景中，Service无法满足应用层中存在着大量的HTTP/HTTPS访问需求。因此，Kubernetes集群提供了另一种基于HTTP协议的访问方式——Ingress。 Ingress是Kubernetes集群中一种独立的资源，制定了集群外部访问流量的转发规则。如图1所示，用户可根据域名和路径对转发规则进行自定义，完成对访问流量的细粒度划分。 图1 Ingress示意图 下面对Ingress的相关定义进行介绍： Ingress资源：一组基于域名或URL把请求转发到指定Service实例的访问规则，是Kubernetes的一种资源对象，通过接口服务实现增、删、改、查的操作。 Ingress Controller：请求转发的执行器，用以实时监控资源对象Ingress、Service、Endpoint、Secret（主要是TLS证书和Key）、Node、ConfigMap的变化，解析Ingress定义的规则并负责将请求转发到相应的后端Service。 Ingress Controller在不同厂商之间的实现方式不同，根据负载均衡器种类的不同，可以将其分成ELB型和Nginx型。CCE支持上述两种Ingress Controller类型，其中ELB Ingress Controller基于弹性负载均衡服务（ELB）实现流量转发；而Nginx Ingress Controller使用Kubernetes社区维护的模板与镜像，通过Nginx组件完成流量转发。

ELB Ingress Controller工作原理 CCE自研的ELB Ingress Controller基于弹性负载均衡服务ELB实现公网和内网（同一VPC内）的七层网络访问，通过不同的URL将访问流量分发到对应的服务。 ELB Ingress Controller部署于Master节点上，与集群所在VPC下的弹性负载均衡器绑定，支持在同一个ELB实例（同一IP）下进行不同域名、端口和转发策略的设置。ELB Ingress Controller的工作原理如图2，实现步骤如下： 用户创建Ingress资源，在Ingress中配置流量访问规则，包括负载均衡器、URL、SSL以及访问的后端Service端口等。 Ingress Controller监听到Ingress资源发生变化时，就会根据其中定义的流量访问规则，在ELB侧重新配置监听器以及后端服务器路由。 当用户进行访问时，流量根据ELB中配置的转发策略转发到对应的后端Service端口，然后再经过Service二次转发访问到关联的各个工作负载。 图2 ELB Ingress工作原理（CCE Standard集群以及CCE Turbo集群使用共享型ELB场景） 在使用CCE Turbo集群 + 独享型ELB实例时，Pod IP直接从VPC中分配，支持ELB直通Pod。创建集群外部访问的Ingress时，可使用ELB对接ClusterIP服务，直接将Pod作为ELB监听器的后端服务器，外部流量可以不经过节点端口转发直接访问集群中的Pod。 图3 ELB Ingress直通容器原理（CCE Turbo集群使用独享型ELB场景）