使用AstroZero创建原生服务

操作场景

AstroZero平台提供了创建原生服务工程的能力，原生服务工程本质上起到一种桥接的作用，用于将运行于AstroZero平台之外的原生服务的API集成到AstroZero，使得运行于AstroZero之上的应用，更容易地使用原生服务的API。

开发Native Service前，请先了解整个Native Service的开发流程。

图1 原生服务开发流程图

1. 创建Native Service

   在AstroZero中，您可以在应用设计器中创建原生服务，也可以在环境配置中创建原生服务。

2. 配置Chart

   通过AstroZero提供的图形化界面，配置部署Docker容器时需要的资源、存储和网络等一系列参数。配置后，生成Chart包并进行导出。

3. 配置API

   原生服务旨在帮助您在AstroZero平台上或外部系统，调用已开发好的服务。为了完成调用，需要知道服务开放了哪些接口，以及这些接口的请求参数、返回参数等。API配置后，可在服务编排中进行调用，也可将API再封装为自定义公共接口，供外部系统调用自定义公共接口。

4. 部署Native Service

   配置完API后，还需要执行部署操作，部署完成后才可使用Native Service。

5. 注册Native Service

   注册Native Service后，才可以在AstroZero的其他组件内（如脚本、服务编排等）调用原生服务的接口，也可将该原生服务开放给第三方系统进行访问。

6. 自定义Native Service公共接口

   自定义原生服务的公共接口，将原生服务API发布到外部网关，第三方系统可以通过OAuth2.0调用AstroZero上的原生服务。

7. 导出Native Service给其他用户使用

   服务编排可以成功调用原生服务后，说明整个流程已测通。您可以导出Native Service包给其他用户，其他用户可以在沙箱环境或运行环境中安装该包，以便于使用该软件或进行定制。

创建Native Service

在AstroZero中，您可以在应用设计器中创建原生服务，也可以在环境配置中创建原生服务。下面以在应用设计器中创建原生服务为例进行介绍，如何在环境配置中创建原生服务，请参见注册原生服务。

1. 进入AstroZero服务控制台。
2. 在主页中，单击“进入首页”，进入AstroZero应用开发页面。
3. 在左侧导航栏中，选择“资产”，单击“新建原生服务”或单击。
4. 设置原生服务的基本信息，单击“新建”。
   图2 配置基本信息
   

   表1 新建原生服务参数说明

   参数	说明
   添加图标	单击“添加图标”按钮，可为新建的原生服务添加图标。
   标签	新建原生服务的标签名，用于在页面展示。 取值范围：1~80个字符。
   名称	新建原生服务的名称，名称是原生服务在系统内的唯一标识，创建后不可修改。命名要求如下： 长度范围为1~26个字符，包括前缀命名空间的长度。 说明： 名称前的内容为命名空间，在AstroZero中为了避免不同租户间数据的重名，租户在首次创建应用时需要先定义一个命名空间。一个租户只能创建一个命名空间，创建后不支持修改。 必须以英文字母开头，只能由英文字母、数字或单下划线组成，且不允许以下划线结尾。
   分类	原生服务所属的分类，直接下拉框中选择。
   标志	新建原生服务在分类下，展示的图标。
   描述	请根据需求，在输入框中输入对该原生服务的描述信息。 取值范围：1~255个字符。
   高级设置 > 运行时版本	开发的资产包依赖所选择的运行时版本，如果线下运行版本不一致，可能会导致不兼容。

配置Chart

通过AstroZero提供的图形化界面，配置部署Docker容器时需要的资源、存储和网络等一系列参数。配置后，生成Chart包并进行导出。导出后，可通过云容器引擎（Cloud Container Engine，简称CCE），在其他平台上部署安装Docker容器。

1. 在创建Native Service中创建的原生服务配置页面，选择“导航”。
   图3 选择导航
   

2. 在右侧“Chart设计”页签，单击“新建”。

   创建Chart有两种方式，一种是在界面单击“新建”手动创建，另一种是单击“导入”，选择已配置好的Chart包直接导入。本章节以手动创建方式为例，进行介绍。

3. 配置Chart名称和版本号，单击“确定”，进入该Chart图形化设计页面。
4. 在Chart图形化设计页面，单击“+”，创建一组资源，该资源包括网络、配置、服务和计算。
   图4 单击加号
   

   创建后界面显示，如图5所示。

   图5 Chart设计界面
   

5. 单击Chart图形化设计页面上方的，进入全局配置页面。
6. 在全局配置中，单击“新增行”，将业务的配置项文件内容设置为全局变量，单击“确认”。

   执行此操作，可避免因为参数变更时，修改并重新生成Chart包。

   图6 全局配置
   

7. 从页面左侧“配置”中，拖拽“ConfigMap”元素至页面右侧的配置区域（界面中会显示，将元素拖入中）。
   图7 拖拽“ConfigMap”元素
   

8. 选中ConfigMap元素，单击鼠标右键选择“配置”，设置ConfigMap。
   图8 ConfigMap配置页面
   
   • 基本信息
     • 名称：新建配置项的名称，同一个命名空间中命名必须唯一。
     • 描述：配置项的描述信息。
   • 配置数据：工作负载中配置的数据，可在容器中使用，或被用来存储配置数据。单击“新增行”，可添加配置数据。
     • 键：配置项文件名。
     • 值：文件中的内容。单击值中的，选择6中创建的全局变量。建议将配置文件内容定义为全局变量，可避免因为文件内容变更时，修改并重新生成Chart包。
   • 注解：单击“新增行”，可以使用Kubernetes注解为对象附加任意的非标识的元数据。注解中的元数据，可以很小，也可以很大，可以是结构化的，也可以是非结构化的，能够包含标签不允许的字符。注解存储的形式是键/值对。

9. 从页面左侧“计算”中，拖拽“无状态负载”元素至页面右侧的计算区域中（界面中会显示，将元素拖入中）。
   图9 拖入计算元素
   

