华为云用户手册

验证数据持久化及共享性 查看部署的应用及文件。 执行以下命令，查看已创建的Pod。 kubectl get pod | grep web-demo 预期输出如下： web-demo-846b489584-mjhm9 1/1 Running 0 46s web-demo-846b489584-wvv5s 1/1 Running 0 46s 依次执行以下命令，查看Pod的/data路径下的文件。 kubectl exec web-demo-846b489584-mjhm9 -- ls /data kubectl exec web-demo-846b489584-wvv5s -- ls /data 两个Pod均无返回结果，说明/data路径下无文件。 执行以下命令，在/data路径下创建static文件。 kubectl exec web-demo-846b489584-mjhm9 -- touch /data/static 执行以下命令，查看/data路径下的文件。 kubectl exec web-demo-846b489584-mjhm9 -- ls /data 预期输出如下： static 验证数据持久化 执行以下命令，删除名称为web-demo-846b489584-mjhm9的Pod。 kubectl delete pod web-demo-846b489584-mjhm9 预期输出如下： pod "web-demo-846b489584-mjhm9" deleted 删除后，Deployment控制器会自动重新创建一个副本。 执行以下命令，查看已创建的Pod。 kubectl get pod | grep web-demo 预期输出如下，web-demo-846b489584-d4d4j为新建的Pod： web-demo-846b489584-d4d4j 1/1 Running 0 110s web-demo-846b489584-wvv5s 1/1 Running 0 7m50s 执行以下命令，验证新建的Pod中/data路径下的文件是否更改。 kubectl exec web-demo-846b489584-d4d4j -- ls /data 预期输出如下： static static文件仍然存在，则说明数据可持久化保存。 验证数据共享性 执行以下命令，查看已创建的Pod。 kubectl get pod | grep web-demo 预期输出如下： web-demo-846b489584-d4d4j 1/1 Running 0 7m web-demo-846b489584-wvv5s 1/1 Running 0 13m 执行以下命令，在任意一个Pod的/data路径下创建share文件。本例中选择名为web-demo-846b489584-d4d4j的Pod。 kubectl exec web-demo-846b489584-d4d4j -- touch /data/share 并查看该Pod中/data路径下的文件。 kubectl exec web-demo-846b489584-d4d4j -- ls /data 预期输出如下： share static 由于写入share文件的操作未在名为web-demo-846b489584-wvv5s的Pod中执行，在该Pod中查看/data路径下是否存在文件以验证数据共享性。 kubectl exec web-demo-846b489584-wvv5s -- ls /data 预期输出如下： share static 如果在任意一个Pod中的/data路径下创建文件，其他Pod下的/data路径下均存在此文件，则说明两个Pod共享一个存储卷。

验证数据持久化及共享性 查看部署的应用及文件。 执行以下命令，查看已创建的Pod。 kubectl get pod | grep web-demo 预期输出如下： web-demo-846b489584-mjhm9 1/1 Running 0 46s web-demo-846b489584-wvv5s 1/1 Running 0 46s 依次执行以下命令，查看Pod的/data路径下的文件。 kubectl exec web-demo-846b489584-mjhm9 -- ls /data kubectl exec web-demo-846b489584-wvv5s -- ls /data 两个Pod均无返回结果，说明/data路径下无文件。 执行以下命令，在/data路径下创建static文件。 kubectl exec web-demo-846b489584-mjhm9 -- touch /data/static 执行以下命令，查看/data路径下的文件。 kubectl exec web-demo-846b489584-mjhm9 -- ls /data 预期输出如下： static 验证数据持久化 执行以下命令，删除名称为web-demo-846b489584-mjhm9的Pod。 kubectl delete pod web-demo-846b489584-mjhm9 预期输出如下： pod "web-demo-846b489584-mjhm9" deleted 删除后，Deployment控制器会自动重新创建一个副本。 执行以下命令，查看已创建的Pod。 kubectl get pod | grep web-demo 预期输出如下，web-demo-846b489584-d4d4j为新建的Pod： web-demo-846b489584-d4d4j 1/1 Running 0 110s web-demo-846b489584-wvv5s 1/1 Running 0 7m50s 执行以下命令，验证新建的Pod中/data路径下的文件是否更改。 kubectl exec web-demo-846b489584-d4d4j -- ls /data 预期输出如下： static static文件仍然存在，则说明数据可持久化保存。 验证数据共享性 执行以下命令，查看已创建的Pod。 kubectl get pod | grep web-demo 预期输出如下： web-demo-846b489584-d4d4j 1/1 Running 0 7m web-demo-846b489584-wvv5s 1/1 Running 0 13m 执行以下命令，在任意一个Pod的/data路径下创建share文件。本例中选择名为web-demo-846b489584-d4d4j的Pod。 kubectl exec web-demo-846b489584-d4d4j -- touch /data/share 并查看该Pod中/data路径下的文件。 kubectl exec web-demo-846b489584-d4d4j -- ls /data 预期输出如下： share static 由于写入share文件的操作未在名为web-demo-846b489584-wvv5s的Pod中执行，在该Pod中查看/data路径下是否存在文件以验证数据共享性。 kubectl exec web-demo-846b489584-wvv5s -- ls /data 预期输出如下： share static 如果在任意一个Pod中的/data路径下创建文件，其他Pod下的/data路径下均存在此文件，则说明两个Pod共享一个存储卷。

相关操作 您还可以执行表4中的操作。 表4 其他操作 操作 说明 操作步骤 创建存储卷 通过CCE控制台单独创建PV。 在左侧导航栏选择“存储”，在右侧选择“存储卷”页签。单击右上角“创建存储卷”，在弹出的窗口中填写存储卷声明参数。 存储卷类型：选择“文件存储”。 文件存储：单击“选择文件存储”，在新页面中勾选满足要求的文件存储，并单击“确定”。 PV名称：输入PV名称，同一集群内的PV名称需唯一。 访问模式：仅支持ReadWriteMany，表示存储卷可以被多个节点以读写方式挂载，详情请参见存储卷访问模式。 回收策略：Delete或Retain，详情请参见PV回收策略。 说明： 多个PV使用同一个底层存储时建议使用Retain，避免级联删除底层卷。 挂载参数：输入挂载参数键值对，详情请参见设置文件存储挂载参数。 单击“创建”。 事件 查看PVC或PV的事件名称、事件类型、发生次数、Kubernetes事件、首次和最近发生的时间，便于定位问题。 在左侧导航栏选择“存储”，在右侧选择“存储卷声明”或“存储卷”页签。 单击目标实例操作列的“事件”，即可查看1小时内的事件（事件保存时间为1小时）。 查看YAML 可对PVC或PV的YAML文件进行查看、复制和下载。 在左侧导航栏选择“存储”，在右侧选择“存储卷声明”或“存储卷”页签。 单击目标实例操作列的“查看YAML”，即可查看或下载YAML。

