华为云用户手册

  • Pod规格计算方式 Pod规格的计算步骤如下: Pod 包含的所有 Init 容器上定义的任何特定资源的约束值 (limit) 或 请求值 (request) 的最大值,作为 Pod 有效初始 request/limit。 Pod 对资源的有效 limit/request ,是取如下两项的较大者: 所有应用容器对某个资源的 limit/request 之和。 对某个资源的有效初始的 limit/request 。 针对如下实例,计算Pod规格。 apiVersion: v1 kind: Pod metadata: name: web-app spec: 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
  • 概念 Init-Containers,即初始化容器,顾名思义容器启动的时候,会先启动可一个或多个容器,如果有多个,那么这几个Init Container按照定义的顺序依次执行,只有所有的Init Container执行完后,主容器才会启动。由于一个Pod里的存储卷是共享的,所以Init Container里产生的数据可以被主容器使用到。 Init Container可以在多种K8S资源里被使用到如Deployment、DaemonSet、Job等,但归根结底都是在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/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
共100000条