10. 选中拖入的“无状态负载”元素，单击鼠标右键选择“配置”，在页面右侧区域进行配置。
    • 基础信息
      • 名称：新建工作负载的名称，命名必须唯一。
      • 实例数量：工作负载的实例（Pod）数量。工作负载可以有一个或多个实例，用户可以设置具体实例个数。每个无状态负载实例都由相同的容器部署而成。设置多个实例主要用于实现高可靠性，当某个实例故障时，工作负载还能正常运行。如果使用单实例，节点异常或实例异常会导致服务异常。
      • 升级策略：工作负载的升级策略。

        从下拉列表中选择“RollingUpdate”，表示执行滚动更新策略。用户希望应用程序始终可用，当开发人员线下开发新版本的应用程序时，在Kubernetes中，可以通过滚动更新来完成更新升级。 “RollingUpdate”允许通过使用新的实例逐步更新旧的Pod实例，零停机进行整个“无状态负载”或“有状态负载”更新。新Pod将在具有可用资源的节点上，进行调度。

      • 最大增量：当“升级策略”配置为“RollingUpdate”时，才会显示该参数。表示进行滚动更新（RollingUpdate）时，新实例每次替换旧的Pod实例的最大数。
      • 最大不可用：当“升级策略”配置为“RollingUpdate”时，才会显示该参数。表示进行滚动更新（RollingUpdate）时，最大不可用的Pod实例数。
      • 拉取镜像的密钥名称：在同一命名空间中，用于拉取容器镜像的密钥名称列表。多个密钥名称之间，用英文逗号隔开。
        • 如果需要拉取CCE华为云容器的镜像仓库的镜像，参数值固定为“default-secret”。CCE中容器拉取镜像时，使用密钥认证方式。
        • 如果需要拉取第三方镜像仓库的镜像时，配置为创建的密钥，创建方法请参考使用第三方镜像。

        您也可以单击参数后的，单击“增加全局配置”，将拉取镜像的密钥配置为全局变量，以参数名和值的方式定义变量，后续在修改该密钥时，只需要修改全局变量即可。

      • 描述：工作负载的描述信息。
    • 容器配置：容器与虚拟机类似，具有自己的文件系统、CPU、内存和进程空间等，单击“配置”，参考表2配置容器的属性。
      图10 容器配置
      
      图11 复制CCE中镜像地址
      
      图12 镜像地址全局变量配置
      

      表2 容器配置参数说明

      页签	参数	说明
      基本信息	容器名称	容器的名称。
      	镜像地址	镜像的地址，取值说明如下： 如果需要拉取CCE镜像仓库的镜像，请登录CCE控制台，在左侧导航栏中选择“镜像仓库 > 镜像管理”，根据需要选择“自有镜像”或“公开镜像”（“自有镜像”为该租户自有的镜像，“公开镜像”页签的镜像所有用户都可以下载使用）。单击需要使用的镜像名，进入镜像详情页面，如图11所示。单击“下载指令”列后的，即可获取。 在此处粘贴获取的值时，需要去掉粘贴内容中的“docker pull”，只保留后面部分 。例如，镜像地址配置为“10.10.10.1/bingodev/testoauth:fifth”。 如果需要拉取第三方镜像仓库的镜像，请直接输入第三方镜像仓库的镜像地址，例如“www.3rdregistry.com”或“10.10.10.10:443”。 您也可以单击参数后的，单击“增加全局配置”，如图12所示，将镜像地址配置为全局变量。后续在修改镜像地址时，只需要修改全局变量即可，建议使用全局变量方式，设置镜像地址。
      	镜像拉取策略	从镜像仓库中，下载镜像的策略。 Always：总是从仓库下载镜像。 IfNotPresent ：如果本地没有，则从仓库下载镜像。 Never：总是使用本地的镜像。
      	申请/Cores	容器需要使用的最小CPU值，作为容器调度时资源分配的判断依赖。只有当节点上可分配CPU总量 ≥ 容器CPU申请数时，才允许将容器调度到该节点。
      	限制/Cores	允许容器使用的CPU最大值。建议设容器配额的最高限额，避免容器资源超额，导致系统故障。
      	申请/Mi	容器需要使用的内存最小值，作为容器调度时资源分配的判断依赖。只有当节点上可分配内存总量 ≥ 容器内存申请数时，才允许将容器调度到该节点。
      	限制/Mi	允许容器使用的内存最大值。如果超过，容器会被终止。
      环境变量	变量名称	在容器中添加环境变量，一般用于通过环境变量设置参数。 在 “环境变量”页签，单击 “新增行”，可进行配置。
      	变量/变量引用	选择变量或变量引用。您也可以单击参数后的，单击“增加全局配置”，将变量/变量引用配置为全局变量。
      数据存储	-	给容器挂载数据存储，支持本地磁盘和云存储，适用于需持久化存储、高磁盘IO等场景。 单击“新增行”进行添加，可选项。
      	本地存储	通过本地磁盘存储将容器所在宿主机的文件目录挂载到容器的指定路径中，也可以不填写源路径。参数如下： 名称：容器所在宿主机的文件目录名。 本地路径：请输入本地路径。 子路径：请输入子路径。 挂载路径：请输入挂载路径。
      	云存储	为满足数据的持久化需求，CCE支持将云硬盘（EVS）挂载到容器中。通过云硬盘，可以将存储系统的远端文件目录挂载到容器中，数据库逻辑卷中的数据将被永久保存，即使删除了容器，数据库逻辑卷中的数据依然保存在存储系统中。参数如下： 名称：云硬盘名。 PVC：新建PVC的名称，PVC创建时将自动创建存储卷，一个PVC对应一个存储卷。存储卷名称在PVC创建时自动生成。 子路径：请输入子路径。 挂载路径：请输入挂载路径。
      	ConfigMap	用于把7~8中配置的ConfigMap挂载到容器内。 名称：ConfigMap的名称。 子路径：系统支持挂载ConfigMap中部分配置项文件。如果只需要挂载部分配置项文件，这里“子路径”配置为要挂载的具体配置项文件名。即8中配置ConfigMap时，配置数据中的“键”如果若需要挂载ConfigMap的所有配置项文件，则不需要配置“子路径”。 挂载路径：请输入挂载路径。当子路径不配置时，请确保挂载路径为空文件夹。 权限：设置ConfigMap挂载文件的权限，例如设置为777，表示所有人具有可读可写可执行权限（即rwxrwxrwx）。 将ConfigMap中部分配置项文件挂载到容器中，即配置了子路径时，部署Chart的容器将不会收到ConfigMap的更新。如果将ConfigMap中全部配置项文件挂载到容器中，即不配置子路径时， 部署Chart的容器将会收到ConfigMap的更新，此时挂载路径应该是一个空的文件夹，否则ConfigMap更新时，挂载路径里面的文件会被删除。
      	Secret	如果之前配置了Secret，则需要把配置的Secret挂载到容器内。非必填。参数说明如下： 名称：Secret的名称。 子路径：系统支持挂载Secret中部分配置项文件。如果只需要挂载部分配置项文件，这里“子路径”配置为要挂载的具体配置项文件名。即Secret中配置数据中的“键”。如果需要挂载Secret的所有配置项文件，则不需要配置“子路径”。 挂载路径：请输入挂载路径。 权限：设置Secret挂载文件的权限，例如设置为777，表示所有人具有可读可写可执行权限（即rwxrwxrwx）。 将Secret中部分配置项文件挂载到容器中，即配置了子路径时，部署Chart的容器将不会收到Secret的更新。如果将Secret中全部配置项文件挂载到容器中，即不配置子路径时， 部署Chart的容器将会收到Secret的更新，此时挂载路径应该是一个空的文件夹，否则Secret更新时，挂载路径里面的文件会被删除。
      生命周期（设置容器启动和运行时，需要执行的命令）	启动命令/运行命令	设置容器启动时执行的命令，控制镜像运行的实际命令。
      	启动命令/运行参数	传递给运行命令的参数。
      	启动后处理/检查方式	设置容器成功运行后，执行的命令。 执行命令检查：在容器中执行指定的命令，配置为需要执行的命令。命令的格式为Command Args[1] Args[2]…（Command为系统命令或者用户自定义可执行程序，如果未指定路径则在默认路径下寻找可执行程序），如果需要执行多条命令，建议采用将命令写入脚本执行的方式。 HTTP请求检查：发起一个HTTP调用请求。 路径：请求的URL路径。 端口：请求的端口。 主机地址：请求的IP地址，默认是容器所在的节点IP。
      	停止前处理/检查方式	设置容器结束前执行的命令，通常用于删除日志/临时文件等。分为以下两种： 执行命令检查：在容器中执行指定的命令，配置为需要执行的命令。命令的格式为Command Args[1] Args[2]…（Command为系统命令或者用户自定义可执行程序，如果未指定路径则在默认路径下寻找可执行程序），如果需要执行多条命令，建议采用将命令写入脚本执行的方式。 HTTP请求检查：发起一个HTTP调用请求。 路径：请求的URL路径。 端口：请求的端口。 主机地址：请求的IP地址，默认是容器所在的节点IP。
      健康检查（容器运行过程中，根据用户需要，定时检查容器健康状况。如果不配置健康检查，如果服务出现业务异常，pod将无法感知，也不会自动重启去恢复业务。最终导致pod状态正常，但pod中的业务异常的情况）	工作负载存活探针	用于检测容器是否正常，类似于执行ps命令，检查进程是否存在。如果容器的存活检查失败，集群会对该容器执行重启操作。如果容器的存活检查成功，则不执行任何操作。 HTTP请求检查 HTTP请求方式针对的是提供HTTP/HTTPS服务的容器，集群周期性地对该容器发起HTTP/HTTPS GET请求。如果HTTP/HTTPS response返回码属于200~399范围，则证明探测成功，否则探测失败。使用HTTP请求探测，必须指定容器监听的端口和HTTP/HTTPS的请求路径。 例如，提供HTTP服务的容器，端口为80，HTTP检查路径为“/health-check”，主机地址为containerIP，那么集群会周期性地对容器发起如下请求GET http://containerIP:80/health-check。 TCP端口检查 对于提供TCP通信服务的容器，集群周期性地对该容器建立TCP连接。如果连接成功，则证明探测成功，否则探测失败。选择TCP端口探测方式，必须指定容器监听的端口。例如，有一个nginx容器，服务端口是80，对该容器配置了TCP端口探测，指定探测端口为80，那么集群会周期性地对该容器的80端口发起TCP连接，如果连接成功则证明检查成功，否则检查失败。 执行命令检查 命令检查是一种强大的检查方式，该方式要求用户指定一个容器内的可执行命令，集群会周期性地在容器内执行该命令，如果命令的返回结果是0，则检查成功，否则检查失败。 对于上面提到的TCP端口检查和HTTP请求检查，都可以通过执行命令检查的方式来替代： 对于TCP端口探测，可以写一个程序来对容器的端口进行connect。如果connect成功，脚本返回0，否则返回-1。 对于HTTP请求探测，可以写一个脚本来对容器进行wget。 上述三种检查方式的公共参数说明如下： 延迟时间：延迟检查时间，单位为秒，此设置与业务程序正常启动时间相关。例如，设置为30，表明容器启动后30秒，才开始健康检查。该时间是预留给业务程序启动的时间。 超时时间：超时等待时间，单位为秒。例如，设置为10，表明执行健康检查的超时等待时间为10秒，如果超过这个时间，本次健康检查会被视为失败。如果设置为0或不设置，默认超时等待时间为1秒。
      	工作负载业务探针	检查用户业务是否就绪，不就绪则不转发流量到当前实例。一些程序的启动时间可能很长，比如要加载磁盘数据或者要依赖外部的某个模块启动完成，才能提供服务。这时候程序进程在，但是并不能对外提供服务。这种场景下该检查方式非常有用。如果容器的就绪检查失败，集群会屏蔽请求访问该容器。如果检查成功，则会开放对该容器的访问。检查方法和配置请参考“工作负载存活探针”。
      容器日志（支持用户进行容器日志配置，仅在华为云上可用。日志文件内容，由采集器上报到AOM进行统一管理）	主机路径	日志文件在主机上保存的路径。
      	挂载路径	日志文件挂载到容器上的路径。 请不要挂载到系统目录下，如“/”、“/var/run”等，可能会导致容器异常。
      	采集路径	采集路径是基于挂载路径的扩展功能，设置采集路径可以更精确的指定采集内容。当前支持以下设置方式： 不设置：默认采集当前路径下的“.log”、“.trace”和“.out”文件。 设置**：表示递归采集5层目录下的“.log”、“.trace”和“.out”文件。 设置*：表示模糊匹配。 例如， 采集路径为/tmp/**/test*.log，表示采集“/tmp”目录及其1-5层子目录下，以test开头的全部“.log”文件。 使用采集路径功能，请确认采集器ICAgent版本为5.12.22或以上版本。
      	主机扩展路径	通过实例ID或容器名称，扩展主机路径，实现同一个主机路径下区分来自不同容器的挂载。

