通过MCI访问服务 MCI对象创建成功后，您可以通过 http://IP:port/path 访问后端工作负载，其中IP:port为MCI关联ELB的IP和端口，path为MCI对象中定义的路径。 MCI对象中还可以设置外部 域名 ，这样您就可以通过域名来访问到ELB，进而访问到后端服务。 spec: rules: - host: www.example.com # 域名 http: paths: - path: / backend: serviceName: nginx # 准备一个名为nginx的联邦service servicePort: 80 # 端口号为80 域名访问依赖于域名解析，需要您将域名解析指向ELB实例的IP地址，例如您可以使用云解析服务 DNS来实现域名解析。 若访问服务失败，请参考通过MCI访问服务失败，如何排查？。

创建MCI对象 使用kubectl连接集群联邦，详细操作请参见使用kubectl连接集群联邦。 创建并编辑 mci.yaml 文件，文件内容定义如下所示，参数定义请参见表1。 vi mci.yaml apiVersion: networking.karmada.io/v1alpha1 kind: MultiClusterIngress metadata: name: nginx-ingress namespace: default annotations: karmada.io/elb.conditions.nginx-svc: '[{ "type": "header", "headerConfig": { "key":"x-header", "values": [ "green" ] } }]' karmada.io/elb.id: 90f9f782-1243-41cc-a57d-6157f6cb85bf karmada.io/elb.projectid: 65382450e8f64ac0870cd180d14e684b karmada.io/elb.port: "883" # 端口设置 karmada.io/elb.health-check-flag.nginx-svc: "on" # 对应服务的健康检查配置项开关 karmada.io/elb.health-check-option.nginx-svc: '{"protocol":"TCP"}' # 对应服务的健康检查配置项 spec: ingressClassName: public-elb rules: - host: demo.localdev.me http: paths: - backend: service: name: nginx-svc # 准备一个名为nginx-svc的联邦service port: number: 8080 # 端口号为8080 path: /web pathType: Prefix MCI对象的结构体定义与networking.kubernetes.io/v1版本Ingress一致，不同之处在于后端服务需要填写为联邦Service，即在U CS 控制台创建的Service，具体请参见集群内访问（ClusterIP）。 在配置MCI文件内容的过程中需要遵守的约束条件如下： apiVersion，kind，name必须指定。 spec下不允许填写TLS和DefaultBackend字段。 rules、paths不能为空。 host必须是DNS名称，不可以是IP地址。 service中所指定的后端服务必须是存在的、且输入的相关信息（如端口）是正确的，否则会导致访问服务失败。若您已经创建了参数信息错误的MCI对象，请参考4中的命令更新该MCI对象。 paths中，配置的高级转发策略（karmada.io/elb.conditions.{service name}）越多的后端（backend）在paths中的位置应该越靠前。因为backend在paths中配置的位置越靠前，其转发优先级越高。 示例：如果为后端X配置两条转发策略a和b，为后端Y配置一条转发规则a，则此时paths中X的配置顺序应在Y之前，否则，同时符合a、b两条转发规则的流量将按照优先级顺序全部转发至Y中。 backend下不允许填写resource字段。 path值需要是绝对路径；不合法的path值：invalidPathSequences = []string{"//", "/./", "/../", "%2f","%2F"}，invalidPathSuffixes = []string{"/..", "/."}。 pathType合法值：Exact、Prefix、ImplementationSpecific。 在默认配置下，Service名称的长度限制最长支持50个字符。 表1 关键参数说明 参数 是否必填 参数类型 描述 karmada.io/elb.id 是 String MCI关联的elb的id，不允许为空。 取值范围：1-32个字符。 karmada.io/elb.projectid 是 String MCI关联的elb所属的项目ID，获取方法请参见获取项目ID。 取值范围：1-32个字符。 karmada.io/elb.port 否 String MCI关联的elb的端口，不填时默认为80。 取值范围：1-65535。 karmada.io/elb.health-check-flag.{service name} 否 String 是否启用健康检查，可选值为： on：开启 off：不开启 不填写时默认为off。 说明： 该标签为"karmada.io/elb.health-check-flag.{serviceName}"，仅对对应的service生效； karmada.io/elb.health-check-option.{service name} 否 HealthCheck Object 健康检查参数，详情请参见HealthCheck。{service name}请修改为联邦Service的名称。 说明： 健康检查参数配置示例： karmada.io/elb.health-check-option.nginx-svc: '{"protocol":"TCP","delay":"5","connect_port":"80","timeout":"1","max_retries":"1","path":"/wd"}' 在annotation开启健康检查配置的情况下，Service名称的长度不应超过39个字符。 karmada.io/elb.conditions.{service name} 否 Array of Condition Object 高级转发策略，详情请参见Condition。{service name}请修改为联邦Service的名称。 karmada.io/elb.lb-algorithm.{service name} 否 String 转发算法： ROUND_ROBIN：加权轮询算法。 LEAST_CONNECTIONS：加权最少连接算法。 SOURCE_IP：源IP算法。 不填写时默认为ROUND_ROBIN。 {service name}请修改为联邦Service的名称。 karmada.io/elb.keepalive_timeout 否 string 客户端连接空闲超时时间，单位为秒。当一直未请求的时间超过配置值，负载均衡会暂时中断当前连接，直到下一次请求时再重新建立新的连接。 不填写时默认为60s。 取值范围：0-4000s karmada.io/elb.client_timeout 否 string 等待客户端请求超时时间，单位为秒。 不填写时默认值为60s。 取值范围：1-300s karmada.io/elb.member_timeout 否 string 等待后端服务器响应超时时间，单位为秒。请求转发后端服务器后，若未响应时间超过配置值，负载均衡将终止等待，并返回HTTP 504错误码。 不填写时默认为60s。 取值范围：1-300s ingressClassName 是 String ingressClass名称。取值必须为public-elb。 host 否 String 为服务访问域名配置，默认为""，表示域名全匹配。请确保所填写的域名已注册并备案，一旦配置了域名规则后，必须使用域名访问。 backend 否 Backend Object 后端，是Service和端口名称的组合。对于发往MCI的 HTTP和HTTPS请求，如果与规则中的主机和路径匹配，则会被发送到所列出的后端。 注意： 后端在paths中的配置顺序决定了策略的转发优先级。 示例：如果为后端X配置两条转发策略a和b，为后端Y配置一条转发规则a，则此时paths中X的配置顺序应在Y之前，否则，同时符合a、b两条转发规则的流量将按照优先级顺序全部转发至Y中。 path 是 String 路由路径，您可以自定义设置。所有外部访问请求需要匹配host和path。 说明： 此处添加的访问路径要求后端应用内存在相同的路径，否则转发无法生效。 例如，Nginx应用默认的Web访问路径为“/usr/share/nginx/html”，在为Ingress转发策略添加“/test”路径时，需要应用的Web访问路径下也包含相同路径，即“/usr/share/nginx/html/test”，否则将返回404。 pathType 是 String 路径类型。 ImplementationSpecific: 正则匹配，请求的URL和设定的URL正则表达式匹配。 Exact：精确匹配 URL 路径，且区分大小写。 Prefix：前缀匹配，且区分大小写。该方式是将URL路径通过“/”分隔成多个元素 ，并且对元素进行逐个匹配。 如果URL中的每个元素均和路径匹配，则说明该URL的子路径均可以正常路由。 说明： Prefix匹配时每个元素均需精确匹配，如果URL的最后一个元素是请求路径中最后一个元素的子字符串，则不会匹配 。例如：/foo/bar匹配/foo/bar/baz，但不匹配/foo/barbaz。 通过“/”分隔元素时，若URL或请求路径以“/”结尾，将会忽略结尾的“/”。例如：/foo/bar会匹配/foo/bar/。 关于Ingress路径匹配示例，请参见示例。 表2 HealthCheck参数说明 参数 是否必填 参数类型 描述 protocol 否 String 健康检查使用的协议，支持TCP/HTTP，默认值是HTTP。 connect_port 否 Int 健康检查使用的端口。取值范围[1，65535]，为可选参数。 说明： 默认使用后端服务器默认业务端口进行健康检查。指定特定端口后，使用指定的端口进行健康检查。 delay 否 Int 健康检查的延迟时间，以秒为单位，1-50，默认值是5秒。 timeout 否 Int 健康检查的超时时间，以秒为单位，1-50，默认值是10秒。 path 否 String 健康检查的请求URL，当type为HTTP/HTTPS时生效。 以"/"开头，默认为"/"。支持使用字母、数字和短划线（-）、正斜线（/）、半角句号（.）、百分号（%）、半角问号（?）、井号（#）和and（&）以及扩展字符集。长度为1-80个字符。 max_retries 否 Int 最大重试次数，取值范围1-10，默认值是3次。 表3 Condition参数说明 参数 是否必填 参数类型 描述 type 是 String 高级转发策略类型，当前仅支持header。 headerConfig 是 headerConfig Object 高级转发策略对象，详情请参见headerConfig。 表4 headerConfig参数说明 参数 是否必填 参数类型 描述 key 是 String 转发Header头。 长度限制1-40字符，只允许包含字母、数字、短划线和下划线。 values 是 String数组 转发Header头对应的值。 长度限制1-128字符，不支持空格， 双引号，支持以下通配符：*（匹配0个或更多字符）和？（正好匹配1个字符）。 执行如下命令创建MCI对象。 kubectl apply -f mci.yaml 回显如下。 multiClusterIngress.networking.karmada.io/nginx-ingress created 创建完成后，可以执行如下命令操作MCI对象。其中nginx-ingress为MCI对象的名称。 获取MCI对象：kubectl get mci nginx-ingress 更新MCI对象：kubectl edit mci nginx-ingress 删除MCI对象：kubectl delete mci nginx-ingress

