容器服务

<article class=“article fmt article-content”><h2>前言</h2><p>在后面的文章《弹性调度助力企业灵便应答业务变动，高效治理云上资源》中，咱们介绍了阿里云容器服务 ACK 弹性调度为了帮忙客户解决在应用云上弹性资源时，面对的“难以差异化管制业务资源使用量，缩容时局部业务 Pod 未开释”等挑战，提供了依照多级资源的优先程序进行调度，以及依照定义的优先程序进行缩容的能力。</p><p>本文将介绍弹性调度如何应用虚构节点来满足您的业务弹性需要。</p><p>企业在施行利用弹性过程中，弹性速度和弹性地位是重点关注的两个外围指标。</p><p>对于谋求高可用以及稳定性的企业来说，麻利的弹性可能在业务流量突增时，保证系统的连续性与稳定性。同时，通过跨多地区部署利用，能够在地域性故障产生时，无效地维持服务的继续可用性。</p><p>对于大数据处理工作的企业来说，疾速的弹性可能缩短工作执行工夫，放慢利用的迭代速度。同时，集中部署在单个地区，则能够缩小利用之间的网络通信时延，从而进一步晋升数据处理效率。</p><p>显然，这两个指标对于确保企业业务的稳固高效运行至关重要。</p><p>然而，许多企业在面对疾速到来的业务流量顶峰和日益增长的大数据算力需要时，现行的分钟级主动伸缩节点池的弹性响应曾经无奈满足需要。并且，通过正当的部署策略，实现预期的弹性地位，也颇具挑战。</p><p>为此，阿里云推出弹性容器实例（Elastic Container Instance，ECI），以十秒级的弹性速度，有效应对突发流量的弹性需要。同时，阿里云容器服务 Kubernetes 版（ACK）利用虚构节点技术实现与 ECI 弹性资源的无缝集成，使得业务可能在集群内灵便动静地调用 ECI 资源，迅速应答弹性挑战。此外，容器服务 ACK 的弹性调度性能在将业务调度到 ECI 上时，还能维持业务的亲和性配置不变，确保利用运行的稳固和高效。</p><h2>应用虚构节点实现秒级弹性</h2><p>为了在 ACK 中应用 ECI，须要在 ACK 集群中装置虚构节点组件。</p><blockquote><p>在 ACK Pro 版集群中，能够通过组件治理页面部署 ack-virtual-node 组件，该组件默认被托管，不占用 Worker 节点资源。</p><p>在 ACK 专有版集群中，能够通过利用市场页面部署 ack-virtual-node 组件，装置胜利后会在 kube-system 命名空间下创立一个名为 ack-virtual-node-controller 的 deployment，该 deployment 会运行在您的 Worker 节点上。</p></blockquote><p>装置胜利后用户能够通过 kubectl get no 命令在集群中查看到若干虚构节点，代表虚构节点装置胜利。</p><p>虚构节点装置胜利之后，能够应用弹性调度性能配置 ECI 的应用策略，以下是“优先调度 ECS，当 ECS 资源应用完后应用 ECI 资源”的示例。</p><pre><code>apiVersion: scheduling.alibabacloud.com/v1alpha1kind: ResourcePolicymetadata: name: testspec: strategy: prefer units: - resource: ecs - resource: eci</code></pre><p>配置了以上 ResourcePolicy 之后，在 default 命名空间下的所有 Pod 都将遵循以下的调度规定：优先应用 ECS，ECS 资源用完后应用 ECI。</p><p>须要留神的是：以上配置会使得 ECS 节点上的抢占性能生效，如果须要同时放弃在 ECS 上的抢占能力，请配置 preemptPolicy=BeforeNextUnit，如果须要限定失效的业务范围，请按需配置 selector。</p><p>以下是理论应用成果：</p><p>首先，提交一个 Deployment，8 个业务 Pod 中仅有 7 个业务 Pod 可能被胜利调度。</p><p></p><p>此时，提交 ResourcePolicy，并将 Deployment 的正本数减少到 10，新的正本将全副运行在 ECI 上。</p><p></p><p>通过统计业务 Pod 的创立工夫以及 startTime，能够看到这里新 Pod 的创立工夫在 13 秒，远远低于主动伸缩节点所需的弹性工夫。</p><p></p><h2>升高大数据工作通信时延</h2><p>若您的集群配置了多个可用区的虚构节点，在默认状况下，ECI Pod 可能会被调度在多个可用区上。如下图，在默认状况下，nginx 被调度到了 C 和 D 两个可用区的 virtual node 上。</p><p></p><p></p><p>对于大数据型利用，配置可用区亲和往往意味着计算 Pod 之间的网络通信代价更小，进而带来更高的吞吐量。通过阿里云弹性调度，您能够通过 Pod 上的节点亲和以及 Pod 亲和限度业务调度的可用区，从而实现 ECS 上的 Pod 与 ECI 上的 Pod 调度在雷同的可用区上。</p><p>以下是两种在 ECI 上配置雷同可用区调度的示例，别离应用了指定可用区调度以及不指定可用区调度两种形式，在以下的两个例子中，已提前提交了 ResourcePolicy：</p><h3>手动指定可用区</h3><p>原生 Kubernetes 提供了节点亲和调度语义来管制 Pod 的调度地位，以下的例子中咱们指定 nginx 服务仅在可用区 C 上进行调度。您惟一须要进行的批改是在工作负载的 PodTemplate 或 PodSpec 中增加节点亲和束缚。</p><pre><code>apiVersion: apps/v1kind: Deploymentmetadata: labels: app: nginx name: nginx-deployment-basicspec: replicas: 9 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: topology.kubernetes.io/zone operator: In values: - cn-hongkong-c containers: - image: ’nginx:1.7.9’ imagePullPolicy: IfNotPresent name: nginx resources: limits: cpu: 1500m requests: cpu: 1500m terminationMessagePath: /dev/termination-log terminationMessagePolicy: File</code></pre><p>同样将业务 Pod 扩容到 9，此时可能察看到业务 Pod 全副运行在可用区 C 上，因为集群中 ECS 节点均为可用区 D 上的机器，因而所有业务 Pod 全副运行在 ECI 上。</p><p></p><h3>最优可用区感知调度</h3><p>为应答大数据计算需要，通常须要部署大量的 Pod，这时候确保 ECI 提供短缺的算力资源成为要害。为确保抉择到具备短缺残余算力的可用区，能够在指定可用区亲和时应用 Pod 亲和。在 ECI 调度过程中，调度器会参考 ECI 提供的可用区倡议，抉择一个可用算力更多的可用区，从而实现主动抉择更优地位的成果。以下例子中咱们将限度 Pod 仅在 ECI 上调度，并通过 Pod 亲和限度 Pod 必须被调度到同一个可用区。</p><p>注：Pod 亲和会使得后续 Pod 与第一个被调度的 Pod 亲和在雷同可用区，当采纳 ECS+ECI 弹性调度时，因为第一个被调度的 Pod 通常为 ECS Pod，会使得后续 ECI Pod 亲和在 ECS 雷同的可用区，此时建议您应用 preferredDuringSchedulingIgnoredDuringExecution。</p><p>提交的 ResourcePolicy 为：</p><pre><code>apiVersion: scheduling.alibabacloud.com/v1alpha1kind: ResourcePolicymetadata: name: testspec: strategy: prefer units: - resource: eci</code></pre><p>提交的工作负载为：</p><pre><code>apiVersion: apps/v1kind: Deploymentmetadata: labels: app: nginx name: nginx-deployment-basicspec: replicas: 9 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - nginx topologyKey: topology.kubernetes.io/zone containers: - image: ’nginx:1.7.9’ imagePullPolicy: IfNotPresent name: nginx resources: limits: cpu: 1500m requests: cpu: 1500m terminationMessagePath: /dev/termination-log terminationMessagePolicy: File</code></pre><p>提交后可用发现，此时 Pod 仍然均调度在雷同的可用区，此时调度到的可用区将会是 ECI 举荐的更优可用区。</p><p></p><h2>保障在线业务高可用</h2><p>对于在线业务而言，配置业务多可用区部署是保障业务高可用的一种无效伎俩。通过阿里云弹性调度，您能够通过 Pod 上的拓扑散布束缚来实现 ECS 上的 Pod 与 ECI 上的 Pod 遵循雷同的拓扑散布束缚，从而实现业务的高可用。</p><p>以下是一个在 ECI 上配置业务高可用的示例，指定了业务 Pod 在多个可用区上均匀分布，并且在 ECS 资源有余时应用 ECI。</p><pre><code>apiVersion: scheduling.alibabacloud.com/v1alpha1kind: ResourcePolicymetadata: name: testspec: strategy: prefer units: - resource: ecs - resource: eci—apiVersion: apps/v1kind: Deploymentmetadata: labels: app: nginx name: nginx-deployment-basicspec: replicas: 9 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: topologySpreadConstraints: - labelSelector: matchLabels: app: nginx maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule containers: - image: ’nginx:1.7.9’ imagePullPolicy: IfNotPresent name: nginx resources: limits: cpu: 1500m requests: cpu: 1500m terminationMessagePath: /dev/termination-log terminationMessagePolicy: File</code></pre><p>提交上述资源清单后，Pod 最终的可用区和节点散布如下，因为可用区 D 上存在三个 ECS 节点，因而最终 Pod 在可用区 D 上存在 5 个 Pod，在可用区 C 上存在 4 个 Pod。可能满足束缚中最大倾斜度为 1 的要求。</p><p></p><h2>What’s Next</h2><p>阿里云容器服务 Kubernetes 版（ACK）在规范 K8s 调度框架的根底上扩大了弹性调度性能，致力于进步利用性能和集群整体资源的利用率，保障企业业务的稳固高效运行。</p><p>在后期文章《弹性调度助力企业灵便应答业务变动，高效治理云上资源》中，咱们曾经探讨了如何通过阿里云容器服务 ACK 的弹性调度无效治理各类弹性资源，以帮忙企业优化资源配置，实现降本增效。</p><p>在本文中，咱们又深刻解析了 ACK 弹性调度如何与弹性容器实例（ECI）这一要害弹性资源联合，凭借 ECI 疾速弹性、秒级计费和即时开释的劣势，显著晋升企业业务的稳定性和效率。</p><p>在行将推出的调度系列文章中，咱们将具体介绍如何在 ACK 上治理和调度 AI 工作，助力企业 AI 业务在云端疾速落地。</p><p>作者：吴昆</p><p><strong>原文链接</strong></p><p><strong>本文为阿里云原创内容，未经容许不得转载。</strong></p></article> ...