11. （可选）选中拖入的无状态负载元素，单击，设置调度策略。
    • 节点亲和：是指可以根据节点上的标签，来约束Pod只能或优先调度到哪些节点上。Kubernetes目前两种类型的节点亲和，一种是Pod调度到的节点必须满足一定规则，即“requiredDuringSchedulingIgnoredDuringExecution”。另一种是将Pod优先调度到一些满足规则的节点，如果不满足要求，则可以将Pod调度到其他节点，即“preferredDuringSchedulingIgnoredDuringExecution”。AstroZero目前两种类型都支持，两种类型的节点亲和有一个共同点，即如果节点的标签在运行时发生变更，从而不再满足Pod上的亲和规则，但是Pod将仍然继续在该节点上运行。
      • 必须满足原则：“必须满足原则”对应kubernetes的“requiredDuringSchedulingIgnoredDuringExecution”，是指定将Pod调度到某节点上，必须满足的规则，不存在Pod被调度到其他节点的可能性。例如，按照组网规划，Datatool服务的宿主机是固定的，因此，调度策略应该使用“必须满足原则”。

        单击“添加”，可添加多个条件卡片。在条件卡片中，单击“新增行”，可定义规则。在一个条件卡片中，可以添加多条规则，可定义多个条件卡片。其中，任意条件卡片中，多条规则必须都要满足的节点才会被调度。

        单击“添加”，再单击“新增行”后，界面会出现“键”（节点标签键）、“操作符”和“值”（节点标签值），组合起来便是规则表达式。其中，“操作符”可以设置六种匹配关系（In、NotIn、Exists、DoesNotExist、Gt、和Lt）。In和NotIn操作符可以添加单个值或多个值（多值使用“,”进行分隔），Exists和DoesNotExist判断某个标签是否存在，不需设置值。Gt和Lt判断标签的值大于或小于某个值（值要求整数）。

        

        如果节点的标签在运行时发生变更，从而不再满足Pod上的亲和规则，但是Pod将仍然继续在该节点上运行。

      • 尽量满足原则：“尽量满足原则”对应kubernetes的“preferredDuringSchedulingIgnoredDuringExecution”，是指将Pod优先调度到一些满足规则的节点。如果不满足要求，则可以将Pod调度到其他节点。即存在被调度器调度到其他节点的可能性。

        单击“添加”，可添加多个条件卡片。在条件卡片中，单击“新增行”，可定义规则。在一个条件卡片中，可添加多条规则，可定义多个条件卡片。其中，任意条件卡片中，多条规则必须都要满足的节点，才会被优先调度。满足条件后，“权重”值（值范围为1~100）总和越高的节点，越会被优先调度。

        单击“添加”，再单击“新增行”后，界面会出现“键”（节点标签键）、“操作符”和“值”（节点标签值），组合起来便是规则表达式。其中，“操作符”可以设置六种匹配关系（In、NotIn、Exists、DoesNotExist、Gt和Lt）。In和NotIn操作符可以添加单个值或多个值（多值使用“,”进行划分），Exists和DoesNotExist判断某个标签是否存在，不需设置值。Gt和Lt判断标签的值大于或小于某个值（值要求整数）。

        

        如果节点的标签在运行时发生变更，从而不再满足Pod上的亲和规则，但是Pod将仍然继续在该节点上运行。

        配置示例：如图13所示，节点亲和“必须满足原则”中配置“kubernetes.io/e2e-az-name In e2e-az1,e2e-az2”，“尽量满足原则”中配置“another-node-label-key In another-node-label-value”。此节点亲和性规则表示，Pod只能放置在具有标签键“kubernetes.io/e2e-az-name”且标签值为“e2e-az1”或“e2e-az2”的节点上。 另外，在满足这些标准的节点中，具有标签键为“another-node-label-key”且标签值为“another-node-label-value”的节点应该被优先使用。一个节点可能有多个标签，即多个标签键值。

        图13 节点亲和配置示例
        
    • Pod亲和：Pod间亲和性与反亲和性是指基于已经在节点上运行的Pod标签，来约束Pod可以调度到的节点，而不是基于节点上的标签。 即规则为“如果X节点上已经运行了一个或多个满足规则Y的Pod， 则这个Pod在亲和情况下，应该（或者在反亲和的情况下不应该）运行在X节点”。Y表示一个具有可选的关联命名空间列表的LabelSelector。与节点不同，Pod是命名空间限定的（因此Pod上的标签也是命名空间限定的），因此作用于Pod标签的标签选择算符，必须指定选择算符应用在哪个命名空间。 从概念上讲，X是一个拓扑域，如节点、机架、云供应商可用区、云供应商地理区域等。 您可以使用topologyKey来表示它，topologyKey是节点标签的键，以便系统用来表示这样的拓扑域。

      与节点亲和性一样，当前有两种类型的Pod亲和性与反亲和性，即“requiredDuringSchedulingIgnoredDuringExecution”和“preferredDuringSchedulingIgnoredDuringExecution”，请参阅前面节点亲和性部分中的描述。 亲和性的一个示例是“将服务A和服务B的Pod放置在同一区域，因为它们之间需要进行大量交流”，而反亲和性的示例将是“将此服务的pod跨区域分布”。

      

      Pod间亲和性与反亲和性需要大量的处理，这可能会显著减慢大规模集群中的调度。 不建议在超过数百个节点的集群中使用它们。

      • 必须满足原则：“必须满足原则”对应kubernetes的“requiredDuringSchedulingIgnoredDuringExecution”，是指定将Pod调度到某节点上必须满足的规则，不存在Pod被调度到其他节点的可能性。

        单击“添加”，可添加多个条件卡片。在条件卡片中，单击“新增行”，可定义规则。在一个条件卡片中，可添加多条规则，可定义多个条件卡片。其中，任意条件卡片中，多条规则必须都要满足的节点才会被调度。

        • 拓扑域：节点标签的键，同一标签键取值意味着处于同一拓扑域。当节点标签的键是标准标签键时，可从选项中直接选择，当是自定义的标签键时，直接输入键即可。
        • 命名空间：指定Pod标签所在的命名空间列表，用逗号分隔。为空，则表示为此Pod的命名空间。
        • 再单击“新增行”后，界面会出现“键”（Pod标签键）、“操作符”和“值”（Pod标签值），组合起来便是规则表达式。其中，“操作符”可以设置四种匹配关系（In、NotIn、Exists和DoesNotExist）。In和NotIn操作符可以添加单个值或多个值（多值使用“,”进行划分），Exists和DoesNotExist判断某个标签是否存在，不需设置值。
        

        如果节点的标签在运行时发生变更，从而不再满足Pod上的亲和规则，但是Pod将仍然继续在该节点上运行。

      • 尽量满足原则：“尽量满足原则”对应Kubernetes的“preferredDuringSchedulingIgnoredDuringExecution”，是指将Pod优先调度到一些满足规则的节点。如果不满足要求，则可以将Pod调度到其他节点。即存在被调度器调度到其他节点的可能性。

        单击“添加”，可添加多个条件卡片。在条件卡片中，单击“新增行”，可定义规则。在一个条件卡片中，可添加多条规则，可定义多个条件卡片。其中，任意条件卡片中，多条规则必须都要满足的节点才会被优先调度。满足条件后，“权重”值（值范围为1~100）总和越高的节点，越会被优先调度。

        • 拓扑域：节点标签的键，同一标签键取值意味着处于同一拓扑域。当节点标签的键是标准标签键时，可从选项中直接选择。当是自定义的标签键时，直接输入键即可。
        • 命名空间：指定Pod标签所在的命名空间列表，用逗号分隔。为空，则表示为此Pod的命名空间。
        • 再单击“新增行”后，界面会出现“键”（Pod标签键）、“操作符”和“值”（Pod标签值），组合起来便是规则表达式。其中，“操作符”可以设置四种匹配关系（In、NotIn、Exists和DoesNotExist）。In和NotIn操作符可以添加单个值或多个值（多值使用“,”进行划分），Exists和DoesNotExist判断某个标签是否存在，不需设置值。
        

        如果节点的标签在运行时发生变更，从而不再满足Pod上的亲和规则，但是Pod将仍然继续在该节点上运行。

    • Pod反亲和：Pod间亲和性与反亲和性是指基于已经在节点上运行的Pod的标签，来约束Pod可以调度到的节点，而不是基于节点上的标签。 即规则为“如果X节点上已经运行了一个或多个满足规则Y的Pod， 则这个Pod在反亲和的情况下不应该运行在X节点”。
      • 必须满足原则：“必须满足原则”对应kubernetes的“requiredDuringSchedulingIgnoredDuringExecution”，是指定将Pod不应该调度到某节点上必须满足的规则。
      • 尽量满足原则：“尽量满足原则”对应kubernetes的“preferredDuringSchedulingIgnoredDuringExecution”，是指将Pod尽量不要调度到某节点上。

        配置示例：如图14所示，Pod亲和“必须满足原则”中配置“security In S1”，Pod反亲和“尽量满足原则”中配置“security In S2”，拓扑域都配置为“topology.kubernetes.io/zone”。此规则组合起来配置了一条Pod亲和性规则和一条Pod反亲和性规则。Pod亲和性规则表示，仅当节点和至少一个已运行且有键为“security”值为“S1”的标签的Pod处于同一区域时，才可以将新Pod调度到节点上。Pod反亲和性规则表示，如果节点处于Pod所在的同一可用区且已运行具有键为“security”和值为“S2”的标签的Pod，则新Pod尽量不要调度到该节点所在可用区内。

        图14 Pod亲和与反亲和配置示例
        
    • 容忍度：节点亲和性是Pod的一种属性，使Pod被吸引到一类特定的节点上。 这可能出于一种偏好（即优先调度“尽量满足原则”），也可能是硬性要求（即“必须满足原则”）。污点则相反，它使节点能够排斥一类特定的Pod。

      容忍度是应用于Pod上的，允许（但并不要求）Pod调度到带有与之匹配的污点的节点上。污点和容忍度是相互配合的，可以用来避免Pod被分配到不合适的节点上。 每个节点上都可以设置一个或多个污点，这表示对于那些不能容忍这些污点的Pod，是不会被该节点接受的。

      例如，用户希望把Master节点保留给Kubernetes系统组件使用，或者把一组具有特殊资源预留给某些Pod，则污点就很有用了，Pod不会再被调度到设置了污点的节点。

      • 键：选择器适用的标签键。如果键为空，操作符必须为“Exists”，表示这个容忍度能容忍任意污点。
      • 操作符：表示键与一组值的关系。有效的运算符为“Exists”或“Equal”。
      • 值：如果操作符为“Exists”，值必须为空。如果操作符为“Equal”，值必须要设置。
      • 效果
        • NoSchedule：表示不会被调度到污点节点上去。
        • PreferNoSchedule：表示尽量不调度到污点节点上去。
        • NoExecute：表示一旦污点生效，如该节点内正在运行的Pod没有对应容忍度设置，则会直接被逐出。
      • 容忍时间：可容忍时间，单位为秒。仅当效果为“NoExecute”时生效。默认不设置，意味着永久容忍。

      配置示例：如果使用命令“kubectl taint nodes node1 key1=value1:NoSchedule”某节点node1增加一个污点，键是“key1”，操作符是“Equal”，值是“value1”，效果是“NoSchedule”。 如果需要该Pod运行在node1节点，则需要按照图15或图16所示进行配置，配置Pod容忍度为“key1 Equal value1 NoSchedule”或“key1 Exists NoSchedule”，则该Pod拥有和这个污点相匹配的容忍度，Pod才能够被分配到node1这个节点。

      图15 容忍度配置示例1
      
      图16 容忍度配置示例2
      

      您可以给一个节点添加多个污点，也可以给一个Pod添加多个容忍度设置。 系统处理多个污点和容忍度的过程就像一个过滤器，即从一个节点的所有污点开始遍历， 过滤掉那些Pod中存在与之相匹配的容忍度的污点，余下未被过滤的污点的效果值决定了Pod是否会被分配到该节点。再举个复杂的例子，如果给一个节点添加了如下污点：

      kubectl taint nodes node1 key1=value1:NoSchedule
      kubectl taint nodes node1 key1=value1:NoExecute
      kubectl taint nodes node1 key2=value2:NoSchedule

      然后按照图17，配置了两个容忍度。在这种情况下，该Pod不会被分配到node1节点，因为其没有容忍度和第三个污点“key2=value2:NoSchedule”相匹配。 但是如果在给节点添加上述污点之前，该Pod已经在上述节点运行， 那么它还可以继续运行在该节点上。

      图17 容忍度配置示例3
      

      通常情况下，如果给一个节点添加了一个效果值为NoExecute的污点， 则任何不能忍受这个污点的Pod都会马上被驱逐， 任何可以忍受这个污点的Pod都不会被驱逐。

      配置示例：如果Pod存在一个效果值为“NoExecute”的容忍度且容忍时间为“3600”秒，即配置如图18所示，这表示如果该Pod正在运行，同时一个匹配的污点被添加到其所在的节点， 那么Pod还将继续在节点上运行3600秒，然后被驱逐。 如果在此之前上述污点被删除了，则Pod不会被驱逐。

      图18 容忍度配置示例4
      

