华为云用户手册

请求消息 请求参数的详细描述请参见表154。 请求示例： 更改TFJob的结束存活时间ttlSecondsAfterFinished： { "apiVersion": "kubeflow.org/v1", "kind": "TFJob", "metadata": { "creationTimestamp": "2019-07-24T07:17:01Z", "generation": 2, "labels": { "app": "test" }, "name": "tfjob-test", "namespace": "kube-test", "resourceVersion": "72447176", "selfLink": "/apis/kubeflow.org/v1/namespaces/kube-test/tfjobs/tfjob-test", "uid": "083cc6df-ade3-11e9-aaa4-340a9837e413" }, "spec": { "backoffLimit": 6, "tfReplicaSpecs": { "Ps": { "replicas": 1, "template": { "spec": { "containers": [ { "args": [ "python", "/opt/tf-benchmarks/scripts/tf_cnn_benchmarks/tf_cnn_benchmarks.py", "--batch_size=1", "--model=resnet50", "--variable_update=parameter_server", "--flush_stdout=true", "--num_gpus=1", "--local_parameter_device=cpu", "--device=cpu", "--data_format=NHWC" ], "image": "*.*.*.215:20202/cci/tf-benchmarks-cpu:v1", "name": "tensorflow", "ports": [ { "containerPort": 2222, "name": "tfjob-port" } ], "resources": { "limits": { "cpu": "2", "memory": "4Gi" }, "requests": { "cpu": "2", "memory": "4Gi" } } } ], "imagePullSecrets": [ { "name": "imagepull-secret" } ], "restartPolicy": "OnFailure" } } }, "Worker": { "replicas": 1, "template": { "spec": { "containers": [ { "args": [ "python", "/opt/tf-benchmarks/scripts/tf_cnn_benchmarks/tf_cnn_benchmarks.py", "--batch_size=1", "--model=resnet50", "--variable_update=parameter_server", "--flush_stdout=true", "--local_parameter_device=cpu", "--device=cpu", "--data_format=NHWC" ], "image": "*.*.*.215:20202/cci/tf-benchmarks-cpu:v1", "name": "tensorflow", "ports": [ { "containerPort": 2222, "name": "tfjob-port" } ], "resources": { "limits": { "cpu": "2", "memory": "4Gi" }, "requests": { "cpu": "2", "memory": "4Gi" } } } ], "imagePullSecrets": [ { "name": "imagepull-secret" } ], "restartPolicy": "OnFailure" } } } }, "ttlSecondsAfterFinished": 1000 }, "status": { "conditions": [ { "lastTransitionTime": "2019-07-24T07:16:13Z", "lastUpdateTime": "2019-07-24T07:16:13Z", "message": "TFJob tfjob-test is created.", "reason": "TFJobCreated", "status": "True", "type": "Created" }, { "lastTransitionTime": "2019-07-24T07:16:18Z", "lastUpdateTime": "2019-07-24T07:16:18Z", "message": "TFJob tfjob-test is running.", "reason": "TFJobRunning", "status": "True", "type": "Running" } ], "replicaStatuses": { "PS": { "active": 1 }, "Worker": { "active": 1 } }, "startTime": "2019-07-24T07:16:13Z" }}

响应消息 响应参数： 响应参数的详细描述请参考表154。 响应示例： { "apiVersion": "kubeflow.org/v1", "kind": "TFJob", "metadata": { "creationTimestamp": "2019-07-24T07:17:01Z", "generation": 2, "labels": { "app": "test" }, "name": "tfjob-test", "namespace": "kube-test", "resourceVersion": "72447176", "selfLink": "/apis/kubeflow.org/v1/namespaces/kube-test/tfjobs/tfjob-test", "uid": "083cc6df-ade3-11e9-aaa4-340a9837e413" }, "spec": { "backoffLimit": 6, "tfReplicaSpecs": { "Ps": { "replicas": 1, "template": { "spec": { "containers": [ { "args": [ "python", "/opt/tf-benchmarks/scripts/tf_cnn_benchmarks/tf_cnn_benchmarks.py", "--batch_size=1", "--model=resnet50", "--variable_update=parameter_server", "--flush_stdout=true", "--num_gpus=1", "--local_parameter_device=cpu", "--device=cpu", "--data_format=NHWC" ], "image": "*.*.*.215:20202/cci/tf-benchmarks-cpu:v1", "name": "tensorflow", "ports": [ { "containerPort": 2222, "name": "tfjob-port" } ], "resources": { "limits": { "cpu": "2", "memory": "4Gi" }, "requests": { "cpu": "2", "memory": "4Gi" } } } ], "imagePullSecrets": [ { "name": "imagepull-secret" } ], "restartPolicy": "OnFailure" } } }, "Worker": { "replicas": 1, "template": { "spec": { "containers": [ { "args": [ "python", "/opt/tf-benchmarks/scripts/tf_cnn_benchmarks/tf_cnn_benchmarks.py", "--batch_size=1", "--model=resnet50", "--variable_update=parameter_server", "--flush_stdout=true", "--local_parameter_device=cpu", "--device=cpu", "--data_format=NHWC" ], "image": "*.*.*.215:20202/cci/tf-benchmarks-cpu:v1", "name": "tensorflow", "ports": [ { "containerPort": 2222, "name": "tfjob-port" } ], "resources": { "limits": { "cpu": "2", "memory": "4Gi" }, "requests": { "cpu": "2", "memory": "4Gi" } } } ], "imagePullSecrets": [ { "name": "imagepull-secret" } ], "restartPolicy": "OnFailure" } } } }, "ttlSecondsAfterFinished": 1000 }, "status": { "conditions": [ { "lastTransitionTime": "2019-07-24T07:16:13Z", "lastUpdateTime": "2019-07-24T07:16:13Z", "message": "TFJob tfjob-test is created.", "reason": "TFJobCreated", "status": "True", "type": "Created" }, { "lastTransitionTime": "2019-07-24T07:16:18Z", "lastUpdateTime": "2019-07-24T07:16:18Z", "message": "TFJob tfjob-test is running.", "reason": "TFJobRunning", "status": "True", "type": "Running" } ], "replicaStatuses": { "PS": { "active": 1 }, "Worker": { "active": 1 } }, "startTime": "2019-07-24T07:16:13Z" }}