明天，容器和 K8s 曾经成为利用研发运维的新规范，行业调研数据显示，2022 年有 64% 的最终用户在生产环境中应用了 K8s；2022 年托管在云上的 K8s 集群增速达到了 127%。咱们也看到云托管的 K8s 将在 2023 年超过本地部署。这意味着容器化上云成为了新常态。 同时，随着互联网分布式技术的遍及，微服务架构被宽泛应用，围绕着一整套的技术体系，运维复杂度陡然回升。在这两个趋势之下，咱们看到企业和开发者面临新的挑战：比方 K8s 的入门门槛高、保护比较复杂，而微服务的运维体系很简单，企业的业务流量稳定很大，须要更好的按需弹性、同时实现更低成本；云产品组合抉择比拟多，对于企业来讲须要更好的性价比。 为了解决企业在当下背景下面临的挑战，阿里云带来一款全新的产品：容器计算服务 ACS，将容器和资源一体化，打造全新的用云范式。 ACS 简化了产品的实例类型，它只有 3 种实例：通用型、工作型、独享型。以一个典型的互联网网站服务为例，一个典型企业的利用工作负载，个别包含 Web 应用程序、CICD 流水线、大数据计算、数据库中间件等。对于这样经典的场景，咱们举荐在 Web 应用程序里应用通用型实例，CI/CD 流水线应用通用型实例，大数据计算框架应用工作型实例，数据库、缓存就应用独享型实例。通过这样的实例组合，可能实现企业最大化的资源利用和老本升高。 目前，容器计算服务 ACS 已开启体验。咱们也期待有更多的用户通过 ACS，可能去享受容器化用云的红利。点击浏览原文，即可体验容器计算服务 ACS。 体验链接：https://www.aliyun.com/product/acs咱们特地邀请阿里云云原生利用平台负责人丁宇，针对 ACS 相干话题，期待通过他的答复给予企业和开发者更多的思考。 问题 1：阿里云目前有四十余款外围 Serverless 产品的公布，这背地反映出了云上开发需要的微小转变。您如何对待这一变动？丁宇：呈现这一变动的起因与越来越多的客户开始上云无关。千行百业的客户都在上云，并且他们寻求的是更高效、便捷、经济及易用的服务。这标记着客户进入到了一个用好云的阶段，他们对云产品提出了更高的要求，冀望免运维、全托管、按需弹性、按量付费。因而，云平台也在降级云产品，朝着 Serverless 方向投入产品建设，以满足客户增长对于云的多快好省的需要。 云具备资源池化、弹性能力、存储计算拆散、分布式存储和网络等技术劣势，正是这些技术的底座和根底，让咱们可能更迅速地推动 Serverless 化产品建设。 问题 2：那您如何对待以后企业应用云的现状？ACS 又是如何解决这些问题的？丁宇：据调研报告显示，2022 年，64% 的最终用户在生产环境中应用了 K8s，并且托管在云上的 K8s 集群年增速达到 127%，所以说上云用容器曾经成为一个微小的趋势。预计到 2023 年，云托管的 K8s 将超过本地部署，这意味着容器化用云将成为一个新常态。 此外，随着越来越多的利用架构微服务化，服务治理的复杂度在一直回升，当微服务遇到 K8s，带来了更多的复杂度。例如，K8s 配置简单，计算资源机型多、代际多，集群和节点组件治理简单，业务顶峰实现按需弹性难度大等。 因而，为了升高 K8s 应用和运维复杂度，解决资源和容器割裂的问题，咱们设计了容器计算服务 ACS。它能大幅简化云的应用界面，让云的应用界面上移，实现容器、资源一体化。同时 K8s 集群不须要保护，节点不须要运维，ACS 的性能与资源类型也极为简洁，能够让咱们实现灵便的资源调配，反对多种利用场景。 ...

牧云·云原生平安平台 是长亭牧云团队以开源社区为生态载体，技术积攒为驱动所打造的云原生平安平台。援用本文将介绍如何应用牧云·云原生平安平台进行CI/CD扫描。介绍：在我的项目开发过程中，咱们频繁在生产环境应用镜像实现根底构建，但在镜像创立、构建、传输的过程中，咱们该如何保障镜像的安全性与完整性？ 牧云·云原生平安平台提供 CI/CD 性能，目前兼容多种支流 CI/CD，一键生成检测策略，并查看具体检测后果，直观高效，精准定位！ 反对自定义策略参数配置：检测范畴、检测内容、事件阻断等级反对可视化查问后果：是否通过检测、危险事件统计反对查看每条 Pipline 检测详情：关联每条构建编号与检测后果数据、梳理以后所有被影响镜像信息、检测后果详情查看跳转应用指引：1、点击「平安左移-CI/CD」返回应用CI/CD性能，点击Jenkins卡片进入Jenkins详情页面。首次进入页面的用户会间接看到配置Token的弹窗，用户能够根据流程进行前置插件装置配置，敞开弹窗后，能够再次点击页面右上方「配置Token 」进行查看。 点击下载插件包返回Jenkins面板>系统管理>插件治理>高级>DeployPlugin抉择插件文件,点击Deploy按钮实现插件装置。返回Jenkins面版>系统管理>系统配置找到VeinmindScannerOptions,粘贴平台获取的Token,点击保留按钮实现初始化配置。2、装置插件后，默认启动插件的主动模式，应用默认策略对应用插件的CI/CD进行平安检测扫描并上报后果到平台，默认策略不会进行镜像阻断操作，用户可在系统配置中批改策略id批改默认策略内容。如针对不同的Pipline有不同的检测需要，即可应用手动模式，创立策略进行检测。点击「创立策略」弹窗策略参数配置，根据业务状况配置参数详情。3、Jenkins列表页面分为三个模块，左侧是策略管理，右侧是Pipline事件列表，上方是操作按钮。点击右上方「创立策略」能够基于业务场景创立不同的策略进行应用；左侧点击某一个策略对象，右侧将会展现应用此策略进行扫描上报的所有事件数据，点击编辑即可返回查看策略详情并编辑具体字段。4、点击「Job」进入Pipline事件详情页面，Piplinel事件详情包含四个模块「CI/CD信息」「扫描镜像信息」「策略详情」「检测详情」，提供CI/CD具体字段、本次扫描的镜像对象、本次扫描应用的策略内容和扫描的后果，多类型数据对立展现，便于疾速排查危险并进行下一步解决修复。 Jenkins的配置：所需环境JenkinsJenkins 部署服务器与牧云·云原生平安平台网络畅通插件装置1、返回平台 /镜像平安/CI/CD，抉择 Jenkins 卡片，点击「配置 Token」按钮，点击下载插件包。 2、返回 Jenkins 面板 > 系统管理 > 插件治理 > 高级 > Deploy Plugin 抉择插件文件, 点击 Deploy 按钮实现插件装置。3、返回 Jenkins 面板> 系统管理 > 系统配置 找到 Veinmind Scanner Options, 粘贴平台获取的 Token, 点击 保留 按钮实现初始化配置。 这里是插件的全局配置参数，对所有应用插件的 CICD 都失效，您只需根据上图内容粘贴 Token 即可，其余参数可放弃默认选项image ：默认为空策略 id：默认抉择平台内置的默认策略，如需更换全局策略需返回平台创立策略后复制策略 id 填写到此处serverURl：默认即可CaURl：默认即可日志级别：默认即可主动模式：装置插件后，默认启动插件的主动模式，应用默认策略对所有应用插件的 CICD 进行平安检测扫描并上报后果到平台，默认策略不会进行镜像阻断操作，您可在系统配置中批改策略 id 批改默认策略内容。 手动模式：如针对不同的 Pipline 有不同的检测需要，即可应用手动模式，具体教程请参考下方内容。 创立策略1、返回平台，点击「创立策略」按钮，根据业务状况配置策略参数。2、复制命令，返回 Jenkins 面板 > 进入指标 Pipline 详情 > 左侧点击配置 > 定位到流水线 > 粘贴命令 > 点击保留 ...

公司介绍丽迅物流是百丽旗下专一于时尚产业、为企业提供业余物流及供应链解决方案的服务商。其产品服务次要包含城市落地配、仓配一体、支线运输及定制化解决方案。通过自研智能化物流治理平台，全面助力企业单干集约化倒退。目前，丽迅物流已在全国领有 70+ 全渠道实体云仓、6 大核心电商仓，总面积达 100 万+ 平方米，服务笼罩 300+ 城市、3000+ 商圈，为多家出名时尚品牌及其品牌门店提供全渠道配送服务。 为了升高业务各环节中的运维老本、进步物流服务效率，2021 年 8 月起，丽迅物流开始在阿里云上实现本身从 IDC 自建到全面云原生化的过程。其中应用了阿里云容器镜像仓库企业版 ACR EE 和阿里云容器服务 ACK 作为容器制品治理及调度平台，应用了阿里云服务网格 ASM 作为云原生应用服务的分布式治理平台，通过服务网格的服务治理和流量管制性能，实现了应用程序的高效部署和扩大。 通过本文，丽迅物流架构师刘强分享了对于基于阿里云服务网格 ASM 如何减速企业业务云原生化过程的实践经验。 业务痛点在技术架构转型及业务疾速倒退的背景下，丽迅物流须要和各供应链撑持平台、研发平台等多个业务单元和合作伙伴进行业务交互，其业务零碎多元化并且具备开放性。在市场环境和消费者需要疾速变动的现状下，咱们更心愿将精力专一于外围业务的研发。包含了以下须要解决的业务问题痛点： 利用版本迭代艰难面对疾速变动的客户、业务要求，所依赖的利用性能越来越多。业务越简单，代码的耦合度也越来越高，新个性上线周期逐渐拉长，使得利用版本迭代愈发艰难。 异构零碎无奈对立治理企业级 IT 零碎多语言、多协定、多框架的现状，为对立进行服务整合、服务治理设下困局。同时，因为 IT 零碎部署基础设施简单，反对跨平台、跨多个 Kubernetes 集群的技术难点亟需解决。 构建对立的云原生应用服务研发平台存在肯定艰难以 Spring Cloud 为代表的开源微服务框架成为业界支流的微服务脚手架。这些框架已具备服务注册发现、健康检查等根底微服务能力，但面对企业级利用所波及的服务拜访安全控制、服务流控、路由管制、灰度公布等高阶服务治理问题，仍须利用自行整合大量的第三方开源框架。这使得云原生应用服务业务利用设计开发具备较高的技术门槛，对于企业构建对立的云原生应用服务研发平台带来肯定艰难。 简单的运维体系现有的运维体系存在肯定的复杂性，相比于服务网格提供围绕流量治理、安全性、可观测性的一系列性能，目前对于大规模治理应用服务的运维体系存在挑战。 解决方案作为业内首个全托管 Istio 兼容的服务网格产品 ASM，一开始从架构上就放弃了业界当先性以及社区与业界倒退的一致性，管制立体的组件托管在阿里云侧，与数据面侧的用户集群独立，放弃高可用部署与稳定性。ASM 产品是基于社区开源的 Istio 定制实现的，在托管的管制面侧提供了用于撑持精细化的流量治理和平安治理的组件能力。通过托管模式，解耦了 Istio 组件与所治理的 K8s 集群的生命周期治理，使得架构更加灵便，晋升了零碎的可伸缩性。 $$阿里云服务网格 ASM 架构图$$ 托管式服务网格 ASM 在成为多种类型计算服务对立治理的基础设施中，提供了对立的流量治理能力、对立的服务平安能力、对立的服务可观测性能力、以及基于 WebAssembly 实现对立的代理可扩大能力，以此构筑企业级能力。 除大数据的剖析体系外，丽迅物流的以后零碎曾经全面接入服务网格体系，包含应用以下能力： $$丽迅科技业务利用部署架构图$$ 认证鉴权体系客户端发动业务申请，后端须要验证用户申请的合法性。例如，判断用户申请是否有该资源拜访权限。认证通过后，返回后果中还须要减少一些原始申请中没有的信息，例如用户认证通过后在 header 中增加业务版本号、用户 ID 等。 针对上述业务场景，ASM 提供了自定义受权服务。在 ASM 网关上退出鉴权流程，以确保只有失去受权的状况下，能力拜访要害服务。 ...

