云服务器内容精选

  • 本地集群 关于本地集群KubeConfig详情请参见本地集群KubeConfig文件。 获取本地集群的KubeConfig需要使用ucs-ctl工具,获取步骤如下: 使用ucs-ctl获取集群名称。 ./ucs-ctl get cluster 使用ucs-ctl导出指定集群的KubeConfig。 ./ucs-ctl get kubeconfig -c test-redhat86 -o kubeconfig 可以使用ucs-ctl get kubeconfig -h查看获取KubeConfig所使用到的参数。 -c, --cluster:指定待导出KubeConfig的集群名。 -e, --eip:指定API server的eip。 -o, --output:指定KubeConfig导出文件名。
  • 自建集群 如果您的集群是通过Kubernetes官方二进制文件或Kubeadm等部署工具搭建的标准集群,可直接使用以下方法获取KubeConfig文件。 该方法不适用于云服务商提供的商用集群,商用集群的KubeConfig文件获取请参考第三方云厂商集群。 登录集群Master节点。 查看集群访问凭证。默认情况下,自建集群的配置文件路径为Master节点的“$HOME/.kube/config”,如您的集群指定了其他KubeConfig配置文件,请自行更换路径。 cat $HOME/.kube/config 复制该凭证内容。 在本地创建一个YAML文件,将上一步中复制的凭证内容粘贴至该文件并保存。 使用4中的YAML文件接入集群,详细步骤请继续参考注册附着集群(公网接入)或注册附着集群(私网接入)。
  • 第三方云厂商集群 由于第三方云厂商集群提供的KubeConfig文件格式存在差异,您需要自行创建一个具有所有集群资源操作权限的ServiceAccount,并获取这个ServiceAccount的token,用于配置U CS 支持的KubeConfig文件。 通过kubectl连接集群。 创建ucs-service-account.yaml文件。 apiVersion: v1 kind: ServiceAccount metadata: name: ucs-user --- apiVersion: v1 kind: Secret metadata: name: ucs-user-token annotations: kubernetes.io/service-account.name: "ucs-user" type: kubernetes.io/service-account-token --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: ucs-user-role rules: - apiGroups: - '*' resources: - '*' verbs: - '*' - nonResourceURLs: - '*' verbs: - get --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: ucs-user-role-binding subjects: - kind: ServiceAccount name: ucs-user namespace: default roleRef: kind: ClusterRole name: ucs-user-role apiGroup: rbac.authorization.k8s.io 在集群中执行以下命令创建ServiceAccount。 kubectl apply -f ucs-service-account.yaml 使用以下命令获取token。 kubectl get secret ucs-user-token -n default -oyaml | grep token: | awk '{print $2}' | base64 -d ;echo 配置KubeConfig文件。 参考以下示例创建一个kubeconfig.yaml文件,并将token替换为4中获取的值。 kubeconfig.yaml: kind: Config apiVersion: v1 preferences: {} clusters: - name: internalCluster cluster: server: 'https://kubernetes.default.svc.cluster.local:443' insecure-skip-tls-verify: true users: - name: ucs-user user: token: 'MIIFbAYJKo*****' contexts: - name: internal context: cluster: internalCluster user: ucs-user current-context: internal KubeConfig文件中的关键参数说明如下: 参数名 参数值 说明 是否可选 server 'https://kubernetes.default.svc.cluster.local:443' APIServer的集群内访问地址。由于部分厂商集群对APIServer地址做了外部访问限制,可能导致UCS无法正常接入集群,因此建议使用集群内访问地址。 必选 insecure-skip-tls-verify true 如使用该参数,表示跳过证书认证,参数值必须为true。 二选一 说明: 当server字段为集群内访问地址时,优选跳过证书认证。 certificate-authority-data base64加密字符串 如使用该参数,表示集群开启双向认证,参数值为经base64加密后的服务端证书。 原生K8s集群的服务端证书默认地址为master节点的“/etc/kubernetes/pki/ca.crt”。 token base64加密字符串 用户以token方式进行认证,参数值为4中获取的token值。 三选一 说明: 优选token方式,UCS不支持除这三种方式外的其他认证方式。 client-certificate-data client-key-data base64加密字符串 用户以证书加私钥的方式进行认证。 client-certificate-data:经base64加密后的客户端证书。 client-key-data:经base64加密后的客户端私钥。 username password 字符串 用户通过用户名密码进行认证。 username:访问集群的用户名。 password:用户名对应的密码。 使用5中配置的KubeConfig文件接入集群,详细步骤请继续参考注册附着集群(公网接入)或注册附着集群(私网接入)。 使用UCS期间,创建的ServiceAccount、ClusterRole、ClusterRoleBinding对象均不能删除,否则token将会失效。 如集群不再接入UCS,可使用kubectl delete -f ucs-service-account.yaml命令删除UCS创建的SA对象。
  • 管理节点标签/污点 登录集群控制台。 在左侧导航栏中单击“节点管理”,在节点列表中选择节点,并单击“标签与污点管理”。 单击按钮,设置节点标签/污点。如需执行多项操作,可多次添加,最多支持10条操作。 图1 添加标签/污点 选择“添加”或“删除”操作。 选择操作对象为“K8S标签”或“污点(Taints)”。 填写需要增加标签/污点的“键”和“值”。 如选择操作对象为“污点(Taints)”,需选择污点效果,关于污点效果说明请参见污点(Taints)说明。 单击“确定”,对所选节点执行标签/污点操作。
  • 节点标签使用场景 节点标签的主要使用场景有两类。 节点分类:通过添加标签对节点进行分类。 工作负载与节点的亲和与反亲和: 有的工作负载需要的CPU大,有的工作负载需要的内存大,有的工作负载需要IO大,可能会影响其他工作负载正常工作,此时建议给节点添加不同标签。在部署工作负载的时候,就可以选择相应标签的节点亲和部署,保证系统正常工作;反之,可以使用节点的反亲和部署。 一个系统可以分为多个模块,每个模块由多个微服务组成,为保证后期运维的高效,可以将节点打上对应模块的标签,让各模块的工作负载部署到各自的节点上,互不干扰、利于维护。
  • 节点固有标签 创建节点后,UCS会为节点添加固有标签,这些标签是无法编辑和删除的。节点固有标签的含义请参见表1。 表1 节点固有标签 键 值 failure-domain.beta.kubernetes.io/region 表示节点当前所在区域 failure-domain.beta.kubernetes.io/zone 表示节点所在区域的可用区 beta.kubernetes.io/arch 表示节点处理器架构 例如:amd64,表示AMD64位的处理器 beta.kubernetes.io/os 表示节点的操作系统 例如:linux,表示Linux操作系统 kubernetes.io/availablezone 表示节点所在区域的可用区 kubernetes.io/hostname 表示节点主机名称 os.architecture 表示节点处理器架构 例如:amd64,表示AMD64位的处理器 os.name 表示节点的操作系统名称 例如:EulerOS_2.0_SP2,表示欧拉2.2的版本 os.version 表示节点内核版本
  • 容忍度(Toleration)说明 容忍度应用于Pod上,允许(但并不要求)Pod调度到带有与之匹配的污点的节点上。 污点和容忍度相互配合,可以用来避免Pod被分配到不合适的节点上。每个节点上都可以拥有一个或多个污点,而对这些污点没有设置容忍度的Pod,将不会被调度到该节点上。 在Pod中设置容忍度的示例如下: apiVersion: v1 kind: Pod metadata: name: nginx labels: env: test spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent tolerations: - key: "key1" operator: "Equal" value: "value1" effect: "NoSchedule" 上面示例中表示节点上存在键名为“key1”,键值为“value1”,且效果为“NoSchedule”的污点时,该Pod能够调度到节点上。 容忍度还可以按如下方式进行设置,表示当节点上存在键名为“key1”,且效果为“NoSchedule”的污点时,该Pod也可以调度到节点上。 tolerations: - key: "key1" operator: "Exists" effect: "NoSchedule"
  • 不同规格的资源配额要求 安装kube-prometheus-stack插件时,需确保集群中有足够的CPU、内存等可调度资源。Agent模式默认规格的资源配额要求请参见表1,Server模式下不同插件规格的资源配额要求请参见表2。 表1 Agent模式默认规格的资源配额要求 插件规格 容器实例 CPU配额 内存配额 默认规格 prometheusOperator 申请:100m 限制:500m 申请:100Mi 限制:500Mi prometheus 申请:500m 限制:4 申请:1Gi 限制:8Gi kube-state-metrics 申请:200m 限制:500m 申请:200Mi 限制:500Mi nodeExporter 申请:200m 限制:500m 申请:200Mi 限制:1Gi grafana 申请:100m 限制:500m 申请:200Mi 限制:2Gi 表2 Server模式不同规格的资源配额要求 插件规格 容器实例 CPU配额 内存配额 演示规格(100容器以内) prometheusOperator 申请:200m 限制:500m 申请:200Mi 限制:500Mi prometheus 申请:500m 限制:2 申请:2Gi 限制:8Gi alertmanager 申请:200m 限制:1 申请:200Mi 限制:1Gi thanosSidecar 申请:100m 限制:1 申请:100Mi 限制:2Gi thanosQuery 申请:500m 限制:2 申请:500Mi 限制:4Gi adapter 申请:400m 限制:2 申请:400Mi 限制:1Gi kube-state-metrics 申请:200m 限制:500m 申请:200Mi 限制:500Mi nodeExporter 申请:200m 限制:500m 申请:200Mi 限制:1Gi grafana 申请:200m 限制:500m 申请:200Mi 限制:2Gi clusterProblemDetector 申请:100m 限制:200m 申请:200Mi 限制:400Mi 小规格(2000容器以内) prometheusOperator 申请:200m 限制:500m 申请:200Mi 限制:500Mi prometheus 申请:4 限制:8 申请:16Gi 限制:32Gi alertmanager 申请:500m 限制:1 申请:500Mi 限制:1Gi thanosSidecar 申请:500m 限制:1 申请:500Mi 限制:2Gi thanosQuery 申请:2 限制:4 申请:2Gi 限制:16Gi adapter 申请:2 限制:4 申请:4Gi 限制:16Gi kube-state-metrics 申请:500m 限制:1 申请:500Mi 限制:1Gi nodeExporter 申请:200m 限制:500m 申请:200Mi 限制:1Gi grafana 申请:200m 限制:500m 申请:200Mi 限制:2Gi clusterProblemDetector 申请:200m 限制:500m 申请:300Mi 限制:1Gi 中规格(5000容器以内) prometheusOperator 申请:500m 限制:1 申请:500Mi 限制:1Gi prometheus 申请:8 限制:16 申请:32Gi 限制:64Gi alertmanager 申请:500m 限制:1 申请:500Mi 限制:2Gi thanosSidecar 申请:1 限制:2 申请:1Gi 限制:4Gi thanosQuery 申请:2 限制:4 申请:2Gi 限制:16Gi adapter 申请:2 限制:4 申请:16Gi 限制:32Gi kube-state-metrics 申请:1 限制:2 申请:1Gi 限制:2Gi nodeExporter 申请:200m 限制:500m 申请:200Mi 限制:1Gi grafana 申请:200m 限制:500m 申请:200Mi 限制:2Gi clusterProblemDetector 申请:200m 限制:1 申请:400Mi 限制:2Gi 大规格(超过5000容器) prometheusOperator 申请:500m 限制:1 申请:500Mi 限制:2Gi prometheus 申请:8 限制:32 申请:64Gi 限制:128Gi alertmanager 申请:1 限制:2 申请:1Gi 限制:4Gi thanosSidecar 申请:2 限制:4 申请:2Gi 限制:8Gi thanosQuery 申请:2 限制:4 申请:2Gi 限制:32Gi adapter 申请:2 限制:4 申请:32Gi 限制:64Gi kube-state-metrics 申请:1 限制:3 申请:1Gi 限制:3Gi nodeExporter 申请:200m 限制:500m 申请:200Mi 限制:1Gi grafana 申请:200m 限制:500m 申请:200Mi 限制:2Gi clusterProblemDetector 申请:200m 限制:1 申请:400Mi 限制:2Gi
  • 插件简介 kube-prometheus-stack通过使用Prometheus Operator和Prometheus,提供简单易用的端到端Kubernetes集群监控能力,同时还具备自定义插件规格、对接Grafana、高可用、节点亲和等能力。 kube-prometheus-stack插件的核心组件包括prometheusOperator、prometheus、alertmanager、thanosSidecar、thanosQuery、adapter、kubeStateMetrics、nodeExporter、grafana。 prometheusOperator:根据自定义资源(Custom Resource Definition / CRDs)来部署和管理Prometheus Server,同时监控这些自定义资源事件的变化来做相应的处理,是整个系统的控制中心。 prometheus(Server):Operator根据自定义资源Prometheus类型中定义的内容而部署Prometheus Server集群,这些自定义资源可以看作是用来管理Prometheus Server集群的StatefulSets资源。 alertmanager:插件的告警中心,主要用于接收Prometheus发送的告警并通过去重、分组、分发等能力管理告警信息。 thanosSidecar:高可用场景和Prometheus运行在同一个Pod中,用于实现普罗指标数据的持久化存储。 thanosQuery:普罗高可用时PromQL查询的入口,能够对来自Store或Prometheus的相同指标进行重复数据删除。 adapter(custom-metrics-apiserver):将自定义指标聚合到原生的Kubernetes API Server。 kube-state-metrics:将Prometheus的metrics数据格式转换成Kubernetes API接口能识别的格式。kube-state-metrics组件在默认配置下,不采集Kubernetes资源的所有labels和annotation。如需采集,请参考如何修改kube-state-metrics组件的采集配置?章节进行配置。 nodeExporter:每个节点上均有部署,收集Node级别的监控数据。 grafana:可视化浏览普罗监控数据。Grafana会默认创建大小为5 GiB的存储卷,卸载插件时Grafana的存储卷不随插件被删除。 clusterProblemDetector:用于监控集群异常。
  • 背景 Podinfo是一个微模型的Web应用程序,它展示了在Kubernetes中运行微服务的最佳实践,其主要用作于测试和研讨。本章将用podinfo源代码来做创建配置集合的示例。 为了可以更快的、更稳定的持续地交付软件、减少后续维护工作,所以将podinfo的源代码放入GitHub仓库,并通过创建配置集合的方式部署到集群中,通过GitOps能力实现软件自动化部署,具体请参考操作步骤。 创建podinfo源代码仓时,请先注册一个属于自己的GitHub账号,然后将podinfo所有代码fork到自己的GitHub仓库中。 在git仓库中定义交付资源清单文件时,不应包含敏感信息(如数据库连接密钥等)。相关敏感信息应以环境变量、加密存储的Secret等方式进行存储。 图1 Podinfo界面
  • 操作步骤 登录华为云控制台。 在左侧导航栏中选择“分布式云原生”,选择“配置管理”。 在右上角“添加集群”,选择需要启用配置管理功能的目标集群,单击确定。 在集群概览页,选择目标集群,单击“Gitops能力”,查看Gitops插件(名称:集群名称-FluxPlugin)是否安装成功。当插件部署状态显示运行中,表示插件已部署成功。 图2 集群概览页 选择“配置集合”页签,单击创建配置集合。 选择仓库源,如果已有仓库源请参考使用已有仓库源配置,如果需要创建新仓库源,请参考创建新仓库源。
  • 创建新仓库源 单击“创建新仓库源”输入仓库源名称、仓库源URL地址。 输入需要与其同步的代码库分支。 选择数据源验证,以及输入密钥。 选择公有类型的仓库无需进行身份验证,即可提供只读权限。 选择私有类型的仓库,则数据源验证可选择“选择集群secret”和“提供认证信息(SSH)”,两种方式都需要配置的密钥进行身份验证。 仓库密钥创建请参考密钥。 仓库源创建完成后,在“自动同步策略”内输入“配置集合路径”,单击“下一步:信息确认”。 确认配置信息无误后,单击“创建配置集合”;如有问题,单击上一步进行修改。
  • 通过命令行配置升级示例 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。
  • 通过命令行回退工作负载版本 例如上面升级的新版镜像有问题,可以执行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。
  • 通过控制台配置工作负载升级 在创建工作负载时,单击“展开高级配置”。 参考表1,设置升级策略。 表1 参数说明 参数 描述 升级方式 设置不同的升级策略,有如下两种。 RollingUpdate:滚动升级,即逐步创建新Pod再删除旧Pod,为默认策略。 Recreate:替换升级,即先把当前Pod删掉再重新创建Pod。 最大无效实例数(maxUnavailable) 与spec.replicas相比,可以有多少个Pod失效,也就是删除的比例,默认值是25%,比如spec.replicas为4,那升级过程中就至少有3个Pod存在,即删除Pod的步伐是1。同样这个值也可以设置成数字。 仅Deployment支持配置。 最大浪涌(maxSurge) 与spec.replicas相比,可以有多少个Pod存在,默认值是25%,比如spec.replicas为 4,那升级过程中就不能超过5个Pod存在,即按1个的步伐升级,实际升级过程中会换算成数字,且换算会向上取整。这个值也可以直接设置成数字。 仅Deployment支持配置。 实例可用最短时间(minReadySeconds) 指定新创建的 Pod 在没有任意容器崩溃情况下的最小就绪时间, 只有超出这个时间 Pod 才被视为可用。默认值为 0(Pod 在准备就绪后立即将被视为可用)。 最大保留版本数(revisionHistoryLimit) 用来设定出于回滚目的所要保留的旧 ReplicaSet 数量。 这些旧 ReplicaSet 会消耗 etcd 中的资源,并占用 kubectl get rs 的输出。 每个 Deployment 修订版本的配置都存储在其 ReplicaSets 中;因此,一旦删除了旧的 ReplicaSet, 将失去回滚到 Deployment 的对应修订版本的能力。 默认情况下,系统保留 10 个旧 ReplicaSet,但其理想值取决于新 Deployment 的频率和稳定性。 升级最大时长(progressDeadlineSeconds) 指定系统在报告 Deployment 进展失败 之前等待 Deployment 取得进展的秒数。 这类报告会在资源状态中体现为 Type=Progressing、Status=False、 Reason=ProgressDeadlineExceeded。Deployment 控制器将持续重试 Deployment。 将来,一旦实现了自动回滚,Deployment 控制器将在探测到这样的条件时立即回滚 Deployment。 如果指定,则此字段值需要大于 .spec.minReadySeconds 取值。 缩容时间窗(terminationGracePeriodSeconds) 优雅删除时间,默认为30秒,删除Pod时发送SIGTERM终止信号,然后等待容器中的应用程序终止执行,如果在terminationGracePeriodSeconds时间内未能终止,则发送SIGKILL的系统信号强行终止。 图1 升级策略