限制条件 挂载OBS时有如下限制： 创建Pod时需要添加annotations字段：obssidecar-injector-webhook/inject: 'true'。 obssidecar-injector-webhook/inject: 'true' : 表示挂载OBS需要创建obssidecar容器。 挂载obs并行文件系统时，obssidecar容器需预留一定内存以保障业务可靠性，防止容器因资源不足异常退出。当业务容器挂载单个obs并行文件系统时，CPU和内存规格建议配置如下： "obssidecar-injector-webhook/cpu": "500m", "obssidecar-injector-webhook/memory": "1024Mi" 当业务容器挂载多个obs并行文件系统时，相应CPU和内存规格逐倍增加。 obssidecar-injector-webhook/cpu: 表示obssidecar容器cpu规格。 obssidecar-injector-webhook/memory: 表示obssidecar容器memory规格。 挂载obs并行文件系统时，可指定挂载的umask来限制文件或目录权限。 obssidecar-injector-webhook/umask：表示obssidecar容器挂载时的权限掩码。

创建静态EIPPool 静态EIPPool，即根据用户指定的多个未使用的EIP，静态纳管底层的EIP资源，同时在CCI命名空间下创建相应的EIP对象。如果EIPPool中的EIP已经被NAT或者ELB使用，则会纳管失败。 以下示例创建了一个名为eippool-demo2的静态EIPPool，并在此EIPPool中纳管10.246.173.254和10.246.172.3两个公网IP。 示例如下： apiVersion: crd.yangtse.cni/v1kind: EIPPool # 创建的对象类别metadata: # 资源对象的元数据定义 name:eippool-demo2spec: # EIPPool的配置信息 eips: # 纳管的公网IP - 10.246.173.254 - 10.246.172.3 父主题： 创建EIPPool

创建PVC 通过如下定义创建PVC，这个定义申请了一块大小为100G的SAS型云硬盘。 如果需要创建加密类型的云硬盘存储卷，在metadata.annotations中增加paas.storage.io/cryptKeyId字段即可。 apiVersion: v1kind: PersistentVolumeClaimmetadata: name: pvc-evs namespace: namespaces-test annotations: { paas.storage.io/cryptKeyId: ee9b610c-e356-11e9-aadc-d0efc1b3bb6b }spec: accessModes: - ReadWriteMany resources: requests: storage: 100Gi storageClassName: sas accessModes为存储访问模式，支持如下3种模式： ReadWriteOnce：可以被单个节点以读/写模式挂载 ReadOnlyMany：可以被多个节点以只读模式挂载 ReadWriteMany：可以被多个节点以读/写模式挂载 storageClassName表示申请的存储类型，当前支持如下4个参数： sas：SAS（高I/O）型EVS硬盘 ssd：SSD（超高I/O）型EVS硬盘 nfs-rw：标准文件协议类型SFS文件存储 csi-sfs：SFS 3.0容量型弹性文件服务 通过如下定义创建PVC，这个定义申请了一块大小为100G的文件存储。 如果需要创建加密类型的文件存储卷，在metadata.annotations中增加paas.storage.io/cryptKeyId、paas.storage.io/cryptAlias和paas.storage.io/cryptDomainId即可。 apiVersion: v1kind: PersistentVolumeClaimmetadata: name: pvc-sfs namespace: namespace-test annotations: { paas.storage.io/cryptKeyId: ee9b610c-e356-11e9-aadc-d0efc1b3bb6b paas.storage.io/cryptAlias: sfs/default paas.storage.io/cryptDomainId: d6912480-c3d6-4e9e-8c70-38afeea434c3 volume.beta.kubernetes.io/storage-provisioner: flexvolume-huawei.com/fuxinfs }spec: accessModes: - ReadWriteMany resources: requests: storage: 100Gi storageClassName: nfs-rw