约束与限制 支持多个PV挂载同一个SFS或SFS Turbo，但有如下限制： 多个不同的PVC/PV使用同一个底层SFS或SFS Turbo卷时，如果挂载至同一Pod使用，会因为PV的volumeHandle参数值相同导致无法为Pod挂载所有PVC，出现Pod无法启动的问题，请避免该使用场景。 PV中persistentVolumeReclaimPolicy参数建议设置为Retain，否则可能存在一个PV删除时级联删除底层卷，其他关联这个底层卷的PV会由于底层存储被删除导致使用出现异常。 重复用底层存储时，建议在应用层做好多读多写的隔离保护，防止产生的数据覆盖和丢失。 使用SFS 3.0存储卷时，挂载点不支持修改属组和权限。 使用SFS 3.0存储卷时，创建、删除PVC和PV过程中可能存在时延，实际计费时长请以SFS侧创建、删除时刻为准。 SFS 3.0存储卷在Delete回收策略下暂不支持自动回收文件存储卷。当删除PV/PVC时，需要手动删除所有文件后才可以正常删除PV和PVC。

API变更与弃用 在Kubernetes 1.28版本，移除特性NetworkPolicyStatus，因此Network Policy不再有status属性。 在Kubernetes 1.28版本，Job对象中增加了新的annotationbatch.kubernetes.io/cronJob-scheduled-timestamp，表示Job的创建时间。 在Kubernetes 1.28版本，Job API中添加podReplacementPolicy和terminating字段，当前一旦先前创建的pod终止，Job就会立即启动替换pod。添加字段允许用户指定是在先前的Pod终止后立即更换Pod（原行为），还是在现有的Pod完全终止后才替换Pod（新行为）。这是一项Alpha级别特性，您可以通过在集群中启用JobPodReplacementPolicy 来启用该特性。 在Kubernetes 1.28版本，Job支持BackoffLimitPerIndex字段。当前使用的运行Job的策略是Job中的整个Pod共享一个Backoff机制，当Job达到次Backoff的限制时，整个Job都会被标记为失败，并清理资源，包括尚未运行的index。此字段允许对单个的index设置Backoff。更多信息请参见带索引Job的Backoff限制。 在Kubernetes 1.28版本，添加ServedVersions字段到 StorageVersion API中。该变化由混合代理版本特性引入。该增加字段ServedVersions用于表明 API服务 器可以提供的版本。 在Kubernetes 1.28版本，SelfSubjectReview 添加到authentication.k8s.io/v1中，并且kubectl auth whoami走向GA。 在Kubernetes 1.28版本，PersistentVolume有了一个新的字段LastPhaseTransitionTime，用来保存最近一次volume转变Phase的时间。 在Kubernetes 1.28版本，PVC.Status中移除resizeStatus，使用AllocatedResourceStatus替代。resizeStatus表示调整存储大小操作的状态，默认为空字符串。 在Kubernetes 1.28版本，设置了hostNetwork: true并且定义了ports的Pods，自动设置hostport字段。 在Kubernetes 1.28版本，StatefulSet的Pod索引设置为Pod的标签statefulset.kubernetes.io/pod-index。 在Kubernetes 1.28版本，Pod的Condition字段中的PodHasNetwork重命名为PodReadyToStartContainers，用来表明网络、卷等已成功创建，sandbox pod已经创建完成，可以启动容器。 在Kubernetes 1.28版本，在KubeSchedulerConfiguration中添加了新的配置选项delayCacheUntilActive， 该参数为true时，非master节点的kube-scheduler不会缓存调度信息。这为非主节点的内存减缓了压力，但会导致主节点发生故障时，减慢故障转移的速度。 在Kubernetes 1.28版本，在admissionregistration.k8s.io/v1alpha1.ValidatingAdmissionPolicy中添加namespaceParamRef字段。 在Kubernetes 1.28版本，在CRD validation rules中添加reason和fieldPath，允许用户指定验证失败的原因和字段路径。 在Kubernetes 1.28版本，ValidatingAdmissionPolicy的CEL表达式通过namespaceObject支持namespace访问。 在Kubernetes 1.28版本，将API groups ValidatingAdmissionPolicy 和ValidatingAdmissionPolicyBinding提升到betav1。 在Kubernetes 1.28版本，ValidatingAdmissionPolicy 扩展了messageExpression字段，用来检查已解析类型。

重要说明 在Kubernetes 1.28版本，调度框架发生变化，减少无用的重试，从而提高调度程序的整体性能。如果开发人员在集群中使用了自定义调度程序插件，请参见调度框架变化进行适配升级。 在Kubernetes 1.28版本，Ceph FS树内插件已在v1.28中弃用，并计划在v1.31中删除（社区没有计划进行 CS I迁移）。建议使用Ceph CSI第三方存储驱动程序作为替代方案。 在Kubernetes 1.28版本，Ceph RBD树内插件已在v1.28中弃用，并计划在v1.31中删除（社区没有计划进行CSI迁移）。建议使用RBD模式的Ceph CSI第三方存储驱动程序作为替代方案。

