华为云用户手册

操作步骤 编辑initcontainer工作负载yaml文件。 vi deployment.yaml Yaml示例如下： apiVersion: apps/v1 kind: Deployment metadata: name: mysql spec: 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

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

HTTP GET Readiness Probe的配置与存活探针（livness probe）一样，都是在 Pod Template 的 containers 里面，如下所示，这个Readiness Probe向Pod发送HTTP请求，当Probe收到2xx或3xx返回时，说明Pod已经就绪。 apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx:latest name: container-0 resources: limits: cpu: 500m memory: 1024Mi requests: cpu: 500m memory: 1024Mi readinessProbe: # readinessProbe httpGet: # HTTP GET定义 path: /read port: 80 imagePullSecrets: - name: imagepull-secret

Readiness Probe高级配置 与Liveness Probe相同，Readiness Probe也有同样的高级配置选项，上面nginx Pod的describe命令回显有中有如下行。 Readiness: exec [ls /var/ready] delay=0s timeout=1s period=10s #success=1 #failure=3 这一行表示readiness probe的具体参数配置，其含义如下： delay=0s 表示容器启动后立即开始探测，没有延迟时间 timeout=1s 表示容器必须在1s内做出相应反馈给probe，否则视为探测失败 period=10s 表示每10s探测一次 #success=1 表示探测连续1次成功表示成功 #failure=3 表示探测连续3次失败后会重启容器 这些是创建时默认设置的，您也可以手动配置，如下所示。 readinessProbe: # Readiness Probe exec: # 定义 ls /readiness/ready 命令 command: - ls - /readiness/ready initialDelaySeconds: 10 # 容器启动后多久开始探测 timeoutSeconds: 2 # 表示容器必须在2s内做出相应反馈给probe，否则视为探测失败 periodSeconds: 30 # 探测周期，每30s探测一次 successThreshold: 1 # 连续探测1次成功表示成功 failureThreshold: 3 # 连续探测3次失败表示失败

Exec Exec方式与HTTP GET方式一致，如下所示，这个探针执行ls /ready命令，如果这个文件存在，则返回0，说明Pod就绪了，否则返回其他状态码。 apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx:latest name: container-0 resources: limits: cpu: 500m memory: 1024Mi requests: cpu: 500m memory: 1024Mi readinessProbe: # Readiness Probe exec: # 定义 ls /ready 命令 command: - ls - /ready imagePullSecrets: - name: imagepull-secret 将上面Deployment的定义保存到deploy-read.yaml文件中，删除之前创建的Deployment，用deploy-read.yaml创建这个Deployment。 # kubectl delete deploy nginx -n $namespace_name deployment.apps "nginx" deleted # kubectl create -f deploy-read.yaml -n $namespace_name deployment.apps/nginx created 这里由于nginx镜像不包含 /ready 这个文件，所以在创建完成后容器不在Ready状态，如下所示，注意READY这一列的值为0/1，表示容器没有Ready。 # kubectl get po -n $namespace_name NAME READY STATUS RESTARTS AGE nginx-7955fd7786-686hp 0/1 Running 0 7s nginx-7955fd7786-9tgwq 0/1 Running 0 7s nginx-7955fd7786-bqsbj 0/1 Running 0 7s 再次查看Service，发现Endpoints一行的值为空，表示没有Endpoints。 $ kubectl describe svc nginx -n $namespace_name Name: nginx ...... Endpoints: ...... 如果此时给容器中创建一个 /ready 的文件，让Readiness Probe成功，则容器会处于Ready状态。再查看Pod和Endpoints，发现创建了/ready文件的容器已经Ready，Endpoints也已经添加。 # kubectl exec -n $namespace_name nginx-7955fd7786-686hp -- touch /ready # kubectl get po -o wide -n $namespace_name NAME READY STATUS RESTARTS AGE IP nginx-7955fd7786-686hp 1/1 Running 0 10m 192.168.93.169 nginx-7955fd7786-9tgwq 0/1 Running 0 10m 192.168.166.130 nginx-7955fd7786-bqsbj 0/1 Running 0 10m 192.168.252.160 # kubectl get endpoints -n $namespace_name NAME ENDPOINTS AGE nginx 192.168.93.169:80 14d