网络访问场景 在前面两节中介绍了如何通过Service和Ingress访问Pod，本节总结一下云容器实例中Pod的访问场景，如图1所示，访问负载可以分为如下几种场景，每种场景下可以使用Service和Ingress来解决访问问题。 同一个命名空间中的负载相互访问：只需创建Service，使用“服务名称:服务端口”访问负载。 同一个VPC内资源互相访问：直接访问Service的IP地址，或者通过Ingress绑定私网ELB，使用私网ELB的IP访问负载。 不同VPC内资源互相访问：不同VPC内，可以选择创建VPC对等连接，使得两个VPC之间网络互通，在访问时通过Service的IP地址或私网ELB访问负载。 从公网访问负载：从外部访问负载，需要通过Ingress绑定公网ELB，通过ELB的IP访问负载。 从负载中访问公网：通过在NAT网关服务中配置SNAT规则，使得容器能够访问公网，具体配置方法请参见从容器访问公网。 图1 网络访问示意图 父主题： 使用Service和Ingress管理网络访问

使用PVC 使用PVC申请到存储资源后，您可以在Pod中使用Volume来关联PVC，并将Volume挂载到容器中使用。 下面是的示例中说明了PVC如何在Pod中使用，这个Pod定义了一个名为“pvc-test-example”的Volume，并将这个Volume挂载到容器的“/tmp/volume0”路径，这样您写入到/tmp的数据就是写到名为pvc-test的PVC中。 写入上面申请的sas型云硬盘中 apiVersion: v1kind: Podmetadata: name: nginx labels: app: nginxspec: containers: - image: nginx:latest name: container-0 resources: limits: cpu: 500m memory: 1024Mi requests: cpu: 500m memory: 1024Mi volumeMounts: - mountPath: "/tmp/volume0" # 将PVC挂载到容器的/tmp/volume0路径 name: pvc-test-example # Volume的名称 volumes: # 定义Volume，关联PVC - name: pvc-test-example persistentVolumeClaim: claimName: pvc-test # PVC的名称 imagePullSecrets: - name: imagepull-secret 写入上面申请的文件存储（storageClassName设置为nfs-rw型）中。 当创建PVC申请文件存储（storageClassName设置为nfs-rw型）时，在volumeMounts中可设置挂载子路径，即文件存储根路径下子路径。 apiVersion: v1kind: Podmetadata: name: nginx labels: app: nginxspec: containers: - image: nginx:latest name: container-0 resources: limits: cpu: 500m memory: 1024Mi requests: cpu: 500m memory: 1024Mi volumeMounts: - mountPath: "/tmp/volume0" # 将PVC挂载到容器的/tmp/volume0路径 subPath: "abc" # 文件存储根路径下子路径，如果不存在会自动在文件存储中创建。该子路径必须为相对路径。 name: pvc-test-example # Volume的名称 volumes: # 定义Volume，关联PVC - name: pvc-test-example persistentVolumeClaim: claimName: pvc-test # PVC的名称 imagePullSecrets: - name: imagepull-secret

Pod规格计算方式 Pod规格的计算步骤如下： Pod 包含的所有 Init 容器上定义的任何特定资源的约束值 (limit) 或 请求值 (request) 的最大值，作为 Pod 有效初始 request/limit。 Pod 对资源的有效 limit/request ，是取如下两项的较大者： 所有应用容器对某个资源的 limit/request 之和。 对某个资源的有效初始的 limit/request 。 针对如下实例，计算Pod规格。 apiVersion: v1kind: Podmetadata: name: web-appspec: initContainers: - name: config-generator image: busybox resources: requests: memory: "256Mi" cpu: "250m" limits: memory: "256Mi" cpu: "250m" - name: mysql-checker image: centos resources: requests: memory: "1Gi" cpu: "500m" limits: memory: "1Gi" cpu: "500m" containers: - name: app image: images.my-company.example/app:v4 env: - name: MYSQL_ROOT_PASSWORD value: "password" resources: requests: memory: "1Gi" cpu: "500m" limits: memory: "1Gi" cpu: "500m" - name: log-aggregator image: images.my-company.example/log-aggregator:v6 resources: requests: memory: "1Gi" cpu: "250m" limits: memory: "1Gi" cpu: "250m" Init 容器，request/limit取最大值：memory为1Gi，cpu为500m。 所有应用容器request/limit之和：memory为2Gi，cpu为750m。 如上两步取较大值，Pod的规格为request/limit：memory 2Gi，cpu 750m。 父主题： Pod