12. 从页面左侧“服务”中，拖拽“Service”元素至页面右侧的服务区域中（界面中会显示，将元素拖入中）。

    Pod是Kubernetes应用程序的基本执行单元，即它是Kubernetes对象模型中创建或部署的最小和最简单的单元。Pod封装了一个或多个应用程序容器、存储资源、唯一网络IP以及控制容器应该如何运行的选项。Service可以理解为使用标签选择器（selectors）标识的一组Pod，通过Service可以访问到这组Pod。

13. 选中拖入的“Service”元素，单击，配置Service。
    图19 “service”配置页面
    
    • 名称：新建服务的名称。
    • 访问类型：访问服务的类型。
      • 集群内访问（ClusterIP）：表示工作负载暴露给同一集群内，其他工作负载的访问方式，可以通过“集群内部域名”访问。集群内部域名格式为“<自定义的访问方式名称>.<工作负载所在命名空间>.svc.cluster.local”，例如“nginx.default.svc.cluster.local”。
      • 节点访问 ( NodePort)：是指在每个节点的IP上，开放一个静态端口，通过静态端口对外暴露服务。节点访问 ( NodePort )会路由到ClusterIP服务，这个ClusterIP服务会自动创建。通过请求<NodeIP>:<NodePort>，可以从集群的外部访问一个NodePort服务。
    • 描述：服务的描述信息。
    • 协议：端口配置，请根据业务的协议类型，选择TCP或UDP。
    • 容器端口：容器镜像中，工作负载实际监听的端口，取值范围为1-65535。
    • 访问端口：如果访问类型配置为“集群内访问（ClusterIP）”，则访问端口为容器端口映射到集群虚拟IP上的端口，用虚拟IP访问工作负载时使用，端口范围为1-65535，可任意指定。如果访问类型配置为“节点访问 ( NodePort)”，则访问端口为容器端口映射到节点私有IP上的端口。
    • 注解：单击“新增行”，可使用Kubernetes注解为对象附加任意非标识的元数据。注解中的元数据，可以很小，也可以很大，可以是结构化的，也可以是非结构化的，能够包含标签不允许的字符。注解存储的形式为键/值对。