Readiness Probe的工作原理 如果调用kubectl describe命令查看Service的信息，您会看到如下信息。 $ kubectl describe svc nginx -n $namespace_name Name: nginx ...... Endpoints: 192.168.113.81:80,192.168.165.64:80,192.168.198.10:80 ...... 可以看到一个Endpoints，Endpoints同样也是Kubernetes的一种资源对象，可以查询得到。 $ kubectl get endpoints -n $namespace_name NAME ENDPOINTS AGE nginx 192.168.113.81:80,192.168.165.64:80,192.168.198.10:80 14m 这里的192.168.113.81:80是Pod的IP:Port，通过如下命令可以查看到Pod的IP，与上面的IP一致。 # kubectl get pods -o wide -n $namespace_name NAME READY STATUS RESTARTS AGE IP nginx-55c54cc5c7-49chn 1/1 Running 0 1m 192.168.198.10 nginx-55c54cc5c7-x87lb 1/1 Running 0 1m 192.168.165.64 nginx-55c54cc5c7-xp4c5 1/1 Running 0 1m 192.168.113.81 通过Endpoints就可以实现Readiness Probe的效果，当Pod还未就绪时，将Pod的IP:Port在Endpoints中删除，Pod就绪后再加入到Endpoints中，如下图所示。 图1 Readiness Probe的实现原理

添加Label Label的形式为key-value形式，使用非常简单，如下，为Pod设置了app=nginx和env=prod两个Label。 apiVersion: v1 kind: Pod metadata: name: nginx labels: # 为Pod设置两个Label app: nginx env: prod spec: 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_name NAME READY STATUS RESTARTS AGE LABELS nginx 1/1 Running 0 50s app=nginx,env=prod 还可以使用 -L 只查询某些固定的Label。 $ kubectl get pod -L app,env -n $namespace_name NAME READY STATUS RESTARTS AGE APP ENV nginx 1/1 Running 0 1m nginx prod 对已存在的Pod，可以直接使用 kubectl label 命令直接添加Label。 $ kubectl label po nginx creation_method=manual -n $namespace_name pod "nginx" labeled $ kubectl get pod --show-labels -n $namespace_name NAME READY STATUS RESTARTS AGE LABELS nginx 1/1 Running 0 50s app=nginx,env=prod,creation_method=manual

修改Label 对于已存在的Label，如果要修改的话，需要在命令中带上--overwrite，如下所示。 $ kubectl label po nginx env=debug --overwrite -n $namespace_name pod "nginx" labeled $ kubectl get pod --show-labels -n $namespace_name NAME READY STATUS RESTARTS AGE LABELS nginx 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

网络访问场景 在前面两节中介绍了如何通过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管理网络访问

创建Namespace Namespace下需要有一个Network关联VPC及子网，创建完Namespace后需要创建一个Network。 通常情况下，没有频繁创建Namespace的需求，建议通过云容器实例的控制台界面创建Namespace，具体方法请参见创建命名空间。 以下示例创建一个名为namespace-test的Namespace，指定云容器实例的资源类型为general-computing。 apiVersion: v1 kind: Namespace metadata: name: namespace-test labels: sys_enterprise_project_id: "0" annotations: namespace.kubernetes.io/flavor: general-computing spec: finalizers: - kubernetes 这里的定义文件采用YAML格式描述（如果您对YAML格式不了解，可以参考YAML语法），也可使用JSON格式。 sys_enterprise_project_id：表示企业项目ID，可进入企业管理的企业项目详情页面获取。未开通企业管理的用户无需配置此参数。不配置时默认为0，表示default企业项目。 namespace.kubernetes.io/flavor: general-computing：指定命名空间类型。 命令空间的类型有如下两种： general-computing：通用计算型，支持创建含CPU资源的容器实例及工作负载，适用于通用计算场景。 gpu-accelerated：GPU型，支持创建含GPU资源的容器实例及工作负载，适用于深度学习、科学计算、视频处理等场景。 假如上面Namespace定义的文件名称为ns.yaml，则执行kubectl create -f ns.yaml即可创建命名空间，-f 表示从文件创建。 # kubectl create -f ns.yaml namespace/namespace-test created 执行kubectl get ns查询namespace是否创建成功，ns为namespace的缩写。 # kubectl get ns NAME STATUS AGE namespace-test Active 23s 如上，可以看到namespace-test这个命名空间创建成功，且存在的时长为23秒。 登录云容器实例控制台，单击左侧导航栏“命名空间”，您可以看到命令空间创建成功，但状态为“异常”。这是因为在云容器实例中，您需要为Namespace定义网络策略，具体操作方法请参见创建Network。 图2 Namespace-异常

