云服务器内容精选
-
本地集群 关于本地集群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 升级策略
更多精彩内容
CDN加速
GaussDB
文字转换成语音
免费的服务器
如何创建网站
域名网站购买
私有云桌面
云主机哪个好
域名怎么备案
手机云电脑
SSL证书申请
云点播服务器
免费OCR是什么
电脑云桌面
域名备案怎么弄
语音转文字
文字图片识别
云桌面是什么
网址安全检测
网站建设搭建
国外CDN加速
SSL免费证书申请
短信批量发送
图片OCR识别
云数据库MySQL
个人域名购买
录音转文字
扫描图片识别文字
OCR图片识别
行驶证识别
虚拟电话号码
电话呼叫中心软件
怎么制作一个网站
Email注册网站
华为VNC
图像文字识别
企业网站制作
个人网站搭建
华为云计算
免费租用云托管
云桌面云服务器
ocr文字识别免费版
HTTPS证书申请
图片文字识别转换
国外域名注册商
使用免费虚拟主机
云电脑主机多少钱
鲲鹏云手机
短信验证码平台
OCR图片文字识别
SSL证书是什么
申请企业邮箱步骤
免费的企业用邮箱
云免流搭建教程
域名价格