准备工作 如您没有可用的ELB实例，需要先创建ELB实例，具体请参考创建独享型负载均衡器。该ELB实例需要满足以下条件： ELB为独享型。 ELB必须支持应用型（HTTP/HTTPS）。 ELB网络类型必须支持私网（有私有IP地址）。 如果ELB与成员集群的网络不在同一VPC内，ELB需要支持开启跨VPC访问的开关。 MCI为跨集群后端工作负载提供统一入口和七层网络访问，因此需要在联邦中提前部署可用的工作负载（Deployment）和服务（Service）。若您无可用工作负载和服务，请参考无状态负载和集群内访问（ClusterIP）创建。 设置集群为underlay网络，支持underlay网络的集群类型请参见设置集群网络。

约束限制 当前MCI仅支持版本为1.21及以上的 CCE Turbo 集群、网络模型为underlay的其他Kubernetes集群创建。 请提前做好网络规划，保证成员集群间容器网络不冲突，确保ELB实例与容器Pod IP网络可达。若MCI的ELB实例与集群处于不同VPC内，请提前打通VPC间的网络。 当为同一Service同时配置MCI与MCS时，该Service将会下发至MCS中配置的下发集群、访问集群以及对应工作负载的部署集群。

请求示例 { "apiVersion" : "extensions/v1beta1", "kind" : "Ingress", "metadata" : { "annotations" : { "kubernetes.io/elb.id" : "xxx", "kubernetes.io/elb.ip" : "192.168.137.182", "kubernetes.io/elb.port" : "6071" }, "labels" : { "app" : "redis" }, "name" : "redis" }, "spec" : { "rules" : [ { "http" : { "paths" : [ { "backend" : { "serviceName" : "redis", "servicePort" : 8080 }, "path" : "/" } ] } } ] } }