为kubectl上下文指定Namespace 上面创建Network是在指定的Namespace下创建的，本文档后续的资源创建都是在某个命名空间下操作，每次都指定命名空间比较麻烦，您可以为kubectl上下文指定命名空间，这样在某个上下文中，创建的资源就都是在某个命名空间下，方便操作。 指定Namespace只需要在设置上下文命令中添加一个“--namespace”选项，如下所示。 kubectl config set-context $context --namespace=$ns 其中，$ns为Namespace的名称；$context 为上下文的名称，可以自定义，也可执行如下命令获取： # kubectl config get-contexts CURRENT 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 pod No resources found.

Namespace与网络的关系 从网络角度看，命名空间对应一个虚拟私有云（VPC）中一个子网，如图1所示，在创建命名空间时会关联已有VPC或创建一个新的VPC，并在VPC下创建一个子网。后续在该命名空间下创建Pod、Service等资源时都会在对应的VPC及子网之内，且占用子网中的IP地址。 通常情况下，如果您在同一个VPC下还会使用其他服务的资源，您需要考虑您的网络规划，如子网网段划分、IP数量规划等，确保有可用的网络资源。 图1 命名空间与VPC子网的关系

创建Job 以下是一个Job配置，其计算π到2000位并打印输出。Job结束需要运行50个Pod，这个示例中就是打印π 50次，并行运行5个Pod，Pod如果失败最多重试5次。 apiVersion: batch/v1 kind: Job metadata: name: pi-with-timeout namespace: cci-namespace-test1 spec: completions: 50 # 运行的次数，即Job结束需要成功运行的Pod个数 parallelism: 5 # 并行运行Pod的数量，默认为1 backoffLimit: 5 # 表示失败Pod的重试最大次数，超过这个次数不会继续重试。 activeDeadlineSeconds: 10 # 表示Pod超期时间，一旦达到这个时间，Job即其所有的Pod都会停止。 template: # Pod定义 spec: containers: - name: pi image: perl command: - perl - "-Mbignum=bpi" - "-wle" - print bpi(2000) restartPolicy: Never 根据completions和parallelism的设置，可以将Job划分为以下几种类型。 表1 任务类型 Job类型 说明 使用示例 一次性Job 创建一个Pod直至其成功结束 数据库迁移 固定结束次数的Job 依次创建一个Pod运行直至completions个成功结束 处理工作队列的Pod 固定结束次数的并行Job 依次创建多个Pod运行直至completions个成功结束 多个Pod同时处理工作队列 并行Job 创建一个或多个Pod直至有一个成功结束 多个Pod同时处理工作队列

创建CronJob 相比Job，CronJob就是一个加了定时的Job，CronJob执行时是在指定的时间创建出Job，然后由Job创建出Pod。 apiVersion: batch/v1beta1 kind: CronJob metadata: name: cronjob-example namespace: cci-namespace-test1 spec: schedule: "0,15,30,45 * * * *" # 定时相关配置 jobTemplate: # Job的定义 spec: template: spec: restartPolicy: OnFailure containers: - name: main image: pi cron的格式从前到后就是： Minute Hour Day of month Month Day of week 如 "0,15,30,45 * * * * " ，前面逗号隔开的是分钟，后面第一个* 表示每小时，第二个 * 表示每个月的哪天，第三个表示每月，第四个表示每周的哪天。 如果你想要每个月的第一天里面每半个小时执行一次，那就可以设置为" 0,30 * 1 * * " 如果你想每个星期天的3am执行一次任务，那就可以设置为 "0 3 * * 0"。 更详细的cron格式说明请参见https://zh.wikipedia.org/wiki/Cron。

在环境变量中引用Secret Secret最常见的用法是作为环境变量注入到容器中，如下示例。 apiVersion: v1 kind: Pod metadata: name: nginx spec: 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: v1 kind: Pod metadata: name: nginx spec: 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

创建Secret 如下示例中定义的Secret中包含两条Key-Value。 apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque data: key1: VkZNME0wVlpVbEpQVHpGTFdrSkRWVWhCV2s5T1ZrNUxUVlZNUjBzMFRWcElVMFpVUkVWV1N3PT0= # Base64编码后的值 key2: T0VkR1RGRlZVRlpVU2xCWFdUZFBVRUZCUmtzPQ== # Base64编码后的值

