云服务器内容精选

  • 升级示例 Deployment的升级可以是声明式的,也就是说只需要修改Deployment的YAML定义即可,比如使用kubectl edit命令将上面Deployment中的镜像修改为nginx:alpine。修改完成后再查询ReplicaSet和Pod,发现创建了一个新的ReplicaSet,Pod也重新创建了。 $ kubectl edit deploy nginx $ kubectl get rs NAME DESIRED CURRENT READY AGE nginx-6f9f58dffd 2 2 2 1m nginx-7f98958cdf 0 0 0 48m $ kubectl get pods NAME READY STATUS RESTARTS AGE nginx-6f9f58dffd-tdmqk 1/1 Running 0 1m nginx-6f9f58dffd-tesqr 1/1 Running 0 1m Deployment可以通过maxSurge和maxUnavailable两个参数控制升级过程中同时重新创建Pod的比例,这在很多时候是非常有用,配置如下所示。 spec: strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 0 type: RollingUpdate 在前面的例子中,由于spec.replicas是2,如果maxSurge和maxUnavailable都为默认值25%,那实际升级过程中,maxSurge允许最多3个Pod存在(向上取整,2*1.25=2.5,取整为3),而maxUnavailable则不允许有Pod Unavailable(向上取整,2*0.75=1.5,取整为2),也就是说在升级过程中,一直会有2个Pod处于运行状态,每次新建一个Pod,等这个Pod创建成功后再删掉一个旧Pod,直至Pod全部为新Pod。
  • 回滚 回滚也称为回退,即当发现升级出现问题时,让应用回到原版本。Deployment可以非常方便地回滚到原版本。 例如上面升级的新版镜像有问题,可以执行kubectl rollout undo命令进行回滚。 $ kubectl rollout undo deployment nginx deployment.apps/nginx rolled back Deployment之所以能如此容易的做到回滚,是因为Deployment是通过ReplicaSet控制Pod的,升级后之前ReplicaSet都一直存在,Deployment回滚做的就是使用之前的ReplicaSet再次把Pod创建出来。Deployment中保存ReplicaSet的数量可以使用revisionHistoryLimit参数限制,默认值为10。
  • 升级参数说明 最大浪涌(maxSurge) 与spec.replicas相比,可以有多少个Pod存在,默认值是25%,比如spec.replicas为 4,那升级过程中就不能超过5个Pod存在,即按1个的步伐升级,实际升级过程中会换算成数字,且换算会向上取整。这个值也可以直接设置成数字。 仅Deployment在“滚动升级”方式下支持配置。 最大无效实例数(maxUnavailable) 与spec.replicas相比,可以有多少个Pod失效,也就是删除的比例,默认值是25%,比如spec.replicas为4,那升级过程中就至少有3个Pod存在,即删除Pod的步伐是1。同样这个值也可以设置成数字。 仅Deployment、DaemonSet在“滚动升级”方式下支持配置。 实例可用最短时间(minReadySeconds) 指定新创建的 Pod 在没有任意容器崩溃情况下的最小就绪时间, 只有超出这个时间 Pod 才被视为可用。默认值为 0(Pod 在准备就绪后立即将被视为可用)。 仅Deployment、DaemonSet支持配置。 最大保留版本数(revisionHistoryLimit) 用来设定出于回滚目的所要保留的旧 ReplicaSet 数量。 这些旧 ReplicaSet 会消耗 etcd 中的资源,并占用 kubectl get rs 的输出。 每个工作负载修订版本的配置都存储在其 ReplicaSets 中;因此,一旦删除了旧的 ReplicaSet, 将失去回滚到工作负载的对应修订版本的能力。 默认情况下,系统保留 10 个旧 ReplicaSet,但其理想值取决于新工作负载的频率和稳定性。 升级最大时长(progressDeadlineSeconds) 指定系统在报告 Deployment 进展失败 之前等待 Deployment 取得进展的秒数。 这类报告会在资源状态中体现为 Type=Progressing、Status=False、 Reason=ProgressDeadlineExceeded。Deployment 控制器将持续重试 Deployment。 将来,一旦实现了自动回滚,Deployment 控制器将在探测到这样的条件时立即回滚 Deployment。 如果指定,则此字段值需要大于 .spec.minReadySeconds 取值。 仅Deployment支持配置。 缩容时间窗(terminationGracePeriodSeconds): 优雅删除时间,默认为30秒,删除Pod时发送SIGTERM终止信号,然后等待容器中的应用程序终止执行,如果在terminationGracePeriodSeconds时间内未能终止,则发送SIGKILL的系统信号强行终止。
  • 容器基本信息 工作负载是Kubernetes对一组Pod的抽象模型,用于描述业务的运行载体,一个Pod可以封装1个或多个容器,您可以单击右上方的“添加容器”,添加多个容器镜像并分别进行设置。 图1 添加容器 表1 镜像参数说明 参数 说明 容器名称 为容器命名。 镜像名称 单击后方“选择镜像”,选择容器使用的镜像。 镜像版本 选择需要部署的镜像版本。 更新策略 镜像更新/拉取策略。可以勾选“总是拉取镜像”,表示每次都从镜像仓库拉取镜像;如不勾选则优使用节点已有的镜像,如果没有这个镜像再从镜像仓库拉取。 CPU配额 申请:容器需要使用的最小CPU值,默认0.25Core。 限制:允许容器使用的CPU最大值。建议设容器配额的最高限额,避免容器资源超额导致系统故障。 内存配额 申请:容器需要使用的内存最小值,默认512MiB。 限制:允许容器使用的内存最大值。如果超过,容器会被终止。 申请和限制的具体请参见设置容器规格。 初始化容器 选择容器是否作为初始化容器。 Init 容器是一种特殊容器,在 Pod 内的应用容器启动之前运行。详细说明请参见Init 容器。 父主题: 容器设置
  • 通过控制台配置负载亲和调度策略 在创建工作负载时,在“高级设置”中找到“调度策略”。创建工作负载的步骤详情请参见创建工作负载。 选择负载亲和调度的策略类型。 不配置:不设置负载亲和策略。 优先多可用区部署:该策略通过Pod自身反亲和实现,优先将工作负载的Pod调度到不同可用区的节点上。 强制多可用区部署:该策略通过Pod自身反亲和实现,强制将工作负载的Pod调度到不同可用区,并且强制调度到不同节点上。使用该调度策略时,如果节点数小于实例数或节点资源不足,Pod将无法全部运行。 自定义亲和策略:根据Pod标签实现灵活的调度策略,支持的调度策略类型请参见表1。选择合适的策略类型后,单击添加调度策略,参数详情请参见表2。 表1 负载亲和策略类型 策略 规则类型 说明 工作负载亲和性 必须满足 即硬约束,设置必须满足的条件,对应YAML定义中的requiredDuringSchedulingIgnoredDuringExecution字段。 通过标签筛选需要亲和的Pod,如果满足筛选条件的Pod已经运行在拓扑域中的某个节点上,调度器会将本次创建的Pod强制调度到该拓扑域。 说明: 添加多条亲和性规则时,即设置多个标签筛选需要亲和的Pod,则本次创建的Pod必须要同时亲和所有满足标签筛选的Pod,即所有满足标签筛选的Pod要处于同一拓扑域中才可以调度。 尽量满足 即软约束,设置尽量满足的条件,对应YAML定义中的preferredDuringSchedulingIgnoredDuringExecution字段。 通过标签筛选需要亲和的Pod,如果满足筛选条件的Pod已经运行在拓扑域中的某个节点上,调度器会将本次创建的Pod优先调度到该拓扑域。 说明: 添加多条亲和性规则时,即设置多个标签筛选需要亲和的Pod,则本次创建的Pod会尽量同时亲和多个满足标签筛选的Pod。但即使所有Pod都不满足标签筛选条件,也会选择一个拓扑域进行调度。 工作负载反亲和性 必须满足 即硬约束,设置必须满足的条件,对应YAML定义中的requiredDuringSchedulingIgnoredDuringExecution字段。 通过标签筛选需要反亲和的一个或多个Pod,如果满足筛选条件的Pod已经运行在拓扑域中的某个节点上,调度器不会将本次创建的Pod调度到该拓扑域。 说明: 添加多条反亲和性规则时,即设置多个标签筛选需要反亲和的Pod,则本次创建的Pod必须要同时反亲和所有满足标签筛选的Pod,即所有满足标签筛选的Pod所处的拓扑域都不会被调度。 尽量满足 即软约束,设置尽量满足的条件,对应YAML定义中的preferredDuringSchedulingIgnoredDuringExecution字段。 通过标签筛选需要反亲和的一个或多个Pod,如果满足筛选条件的Pod已经运行在拓扑域中的某个节点上,调度器会将本次创建的Pod优先调度到其他拓扑域。 说明: 添加多条反亲和性规则时,即设置多个标签筛选需要反亲和的Pod,则本次创建的Pod会尽量同时反亲和多个满足标签筛选的Pod。但即使每个拓扑域都存在需要反亲和的Pod,也会选择一个拓扑域进行调度。 表2 负载亲和/反亲和调度策略设置参数说明 参数名 参数描述 权重 仅支持在“尽量满足”策略中添加。权重的取值范围为1-100,调度器在进行调度时会将该权重加到其他优先级函数的评分上,最终将Pod调度到总分最大的节点上。 命名空间 指定调度策略生效的命名空间。 拓扑域 拓扑域(topologyKey)通过节点的标签先圈定调度的节点范围,例如标签指定为kubernetes.io/hostname,则根据标签值不同(标签值为节点名称)区分范围,不同名称的节点为不同的拓扑域,此时一个拓扑域中仅包含一个节点;如果指定标签为kubernetes.io/os,则根据标签值不同(标签值为节点的操作系统类型)来区分,不同操作系统的节点为不同的拓扑域,此时一个拓扑域中可能包含多个节点。 根据拓扑域确定节点范围后,然后再选择策略定义的内容(通过标签名、操作符、标签值确定)进行调度,调度时最小单位为拓扑域。例如,某个拓扑域中的一个节点满足负载亲和性规则,则该拓扑域中的节点均可以被调度。 标签名 设置工作负载亲和/反亲和性时,填写需要匹配的工作负载标签。 该标签可以使用系统默认的标签,也可以使用自定义标签。 操作符 可以设置四种匹配关系(In、NotIn、Exists、DoesNotExist)。 In:亲和/反亲和对象的标签在标签值列表(values字段)中。 NotIn:亲和/反亲和对象的标签不在标签值列表(values字段)中。 Exists:亲和/反亲和对象存在指定标签名。 DoesNotExist:亲和/反亲和对象不存在指定标签名。 标签值 设置工作负载亲和/反亲和性时,填写工作负载标签对应的标签值。 调度策略添加完成后,单击“创建工作负载”。
  • 通过控制台配置节点亲和调度策略 在创建工作负载时,在“高级设置”中找到“调度策略”。创建工作负载的步骤详情请参见创建工作负载。 选择节点亲和调度的策略类型。 不配置:不设置节点亲和策略。 指定节点调度:指定工作负载Pod部署的节点。若不指定,将根据集群默认调度策略随机调度。 指定节点池调度:指定工作负载Pod部署的节点池。若不指定,将根据集群默认调度策略随机调度。 自定义亲和策略:根据节点标签实现灵活的调度策略,支持的调度策略类型请参见表3。选择合适的策略类型后,单击添加调度策略,参数详情请参见表4。您也可以单击“指定节点”或“指定可用区”通过控制台快速选择需要调度的节点或可用区。 “指定节点”和“指定可用区”本质也是通过标签实现,只是通过控制台提供了更为便捷的操作,无需手动填写节点标签和标签值。指定节点使用的是 kubernetes.io/hostname 标签,指定可用区使用的是 failure-domain.beta.kubernetes.io/zone 标签。 表3 节点亲和性设置 参数名 参数描述 必须满足 即硬约束,设置必须要满足的条件,对应requiredDuringSchedulingIgnoredDuringExecution。 添加多条“必须满足”规则时,只需要满足一条规则就会进行调度。 尽量满足 即软约束,设置尽量满足的条件,对应preferredDuringSchedulingIgnoredDuringExecution。 添加多条“尽量满足”规则时,满足其中一条或者都不满足也会进行调度。 表4 节点亲和性调度策略设置参数说明 参数名 参数描述 标签名 设置节点亲和性时,填写需要匹配的节点标签。 该标签可以使用系统默认的标签,也可以使用自定义标签。 操作符 可以设置六种匹配关系(In、NotIn、Exists、DoesNotExist、Gt、Lt)。 In:亲和/反亲和对象的标签在标签值列表(values字段)中。 NotIn:亲和/反亲和对象的标签不在标签值列表(values字段)中。 Exists:亲和/反亲和对象存在指定标签名。 DoesNotExist:亲和/反亲和对象不存在指定标签名。 Gt:仅在节点亲和性中设置,调度节点的标签值大于列表值 (字符串比较)。 Lt:仅在节点亲和性中设置,调度节点的标签值小于列表值 (字符串比较)。 标签值 设置节点亲和性时,填写节点标签对应的标签值。 调度策略添加完成后,单击“创建工作负载”。
  • 操作符取值说明 您可以使用操作符(operator字段)来设置使用规则的逻辑关系,operator取值如下: In:亲和/反亲和对象的标签在标签值列表(values字段)中。 NotIn:亲和/反亲和对象的标签不在标签值列表(values字段)中。 Exists:亲和/反亲和对象存在指定标签名。 DoesNotExist:亲和/反亲和对象不存在指定标签名。 Gt:仅在节点亲和性中设置,调度节点的标签值大于列表值 (字符串比较)。 Lt:仅在节点亲和性中设置,调度节点的标签值小于列表值 (字符串比较)。
  • 操作场景 环境变量是指容器运行环境中设定的一个变量,环境变量可以在工作负载部署后修改,为工作负载提供极大的灵活性。 CCE中设置的环境变量与Dockerfile中的“ENV”效果相同。 容器启动后,容器中的内容不应修改。如果修改配置项(例如将容器应用的密码、证书、环境变量配置到容器中),当容器重启(例如节点异常重新调度Pod)后,会导致配置丢失,业务异常。 配置信息应通过入参等方式导入容器中,以免重启后配置丢失。 环境变量支持如下几种方式设置。 自定义:手动填写环境变量名称及对应的参数值。 配置项导入:将配置项中所有键值都导入为环境变量。 配置项键值导入:将配置项中某个键的值导入作为某个环境变量的值。例如图1中将configmap-example这个配置项中configmap_key的值configmap_value导入为环境变量key1的值,导入后容器中将会存在一个名为key1的环境变量,其值为configmap_value。 密钥导入:将密钥中所有键值都导入为环境变量。 密钥键值导入:将密钥中某个键的值导入作为某个环境变量的值。例如图1中将secret-example这个配置项中secret_key的值secret_value导入为环境变量key2的值,导入后容器中将会存在一个名为key2的环境变量,其值为secret_value。 变量/变量引用:用Pod定义的字段作为环境变量的值。例如图1中将此Pod的名称导入为环境变量key3的值,导入后容器中将会存在一个名为key3的环境变量,其值为该Pod的名称。 资源引用:用容器定义的资源申请值或限制值作为环境变量的值。例如图1中将容器container-1的CPU限制值导入为环境变量key4的值,导入后容器中将会存在一个名为key4的环境变量,其值为容器container-1的CPU限制值。
  • YAML样例 apiVersion: apps/v1 kind: Deployment metadata: name: env-example namespace: default spec: replicas: 1 selector: matchLabels: app: env-example template: metadata: labels: app: env-example spec: containers: - name: container-1 image: nginx:alpine imagePullPolicy: Always resources: requests: cpu: 250m memory: 512Mi limits: cpu: 250m memory: 512Mi env: - name: key # 自定义 value: value - name: key1 # 配置项键值导入 valueFrom: configMapKeyRef: name: configmap-example key: configmap_key - name: key2 # 密钥键值导入 valueFrom: secretKeyRef: name: secret-example key: secret_key - name: key3 # 变量引用,用Pod定义的字段作为环境变量的值 valueFrom: fieldRef: apiVersion: v1 fieldPath: metadata.name - name: key4 # 资源引用,用Container定义的字段作为环境变量的值 valueFrom: resourceFieldRef: containerName: container1 resource: limits.cpu divisor: 1 envFrom: - configMapRef: # 配置项导入 name: configmap-example - secretRef: # 密钥导入 name: secret-example imagePullSecrets: - name: default-secret
  • 环境变量查看 如果configmap-example和secret-example的内容如下。 $ kubectl get configmap configmap-example -oyaml apiVersion: v1 data: configmap_key: configmap_value kind: ConfigMap ... $ kubectl get secret secret-example -oyaml apiVersion: v1 data: secret_key: c2VjcmV0X3ZhbHVl # c2VjcmV0X3ZhbHVl为secret_value的base64编码 kind: Secret ... 则进入Pod中查看的环境变量结果如下。 $ kubectl get pod NAME READY STATUS RESTARTS AGE env-example-695b759569-lx9jp 1/1 Running 0 17m $ kubectl exec env-example-695b759569-lx9jp -- printenv / # env key=value # 自定义环境变量 key1=configmap_value # 配置项键值导入 key2=secret_value # 密钥键值导入 key3=env-example-695b759569-lx9jp # Pod的metadata.name key4=1 # container1这个容器的limits.cpu,单位为Core,向上取整 configmap_key=configmap_value # 配置项导入,原配置项中的键值直接会导入结果 secret_key=secret_value # 密钥导入,原密钥中的键值直接会导入结果
  • 启动后处理 登录MCP控制台,在创建工作负载时,配置容器信息,选择“生命周期”。 在“启动后处理”页签,设置启动后处理的参数。 表3 启动后处理-参数说明 参数 说明 命令行方式 在容器中执行指定的命令,配置为需要执行的命令。命令的格式为Command Args[1] Args[2]…(Command为系统命令或者用户自定义可执行程序,如果未指定路径则在默认路径下寻找可执行程序),如果需要执行多条命令,建议采用将命令写入脚本执行的方式。 如需要执行的命令如下: exec: command: - /install.sh - install_agent 请在执行脚本中填写: /install install_agent。这条命令表示容器创建成功后将执行install.sh。 HTTP请求方式 发起一个HTTP调用请求。配置参数如下: 路径:请求的URL路径,可选项。 端口:请求的端口,必选项。 主机地址:请求的IP地址,可选项,默认为实例IP。
  • 启动命令 在默认情况下,镜像启动时会运行默认命令,如果想运行特定命令或重写镜像默认值,需要进行相应设置。 Docker的镜像拥有存储镜像信息的相关元数据,如果不设置生命周期命令和参数,容器运行时将运行镜像制作时提供的默认的命令和参数,Docker将这两个字段定义为ENTRYPOINT和 CMD。 如果在创建工作负载时填写了容器的运行命令和参数,将会覆盖镜像构建时的默认命令ENTRYPOINT、CMD,规则如下: 表1 容器如何执行命令和参数 镜像 ENTRYPOINT 镜像CMD 容器运行命令 容器运行参数 最终执行 [touch] [/root/test] 未设置 未设置 [touch /root/test] [touch] [/root/test] [mkdir] 未设置 [mkdir] [touch] [/root/test] 未设置 [/opt/test] [touch /opt/test] [touch] [/root/test] [mkdir] [/opt/test] [mkdir /opt/test] 登录MCP控制台,在创建工作负载时,配置容器信息,选择“生命周期”。 在“启动命令”页签,输入运行命令和运行参数。 表2 容器启动命令 命令方式 操作步骤 运行命令 输入可执行的命令,例如“/run/server”。 若运行命令有多个,多个命令之间用空格进行分隔。若命令本身带空格,则需要加引号("")。 说明: 多命令时,运行命令建议用/bin/sh或其他的shell,其他全部命令作为参数来传入。 运行参数 输入控制容器运行命令参数,例如--port=8080。 若参数有多个,可添加运行参数。
  • YAML样例 本节以nginx为例,说明kubectl命令设置容器生命周期的方法。 在以下配置文件中,您可以看到postStart命令在容器目录/bin/bash下写了个install.sh命令。 preStop执行uninstall.sh命令。 apiVersion: apps/v1kind: Deploymentmetadata: name: nginxspec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx command: - sleep 3600 #启动命令 imagePullPolicy: Always lifecycle: postStart: exec: command: - /bin/bash - install.sh #启动后命令 preStop: exec: command: - /bin/bash - uninstall.sh #停止前命令 name: nginx imagePullSecrets: - name: default-secret
  • 停止前处理 登录MCP控制台,在创建工作负载时,配置容器信息,选择“生命周期”。 在“停止前处理”页签,设置停止前处理的命令。 表4 停止前处理 参数 说明 命令行方式 在容器中执行指定的命令,配置为需要执行的命令。命令的格式为Command Args[1] Args[2]…(Command为系统命令或者用户自定义可执行程序,如果未指定路径则在默认路径下寻找可执行程序),如果需要执行多条命令,建议采用将命令写入脚本执行的方式。 如需要执行的命令如下: exec: command: - /uninstall.sh - uninstall_agent 请在执行脚本中填写: /uninstall uninstall_agent。这条命令表示容器结束前将执行uninstall.sh。 HTTP请求方式 发起一个HTTP调用请求。配置参数如下: 路径:请求的URL路径,可选项。 端口:请求的端口,必选项。 主机地址:请求的IP地址,可选项,默认为实例IP。