新增特性及特性增强 社区特性的Alpha阶段默认禁用、Beta阶段一般默认启用、GA阶段将一直默认启用，且不能禁用（会在后续版本中删除这个开关功能）。CCE对新特性的策略与社区保持一致。 版本偏差策略扩展至3个版本 从1.28控制平面/1.25工作节点开始，Kubernetes版本偏差策略将支持的控制平面/工作节点偏差扩展到3个版本。 这使得节点的年度次要版本升级成为可能，同时保持受支持的次要版本。更多细节请参考版本偏差策略。 可追溯的默认StorageClass进阶至GA 在Kubernetes 1.28版本，可追溯默认StorageClass赋值现已进阶至GA。 这项增强特性极大地改进了默认的StorageClasses为PersistentVolumeClaim（PVC）赋值的方式。 PersistentVolume（PV）控制器已修改为：当未设置storageClassName时，自动向任何未绑定的PersistentVolumeClaim分配一个默认的StorageClass。此外，API 服务器中的PersistentVolumeClaim准入验证机制也已调整为允许将值从未设置状态更改为实际的StorageClass名称。更多使用细节请参考默认StorageClass赋值。 原生边车容器（Alpha） 在Kubernetes 1.28版本，原生边车容器以Alpha版本正式发布。其在Init容器中添加了一个新的restartPolicy字段， 该字段在SidecarContainers特性门控启用时可用。需要注意的是，原生边车容器目前仍有些问题需要解决，因此K8S社区建议仅在Alpha阶段的短期测试集群中使用边车功能。 更多使用细节请参考原生边车容器。 混合版本代理（Alpha） 在Kubernetes 1.28版本，发布了用于改进集群安全升级的新机制（混合版本代理）。该特性为Alpha特性。当集群进行升级时，集群中不同版本的kube-apiserver为不同的内置资源集（组、版本、资源）提供服务。在这种情况下资源请求如果由任一可用的apiserver提供服务，请求可能会到达无法解析此请求资源的apiserver中，导致请求失败。该特性能解决该问题。（主要注意的是，CCE本身提供的升级能力即可做到无损升级，因此不存在该特性涉及的场景）。更多使用细节请参考混合版本代理。 节点非体面关闭特性达到GA 在Kubernetes 1.28版本，节点非体面关闭特性达到GA阶段。当一个节点被关闭但没有被Kubelet的Node Shutdown Manager检测到时，StatefulSet的Pod将会停留在终止状态，并且不能移动到新运行的节点上。当用户确认该节点已经处于不可恢复的情况下，可以手动为Node打上out-of-service的污点，以使得该节点上的StatefulSet的Pod和VolumeAttachments被强制删除，并在健康的Node上创建相应的Pod。更多使用细节请参考节点非体面关闭。 NodeSwap特性达到Beta 在Kubernetes 1.28版本，NodeSwap能力进阶至Beta版本。目前仍然处于默认关闭状态，需要使用NodeSwap门控打开。该特性可以为Linux节点上运行的Kubernetes工作负载逐个节点地配置内存交换。需要注意的是，该特性虽然进阶至Beta特性，但仍然存在一些需要增强的问题和安全风险。更多使用细节请参考NodeSwap特性。 Job相关特性 在Kubernetes 1.28版本，增加了Pod更换策略和基于带索引Job的回退限制两个alpha特性。 Pod更换策略 默认情况下，当Pod进入终止（Terminating）状态（例如由于抢占或驱逐机制）时，Kubernetes会立即创建一个替换的Pod，因此这时会有两个Pod同时运行。 在Kubernetes 1.28版本中可以使用JobPodReplacementPolicy 来启用该特性。可以在Job的Spec中定义podReplacementPolicy，目前仅可设置为Failed。在设置为Failed之后，Pod仅在达到Failed阶段时才会被替换，而不是在它们处于终止过程中（Terminating）时被替换。此外，您可以检查Job的.status.termination字段。该字段的值表示终止过程中的Job所关联的Pod数量。 带索引Job的回退限制 默认情况下，带索引的Job（Indexed Job）的 Pod 失败情况会被记录下来，受.spec.backoffLimit字段所设置的全局重试次数限制。这意味着，如果存在某个索引值的Pod一直持续失败，则Pod会被重新启动，直到重试次数达到限制值。一旦达到限制值，整个Job将被标记为失败，并且对应某些索引的Pod甚至可能从不曾被启动。 在Kubernetes 1.28版本中，可以通过启用集群的JobBackoffLimitPerIndex特性门控来启用此特性。开启之后，允许在创建带索引的Job（Indexed Job）时指定.spec.backoffLimitPerIndex字段。当某个Job的失败次数超过设定的上限时，将不再进行重试。 CEL相关特性 在Kubernetes 1.28版本，CEL能力进行了相应的增强。 CRD使用CEL进行Validate的特性进阶至Beta 该特性在v1.25版本就已经升级为Beta版本。通过将CEL表达式直接集成在CRD中，可以使开发者在不使用Webhook的情况下解决大部分对CR实例进行验证的用例。在未来的版本，将继续扩展CEL表达式的功能，以支持默认值和 CRD转换。 基于CEL的准入控制进阶至Beta 基于通用表达式语言 (CEL) 的准入控制是可定制的，对于kube-apiserver接受到的请求，可以使用CEL表达式来决定是否接受或拒绝请求，可作为Webhook准入控制的一种替代方案。在 v1.28 中，CEL准入控制被升级为Beta，同时添加了一些新功能，包括但不限于： ValidatingAdmissionPolicy类型检查现在可以正确处理CEL表达式中的“authorizer”变量。 ValidatingAdmissionPolicy支持对messageExpression字段进行类型检查。 kube-controller-manager组件新增ValidatingAdmissionPolicy控制器，用来对ValidatingAdmissionPolicy中的CEL表达式做类型检查，并将原因保存在状态字段中。 支持变量组合，可以在ValidatingAdmissionPolicy中定义变量，然后在定义其他变量时使用它。 新增CEL库函数支持对Kubernetes的resource.Quantity类型进行解析。 其它特性说明 在Kubernetes 1.28版本，ServiceNodePortStaticSubrange 特性为beta，允许保留静态端口范围，避免与动态分配端口冲突。具体细节请参考为NodePort Service分配端口时避免冲突。 在Kubernetes 1.28版本，增加了alpha特性ConsistentListFromCache，允许kube-apiserver从缓存中提供一致性列表，Get和List请求可以从缓存中读取数据，而不需要从etcd中获取。 在Kubernetes 1.28版本，kubelet能够配置drop-in目录（alpha特性）。该特性允许向kubelet添加对“--config-dir”标志的支持，以允许用户指定一个插入目录，该目录将覆盖位于/etc/kubernetes/kubelet.conf位置的Kubelet的配置。 在Kubernetes 1.28版本，ExpandedDNSConfig升级至GA，默认会被打开。该参数用于允许扩展DNS的配置。 在Kubernetes 1.28版本，提供Alpha特性CRD Validation Ratcheting。该特性允许Patch或者Update请求没有更改任何不合法的字段，将允许CR验证失败。 在Kubernetes 1.28版本，kube-controller-manager添加了--concurrent-cron-job-syncs flag用来设置cron job controller的workers数。

特性门禁及命令行参数 在Kubernetes 1.28版本，kubelet移除了flag –short。因此kubectl version 默认输出与kubectl version –short相同。 在Kubernetes 1.28版本，kube-controller-manager废弃flag--volume-host-cidr-denylist和--volume-host-allow-local-loopback。--volume-host-cidr-denylist是用逗号分隔的一个CIDR范围列表，禁止使用这些地址上的卷插件。--volume-host-allow-local-loopback为false时，禁止本地回路IP地址和--volume-host-cidr-denylist中所指定的CIDR范围。 在Kubernetes 1.28版本，kubelet --azure-container-registry-config被弃用并在未来的版本中会被删除。 请使用--image-credential-provider-config和--image-credential-provider-bin-dir来设置。 在Kubernetes 1.28版本，kube-scheduler: 删除了--lock-object-namespace和--lock-object-name。 请使用--leader-elect-resource-namespace和--leader-elect-resource-name或ComponentConfig来配置这些参数。（--lock-object-namespace用来定义锁对象的命名空间，--lock-object-name用来定义锁对象的名称） 在Kubernetes 1.28版本，KMSv1已弃用，以后只会接收安全更新。请改用KMSv2。在未来版本中，设置--feature-gates=KMSv1=true以使用已弃用的KMSv1功能。 在Kubernetes 1.28版本，移除了如下特性门禁：DelegateFSGroupToCSIDriver、DevicePlugins、KubeletCredentialProviders、MixedProtocolLBService、ServiceInternalTrafficPolicy、ServiceIPStaticSubrange、EndpointSliceTerminatingCondition。

