华为云用户手册

环境变量 环境变量是容器运行环境中设定的一个变量。 环境变量为应用提供极大的灵活性，您可以在应用程序中使用环境变量，在创建容器时为环境变量赋值，容器运行时读取环境变量的值，从而做到灵活的配置，而不是每次都重新编写应用程序制作镜像。 另外，您还可以使用ConfigMap和Secret作为环境变量，详细信息请参见使用ConfigMap和Secret提高配置灵活性。 环境变量的使用方法如下所示，配置spec.containers.env字段即可。 apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - image: nginx:1 name: container-0 resources: limits: cpu: 500m memory: 1024Mi requests: cpu: 500m memory: 1024Mi env: # 环境变量 - name: env_key value: env_value - name: pod_name valueFrom: # 引用Pod的名称 fieldRef: fieldPath: metadata.name - name: pod_ip valueFrom: # 引用Pod的IP地址 fieldRef: fieldPath: status.podIP imagePullSecrets: - name: imagepull-secret 父主题： Pod

路由到多个服务 Ingress可以同时路由到多个服务，配置如下所示。 当访问“http://foo.bar.com/foo”时，访问的是“s1:80”后端。 当访问“http://foo.bar.com/bar”时，访问的是“s2:80”后端。 spec: rules: - host: foo.bar.com # host地址 http: paths: - path: "/foo" backend: serviceName: s1 servicePort: 80 - path: "/bar" backend: serviceName: s2 servicePort: 80

创建Ingress 使用http协议创建Ingress 下面例子中，关联的backend为“nginx:8080”，当访问“http://10.10.10.10:6071/”时，流量转发“nginx:8080”对应的Service，从而将流量转发到对应负载中的Pod。 apiVersion: extensions/v1beta1 # Ingress的版本 kind: Ingress metadata: name: nginx labels: app: nginx isExternal: "true" # 系统预留字段，必选参数，取值必须为 "true" zone: data # 系统预留字段，数据平面模式，必选参数，取值必须为data annotations: kubernetes.io/elb.id: 2d48d034-6046-48db-8bb2-53c67e8148b5 # ELB实例的ID，必选参数 kubernetes.io/elb.ip: 192.168.137.182 # ELB实例的IP，可选参数 kubernetes.io/elb.port: '6071' # ELB实例的端口，必选参数 spec: rules: # 路由规则 - http: # 使用http协议 paths: - path: / # 路由 backend: serviceName: nginx # 转发到的Service名称 servicePort: 8080 # 转发到的Service端口 Ingress中还可以设置外部 域名 ，这样您就可以通过域名来访问到ELB，进而访问到后端服务。 域名访问依赖于域名解析，需要您将域名解析指向ELB实例的IP地址，例如您可以使用云解析服务 DNS来实现域名解析。 spec: rules: - host: www.example.com # 域名 http: paths: - path: / backend: serviceName: nginx servicePort: 80 使用https协议创建Ingress 下面例子中，关联的backend为“nginx:8080”，当访问“https://10.10.10.10:6071/”时，流量转发“nginx:8080”对应的Service，从而将流量转发到对应负载中的Pod。 apiVersion: extensions/v1beta1 kind: Ingress metadata: annotations: kubernetes.io/elb.id: 2d48d034-6046-48db-8bb2-53c67e8148b5 kubernetes.io/elb.ip: 192.168.137.182 kubernetes.io/elb.port: '6071' labels: app: nginx isExternal: 'true' zone: data name: nginx spec: rules: - http: paths: - backend: serviceName: nginx servicePort: 8080 path: / tls: - secretName: cci-sslcertificate-20214221 # 上传的SSL证书的名称

直接访问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的类型