14. 从页面左侧“网络”中，拖拽“Ingress”元素至页面右侧的网络区域中（界面中会显示，将元素拖入中）。

    Ingress是对集群中服务的外部访问，进行管理的API对象，访问方式是HTTP或HTTPS。

15. 选中拖入的“Ingress”元素，单击，设置Ingress。
    图20 “Ingress”配置页面
    
    • 基本信息
      • 名称：新建Ingress的名称。七层负载均衡（Ingress）采用了增强型弹性负载均衡，通过对应的URI将访问流量分发到对应的服务。同时，服务根据不同URI实现不同的功能。
      • 描述：Ingress的描述信息。
    • 监听器配置：Ingress为负载均衡器配置监听器，监听器对负载均衡器上的请求进行监听，并分发流量。
      • 对外协议：对外协议支持HTTP和HTTPS。
        • 勾选HTTPS，表示使用HTTPS。
        • 默认不勾选HTTPS，表示使用HTTP。
      • Secret证书名称：如果对外协议勾选“HTTPS”，需要配置密钥名称，取值和在CCE中上传镜像中配置的密钥名称保持一致。

        您也可以单击参数后的，单击“增加全局配置”，将密钥证书名称配置为全局变量。后续在修改用到的密钥证书名称时，只需要修改全局变量即可。建议使用全局变量的方式，设置密钥证书名称。

    • 转发策略配置：请求的访问地址与转发规则匹配时，此请求将被转发到对应的目标Service处理。
      • 域名：实际访问的域名地址，请确保所填写的域名，已注册并备案。在Ingress创建完成后，将域名与自动创建的负载均衡实例的IP（即Ingress访问地址的IP部分）绑定。一旦配置了域名规则，则必须使用域名访问。
      • URL：需要注册的访问路径，例如“/test”。URL匹配规则为前缀匹配，例如URL为“/test”，只要符合此前缀的URL均可访问。例如“/test/v1”，“/test/v2。”
      • 目标服务：请求将被转发到对应的目标服务，请从下拉框选择12~13中配置的Service。
      • 服务端口：目标Service的访问端口，请从下拉框选择13中配置的访问端口。
    • 注解：单击“新增行”，可使用Kubernetes注解，为对象附加任意非标识的元数据。注解中的元数据，可以很小，也可以很大，可以是结构化的，也可以是非结构化的，能够包含标签不允许的字符。注解存储的形式为键/值对。
      • 由于CCE的Kubernetes集群默认部署了Nginx控制器，因此需要在Ingress上添加注解，详情请参见Kubernetes资料。
      • 在AstroZero中，调用Native服务接口时，无法处理重定向的响应，因此必须给Ingress添加注解，键为“nginx.ingress.kubernetes.io/ssl-redirect”，值为“false”。
      • Nginx控制器默认后端Service使用的是http协议。如果后端Service使用的是https协议，应添加如下注解：键为“nginx.ingress.kubernetes.io/backend-protocol”，值为“HTTPS”和键为“nginx.ingress.kubernetes.io/secure-backends”，值为“true”。

