云服务器内容精选

  • 创建Statefulset Statefulset的YAML定义与其他对象基本相同,主要有两个差异点: serviceName指定了Statefulset使用哪个Headless Service,需要填写Headless Service的名称。 volumeClaimTemplates是用来申请持久化声明PVC ,这里定义了一个名为data的模板,它会为每个Pod创建一个PVC,storageClassName指定了持久化存储的类型,在PV、PVC和StorageClass会详细介绍;volumeMounts是为Pod挂载存储。当然如果不需要存储的话可以删除volumeClaimTemplates和volumeMounts字段。 apiVersion: apps/v1 kind: StatefulSet metadata: name: nginx spec: serviceName: nginx # headless service的名称 replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: container-0 image: nginx:alpine resources: limits: cpu: 100m memory: 200Mi requests: cpu: 100m memory: 200Mi volumeMounts: # Pod挂载的存储 - name: data mountPath: /usr/share/nginx/html # 存储挂载到/usr/share/nginx/html imagePullSecrets: - name: default-secret volumeClaimTemplates: - metadata: name: data spec: accessModes: - ReadWriteMany resources: requests: storage: 1Gi storageClassName: csi-nas # 持久化存储的类型 执行如下命令创建。 # kubectl create -f statefulset.yaml statefulset.apps/nginx created 命令执行后,查询一下StatefulSet和Pod,可以看到Pod的名称后缀从0开始到2,逐个递增。 # kubectl get statefulset NAME READY AGE nginx 3/3 107s # kubectl get pods NAME READY STATUS RESTARTS AGE nginx-0 1/1 Running 0 112s nginx-1 1/1 Running 0 69s nginx-2 1/1 Running 0 39s 此时如果手动删除nginx-1这个Pod,然后再次查询Pod,可以看到StatefulSet重新创建了一个名称相同的Pod,通过创建时间5s可以看出nginx-1是刚刚创建的。 # kubectl delete pod nginx-1 pod "nginx-1" deleted # kubectl get pods NAME READY STATUS RESTARTS AGE nginx-0 1/1 Running 0 3m4s nginx-1 1/1 Running 0 5s nginx-2 1/1 Running 0 1m10s 进入容器查看容器的hostname,可以看到同样是nginx-0、nginx-1和nginx-2。 # kubectl exec nginx-0 -- sh -c 'hostname' nginx-0 # kubectl exec nginx-1 -- sh -c 'hostname' nginx-1 # kubectl exec nginx-2 -- sh -c 'hostname' nginx-2 同时可以看一下StatefulSet创建的PVC,可以看到这些PVC,都以“PVC名称-StatefulSet名称-编号”的方式命名,并且处于Bound状态。 # kubectl get pvc NAME STATUS VOLUME CAPACITY AC CES S MODES STORAGECLASS AGE data-nginx-0 Bound pvc-f58bc1a9-6a52-4664-a587-a9a1c904ba29 1Gi RWX csi-nas 2m24s data-nginx-1 Bound pvc-066e3a3a-fd65-4e65-87cd-6c3fd0ae6485 1Gi RWX csi-nas 101s data-nginx-2 Bound pvc-a18cf1ce-708b-4e94-af83-766007250b0c 1Gi RWX csi-nas 71s
  • 有状态负载(StatefulSet) Deployment控制器下的Pod都有个共同特点,那就是每个Pod除了名称和IP地址不同,其余完全相同。需要的时候,Deployment可以通过Pod模板创建新的Pod;不需要的时候,Deployment就可以删除任意一个Pod。 但是在某些场景下,这并不满足需求,比如有些分布式的场景,要求每个Pod都有自己单独的状态时,比如 分布式数据库 ,每个Pod要求有单独的存储,这时Deployment无法满足业务需求。 分布式有状态应用的特点主要是应用中每个部分的角色不同(即分工不同),比如数据库有主备、Pod之间有依赖,在Kubernetes中部署有状态应用对Pod有如下要求: Pod能够被别的Pod找到,要求Pod有固定的标识。 每个Pod有单独存储,Pod被删除恢复后,必须读取原来的数据,否则状态就会不一致。 Kubernetes提供了StatefulSet来解决这个问题,其具体如下: StatefulSet给每个Pod提供固定名称,Pod名称增加从0-N的固定后缀,Pod重新调度后Pod名称和HostName不变。 StatefulSet通过Headless Service给每个Pod提供固定的访问 域名 。 StatefulSet通过创建固定标识的PVC保证Pod重新调度后还是能访问到相同的持久化数据。
  • URI GET /api/v1/namespaces/{namespace}/pods/{name}/exec 表1 路径参数 参数 是否必选 参数类型 描述 name 是 String name of the PodExecOptions namespace 是 String object name and auth scope, such as for teams and projects 表2 Query参数 参数 是否必选 参数类型 描述 command 否 String Command is the remote command to execute. argv array. Not executed within a shell. container 否 String Container in which to execute the command. Defaults to only container if there is only one container in the pod. stderr 否 Boolean Redirect the standard error stream of the pod for this call. Defaults to true. stdin 否 Boolean Redirect the standard input stream of the pod for this call. Defaults to false. stdout 否 Boolean Redirect the standard output stream of the pod for this call. Defaults to true. tty 否 Boolean TTY if true indicates that a tty will be allocated for the exec call. Defaults to false.
  • 状态码 状态码 描述 200 OK 400 BadRequest 401 Unauthorized 403 Forbidden 404 NotFound 405 MethodNotAllowed 406 NotAcceptable 409 Conflict 415 UnsupportedMediaType 422 Invalid 429 TooManyRequests 500 InternalError 503 ServiceUnavailable 504 ServerTimeout
  • 查询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
  • 使用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是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。
  • 创建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
  • 约束限制 开启固定EIP功能需要和Pod自动创建EIP功能配合使用,详情请参见为Pod配置EIP。 目前只支持StatefulSet类型的Pod或直接创建的Pod固定EIP,暂不支持Deployment等其他类型的工作负载配置Pod固定EIP。 固定EIP创建后,生命周期内(如过期时间未到/Pod还在使用中)不支持通过Pod修改EIP属性。 对Pod的EIP地址无明确要求的业务不建议配置固定EIP,因为配置了固定EIP的Pod,Pod重建的耗时会略微变长。
  • 容器组(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。
  • 使用环境变量 环境变量是容器运行环境中设定的一个变量。 环境变量为应用提供极大的灵活性,您可以在应用程序中使用环境变量,在创建容器时为环境变量赋值,容器运行时读取环境变量的值,从而做到灵活的配置,而不是每次都重新编写应用程序制作镜像。 环境变量的使用方法如下所示,配置spec.containers.env字段即可。 apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - image: nginx:alpine name: container-0 resources: limits: cpu: 100m memory: 200Mi requests: cpu: 100m memory: 200Mi env: # 环境变量 - name: env_key value: env_value imagePullSecrets: - name: default-secret 执行如下命令查看容器中的环境变量,可以看到env_key这个环境变量,其值为env_value。 $ kubectl exec -it nginx -- env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin HOSTNAME=nginx TERM=xterm env_key=env_value 环境变量还可以引用ConfigMap和Secret,具体使用方法请参见在环境变量中引用ConfigMap和在环境变量中引用Secret。
  • 容器启动命令 启动容器就是启动主进程,但有些时候,启动主进程前,需要一些准备工作。比如MySQL类的数据库,可能需要一些数据库配置、初始化的工作,这些工作要在最终的MySQL服务器运行之前做完。这些操作,可以在制作镜像时通过在Dockerfile文件中设置ENTRYPOINT或CMD来完成,如下所示的Dockerfile中设置了ENTRYPOINT ["top", "-b"]命令,其将会在容器启动时执行。 FROM ubuntu ENTRYPOINT ["top", "-b"] 实际使用时,只需配置Pod的containers.command参数,该参数是list类型,第一个参数为执行命令,后面均为命令的参数。 apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - image: nginx:alpine name: container-0 resources: limits: cpu: 100m memory: 200Mi requests: cpu: 100m memory: 200Mi command: # 启动命令 - top - "-b" imagePullSecrets: - name: default-secret
  • 容器的生命周期 Kubernetes提供了容器生命周期钩子,在容器的生命周期的特定阶段执行调用,比如容器在停止前希望执行某项操作,就可以注册相应的钩子函数。目前提供的生命周期钩子函数如下所示。 启动后处理(PostStart):容器启动后触发。 停止前处理(PreStop):容器停止前触发。 实际使用时,只需配置Pod的lifecycle.postStart或lifecycle.preStop参数,如下所示。 apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - image: nginx:alpine name: container-0 resources: limits: cpu: 100m memory: 200Mi requests: cpu: 100m memory: 200Mi lifecycle: postStart: # 启动后处理 exec: command: - "/postStart.sh" preStop: # 停止前处理 exec: command: - "/preStop.sh" imagePullSecrets: - name: default-secret
  • 创建Pod kubernetes中资源可以使用YAML描述(如果您对YAML格式不了解,可以参考YAML语法),也可以使用JSON,如下示例描述了一个名为nginx的Pod,这个Pod中包含一个名为container-0的容器,使用nginx:alpine镜像,使用的资源为100m CPU、200Mi内存。 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: cpu: 100m memory: 200Mi requests: cpu: 100m memory: 200Mi imagePullSecrets: # 拉取镜像使用的证书,在CCE上必须为default-secret - name: default-secret 如上面YAML的注释,YAML描述文件主要为如下部分: metadata:一些名称/标签/namespace等信息。 spec:Pod实际的配置信息,包括使用什么镜像,volume等。 如果去查询Kubernetes的资源,您会看到还有一个status字段,status描述kubernetes资源的实际状态,创建时不需要配置。这个示例是一个最小集,其他参数定义后面会逐步介绍。 Pod定义好后就可以使用kubectl创建,如果上面YAML文件名称为nginx.yaml,则创建命令如下所示,-f表示使用文件方式创建。 $ kubectl create -f nginx.yaml pod/nginx created