使用GPU 云容器实例支持使用GPU（必须在GPU类型命名空间下），申请GPU资源的方法非常简单，只需要在容器定制中申请GPU字段即可。 具体的规格信息请参考约束与限制中的“Pod规格”。 您需要设置Pod的metadata.annotations中添加cri.cci.io/gpu-driver字段，指定使用哪个版本显卡驱动，取值如下： gpu-460.106 gpu-418.126 如下示例创建一个容器规格为NVIDIA V100 16G x 1，CPU 4核，内存32GiB的Pod。 apiVersion: v1 kind: Pod metadata: name: gpu-test annotations: cri.cci.io/gpu-driver: gpu-418.126 # 指定GPU显卡的驱动版本 spec: containers: - image: tensorflow:latest name: container-0 resources: limits: cpu: 4000m # 4核 memory: 32Gi nvidia.com/gpu-tesla-v100-16GB: 1 # 申请GPU资源，支持 1、2、4、8，代表几块显卡 requests: cpu: 4000m # 4核 memory: 32Gi nvidia.com/gpu-tesla-v100-16GB: 1 imagePullSecrets: - name: imagepull-secret

删除Pod 删除pod时，Kubernetes终止Pod中所有容器。 Kubernetes向进程发送SIGTERM信号并等待一定的秒数（默认为30）让容器正常关闭。 如果它没有在这个时间内关闭，Kubernetes会发送一个SIGKILL信号杀死该进程。 Pod的停止与删除有多种方法，比如按名称删除，如下所示。 $ kubectl delete po nginx -n $namespace_name pod "nginx" deleted 同时删除多个Pod。 $ kubectl delete po pod1 pod2 -n $namespace_name 删除所有Pod。 $ kubectl delete po --all -n $namespace_name pod "nginx" deleted 根据Label删除Pod，Label详细内容将会在下一个章节介绍。 $ kubectl delete po -l app=nginx -n $namespace_name pod "nginx" deleted

查询Pod详情 Pod创建完成后，可以使用kubectl get pods命令查询Pod的状态，如下所示。 $ kubectl get pods -n $namespace_name NAME READY STATUS RESTARTS AGE nginx 1/1 Running 0 40s 可以看到此处nginx这个Pod的状态为Running，表示正在运行；READY为1/1，表示这个Pod中有1个容器，其中1个容器的状态为Ready。 可以使用kubectl get命令查询具体Pod的配置信息，如下所示，-o yaml表示以YAML格式返回，还可以使用 -o json，以JSON格式返回。 $ kubectl get pod nginx -o yaml -n $namespace_name 您还可以使用kubectl describe命令查看Pod的详情。 $ kubectl describe pod nginx -n $namespace_name

创建Pod kubernetes资源可以使用YAML描述（如果您对YAML格式不了解，可以参考YAML语法），也可以使用JSON，如下示例描述了一个名为nginx的Pod，这个Pod中包含一个名为container-0的容器，使用nginx:alpine镜像，使用的资源为0.5核CPU、1024M内存。 apiVersion: v1 # Kubernetes的API Version kind: Pod # Kubernetes的资源类型 metadata: name: nginx # Pod的名称 spec: # Pod的具体规格（specification） containers: - image: nginx:alpine # 使用的镜像为 nginx:alpine name: container-0 # 容器的名称 resources: # 申请容器所需的资源，云容器实例中limits与requests的值必须相同 limits: cpu: 500m # 0.5核 memory: 1024Mi requests: cpu: 500m # 0.5核 memory: 1024Mi imagePullSecrets: # 拉取镜像使用的证书，必须为imagepull-secret - name: imagepull-secret 如上面YAML的注释，YAML描述文件主要为如下部分： metadata：一些名称/标签/namespace等信息 spec：Pod实际的配置信息，包括使用什么镜像，volume等 如果去查询Kubernetes的资源，您会看到还有一个status字段，status描述kubernetes资源的实际状态，创建时不需要配置。这个示例是一个最小集，其他参数定义后面会逐步介绍。 kubernetes资源的参数定义的解释，您可以通过具体资源的API参考查询对应的解释。 Pod定义好后就可以使用kubectl创建，如果上面YAML文件名称为nginx.yaml，则创建命令如下所示，-f 表示使用文件方式创建。 $ kubectl create -f nginx.yaml -n $namespace_name pod/nginx created