16. （可选）如果需要配置多个负载相关的容器，可参考4~15配置另外的容器。
17. 单击页面上方的，保存Chart。

配置API

原生服务旨在帮助您在AstroZero平台上或外部系统，调用已开发好的服务。为了完成调用，需要知道服务开放了哪些接口，以及这些接口的请求参数、返回参数，完成设计API后，可在服务编排中进行调用，也可将API再封装为自定义公共接口，供外部系统调用自定义公共接口。

部署Native Service

配置完API后，还需要部署才可使用Native Service。请使用此前设计的Chart包，在CCE上完成服务的部署。

1. 下载Chart包。
   1. 在创建Native Service中创建的原生服务配置页面，选择“导航”。
   2. 在“Chart设计”页签版本列表区域，单击待导出Chart后的，将Chart包导出到本地。
      图23 导出Chart包
      

      操作列按钮分别提供编辑Chart包、修改Chart包状态（单击后，Chart包状态是“Published”，无法再编辑该Chart包。单击后，Chart包状态是“Draft”，可编辑该Chart包。该界面不提供发布功能，实际发布要去CCE部署和发布）、预览Chart配置、导出Chart包、克隆已有Chart包配置和删除功能。

2. 安装Native Service。
   1. 登录CCE服务控制台，单击集群名称进入集群，在左侧导航栏中选择“应用模板”，在右上角单击“上传模板”。
   2. 单击“添加文件”，选择已下载的Chart包，单击“上传”。
   3. 在我的模板中，单击已上传模板上的“安装”。
   4. 参照表3，设置安装参数。

      表3 安装参数说明

      参数	说明
      实例名称	新建模板实例名称，命名必须唯一。
      命名空间	指定部署的命名空间。
      选择版本	选择模板的版本。
      配置文件	用户可以导入values.yaml文件，导入后可替换模板包中的values.yaml文件；也可直接在配置框中在线编辑模板参数。 说明： 此处导入的values.yaml文件需符合yaml规范，即KEY:VALUE格式。对于文件中的字段不做任何限制。 导入的value.yaml的key值必须与所选的模板包的values.yaml保持一致，否则不会生效。即key不能修改。 单击“添加文件”。 选择对应的values.yaml文件，单击“打开”。

   5. 配置完成后，单击“安装”。

      在“模板实例”页签下，可以查看模板实例的安装情况。