为kubectl上下文指定Namespace 上面创建Network是在指定的Namespace下创建的，本文档后续的资源创建都是在某个命名空间下操作，每次都指定命名空间比较麻烦，您可以为kubectl上下文指定命名空间，这样在某个上下文中，创建的资源就都是在某个命名空间下，方便操作。 指定Namespace只需要在设置上下文命令中添加一个“--namespace”选项，如下所示。 kubectl config set-context $context --namespace=$ns 其中，$ns为Namespace的名称；$context 为上下文的名称，可以自定义，也可执行如下命令获取： # kubectl config get-contextsCURRENT NAME CLUSTER AUTHINFO NAMESPACE cci-context-cn-east-3-1C8PNI0POPP CS FGXPM6S cci-cluster-cn-east-3 cci-user-cn-east-3-1C8PNI0POPPCSFGXPM6S * cci-context-cn-east-3-hwuser_xxx cci-cluster-cn-east-3 cci-user-cn-east-3-hwuser_xxx kubernetes-admin@kubernetes kubernetes kubernetes-admin 假设，上面创建的Namespace名称为namespace-test，则示例如下。 # kubectl config set-context cci-context --namespace=namespace-test 指定Namespace后，就可以使用 kubectl 命令直接操作云容器实例的相关资源。如下所示，执行kubectl get pod，查看Pod资源，一切正常。 # kubectl get podNo resources found.

cci-iam-authenticator使用参考 cci-iam-authenticator作为k8s client端的认证插件，主要提供了generate-kubeconfig和token两个子命令。 A tool to authenticate to CCI using HuaweiCloud IAM credentialsUsage: cci-iam-authenticator [command]Available Commands: generate-kubeconfig Generate or modify kubeconfig files based on user configuration help Help about any command token Authenticate using HuaweiCloud IAM and get token for CCIFlags: --alsologtostderr log to standard error as well as files -h, --help help for cci-iam-authenticator --log_dir string If non-empty, write log files in this directory --log_file string If non-empty, use this log file --logtostderr log to standard error instead of files (default true) -v, --v Level number for the log level verbosity --version version for cci-iam-authenticatorUse "cci-iam-authenticator [command] --help" for more information about a command. 其中，Flags主要为日志选项。 token token子命令用于获取用户token，获取token的认证方式有用户名/密码、ak/sk两种，选择其中一种即可。 Authenticate using HuaweiCloud IAM and get token for CCIUsage: cci-iam-authenticator token [flags]Flags: --ak string IAM access key ID --cache Cache the token credential on disk until it expires (default true) --domain-name string IAM domain name, typically your account name -h, --help help for token --iam-endpoint string HuaweiCloud IAM endpoint, i.e. https://iam.cn-north-4.myhuaweicloud.com (default "https://iam.myhuaweicloud.com") --insecure-skip-tls-verify If true, the iam server's certificate will not be checked for validity. (default true) --password string IAM user password --project-id string IAM project id, project id and project name should not be empty at same time --project-name string IAM project name, project id and project name should not be empty at same time --sk string IAM secret access key --token-only Return token only for other tool integration --user-name string IAM user name. Same as domain-name when using main account, otherwise use iam user name 其中，Flags分为用户名密码、AKSK和公共配置。 表1 用户名/密码配置 Command Flag Environment Value Description domain-name DOMAIN_NAME 租户名，即账号名，详情请参见https://support.huaweicloud.com/usermanual-ca/ca_01_0001.html。 user-name USER_NAME 子用户名，即IAM用户名。如果不配置与domain-name一致。 详情请参见https://support.huaweicloud.com/usermanual-ca/ca_01_0001.html。 password PASSWORD 用户或子用户密码。 表2 AK/SK配置 Command Flag Environment Value Description ak AC CES S_KEY_ID ak、sk的获取方法请参见获取AK/SK，ak为文件中Access Key部分，sk为文件中Secret Key部分。 sk SECRET_ACCESS_KEY 表3 公共配置 Command Flag Environment Value Description iam-endpoint IAM_ENDPOINT IAM的Endpoint，必须配置，详情请参见https://developer.huaweicloud.com/endpoint?IAM。 project-name PROJECT_NAME 项目名，详情请参见https://support.huaweicloud.com/usermanual-ca/ca_01_0001.html。 project-id PROJECT_ID 项目ID，详情请参见https://support.huaweicloud.com/usermanual-ca/ca_01_0001.html。 insecure-skip-tls-verify INSECURE_SKIP_TLS_VERIFY 是否跳过对CCI/IAM服务端的校验，默认为true。 cache CREDENTIAL_CACHE 是否开启将IAM Token缓存到本地，提高访问性能，默认为true。 注意： 在非安全环境，建议关闭此选项。 generate-kubeconfig 为用户直接生成kubeconfig配置，如果指定的kubeconfig已存在，则会注入新的server、user、context配置，并将当前的kubeconfig context切换到此次配置的结果。 默认情况下会对用户的配置进行校验，尝试访问IAM及CCI，确保用户配置的IAM认证信息、CCI地址可用。 Generate or modify kubeconfig files based on user configuration.Sets a cluster entry, a user entry and a context entry in kubeconfig and use this context as the current-context. The loading order follows these rules: 1. If the --kubeconfig flag is set, then only that file is loaded. The flag may only be set once and no merging takesplace. 2. If $KUBECONFIG environment variable is set, then it is used as a list of paths (normal path delimiting rules foryour system). These paths are merged. When a value is modified, it is modified in the file that defines the stanza. Whena value is created, it is created in the first file that exists. If no files in the chain exist, then it creates thelast file in the list. 3. Otherwise, ${HOME}/.kube/config is used and no merging takes place. Examples: # Generate kubeconfig to ${HOME}/.kube/config using aksk cci-iam-authenticator generate-kubeconfig --cci-endpoint=https://cci.cn-north-4.myhuaweicloud.com --ak=*** --sk=*** # Generate kubeconfig to ${HOME}/.kube/config using domain name and password cci-iam-authenticator generate-kubeconfig --cci-endpoint=https://cci.cn-north-4.myhuaweicloud.com --domain-name=*** --password=***Usage: cci-iam-authenticator generate-kubeconfig [flags]Flags: --ak string IAM access key ID --cache Cache the token credential on disk until it expires (default true) --cci-endpoint string CCI server endpoint, i.e. https://cci.cn-north-4.myhuaweicloud.com --domain-name string IAM domain name, typically your account name -h, --help help for generate-kubeconfig --iam-endpoint string HuaweiCloud IAM endpoint, i.e. https://iam.cn-north-4.myhuaweicloud.com (default "https://iam.myhuaweicloud.com") --insecure-skip-tls-verify If true, the iam server's certificate will not be checked for validity. (default true) --kubeconfig string use a particular kubeconfig file --password string IAM user password --project-id string IAM project id, project id and project name should not be empty at same time --project-name string IAM project name, project id and project name should not be empty at same time --sk string IAM secret access key --token-only Return token only for other tool integration --user-name string IAM user name. Same as domain-name when using main account, otherwise use iam user name --validation Validate kubeconfig by trying to access CCI with existing config (default true) 同一个kubeconfig可以包含多个环境、认证信息，用户可以通过同一份IAM认证配置，仅修改cci-endpoint生成多个region的kubeconfig，例如： # 生成北京4的kubeconfig，并切换到对应context $ cci-iam-authenticator generate-kubeconfig --cci-endpoint=https://cci.cn-north-4.myhuaweicloud.com --ak=my-ak --sk=xxxxxx Switched to context "cci-context-cn-north-4-my-ak". # 生成上海1的kubeconfig，并切换到对应context $ cci-iam-authenticator generate-kubeconfig --cci-endpoint=https://cci.cn-east-3.myhuaweicloud.com --ak=my-ak --sk=xxxxxx Switched to context "cci-context-cn-east-3-my-ak". # 切换到北京4的context $ kubectl config use-context cci-context-cn-north-4-my-ak 父主题： 使用kubectl（推荐）