什么是Pod Pod是Kubernetes创建或部署的最小单位。一个Pod封装一个或多个容器（container）、存储资源（volume）、一个独立的网络IP以及管理控制容器运行方式的策略选项。 Pod使用主要分为两种方式： Pod中运行一个容器。这是Kubernetes最常见的用法，您可以将Pod视为单个封装的容器，但是Kubernetes是直接管理Pod而不是容器。 Pod中运行多个需要耦合在一起工作、需要共享资源的容器。通常这种场景下是应用包含一个主容器和几个辅助容器（SideCar Container），如图1所示，例如主容器为一个web服务器，从一个固定目录下对外提供文件服务，而辅助的容器周期性的从外部下载文件存到这个固定目录下。 图1 Pod 实际使用中很少直接创建Pod，而是使用Kubernetes中称为Controller的抽象层来管理Pod实例，例如Deployment和Job。Controller可以创建和管理多个Pod，提供副本管理、滚动升级和自愈能力。通常，Controller会使用Pod Template来创建相应的Pod。

文档导读 本文档分为如下几个部分。 使用kubectl 介绍如何在云容器实例中配置kubectl。CCI支持使用原生kubectl或定制的kubectl来创建负载等资源，建议优先选用原生kubectl。 Namespace和Network 介绍云容器示例中Namespace与Network的概念。 Pod 介绍Pod相关概念，以及如何使用Pod。 Label 介绍Label的作用，以及如何使用Label。 无状态负载（Deployment） 介绍Deployment的使用场景，如何使用Deployment将容器镜像部署到云容器实例中。 访问负载 介绍Service和Ingress两种管理负载访问的资源对象，使用Service和Ingress解决负载访问的问题。 Service：定义一系列Pod以及访问这些Pod的策略的一层抽象。 Ingress：管理外部访问的资源对象。 使用存储 介绍负载中如何使用存储，即如何容器中如何使用存储卷。包括如何使用云硬盘（EVS）、弹性文件服务（SFS）、对象存储（OBS）。 使用ConfigMap和Secret 介绍如何使用ConfigMap和Secret。 ConfigMap和Secret用于保存配置信息和敏感信息，从而提高负载配置的易用性和灵活性。 使用Job和CronJob 介绍如何使用Job。Job适用于一次性任务的场景。