回滚 回滚也称为回退，即当发现升级出现问题时，让应用回到老的版本。Deployment可以非常方便的回滚到老版本。 例如上面升级的新版镜像有问题，可以执行kubectl rollout undo命令进行回滚。 $ kubectl rollout undo deployment nginx deployment.apps/nginx rolled back Deployment之所以能如此容易的做到回滚，是因为Deployment是通过ReplicaSet控制Pod的，升级后之前ReplicaSet都一直存在，Deployment回滚做的就是使用之前的ReplicaSet再次把Pod创建出来。Deployment中保存ReplicaSet的数量可以使用revisionHistoryLimit参数限制，默认值为10。

升级参数说明 参数 说明 限制 最大浪涌（maxSurge） 与spec.replicas相比，可以有多少个Pod存在，默认值是25%。 比如spec.replicas为 4，那升级过程中就不能超过5个Pod存在，即按1个的步长升级，实际升级过程中会换算成数字，且换算会向上取整。这个值也可以直接设置成数字。 仅Deployment支持配置。 最大无效实例数（maxUnavailable） 与spec.replicas相比，可以有多少个Pod失效，也就是删除的比例，默认值是25%。 比如spec.replicas为4，那升级过程中就至少有3个Pod存在，即删除Pod的步长是1。同样这个值也可以设置成数字。 仅Deployment支持配置。 实例可用最短时间（minReadySeconds） 指定新创建的 Pod 在没有任意容器崩溃情况下的最小就绪时间， 只有超出这个时间 Pod 才被视为可用。默认值为 0（Pod 在准备就绪后立即将被视为可用）。 - 最大保留版本数（revisionHistoryLimit） 用来设定出于回滚目的所要保留的旧 ReplicaSet 数量。 这些旧 ReplicaSet 会消耗 etcd 中的资源，并占用 kubectl get rs 的输出。 每个 Deployment 修订版本的配置都存储在其 ReplicaSets 中；因此，一旦删除了旧的 ReplicaSet， 将失去回滚到 Deployment 的对应修订版本的能力。 默认情况下，系统保留 10 个旧 ReplicaSet，但其理想值取决于新 Deployment 的频率和稳定性。 - 升级最大时长（progressDeadlineSeconds） 指定系统在报告 Deployment 进展失败 之前等待 Deployment 取得进展的秒数。 这类报告会在资源状态中体现为 Type=Progressing、Status=False、 Reason=ProgressDeadlineExceeded。Deployment 控制器将持续重试 Deployment。 将来，一旦实现了自动回滚，Deployment 控制器将在探测到这样的条件时立即回滚 Deployment。 如果指定，则此字段值需要大于 .spec.minReadySeconds 取值。 - 缩容时间窗（terminationGracePeriodSeconds） 优雅删除时间，默认为30秒，删除Pod时发送SIGTERM终止信号，然后等待容器中的应用程序终止执行，如果在terminationGracePeriodSeconds时间内未能终止，则发送SIGKILL的系统信号强行终止。 -

升级示例 Deployment的升级可以是声明式的，也就是说只需要修改Deployment的YAML定义即可，比如使用kubectl edit命令将上面Deployment中的镜像修改为nginx:alpine。修改完成后再查询ReplicaSet和Pod，发现创建了一个新的ReplicaSet，Pod也重新创建了。 $ kubectl edit deploy nginx $ kubectl get rs NAME DESIRED CURRENT READY AGE nginx-6f9f58dffd 2 2 2 1m nginx-7f98958cdf 0 0 0 48m $ kubectl get pods NAME READY STATUS RESTARTS AGE nginx-6f9f58dffd-tdmqk 1/1 Running 0 1m nginx-6f9f58dffd-tesqr 1/1 Running 0 1m Deployment可以通过maxSurge和maxUnavailable两个参数控制升级过程中同时重新创建Pod的比例，这在很多时候是非常有用，配置如下所示。 spec: strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 0 type: RollingUpdate 在前面的例子中，由于spec.replicas是2，如果maxSurge和maxUnavailable都为默认值25%，那实际升级过程中，maxSurge允许最多3个Pod存在（向上取整，2*1.25=2.5，取整为3），而maxUnavailable则不允许有Pod Unavailable（向上取整，2*0.75=1.5，取整为2），也就是说在升级过程中，一直会有2个Pod处于运行状态，每次新建一个Pod，等这个Pod创建成功后再删掉一个旧Pod，直至Pod全部为新Pod。

检查Pod的EIP就绪 容器网络控制器会在Pod IP分配后，为Pod绑定EIP并回写分配结果至Pod的annotation（yangtse.io/allocated-ipv4-eip），Pod业务容器的启动时间可能早于EIP分配结果回写成功时间。 您可以尝试为Pod配置init container并使用downwardAPI类型的存储卷把yangtse.io/allocated-ipv4-eip的annotation通过volume挂载到init container里，并在init container中检查EIP是否已经分配成功。您可以参考以下示例配置init container。 apiVersion: v1 kind: Pod metadata: name: example annotations: yangtse.io/pod-with-eip: "true" yangtse.io/eip-bandwidth-size: "5" yangtse.io/eip-network-type: 5_bgp yangtse.io/eip-charge-mode: bandwidth yangtse.io/eip-bandwidth-name: "xxx" spec: initContainers: - name: init image: busybox:latest command: ['timeout', '60', 'sh', '-c', "until grep -E '[0-9]+' /etc/eipinfo/allocated-ipv4-eip; do echo waiting for allocated-ipv4-eip; sleep 2; done"] volumeMounts: - name: eipinfo mountPath: /etc/eipinfo volumes: - name: eipinfo downwardAPI: items: - path: "allocated-ipv4-eip" fieldRef: fieldPath: metadata.annotations['yangtse.io/allocated-ipv4-eip'] ...

约束限制 绑定EIP的Pod，如果要被公网成功访问，需要添加放通相应请求流量的安全组规则。 单个Pod只能绑定单个EIP。 创建Pod时，可指定相关的annotation配置EIP的属性，创建完成后，更新EIP相关的annotation均无效。 与Pod关联的EIP不要通过弹性公网IP的console或API直接操作（修改名称/删除/解绑/绑定/转包周期等操作），否则可能导致EIP功能异常。 自动创建的EIP被手动删除后，会导致网络异常，需要重建Pod。