概念 Init-Containers，即初始化容器，顾名思义容器启动的时候，会先启动可一个或多个容器，如果有多个，那么这几个Init Container按照定义的顺序依次执行，只有所有的Init Container执行完后，主容器才会启动。由于一个Pod里的存储卷是共享的，所以Init Container里产生的数据可以被主容器使用到。 Init Container可以在多种K8S资源里被使用到如Deployment、DaemonSet、Job等，但归根结底都是在Pod启动时，在主容器启动前执行，做初始化工作。

启动命令 启动容器就是启动主进程，但有些时候，启动主进程前，需要一些准备工作。比如MySQL类的数据库，可能需要一些数据库配置、初始化的工作，这些工作要在最终的MySQL服务器运行之前解决。您可以在制作镜像时通过在Dockerfile文件中设置ENTRYPOINT或CMD来完成。 如下所示的Dockerfile中设置了ENTRYPOINT ["top", "-b"]命令，其将会在容器启动时执行。 FROM ubuntuENTRYPOINT ["top", "-b"] 调用接口时，只需配置pod的containers.command参数，该参数是list类型，第一个参数为执行命令，后面均为命令的参数。 apiVersion: v1kind: Podmetadata: name: Ubuntuspec: containers: - image: Ubuntu name: container-0 resources: limits: cpu: 500m memory: 1024Mi requests: cpu: 500m memory: 1024Mi command: # 启动命令 - top - "-b" imagePullSecrets: - name: imagepull-secret 父主题： Pod