3. （可选）升级Native Service。

   部署Native Service后，可以通过更换镜像或镜像版本，实现Native Service的快速升级，业务无中断。

   1. 登录CCE控制台，单击集群名称进入集群，在左侧导航栏中选择“应用模板”，在右侧选择“模板实例”页签。
   2. 单击待升级工作负载后的“升级”，设置升级模板工作负载的参数。
   3. 选择对应的模板版本。
   4. 参照界面提示修改模板参数。单击“升级”。
   5. 执行状态为“升级成功”时，表明工作负载升级成功。

注册Native Service

注册Native Service后，才可以在AstroZero的其他组件内（如脚本、服务编排等）调用原生服务的接口，也可将该原生服务开放给第三方系统进行访问。

1. 注册Native Service，有两种入口方式。
   • 方式一：在环境配置注册原生服务
     1. 在应用开发页面，单击，选择“环境管理 > 环境配置”。
     2. 在左侧导航栏中，选择“开发配置 > 原生服务 > 服务注册”。
     3. 单击“注册服务”，选择要注册的原生服务，单击“确认”。

        在环境配置中注册原生服务的详细介绍，请参见管理原生服务。

   • 方式二：在原生服务应用设计器中注册原生服务
     1. 在原生服务的设计器中，单击“导航”。
     2. 在右侧页面，选择服务注册，单击“注册服务”。
        图24 注册原生服务
        

