企业级云原生白皮书项目实战.pdf

企业级云原生白皮书项目实战目录CATALOG第一章 引言 3.1 创建集群3.1.1 运行时runtime选择 3.1.2 集群版本选择3.1.3 网络插件选择3.1.4 集群网络规划3.1.5 网络代理模式选择3.1.6 节点池配置3.1.7 组件配置1111121213131414第三章 容器2.1 云原生发展历史及现状 2.2 云原生的发展及现状0203第二章 云原生发展历史及现状636363644.1 消息队列RocketMQ&Kafka4.1.1 消息队列RocketMQ版概述4.1.2 消息队列RocketMQ版的优势4.1.3 消息队列RocketMQ版最佳实践 第四章 云原生中间件3.2 业务部署3.2.1 ACR容器镜像服务 3.2.2 优雅更新3.2.3 健康检查3.2.4 QoS设置3.2.5 滚动更新3.2.6 亲和性&污点容忍3.2.7 CPU/内存3.2.8 Scheduler调度3.2.9 nginxcontroller最佳调度部署实践3.2.10 服务发现3.2.11 伸缩与优化3.3 访问链路3.3.1 入方向 3.3.2 出方向151528323336384043464955575759951031131291301371411411461521581601621661681691691751882022022025.1.2 创建实例5.1.3 变更实例5.1.4 集群监控告警5.1.5 日志查询5.1.6 数据备份恢复5.1.7 数据同步5.2 云原生大数据计算服务 MaxCompute5.2.1 开始使用5.2.2 使用安全5.2.3 数据上云5.2.4 SQL开发参考5.2.5 多引擎开发参考5.2.6 数据开发及任务调度5.2.7 运维5.2.8 小结5.3 实时计算Flink版5.3.1 开始使用5.3.2 Flink任务开发相关5.3.3 任务性能5.4 Quick BI 数据可视化分析平台5.4.1 背景5.4.2 产品介绍4.1.4 消息队列Kafka版概述4.1.5 消息队列Kafka版的优势4.1.6 消息队列Kafka版最佳实践4.2 微服务引擎MSE4.2.1 MSE概述4.2.2 MSE功能介绍4.2.3 微服务概述4.2.4 MSE最佳实践4.3 可观测产品ARMS4.3.1 ARMS概述4.3.1 ARMS优势4.3.1 ARMS最佳实践4.4 日志服务SLS4.4.1 阿里云日志服务产品介绍4.4.2 产品功能4.4.3 开源日志方案比对4.4.4 最佳实践676970737474747579797981868686888994945.1 检索分析服务 Elasticsearch版5.1.1 产品介绍第五章 大数据5.4.3 版本选择5.4.4 开始使用5.4.5 功能进阶2022062176.1 vivo AI计算平台的ACK混合云实践6.1.1 背景6.1.2 方案6.1.3 落地实践6.1.4 落地效果6.1.5 未来展望6.2 全面容器化之后，来电科技如何实现微服务治理6.2.1 缘起6.2.2 初见6.2.3 落地6.2.4 未来6.3 基于 RocketMQ 的基金数字化陪伴体系的架构实践6.3.1 行业背景6.3.2 RocketMQ 在陪伴体系中的应用6.3.3 RocketMQ 事务消息的金融应用场景6.3.4 未来规划224224225226228228229229232234238239239240242248第六章 云原生最佳实践7.1 多云融合7.2 无服务器7.3 低代码、无代码7.4 场景化与多样的云原生应用7.5 场景化的解决方案249249250250250第七章 云原生未来发展趋势第一章 引言随着数字化转型深入社会的千行百业，随着近10年云计算的高速发展，以容器化为代表的云原生技术作为云计算的新界面加速云计算发展的同时，也势必将成为企业数字化转型升级成功的关键。云原生概念定义了一种全新的软件架构开发方法论，旨在利用云计算在公有云、私有云或混合云环境中，构建弹性、健壮、可扩展的业务应用。典型的云原生技术代表有：容器、微服务、serverless、Service Mesh 技术、云原生中间件等。相应地，阿里云在云上提供了丰富的云原生技术产品，例如：容器服务 ACK、容器镜像服务 ACR、服务网格 ASM、消息队列RocketMQ版等。这些云产品将极大助力企业云原生架构转型的企业，更加聚焦于业务本身并借助云原生技术与产品实现更多业务创新，有效提升企业增长效率，爆发出前所未有的生产力与创造力。第二章 云原生发展历史及现状一切技术和架构的出现都是为了解决一个问题：提高效率，降低成本。如今越来越多的应用正在迁移到“云”上，如我们生活中接触的各种“云盘”存储。实际上，“云”并不新潮，已经持续了超过10年，并还在不断扩大到所有领域。可预见的事：下一个10年中，几乎所有的应用都会部署到云端，而它们中的大部分都将直接通过移动设备，为我们提供各种各样的服务。传统的应用正在变得越来越复杂：需要支持更多的用户，需要更强的计算能力，需要更加稳定安全等等，而为了支撑这些不断增长的需求，企业不得不去购买各类硬件设备（服务器，存储，带宽等等）和软件（数据库，中间件等等），另外还需要组建一个完整的运维团队来支持这些设备或软件的正常运作，这些维护工作就包括安装、配置、测试、运行、升级以及保证系统的安全等。可以发现支持这些应用的开销变得非常巨大，而且它们的费用会随着应用的数量或规模的增加而不断提高。这也是为什么即使是在那些拥有很出色IT部门的大企业中，那些用户仍在不断抱怨他们所使用的系统难以满足他们的需求。而对于那些中小规模的企业，甚至个人创业者来说，创造软件产品的运维成本就更加难以承受了。所以在目前的大环境下，软件开发商不使用云基本上无法在竞争中取得优势。解决上述问题的方法就是使用云原生，将应用部署到云上，可以不用再关注令人头疼的软硬件问题，这些问题将由云服务提供商的专业团队解决。阿里云致力于用户在部署应用时利用云服务就像使用水电煤一样快捷便利。大型赛事上云，作为一种新兴发展领域，顺应了时代发展，也见证了时代进步。在第八章节，我们展望未来丰富多彩的云上世界，脚踏实地走好技术的发展创新之路。01 企业级云原生白皮书项目实战企业级云原生白皮书项目实战 02企业级云原生白皮书项目实战2.1云原生的诞生及定义根据公开发表的文献来看，云原生一词最早可追溯至2012年4月，Andrikopou-los 等人在发表的论文中，在该论文中只提出了云原生应用工程的解决方案并描述了应用程序和中间件在云环境中的良好运行状态，但并未对云原生这一概念作出具体的定义。在本节中，通过对云计算及其上应用的特点进行分析，结合阿里自身的云原生技术和上云实践，尝试给出云原生的定义。云原生从字面上来拆分，可以分成云+原生，云与本地是相对的，传统应用运行在本地服务器上，云原生应用运行在云上。而原生则指为适配云的特性而设计的一套技术体系。我们从这云和原生两方面分别展开介绍。云即云计算，是一种模型，实现对可配置计算资源（如网络、服务器、存储、应用和服务）的随时随地按需使用。云计算模型通常满足以下五个特点：1.按需自助使用：用户可以根据需要，配置相应的计算能力，并且无需服务提供商的人工介入。2.随时随地接入：用户可以方便快捷地使用各种终端通过网络接入到云计算平台中。3.可池化的资源：服务商计算资源汇集在一个“资源池”中，使用多租户模型为消费者提供服务，根据消费者的需求动态分配不同的物理和虚拟资源，在消费者使用完后，计算资源重新回到“资源池“中。4.弹性伸缩：资源可以灵活地供应和释放，根据需求的变化，可以自动地、快速地扩展和收缩。从消费者的视角来看，可以在任何时间使用任意数量的资源。5.可观测服务：云系统可以监视、控制和报告资源使用情况，为所使用服务的提供者和使用者提供透明度。支持存储、带宽、处理能力等其他适合于服务类型的抽象度量。云计算的服务模型可分为以下三种：1.软件即服务（SaaS）：服务商提供基于云基础设施的应用程序并负责应用程序的升级维护等工作。使用者不管理或控制底层云基础设施，包括网络、服务器、操作系统和存储，只能管理有限的特定于用户的应用程序配置。2.平台即服务（PaaS）：服务商提供基于云基础设施的支持应用程序开发、测试、交付等所需的环境。使用者不管理或控制底层云基础设施，包括网络、服务器、操作系统和存储，但可以控制已部署的应用程序，还可以控制应用程序托管环境的配置。3.基础设施即服务（IaaS）：服务商提供计算、存储、网络等基本的计算资源。使用者可以在这些资源中部署和运行任意软件，包括操作系统、中间件、应用程序。使用者不管理或控制底层云基础设施，但可以控制操作系统、存储和部署的应用程序；以及有限的网络组件（例如，主机防火墙）。从以上云计算服务的特点和服务模型中可以看出，区别于传统的本地服务器，云服务器具有更快的接入效率，更高的弹性能力以及更强的容灾能力。而传统的应用设计模式无法发挥出云服务器的全部优势，因此需要设计一套适应和满足云特性的方法论和技术体系，软件的设计架构、开发方式、部署维护上均做出改变来满足云化，使得软件的开发和构建能够依托于云计算。云原生应用应具有如下的要点：1.微服务：每个微服务都有一个自治的生命周期，可以独立发展和频繁部署。客户可以只更新软件的一部分，快速部署新功能从而降低破坏整个系统的风险。每个微服务都可以独立扩展，无需将整个应用程序扩展为一个单元，而是仅扩展那些需要更多处理能力，以满足所需性能级别和服务级别协议的服务。细粒度扩展可更好地控制系统，并有助于在扩展系统的某些部分时，无需扩展所有部分来降低总体成本。2.容器化：容器提供可移植性并保证跨环境的一致性。通过将所有内容封装到一个包中，可以将微服务及其依赖项与底层基础设施隔离开来。可以在托管 Docker 运行时引擎的任何环境中部署容器。容器化工作负载还消除了使用框架、软件库和运行时引擎预先配置每个环境的复杂度。通过共享底层操作系统和主机资源，容器的占用03 企业级云原生白皮书项目实战企业级云原生白皮书项目实战 04企业级云原生白皮书项目实战Kubernetes、DevOps和CI/CD等技术的开始流行。这些技术也是作为云原生技术体系中的关键技术，支撑着云原生应用的部署、运行、测试、升级。因此理解这些技术的原理对于了解云原生的发展是必要的，下面介绍一下这些技术的基本原理以及互相之间的关联关系。空间比完整的虚拟机小得多。当使用许多独立运行的容器进行大规模操作时，还需要使用Kubernetes编排容器；Kubernetes 是为生产环境而设计的容器调度管理系统，对于负载均衡、服务发现、高可用、滚动升级、自动伸缩等容器云平台的功能要求有原生支持，目前K8S已经是云原生容器管理的事实标准。3.DevOps：强调的是以开发运维的视角，去构建一套高效完备的CI/CD流程，并通过自动化构建工具及发布系统，来实现软件生命周期的管理。从而使得普通开发人员，能够更快、更频繁地交付更加稳定的软件代码。DevOps可以视作一组实践，旨在缩短将变更应用到生产环境的时间，保障在代码和交付机制方面的软件质量。持续交付(CD)是一种DevOps实践，可以通过自动化机制按需将软件部署到任何环境。随着可部署单元数量的增加，CD是微服务中必不可少的一环。基于以上的讨论，可以对云原生应用做出定义：云原生应用是一个分布式、弹性和可水平扩展的系统，由多个状态相互隔离的、可独立部署的服务组成。应用程序依据云平台的特点进行设计的，将大量非功能特性（弹性、安全、可用性、可观测性等）交由云设施接管，开发者只需关注实际业务的开发。2.2云原生的发展及现状云原生大数据计算服务 MaxCompute 是适用于数据分析场景的企业级SaaS（Software as a Service）模式云数据仓库，以Serverless架构提供快速、全托管的在线数据仓库服务，消除了传统数据平台在资源扩展性和弹性方面的限制，最小化用户运维投入，使用户可以经济并高效地分析处理海量数据。MaxCompute(原名ODPS)是一种快速、完全托管的TB/PB级数据仓库解决方案。MaxCompute向用户提供了完善的数据导入方案以及多种经典的分布式计算模型，能够更快速地解决用户海量数据计算问题，有效降低企业成本，并保障数据安全。从图 2.1中可以看出，云原生在2016年后开始变得火热起来，这得益于微服务、(a)cloud-native google搜索趋势图图 2.1 google搜索趋势图(b)微服务/DevOps/K8s/CICD google搜索趋势对比图05 企业级云原生白皮书项目实战企业级云原生白皮书项目实战 06企业级云原生白皮书项目实战根据谷歌的趋势，DevOps和微服务都被认为是增长的概念，且它们的增长趋势也相对一致（见图 2.1b）。微服务体系结构是一种原生云体系结构，旨在将软件系统实现为一组小型服务，每个服务可独立部署在可能不同的平台和技术堆栈上并独立运行，同时通过RESTful或基于rpc的ap等轻量级机制进行通信。在这种设置中，每个服务都是一个业务功能，可以利用各种编程语言和数据存储，并由一个小型团队开发。将整体架构迁移到微服务带来许多好处，包括但不限于适应技术变化的灵活性，以避免技术锁定，更重要的是，减少了上市时间，并围绕服务更好地构建开发团队。DevOps旨在缩短将变更应用到系统和将变更转移到生产环境之间的时间，且坚持在代码和交付机制方面保持软件质量，将其作为开发过程中的关键元素之一。任何实现上述目标的技术都被认为是DevOps实践。CI/CD是一种典型的DevOps实践，CI指持续集成，强调开发人员提交了新代码之后，立刻自动的进行构建、（单元）测试。根据测试结果，可以确定新代码和原有代码能否正确地集成在一起；CD指持续交付，在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的类生产环境（production-like environments）中。交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。DevOps与微服务是相辅相成的，DevOps致力于持续监控、测试并部署软件，微服务架构的本质则在于模块化属性，即通过小型单一服务执行单一功能。从这个角度来看，模块化软件很容易适应DevOps结构，允许开发者轻松实现增量式变更。单一微服务天然更易于升级、构建、测试、部署与监控，这正是DevOps希望达成的关键目标。因此，只要项目采用基于微服务的结构，DevOps就能显著加快交付速度并提升交付质量。此外，DevOps实践还要求将大问题拆分成多个较小的部分，再由团队逐一加以解决。从这个角度看，微服务更加与DevOps息息相关，二者同样要求小型团队对企业服务做出功能性变更，且微服务高度强调在低复杂度环境下由增强型小规模团队完成实施与协作。在低复杂度环境的支持下，得以建立持续交付管道并保持稳定的部署流程。同样的，容器化微服务同样可以加快部署与内置功能实现速度，确保新服务能够立即在任意系统上运行。Kubernetes是一个工业级的容器编排平台，该系统管理所有基于微服务的应用程序。Kubernetes中调度的基本单元是pod，它是一组一个或多个docker风格的容器，以及由该pod中的容器共享的一组资源。Kubernetes有如下几个核心功能：服务的发现与负载；容器的自动装箱与调度；容器的自动化恢复；应用的发布与回滚；支持水平伸缩能力。云原生的微服务架构正是基于以上技术，在微服务的基础上，以容器为载体，Kubernetes作为“操作系统”，利用高度可扩展、灵活和分布式的云特性，在持续交付环境中生产以客户为中心的软件产品。云原生架构的显着特点是它允许抽象基础架构的所有层，例如数据库、网络、服务器、操作系统、安全性等，能够使用脚本独立地自动化和管理每一层。同时，可以使用代码立即启动所需的基础架构。因此，开发人员可以专注于向软件添加功能和编排基础架构，而不必担心平台、操作系统或运行时环境。!图 2.2云原生架构演进07 企业级云原生白皮书项目实战企业级云原生白皮书项目实战 08企业级云原生白皮书项目实战如图 2.2云原生架构的演进过程可以看作是基础能力的逐渐下沉以及业务代码的纯粹度提升。微服务架构模式是云原生应用的标准架构模式，通过微服务架构，将一个庞大的应用拆分为不同的模块，解耦后，各个模块独立自治，单独维护，以接口契约定义彼此业务关系，以标准协议确保彼此的互联互通，提高了系统的整体迭代速度，也能有效降低单个庞大系统的风险。通过服务化架构，把代码模块关系和部署关系进行分离，每个接口可以部署不同数量的实例，单独扩缩容，从而使得整体的部署更经济。此外，由于在进程级实现了模块的分离，每个接口都可以单独升级，从而提升了整体的迭代效率。但是也需要注意到，服务拆分导致要维护的模块数增多，如果缺乏服务的自动化能力和治理能力，会让模块管理和组织技能不匹配，反而导致开发和运维效率的降低。Mesh架构模式主要是采用sidecar模式，将业务逻辑和辅助业务的其他内容分离，让业务更专注于业务部分，非业务能力部分下沉，这样业务逻辑将不会受非业务逻辑的影响，mesh部分即可实现独立更新扩展。具体地，Mesh 化架构是把中间件框架（比如 RPC、缓存、异步消息等）从业务进程中分离，让中间件SDK 与业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件也对业务透明。分离后业务进程只保留客户端部分代码，客户端的只与Mesh进程通信，原来需要在SDK中处理的流程和逻辑则由Mesh进程完成。Serverless模式，从中文含义上翻译为“无服务”，但并不是没有服务器了，而是服务器被云管理了，不论是在开发测试还是部署上，都无需感知服务器的存在，唯一需要感知的只有业务逻辑，非业务逻辑的代码，存储，网络，部署都不需要感知，这些能力将会全部下层到基础设施层，是一种比较理想化的云原生架构模式。目前Serverless并不适用于所有类型的应用，需要使用者决策应用类型是否适用于Serverless运算。在决策过程中可以考虑以下几方面：1.应用是否有状态。对于有状态的应用，Serverless在调度时不会对应用的状态做同步，因此在调度时会导致上下文的丢失；!2.是否为I/O密集型应用。对于需要频繁的外部I/O的应用，通常因为I/O负担繁重，导致时延大而不适用于Serverless；3.应用是否事件驱动。Serverless适用于应对突发流量或服务使用量不可预测的应用，因为Serverless应用在不运行时不收费；4.业务是否需要快速开发迭代。Serverless无需提前申请资源，因此可以加快业务上线的速度。!09 企业级云原生白皮书项目实战企业级云原生白皮书项目实战 10企业级云原生白皮书项目实战与Docker容器一样的用户体验，例如日志、监控、弹性等下面给出详细的对比，不关注的同学直接跳到下一个章节即可,参考官网。-容器运行时实现和使用限制的对比-运行时部署结构对比3.1.2 集群版本选择目前云上支持的kubernetes最新版本为1.22.3，同时可选的版本为1.20.11不同版本支持的特性以及组件版本有所不同，如果特殊要求，建议选择最新版本版本发布说明可参考官网。3.1.3 网络插件选择 注意：networkpolicy均不建议开启-flannel 网络插件每个节点具备独立的podcidr，依赖ccm 更新podcidr到vpc路由表默认alloc模式 不建议使用 vxlan假如必须修改为vxlan，则需要删除flannel pod重拉，同时mtu会有所变化，如不注意可能导致丢包依赖vpc路由表额度，存在大规模扩容节点时路由表额度不足导致路由添加失败-terway-eniip 网络插件-推荐使用terway-eniip 单网卡可以绑定多个vpcip，pod分配的ip可与vpc内的其他资源直接通讯，不会受限路由表额度，不同的访问路径依赖veth策略路由实现为避免串流 ingress的svc首选eni作为backendpod数量受限于实例规格可绑定的eni网卡数量，乘以单网卡可分配的ip数量第三章 容器引言云原生已经成为未来的技术趋势，而k8s更是有成为基础设施的潜质，目前阿里云ACK集群数量及用户逐年翻倍增长，为了帮助更多的用户快速适应ACK，AES容器专家服务团队提炼近3年云上用户各种场景使用k8s遇到的各种问题，以期可以帮助用户少走弯路。我们的最佳实践将从集群创建，业务部署，访问链路，等为用户提供相关的建议，话不多说，我们直接开始吧 3.1 创建集群 我们从创建pro托管集群开始，创建集群的时候，我们首要关注的可能是哪些因素？3.1.1 运行时runtime选择目前容器服务Kubernetes版（ACK）支持Containerd、Docker、安全沙箱三种运行时。-Docker：docker 作为k8s最早时期的运行时唯一选择，由于各种各样的原因，dockershim即将在k8s后续版本中弃用-Containerd：containerd是大势所趋，同时调用链更短。-安全沙箱：安全沙箱特别适合于不可信应用隔离、故障隔离、性能隔离、多用户间负载隔离等场景，在提升安全性的同时，对性能影响非常小，并且具备与11 企业级云原生白皮书项目实战企业级云原生白皮书项目实战 12企业级云原生白皮书项目实战-terway-eni 独享网卡ip可以一个pod独占一个eni+ip，需要白名单开启，该模式没有必要的场景无需使用，目前terway-eniip模式支持pod直接绑定eip-terway-ipvlan 基于terway+ebpf实现的ipvlan 在内核转发路径上更短，Linux在4.2以上的内核中支持了ipvlan的虚拟网络，可以实现单个网卡虚拟出来多个子网卡用不同的IP地址，而Terway便利用了这种虚拟网络类型，将弹性网卡的辅助IP绑定到IPVlan的子网卡上来打通网络，使用这种模式使ENI多IP的网络结构足够简单，性能也相对veth策略路由较好。3.1.4 集群网络规划 基于优选terway-eniip的模式 vpc&交换机的网段要足够大-pod cidr 选择pod交换机即可，同vpc不同交换机也是互通的，注意安全组设置，以及交换机的子网掩码大小-service cidr可以设置为较小的内网段 需要提前规划好集群内有多少服务 预备后期多集群打通内网，vpc打通之类的场景路由学习3.1.5 网络代理模式选择-iptables 如果选择使用iptables作为网络代理模式，那么当集群规模较大时会存在更新延迟，负载不均衡,无法调整均衡算法等问题-ipvs+terway-eniip强烈推荐使用ipvs+terway-eni+alinux2模式，是目前云上的最优解，如果使用了低版本的内核存在以下问题mode_reuse 0 1 低版本内核有丢包及转发问题，建议使用alinux2的内核版本，修复了mode_reuse问题flannel+ipvs+nodeport 高并发，短连接端口复用时有串流的概率，避免混访ipvs+terway-eniip 强烈推荐，关键业务可使用eni作为slb的后端，即可避免nodeport串流问题3.1.6 节点池配置-建议使用6代及以上实例较老的规格与新的规格存在性能差异，不建议混部，同时存量的老规格节点，可以通过新建节点池的方式逐步替换掉，以达到性能最佳的状态。-建议使用alinux2系统（4.19内核）很多用户依然在使用较低版本的内核，我们强烈建议使用alinux2的系统，使用较低版本的内核可能会遇到以下问题：低版本内核如3.x 存在如systemd泄漏，cgroup泄漏等低版本内核使用ipvs mode_reuse 模式存在丢包或转发请求给已下线podcpu-policy 如有cpu亲和性需求使用static，整核分配减少上下文切换，充分发挥CPU处理能力3.1.7 组件配置-Ingress必选Ingress作为集群入口是集群不可或缺的重要环节，使用ingress需要注意以下方面：13 企业级云原生白皮书项目实战企业级云原生白皮书项目实战 14企业级云原生白皮书项目实战拉取镜像，一方面可以获得内网连接的高稳定，高速度，低延迟的带宽，另一方也可以避免NAT GW 可能产生的公网流量的费用。比如下面的registry-- 就算是阿里云组件的内网拉取地址，对于公网方式一般为-hongkong.ali- bucket的ID，它的命名一般是-registry，以及访问控制中的相关相关信息，此处是用于ACR内网拉去时的必要配置之一。使用xff获取真实ip集群内不建议使用域名解析到ingress controller svc的外部ip的ingress域名进行访问，建议使用svcname访问-nodelocal dnscache优先在性能问题分析的时候经常碰到因为解析导致的异常，可以使用dnscache组件来优化，使用dnscache组件，以下注意事项：安装后需要在namespace/pod内开启注入才能生效alpine基础镜像存在musllibc多个nameserver并发请求，可能会导致cache失效，请求直达coredns短连接程序必备-存储组件的选择CSI自研存储插件强烈推荐，支持如下存储：nas，云盘，cnfs；flexvolume 版本滞后不推荐其他组件按需勾选或默认配置安装3.2 业务部署3.2.1 ACR容器镜像服务要使用内网地址拉去镜像，且无需自行搭建及运维的镜像仓库，必然需要使用ACR。ACR分为个人版和企业版，他们的具体区别如下（详情请见https:/help.ali- NAT 网关的SNAT方式访问外网（如下图）。建议使用ACR+ACK 方式部署镜像拉去，并使用ACR的内网地址进行图：ACK集群拉取ACR镜像网络架构图：pod镜像地址示意图15 企业级云原生白皮书项目实战企业级云原生白皮书项目实战 16企业级云原生白皮书项目实战使用企业版ACR拉取镜像过程中会涉及Registry、AUthorization Service和OSS 三个部分，下图展示了阿里云容器镜像服务的推拉的整个交互过程。当出现推拉问题时候，所涉及的方面必然是这三部分中的某一个交互环节。1.向registry发起镜像推拉请求。2.registry返回401 Unauthorized的HTTP返回值，并且携带鉴权服务(authorization service)的地址，需要客户端去做鉴权。3.客户端向鉴权服务发起请求以获取一个授权token.。4.鉴权服务返回一个携带权限的token给客户端。5.客户端将token嵌入HTTP Authorization header头中，再次向registry发起请求。6.registry验证token权限无问题后，在镜像推送过程中，客户端可以向registry推送镜像数据；在镜像拉取过程中，registry会向客户端颁发有时效的OSS url地址。7.客户端通过OSS url地址拉取保存在OSS中的镜像数据。图：企业版ACR镜像与OSS对应示意图图：企业版ACR访问控制示意图图：企业版ACR拉取鉴权示意图17 企业级云原生白皮书项目实战企业级云原生白皮书项目实战 18企业级云原生白皮书项目实战OSS bucket错误设置导致推送失败某客户反馈推送镜像失败，推送报错是TLS handshake timeout。通过前面几个镜像的Already exists，可以判断此时已经过了login和鉴权服务，是连接oss时候出现了问题。通过查看连接地址的TLS信息，可以发现连接地址的证书的CN有问题，最后确定是由于在oss侧单独设置了ACL规则导致的。docker login 登陆Tips阿里云的账户名是中文的能登陆吗？亲测可以登陆，登录失败除了排查下面的原因，还要排查用户使用的远程访问的客户端编码。用户没有填写登陆域名，这样用户登陆的是Docker Hub，没有使用阿里云容器镜像服务docker loginUsername:dockerPassword:Email:Error response from daemon:Wrong login/password,please try again用户使用了sudo，Linux提示输入的是sudo的密码。特点是sudo的密码错误会重新尝试三次。sudo docker login -sudo password for hyzhou:Sorry,try again.sudo password for hyzhou:Sorry,try again.sudo password for hyzhou:Sorry,try again.sudo:3 incorrect password attempts用户密码使用错误，登陆Registry的密码是容器镜像服务控制台独立设置的。不是阿里云账户的登陆密码。Registry的登录密码是在容器镜像服务控制台上设置与修改的https:/ 进行登录。企业别名未设置时为AliyunUID。图：拉取失败图：连接证书有误19 企业级云原生白皮书项目实战企业级云原生白皮书项目实战 20企业级云原生白皮书项目实战注意企业别名是没有.字符的。区分一下企业别名和域别名的概念。https:/ Daemon中设置全局代理。docker pull/push用户拉取的是否是容器镜像服务的镜像。如果不是用户自己检查一下登陆权限等问题docker pull notme/asdas:latest Using default tag:latest you are not autho-rized to perform this operation:server returned 401.用户拉取的镜像是自己的私有镜像，这时需要先进行登录再拉取。a.确认用户镜像的所在地域。在A地域的镜像只能使用A地域的服务域名拉取。例如杭州的镜像不能使用 - 拉取。b.确认用户是否登录Registry。使用 cat/.docker/config.json 可以看到用户登陆的所有域名列表。c.查看里面是否包含您想要下载镜像的Registry域名。如果没有的话，需要先进行登录操作。如果显示已经登录的话，那么您需要确认您登录的这个账户是否有权限下载这个镜像。子账户默认没有任何权限。关于仓库的访问控制授权，请参见仓库访问控制。镜像拉取ImageId不能保持一致用户Docker版本低于1.12时，ImageID和宿主机环境有关，导致其在各个机器上不一致。公有仓库数量、私有仓库数量已经到达仓库上线时，会报错不允许上传。免密组件aliyun-acr-credential-helper是一个可以在ACK集群中免密拉取ACR个人版或企业版私有镜像的组件。它是通过读取ACK集群内的kube-system命名空间中的acr-configuration的配置，进行私有镜像拉取。表：免密组件configmap配置说明配置项键配置项键说明配置项值service-accountexpiring-threshold默认值为15m（建议使用15 min）。watch-namespace期望能免密拉取镜像的Namespace。本地Cache Token过期阈值。acr-registry-info使免密组件作用于指定的服务账号。容器镜像的实例信息数组，YAML多行字符串格式，每个实例以三元组方式配置。默认为default。默认值为空，表示免密拉取本地地域的默认容器镜像实例仓库。针对企业版容器镜像实例，配置示例如下：针对个人版容器镜像实例，配置示例如下：默认值为default。当取值为all时，表示期望所有Namespace都能免密拉取。如果需要配置多个Namespace时，以逗号分隔。21 企业级云原生白皮书项目实战企业级云原生白皮书项目实战 22企业级云原生白皮书项目实战如果部署的Kubernetes资源（例如无状态应用Deployment）使用了自定义的Ser-viceAccount，需先调整免密组件配置文件中Service-Account字段，使其作用于自定义的ServiceAccount，再进行部署资源操作。确认Kubernetes集群所属地域与要拉取的镜像所在的地域是否一致，默认配置只可以拉取本地域的镜像。如果需要跨地域拉取镜像，请参考下面的配置。（仅适用于公网拉取）在Kubernetes资源（例如无状态应用Deployment）模板中配置拉取凭证（image-PullSecret）会导致免密组件失效，如果需使用免密组件，请避免手工配置拉取凭证（imagePullSecret）。使用自定义RAM角色的AccessKey ID和AccessKey Secret进行镜像拉取的情况下，需要把访问密钥写入configMap，这样存在一定的密钥泄露风险。请确定AccessKey ID和AccessKey Secret所属的RAM角色只拥有拉取容器镜像的相关权限。在集群中创建新的Service Account一段时间后，免密插件根据ACK集群默认权限生成的ACR私有镜像拉取Token才会更新到应用使用到的Service1Account中，使用Service Account的应用才会使用Token去拉取镜像。如果创建完Service Account之后立即创建应用则会出现因鉴权失败无法拉取的情况。图：configmap配置示例图：免密组件日志!图：跨地域配置示例23 企业级云原生白皮书项目实战企业级云原生白皮书项目实战 24企业级云原生白皮书项目实战免密插件默认覆盖ACK中所有命名空间中默认的ServiceAccount中的imagePullSe-cret字段。被覆盖的ServiceAccount会随着对应kube-system命名空间中acr-con-figuration配置项中的service-account字段变动而变动。(见上图)。在修改kube-system命名空间中的acr-configuration配置项时，请确认缩进是否与给出的场景的例子相同。建议直接复制对应场景的YAML内容到编辑器中，修改对应的值然后直接应用到集群，以保证YAML格式的正确性。企业版实例创建后，默认不允许通过公网访问。因此在配置公网的访问控制策略前，需要先打开公网的访问入口。在打开访问入口之后，会默认生成一条127.0.0.1/32的公网白名单。如果删除所有白名单，可以认为放开所有的公网机访问ACR实例。镜像太大，造成每次部署时候拉取速度慢，以及传统容器运行需要将全量镜像数据下载后再解包，然而容器启动可能仅使用其中部分的内容，导致容器启动耗时长。此种场景可以考虑P2P加速和按需加载容器镜像。从本地数据中心访问容器镜像服务企业版实例客户的网络架构通常是多云部署，或者云上和云下通过VPN网关、高速通道物理专线、智能接入网关打通本地数据中心和云上VPC，从而实现本地的数据中心或者本地IDC集群访问ACR服务。通过上一小节企业镜像服务推拉架构，我们知道ACR企业版涉及Registry、AUthorization Service三个服务，所以如果要实现云上和IDC打通的方式实现IDC访问ACR服务，需要打通这三个服务的三个域名。前提条件：云上VPC中的ECS能够正常访问容器镜像服务企业版实例。具体操作，请参见配置专有网络的访问控制。已打通本地数据中心和云上VPC。具体操作，请参见连接本地IDC。获取路由地址需要获取OSS Bucket、容器镜像服务企业版实例和鉴权服务在VPC中的IP，根据获取的IP在本地数据中心创建路由规则。获取OSS Bucket在VPC中的域名。关于OSS内网域名的更多信息，请参见OSS内网域名与VIP网段对照表。OSS Bucket在VPC中的域名为$InstanceId-registry.oss-$RegionId-in-（如果您使用的是自定义OSS Bucket，则域名为$Cu