通过控制台创建 登录CCE控制台。 单击集群名称进入集群，在左侧选择“工作负载”，在右上角单击“创建工作负载”。 配置工作负载的信息。 基本信息 负载类型：选择任务Job。 负载名称：填写工作负载的名称。请输入1到63个字符的字符串，可以包含小写英文字母、数字和中划线（-），并以小写英文字母开头，小写英文字母或数字结尾。 命名空间：选择工作负载的命名空间，默认为default。您可以单击后面的“创建命名空间”，命名空间的详细介绍请参见创建命名空间。 实例数量：填写实例的数量，即工作负载Pod的数量。 容器配置 容器信息 Pod中可以配置多个容器，您可以单击右侧“添加容器”为Pod配置多个容器。 基本信息：配置容器的基本信息。 参数 说明 容器名称 为容器命名。 更新策略 镜像更新/拉取策略。可以勾选“总是拉取镜像”，表示每次都从镜像仓库拉取镜像；如不勾选则优使用节点已有的镜像，如果没有这个镜像再从镜像仓库拉取。 镜像名称 单击后方“选择镜像”，选择容器使用的镜像。 如果需要使用第三方镜像，请参见使用第三方镜像。 镜像版本 选择需要部署的镜像版本。 CPU配额 CPU资源限制值，即允许容器使用的CPU最大值，防止占用过多资源。 内存配额 内存资源限制值，即允许容器使用的内存最大值。如果超过，容器会被终止。 初始化容器（可选） 选择容器是否作为初始化（Init）容器。初始化（Init）容器不支持设置健康检查。 Init容器是一种特殊容器，可以在Pod中的其他应用容器启动之前运行。每个Pod中可以包含多个容器，同时Pod中也可以有一个或多个先于应用容器启动的Init容器，当所有的Init 容器运行完成时，Pod中的应用容器才会启动并运行。详细说明请参见Init容器。 生命周期（可选）：在容器的生命周期的特定阶段配置需要执行的操作，例如启动命令、启动后处理和停止前处理，详情请参见设置容器生命周期。 环境变量（可选）：支持通过键值对的形式为容器运行环境设置变量，可用于把外部信息传递给Pod中运行的容器，可以在应用部署后灵活修改，详情请参见设置环境变量。 数据存储（可选）：在容器内挂载本地存储或 云存储 ，不同类型的存储使用场景及挂载方式不同，详情请参见存储。 镜像访问凭证：用于访问镜像仓库的凭证，默认取值为default-secret，使用default-secret可访问SWR镜像仓库的镜像。default-secret详细说明请参见default-secret。 高级配置（可选） 标签与注解：以键值对形式为工作负载Pod添加标签或注解，填写完成后需单击“确认添加”。关于标签与注解的作用及配置说明，请参见设置标签与注解。 任务设置： 并行数：任务负载执行过程中允许同时创建的最大实例数，并行数应不大于实例数。 超时时间（秒）：当任务执行超出该时间时，任务将会被标识为执行失败，任务下的所有实例都会被删除。为空时表示不设置超时时间。 完成模式： 非索引：当执行成功的Pod数达到实例数时， Job执行成功。Job中每一个Pod都是同质的，Pod之间是独立无关。 索引：系统会为每个Pod分配索引值，取值为 0 到实例数-1。每个分配了索引的Pod都执行成功，则Job执行成功。索引模式下，Job中的Pod命名遵循$(job-name)-$(index)模式。 挂起任务：默认任务创建后被立即执行。选择挂起任务后，任务创建后处于挂起状态；将其关闭后，任务继续执行。 单击右下角“创建工作负载”。

操作场景 普通任务是一次性运行的短任务，部署完成后即可执行。正常退出（exit 0）后，任务即执行完成。 普通任务是用来控制批处理型任务的资源对象。批处理业务与长期伺服业务（Deployment、Statefulset）的主要区别是： 批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。Job管理的Pod根据用户的设置把任务成功完成就自动退出了。成功完成的标志根据不同的spec.completions策略而不同，即： 单Pod型任务有一个Pod成功就标志完成。 定数成功型任务保证有N个任务全部成功。 工作队列型任务根据应用确认的全局成功而标志成功。

监控 在此处，您可以方便地查看实例在近1小时、近8小时、近24小时以及自定义时间段内各维度资源的使用情况。如需查看更多监控信息，请单击“查看全部仪表盘”，跳转至“仪表盘”页面，相应指导请参见使用仪表盘。 图4 Pod监控 CPU相关指标 CPU：Pod 的所有容器在不同的时间段 CPU 使用总量占 Pod 的所有容器 CPU Limit 总量的比例。 CPU 使用量：Pod 已经使用的 CPU 核数。 CPU 申请量：Pod CPU Request 值。 CPU 限制量：Pod CPU Limit 值，使用量接近该值时容器的 CPU 资源会被限流，影响容器性能。 内存相关指标 内存使用率：Pod 的所有容器在不同的时间段内存使用总量占 Pod 的所有容器内存 Limit 总量。 内存使用量：Pod 已经使用的内存量。 内存申请量：Pod 内存 Request 值。 内存限制量：Pod 内存 Limit 值, 使用量到达该值时会导致容器 OOM。 网络相关指标 网络总流出速率：Pod 的所有容器每秒钟发送的总字节数。 网络总流入速率：Pod 的所有容器每秒钟接收的总字节数。 容器相关指标 容器CPU使用率：Pod 的每个容器在不同的时间段的 CPU 使用量占它们的 CPU Limit 量的比例。 容器内存使用率：Pod 的每个容器在不同的时间段的内存使用量占它们的内存 Limit 量的比例。 容器CPU受限：Pod 的每个容器在不同的时间段的 CPU 受限时间所占的比例。 容器网络丢包率：Pod 的每个的容器在不同的时间段接收丢失的数据包总量占接收的数据包总量的比例。 其他指标 Pod 历史状态：Pod 在不同时间段所处的状态。 容器历史状态：Pod 的每个容器在不同的时间段所处的状态。

Pod列表 Pod列表中包含Pod名称、状态、命名空间、Pod IP、所在节点、重启次数、CPU申请/限制、内存申请/限制、CPU使用率，以及内存使用率等信息。 图1 Pod列表 您可以利用列表上方的命名空间，以及搜索栏中的Pod名称、状态、Pod IP和所在节点进行筛选，快速定位所需的Pod。 您也可以单击“导出”按钮来导出全部Pod数据，或者选择部分Pod进行导出，此时仅导出所选中的数据。导出的文件为“.xlsx”格式，文件命名中包含时间戳。

概览 单击Pod名称，您可以方便地查看资源概况，包括Pod状态、容器数量（异常/总数）以及异常事件。此外，还可以浏览Pod近一小时的监控概览，其中包括CPU使用率、内存使用率和网络流入/流出速率这些常见的监控指标。 图2 资源概况和监控概览 同时，概览页面还提供了容器使用趋势功能，您可以从中了解Pod中各容器的CPU使用率、CPU使用量、内存使用率和内存使用量（在图表右上角切换对应指标），并且支持查看降序Top5和升序Top5数据（在图表左上角进行切换）。 如需了解更多指标，请前往监控页面查看。

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