2. 以方式1入口为例，配置相关认证信息，单击“确认”。
   图25 注册服务
   
   • 选择服务：选择需要注册的服务。
   • 名称：注册的服务名称。
   • API服务地址：Ingress的访问地址，需包含协议头http或者https。如何获取，请参见通过控制台创建ELB Ingress。
   • 认证方式：访问原生服务的鉴权认证方式，当前支持以下几种。
     • 无认证：不需要鉴权认证。
     • 用户名&密码：用户名和密码认证方式。选择该方式，需要配置具体的“用户名”和“密码”。
     • JWT： JWT（JSON Web Tokens）鉴权方式。选择该方式，需要配置具体的“JWT密钥”。
     • OAuth 2.0：OAuth 2.0鉴权方式。选择该方式，需要配置如下参数。
       • 授权模式：即Oauth2.0中的grant_type字段的取值，目前支持两种模式“客户端模式”（client_credentials）和“密码模式”（password）。
       • 认证地址：获取access_token的请求路径。
       • 客户端ID：client_id，客户端模式下必填，密码模式下如果有提供请填写。
       • 客户端密钥：client_secret，客户端模式下必填，密码模式下如果有提供请填写。

   注册后，在“已注册服务”列表中，可查看到当前账号已注册的所有原生服务。也可以单击已注册的所有原生服务，在“注册详情”中单击“取消注册”，取消该原生服务的注册。

自定义Native Service公共接口

自定义公共接口，将原生服务API发布到外部网关，第三方系统可以通过OAuth2.0调用AstroZero上的原生服务。

1. 在创建Native Service中创建的原生服务配置页面，选择“设置 > 公共接口”。
2. 在公共接口页面中，单击“新建”。
3. 设置公共接口参数，单击“保存”。
   图26 设置公共接口参数
   
   • 名称：新建公共接口的名称。
   • 版本：公共接口的版本号。
   • URL：新URL的地址。其中“/native”是固定值，其次是“/Native Service名称/版本号”，剩下部分进行自定义。自定义的URL需要符合一定规则，规则如下：
     • 必须以单个“/”开头。
     • 可以配置多级路径，两个或多个“/”之间必须有内容。
   • 描述：公共接口的描述信息，通常设置为接口的功能。
   • 操作名称：需要开放给外部第三方系统的操作名称，取值来源于配置API中配置的操作名称。
   • 资源：与镜像文件中的接口路径一致，不用配置。
   • 方法：映射后调用的方法名，如GET（查询）、PUT（增加）、POST（修改）和DELETE（删除），不用配置。
   • CSRF校验：调用该公共接口时，是否需要做CSRF校验。GET方法不需要做CSRF校验，其他方法可根据需要配置是否做CSRF校验。
     • 否：不需要做CSRF校验，可直接调用该公共接口。
     • 是：需要做CSRF校验。在调该公共接口前，需要先调接口“https://AstroZero域名/u-route/baas/sys/v1.0/csrf/get”获取鉴权result取值（调该接口时需要在请求消息头上设置“access-token”，获取方法可参考配置API中介绍），再调用该公共接口请求消息头上设置的“csrf-token”值为鉴权result值，即可调用该公共接口。

4. （可选）设置访问该自定义接口的用户业务权限。

   如果没有配置业务权限，只有业务用户可访问该接口，平台用户不可访问。如果配置了业务权限，则只有拥有该业务权限的用户才可以访问该接口。

   例如，只有拥有业务权限“A”的用户，才可访问该接口，具体步骤如下：

   1. 返回应用开发页面，单击，选择“环境管理 > 环境配置”。
   2. 在环境配置的顶部菜单栏中，选择“维护”。
   3. 在左侧导航栏中，选择“全局元素 > 业务权限凭证”。
   4. 在业务权限凭证页面，单击“新建”，创建业务权限“A”。
      图27 创建业务权限“A”
      
   5. 返回“配置”页面，选择“用户管理 > 权限”，在权限列表中单击用户对应的权限，进入权限配置详情页面。
   6. 在“业务权限凭证”页签，配置接入业务权限“A”。
      图28 用户权限配置
      
   7. 选择“维护 > 全局元素 > 自定义接口”中，单击对应的公共接口，进入接口详情页面。
   8. 在业务权限凭证中，单击“编辑”，配置业务权限，将左侧业务权限“A”加入到右侧“已选择业务权限凭证列表”中，单击“保存”。
      图29 配置业务权限
      

      业务用户访问该接口URL前，还需要创建如下的服务编排，用于获取token值。其中，赋的值“PL”是一个公式变量，表达式为“PORTALUSERLOGIN("pu1")”，其中“pu1”为业务用户名，配置该服务编排的出参为“token”。

      图30 创建服务编排
      

      执行该服务编排后，在输出信息中，获取token值。

      {
        "interviewId": "002N000000RBLY9scgDY",
        "outputs": {
          "token": "XXXXXXXXXXXXXXX"
        }
      }

导出Native Service给其他用户使用

服务编排可以成功调用原生服务后，说明整个流程已测通。您可以导出原生服务包给其他用户，其他用户可以在沙箱环境或运行环境中安装该包，以便于使用该软件或进行定制。

1. 当原生服务部署成功后，发布该原生服务包。
   1. 在创建Native Service中创建的原生服务配置页面，单击，选择“设置”，进行软件包设置。
   2. 设置完成后，单击，选择“编译”，进行编译。

      编译成功后，页面会显示“编译XXX成功”。

   3. 单击，选择“发布资产包到我的仓库”。
   4. 配置发布的版本号和Chart版本，单击“发布”。
      图31 发布版本信息
      

      发布成功后，页面显示“程序包已经被成功上传到我的仓库”。

2. 在原生服务配置界面左侧，单击。
3. 在“已发布”中，选择资产包或源码包，单击已发布的原生服务，在右侧页面单击“下载”。
4. 将下载到本地的原生服务包，发送给其他需要安装该包的用户。
5. 需要安装该服务的其他用户，登录沙箱环境或者运行环境，安装该服务包。
   1. 在沙箱环境或运行环境中，单击页面右上方的“体验新版”，进入新版沙箱环境或运行环境。
   2. 在左侧导航栏中，选择“应用管理 > 安装管理 > 包安装”。
   3. 单击“新建”，在“包安装”页面将服务包拖入进去，单击“安装”。