使用PVC 使用PVC申请到存储资源后，您可以在Pod中使用Volume来关联PVC，并将Volume挂载到容器中使用。 下面是的示例中说明了PVC如何在Pod中使用，这个Pod定义了一个名为“pvc-test-example”的Volume，并将这个Volume挂载到容器的“/tmp/volume0”路径，这样您写入到/tmp的数据就是写到名为pvc-test的PVC中。 写入上面申请的sas型云硬盘中 apiVersion: v1 kind: Pod metadata: name: nginx labels: app: nginx spec: 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: v1 kind: Pod metadata: name: nginx labels: app: nginx spec: 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

创建PVC 通过如下定义创建PVC，这个定义申请了一块大小为100G的SAS型云硬盘。 如果需要创建加密类型的云硬盘存储卷，在metadata.annotations中增加paas.storage.io/cryptKeyId字段即可。 apiVersion: v1 kind: PersistentVolumeClaim metadata: 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: v1 kind: PersistentVolumeClaim metadata: 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

配置有效的Liveness Probe liveness probe应该检查什么 一个好的liveness probe应该检查应用内部所有关键部分是否健康，并使用一个专有的URL访问，例如 /health，当访问 /health 时执行这个功能，然后返回对应结果。这里要注意不能做鉴权，不然 probe 就会一直失败导致陷入重启的死循环。 另外检查只能限制在应用内部，不能检查依赖外部的部分，例如当前端web server不能连接数据库时，这个就不能看成web server不健康。 liveness probe必须轻量 liveness probe不能占用过多的资源，且不能占用过长的时间，否则所有资源都在做健康检查，这就没有意义了。例如Java应用，就最好用HTTP GET方式，如果用 Exec 方式，JVM启动就占用了非常多的资源。

Liveness Probe高级配置 上面liveness-http的describe命令回显中有如下行。 Liveness: http-get http://:8080/ delay=0s timeout=1s period=10s #success=1 #failure=3 这一行表示liveness probe的具体参数配置，其含义如下： delay=0s 表示容器启动后立即开始探测，没有延迟时间 timeout=1s 表示容器必须在1s内做出相应反馈给probe，否则视为探测失败 period=10s 表示每10s探测一次 #success=1 表示探测连续1次成功表示成功 #failure=3 表示探测连续3次失败后会重启容器 这些是创建时默认设置的，您也可以手动配置，如下所示。 apiVersion: v1 kind: Pod metadata: name: liveness-http spec: template: metadata: annotations: cci.io/httpget-probe-timeout-enable:"true" containers: - image: k8s.gcr.io/liveness livenessProbe: httpGet: path: / port: 8080 initialDelaySeconds: 10 # 容器启动后多久开始探测 timeoutSeconds: 2 # 表示容器必须在2s内做出相应反馈给probe，否则视为探测失败 periodSeconds: 30 # 探测周期，每30s探测一次 successThreshold: 1 # 连续探测1次成功表示成功 failureThreshold: 3 # 连续探测3次失败表示失败 initialDelaySeconds一般要设置大于0，这是由于很多情况下容器虽然启动成功，但应用就绪也需要一定的时间，需要等就绪时间之后才能返回成功，否则就会导致probe经常失败。 另外failureThreshold可以设置多次循环探测，这样在实际应用中健康检查的程序就不需要多次循环，这一点在开发应用时需要注意。