使用场景 部署服务时需要做一些准备工作，在运行服务的pod中使用一个init container，可以执行准备工作，完成后Init Container结束退出，再启动要部署的容器。 等待其它模块Ready：比如有一个应用里面有两个容器化的服务，一个是Web Server，另一个是数据库。其中Web Server需要访问数据库。但是当启动这个应用的时候，并不能保证数据库服务先启动起来，所以可能出现在一段时间内Web Server有数据库连接错误。为了解决这个问题，可以在运行Web Server服务的Pod里使用一个Init Container，去检查数据库是否准备好，直到数据库可以连接，Init Container才结束退出，然后Web Server容器被启动，发起正式的数据库连接请求。 初始化配置：比如集群里检测所有已经存在的成员节点，为主容器准备好集群的配置信息，这样主容器起来后就能用这个配置信息加入集群。 其它使用场景：如将pod注册到一个中央数据库、下载应用依赖等。 更多内容请参见初始容器文档参考。

操作步骤 编辑initcontainer工作负载yaml文件。 vi deployment.yaml Yaml示例如下： apiVersion: apps/v1kind: Deploymentmetadata: name: mysqlspec: replicas: 1 selector: matchLabels: name: mysql template: metadata: labels: name: mysql spec: initContainers: - name: getresource image: busybox command: ['sleep','20'] containers: - name: mysql image: percona:5.7.22 imagePullPolicy: Always ports: - containerPort: 3306 resources: limits: memory: "500Mi" cpu: "500m" requests: memory: "500Mi" cpu: "250m" env: - name: MYSQL_ROOT_PASSWORD value: "mysql" 创建initcontainer工作负载。 kubectl create -f deployment.yaml 命令行终端显示如下类似信息： deployment.apps/mysql created

添加Label Label的形式为key-value形式，使用非常简单，如下，为Pod设置了app=nginx和env=prod两个Label。 apiVersion: v1kind: Podmetadata: name: nginx labels: # 为Pod设置两个Label app: nginx env: prodspec: containers: - image: nginx:latest name: container-0 resources: limits: cpu: 500m memory: 1024Mi requests: cpu: 500m memory: 1024Mi imagePullSecrets: - name: imagepull-secret Pod有了Label后，在查询Pod的时候带上 --show-labels 就可以看到Pod的Label。 $ kubectl get pod --show-labels -n $namespace_nameNAME READY STATUS RESTARTS AGE LABELSnginx 1/1 Running 0 50s app=nginx,env=prod 还可以使用 -L 只查询某些固定的Label。 $ kubectl get pod -L app,env -n $namespace_nameNAME READY STATUS RESTARTS AGE APP ENVnginx 1/1 Running 0 1m nginx prod 对已存在的Pod，可以直接使用 kubectl label 命令直接添加Label。 $ kubectl label po nginx creation_method=manual -n $namespace_namepod "nginx" labeled$ kubectl get pod --show-labels -n $namespace_nameNAME READY STATUS RESTARTS AGE LABELSnginx 1/1 Running 0 50s app=nginx,env=prod,creation_method=manual

修改Label 对于已存在的Label，如果要修改的话，需要在命令中带上--overwrite，如下所示。 $ kubectl label po nginx env=debug --overwrite -n $namespace_namepod "nginx" labeled$ kubectl get pod --show-labels -n $namespace_nameNAME READY STATUS RESTARTS AGE LABELSnginx 1/1 Running 0 50s app=nginx,env=debug,creation_method=manual

为什么需要Label 当资源变得非常多的时候，如何分类管理就非常重要了，Kubernetes提供了一种机制来为资源分类，那就是Label（标签）。Label非常简单，但是却很强大，Kubernetes中几乎所有资源都可以用Label来组织。 Label的具体形式是key-value的标记对，可以在创建资源的时候设置，也可以在后期添加和修改。 以Pod为例，当Pod变得多起来后，就显得杂乱且难以管理，如下图所示。 图1 没有分类组织的Pod 如果我们为Pod打上不同标签，那情况就完全不同了，如下图所示。 图2 使用Label组织的Pod

限制与约束 一个Pod只能绑定一个EIP，一个EIP只能被一个Pod绑定。 创建Pod时，可指定annotation属性，创建完成后，更新EIP相关的annotation均无效。 EIP随Pod创建的优先级高于使用EIPPool创建的EIP。 绑定已有EIP创建的优先级高于EIP随Pod创建的EIP。 绑定EIP的Pod，如果要被公网成功访问，需要添加放通相应公网请求流量的安全组规则。 已经被Pod绑定的弹性公网IP，请勿通过弹性公网IP的console或API直接操作（修改别名/删除/解绑/绑定/转包周期等操作），否则可能导致资源残留。 绑定已有EIP时，使用负载创建的Pod删除重建后，由于需要等待前一个Pod完成解绑，所以重建的Pod就绪时间会变长。 绑定已有的EIP必须是用户手动创建给Pod使用的，不能使用EIPPool生成的EIP，否则会导致EIP状态异常。

在环境变量中引用Secret Secret最常见的用法是作为环境变量注入到容器中，如下示例。 apiVersion: v1kind: Podmetadata: name: nginxspec: containers: - image: nginx:latest name: container-0 resources: limits: cpu: 500m memory: 1024Mi requests: cpu: 500m memory: 1024Mi env: - name: key valueFrom: secretKeyRef: name: mysecret key: key1 imagePullSecrets: - name: imagepull-secret