响应示例 状态码： 200 OK { "apiVersion" : "extensions/v1beta1", "kind" : "Ingress", "metadata" : { "annotations" : { "kubernetes.io/elb.id" : "xxx", "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" : "5161127", "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" : { } } }

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

功能介绍 创建Ingress，使用http协议，关联的后端Service为“redis:8080”，使用ELB作为Ingress控制器，ELB的ip为192.168.137.182，端口号为6071。 说明： 若需要在CCI工作负载详情页面的“访问方式”页签中显示对应的Ingress资源，则需要给创建的Ingress资源对象添加labels标签。添加的标签需满足如下要求： service的labels中设置的标签必须和负载的selector中matchLabels设置的label一致。 例如，负载中matchLabels标s签设置如下： "spec": { "replicas": 1, "selector": { "matchLabels": { "app": "redis" } } service中的labels也必须设置为**"app": "redis"**： "metadata": { "name": "redis", "labels": { "app": "redis" } ingress中定义的serviceName必须和service中定义的名称一致。

URI POST /apis/extensions/v1beta1/namespaces/{namespace}/ingresses 表1 路径参数 参数 是否必选 参数类型 描述 namespace 是 String object name and auth scope, such as for teams and projects 表2 Query参数 参数 是否必选 参数类型 描述 dryRun 否 String When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed fieldManager 否 String fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. pretty 否 String If 'true', then the output is pretty printed.

直接访问Pod的问题 负载创建完成后，如何访问负载呢？访问负载实际上就是访问Pod，但是直接访问Pod会有如下几个问题： Pod会随时被Deployment这样的控制器删除重建，那访问Pod的结果就会变得不可预知。 Pod的IP地址是在Pod启动后才被分配，在启动前并不知道Pod的IP地址。 应用往往都是由多个运行相同镜像的一组Pod组成，一个个Pod的访问也变得不现实。 举个例子，假设有这样一个应用程序，使用Deployment创建了前台和后台，前台会调用后台做一些计算处理，如图1所示。后台运行了3个Pod，这些Pod是相互独立且可被替换的，当Pod出现状况被重建时，新建的Pod的IP地址是新IP，前台的Pod无法直接感知。 图1 负载间访问

Service是如何工作的 Kubernetes中的Service对象就是用来解决上述Pod访问问题的。Service有一个固定IP地址，Service将访问他的流量转发给Pod，具体转发给哪些Pod通过Label来选择，而且Service可以给这些Pod做负载均衡。 那么对于上面的例子，通过为前后台添加两个Service，通过Service来访问Pod，这样前台Pod就无需感知后台Pod的变化，如图2所示。 图2 通过Service访问Pod

LoadBalancer类型的Service 现在您知道可以创建ClusterIP类型的Service，通过Service的IP可以访问到Service后端的Pod。 云容器实例同时还支持创建LoadBalancer类型的Service，将增强型ELB实例与Service绑定，这样访问ELB实例的流量就会访问到Service。 ELB实例根据IP地址不同可以分为私网ELB实例和公网ELB实例，区别在于公网ELB实例绑定了一个公网IP，您可以根据需要选择。您可以调用创建负载均衡器（增强型）创建ELB实例，更方便的方法是通过ELB控制台创建增强型ELB实例。 ELB实例必须与Service在同一个VPC内，否则无法绑定。 跨namespace不支持service或ELB域名访问，只能通过ELB内网IP:端口访问。 图3 LoadBalancer Service 下面是一个创建LoadBalancer类型的Service。创建完成后，可以通过ELB的IP:Port访问到后端Pod。 apiVersion: v1 kind: Service metadata: name: nginx annotations: kubernetes.io/elb.id: 77e6246c-a091-xxxx-xxxx-789baa571280 # ELB的ID spec: selector: app: nginx ports: - name: service0 targetPort: 80 port: 8080 # ELB访问端口 protocol: TCP type: LoadBalancer # Service的类型

添加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。

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

为什么需要MCI 在传统的Kubernetes集群中，每个集群都有其负载均衡器和Ingress，这使得在多个集群之间进行负载均衡和流量路由变得困难。UCS为多集群提供了统一的流量入口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安全策略和证书管理，保障应用程序的安全性。