牧云·云原生平安平台 是长亭牧云团队以开源社区为生态载体技术积攒为驱动所打造的云原生平安平台。本文将介绍如何应用牧云·云原生平安平台进行镜像敏感信息的扫描。应用前的筹备工作：1、在进行镜像敏感信息的扫描之前，咱们同样须要先辨别扫描对象是什么？思维导图如下：镜像平安扫描对象分为本地镜像和仓库镜像。本地镜像分为集群环境和非集群环境，集群环境在进行资产盘点前还须要先集成集群装探针，非集群环境间接装置探针即可。仓库镜像须要先装置旁路探针再集成仓库资源。具体步骤请参考： 牧云·云原生平安平台使用手册：集群资产盘点牧云·云原生平安平台使用手册：镜像/容器/Web资产盘点 牧云·云原生平安平台使用手册：应用软件资产盘点 2、在装置好旁路探针以及集成好仓库资源之后就须要咱们创立工作打算了： 创立工作打算工作打算工作打算性能次要用于向扫描探针下发平安扫描工作，创立具体任务打算后，平台将具体任务下发到对应的扫描探针，扫描探针执行扫描工作并向平台上报安全事件，平台获取后果并展现。 点击 /管理中心/工作打算 进入工作打算页面，点击右上角按钮 「创立工作打算」。本文只介绍本地镜像、仓库镜像、集群镜像的工作打算创立，其余的工作类型之后文章会有具体介绍。 本地镜像如果是本地镜像，创立工作打算时须要填写工作打算参数，抉择好主机扫描范畴、镜像范畴、指定插件和执行周期即创立实现。 仓库镜像如果是仓库镜像，创立工作打算时须要填写对应的工作打算参数，抉择好仓库扫描范畴、镜像范畴、指定插件和执行周期即创立实现。 集群镜像如果是集群镜像，创立工作打算时须要填写对应的工作打算参数，抉择好集群扫描范畴、镜像范畴、指定插件和执行周期即创立实现。 其中工作打算参数须要留神的是： 镜像范畴上传范畴文件 文件内容需保障每行仅蕴含一条镜像数据倡议每条镜像数据不蕴含tag，并以换行符完结可参考下图示例： 操作工作状态 期待执行：工作尚未下发到工作队列中，正在期待下一次执行工夫队列中： 工作已下发，正在工作队列中等在执行正在执行：工作正在执行中执行胜利：即代表此工作打算已全副执行胜利执行失败：即代表此工作打算执行失败生效：当探针范畴抉择的探针从平台删除或仓库范畴抉择的仓库从平台删除 至此咱们曾经实现了后期的筹备工作了，接下来就能够进行敏感信息性能的应用了。 敏感信息介绍：牧云·云原生平安平台依靠问脉开源工具敏感信息检测库，提供上百条敏感信息检测规定，可能对镜像中的敏感信息进行多维度的平安检测并提供修复计划，防止引发重大的平安危险。    应用指引：1、点击 /镜像平安/敏感信息 进入敏感信息事件列表页面，此列表展现扫描打算进行平安扫描后发现的所有安全事件后果详情。您能够通过左上角切换镜像视角、事件视角进行查看筛选与统计。 2、单击事件名称可进入事件详情页面，提供事件信息、文件信息、镜像信息、检测详情模块进行查看。3、列表右侧提供事件处理和全副导出操作，您能够对事件标记“有危险”“确认中”“已解决”“误报”“疏忽”状态。 对于咱们牧云·云原生平安平台 是长亭牧云团队以开源社区为生态载体技术积攒为驱动所打造的云原生平安平台。独创双模探针架构，可选用 Agentless/Agent 多种计划进行部署，笼罩制品、运行时、集群全流程平安，开箱即用、疾速施行、老本极低、主动降级、无需保护、无缝集成，让用户可能轻装上阵，轻松解决云原生平安问题。 平台地址： https://rivers.chaitin.cn/?share=60889b1731a311ee89640242c0a8...

家喻户晓，podman 是一个开源的无守护过程工具，它提供了构建、运行和治理容器的环境。将容器作为 systemd service 运行意味着当零碎重新启动时，容器将主动启动。 在这篇文章中，咱们将学习如何在基于 RHEL 的发行版 (如 RHEL 8、CentOS 8 和 Rocky Linux 8) 上应用 podman 将容器作为零碎服务运行。 前提条件Minimal RHEL based OS Installation.Stable Internet ConnectionSudo User with root privileges(1) 装置 Podman要在 RHEL 8 上装置 podman，请运行 $ sudo dnf install @container-tools -y要在 CentOS 8 / Rocky Linux 8 上装置 podman，请运行 $ sudo dnf install -y podman要查看 podman 是否装置胜利，请尝试应用 podman 上面的命令运行 hello-world 容器。 $ podman -vpodman version 3.3.1$$ podman run 'hello-world'留神:当咱们第一次运行 podman 时，它会提醒咱们抉择想要下载容器映像的托管仓库。 ...

导语 | 本文推选自腾讯云开发者社区-【技思广益 · 腾讯技术人原创集】专栏。该专栏是腾讯云开发者社区为腾讯技术人与宽泛开发者打造的分享交换窗口。栏目邀约腾讯技术人分享原创的技术积淀，与宽泛开发者互启迪共成长。本文作者是腾讯云原生架构师imroc。 本文次要介绍在腾讯云容器服务上如何装置KubeSphere及其踩坑与注意事项，心愿能够给对此方面感兴趣的开发者们一些教训和帮忙。 装置步骤具体装置步骤参考KubeSphere官网文档：在腾讯云TKE装置 KubeSphere。链接：https://kubesphere.io/zh/docs... 踩坑与注意事项 （一）cbs磁盘容量以10Gi为倍数 腾讯云容器服务默认应用CBS云硬盘作为存储，容量只反对10Gi的倍数，如果定义pvc时指定的容量不是10Gi的倍数，就会挂盘失败。装置KubeSphere时，批改下ClusterConfiguration中各个组件的volumeSize配置，确保是10Gi的倍数。 （二）卸载卡住与卸载不洁净导致重装失败 有时装置出问题，心愿卸载重装，应用KubeSphere官网文档从 Kubernetes上卸载KubeSphere中的kubesphere-delete.sh脚本进行清理，可能会呈现卡住的状况。通常是有finalizer的起因: 编辑资源删除相应finalizer即可。如果清理不洁净，重装还会报错: 通常是关联的一些MutatingWebhookConfiguration，ValidatingWebhookConfiguration，ClusterRole， ClusterRoleBinding等资源没清理，能够依据ks-installer日志定位并清理。 （三）监控不兼容导致看不到超级节点中Pod的监控 KubeSphere部署完后看工作负载的Pod列表，没有超级节点上Pod的监控数据: 是因为KubeSphere启用的监控，采集cadvisor监控数据的采集规定是，拜访所有节点的10250端口去拉监控数据，而超级节点的IP是个无奈路由的“假”IP，所以拉不到数据。 解决方案： 依照以下步骤减少自定义采集规定。 筹备secret yaml scrape-config.yaml: apiVersion: v1kind: Secrettype: Opaquemetadata: name: additional-scrape-configs namespace: kubesphere-monitoring-systemstringData: additional-scrape-configs.yaml: |- - job_name: kubelet # eks cadvisor 监控，为兼容 ks 查问，固定 job 名为 kubelet honor_timestamps: true metrics_path: '/metrics' params: collect[]: - 'ipvs' scheme: http kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_annotation_tke_cloud_tencent_com_pod_type] regex: eklet action: keep - source_labels: [__meta_kubernetes_pod_phase] regex: Running action: keep - source_labels: [__meta_kubernetes_pod_ip] separator: ; regex: (.*) target_label: __address__ replacement: ${1}:9100 action: replace - source_labels: [__meta_kubernetes_pod_name] separator: ; regex: (.*) target_label: pod replacement: ${1} action: replace - source_labels: [__meta_kubernetes_namespace] separator: ; regex: (.*) target_label: namespace replacement: ${1} action: replace metric_relabel_configs: - source_labels: [__name__] separator: ; regex: container_.* replacement: $1 action: keep - target_label: metrics_path replacement: /metrics/cadvisor action: replace - job_name: eks # eks cadvisor 之外的其它监控 honor_timestamps: true metrics_path: '/metrics' params: collect[]: - 'ipvs' scheme: http kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_annotation_tke_cloud_tencent_com_pod_type] regex: eklet action: keep - source_labels: [__meta_kubernetes_pod_phase] regex: Running action: keep - source_labels: [__meta_kubernetes_pod_ip] separator: ; regex: (.*) target_label: __address__ replacement: ${1}:9100 action: replace - source_labels: [__meta_kubernetes_pod_name] separator: ; regex: (.*) target_label: pod replacement: ${1} action: replace - source_labels: [__meta_kubernetes_namespace] separator: ; regex: (.*) target_label: namespace replacement: ${1} action: replace metric_relabel_configs: - source_labels: [__name__] separator: ; regex: (container_.*|pod_.*|kubelet_.*) replacement: $1 action: keep创立secret: ...

作者 | 守辰、志敏起源|阿里巴巴云原生公众号 11 月 11 日零点刚过 26 秒，阿里云再一次抗住了寰球最大的流量洪峰。往年 双11 是阿里经济体外围零碎全面云原生化的一年，相比去年外围零碎的上云，云原生化不仅让阿里享受到了云计算技术老本优化的红利，也让阿里的业务最大化取得云的弹性、效率和稳定性等价值。 为应答 双11，阿里云原生面临怎么的挑战？===================== 为了反对阿里这样大规模业务的云原生化，阿里云原生面临怎么样的挑战呢？ 集群多、规模大基于对业务稳定性和零碎性能等方面的综合思考，大型企业往往须要将业务集群部署到多个地区，在这样的场景下，撑持多集群部署的容器服务能力十分必要。同时，为了简化多集群治理的复杂度，以及为不能实现跨集群服务发现的业务提供反对，还须要关注容器服务中单个集群对大规模节点的治理能力。另外，大型企业的业务简单多样，因而一个集群内往往须要部署丰盛的组件，不仅包含次要的 Master 组件， 还须要部署业务方定制的 Operator 等。集群多、规模大，再加上单个集群内组件泛滥， 容器服务的性能、可扩展性、可运维性都面临着很大的挑战。 变动快、难预期市场瞬息万变，企业，特地是互联网企业，如果仅凭借教训、依附布局来应答市场变动，越来越难以撑持业务倒退，往往须要企业疾速地进行业务迭代、部署调整以应答市场的变动。这对为业务提供利用交付疾速反对、弹性伸缩性能和疾速响应撑持的容器服务提出了很大的要求。 变更多、危险大企业 IT 零碎的云原生化过程不仅要面临一次性的云迁徙和云原生革新老本，还将继续应答因为业务迭代和基础设施变更、人员流动带来的危险。而业务的迭代、基础设施的变更会无奈防止地为零碎引入缺点，重大时甚至造成故障，影响业务失常运行。最初，这些危险都可能会随着人员的流动进一步加剧。 阿里云容器服务大规模实际============ 高扩展性为了进步容器服务的可扩展性，须要自底向上、联动利用和服务一起优化。 1）接口最小化针对下层 PaaS，容器服务依靠 OAM（Open Application Model） 和 OpenKruise Workload 提供了丰盛的利用交付能力形象。对于 PaaS 层来说，只须要读取汇总的利用部署统计数值即可，极大缩小了下层零碎须要批量查问 pod、event 等信息的工作量，进而减小了对容器服务的管控压力；同时，通过把数量多、占用空间大的 pod 及 events 信息转存到数据库中， 并依据数据库中的内容提供一个对立的、可内嵌的部署状态查看和诊断页面的形式，能够使 PaaS 层防止间接拜访容器服务来实现相干性能。 2）分化而治之“分化而治之”是指要对业务做出正当的划分，防止因为所有业务和利用都集中在少数几个命名空间中，导致容器服务管控（控制器和 APIServer）在查问命名空间下所有资源时产生过大耗费的状况。目前在阿里外部最宽泛的实际形式是应用“利用名”做为命名空间。一方面利用是业务交付的根本单位，且不受组织调整的影响；另一方面，容器服务的组件以及业务本人的 Operator，在解决时往往会 list 命名空间下的资源，而命名空间默认在控制器和 APIServer 中都实现有索引，如果应用利用作为命名空间能够利用默认的索引减速查问操作。 3）苦修内外功对于容器服务的外围管控，须要扎实的内功做根底。针对大规模的应用场景，阿里云的容器服务进行了大量的组件优化，比方通过索引、Watch 书签等的形式，防止间接穿透 APIServer 拜访底层存储 ETCD，并通过优化 ETCD 闲暇页面调配算法、拆散 event 和 lease 存储至独立 ETCD 的办法，晋升 ETCD 自身的存储能力，其中不少曾经反馈给了社区，极大升高了 ETCD 解决读申请的压力。 详情可查看：https://4m.cn/JsXsU。 ...