在Volume中引用Secret 在Volume中引用Secret，就是通过文件的方式直接将Secret的每条数据填入Volume，每条数据是一个文件，键就是文件名，键值就是文件内容。 如下示例中，创建一个名为vol-secret的Volume，这个Volume引用名为“mysecret”的Secret，再将Volume挂载到容器的“/tmp”路径下。Pod创建成功后，在容器的“/tmp”路径下，就有两个文件key1和key2，它们的值分别为“VkZNME0wVlpVbEpQVHpGTFdrSkRWVWhCV2s5T1ZrNUxUVlZNUjBzMFRWcElVMFpVUkVWV1N3PT0=”和“T0VkR1RGRlZVRlpVU2xCWFdUZFBVRUZCUmtzPQ==”。 此处key1、key2的值为Base64编码后的值。 apiVersion: v1kind: Podmetadata: name: nginxspec: containers: - image: nginx:latest name: container-0 resources: limits: cpu: 500m memory: 1024Mi requests: cpu: 500m memory: 1024Mi volumeMounts: - name: vol-secret # 挂载名为vol-secret的Volume mountPath: "/tmp" #挂载路径，字符串长度不能超过256 imagePullSecrets: - name: imagepull-secret volumes: - name: vol-secret secret: # 引用Secret secretName: mysecret

约束与限制 当前不支持容器中软链路径的日志采集。 当前不支持容器标准输出采集上报到kafka。 当前不支持日志轮转，如果需要对日志文件进行大小的控制，请自行处理。 单条日志长度限制为250KB，如果超过则会丢弃。 不支持指定系统、设备、cgroup、tmpfs、localdir等挂载目录的日志采集，会直接忽略。 容器中长度超过190的日志文件无法被采集。容器中长度在180~190范围的日志文件仅支持采集第一个文件。 当容器被停止时，如果出现因网络延迟、资源占用多等原因导致的采集延时，可能会丢失容器停止前的部分日志。

高级配置 Secret是一种加密存储的资源对象，您可以将认证信息、证书、私钥等保存在密钥中，从而解决了密码、token、密钥等敏感数据的配置问题。 apiVersion: v1kind: Secretmetadata: name: cci-sfs-kafka-tlstype: Opaquedata: ca.crt: ... server.crt: ... server.key: ... 用户可以通过配置SSL参数，进行加密的安全连接，证书文件等相关的文件引用通过sandbox volume的特性来支持。

创建Secret 如下示例中定义的Secret中包含两条Key-Value。 apiVersion: v1kind: Secretmetadata: name: mysecrettype: Opaquedata: key1: VkZNME0wVlpVbEpQVHpGTFdrSkRWVWhCV2s5T1ZrNUxUVlZNUjBzMFRWcElVMFpVUkVWV1N3PT0= # Base64编码后的值 key2: T0VkR1RGRlZVRlpVU2xCWFdUZFBVRUZCUmtzPQ== # Base64编码后的值

约束与限制 一个Pod只能绑定一个EIP。 绑定EIP的Pod，如果要被公网成功访问，需要添加放通相应公网请求流量的安全组规则。 EIPPool正在被Pod使用时，不支持直接删除EIPPool，需删除关联Pod，再删除EIPPool。 EIPPool为namespace级别资源，不可跨namespace使用。 工作负载滚动升级时，默认策略是逐步创建新Pod然后删除旧Pod（请参见升级策略），则可能会由于EIPPool中EIP数量不足而升级失败。建议：EIPPool池的大小略大于使用该EIPPool的所有的Deployment副本数之和，或者maxSurge配置为0，可支持工作负载先减后增滚动升级。

明确指定 明确指定和自动匹配同时使用，明确指定具有高优先级。 创建CCI实例时，可以通过注解中添加以下键值来明确指定镜像快照。 名称 示例值 描述 cci.io/image-snapshot-specified-name "my-imagesnapshot" 指定的镜像快照名称。 以创建Deployment为例： apiVersion: apps/v1kind: Deploymentmetadata: name: deployment-testspec: replicas: 1 selector: matchLabels: app: redis template: metadata: labels: app: redis annotations: cci.io/image-snapshot-auto-match: "false" cci.io/image-snapshot-specified-name: "my-imagesnapshot" spec: containers: - image: redis name: container-0 resources: limits: cpu: 500m memory: 1024Mi requests: cpu: 500m memory: 1024Mi imagePullSecrets: - name: imagepull-secret

