配置Chart

使用说明

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

前提条件

• 已开通CCE服务，详情请参见“CCE资料 > 入门指引”。
• 已创建虚拟私有云，虚拟私有云为CCE集群提供一个隔离的、用户自主配置和管理的虚拟网络环境。创建首个集群前，必须先确保已存在虚拟私有云，否则无法创建集群。如何创建虚拟私有云，请参见创建虚拟私有云和子网。
• 已创建Kubernetes集群，服务将部署在这个集群内。如何创建集群，请参见创建Kubernetes混合集群。
• 在配置Chart前，已准备好Docker镜像。Docker镜像可自行开发并上传到CCE容器中，也可以使用第三方镜像仓库的镜像。

  在进行镜像开发时，如何制作Docker镜像，可参考如何编写高效的Dockerfile。如何上传镜像到CCE，请参考在CCE中上传镜像。

• 已熟悉CCE云容器引擎，熟悉CCE控制台配置，包括工作负载、模板市场、配置中心和镜像仓库，相关资料请参考CCE资料。

操作步骤

1. 在Native Service配置页面，选择“导航”。
   图1 单击导航
   

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

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

   图2 单击新建
   

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

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

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

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

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

      表1 容器配置参数说明

      页签	参数	参数说明
      基本信息	容器名称	容器的名称。
      	镜像地址	镜像的地址，取值说明如下： 若需要拉取CCE镜像仓库的镜像，请登录CCE控制台，在左侧导航栏中选择“镜像仓库 > 镜像管理”，根据需要选择“自有镜像”或“公开镜像”（“自有镜像”为该租户自有的镜像，“公开镜像”页签的镜像所有用户都可以下载使用）。单击需要使用的镜像名，进入镜像详情页面，如图12所示。单击“下载指令”列后的，即可获取。 在此处粘贴获取的值时，需要去掉粘贴内容中的“docker pull”，只保留后面部分 。例如，镜像地址配置为“10.10.10.1/bingodev/testoauth:fifth”。 若需要拉取第三方镜像仓库的镜像，请直接输入第三方镜像仓库的镜像地址，例如“www.3rdregistry.com”或“10.10.10.10:443”。 您也可以单击参数后的，单击“增加全局配置”，如图13所示，将镜像地址配置为全局变量。后续在修改镜像地址时，只需要修改全局变量即可，建议使用全局变量方式，设置镜像地址。
      	镜像拉取策略	从镜像仓库中，下载镜像的策略。 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将仍然继续在该节点上运行。

        配置示例：如图14所示，节点亲和“必须满足原则”中配置“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”的节点应该被优先使用。一个节点可能有多个标签，即多个标签键值。

        图14 节点亲和配置示例
        
    • 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尽量不要调度到某节点上。

        配置示例：如图15所示，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尽量不要调度到该节点所在可用区内。

        图15 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节点，则需要按照图16或图17所示进行配置，配置Pod容忍度为“key1 Equal value1 NoSchedule”或“key1 Exists NoSchedule”，则该Pod拥有和这个污点相匹配的容忍度，Pod才能够被分配到node1这个节点。

      图16 容忍度配置示例1
      
      图17 容忍度配置示例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

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

      图18 容忍度配置示例3
      

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

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

      图19 容忍度配置示例4
      

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

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

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

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

    • 转发策略配置：请求的访问地址与转发规则匹配时，此请求将被转发到对应的目标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。

Chart元素说明

• ConfigMap

  是一种用于存储工作负载所需配置信息的资源类型，内容由用户决定。配置项创建完成后，可在工作负载中作为文件或环境变量使用。允许将配置文件从容器镜像中解耦，从而增强容器工作负载的可移植性。

• Secret（密钥）
  是一种用于存储工作负载所需要认证信息、密钥的敏感信息等的资源类型，内容由用户决定。资源创建完成后，可在容器工作负载中作为文件或环境变量使用。其配置页面上参数含义与ConfigMap大体相同，差异的参数说明如下：

  • “密钥类型”取值为“Opaque”，表示一般密钥类型。
  • “密钥数据”的“值”必须使用Base64编码。对字符串进行Base64加密，可以直接使用“echo -n 待编码内容 | base64”命令。

    root@ubuntu:~# echo -n "待编码内容" | base64

• 无状态负载

  等同于Kubernetes中的“Deployment”概念，所有Pod实例之间是对等的，互不依赖，少了任意一个Pod实例，并不影响整个工作负载的功能。

• 有状态负载

  等同于Kubernetes中的“StatefulSet”概念，是用来管理有状态应用的工作负载API对象。和“无状态负载”相同的是，“有状态负载”管理了基于相同容器定义的一组Pod。和“无状态负载”不同的是，“有状态负载”为每个Pod维护了一个固定的ID。这些Pod是基于相同的声明来创建的，但是不能相互替换。无论怎么调度，每个Pod都有一个永久不变的ID。选择“有状态负载”时，必须要配置“实例间发现服务”。

  实例间发现服务指的是Kubernetes的Headless Service，Headless Service用于控制Pod的网络域名，通过Pod的网络域名可以访问特定的Pod实例。例如，集群域名为cluster.local，有状态负载的名称为web，有3个Pod实例，则3个Pod的名称分别为web-0、web-1和web-2，Headless Service的名称为nginx，则3个Pod的域名分别是web-0.nginx.$(命名空间).svc.cluster.local、web-1.nginx.$(命名空间).svc.cluster.local、web-2.nginx.$(命名空间).svc.cluster.local，通过Pod域名访问到具体的Pod实例。