HTTP GET HTTP GET方式是最常见的探测方法，其具体机制是向容器发送HTTP GET请求，如果probe收到2xx或3xx，说明容器是健康的，定义方法如下所示。 apiVersion: v1 kind: Pod metadata: name: liveness-http spec: containers: - name: liveness image: k8s.gcr.io/liveness args: - /server livenessProbe: # liveness probe httpGet: # HTTP GET定义 path: /healthz port: 8080 创建这个Pod。 $ kubectl create -f liveness-http.yaml -n $namespace_name pod/liveness-http created 如上，这个probe往容器的8080端口发送HTTP GET请求，上面的程序会在第五次请求会返回500状态码，这时Kubernetes会去重启容器。 查看Pod详情。 $ kubectl describe po liveness-http -n $namespace_name Name: liveness-http ...... Containers: container-0: ...... State: Running Started: Mon, 12 Nov 2018 22:57:28 +0800 Last State: Terminated Reason: Error Exit Code: 137 Started: Mon, 12 Nov 2018 22:55:40 +0800 Finished: Mon, 12 Nov 2018 22:57:27 +0800 Ready: True Restart Count: 1 Liveness: http-get http://:8080/ delay=0s timeout=1s period=10s #success=1 #failure=3 ...... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 3m5s default-scheduler Successfully assigned default/pod-liveness to node2 Normal Pulling 74s (x2 over 3m4s) kubelet, node2 pulling image "pod-liveness" Normal Killing 74s kubelet, node2 Killing container with id docker://container-0:Container failed liveness probe.. Container will be killed and recreated. 可以看到Pod当前状态是Running，Last State是Terminated，Restart Count为1，说明已经重启1次，另外从事件中也可以看到 Killing container with id docker://container-0:Container failed liveness probe.. Container will be killed and recreated. 另外，容器Kill后会重新创建一个新容器，不只是之前的容器重启。

Exec Exec即执行具体命令，具体机制是probe执行容器中的命令并检查命令退出的状态码，如果状态码为0则说明健康，定义方法如下所示。 apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-exec spec: containers: - name: liveness image: busybox args: - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 livenessProbe: # liveness probe exec: # Exec定义 command: - cat - /tmp/healthy 上面定义在容器中执行cat /tmp/healthy命令，如果成功执行并返回0，则说明容器是健康的。

存活探针 Kubernetes提供了自愈的能力，具体就是能感知到容器崩溃，然后能够重启这个容器。但是有时候例如Java程序内存泄漏了，程序无法正常工作，但是JVM进程却是一直运行的，对于这种应用本身业务出了问题的情况，kubernetes提供了liveness probe机制，通过检测容器响应是否正常来决定是否重启，这是一种很好的健康检查机制。 毫无疑问，每个pod最好都定义liveness probe，否则Kubernetes无法感知Pod是否正常运行。 当前云容器实例支持如下两种探测机制。 HTTP GET：向容器发送HTTP GET请求，如果probe收到2xx或3xx，说明容器是健康的。 需要为pod配置以下annotation使超时时间(timeoutSeconds)生效： cci.io/httpget-probe-timeout-enable:"true" 具体请参见Liveness Probe高级配置样例。 Exec：probe执行容器中的命令并检查命令退出的状态码，如果状态码为0则说明健康。

生命周期管理 云容器实例基于Kubernetes，提供了容器生命周期钩子，在容器的生命周期的特定阶段执行调用，比如容器在停止前希望执行某项操作，就可以注册相应的钩子函数。目前提供的生命周期钩子函数如下所示。 启动后处理（PostStart）：负载启动后触发。 停止前处理（PreStop）：负载停止前触发。 调用接口时，只需配置pod的lifecycle.postStart或lifecycle.preStop参数，如下所示。 apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - image: nginx:latest name: container-0 resources: limits: cpu: 500m memory: 1024Mi requests: cpu: 500m memory: 1024Mi lifecycle: postStart: # 启动后处理 exec: command: - "/postStart.sh" preStop: # 停止前处理 exec: command: - "/preStop.sh" imagePullSecrets: - name: imagepull-secret 父主题： Pod

启动命令 启动容器就是启动主进程，但有些时候，启动主进程前，需要一些准备工作。比如MySQL类的数据库，可能需要一些数据库配置、初始化的工作，这些工作要在最终的MySQL服务器运行之前解决。您可以在制作镜像时通过在Dockerfile文件中设置ENTRYPOINT或CMD来完成。 如下所示的Dockerfile中设置了ENTRYPOINT ["top", "-b"]命令，其将会在容器启动时执行。 FROM ubuntu ENTRYPOINT ["top", "-b"] 调用接口时，只需配置pod的containers.command参数，该参数是list类型，第一个参数为执行命令，后面均为命令的参数。 apiVersion: v1 kind: Pod metadata: name: Ubuntu spec: 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

环境变量 环境变量是容器运行环境中设定的一个变量。 环境变量为应用提供极大的灵活性，您可以在应用程序中使用环境变量，在创建容器时为环境变量赋值，容器运行时读取环境变量的值，从而做到灵活的配置，而不是每次都重新编写应用程序制作镜像。 另外，您还可以使用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协议创建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证书的名称

路由到多个服务 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