操作步骤 集群升级步骤包括：升级前检查、备份、配置与升级、升级后处理。 登录CCE控制台，单击集群名称进入集群。 在左侧导航栏选择“集群升级”。 根据当前集群版本，系统将为您生成最佳升级路径，您可以在该路径中选择需要升级的版本，确认集群版本差异、插件版本等信息，然后单击“前往升级”。 进行升级前检查，单击“开始检查”并确认。如集群中存在异常项或风险项，请根据页面提示的检查结果进行处理，处理完成后需重新进行升级前检查。 异常项：请查看页面提示的解决方案并处理异常后，重新进行升级前检查。 风险项：表示该结果可能会影响集群升级结果，请您查看风险说明并确认您是否处于风险影响范围。如确认无风险，可单击该风险项后的“确认”按钮，手动跳过该风险项，然后重新进行升级前检查。 待升级前检查通过后，单击“下一步”。 进行集群备份。集群升级过程中将自动进行etcd数据备份，您可手动进行控制面备份，以加快控制面升级失败时的回滚速度，如无需手动备份可直接单击“下一步”。 备份方式 备份对象 备份方式 备份时间 回滚时间 说明 etcd数据备份 etcd数据 升级流程中自动备份 1-5min 2h 必选备份，升级过程中自动进行，用户无需关注 EVS快照备份 控制面数据，包括组件镜像、配置、日志以及etcd数据 通过页面一键备份（手动触发） 1-5min 20min - 配置升级参数。 插件升级配置：此处列出了您的集群中已安装的插件。在集群升级过程中系统会自动升级已选择的插件，以兼容升级后的集群版本，您可以单击插件右侧的“配置”重新定义插件参数。 插件右侧如有标记，表示当前插件不能同时兼容集群升级起始和目标版本，在集群版本升级完成后将为您升级该插件 ，该插件在集群升级过程中可能无法正常使用。 配置完成后，单击“立即升级”按钮，并确认升级操作后集群开始升级。您可以在页面下方查看版本升级的进程。 若在集群升级过程中出现升级失败的提示，请参照提示信息修复问题后重试。 升级完成后，单击“下一步”，请根据页面提示的检查项进行升级后验证。确认所有检查项均正常后，可单击“完成”按钮，并确认完成升级后检查，详情请参见升级后验证。 您可以在集群列表页面查看集群当前的Kubernetes版本，确认升级成功。

约束限制 开启固定EIP功能需要和Pod自动创建EIP功能配合使用，详情请参见为Pod配置EIP。 目前只支持StatefulSet类型的Pod或直接创建的Pod固定EIP，暂不支持Deployment等其他类型的工作负载配置Pod固定EIP。 固定EIP创建后，生命周期内（如过期时间未到/Pod还在使用中）不支持通过Pod修改EIP属性。 对Pod的EIP地址无明确要求的业务不建议配置固定EIP，因为配置了固定EIP的Pod，Pod重建的耗时会略微变长。

使用场景 根据使用场景不同，文件存储支持以下挂载方式： 通过静态存储卷使用已有文件存储：即静态创建的方式，需要先使用已有的文件存储创建PV，然后通过PVC在工作负载中挂载存储。适用于已有可用的底层存储或底层存储需要包周期的场景。 通过动态存储卷使用文件存储：即动态创建的方式，无需预先创建文件存储，在创建PVC时通过指定存储类（StorageClass），即可自动创建文件存储和对应的PV对象。适用于无可用的底层存储，需要新创建的场景。

文件存储介绍 CCE Autopilot支持将弹性文件存储（SFS）创建的存储卷挂载到容器的某一路径下，以满足数据持久化需求，SFS存储卷适用于多读多写的持久化存储，适用大容量扩展以及成本敏感型的业务场景，包括 媒体处理 、内容管理、大数据分析和分析工作负载程序等。SFS文件系统不适合海量小文件业务，推荐使用SFS Turbo文件系统。 SFS为用户提供一个完全托管的共享文件存储，能够弹性伸缩至PB规模，具备高可用性和持久性，为海量数据、高带宽型应用提供有力支持。 符合标准文件协议：用户可以将文件系统挂载给服务器，像使用本地文件目录一样。 数据共享：多台服务器可挂载相同的文件系统，数据可以共享操作和访问。 私有网络：数据访问必须在数据中心内部网络中。 容量与性能：单文件系统容量较高（PB级），性能极佳（IO读写时延ms级）。 应用场景：适用于多读多写（ReadWriteMany）场景下的各种工作负载（Deployment/StatefulSet）和普通任务（Job）使用，主要面向高性能计算、媒体处理、内容管理和Web服务、大数据和分析应用程序等场景。

操作场景 负载均衡（LoadBalancer）类型的服务可以通过弹性负载均衡（ELB）从公网访问到工作负载，与弹性IP方式相比提供了高可靠的保障。负载均衡访问方式由公网弹性负载均衡服务地址以及设置的访问端口组成，例如“10.117.117.117:80”。 在使用CCE Autopilot集群 + 独享型ELB实例时，支持ELB直通Pod，使部署在容器中的业务时延降低、性能无损耗。 从集群外部访问时，从ELB直接转发到Pod；集群内部访问可通过Service转发到Pod。 图1 ELB直通容器