概述External-DNS提供了编程方式管理Kubernetes Service资源的DNS的功能，类似于容器服务kubernetes federation v2实践一：基于External-DNS的多集群Ingress DNS实践，External-DNS会监听LoadBalancer类型的Service，然后与云厂商打通，按照可用区、region和全局三个维度生成独自的域名解析记录，便于服务间调用引导流量。本文简单介绍如何在阿里云容器平台上使用External-DNS管理多集群Service DNS。 环境准备参考容器服务kubernetes federation v2实践一：基于External-DNS的多集群Ingress DNS实践完成【联邦集群准备】、【配置RAM信息】和【部署External-DNS】部分，并配置好kubeConfig，如下所示： kubectl config get-contextsCURRENT NAME CLUSTER AUTHINFO NAMESPACE* cluster1 cluster1 kubernetes-admin1 cluster2 cluster2 kubernetes-admin2资源部署创建FederatedDeployment和FederatedServiceyaml如下，注意FederatedService类型为LoadBalancer apiVersion: v1kind: Namespacemetadata: name: test-namespace---apiVersion: types.federation.k8s.io/v1alpha1kind: FederatedNamespacemetadata: name: test-namespace namespace: test-namespacespec: placement: clusterNames: - cluster1 - cluster2---apiVersion: types.federation.k8s.io/v1alpha1kind: FederatedDeploymentmetadata: name: test-deployment namespace: test-namespacespec: template: metadata: labels: app: nginx spec: replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx name: nginx placement: clusterNames: - cluster1 - cluster2---apiVersion: types.federation.k8s.io/v1alpha1kind: FederatedServicemetadata: name: test-service namespace: test-namespacespec: template: spec: selector: app: nginx type: LoadBalancer ports: - name: http port: 80 placement: clusterNames: - cluster2 - cluster1查看各个集群Service详情： ...

本文来自于我的慕课网手记：简单聊会 Docker，转载请保留链接 ;)最近在工作中一直在忙基础设施构建，发现在选型的时候，大家心里基本上都有一个自己的成熟架构。而在服务部署这块发现公司的同事们都大多数考虑Docker，在业余闲聊了后，发现他们对Docker只是在停留在使用，对一些Docker的基本知识还是不了解，并不清楚 Docker 到底是什么，要解决什么问题，好处又在哪里？今天就来详细解释，帮助大家理解它，还带有简单易懂的实例，教你如何将它用于日常开发并用其部署微服务。 Docker简介Docker是基于Go语言实现的云开源项目，诞生于2013年初，最初发起者是dotCloud公司。Docker自开源后受到广泛的关注和讨论，目前已有多个相关项目，逐渐形成了围绕Docker的生态体系。dotCloud公司后来也改名为Docker Inc，专注于Docker相关技术和产品的开发。Docker 一直广受瞩目，被认为可能会改变软件行业。那么什么是Docker呢？我查阅了网上的一些相关资料，现用一段话总结了一下。Docker是一个开源的容器引擎，它可以帮助我们更快地交付应用。Docker可将应用程序和基础设施层隔离，并且能将基础设施当作程序一样进行管理。使用Docker，可更快地打包、测试以及部署应用程序，并可减少从编写到部署运行代码的周期。对一个事物有了一定了解后，我们的继续学习Docker官方的给出文档和源码。（这个今天不在此文章扩展，不然聊不完。） TIPS (1) Docker官方网站：https://www.docker.com/ (2) Docker GitHub：https://github.com/docker/docker Docker快速入门执行如下命令，即可启动一个Nginx容器``docker run -d -p 91:80 nginx`` Docker架构我们来看一下来自Docker官方文档的架构图，如图所示。 我们来讲解上图中包含的组件。(1) Docker daemon（Docker守护进程） Docker daemon是一个运行在宿主机（DOCKER_HOST）的后台进程。我们可通过Docker客户端与之通信。 (2) Client（Docker客户端） Docker客户端是Docker的用户界面，它可以接受用户命令和配置标识，并与Docker daemon通信。图中，docker build等都是Docker的相关命令。 (3) Images（Docker镜像） Docker镜像是一个只读模板，它包含创建Docker容器的说明。它和系统安装光盘有点像——我们使用系统安装光盘安装系统，同理，我们使用Docker镜像运行Docker镜像中的程序。 (4) Container（容器） 容器是镜像的可运行实例。镜像和容器的关系有点类似于面向对象中，类和对象的关系。我们可通过Docker API或者CLI命令来启停、移动、删除容器。 (5) Registry Docker Registry是一个集中存储与分发镜像的服务。我们构建完Docker镜像后，就可在当前宿主机上运行。但如果想要在其他机器上运行这个镜像，我们就需要手动拷贝。此时，我们可借助Docker Registry来避免镜像的手动拷贝。 一个Docker Registry可包含多个Docker仓库；每个仓库可包含多个镜像标签；每个标签对应一个Docker镜像。这跟Maven的仓库有点类似，如果把Docker Registry比作Maven仓库的话，那么Docker仓库就可理解为某jar包的路径，而镜像标签则可理解为jar包的版本号。 Docker Registry可分为公有Docker Registry和私有Docker Registry。最常用的Docker Registry莫过于官方的Docker Hub，这也是默认的Docker Registry。Docker Hub上存放着大量优秀的镜像，我们可使用Docker命令下载并使用。 Docker应用场景常用的8个Docker的真实使用场景，分别是简化配置、代码流水线管理、提高开发效率、隔离应用、整合服务器、调试能力、多租户环境、快速部署。我们一直在谈Docker，Docker怎么使用，在怎么样的场合下使用？ 首先你在享有Docker带来的虚拟化能力的时候无需担心它带来的额外开销。其次，相比于虚拟机，你可以在同一台机器上创建更多数量的容器。 Docker的另外一个优点是容器的启动与停止都能在几秒中内完成。Docker公司的创始人 Solomon Hykes曾经介绍过Docker在单纯的LXC之上做了哪些事情，你可以去看看。 下面是我总结的一些Docker的使用场景，它为你展示了如何借助Docker的优势，在低开销的情况下，打造一个一致性的环境。 简化配置这是Docker公司宣传的Docker的主要使用场景。虚拟机的最大好处是能在你的硬件设施上运行各种配置不一样的平台（软件、系统），Docker在降低额外开销的情况下提供了同样的功能。它能让你将运行环境和配置放在代码中然后部署，同一个Docker的配置可以在不同的环境中使用，这样就降低了硬件要求和应用环境之间耦合度。 代码流水线（Code Pipeline）管理前一个场景对于管理代码的流水线起到了很大的帮助。代码从开发者的机器到最终在生产环境上的部署，需要经过很多的中间环境。而每一个中间环境都有自己微小的差别，Docker给应用提供了一个从开发到上线均一致的环境，让代码的流水线变得简单不少。 提高开发效率这就带来了一些额外的好处：Docker能提升开发者的开发效率。如果你想看一个详细一点的例子，可以参考Aater在DevOpsDays Austin 2014 大会或者是DockerCon上的演讲。 ...