Pod的EIP准备就绪 Pod业务容器的启动时间可能早于EIP分配结果返回成功时间，在Pod启动过程中EIP可能会绑定失败。 通过在init container中可检查EIP是否已经分配成功。容器网络控制器会在Pod IP分配后，为Pod绑定EIP并返回分配结果至Pod的Annotation（yangtse.io/allocated-ipv4-eip），通过Pod配置init container并使用downwardAPI，把yangtse.io/allocated-ipv4-eip annotation通过volume挂载到init container里，可检查EIP是否已经分配成功。具体您可以参考以下示例配置init container： apiVersion: v1kind: Podmetadata: name: example namespace: demo annotations: yangtse.io/eip-id: 65eb3679-7a8d-4b24-b681-0b661axxxxcbspec: 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']

为Pod指定EIP的ID 创建Pod时，填写yangtse.io/eip-id的annotation后，EIP会随Pod自动完成绑定。 以下示例创建一个名为nginx的实例数为1的无状态负载，EIP将随Pod自动绑定至Pod。具体字段含义见表1。 apiVersion: apps/v1 kind: Deployment metadata: annotations: deployment.kubernetes.io/revision: "14" description: "" name: nginx namespace: eip spec: ... replicas: 1 template: metadata: annotations: yangtse.io/eip-id: 65eb3679-7a8d-4b24-b681-0b661axxxxcb 表1 参数说明 参数 参数含义 必选/可选 约束 yangtse.io/eip-id 弹性公网ID 必选 必须是弹性公网IP页面能查到的ID信息。

自动匹配 创建CCI实例时，可以通过注解中添加以下键值来开启自动匹配镜像快照。 名称 示例值 描述 cci.io/image-snapshot-auto-match "true" 设置是否开启自动匹配镜像快照。 以创建Deployment为例： apiVersion: apps/v1kind: Deploymentmetadata: name: deployment-testspec: replicas: 1 selector: matchLabels: app: redis template: metadata: labels: app: redis annotations: cci.io/image-snapshot-auto-match: "true" spec: containers: - image: redis name: container-0 resources: limits: cpu: 500m memory: 1024Mi requests: cpu: 500m memory: 1024Mi imagePullSecrets: - name: imagepull-secret

高级配置 创建Secret Secret是一种加密存储的资源对象，您可以将认证信息、证书、私钥等保存在密钥中，从而解决了密码、token、密钥等敏感数据的配置问题。 如下示例中定义的Secret中包含三条Key-Value。 apiVersion: v1kind: Secretmetadata: name: certtype: Opaquedata: ca.crt: ... server.crt: ... server.key: ... 配置tls证书 用户可以通过配置annotation指定exporter server的tls证书套件，进行加密通信，并使用文件挂载的方式，关联证书secret。示例如下： kind: DeploymentapiVersion: apps/v1metadata: name: nginx-tlsspec: replicas: 1 selector: matchLabels: app: nginx-tls template: metadata: labels: app: nginx-tls annotations: monitoring.cci.io/enable-pod-metrics: "true" monitoring.cci.io/metrics-port: "19100" monitoring.cci.io/metrics-tls-cert-reference: cert/server.crt monitoring.cci.io/metrics-tls-key-reference: cert/server.key monitoring.cci.io/metrics-tls-ca-reference: cert/ca.crt sandbox-volume.openvessel.io/volume-names: cert spec: volumes: - name: cert secret: secretName: cert defaultMode: 384 containers: - name: container-0 image: 'nginx:alpine' resources: limits: cpu: 1000m memory: 2048Mi requests: cpu: 1000m memory: 2048Mi volumeMounts: - name: cert mountPath: /tmp/secret0 imagePullSecrets: - name: imagepull-secret 表3 tls证书参数说明 Annotation 功能 可选值 默认值 monitoring.cci.io/metrics-tls-cert-reference tls证书volume引用 ${volume-name}/${volume-keyOrPath}（卷/路径） 无（使用http） monitoring.cci.io/metrics-tls-key-reference tls私钥volume引用 ${volume-name}/${volume-keyOrPath} 无（使用http） monitoring.cci.io/metrics-tls-ca-reference tls CA volume引用 ${volume-name}/${volume-keyOrPath} 无（使用http） 以上参数的值为tls的证书、私钥、CA文件所在存储卷的“卷名”和“路径”。

基础配置 以下示例介绍Pod资源监控指标的基础配置方式，提供了Pod级别特性开关和自定义端口的能力。 kind: DeploymentapiVersion: apps/v1metadata: name: nginx-exporterspec: replicas: 1 selector: matchLabels: app: nginx-exporter template: metadata: labels: app: nginx-exporter annotations: monitoring.cci.io/enable-pod-metrics: "true" monitoring.cci.io/metrics-port: "19100" spec: containers: - name: container-0 image: 'nginx:alpine' resources: limits: cpu: 1000m memory: 2048Mi requests: cpu: 1000m memory: 2048Mi imagePullSecrets: - name: imagepull-secret 表2 参数说明 Annotation 功能 可选值 默认值 monitoring.cci.io/enable-pod-metrics 是否开启监控指标特性 true，false（不区分大小写） true monitoring.cci.io/metrics-port 指定pod exporter启动监听端口 合法端口（1~65535） 19100