日志出现重复/丢失的原因 日志出现重复 原因一：日志文件转储，且转储文件仍被匹配到。 详细说明：如果配置日志路径文件名中有通配符，如配置为/tmp/*.log，当/tmp/test.log文件转储为/tmp/test.001.log后，因仍被通配规则匹配到，会被视为新文件，则会被重新采集。 日志出现丢失 原因一：日志文件的存在时间小于5秒。 详细说明：CCI感知日志文件的周期为5秒。日志文件从创建到被删除或重命名的时间小于5秒，则可能该日志文件不会被采集。 父主题： 日志采集类

CCI服务的开源第三方中包含的公网地址声明是什么？ CCI服务提供 Serverless Container（无服务器容器）引擎，让用户无需创建和管理服务器集群即可直接运行容器。在CCI服务组件开源依赖中，包含三方开源依赖k8s.io/kubernetes、go.etcd.io/etcd，其中涉及"http://metadata.google.internal."、"https://www.googleapis.com"、"https://storage.googleapis.com"等域名的公网地址均为开源仓内自带的公网地址，CCI服务不涉及与此类公网地址的连接，也不会与此类公网地址进行任何数据交换。 k8s.io/kubernetes开源社区链接：https://github.com/kubernetes/kubernetes go.etcd.io/etcd开源社区链接：https://github.com/etcd-io/etcd 父主题： 产品咨询类

CCI资源包中的核时怎么理解？ 1 核*时 = 1 * 3600（核*秒） 1 核*时 ：1核的CPU连续跑1个小时所用的资源量 1 核*秒： 1核的CPU连续跑1秒所用的资源量 案例一： 假设用户的Deployment是2.5核的，连续运行了2个小时，那么它所消耗的资源量为：2.5 * 2 = 5（核*时）= 5* 3600（核*秒）。 案例二： 假设当前是730核*时，那么最大可以1小时内运行一个730核的容器，也可以730小时内运行一个1核的容器。 详细信息您可以参考计费说明。 父主题： 基本概念类

使用CCI集群，在容器内部执行systemctl命令，需要以特权模式（--privileged=true）来启动容器是否支持？ 目前，CCI尚不支持特权模式。 特权容器主要场景是让容器共享、操作宿主机的设备，CCI是基于kata的hypervisor虚拟化级别隔离，所以宿主机的资源对容器完全隔离。 其他场景，推荐通过k8s原生SecurityContext中更细粒度的权限策略来控制，按需使用，保障客户容器运行环境安全可靠。 父主题： 容器工作负载类

如何解决Connection timed out问题？ 问题现象： CCI实例创建正常，使用python django smtp服务发送邮件时，一直提示“[Errno 110] Connection timed out”错误。 问题原因： 客户仅购买了ELB服务未购买NAT网关服务，故只能从外部访问容器。购买NAT网关后，才可以从容器内部访问外部网络。 为了确保良好的网络安全环境，华为云对25端口对外发送做了限制。 解决方法： 方法一：使用NAT网关服务，该服务能够为VPC内的容器实例提供 网络地址转换 （Network Address Translation）服务，SNAT功能通过绑定弹性公网IP，实现私有IP向公有IP的转换，可实现VPC内的容器实例共享弹性公网IP访问Internet。详情请参见从容器访问公网。 方法二：联系技术人员，放通客户新申请的弹性公网IP的25端口。 父主题： 网络管理类

创建方式 表2 创建方式不同 云容器引擎CCE 云容器实例CCI CCE是基于Kubernetes的托管式容器管理服务，可以提供原生Kubernetes体验，可以一键创建原生Kubernetes集群，与社区能力基本一致。 使用CCE，您需要创建集群和节点，简单、低成本、高可用，无需管理Master节点。 CCI提供 Serverless Container引擎，在华为云上部署容器时，您不需要购买和管理E CS ，可以直接在华为云上运行容器和Pod，为您省去底层ECS的运维和管理工作。 使用CCI，您无需创建集群，无需创建和管理Master节点及Work节点，可直接启动应用程序。

基本介绍 表1 CCE和CCI基本介绍 云容器引擎CCE 云容器实例CCI 云容器引擎（Cloud Container Engine，简称CCE）提供高度可扩展的、高性能的企业级Kubernetes集群，支持运行Docker容器，提供了Kubernetes集群管理、容器应用全生命周期管理、应用服务网格、Helm应用模板、插件管理、应用调度、监控与运维等容器全栈能力，为您提供一站式容器平台服务。借助云容器引擎，您可以在华为云上轻松部署、管理和扩展容器化应用程序。 详细介绍请查看什么是云容器引擎。 云容器实例（Cloud Container Instance， CCI）服务提供Serverless Container（无服务器容器）引擎，让您无需创建和管理服务器集群即可直接运行容器。通过CCI您只需要管理运行在Kubernetes上的容器化业务，无需管理集群和服务器即可在CCI上快速创建和运行容器负载，使容器应用零运维，使企业聚焦业务核心，为企业提供了Serverless化全新一代的体验和选择。 而Serverless是一种架构理念，是指不用创建和管理服务器、不用担心服务器的运行状态（服务器是否在工作等），只需动态申请应用需要的资源，把服务器留给专门的维护人员管理和维护，进而专注于应用开发，提升应用开发效率、节约企业IT成本。传统上使用Kubernetes运行容器，首先需要创建运行容器的Kubernetes服务器集群，然后再创建容器负载。 详细介绍请查看什么是云容器实例。

CCE与CCI两者的配合 通过安装Virtual-Kubelet插件，可以在短时高负载场景时，将部署在CCE上的无状态工作负载（Deployment）、有状态工作负载（StatefulSet）、普通任务（Job）三种资源类型的容器实例（Pod），弹性创建到华为云云容器实例CCI服务上，以减少集群扩容带来的消耗。 具体功能如下： 支持容器实例实现秒级弹性伸缩：在集群资源不足时，无需新增节点，virtual-kubelet插件将自动为您在云容器实例CCI侧创建容器实例，减少运维成本。 无缝对接华为云 容器镜像服务 SWR，支持使用公用镜像和私有镜像。 支持CCI容器实例的事件同步、监控、日志、exec、查看状态等操作。 支持查看虚拟弹性节点的节点容量信息。 支持CCE和CCI两侧实例的service网络互通。 详情请参见华为云 CCE弹性伸缩 至CCI。

为什么exec进入容器后执行GPU相关的操作报错？ 问题现象： exec进入容器后执行GPU相关的操作（例如nvidia-smi、使用tensorflow运行GPU训练任务等）报错“cannot open shared object file: No such file or directory”。 问题原因： 安全容器内的cuda库位置为/usr/local/nvidia/lib64，您需要添加/usr/local/nvidia/lib64到LD_LIBRARY_PATH，才能正确地找到cuda库。 解决方法： 使用kubectl exec或者前端console登录进入带GPU的容器时，先执行命令export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/nvidia/lib64，然后再执行其他GPU相关的操作命令。 父主题： 容器工作负载类

job的pod已经执行完成的情况下，为什么依然有实例在挂卷等事件，并且事件信息是失败的？ 问题现象： job的Pod已经执行完成的情况下，依然有实例在挂卷等事件，并且事件信息是失败的。 图1 问题截图 问题原因： 各种类型的Pod（Deployment/StatefulSet/Job/CronJob）在Node上启动时： 由kubelet针对该Pod创建podWorker（独立协程）负责检测Pod与关联volume的挂载情况：每隔0.3s检测当前Pod所需挂载的volume都已经挂载成功，检测超时为2min3s；如果检测周期中以及最终超时到达时Pod关联volume都没有检测到挂载成功，则上报事件“Unable to mount volumes for pod …”。 由kubelet中VolumeManager（独立协程）负责具体实施Pod关联volume的挂载操作。 对于long running的Pod（Deployment/StatefulSet），除了类似镜像拉取失败、存储挂载失败、容器网络分配失败、当前节点CPU/Mem不满足Pod的实际使用要求等异常场景外，Pod容器如果最终都会启动成功时，上述podWorker在几次周期后都会判定挂载成功。 而对于短时运行的Pod（Job/CronJob），由于容器中业务存在正常退出（如问题场景的GCS Demo job只执行一些echo和ls命令，总体耗时1s不到），就存在短时Pod运行退出时如果刚好在两次podwork检测volume挂载周期中，那么就会出现本问题单所述的误报，但是不影响业务使用，且实际的Job业务还是会运行超过上述时间的。 当前kubelet上述能力属于社区挂载框架既有能力。 解决方法： 针对短时运行的Pod（Job/CronJob），可能存在由于运行时间过短而误报卷挂载超时的情况，如果这类短时运行任务属于正常退出，则该误报对业务没有影响可以忽略。 父主题： 存储管理类

排查项一：kubectl创建工作负载时未指定imagePullSecret 以创建一个名为nginx的deployment为例，请排查yaml文件中是否存在imagePullSecrets字段（如下yaml示例中的加粗字段），表示pull镜像时的secret名称。 需要使用容器 镜像服务 的镜像时，参数值固定为imagepull-secret。 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:alpine imagePullPolicy: Always name: nginx imagePullSecrets: - name: imagepull-secret

排查项三： IAM 用户没有镜像下载权限 如果您开通了企业管理，您需要在账号下的容器镜像服务中给IAM用户添加权限，IAM用户才能使用账号下的私有镜像。 给IAM用户添加权限有如下两种方法： 在镜像详情中为IAM用户添加授权，授权完成后，IAM用户享有读取/编辑/管理该镜像的权限，具体请参见在镜像详情中添加授权。 在组织中为IAM用户添加授权，使IAM用户对组织内所有镜像享有读取/编辑/管理的权限，具体请参见在组织中添加授权。

负载访问504问题定位思路 负载访问504问题一般是因为ELB实例绑定的Port到后端 CCI 负载Pod的安全组没有放通。查看CCI负载Pod使用的安全组，确保安全组规则放通ELB实例绑定的Port。 Pod绑定的安全组可以通过查看负载对应Network获得，调用Network接口，响应里面metadata.annotations中的network.alpha.kubernetes.io/default-security-group即为安全组ID，如下所示。 { "kind": "Network", "apiVersion": "networking.cci.io/v1beta1", "metadata": { "name": "namespace-test-dc1-default-network", "namespace": "namespace-test", "selfLink": "/apis/networking.cci.io/v1beta1/namespaces/namespace-test/networks/namespace-test-dc1-default-network", "uid": "6fb85414-af6b-11e8-b6ef-f898ef6c78b4", "resourceVersion": "5016899", "creationTimestamp": "2018-09-03T11:21:00Z", "annotations": { "network.alpha.kubernetes.io/project-id": "51bf52609f2a49c68bfda3398817b376", "network.alpha.kubernetes.io/default-security-group": "19c5d024-aed5-4856-b958-c0f65ce70855", "network.alpha.kubernetes.io/domain-id": "aadb43c0b14c4cafbccfff483d075987" }, "enable": true }, "spec": { "cidr": "192.168.244.0/23", "attachedVPC": "0d4080e5-546a-46c4-86fe-f3e26d685177", "networkType": "underlay_neutron", "physicalNetwork": "phy_net0", "networkID": "0022e356-f730-4226-802e-9cdaa6e7da17", "subnetID": "1ffd839d-e534-4fa8-a59d-42356335bf74", "availableZone": "cnnorth1a" }, "status": { "state": "Active" } } 进入网络控制台，根据上述操作中已获取的安全组ID，查找对应的安全组。 单击安全组名称，在安全组的入方向规则中增加如下规则。 UDP类型的公网访问，健康检查依赖ICMP规则，请注意添加。 父主题： 网络管理类

CCI如何配置DNS服务？ 如果用户负载需要使用k8s内部域名解析，则需要安装coredns插件。此时pod的dnsPolicy需要设置为ClusterFirst。 在插件市场界面可以单击，将coredns插件安装在指定的namesapce下。 图1 创建插件 如果用户负载不需要k8s内部域名解析服务，但是需要使用域名解析服务，此时pod的dnsPolicy需要设置为Default。 除了以上两种配置方式用户还可以通过设置dnsPolicy为None使用自定义dns服务。yaml示例如下： apiVersion: v1 kind: Pod metadata: namespace: default name: dns-example spec: containers: - name: test image: nginx dnsPolicy: "None" dnsConfig: nameservers: - 1.2.3.4 searches: - ns1.svc.cluster-domain.example - my.dns.search.suffix options: - name: ndots value: "2" - name: edns0 父主题： 网络管理类

CCI是否支持负载均衡？ CCI支持负载均衡，当前在CCI创建工作负载的访问设置页面中，内网访问（使用私网ELB访问）和公网访问中的配置都是负载均衡方式。 通常所说的负载均衡一般指的是公网负载均衡，CCI对接负载均衡服务。 通过CCI创建工作负载时，在设置访问设置的页面，可以根据需要选择内网访问和外网访问，然后配置负载均衡。 公网访问负载均衡，请参见公网访问。 内网访问负载均衡，请参见内网访问。 父主题： 网络管理类

排查项二：用户自身业务BUG 请检查工作负载启动命令是否正确执行，或工作负载本身bug导致容器不断重启。 按照使用kubectl配置好kubectl。 在页面单击失败的工作负载，进入负载详情界面，查看Pod列表，获取Pod名字。 查看失败的容器的名称。 kubectl describe pod $name -n $namespace | grep "Error syncing pod failed to" 图2 查看失败的容器的名称 查看退出容器的错误日志。 kubectl logs $podName -n $namespace -c $containerName 根据日志提示修复工作负载本身的问题。 图3 容器启动命令配置不正确 此种问题的解决方案是：重新创建工作负载，并配置正确的启动命令。

排查项一：查看端口是否冲突 按照使用kubectl配置好kubectl。 在页面上单击失败的工作负载，进入负载详情界面，查看Pod列表，获取Pod名字。 查看失败的容器的名称。 kubectl describe pod $name -n $namespace | grep "Error syncing pod failed to" 图1 查看失败的容器的名称 查看退出容器的错误日志。 kubectl logs $podName -n $namespace -c $containerName 此种问题有如下解决方法：重新创建工作负载，并配置正确的端口，确保端口不冲突。

排查项四：命名空间的资源类型错误 请检查创建命名空间时选择的资源类型是否正确，通用计算型和GPU加速型支持X86镜像。 登录控制台，在页面上单击失败的工作负载，进入负载详情界面。 查看Pod列表，单击实例异常Pod所在行“操作”列的“查看日志”。 查看报错信息如下。 ERROR: exec failed: Exec format error ERROR: hyper send process initiated event: error