综述学习Kubernetes时，发现它的概念和术语还是比较多的，光靠啃官方文档比较晦涩。所以边学习边整理，对主要的概念和术语做一下分类及简要说明。感觉把重要概念都理解了，对Kubernetes的设计思想，整体框架也就有了初步的认识。从功能上来说，我把Kubernetes的概念或术语大概分为以下三类：组件：指实际在集群中运行的Kubernetes程序集，分为Master组件、Node组件及附加组件。对象：对象是一个抽象的概念实体，Kubernetes把应用、运行场景、功能、集群状态等都抽象成一个个对象，并通过API对这些对象进行管理，从而管理整个集群的状态。标识：对组件和对象的各种表示方式，例如命名、标签、注释等。标识是KubernetesAPI与操作对象间的纽带。组件Master组件Master组件提供了k8s管理集群的核心功能，k8s通过Master组件实现整个集群的调度管理，它就像集群的大脑，会根据集群当前的状态，不断进行调整，使集群一直保持在期望的状态。Master组件包括以下几个进程：kube-apiserverapiserver进程对外暴露REST API接口给外部客户端及内部组件调用，它封装了对各个对象的增、删、改、查操作，可以说是整个集群管理的总入口。kube-schedulerkube-scheduler做的事情说来简单–监控新pod的创建，并把pod分配到合适的node来运行。但实际上，选择“合适的Node”是一个很复杂的过程，需要考虑的因素包括单node及整个集群的资源需求、软硬件资源的限制策略、数据存储、工作负载间的干扰等等。kube-controllers-managercontrollers-manager进程从字面上理解，是用来做控制器管理的。controllers-manager其实是一组守护进程，通过监控集群各组件的状态，并不断调整集群实际状态，使的集群向期望状态调整，它由一组子进程构成：replication controllerendpoints controllernamespace controllerserviceaccounts controllerEtcdEtcd是Kubernetes集群的基础组件，用于保存集群所有的元数据信息、配置信息、对象状态等。Node组件运行Node组件的节点称为Node节点，是k8s集群实际的工作负载节点。Node节点可以是物理机、虚拟机或任何可以运行Node组件的设备。所有的业务应用都运行在Node节点中。Node组件包括以下几个部分：Kubeletkubelet负责实际的容器管理，Kubernetes通过apiserver给kubelet发送Pod管理请求，同时把Pod及Node的运行状态汇报给apiserver。kube-proxykube-proxy负责集群内部的请求转发及负载均衡工作。它通过Service对象的配置信息，为Pod创建代理服务，实现请求从Service到Pod的路由转发。容器运行时实际的容器运行引擎。Kubernetes其实支持其他的容器技术比如rkt，但是Docker相比与它们处于绝对的优势地位。所以，Kubernetes生态中的容器也基本特指指Docker容器。对象Kubernetes中，所谓对象指的就是API对象。Kubernetes集群为每个对象维护三类信息：对象元数据(ObjectMeta)、期望状态(Desired State)与实际状态(Autual State),元数据指对象的基本信息，比如命名、标签、注释等等，用于识别对象；期望状态一般由用户配置spec来描述的；实际状态是由集群各个组件上报的集群实际的运行情况。Kubernetes努力使每个对象的实际状态与期望状态相匹配，从而使整个集群的状态与用户配置的期望状态一致。Kubernetes对象一般用yaml文件来描述，有几个个字段是必须的：apiVersion: 创建该对象所使用的 Kubernetes API 的版本kind: 想要创建的对象的类型metadata: 帮助识别对象唯一性的数据，包括一个 name 字符串、UID 和可选的 namespacespec: 对象期望状态的描述用户通过命令行工具kubectl来操作这些对象，Kubectl吧yaml转换成JSON格式来执行API请求。下面是一个POD对象的描述文件示例及注释：apiVersion: v1kind: Pod # 对象名称metadata: # 对象的基本信息 name: pod-example # 对象唯一标示spec: # 期望状态 containers: # 指定pod中运行的容器镜像及运行参数(类似Dockerfile) - name: ubuntu image: ubuntu:trusty command: [“echo”] args: [“Hello World”]其中，kind字段描述对象类型"Pod"，spec之前是对象的ObjectMeta，spec开始，就是对象期望状态的描述。根据官方API对象参考文档的分类，下面我们把对象分为几大类来分别简要说明。计划以后的文章，会结合实际操作，对各个重要对象做更深入的说明。Workloads 资源对象- workloads类的对象用于管理运行容器实例Pod： Pod是Kubernetes里最重要的对象，也是Kubernetes集群中运行部署应用或服务的最小单位。Pod对象描述一个Pod由哪些容器镜像构成，以及这些容器应该怎么运行。类比传统的业务架构，Pod更接近于虚拟机的角色而不是应用进程的角色。ReplicaSet： ReplicaSet对象是对Pod的更高一层抽象，它用来管理一组相同POD副本，并确保这组相同Pod的数量始终与用户期望一致，并实现Pod的高可用。即如果有容器异常退出，ReplicaSet会自动创建新的Pod来替代，保证Pod数量永远与用户配置一致。Deployment： Deployment对象是Kubernetes中最常用的对象之一，用于部署无状态服务。它在ReplicaSet对象的基础上，又做了一层抽象。通过管理多组ReplicaSet对象，来实现POD的滚动升级、回滚、扩容缩容等。StatefulSet： 不同于Deployment，StatefulSet对象顾名思义是对有状态服务的一种抽象。所以，StatefulSet对象在定义时，相比与Deployment多了一些与状态相关的内容，比如持久化存储、服务对外的不变的唯一标示、部署、扩容、滚动升级时确保有序等等。DaemonSet： DaemonSet对象是Kubernetes对守护进程的抽象。当我们需要集群中的每个Node都跑一些如日志收集、监控等守护进程时，就可以把这类型进程包装成Pod，并用调用DaemonSet来部署了。DaemonSet做的事情其实和Deployment差不多，只不过Deployment对象部署的Pod，会根据集群情况，在不同Node间自动调度。而DaemonSet会指定的NODE上(默认是集群所有Node)，都部署定义Pod，确保这些NODE都有跑着守护进程Pod。Job、CronJob： 除了上面几个对象所抽象描述的应用工作场景外，实际业务场景中，还有一类应用或服务并不需要一直运行，比如一些一次性任务，或需要定时执行的任务。这种不需要长时间运行的任务，完成了就可以退出的服务，就可以用Job对象来定义。CronJob和Job对象的关系，和Deployment与ReplicaSet的关系很像，可以类比来理解。首先，Job也是直接用于管理Pod的，同时可以定义这个一次性任务Pod的执行时间、超时时间、错误处理（重启还是生成新Pod）等任务属性。而CronJob管理是用来管理Job，类似crobtab，它可以通过yaml文件中的schedule字段配置具体时间，来控制指定Job定时执行，从而实现定时执行特定的一次性任务。Discovery & LB 资源对象- 该类对象用于服务发现和负载均衡的对象Service：上面提到的对象都是用于管理POD及容器实例的。但是，业务系统光有POD实例还不够，还必须对外提供服务。这里就会衍生出两个问题：Pod的IP地址并不是固定，而是随着编排不断变化的，外面的请求怎么找到对应的POD，这个也就是大多数分布式业务都会遇到的服务发现问题多个相同Pod一起提供服务的时候，它们的负载均衡怎么实现而Service对象就是用来解决这两个问题的。它用固定的VIP或DNS名称和指定标识的一组Pod对应起来，不管Pod IP怎么变，Service对外的VIP都不会变化，并且，自动的将请求在这组Pod中负载均衡。Config & Storage 资源对象- 该类对象用于初始化容器配置及持久化容器存储的对象Volume：前面说到，Pod里的不同容器可以共享存储，这个共享存储就靠Volume来配置的。要注意的是，这里Volume与Docker中的定义不用，Kubernetes中Volume跟Pod生命周期一致，Pod终止了，该Pod挂载的Volume就失效了（根据挂载volume的类型不同，数据可能丢失也可能不丢失）。PV，PVC：Volume可以支持多种类型的存储，除了直接在Volume字段中去声明所有存储细节，K8S还抽象出了PV和PVC对象。简单来说PV是对具体存储资源的描述，比如存储类型、地址、访问账户等；而PVC，是对怎么使用资源的方法的描述，比如只读只写，需要的空间等；而Pod通过Volume字段挂载具体要使用的PVC。PV和PVC是独立于Pod单独定义的，这样，就把共享存储的配置、分割、挂载等操作都解耦了。比如，一个NFS迁移后ip地址变了，存储管理员只需要修改PV中的配置，而不用关心具体哪个业务POD在使用这个NFS。ConfigMap,SecuretK8S中除了常见的存储，还有一类特殊的Volume，不是为了Pod存放数据，而是为了给Pod提供数据的。ConfigMap和Secret对象就是用来定义这类型的Volume。简单来说，可以将它们理解为一份Key:Value格式的数据，Pod可以通过Volume挂载它们，将这份数据保存成文件随时调用。唯一的区别是，ConfigMap对象保存的数据是明文，一般作为应用配置文件；而Secret对象保存的对象要求是经过Base64转码的，用于提供数据库密码等对安全要求比较高的配置。不过这些配置，直接在做容器镜像时就配置不就好了，为啥要多此一举呢？原因和上面PV和PVC一样，都是为了尽可能解耦业务核心与经常可能变化的依赖配置。比如数据库更换了账号，只需要修改Secret对象，不用重新去构建容器镜像。Cluster resources objects- 该类对象定义整个K8S集群运行方式的对象NamespaceKubernetes作为一个集群管理平台，为不同用户划分不同权限管理，例如多租户等，是必备的功能。而不同用户作用域的隔离，就是靠Namespace对象实现的。Namespace是Kubernetes项目中的一个逻辑管理单位，不同Namespace的API对象，在调用API进行操作是，是相互隔离开的。通过不同用户角色与Namespace关联，从而实现权限管理。Metadata resources- 除了上述分类外的其他对象都归为这一类，一般用来管理集群的特殊功能比如弹性伸缩等Horizontal Pod Autoscaling容器作为一个轻量级的承载应用的技术，快速启动和快速部署是它的优点之一。自然的，根据业务负载自动扩缩容等需求，在容器集群的可行性和效率就可以变得很高。而Kubernetes中 Horizontal Pod Autoscaling对象，就是用于进行POD自动水平缩放的，这也是Kubernetes最能体现运维优势的特性之一。Horizontal Pod Autoscaling具体的操作对象是Deployment和ReplicaSet，通过不同循环获取每个Pod的资源情况，比如CPU利用率，并根据设定的目标利率来计算目前需要的Pod副本缩放的比例，然后通过访问相应的Deployment或ReplicaSet对象，来对Pod数量进行自动缩放，从而提高了集群资源整体利用率。标识标识是Kubernetes中最重要的概念，因为它是所有API的操作与操作对象间的纽带。Kubernetes中的标识主要有以下几种：LabelLabel可以说是Kubernetes中最最重要的核心概念，一个Lable是一个KEY=Value的键值对。任何对象资源都可以有一个或多个Label，而同个Label，也可以配置在多个对象上。然后重点来了，大多数API对象的yaml字段中，都有Label Selector字段，可以实现对Label中的key或value的多维度选择，例如in、not in、and、or等等。这样，Kubernetes对API作用对象就能进行多维度，细粒度的选择，从而实现比较精细化的容器编排调度工作，比如,对所有"ENV:release"执行扩容操作，或者把部分请求灰度到有"ver:v1.14.0"的pod上等等。Label把资源对象和应用、基础设施都解耦了，你不用关心这个Pod具体在那个Node上运行，也不用关心具体是什么应用用了哪个容器镜像，只要Label符合Label Selector，就可以通过API调用统一进行操作。Names除了Label，所有资源对象肯定还必须有一个全局唯一的标识，即Names字段。AnnotationAnnotation很好理解，与通常意义的注释一样，用于描述作者、版本、配置说明等等任何需要的信息，需要说明的是，Annotation也必须是Key：Value格式的。总结通过上面对Kubernetes重要概念的说明，我们可以大致梳理出Kubernetes的一些设计理念：Kubernetes对容器应用进行了抽象，例如把一个容器或强关联的一组容器抽象为Pod，把各类存储都抽象成Volume，把一组Pod抽象成Service等等基础对象。在基础对象的层面上，Kubernetes又对应用使用场景，做了一层抽象。极客时间的Kubernetes课程有一张图画的很好：可以看到，Kubernetes中各个对象实际就是对生产业务场景的各类需求的抽象。抽象出各类型对象以后，用户可以通过yaml文件（或直接命令行调用API）来描述这些对象的期望状态，确认了各对象些期望状态的集合，也就确认了整个集群的期望状态。这些所有的操作，都是声明式的，而不是命令集群要怎么做Kubernetes通过控制器循环不断将各组件收集来的集群实际状态与各对象的期望状态对比，并自动化的将集群实际状态向期望状态转移，这个过程，也就是Kubernetes最核心的概念：编排。本文对Kubernetes中的重要概念做了分类和简要，后面的文章会结合集群的实际操作，对每个概念做更详细的说明。 ...