创建LoadBalancer类型Service 登录CCE控制台，单击集群名称进入集群。 在左侧导航栏中选择“服务”，在右上角单击“创建服务”。 设置参数。 Service名称：自定义服务名称，可与工作负载名称保持一致。 访问类型：选择“负载均衡 LoadBalancer”。 命名空间：工作负载所在命名空间。 服务亲和： 集群级别：集群下所有节点的IP+访问端口均可以访问到此服务关联的负载，服务访问会因路由跳转导致一定性能损失，且无法获取到客户端源IP。 选择器：添加标签，Service根据标签选择Pod，填写后单击“确认添加”。也可以引用已有工作负载的标签，单击“引用负载标签”，在弹出的窗口中选择负载，然后单击“确定”。 负载均衡器：选择弹性负载均衡的类型、创建方式。 ELB类型可选择“独享型”，独享型ELB可以根据支持的协议类型选择“网络型（TCP/UDP）”、“应用型（HTTP/HTTPS）”或“网络型（TCP/UDP）&应用型（HTTP/HTTPS）”。 创建方式可选择“选择已有”或“自动创建”。不同创建方式的配置详情请参见表1。 表1 ELB配置 创建方式 配置 选择已有 仅支持选择与集群在同一个VPC下的ELB实例。如果没有可选的ELB实例，请单击“创建负载均衡器”跳转到ELB控制台创建。 自动创建 实例名称：请填写ELB名称。 企业项目：该参数仅对开通企业项目的企业客户账号显示。企业项目是一种云资源管理方式，企业项目管理服务提供统一的云资源按项目管理，以及项目内的资源管理、成员管理。 可用区：可以选择在多个可用区创建负载均衡实例，提高服务的可用性。如果业务需要考虑容灾能力，建议选择多个可用区。 前端子网：用于分配ELB实例对外服务的IP地址。 后端子网：用于与后端服务建立连接的IP地址。 网络型规格/应用型规格/规格： 弹性规格：适用于业务用量波动较大的场景，按实际使用量收取每小时使用的容量费用。 固定规格：适用于业务用量较为稳定的场景，按固定规格折算收取每小时使用的容量费用。 弹性公网IP：选择“自动创建”时，可配置公网带宽的计费方式及带宽大小。 资源标签：通过为资源添加标签，可以对资源进行自定义标记，实现资源的分类。您可以在TMS中创建“预定义标签”，预定义标签对所有支持标签功能的服务资源可见，通过使用预定义标签可以提升标签创建和迁移效率。v1.27.5-r0、v1.28.3-r0及以上版本集群支持。 负载均衡配置：您可以单击负载均衡配置的“编辑”图标配置ELB实例的参数，在弹出窗口中配置ELB实例的参数。 分配策略：可选择加权轮询算法、加权最少连接或源IP算法。 加权轮询算法：根据后端服务器的权重，按顺序依次将请求分发给不同的服务器。它用相应的权重表示服务器的处理性能，按照权重的高低以及轮询方式将请求分配给各服务器，相同权重的服务器处理相同数目的连接数。常用于短连接服务，例如HTTP等服务。 加权最少连接：最少连接是通过当前活跃的连接数来估计服务器负载情况的一种动态调度算法。加权最少连接就是在最少连接数的基础上，根据服务器的不同处理能力，给每个服务器分配不同的权重，使其能够接受相应权值数的服务请求。常用于长连接服务，例如数据库连接等服务。 源IP算法：将请求的源IP地址进行Hash运算，得到一个具体的数值，同时对后端服务器进行编号，按照运算结果将请求分发到对应编号的服务器上。这可以使得对不同源IP的访问进行负载分发，同时使得同一个客户端IP的请求始终被派发至某特定的服务器。该方式适合负载均衡无cookie功能的TCP协议。 会话保持类型：默认不启用，可选择“源IP地址”。基于源IP地址的简单会话保持，即来自同一IP地址的访问请求转发到同一台后端服务器上。 当分配策略使用源IP算法时，不支持设置会话保持。 健康检查：设置负载均衡的健康检查配置。 全局检查：全局检查仅支持使用相同协议的端口，无法对多个使用不同协议的端口生效，建议使用“自定义检查”。 自定义检查：在端口配置中对多种不同协议的端口设置健康检查。 表2 健康检查参数 参数 说明 协议 当端口配置协议为TCP时，支持TCP和HTTP协议；当端口配置协议为UDP时，支持UDP协议。 检查路径（仅HTTP健康检查协议支持）：指定健康检查的URL地址。检查路径只能以/开头，长度范围为1-80。 端口 健康检查默认使用业务端口作为健康检查的端口；您也可以重新指定端口用于健康检查，重新指定端口会为服务增加一个名为cce-healthz的服务端口配置。 容器端口：使用独享型负载均衡关联ENI实例时，容器端口作为健康检查的检查端口。取值范围为1-65535。 检查周期（秒） 每次健康检查响应的最大间隔时间，取值范围为1-50。 超时时间（秒） 每次健康检查响应的最大超时时间，取值范围为1-50。 最大重试次数 健康检查最大的重试次数，取值范围为1-10。 端口配置： 协议：请根据业务的协议类型选择。 服务端口：Service使用的端口，端口范围为1-65535。 容器端口：工作负载程序实际监听的端口，需用户确定。例如nginx默认使用80端口。 监听器前端协议：ELB监听器的前端协议，是客户端与负载均衡监听器建立流量分发连接所使用的协议。当选择独享型负载均衡器类型时，包含“应用型（HTTP/HTTPS）”方可支持配置HTTP/HTTPS。 健康检查：健康检查选项设置为“自定义检查”时，可以为不同协议的端口配置健康检查，参数说明请参见表2。 在创建LoadBalancer类型Service时，会自动生成一个随机节点端口号（NodePort）。 注解：LoadBalancer类型Service有一些CCE定制的高级功能，通过注解annotations实现，具体注解的内容请参见使用Annotation配置负载均衡。 单击“确定”，创建Service。

Kubernetes中的 域名 解析逻辑 DNS策略可以在每个pod基础上进行设置，目前，Kubernetes支持Default、ClusterFirst、ClusterFirstWithHostNet和None四种DNS策略，具体请参见Service与Pod的DNS。这些策略在pod-specific的dnsPolicy字段中指定。 “Default”：如果dnsPolicy被设置为“Default”，则名称解析配置将从pod运行的节点继承。 自定义上游域名服务器和存根域不能够与这个策略一起使用。 “ClusterFirst”：如果dnsPolicy被设置为“ClusterFirst”，任何与配置的集群域后缀不匹配的DNS查询（例如，www.kubernetes.io）将转发到从该节点继承的上游名称服务器。集群管理员可能配置了额外的存根域和上游DNS服务器。 “ClusterFirstWithHostNet”：对于使用hostNetwork运行的Pod，您应该明确设置其DNS策略“ClusterFirstWithHostNet”。 “None”：它允许Pod忽略Kubernetes环境中的DNS设置。应使用dnsConfigPod规范中的字段提供所有DNS设置 。 Kubernetes 1.10及以上版本，支持Default、ClusterFirst、ClusterFirstWithHostNet和None四种策略；低于Kubernetes 1.10版本，仅支持default、ClusterFirst和ClusterFirstWithHostNet三种。 “Default”不是默认的DNS策略。如果dnsPolicy的Flag没有特别指明，则默认使用“ClusterFirst”。 路由请求流程： 未配置存根域：没有匹配上配置的集群域名后缀的任何请求，例如 “www.kubernetes.io”，将会被转发到继承自节点的上游域名服务器。 已配置存根域：如果配置了存根域和上游DNS服务器，DNS查询将基于下面的流程对请求进行路由： 查询首先被发送到coredns中的DNS缓存层。 从缓存层，检查请求的后缀，并根据下面的情况转发到对应的DNS上： 具有集群后缀的名字（例如“.cluster.local”）：请求被发送到coredns。 具有存根域后缀的名字（例如“.acme.local”）：请求被发送到配置的自定义DNS解析器（例如：监听在 1.2.3.4）。 未能匹配上后缀的名字（例如“widget.com”）：请求被转发到上游DNS。 图1 路由请求流程

插件简介 CoreDNS域名解析插件是一款通过链式插件的方式为Kubernetes提供域名解析服务的DNS服务器。 CoreDNS是由CNCF孵化的开源软件，用于Cloud-Native环境下的DNS服务器和服务发现解决方案。CoreDNS实现了插件链式架构，能够按需组合插件，运行效率高、配置灵活。在Kubernetes集群中使用CoreDNS能够自动发现集群内的服务，并为这些服务提供域名解析。同时，通过级联云上DNS服务器，还能够为集群内的工作负载提供外部域名的解析服务。 该插件为系统资源插件，在创建集群时默认安装。 目前CoreDNS已经成为社区Kubernetes集群推荐的DNS服务器解决方案。 CoreDNS官网：https://coredns.io/ 开源社区地址：https://github.com/coredns/coredns DNS详细使用方法请参见DNS。

