创建应用服务
LHC 应用服务对 Kubernetes 原生的 Deployment 做了能力增强,您可以通过创建应用服务定义容器服务的基本信息、访问策略、发布及调度策略等信息,为后续容器服务的部署做准备。
前提条件
创建应用服务的过程分为以下 6 个步骤:
一、填写基本信息
登录控制台,在左侧导航栏单击 发布运维 > 应用服务。
在应用服务列表页,单击 创建应用服务。
在 创建应用服务 页面,填写以下基本信息,单击 下一步。
命名空间:选择命名空间,默认为列表第一个。
应用服务名称:容器服务的名称。服务实例名称允许包含(小写)字母、数字、连字符,且必须以字母开头,以字母或数字结尾。同一个工作空间组下不允许同名。
所属应用:选择一个该容器服务所关联的应用。
有状态模式:默认关闭。开启后,Pod 名称会加上
-0
、-1
... 数字后缀,重建过程中不会生成新 Pod 名称。相关操作,请参见 LHC Pod 域名配置。数据卷模板配置:可选,用于挂载存储。单击 添加配置 可设置多个。具体配置项如下:
名称:输入模板名称。允许包含字母、数字、连字符,且必须以字母开头,以字母或数字结尾。
存储类型:用于指定支持的存储类别。单击 创建存储类型 将跳转至存储页。
说明对于存储类型,通常由系统管理员定义,具体类别因存储 SLA、备份策略等而异。
对于多集群下的存储类型,需要多集群下都存在此存储类型才可以被调用。
容量:设置数据卷模板的容量。单位为 GiB。
说明数据卷容量大小受设置的 PV 容量的限制。关于 PV 容量设置,请参见 创建存储卷。
描述:选填。容器服务的描述。
二、Pod 模板配置
对 Pod 里的容器做详细的配置。Pod 与容器之间的比例并非 1:1,可通过单击 添加应用容器 为单 Pod 配置多个容器。
对于可添加的容器数量,暂无限制。
基本选项
容器类型:支持 APP 和 INIT 两种类型。
容器名称:容器名称。
镜像来源:支持 镜像仓库、构建记录 两种方式。
CPU 配置:设置容器使用的 CPU 的数量。请求核数 为能保证的最小核数,最大核数 为能使用的最大核数。换算方式:1 core = 1000 millicores。
内存配置:设置容器使用的内存的数量。请求内存 为能保证的最小内存数量,最大内存 为能使用的最大内存数量。换算方式:1024 Bytes = 1 KiB;1024 KiB = 1 MiB;1024 MiB = 1 GiB;1024 GiB = 1 TiB。
启动命令:选填。用于指定容器启动时执行的命令。
高级配置
默认关闭 。如果开启 ,需要完成以下选项配置。
hostNetwork 配置:默认关闭。开启后,Pod IP 地址与节点 IP 地址保持一致。在 host 模式下,一个节点最多只能挂载 1 个 Pod。
环境变量配置:设置在容器启动时传入应用进程的键值对,例如:
USER=tester
。数据卷配置:配置容器使用的数据卷,支持本地储存、临时目录(emptydir)、NFS 等多种类型,目前仅支持挂在当前容器所在宿主机的目录。
健康检查配置:包含两种检查机制:Readiness 和 Liveness。具体参见 Kubernetes Probe。
生命周期事件回调配置:为容器添加生命周期事件回调,分别在容器启动后和容器停止前执行。
日志服务配置:配置日志服务(SLS),可选择已有日志库或创建新的日志库。
更多信息参见 高级配置。
配置覆盖
默认关闭。如果开启,需要完成以下选项配置。
环境变量配置:您可以为每个部署单元单独设置环境变量,覆盖应用服务中的默认配置,但仅针对于手动输入类型的环境变量。
镜像地址:您可以为每个部署单元单独配置不同的镜像地址,覆盖应用服务中的默认配置。
三、弹性配置
副本伸缩策略配置:支持以下两种弹性策略。
固定副本数:默认为 0,可勾选部署单元并修改为期望副本数,即应用服务运行时保持固定数目的 Pod 副本。
弹性扩缩容:可对应用服务自动伸缩进行如下弹性规则配置。
固定副本数:默认为 0,可勾选部署单元并修改为期望副本数。
最小副本数:弹性扩缩容时 Pod 的最小副本数。
最大副本数:弹性扩缩容时 Pod 的最大副本数。
规则:当前伸缩规则基于的指标类型。单击 + 添加配置,配置以下选项。
规则类型:当前伸缩规则基于的规则类型,目前支持 CPU、Memory、QPS、响应时间。
目标类型:当前伸缩规则基于的指标类型所期望达到的值的类型,目前支持 使用率 与 平均资源使用。
使用率/平均值:输入使用率/平均值。
单位:无需输入,根据所选的规则类型自动匹配。
高级配置:默认关闭 。如果开启,需要完成以下选项配置。
幅度:可以通过设置按百分比或指定个数来调整扩缩容的速率,单位为百分比或个数。
间隔时间:上次扩缩容操作与本次扩缩容操作之间的时间间隔,单位为秒。
冷却时间:冷却扩缩容操作的时间,即完成一次扩缩容操作之后不再次触发扩缩容操作的时间窗口,单位为秒。
说明一个扩缩容活动执行完成后,在设定的冷却时间内不执行其他扩缩容活动。
四、访问配置(选填)
应用服务支持统一接入及负载均衡两种访问方式。负载均衡是基于端口的请求负载均衡,统一接入是基于规则的请求负载均衡。您可以根据业务需要做好规划。
负载均衡
您可以在创建应用服务时设置访问方式,也可以应用服务创建完成后添加访问方式。
创建应用服务时设置访问方式
在 访问配置 页面,单击 添加负载均衡。
在 负载均衡 配置中,填写以下信息后,单击 下一步。
负载均衡名称:填写服务名称。系统默认生成服务名称前缀为
应用服务名称-
。服务名称允许包含(小写)字母、数字、连字符且必须以字母开头、以字母或者数字结尾。访问方式:选择负载均衡服务的访问方式。支持以下选项:
内网:创建一个内网的 LoadBalancer,并将流量转发到容器的相应端口上。
外网:创建一个公网的 LoadBalancer,并将流量转发到容器的相应端口上。访问方式由公网负载均衡服务地址以及设置的访问端口组成,例如
10.117.117.117:80
。自定义:在自定义模式下,会在选定的部署单元内分别创建一个 LoadBalancer 类型的 Service,通过用户填入的 ID 复用已有的负载均衡实例。
重要当前仅支持填入阿里云负载均衡实例 ID。更多合作伙伴型号支持,敬请期待。
阿里云场景下,被复用的 SLB 必须要满足如下条件:
确保被复用的 SLB 实例是在 SLB 控制台手动创建的。
确保期望使用的监听器端口尚未被占用。
如果是内网地址类型的 SLB 实例,须确保与部署单元对应的集群同属于同一个 VPC。
是否开启集群内访问VIP转发优化:开启后,集群内访问负载均衡 VIP 的请求会被 kube-proxy 直接转发至相应的后端服务。
部署单元 ID:仅当访问方式选择 自定义 时显示该此选项。为各部署单元填写对应的负载均衡实例 ID。
说明对于同一应用服务下的不同部署单元,支持设置相同的负载均衡实例 ID。
确保应用服务端口映射中配置的前端端口在已有负载均衡实例上尚未被其他应用服务占用,否则会因端口冲突而导致应用服务发布失败。
联邦负载均衡实例:仅当访问方式选择 内网 或 外网 且开启 使用联邦负载均衡 时显示该此选项。从下拉列表中选择对应联邦负载均衡实例,可选择到的联邦负载均衡的部署单元必须能够覆盖应用服务 弹性配置 步骤中选择的所有部署单元。
是否开启优雅下线等待:开启后,在后端服务器流量权重清零后,系统会等待一段时间再从负载均衡后端服务器列表中摘除。
优雅下线等待时间 (单位:秒):开启 是否开启优雅下线等待 后可见,配置优雅下线等待时间。
端口映射:单击 添加端口映射,填写以下信息。
协议:支持 TCP、HTTP、HTTPS 协议。
转发规则:制定端口转发规则。
HTTP/HTTPS 协议支持 RR 轮询、WRR 加权轮询、WLC 最小连接数。
TCP 协议支持 RR 轮询、WRR 加权轮询、WLC 最小连接数、TCH 一致性哈希(四元组)、SCH 一致性哈希(源 IP)。
说明一致性哈希(四元组):基于四元组的一致性 hash(源 IP + 目的 IP + 源端口 + 目的端口),相同四元组的请求会调度到相同的后端服务器。
一致性哈希(源 IP):基于源 IP 地址的一致性 hash,相同源地址的请求会调度到相同的后端服务器。
前端端口:容器镜像中工作负载实际监听的端口,端口范围为 1~65535。
后端端口:容器端口映射到负载均衡实例上的端口,用负载均衡 IP 访问工作负载时使用,端口范围为 1~65535。
带宽:单位为 Mbps,默认值为 -1,表示无限制。支持 -1 或 1~5120 范围内的整数。
证书ID:当协议为 HTTPS 类型时,需要输入相关证书 ID。
连接请求超时时间:HTTP/HTTPS 监听请求超时时间,单位为秒,默认 60。如果一个请求的后端服务返回时间超出了设置的超时时间,负载均衡将放弃等待,直接返回 504 给客户端。
HTTP 健康检查:当协议为 HTTPS 或 HTTP 类型时,可开启此选项,HTTP 模式的健康检查是通过发送 HEAD 或 GET 请求模拟浏览器的访问行为来检查后端 Pod 是否健康。若开启,需填写以下的配置项。
说明TCP 端口默认开启 TCP 健康检查,此处可按需开启额外 HTTP 健康检查。
URL:指定具体的检查路径。
域名:非必填。如果您的应用 Pod 需要校验请求的 host 字段,则需要配置相关域名,确保健康检查正常工作。若在健康检查中配置了域名,SLB 会将域名配置到 host 字段中去;反之,如果没有配置域名,SLB 则不会在请求中附带 host 字段,因此健康检查请求就会被服务器拒绝,可能导致健康检查失败。
端口:健康检查服务访问后端 Pod 时的探测端口。端口范围 1~65535。
超时时间(s):接收响应需要等待的时间。如果后端 Pod 在指定的时间内没有正确响应,则判定为健康检查失败。默认为 3 秒。
时间间隔(s):负载均衡的健康检查请求进行健康检查的时间间隔。默认值为 5 秒。
http 健康状态码:选择健康检查正常的 HTTP 状态码。默认值为 http_2xx。
会话保持:开启会话保持后,负载均衡监听会把来自同一客户端的访问请求分发到同一台后端 Pod 上。
HTTP 协议会话保持基于 Cookie。负载均衡提供了两种 Cookie 处理方式:
植入 Cookie:您只需要指定 Cookie 的过期时间。客户端第一次访问时,负载均衡会在返回请求中植入Cookie(即在 HTTP 或 HTTPS 响应报文中插入 SERVERID),下次客户端携带此 Cookie 访问,负载均衡服务会将请求定向转发给之前记录到的后端服务器上。
重写 Cookie:可以根据需要指定 HTTPS 或 HTTP 响应中插入的 Cookie。您需要在后端 Pod 上维护该 Cookie 的过期时间和生存时间。
负载均衡服务发现用户自定义了 Cookie,将会对原来的 Cookie 进行重写,下次客户端携带新的 Cookie 访问,负载均衡服务会将请求定向转发给之前记录到的后端 Pod。详情请参见 会话保持规则配置。
访问控制:开启后,支持以黑白名单的方式对访问 IP 进行过滤。
说明在使用访问控制功能前,您需要在阿里云负载均衡控制台创建访问控制策略组,如何创建请参见 创建访问控制策略组。
在使用访问控制功能前,是否开启集群内访问VIP转发优化 按钮需为关闭状态。
针对 HTTP 和 HTTPS 协议,默认开启 XForwardFor 选项,通过 X-Forwarded-For 获取客户端真实 IP。
访问控制策略类型:选择 黑名单 或 白名单,禁止或允许特定 IP 访问负载均衡。
访问控制组 ID:输入在阿里云负载均衡控制台创建的访问控制策略组 ID。
统一接入
统一接入 支持配置转发规则,将流量转发到容器的相应端口上。您可以在创建应用服务时设置访问方式,也可以应用服务创建完成后添加访问方式。
创建应用服务时添加访问方式
在 访问配置 页面,单击 添加统一接入,填写以下信息后,单击 下一步。
服务名称:填写服务名称。系统默认生成服务名称前缀为
应用服务名称-
。服务名称允许包含(小写)字母、数字、连字符、且必须以字母开头、以字母或者数字结尾。所属统一接入实例:选择已创建的统一接入实例。详情参见 创建统一接入实例。
接入协议:选择统一接入实例上支持的协议,一般有 HTTP 或 HTTPS。
路由模式:选择 单元化 或 非单元化。
单元化 代表为这个统一接入开启单元化转发的能力,即会根据请求 Cookie 内的特定 UID 进行单元化切片,每个 Zone 处理固定区间的用户请求。
非单元化 代表随机分发。
统一接入规则:单击 添加统一接入规则 转发规则,填写以下信息。
域名:填写需要转发的请求域名。
转发路径:请求转发到的具体容器路径地址。默认为根目录。
后端端口:容器镜像中工作负载程序实际监听的端口,端口范围为 1~65535。
重要添加或删除已有转发规则都会导致发布时线上服务不可用。
是否开启健康检查:健康检查是通过发送 HEAD 或 GET 请求模拟浏览器的访问行为来检查后端 Pod 是否健康。默认关闭,开启后需配置以下参数:
说明使用统一接入健康检查前需确认当前工作空间组下所有集群内组件 cloud-controller-manager 版本大于等于 1.3.0。
健康检查类型:目前仅支持 HTTP 健康检查类型。
健康检查URI:指定具体的检查路径。
健康阈值:默认值为 1,即健康检查连续成功 1 次后将对应后端服务器视为健康。
不健康阈值:默认值为 5,即健康检查连续失败 5 次后将对应后端服务器视为不健康。
健康检查间隔:健康检查的时间间隔。默认值为 10 秒。
健康检查超时时间:接收响应需要等待的时间。如果后端 Pod 在指定的时间内没有正确响应,则判定为健康检查失败。默认为 3 秒。
健康检查端口:健康检查服务访问后端 Pod 时的探测端口。端口范围 1~65535。
健康检查域名:非必填。如果您的应用 Pod 需要校验请求的 host 字段,则需要配置相关域名,确保健康检查正常工作。若在健康检查中配置了域名,Spanner 会将域名配置到 host 字段中去;反之,如果没有配置域名,Spanner 则不会在请求中附带 host 字段,因此健康检查请求就会被服务器拒绝,可能导致健康检查失败。
健康检查方法:选择以什么类型的请求进行健康检查,支持 HEAD 和 GET 方法。
期望返回码:选择健康检查正常的 HTTP 状态码。默认值为 http_2xx。
会话保持:开启会话保持后,统一接入会把来自同一客户端的访问请求分发到同一台后端 Pod 上。会话保持基于 Cookie,提供了两种 Cookie 处理方式:
说明使用统一接入会话保持需满足以下条件:
仅支持非单元化转发模式下单部署单元使用场景。
当前工作空间组下所有集群内组件 cloud-controller-manager 版本大于等于 1.3.0。
应用服务使用的统一接入实例对应统一接入集群使用的 spanner 镜像版本大于等于 1.3.0。
植入 Cookie:需配置会话保持超时时间。客户端第一次访问时,统一接入会在返回请求中植入Cookie,下次客户端携带此 Cookie 访问,统一接入服务会将请求定向转发给之前记录到的后端服务器上。
重写 Cookie:需指定 HTTP 响应中插入的 Cookie 名称。您需要在后端 Pod 上维护该 Cookie 的过期时间和生存时间。
ClusterIP Service
ClusterIP Service 是通过集群内部的 IP 对外提供服务。服务只能在集群内部被访问,且只有集群内部的节点和 Pod 可访问。
创建应用服务时添加 ClusterIP Service
在 访问配置 页面,单击 添加 ClusterIP Service。
在 ClusterIP Service 配置中,单击 添加端口映射,配置以下信息。
协议:支持 TCP 和 UDP 协议。
前端端口:容器镜像中工作负载实际监听的端口,端口范围为 1~65535。
后端端口:容器端口映射到 ClusterIP Service 上的端口,端口范围为 1~65535。
单击 提交。
Headless Service
Headless Service 对应的每一个 Endpoint,即每一个 Pod,都会有对应的 DNS 域名。配置 Headless Service 名称,这样各 Pod 之间便可以通过域名互相访问。Headless Service 不会分配 Cluster IP,kube-proxy 不会处理此类 Service,但可以通过域名解析访问 Pod。相关操作,请参见 LHC Pod 域名配置。
您可以在创建应用服务时添加 Headless Service 名称,也可以应用服务创建完成后重新编辑应用服务进行添加。添加之后需要发布应用服务才会生效。
创建应用服务时添加 Headless Service
一个应用服务仅支持添加一个 Headless Service 。
在 访问配置 页面,单击 添加 Headless Service。
在 Headless Service 配置中,填写 Headless Service 名称。名称由服务名称前缀、Headless Service 名称组成。
前缀:系统默认生成服务名称前缀
应用服务名称-
。Headless Service 名称:输入名称,允许包含小写字母、数字、连字符(-)。最大长度不超过 20 个字符。
单击 下一步。
五、部署和调度配置(选填)
您可以自定义部署和调度配置,若不修改,发布应用服务时,系统会使用默认配置。
该配置项用于配置容器服务在部署时需要用到的信息,包括以下内容:
是否使用 Beta 验证:发布时选取部分 Pod 先行发布,待确认无异常后继续发布。默认开启。
开启 Beta 分组后,发布时会给应用服务设置一个特殊的 Beta 分组,在该组中,系统会在每个部署单元选择一个 Pod,Beta 分组会在第一组发布。
Beta 分组发布完成后系统会自动暂停应用服务发布,等待系统负责人或者运维工程师对应用服务的发布情况进行确认。若容器服务发布正常,则单击 Beta 分组确认,使应用服务继续分组发布。
Beta 分组可以与所有分组策略共同决定分组。创建新的发布申请时,默认开启 添加 Beta 分组,此时同一个发布单上的所有应用服务都设置 Beta 分组。
部署分组策略:指定发布容器服务时 Pod 的分组策略,支持以下几种策略,具体可参考下表。
策略类型
说明
按部署单元分组
默认为 按部署单元分组。
按部署单元维度发布,尽可能让 Pod 均匀分布在各部署单元中。
每个 Pod 一组
每组一个 Pod,有几个 Pod 便分几组。
共分一组
所有 Pod 在一组中进行发布。
快速分组
在发布时按照组的维度进行发布。
共分一组(Beta 单元模式)
在发布时按设定的每次最大同时变更 Pod 数量进行发布。选定后,可以根据需要配置以下选项。
最大步长:每个普通分组最大变更 Pod 数(不包含 Beta 分组)。如果将最大步长设为 2,则普通分组的 Pod 数不超过 2。
部署单元发布顺序:
如果不设置部署单元发布顺序,按默认的部署单元顺序对各部署单元的 Pod 进行发布或变更。
如果设置了部署单元发布顺序,按指定顺序对各部署单元的 Pod 进行发布或变更。
是否开启 Beta 验证:
如果未开启,所有 Pod 会依次发布,无 Beta 分组,无分组暂停,即用户不需要确认任何分组,执行完一个普通分组后自动执行下一个分组。
如果开启,部署顺序中的第一个单元会整体作为 Beta 分组进行发布,需要用户确认。其余单元的所有 Pod 会依次发布,这些分组无分组暂停。
说明选择 共分一组(Beta 单元模式)后,在某一时刻可能出现某一部署单元内的 Pod 同时在发布,以致 Pod 不可用的情形。如需规避此现象,即在加快发布进度的同时保证一定 Pod 可用,建议选择 按部署单元百分比并发模式。
按部署单元百分比并发模式
如需加快按部署单元发布进度,可选择该分组策略。选定后,需指定一个百分比值。发布变更时,按每个部署单元该百分比数量的 Pod 为一批。
如果将百分比设为 25%,则第一批发布所有部署单元的前 25% 的 Pod,第二批发布所有部署单元的 25%-50% 的 Pod,以此类推直至 100%,可参考以下示例图。
部署单元发布顺序:仅当分组策略选择 按部署单元分组 或 共分一组(Beta 单元模式)时显示该此选项。默认关闭。用于重新编排原有部署单元发布顺序。开启后,支持通过拖拽操作对部署单元进行排序,便于根据实际业务需要灵活调整发布顺序。
最小分组数:分组策略选择 按部署单元分组 或 快速分组 时需设置。
说明最小分组数是发布时分组的参考值,实际分组数受发布时 Pod 在部署单元的分布情况影响。
分组暂停:支持仅第一个分组或每组暂停发布,待确认发布后继续发布。
全部暂停:默认选中。发布单会在每个分组暂停发布。
首批暂停:选择 首批暂停 后,发布单只会在第一个分组暂停发布。
分组发布模式(并行/串行):默认不选,系统默认模式为准,选中后可以选择并行/串行的分组发布模式。
自定义标签:发布应用服务时,将会以 label 的形式发布在 Pod 上。请以
key=value
的格式输入,多个 label 间用英文逗号分隔。Annotation:发布时,将以 annotation 的形式发布在 Pod 上,请以
key=value
的格式输入,多个 annotation 以英文逗号(,)分隔。自定义属性配置:支持手动配置 Pod 删除宽限期。
Pod拓扑打散约束:通过配置打散调度策略,将 Pod 打散到不同机器上以保证应用服务的高可用。
应用服务与节点亲和性配置:添加应用服务在节点级别的亲和性配置。可以通过 node 标签来限定应用服务可以调度的节点范围。
说明亲和性需要 Pod 重新创建才会生效。首次发布时,亲和性配置一定会生效,后续发布时,必须选择替换升级方式,才能让亲和性配置生效。
应用服务间亲和性配置:添加应用服务在 Pod 级别的亲和性配置。通过选择与某些应用服务在相同或不同的节点来限定应用服务可以调度的节点范围。
说明亲和性需要 Pod 重新创建才会生效。首次发布时,亲和性配置一定会生效,后续发布时,必须选择替换升级方式,才能让亲和性配置生效。
是否摘除注册中心流量:默认关闭,开启后配置摘流后等待时间。
说明集群组件 cloud-controller-manager 版本必须大于等于 1.2.0-pub 才能开启,否则开启后应用服务会发布失败。
应用服务污点容忍配置:配置完成后应用服务将部署到对应污点的节点上。在弹出框中输入 键、值,选择 Effect。Effect 包含以下选项:
NoSchedule:不允许无匹配 toleration 的 Pod 调度到该节点。
NoExecute:若无匹配 toleration 的 Pod 已经在节点上运行,则将 Pod 驱逐,若无匹配 toleration 的 Pod 尚未在节点上运行,则不会将 Pod 调度到该节点上。
PreferNoSchedule:尽量不将无匹配 toleration 的 Pod 调度到该节点。
注入 SOFAMesh:需集群开启 Mesh 功能。开启引流配置时,每次发布会按所设置的引流规则转发流量到新版本,也可在发布过程中配置。开启后,会为应用服务开启服务网格功能,可以在服务网格控制台对应用服务进行管控和治理。
六、预览并提交
在应用服务 预览 页面,确认信息无误,单击 提交。
提交前您可以单击修改图标对应用服务信息进行修改。
应用服务提交后处于 待部署 状态,需要单击 发布 才会将应用服务部署到集群中。