一. 概述Prometheus除了存储数据外，还提供了一种强大的功能表达式语言 PromQL，允许用户实时选择和汇聚时间序列数据。表达式的结果可以在浏览器中显示为图形，也可以显示为表格数据，或者由外部系统通过 HTTP API 调用。通过PromQL用户可以非常方便地查询监控数据，或者利用表达式进行告警配置如：k8s中的node在线率：sum(kube_node_status_condition{condition=“Ready”, status=“true”}) / sum(kube_node_info) 100 Metric类型关于时间序列存储，可以参考：https://www.infoq.cn/article/…Prometheus会将所有采集到的样本数据以时间序列（time-series）的方式保存在内存数据库TSDB中，并且定时保存到硬盘上。time-series是按照时间戳和值的序列顺序存放的，我们称之为向量(vector)。每条time-series通过指标名称(metrics name)和一组标签集(labelset)命名。在time-series中的每一个点称为一个样本（sample），样本由以下三部分组成：指标(metric)：metric name和描述当前样本特征的labelsets;时间戳(timestamp)：一个精确到毫秒的时间戳;样本值(value)： 一个folat64的浮点型数据表示当前样本的值。如某一时刻的node_cpu指标为459.71node_cpu{app=“node-exporter”,cpu=“cpu0”,instance=“192.168.0.4:9100”,job=“kubernetes-service-endpoints”,kubernetes_name=“node-exporter”,kubernetes_namespace=“kube-system”,mode=“guest”} 459.71Prometheus定义了4中不同的指标类型(metric type):Counter 计数器计数器，只增不减，如http_requests_total请求总数例如，通过rate()函数获取HTTP请求量的增长率：rate(http_requests_total[5m])Gauge 仪表盘当前状态，可增可减。如kube_pod_status_ready当前pod可用数可以获取样本在一段时间返回内的变化情况,如：delta(kube_pod_status_ready[2h])Histogram 直方图Histogram 由 <basename>_bucket{le="<upper inclusive bound>"}，<basename>_bucket{le="+Inf"}, <basename>_sum，<basename>_count 组成，主要用于表示一段时间范围内对数据进行采样（通常是请求持续时间或响应大小），并能够对其指定区间以及总数进行统计，通常它采集的数据展示为直方图。例如 Prometheus server 中 prometheus_local_storage_series_chunks_persisted, 表示 Prometheus 中每个时序需要存储的 chunks 数量，我们可以用它计算待持久化的数据的分位数。Summary 摘要Summary 和 Histogram 类似，由 <basename>{quantile="<>"}，<basename>_sum，<basename>_count 组成，主要用于表示一段时间内数据采样结果（通常是请求持续时间或响应大小），它直接存储了 quantile 数据，而不是根据统计区间计算出来的。例如 Prometheus server 中 prometheus_target_interval_length_seconds。Histogram 需要通过 <basename>_bucket 计算 quantile, 而 Summary 直接存储了 quantile 的值。基础查询PromQL是Prometheus内置的数据查询语言，其提供对时间序列数据丰富的查询，聚合以及逻辑运算能力的支持。如http_requests_total指标你可以通过附加一组标签，并用{}括起来，来进一步筛选这些时间序列。下面这个例子只选择有http_requests_total名称的、有prometheus工作标签的、有canary组标签的时间序列：http_requests_total{job=“prometheus”,group=“canary”}如果条件为空，可以写为：http_requests_total{}另外，也可以也可以将标签值反向匹配，或者对正则表达式匹配标签值。如操作符： =：选择正好相等的字符串标签 !=：选择不相等的字符串标签 =~：选择匹配正则表达式的标签（或子标签） !=：选择不匹配正则表达式的标签（或子标签） 范围查询类似http_requests_total{job=“prometheus”,group=“canary”}的方式，得到的是瞬时值，如果想得到一定范围内的值，可以使用范围查询时间范围通过时间范围选择器[]进行定义。例如，通过以下表达式可以选择最近5分钟内的所有样本数据，如：http_request_total{}[5m]除了分钟，支持的单位有：s - 秒m - 分钟h - 小时d - 天w - 周y - 年偏移查询如：查询http_requests_total在当前时刻的一周的速率：rate(http_requests_total{} offset 1w)偏移修饰符允许更改查询中单个即时向量和范围向量的时间偏移量，例如，以下表达式返回相对于当前查询时间5分钟前的http_requests_total值：http_requests_total offset 5m等价于http_requests_total{job=“prometheus”}[5m]请注意，偏移量修饰符始终需要跟随选择器，即以下是正确的：sum(http_requests_total{method=“GET”} offset 5m) // GOOD.下面是错误的:sum(http_requests_total{method=“GET”}) offset 5m // INVALID.操作符Prometheus 的查询语言支持基本的逻辑运算和算术运算二元算术运算：加法减法乘法/ 除法% 模^ 幂等运算中用到的基础数据类型：瞬时向量（Instant vector） - 一组时间序列，每个时间序列包含单个样本，它们共享相同的时间戳。也就是说，表达式的返回值中只会包含该时间序列中的最新的一个样本值。而相应的这样的表达式称之为瞬时向量表达式。区间向量（Range vector） - 一组时间序列，每个时间序列包含一段时间范围内的样本数据。标量（Scalar） - 一个浮点型的数据值。字符串（String） - 一个简单的字符串值。二元运算操作符支持 scalar/scalar(标量/标量)、vector/scalar(向量/标量)、和 vector/vector(向量/向量) 之间的操作。在两个标量之间进行数学运算，得到的结果也是标量。例如，如果我们想根据 node_disk_bytes_written 和 node_disk_bytes_read 获取主机磁盘IO的总量，可以使用如下表达式：node_disk_bytes_written + node_disk_bytes_read或者node的内存数GBnode_memory_free_bytes_total / (1024 * 1024)布尔运算== (相等)!= (不相等)(大于)< (小于)= (大于等于)<= (小于等于)如：获取http_requests_total请求总数是否超过10000，返回0和1，1则报警http_requests_total > 10000 # 结果为 true 或 falsehttp_requests_total > bool 10000 # 结果为 1 或 0集合运算and (并且)or (或者)unless (排除)优先级四则运算有优先级，promql的复杂运算也有优先级例如，查询主机的CPU使用率，可以使用表达式：100 * (1 - avg (irate(node_cpu{mode=‘idle’}[5m])) by(job) )其中irate是PromQL中的内置函数，用于计算区间向量中时间序列每秒的即时增长率在PromQL操作符中优先级由高到低依次为：^, /, %+, -==, !=, <=, <, >=, >and, unlessor匹配模式（联合查询）与数据库中的join类似，promsql有两种典型的匹配查询：一对一（one-to-one）多对一（many-to-one）或一对多（one-to-many）例如当存在样本：method_code:http_errors:rate5m{method=“get”, code=“500”} 24method_code:http_errors:rate5m{method=“get”, code=“404”} 30method_code:http_errors:rate5m{method=“put”, code=“501”} 3method_code:http_errors:rate5m{method=“post”, code=“500”} 6method_code:http_errors:rate5m{method=“post”, code=“404”} 21method:http_requests:rate5m{method=“get”} 600method:http_requests:rate5m{method=“del”} 34method:http_requests:rate5m{method=“post”} 120使用 PromQL 表达式：method_code:http_errors:rate5m{code=“500”} / ignoring(code) method:http_requests:rate5m该表达式会返回在过去 5 分钟内，HTTP 请求状态码为 500 的在所有请求中的比例。如果没有使用 ignoring(code)，操作符两边表达式返回的瞬时向量中将找不到任何一个标签完全相同的匹配项。因此结果如下：{method=“get”} 0.04 // 24 / 600{method=“post”} 0.05 // 6 / 120同时由于 method 为 put 和 del 的样本找不到匹配项，因此不会出现在结果当中。多对一模式例如，使用表达式：method_code:http_errors:rate5m / ignoring(code) group_left method:http_requests:rate5m该表达式中，左向量 method_code:http_errors:rate5m 包含两个标签 method 和 code。而右向量 method:http_requests:rate5m 中只包含一个标签 method，因此匹配时需要使用 ignoring 限定匹配的标签为 code。 在限定匹配标签后，右向量中的元素可能匹配到多个左向量中的元素 因此该表达式的匹配模式为多对一，需要使用 group 修饰符 group_left 指定左向量具有更好的基数。最终的运算结果如下：{method=“get”, code=“500”} 0.04 // 24 / 600{method=“get”, code=“404”} 0.05 // 30 / 600{method=“post”, code=“500”} 0.05 // 6 / 120{method=“post”, code=“404”} 0.175 // 21 / 120提醒：group 修饰符只能在比较和数学运算符中使用。在逻辑运算 and，unless 和 or 操作中默认与右向量中的所有元素进行匹配。聚合操作Prometheus 还提供了下列内置的聚合操作符，这些操作符作用域瞬时向量。可以将瞬时表达式返回的样本数据进行聚合，形成一个具有较少样本值的新的时间序列。sum (求和)min (最小值)max (最大值)avg (平均值)stddev (标准差)stdvar (标准差异)count (计数)count_values (对 value 进行计数)bottomk (样本值最小的 k 个元素)topk (样本值最大的k个元素)quantile (分布统计)这些操作符被用于聚合所有标签维度，或者通过 without 或者 by 子语句来保留不同的维度。without 用于从计算结果中移除列举的标签，而保留其它标签。by 则正好相反，结果向量中只保留列出的标签，其余标签则移除。通过 without 和 by 可以按照样本的问题对数据进行聚合。例如：如果指标 http_requests_total 的时间序列的标签集为 application, instance, 和 group，我们可以通过以下方式计算所有 instance 中每个 application 和 group 的请求总量：sum(http_requests_total) without (instance)等价于 sum(http_requests_total) by (application, group)如果只需要计算整个应用的 HTTP 请求总量，可以直接使用表达式：sum(http_requests_total)count_values 用于时间序列中每一个样本值出现的次数。count_values 会为每一个唯一的样本值输出一个时间序列，并且每一个时间序列包含一个额外的标签。这个标签的名字由聚合参数指定，同时这个标签值是唯一的样本值。例如要计算运行每个构建版本的二进制文件的数量：count_values(“version”, build_version)返回结果如下：{count=“641”} 1{count=“3226”} 2{count=“644”} 4topk 和 bottomk 则用于对样本值进行排序，返回当前样本值前 n 位，或者后 n 位的时间序列。获取 HTTP 请求数前 5 位的时序样本数据，可以使用表达式：topk(5, http_requests_total)quantile 用于计算当前样本数据值的分布情况 quantile(, express) ，其中 0 ≤ ≤ 1例如，当 为 0.5 时，即表示找到当前样本数据中的中位数：quantile(0.5, http_requests_total)返回结果如下：{} 656内置函数Prometheus 提供了其它大量的内置函数，可以对时序数据进行丰富的处理。如上文提到的irate100 * (1 - avg (irate(node_cpu{mode=‘idle’}[5m])) by(job) )常用的有：两分钟内的平均CPU使用率： rate(node_cpu[2m])和irate(node_cpu[2m])需要注意的是使用rate或者increase函数去计算样本的平均增长速率，容易陷入“长尾问题”当中，其无法反应在时间窗口内样本数据的突发变化。 例如，对于主机而言在2分钟的时间窗口内，可能在某一个由于访问量或者其它问题导致CPU占用100%的情况，但是通过计算在时间窗口内的平均增长率却无法反应出该问题。为了解决该问题，PromQL提供了另外一个灵敏度更高的函数irate(v range-vector)。irate同样用于计算区间向量的计算率，但是其反应出的是瞬时增长率。irate函数是通过区间向量中最后两个两本数据来计算区间向量的增长速率。这种方式可以避免在时间窗口范围内的“长尾问题”，并且体现出更好的灵敏度，通过irate函数绘制的图标能够更好的反应样本数据的瞬时变化状态。irate函数相比于rate函数提供了更高的灵敏度，不过当需要分析长期趋势或者在告警规则中，irate的这种灵敏度反而容易造成干扰。因此在长期趋势分析或者告警中更推荐使用rate函数。完整的函数列表为：abs()absent()ceil()changes()clamp_max()clamp_min()day_of_month()day_of_week()days_in_month()delta()deriv()exp()floor()histogram_quantile()holt_winters()hour()idelta()increase()irate()label_join()label_replace()ln()log2()log10()minute()month()predict_linear()rate()resets()round()scalar()sort()sort_desc()sqrt()time()timestamp()vector()year()<aggregation>_over_time()API访问Prometheus当前稳定的HTTP API可以通过/api/v1访问错误状态码：404 Bad Request：当参数错误或者缺失时。422 Unprocessable Entity 当表达式无法执行时。503 Service Unavailiable 当请求超时或者被中断时。所有的API请求均使用以下的JSON格式：{ “status”: “success” | “error”, “data”: <data>, // 为error时，有如下报错信息 “errorType”: “<string>”, “error”: “<string>"}通过HTTP API我们可以分别通过/api/v1/query和/api/v1/query_range查询PromQL表达式当前或者一定时间范围内的计算结果。瞬时数据查询URL请求参数：query=：PromQL表达式。time=：用于指定用于计算PromQL的时间戳。可选参数，默认情况下使用当前系统时间。timeout=：超时设置。可选参数，默认情况下使用-query,timeout的全局设置。$ curl ‘http://localhost:9090/api/v1/query?query=up&time=2015-07-01T20:10:51.781Z’返回：{ “status” : “success”, “data” : { “resultType” : “vector”, “result” : [ { “metric” : { “name” : “up”, “job” : “prometheus”, “instance” : “localhost:9090” }, “value”: [ 1435781451.781, “1” ] }, { “metric” : { “name” : “up”, “job” : “node”, “instance” : “localhost:9100” }, “value” : [ 1435781451.781, “0” ] } ] }}区间查询URL请求参数：query=: PromQL表达式。start=: 起始时间。end=: 结束时间。step=: 查询步长。timeout=: 超时设置。可选参数，默认情况下使用-query,timeout的全局设置。$ curl ‘http://localhost:9090/api/v1/query_range?query=up&start=2015-07-01T20:10:30.781Z&end=2015-07-01T20:11:00.781Z&step=15s’返回：{ “status” : “success”, “data” : { “resultType” : “matrix”, “result” : [ { “metric” : { “name” : “up”, “job” : “prometheus”, “instance” : “localhost:9090” }, “values” : [ [ 1435781430.781, “1” ], [ 1435781445.781, “1” ], [ 1435781460.781, “1” ] ] }, { “metric” : { “name” : “up”, “job” : “node”, “instance” : “localhost:9091” }, “values” : [ [ 1435781430.781, “0” ], [ 1435781445.781, “0” ], [ 1435781460.781, “1” ] ] } ] }}本文为容器监控实践系列文章，完整内容见：container-monitor-book ...