通过控制台创建 登录CCE控制台。 单击集群名称进入集群，在左侧选择“工作负载”，在右上角单击“创建工作负载”。 配置工作负载的信息。 基本信息 负载类型：选择无状态工作负载Deployment。 负载名称：填写工作负载的名称。请输入1到63个字符的字符串，可以包含小写英文字母、数字和中划线（-），并以小写英文字母开头，小写英文字母或数字结尾。 命名空间：选择工作负载的命名空间，默认为default。您可以单击后面的“创建命名空间”，命名空间的详细介绍请参见创建命名空间。 实例数量：填写实例的数量，即工作负载Pod的数量。 容器配置 容器信息 Pod中可以配置多个容器，您可以单击右侧“添加容器”为Pod配置多个容器。 基本信息：配置容器的基本信息。 参数 说明 容器名称 为容器命名。 更新策略 镜像更新/拉取策略。可以勾选“总是拉取镜像”，表示每次都从镜像仓库拉取镜像；如不勾选则优使用节点已有的镜像，如果没有这个镜像再从镜像仓库拉取。 镜像名称 单击后方“选择镜像”，选择容器使用的镜像。 如果需要使用第三方镜像，请参见使用第三方镜像。 镜像版本 选择需要部署的镜像版本。 CPU配额 CPU资源限制值，即允许容器使用的CPU最大值，防止占用过多资源。 内存配额 内存资源限制值，即允许容器使用的内存最大值。如果超过，容器会被终止。 初始化容器（可选） 选择容器是否作为初始化（Init）容器。初始化（Init）容器不支持设置健康检查。 Init容器是一种特殊容器，可以在Pod中的其他应用容器启动之前运行。每个Pod中可以包含多个容器，同时Pod中也可以有一个或多个先于应用容器启动的Init容器，当所有的Init 容器运行完成时，Pod中的应用容器才会启动并运行。详细说明请参见Init容器。 生命周期（可选）：在容器的生命周期的特定阶段配置需要执行的操作，例如启动命令、启动后处理和停止前处理，详情请参见设置容器生命周期。 健康检查（可选）：根据需求选择是否设置存活探针、就绪探针及启动探针，详情请参见设置容器健康检查。 环境变量（可选）：支持通过键值对的形式为容器运行环境设置变量，可用于把外部信息传递给Pod中运行的容器，可以在应用部署后灵活修改，详情请参见设置环境变量。 数据存储（可选）：在容器内挂载本地存储或云存储，不同类型的存储使用场景及挂载方式不同，详情请参见存储。 安全设置（可选）：对容器权限进行设置，保护系统和其他容器不受其影响。请输入用户ID，容器将以当前用户权限运行。 镜像访问凭证：用于访问镜像仓库的凭证，默认取值为default-secret，使用default-secret可访问SWR镜像仓库的镜像。default-secret详细说明请参见default-secret。 服务配置（可选） 服务（Service）可为Pod提供外部访问。每个Service有一个固定IP地址，Service将访问流量转发给Pod，而且Service可以为这些Pod自动实现负载均衡。 您也可以在创建完工作负载之后再创建Service，不同类型的Service概念和使用方法请参见服务（Service）。 高级配置（可选） 升级策略：指定工作负载的升级方式及升级参数，支持滚动升级和替换升级，详情请参见设置工作负载升级策略。 标签与注解：以键值对形式为工作负载Pod添加标签或注解，填写完成后需单击“确认添加”。关于标签与注解的作用及配置说明，请参见设置标签与注解。 DNS配置：为工作负载单独配置DNS策略，详情请参见工作负载DNS配置说明。 单击右下角“创建工作负载”。

通过kubectl命令行创建 本节以nginx工作负载为例，说明kubectl命令创建工作负载的方法。 Autopilot集群暂不支持配置节点亲和与反亲和，所以当您使用kubectl命令行创建工作负载时，为避免Pod创建失败，请不要配置affinity字段。 请参见通过kubectl连接集群，使用kubectl连接集群。 创建一个名为nginx-deployment.yaml的描述文件。其中，nginx-deployment.yaml为自定义名称，您可以随意命名。 vi nginx-deployment.yaml 描述文件内容如下。此处仅为示例，deployment的详细说明请参见kubernetes官方文档。 apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: replicas: 1 selector: matchLabels: app: nginx strategy: type: RollingUpdate template: metadata: labels: app: nginx spec: containers: - image: nginx #若使用“开源镜像中心”的镜像，可直接填写镜像名称；若使用“我的镜像”中的镜像，请在SWR中获取具体镜像地址。 imagePullPolicy: Always name: nginx imagePullSecrets: - name: default-secret 以上yaml字段解释如表1。 表1 deployment字段详解 字段名称 字段说明 必选/可选 apiVersion 表示API的版本号。 说明： 请根据集群版本输入： 1.17及以上版本的集群中无状态应用apiVersion格式为apps/v1 1.15及以下版本的集群中无状态应用apiVersion格式为extensions/v1beta1 必选 kind 创建的对象类别。 必选 metadata 资源对象的元数据定义。 必选 name deployment的名称。 必选 spec 用户对deployment的详细描述的主体部分都在spec中给出。 必选 replicas 实例数量。 必选 selector 定义Deployment可管理的容器实例。 必选 strategy 升级类型。当前支持两种升级方式，默认为滚动升级。 RollingUpdate：滚动升级。 ReplaceUpdate：替换升级。 可选 template 描述创建的容器实例详细信息。 必选 metadata 元数据。 必选 labels metadata.labels定义容器标签。 可选 spec: containers image（必选）：容器镜像名称。 imagePullPolicy（可选）：获取镜像的策略，可选值包括Always（每次都尝试重新下载镜像）、Never（仅使用本地镜像）、IfNotPresent（如果本地有该镜像，则使用本地镜像，本地不存在时下载镜像），默认为Always。 name（必选）：容器名称。 必选 imagePullSecrets Pull镜像时使用的secret名称。若使用私有镜像，该参数为必选。 需要Pull SWR容器镜像 仓库的镜像时，参数值固定为default-secret。 当Pull第三方镜像仓库的镜像时，需设置为创建的secret名称。 可选 创建deployment。 kubectl create -f nginx-deployment.yaml 回显如下表示已开始创建deployment。 deployment "nginx" created 查看deployment状态。 kubectl get deployment deployment状态显示为Running，表示deployment已创建成功。 NAME READY UP-TO-DATE AVAILABLE AGE nginx 1/1 1 1 4m5s 参数解析： NAME：工作负载名称。 READY：表示工作负载的可用状态，显示为“可用Pod个数/期望Pod个数”。 UP-TO-DATE：指当前已经完成更新的副本数。 AVAILABLE：可用的Pod个数。 AGE：已经运行的时间。 若工作负载（即deployment）需要被访问，您需要设置访问方式，具体请参见服务（Service）创建对应服务。

注意事项 升级集群前，您需要知晓以下事项： 请务必慎重并选择合适的时间段进行升级，以减少升级对您的业务带来的影响。 集群升级前，请参考Kubernetes版本发布记录了解每个集群版本发布的特性以及差异，否则可能因为应用不兼容新集群版本而导致升级后异常。例如，您需要检查集群中是否使用了目标版本废弃的API，否则可能导致升级后调用接口失败。 集群升级时，以下几点注意事项可能会对您的业务存在影响，请您关注： 集群升级前，请确认集群中未执行高危操作，否则可能导致集群升级失败或升级后配置丢失。例如，常见的高危操作有通过ELB控制台修改CCE管理的监听器配置等。建议您通过CCE控制台修改相关配置，以便在升级时自动继承。