系统架构图1.x版本的Prometheus的架构图为：目前Prometheus版本为2.7，架构图为：Prometheus从exporter拉取数据，或者间接地通过网关gateway拉取数据（如果在k8s内部署，可以使用服务发现的方式），它默认本地存储抓取的所有数据，并通过一定规则进行清理和整理数据，并把得到的结果存储到新的时间序列中，采集到的数据有两个去向，一个是报警，另一个是可视化。PromQL和其他API可视化地展示收集的数据，并通过Alertmanager提供报警能力。组件内容Prometheus Server负责从 Exporter 拉取和存储监控数据,并提供一套灵活的查询语言（PromQL）Retrieval: 采样模块TSDB: 存储模块默认本地存储为tsdbHTTP Server: 提供http接口查询和面板，默认端口为9090Exporters/Jobs负责收集目标对象（host, container…）的性能数据，并通过 HTTP 接口供 Prometheus Server 获取。支持数据库、硬件、消息中间件、存储系统、http服务器、jmx等。只要符合接口格式，就可以被采集。Short-lived jobs瞬时任务的场景，无法通过pull方式拉取，需要使用push方式，与PushGateway搭配使用PushGateway可选组件，主要用于短期的 jobs。由于这类 jobs 存在时间较短，可能在 Prometheus 来 pull 之前就消失了。为此，这次 jobs 可以直接向 Prometheus server 端推送它们的 metrics。这种方式主要用于服务层面的 metrics，对于机器层面的 metrices，需要使用 node exporter。客户端sdk官方提供的客户端类库有go、java、scala、python、ruby，其他还有很多第三方开发的类库，支持nodejs、php、erlang等PromDash使用rails开发的dashboard，用于可视化指标数据，已废弃Alertmanager从 Prometheus server 端接收到 alerts 后，会进行去除重复数据，分组，并路由到对收的接受方式，发出报警。常见的接收方式有：电子邮件，pagerduty，OpsGenie, webhook 等。Service Discovery服务发现，Prometheus支持多种服务发现机制：文件，DNS，Consul,Kubernetes,OpenStack,EC2等等。基于服务发现的过程并不复杂，通过第三方提供的接口，Prometheus查询到需要监控的Target列表，然后轮训这些Target获取监控数据。其大概的工作流程是：Prometheus server 定期从配置好的 jobs 或者 exporters 中拉 metrics，或者接收来自 Pushgateway 发过来的 metrics，或者从其他的 Prometheus server 中拉 metrics。Prometheus server 在本地存储收集到的 metrics，并运行已定义好的 alert.rules，记录新的时间序列或者向 Alertmanager 推送警报。Alertmanager 根据配置文件，对接收到的警报进行处理，发出告警。在图形界面中，可视化采集数据。关于Push与PullPrometheus采集数据是用的pull也就是拉模型,通过HTTP协议去采集指标，只要应用系统能够提供HTTP接口就可以接入监控系统，相比于私有协议或二进制协议来说开发、简单。优点主要是：开发任何新功能，你甚至可以在电脑上查看你的监控如果目标实例挂掉，你可以很快知道你可以手动指定目标实例，并且在浏览器中查看他的健康状态总体来说，Pull模式比Push模式更好一些，在监控系统中这也不是一个很重要的点。如果要使用push的方式，可以使用Pushgateway的方式，如定时任务的采集。对于定时任务这种短周期的指标采集，如果采用pull模式，可能造成任务结束了，Prometheus还没有来得及采集，这个时候可以使用加一个中转层，客户端推数据到Push Gateway缓存一下，由Prometheus从push gateway pull指标过来。(需要额外搭建Push Gateway，同时需要新增job去从gateway采数据)推的代表有 ElasticSearch，InfluxDB，OpenTSDB 等，需要你从程序中将指标使用 TCP，UDP 等方式推送至相关监控应用，只是使用 TCP 的话，一旦监控应用挂掉或存在瓶颈，容易对应用本身产生影响，而使用 UDP 的话，虽然不用担心监控应用，但是容易丢数据。拉的代表，主要代表就是 Prometheus，让我们不用担心监控应用本身的状态。而且，可以利用 DNS-SRV 或者 Consul 等服务发现功能就可以自动添加监控。当然，InfluxDB 加上 collector，或者 ES 加上 metricbeat 也可以变为 『拉』，而 Prometheus 加上 Push Gateway 也可以变为 『推』。更多区别可以参考下图：存储机制Prometheus有着非常高效的时间序列数据存储方法，每个采样数据仅仅占用3.5byte左右空间，上百万条时间序列，30秒间隔，保留60天，大概花了200多G（引用官方PPT）。Prometheus内部主要分为三大块，Retrieval是负责定时去暴露的目标页面上去抓取采样指标数据，Storage是负责将采样数据写磁盘，PromQL是Prometheus提供的查询语言模块。Prometheus内置了一个基于本地存储的时间序列数据库。在Prometheus设计上，使用本地存储可以降低Prometheus部署和管理的复杂度同时减少高可用（HA）带来的复杂性。 在默认情况下，用户只需要部署多套Prometheus，采集相同的Targets即可实现基本的HA。同时由于Promethus高效的数据处理能力，单个Prometheus Server基本上能够应对大部分用户监控规模的需求。同时为了适应数据持久化的问题，Prometheus提供了remote_write和remote_read的特性，支持将数据存储到远端和从远端读取数据。通过将监控与数据分离，Prometheus能够更好地进行弹性扩展。关于存储用量规划：https://www.jianshu.com/p/934…更多：Prometheus存储机制详解https://yunlzheng.gitbook.io/…https://www.cnblogs.com/vovli...https://www.linuxidc.com/Linu...https://segmentfault.com/a/11...https://www.infoq.cn/article/…关于日志处理不建议将日志监控放在Prometheus中，这不是他的专长，还是使用ELK或EFK的方式处理日志信息竞品对比参考: https://toutiao.io/posts/fsjq…未来规划服务端度量指标元数据支持在度量指标类型和其他元数据仅仅在客户库和展示格式中使用，并不会在Prometheus服务中持久保留或者利用。将来我们计划充分利用这些元数据。第一步是在Prometheus服务的内存中聚合这些数据，并开放一些实验性的API来提供服务支持OpenMetricsOpenMetrics组开放了一个新的监控指标暴露标准，我们将支持这种标准：https://openmetrics.io/回溯时间序列允许将过去一段时间的数据发送到其他的监控系统HTTP服务支持TLS安全认证当前的Prometheus, Alertmanager和一些官方exporter，暴露服务时，都不支持tls认证，有很大的安全风险，现在的实现都是基于反向代理，之后将内置到组件中支持子查询当前的Promq不支持子查询，如max_over_time() of a rate())，后续将会支持支持生态建设Prometheus有很多的client库和exporter，我们将会对其进行规范和生态建设。在K8S中使用在之前的版本中，k8s默认以及推荐的监控体系是它自己的一套东西：Heapster + cAdvisor + Influxdb + Grafana，1.8后Heaspter由Metric-server替代。如果你部署了Dashboard，就能看到监控数据（来自heapster）k8s 自身的 HPA (Horizontal Pod Autoscaler)，默认从 Heapster 中获取数据进行自动伸缩1.8版本以后，K8S希望将核心监控指标收拢到metric api的形式，而自定义监控指标，由prometheus来实现，prometheus正式成为k8s推荐的监控实现方案。参考文档：https://www.ibm.com/developer…https://prometheus.io/docs/in...https://www.kancloud.cn/cdh08...https://yunlzheng.gitbook.io/…本文为容器监控实践系列文章，完整内容见：container-monitor-book ...

一.单独部署二进制安装各版本下载地址：https://prometheus.io/download/Docker运行运行命令：docker run –name prometheus -d -p 127.0.0.1:9090:9090 prom/prometheus暴露服务： http://localhost:9090/二.在K8S中部署如果在Kubernetes中部署Prometheus，可以使用prometheus in kubernetes，含exporter、grafana等组件。安装方式：kubectl apply \ –filename https://raw.githubusercontent.com/giantswarm/kubernetes-prometheus/master/manifests-all.yaml卸载方式：kubectl delete namespace monitoring该方式为大多数用户和云厂商使用的方式，可以基于Prometheus的服务发现：在annotation中设置prometheus.io/scrape为true，就可以把K8S的所有服务都加入到监控中，但在使用的过程中会有一些问题：1.如果增加了新的exporter，如nginx-exporter，需要修改prometheus配置并重启2.服务本身和监控配置没有分离3.监控集群多实例的状态不好管理4.报警配置也包含在prometheus的配置中，监控与报警没有分离，添加规则麻烦以上问题一般的处理方式为：在prometheus上加一个控制台，来动态配置target、报警规则，并向后端server发起修改、重启操作。同时有权限控制、日志审计、整体配置过期时间等功能。但如果使用了Prometheus Operator，就可以将以上大多数操作抽象为k8s中的资源提交、修改，减少上层封装的工作量。三.Prometheus Operator部署Prometheus-Operator是一套为了方便整合prometheus和kubernetes的开源方案，使用Prometheus-Operator可以非常简单的在kubernetes集群中部署Prometheus服务，用户能够使用简单的声明性配置来配置和管理Prometheus实例，这些配置将响应、创建、配置和管理Prometheus监控实例。官方地址：https://github.com/coreos/pro…目前状态：beta状态，还不够完整，但向后兼容。将成为趋势前置条件：要求k8s的版本>=1.8.0（应该是因为metric api和CRD支持的限制）Operator的核心思想是将Prometheus的部署与它监控的对象的配置分离，做到部署与监控对象的配置分离之后，就可以轻松实现动态配置。使用Operator部署了Prometheus之后就可以不用再管Prometheus Server了，以后如果要添加监控对象或者添加告警规则，只需要编写对应的ServiceMonitor和Prometheus资源就可以，不用再重启Prometheus服务，Operator会动态的观察配置的改动，并将其生成为对应的prometheus配置文件其中Operator可以部署、管理Prometheus Service四种CRD作用如下：Prometheus: 由 Operator 依据一个自定义资源kind: Prometheus类型中，所描述的内容而部署的 Prometheus Server 集群，可以将这个自定义资源看作是一种特别用来管理Prometheus Server的StatefulSets资源。ServiceMonitor: 一个Kubernetes自定义资源(和kind: Prometheus一样是CRD)，该资源描述了Prometheus Server的Target列表，Operator 会监听这个资源的变化来动态的更新Prometheus Server的Scrape targets并让prometheus server去reload配置(prometheus有对应reload的http接口/-/reload)。而该资源主要通过Selector来依据 Labels 选取对应的Service的endpoints，并让 Prometheus Server 通过 Service 进行拉取（拉）指标资料(也就是metrics信息)，metrics信息要在http的url输出符合metrics格式的信息，ServiceMonitor也可以定义目标的metrics的url。Alertmanager：Prometheus Operator 不只是提供 Prometheus Server 管理与部署，也包含了 AlertManager，并且一样通过一个 kind: Alertmanager 自定义资源来描述信息，再由 Operator 依据描述内容部署 Alertmanager 集群。PrometheusRule:对于Prometheus而言，在原生的管理方式上，我们需要手动创建Prometheus的告警文件，并且通过在Prometheus配置中声明式的加载。而在Prometheus Operator模式中，告警规则也编程一个通过Kubernetes API 声明式创建的一个资源.告警规则创建成功后，通过在Prometheus中使用想servicemonitor那样用ruleSelector通过label匹配选择需要关联的PrometheusRule即可。安装方式：创建命名空间：monitoring执行yaml文件：https://github.com/coreos/pro…prometheus的target列表： grafana的自带监控图列表：常见问题：因为要operator中要支持聚合api，在某些版本的集群上可能需要一些配置，如下：安装cfssl证书生成工具：http://www.cnblogs.com/xuling…生成证书cfssl gencert -ca=/etc/kubernetes/pki/ca.pem -ca-key=/etc/kubernetes/pki/ca-key.pem -config=/etc/kubernetes/pki/ca-config.json -profile=jpaas metrics-server-csr.json | cfssljson -bare metrics-server{ “CN”: “aggregator”, “host”: [], “key”: { “algo”: “rsa”, “size”: 2048 }, “names”: [ { “C”: “CN”, “ST”: “BeiJing”, “L”: “BeiJing”, “O”: “k8s”, “OU”: “cloudnative” } ]}配置master组件参数，以支持metric-servervim /etc/systemd/system/kube-apiserver.service–requestheader-client-ca-file=/etc/kubernetes/pki/ca.pem --requestheader-allowed-names=“aggregator” --requestheader-extra-headers-prefix=“X-Remote-Extra-” --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --proxy-client-cert-file=/etc/kubernetes/pki/metrics-server.pem --proxy-client-key-file=/etc/kubernetes/pki/metrics-server-key.pem --runtime-config=api/all=true --enable-aggregator-routing=true \systemctl daemon-reloadsystemctl restart kube-apiserver.servicesystemctl status kube-apiserver.servicevim /etc/systemd/system/kube-controller.service–horizontal-pod-autoscaler-use-rest-clients=truesystemctl daemon-reloadsystemctl restart kube-controller.servicesystemctl status kube-controller.service启动成功后，prometheus的target中，kubelet没有值，401报错vim /etc/systemd/system/kubelet.service–authentication-token-webhook=true–authorization-mode=Webhooksystemctl daemon-reloadsystemctl restart kubelet.service参考文档：https://github.com/coreos/pro…https://www.yinjk.cn/2018/09/...http://www.servicemesher.com/…本文为容器监控实践系列文章，完整内容见：container-monitor-book ...

目前，阿里云容器服务已经可以创建托管版Kubernetes集群了。相比于默认的Kubernetes集群，托管版本会主动替您运维一套高可用的Master组件，免去了默认版本集群中三个节点，从而节约所需的资金成本及维护时的人力成本。在容器服务控制台，我们为您提供了便捷使用的可视界面一步一步引导式地创建该类型集群。但当您需要反复创建托管版集群，大批量创建集群，或者您就是天生抗拒控制台手工操作的那一类人，可以了解并尝试使用一下Terraform了。Terraform是一款Infrastructure作为Code的工具，可以将云端资源代码化。关于Terraform的基本介绍本文不再赘述，有兴趣的同学可以参考“云生态下的基础架构资源管理利器Terraform”等云栖社区的优秀文章。目前我们一直在支持阿里云Terraform Provider，已经实现了阿里云上面绝大部分的云产品的对接。在2018年圣诞节来临之前，阿里云Terraform Provider已经发布v1.26.0版本，其中已经支持了创建托管版Kubernetes集群，下面我们来一起看下如何实现命令行快速部署一个这样的集群。创建托管版Kubernetes集群首先我们打开“阿里云Terraform Provider文档 - 托管版Kubernetes”的帮助文档，可以看到该资源资源提供的参数列表。参数分参入参数和出参属性。入参列表内包含了必填参数以及可选参数，例如name和name_prefix就是一对必填参写，但它们互斥，即不能同时填写。如果填了名，集群名就是名的值，如果填了name_prefix，集群名会以name_prefix开头自动生成一个。我们对照文档中的参数列表Argument Reference，先草拟出一个集群的描述，为了方便起见，我把填写每个参数的理由都注释在代码中。# 引入阿里云 Terraform Providerprovider “alicloud” { # 填入您的账号 Access Key access_key = “FOO” # 填入您的账号 Secret Key secret_key = “BAR” # 填入想创建的 Region region = “cn-hangzhou” # 可选参数，默认不填就使用最新版本 version = “v1.26.0”}# 必要的资源标识# alicloud_cs_managed_kubernetes 表明是托管版 Kubernetes 集群# k8s 代表该资源实例的名称resource “alicloud_cs_managed_kubernetes” “k8s” { # 集群名称，可以带中划线，一个账户内的集群名称不能相同 name = “test-managed-kubernetes” # 可以从 ECS 控制台上面查询到可用区信息，以及对应的 ECS 实例类型库存 # 以下代表 Worker 节点将部署在 cn-hangzhou-h 这个可用区，采用 ecs.c5.xlarge 这个机型。 availability_zone = “cn-hangzhou-h” worker_instance_types = [“ecs.c5.xlarge”] # 配置该集群 Worker 节点数为 2 个，该数字后续可以再扩容 worker_numbers = [2] # Worker 节点使用高效云盘 worker_disk_category = “cloud_efficiency” # 默认为 true，会在 VPC 内创建一个 Nat 网关用于 ECS 连上互联网 new_nat_gateway = true # 配置所有 ECS 的默认 Root 密码，此处也可以用密钥对 key_name 代替，但需要提前创建 password = “Test12345” # Kubernetes 集群内所有 Pod 使用的子网网段，不能与 service_cidr 和 ECS 所在网段冲突 # 默认创建的 VPC 是 192.168.0.0/16 这个网段内的，所以 pod_cidr 和 service_cidr 可以使用 172 网段 # 请参考 VPC下 Kubernetes 的网络地址段规划 pod_cidr = “172.20.0.0/16” service_cidr = “172.21.0.0/20” # 安装云监控插件 install_cloud_monitor = true}我们可以将以上的配置保存为一个main.tf描述文件，在该文件的当前目录下执行terraform init和terraform apply。xh4n3@xh4n3:/ops/terraform-example% terraform init –get-plugins=true -upgradeInitializing provider plugins…- Checking for available provider plugins on https://releases.hashicorp.com…- Downloading plugin for provider “alicloud” (1.26.0)…Terraform has been successfully initialized!You may now begin working with Terraform. Try running “terraform plan” to seeany changes that are required for your infrastructure. All Terraform commandsshould now work.xh4n3@xh4n3:/ops/terraform-example% terraform applyAn execution plan has been generated and is shown below.Resource actions are indicated with the following symbols: + createTerraform will perform the following actions: + alicloud_cs_managed_kubernetes.k8s id: <computed> availability_zone: “cn-hangzhou-h” install_cloud_monitor: “true” name: “test-managed-kubernetes” name_prefix: “Terraform-Creation” new_nat_gateway: “true” password: <sensitive> pod_cidr: “172.20.0.0/16” security_group_id: <computed> service_cidr: “172.21.0.0/20” vpc_id: <computed> vswitch_ids.#: <computed> worker_disk_category: “cloud_efficiency” worker_disk_size: “40” worker_instance_charge_type: “PostPaid” worker_instance_types.#: “1” worker_instance_types.0: “ecs.c5.xlarge” worker_nodes.#: <computed> worker_numbers.#: “1” worker_numbers.0: “2"Plan: 1 to add, 0 to change, 0 to destroy.Do you want to perform these actions? Terraform will perform the actions described above. Only ‘yes’ will be accepted to approve. Enter a value:从上述日志中可以看到，terraform init会把我们用到的提供者插件下载好，terraform apply会根据我们的main.tf描述文件计算出需要执行的操作，上述显示将会创建一个alicloud_cs_managed_kubernetes.k8s的资源，需要我们输入是来确认创建。确认创建后，创建大约会耗时五分钟，terraform会输出类似下面的日志。# 以上省略Do you want to perform these actions? Terraform will perform the actions described above. Only ‘yes’ will be accepted to approve. Enter a value: yesalicloud_cs_managed_kubernetes.k8s: Creating… availability_zone: "” => “cn-hangzhou-h” install_cloud_monitor: "" => “true” name: "" => “test-managed-kubernetes” name_prefix: "" => “Terraform-Creation” new_nat_gateway: "" => “true” password: “<sensitive>” => “<sensitive>” pod_cidr: "" => “172.20.0.0/16” security_group_id: "" => “<computed>” service_cidr: "" => “172.21.0.0/20” vpc_id: "" => “<computed>” vswitch_ids.#: "" => “<computed>” worker_disk_category: "" => “cloud_efficiency” worker_disk_size: "" => “40” worker_instance_charge_type: "" => “PostPaid” worker_instance_types.#: "" => “1” worker_instance_types.0: "" => “ecs.c5.xlarge” worker_nodes.#: "" => “<computed>” worker_numbers.#: "" => “1” worker_numbers.0: "" => “2"alicloud_cs_managed_kubernetes.k8s: Still creating… (10s elapsed)alicloud_cs_managed_kubernetes.k8s: Still creating… (20s elapsed)alicloud_cs_managed_kubernetes.k8s: Still creating… (30s elapsed)# 以上省略alicloud_cs_managed_kubernetes.k8s: Creation complete after 6m5s (ID: cc54df7d990a24ed18c1e0ebacd36418c)Apply complete! Resources: 1 added, 0 changed, 0 destroyed.当出现申请完成！资源：1添加字样的时候，集群已经成功创建，此时我们也可以登录控制台后在控集群列表中看到集群。修改托管版Kubernetes集群在Terraform Provider中，我们提供了一部分参数的修改能力，一般情况下，所有非Force New Resouce（强制新建资源）的参数都可以被修改。下面我们修改部分参数，注释内容为更新的项目。provider “alicloud” { access_key = “FOO” secret_key = “BAR” region = “cn-hangzhou” version = “v1.26.0”}resource “alicloud_cs_managed_kubernetes” “k8s” { # 更换集群的名称为 test-managed-kubernetes-updated name = “test-managed-kubernetes-updated” availability_zone = “cn-hangzhou-h” worker_instance_types = [“ecs.c5.xlarge”] # 修改 worker_numbers 为 3，可以扩容一个 worker 节点 worker_numbers = [3] worker_disk_category = “cloud_efficiency” new_nat_gateway = true password = “Test12345” pod_cidr = “172.20.0.0/16” service_cidr = “172.21.0.0/20” install_cloud_monitor = true # 导出集群的连接配置文件到 /tmp 目录 kube_config = “/tmp/config” # 导出集群的证书相关文件到 /tmp 目录，下同 client_cert = “/tmp/client-cert.pem” client_key = “/tmp/client-key.pem” cluster_ca_cert = “/tmp/cluster-ca-cert.pem”}同创建集群一样，修改集群时使用的命令也是terraform apply。执行后我们得到以下日志输出，输入是并回车，我们就可以把该集群的名称改为test-managed-kubernetes-updated，worker节点扩容至3节点，同时将导出证书和连接文件到本机的/ tmp目录。xh4n3@xh4n3:~/ops/terraform-example% terraform applyalicloud_cs_managed_kubernetes.k8s: Refreshing state… (ID: cc54df7d990a24ed18c1e0ebacd36418c)An execution plan has been generated and is shown below.Resource actions are indicated with the following symbols: ~ update in-placeTerraform will perform the following actions: ~ alicloud_cs_managed_kubernetes.k8s client_cert: "” => “/tmp/client-cert.pem” client_key: "" => “/tmp/client-key.pem” cluster_ca_cert: "" => “/tmp/cluster-ca-cert.pem” kube_config: "" => “/tmp/config” name: “test-managed-kubernetes” => “test-managed-kubernetes-updated” worker_numbers.0: “2” => “3"Plan: 0 to add, 1 to change, 0 to destroy.Do you want to perform these actions? Terraform will perform the actions described above. Only ‘yes’ will be accepted to approve. Enter a value: yesalicloud_cs_managed_kubernetes.k8s: Modifying… (ID: cc54df7d990a24ed18c1e0ebacd36418c) client_cert: "” => “/tmp/client-cert.pem” client_key: "" => “/tmp/client-key.pem” cluster_ca_cert: "" => “/tmp/cluster-ca-cert.pem” kube_config: "" => “/tmp/config” name: “test-managed-kubernetes” => “test-managed-kubernetes-updated” worker_numbers.0: “2” => “3"alicloud_cs_managed_kubernetes.k8s: Still modifying… (ID: cc54df7d990a24ed18c1e0ebacd36418c, 10s elapsed)alicloud_cs_managed_kubernetes.k8s: Still modifying… (ID: cc54df7d990a24ed18c1e0ebacd36418c, 20s elapsed)alicloud_cs_managed_kubernetes.k8s: Still modifying… (ID: cc54df7d990a24ed18c1e0ebacd36418c, 30s elapsed)# 以上省略alicloud_cs_managed_kubernetes.k8s: Modifications complete after 4m4s (ID: cc54df7d990a24ed18c1e0ebacd36418c)Apply complete! Resources: 0 added, 1 changed, 0 destroyed.Terraform适用于运行成功后，控制台中显示的集群信息已经表明现在集群已经变成了我们期望的状态。在本机上，我们也通过导出的连接文件，用kubectl连接到集群。附录控制台创建托管版Kubernetes集群帮助文档https://help.aliyun.com/document_detail/95108.html云生态下的基础架构资源管理利器Terraform https://yq.aliyun.com/articles/215592阿里云Terraform提供者代码库https://github.com/terraform-providers/terraform-provider-alicloud阿里云Terraform提供商文档https://www.terraform.io/docs/providers/alicloud/index.html阿里云Terraform Provider文档 -托管版Kubernetes https://www.terraform.io/docs/providers/alicloud/r/cs_managed_kubernetes.htmlVPC下Kubernetes的网络地址段规划https://help.aliyun.com/document_detail/86500.htmlTerraform部署容器服务Kubernetes集群及WordPress的应用https://yq.aliyun.com/articles/641627本文作者：予栖.阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...